I've been bouldering for about five years now. Over this period of time, I've had good days and I've had bad days. I've had long periods of growth as well as long periods of stagnation. I've taken time off due to injury or various life events, and I've had stints where I'm gone to the gym three or more times a week. Once I was hooked, I couldn't not track my workouts. And since I wanted to track data, I couldn't help but go overboard and make a web app for it. This satisfying all my competing desires to build products, climb fake rocks, and enable my incredibly casual interest in the quantified self.
\nWhenever I build a product from scratch, I start with asking why I even feel the urge to build the product. This first helps me prioritize work and second keeps me from adding scope for scope's sake. I'm a firm believer in Kathy Sierra's Making Users Awesome concept. The gist of which is that users don't want products, or web apps, or material goods. They want to be more awesome. To this extent, no amount of clever engineering or smart design will keep users if you aren't making them feel more awesome.
\nI knew that in my mind I would be more awesome if I had an unlimited memory when it came to how my climbing sessions went. What to build and how to build it all came after this core hypothesis.
\nThe experiment that tested this hypothesis needed to be able to track pertinent climbing metrics, and it needed to be able to report those metrics back to a user at a later date. So I set out to make a single page that allowed a user to punch in the difficulty of a problem they just climbed using the Hueco, or V-Scale. My user experience chops kicked in at this point. I think one of the most important and undervalued aspects of user experience (especially in today's increasingly dynamic use of technology) is designing for context.
\nIn this case, the context is climbing in a gym. Your hands are chalky, your fingers hurt, your fingerprint may be worn to the point where it won't unlock your phone anymore, and yet I'm asking you to interact with this app. Your mind is on the wall: what will you climb next? What did you do wrong? Does your friend need a spotter? Are you in a stranger's way? And yet, I'm asking you to interact with this app. For these reasons, I assumed that a short time to input data would be important. I say \"assume\" because despite being an active boulderer, a seasoned web developer, and a student of user experience, I didn't actually know for sure until I tested the assumption.
\nIn addition to making users awesome, I am a fan of the Lean methodology. Although not prescribed directly in The Lean Startup, the Riskiest Assumption Test perfectly describes the importance and science behind what an MVP is meant to do. In the case of Climb Tracker, the riskiest assumption was that people would be willing to pull out their phones to log their climbs as they climbed. This could be tested before I went down the path of making beautiful charts to report back metrics to a user.
\nI could have done this test in a low-tech manner, but this was my side project, and I'm an engineer. Of course I wanted to make a good project, but I'm also not about to turn down a good excuse to kick the tires on new tech. In 2016, that new tech was React. So I made a prototype of the climb tracking experience in React and shipped it as a progressive web app. I used React and Firebase to quickly take care of authentication and realtime storage.
\nThe test was mostly successful. I loved the experience, and my friends were pleased with it. One friend ultimately didn't care enough to bother tracking everything (the product would likely never work for him). Another friend liked it, but really didn't want to climb with his phone on him. He immediately asked for a UI that worked on his Android Wear watch. I politely but firmly told him no :)
\nNow that my riskiest assumption had been tested and passed, I could move on to building the rest of the app. Instead, I did nothing. As side projects so often go, it fell to the wayside. It still stored data forever in Firebase, so I wasn't losing information for future analysis, but I didn't make the time to improve the app.
\nI have since worked on it more and added a Reports section, which includes monthly digests for every month with reported climbs in it. I want to do more beyond this, but even as is, I'm happy with it as a side project.
\njavascript:<insert-lots-of-javascript-here>.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-jobs.png","alt":"Nomad UI jobs list","caption":"The Jobs List page serves as the home page for developers interacting with Nomad. It represents all software known to the cluster.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-deployments.png","alt":"Nomad UI job deployments","caption":"Nomad supports automatic rolling and green/blue deployments as well as optional canary deployments. All of this is represented in the UI\nand kept up to date in realtime.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-logs.png","alt":"Nomad UI stdout log streaming","caption":"Nomad also has a streaming HTTP API for tailing logs for allocations. The UI lets any privileged user see these logs using fetch and streaming\nrequests when possible and falling back to polling otherwise.\n"},{"project":"nomad-web-ui","url":"/images/nomad-ui-stats.png","alt":"Nomad UI metrics over time","caption":"Stats in Nomad are not stored, but the UI makes a best effort attempt at tracking data over time by storing previous values in memory,\naccounting for skipped data, and persisting historical data (up to a limit) between page views.\n"}]}},"pageContext":{"slug":"/project/climb-tracker/"}},"staticQueryHashes":[]}