In part 1 of this series, I examined what I felt was a central contradiction in how we use computers: we expect them to save us from rote, tedious, repetitive, and error-prone work, and yet designing computer software can be a rote, tedious, repetitive, and error-prone task.
By manually applying programming and UX patterns to the design of software, we can guarantee a certain level of consistency from one app to the next. Nevertheless, by mis-applying existing patterns, disregarding best practices or making other errors when crafting computer software, we unwittingly allow anti-patterns to destroy this hard-fought consistency.
This is to say, computer code is ephemeral, and software only works until it’s broken again.
From the time I discovered the existence of music in the MP3 format, I became infatuated with the idea of collecting and cataloguing music. Anytime I wanted to add to my library, I’d search for a song or album I enjoyed, download it to my computer, and drop it into my music library. I would spend a lot of time carefully crafting the metadata in my music collection. This meant ensuring that all tracks, album and artists names were properly spelled and capitalized. I would make sure that every song was placed in the context of an album, with the track numbers filled in and album artwork attached. Recording years, genres, lyrics, and composers were also painstakingly researched and slotted into the appropriate fields.
I spent hours doing this. The idea of owning a well-curated and -catalogued music library very much appealed to me — as it does to a lot of music collectors. And hey, what can I say, I’m the son of a librarian. I’ve written about metadata and cataloguing elsewhere on this blog, with particular reference to searching for music.
At any moment, a stranger could look at my music library and get a snapshot of what artists I enjoyed listening to, what music styles and years I was drawn to, what my favourite tracks were, and so on. Why was this important to me? In some senses, it was functional, in that having a well-annotated music library could allow me to construct specific playlists, to suit my moods and tastes. In other senses, it was purely aesthetic.
iTunes allowed me to own, maintain and be proud of my personal radio station, programmed expressly to cater to my tastes.
Along Came Spotify
I had heard a healthy amount of buzz about Spotify from some Swedish colleagues of mine, and in 2010, on a trip to Sweden, I finally got the opportunity to try out the desktop app first-hand.
The first thing I noticed was that the interface bore many resemblances to Apple’s iTunes. In a single window, one could find their playlists on the left, their music library in the main pane, and search, and filtering options at the top.
There were some variations, but by-and-large, iTunes and Spotify were very similar products. The biggest difference, of course, being that Spotify is an online product which streams music from a remote library. This means that, unlike iTunes, it is impossible to have a global look at the entirety of the music library, due to its sheer size (Spotify’s global catalogue ranges into the 20+ millions).
Indeed, with Spotify, it was necessary to have search capabilities in order to locate the song, album, or artist you wanted, and then play it back. iTunes relied mainly on a browsing interface.
Another direct consequence of this architectural difference between both products is that Spotify provides read-only access to its song database, and in my case, that meant that curating the music library as thoroughly as I had previously done was impossible. If I spotted a typo in a track name, for instance, I would have to flag the track as having inaccurate information, in order to notify a Spotify curator to fix it. There was a shift, from owning the music and the data, to simply having access to it. In Spotify, the editorial opportunities available were limited to creating playlists.
Apart from Spotify and iTunes, there are countless music players of various architectural styles, and naturally, the one base trait they must all share is the ability to play music. Beyond this, each one offers a grab-bag of features to support the central task: metadata editors, smart playlists, visualizers, integrated lyric searching, etc.
I take issue with the current practices of developing software because, as I referred to in the first part, it is a labour-intensive process which requires a certain knowledge of the inner workings of computers. Not everyone is inclined to learn the discipline of computer programming, and so programmers and UX designers must step into the shoes of an end-user in order to anticipate and dictate which features are included, and which aren’t.
For example, when I find a song that is particularly appealing to me, I tend to obsessively binge-listen to it. (It can get pretty bad. I remember playing and rewinding “The Sign” on my Ace of Base cassette album at least 20 times in one sitting. But I digress.) Computers remove the need to rewind songs in order to listen to them again. Most music players will even include a handy Repeat One feature, for people like me.
Consider this: here is a feature that I know and enjoy, and also a feature which is not particularly difficult for a computer programmer to implement. To describe the logic behind the feature is dead easy: when the song finishes, play it again.
I enjoyed this feature when using Apple’s iTunes, but was dismayed to find it absent in Spotify. Luckily for me, the company introduced it to their desktop player in February of 2014, and announced it with a blog post. “You asked and we listened!” they announce.
Unfortunately for me, as of the time of this writing, this feature is still unavailable in the Android app.
I believe this perfectly illustrates another intrinsic absurdity in the process of manual software development: a feature that I use and enjoy, and which is incredibly easy to describe and implement, is not necessarily available to me. I must rely on the software maker to implement and maintain it. Apple and Spotify, for all of their talent, are limited in what they can design and implement, and so feature requests that shout the loudest get answered the fastest.
Conversely, because of Spotify’s and iTunes’ auto-updating features, there exists the possibility that the features I know and enjoy won’t be there tomorrow. Repeat One exists in Spotify on my Mac, but for how long?
Software ecosystems are in a state of constant flux. Features which were previously available or known to you might be removed, modified, or broken, with each subsequent software update. New features and paradigms are introduced all the time, as products evolve, grow, and shift their focus.
A handy but little-known feature might be removed from one version of an application to the next. Conversely, an incredibly-useful but obscure feature that would make your job ten times easier might never get built, because the software’s developer has other priorities.
These are human-motivated changes, but what about unmotivated ones, such as bugs and anti-patterns? While we’re on the subject of iTunes, have you heard about the installer for iTunes 2 which could potentially erase your whole hard drive? And not to play favourites, Spotify recently found a severe bug in their software which required every Android user to manually upgrade the Spotify app, and re-download all their previously-downloaded music. This is not a dig at either company — programming software is very tricky business. Even with the incredibly bright minds at both companies, well, shit happens.
Owning Your Computer
If you want to teach people a new way of thinking, don’t bother trying to teach them. Instead, give them a tool, the use of which will lead to new ways of thinking.
– Buckminster Fuller
I think there’s a much better way to make software, and I alluded to it in the previous article. By using computers to write computer programs for us, we can do away with many of the human errors which result in features breaking.
By delegating the rote, tedious, and error-prone job of programming to a machine (which is why we built the machine in the first place), we can focus on using our intrinsically-human gifts of creativity to design software faster, much cheaper, and without the resource bottleneck that exists today.
In much the same way as iTunes allowed me to own and curate my own music library, I’m looking to have the same experience on my computer platform at large. I can own the physical boxes that run the software, but as far as the software itself goes, I mostly have to trust that other people will do things that make my computer useful and pleasing to me. What if there were a better way?
Imagine being able to build all of your own software. In the case of a music player, you could start by having a list of hundreds of different features in front of you, each with its own checkbox. You’d go through the list, checking the boxes of features you wanted, and leaving unchecked those features you didn’t care for. At the end of the form, you’d find a button which, when pressed, would churn out a bespoke music player, tailored precisely for your tastes, having exactly the capabilities you needed.
Imagine, as well, being able to describe a feature, e.g. “the ability to listen to a single song on loop,” and have that be all of the effort required for you to have that feature built into your bespoke music player.
Going beyond that, imagine the capacity to describe a feature that no one has ever heard of or implemented before, and have it be built and crafted into your music player, e.g. “Always repeat songs by Tom Waits twice, before moving on in the playlist.”
In order to have such a software ecosystem, we need to bridge the gap between human description of features, and their technical implementation. We do this by isolating and cataloguing patterns of computer software design, and their meta-patterns of assembly. How does a feature like the Repeat-Waits break down into smaller components, (i.e. “repeat twice” and “identify Tom Waits songs”), and how do those components fit together in a meaningful way?
The translation of meaning, from human description to software implementation, is key to this new way of programming, and this is where I think the ideas of semantically linked data have a lot to offer.