I’m a UX/UI designer and front-end developer at Glassbreakers. My background is in computer science and interaction design. Interface design and development is what I work on during the day and dream about at night (not exactly, but that sounds cool).
Recently, I found myself working on a project involving design and code that I started just over 9 years ago. When I first started, Metronomic was an exercise in learning how to create an OSX Dashboard Widget. (It’s sad for me that Apple is disabling dashboard widgets since that means that I probably won’t hear from people using this anymore). For such a simple app, there were (surprisingly) quite a few technical challenges involved.
Beyond the technical, embarking on personal projects is always an adventure in understanding both the self and the world.
It has been an interesting experience reflecting on this project because it’s the only one I have had a chance to think about how my coding standards has evolved. There are definitely instances of projects where I posit the thought experiment of:
“If I were to code this again, would I do it any differently?”
I am guessing this is a recurring thought experiment for most developers, and personally, for the projects that I have worked on, it’s mostly been a theoretical endeavour (because really, it is just a waste of time on coding something that still works or if that project is no longer relevant).
So in this instance, I actually did/do continue to work on it (albeit at very large time frame gaps) and did re-code it. Though mostly to keep the widget functional. One of the most amazing revelations is seeing the evolution of my coding technique. There is a mixed feeling of pride and relief of feeling skill growth. It functions as a mirror reflecting a sense of progress.
Honestly, the code is far from optimal and there are certain parts I can clearly see that are inefficient, though as I’m writing this article, I’m debating whether or not I should optimize/refresh it to current standards.
I am amazed at how many comments I left in my original code. It was a little on the excessive side, but I am proud of my younger self because I did not have any issues understanding my own code even though it’s been almost 10 years since I first wrote it. My advice:
Comment your code. Seriously.
This is more of a general developer lesson I have picked up on in all my years of coding is that you will forget why you coded something in a particular way. I’ve picked up the habit of commenting enough so that someone who isn’t familiar with the code will be able to pick up enough hints of where to look and how it is structured. No matter how much you think you will remember why you did something in the first place, memory fades — I have definitely run into instances of looking at my own code and wondering what the logic behind it was. Also as a side note, working with other people’s code is a nightmare (if they don’t leave some comments) because everyone’s style is so different, and there are (potentially) infinite ways to do code logic and no guarantee that any style is obviously clear.
- Audio. HTML audio has gone through a few evolutions since I started. There is the current HTML5 audio objects now. The initial versions used the <embed> tag and I think this third iteration through updating the sound objects, I’m not even using HTML tags anymore and just creating the Audio objects directly in JS. There is also a lot of experimentation regarding file formats. .WAV, .mp3, .ogg. File compression. Trimming audio. Volume adjustments. Understanding dBFS, not to be confused with the decibel scale.
“How is it that something is the LOUDEST when it’s at zero dBFS and everything on the scale is negative!?”
- Rotational calculation / animation. This is related to timing as well, and required some processing of maths (oh no!). For the ‘analog’ view, I had to convert the digital timing into a mechanical (or at least the analogy of one) visualization. Flashbacks to classes on geometry, calculating differences in rotation, degrees, radians, calculating rotational angles for dynamic tempo changes.
- Canvas visualization. Canvas drawing is powerful but not great for most web contexts. It requires some knowledge of drawing 2d context state stacks which is related to more digital graphic rendering concepts such as matrix stacks in openGL. (Gotta love those hierarchical rendering models!)
- HTML validity. I have had to do incremental changes over the years when new versions of OSX (or Safari I’m guessing) come out and it would break the widget because of new HTML conventions that would no longer accept previously valid code. Frustrating, but a good lesson on being updated on HTML formatting standards.
You’ll never know what you’ll learn if you don’t try anything new. Experiment with the unknown and explore new horizons. Discovery fills the soul with joy.
Interacting with the world
Interesting surprise emails have been a result of this project and people have told me about unique ways they have been using the widget. Most uses are obviously regarding uses for musical purposes, but then there are the unique stories about helping with Buteyko breathing exercises for asthma, using it as a practical educational example on musical perception theory, and aiding in training for flamenco dancing.
These wonderful stories make this project so worthwhile. Engaging with people about the app has lead to some of the most authentic conversations I have ever had. When I step back to think about it, I am in awe of how people just contacted me, people from all walks of life across the world who just wanted to talk about what I made. Craft is a language of shared experience.
On the flip side, I also encountered radical cynicism dealing with negative feedback. People can be harsh, and brutally so. (The internet is a very unforgiving place).
“this is the untightest Metronome i ever witnessed”
“Nice widget, but it limps, and is therefore useless.”
I learned a lot in understanding product expectations and dealing with unsatisfied customers. You can’t satisfy everyone, and all you can do when you release something is hope that people will like it. People want products and they want it to work how they want it to (even if they didn’t pay for it).
Why personal side projects?
I already do design and development in my day-to-day, but having projects beyond work-related responsibilities are good for the creative soul. They serve as a north star and reminder of why I enjoy doing what I do every day. The privilege of having professional work assignments that align with personal values that feed and stoke the creative fire within is a luxury. Personal pet projects are there as a contingency to make sure you have that guiding light to keep searching — the desire to learn; to create; to go beyond what is expected; to keep pushing the bar.
I want you to find your north star.
Find what drives your soul.