On the design of Nasturtium Player
I’d like to give a few personal notes on the process leading up to Nasturtium Player 1.0, since I’ve always enjoyed reading these narratives from other developers…
Background
Since iTunes is the 800-lb gorilla of Mac music players, let me set the stage a little by describing the paradigm of its interface. iTunes has a monolithic single window — as of version 11, it has a minimum size of roughly 840x550 pixels. Why so big? The answer lies in the source list, present since the very first version of iTunes until it was unceremoniously handcuffed and stuffed in a closet in iTunes 11. The source list defines iTunes as the Finder of music, built to manage and organize your media in much the same way that Finder manages your files. This design decision was undeniably brilliant for Apple’s purposes: it allowed them to easily bolt onto iTunes the iTunes Music Store, and then Movies, TV Shows, Podcasts, Books, Apps, Shared Music, Radio, and a variety of playlist-like sources, not to mention devices such as iPods, iPhones, and iPads, all in the same iTunes window. Indeed, innumerable other music players subsequently imitated this interface: doubleTwist, Sonora, Spotify, Rdio, Pandora, and even the llama-kicking WinAmp, have all adopted some kind of Finder paradigm.
This expandability came with a cost though, and that cost was defining the way users interacted with their music: albums and tracks are presented as curated objects existing within iTunes. To listen, you browse to the song you want and select it. Contrary to Apple’s “Rip. Mix. Burn.” ad campaign, iTunes didn’t encourage causal DJ’ing, instead relegating the user-defined playlist to a small row in the source list that you had to drag and drop your tracks onto. If Fitts’s Law implies that more frequently-used interface elements should be larger, then clearly Apple expected playlists to be an occasional extravagance, perhaps in preparation for burning a CD.
In the recently-released iTunes 11, there is evidence that Apple also recognized the anachronism of exiling playlists to the source list — they’ve been moved to their own pop-up list on the other side of the iTunes window. Furthermore, we’ve also acquired the “Up Next” popover, a sort-of-but-not-quite-playlist. Unfortunately, “you can’t make a complex application simple by adding a veneer of simplicity on top of it.” Nonetheless, the central paradigm of iTunes remains the same, a monolithic window which does an admirable job of browsing your music, with playlists and other new features jammed in the edges as a design afterthought. (Indeed, as I write this, the main functional points listed on Apple’s “What is iTunes” webpage are, in order, “Browse”, “Organize”, “Play”, and “Genius”.) Perhaps this was the right thing to do when digital music was a novelty, and the average user an OCD computer geek, but increasingly today’s user of iTunes feels like Smaug, endlessly admiring a carefully hoarded pile of music but not actually doing very much with it.
Inspiration
Nasturtium Player was born out of a recurring frustration with actually listening to music in iTunes: I would navigate to the album I wanted to listen to, double-click to play, and hours later realize that the album had finished and in the meantime I’d been listening to nothing. Something very much like the motivation for Iconfactory’s Take Five app, in fact, except that in my case, the music was just running out. I could’ve made a playlist every time I wanted to listen to a few things — but this was a hassle of button clicking and precise dragging. What’s worse, pre-iTunes-11, actually viewing your playlist took over your entire iTunes window. It just felt clunky.
I knew music listening could be easier — in fact I had experienced better in my Linux days, via an obscure little music player called Muine:
Instead of imitating iTunes as so many Linux jukeboxes did (and still do), Muine introduced a crucial innovation, making the main window a playlist, rather than a browser. By inverting the priority of these interface items, Muine put the focus on listening to music instead of hoarding it. Muine never gained much traction amongst the highly-technical, feature-focused demographic of Linux users (it hasn’t been updated since 2009), but perhaps a modern implementation of the concept for Mac users might do better…?
YouTube
From the start of this project, it was clear that bringing this playlist-centric paradigm to modern Mac computers would represent a unique and valuable addition to the OS X software ecosystem. But Nasturtium Player had to go further — if I was going to de-emphasize the importance of browsing the user’s music library, why not eliminate the boundaries between personal and shared music altogether? Disappointingly, services like Spotify and Rdio do not (yet?) allow commercial use of their APIs, but a recent study drew my attention to YouTube, not as a video service, but as a music service. Thus, it became natural to search for desired music not only in the user’s collection, but also in YouTube. And since Nasturtium Player was built around gathering music in playlists, it was very natural to intermingle YouTube videos with iTunes tracks, in a way that would not have been possible otherwise. I hope that someday it will be possible to legally incorporate music from other streaming sources as well.
Design and Implementation
As can be seen from my sketchbook, Nasturtium Player went through many design iterations on the road to 1.0.0. One early obsession was the idea of a menubar popover, implemented to great success by Fantastical, and subsequently imitated by music apps such as PandaBar. There’s some merit to the idea — a menubar popover is always accessible and stows away when not in use. But every design has its tradeoffs, and in this case, there were two insurmountable obstacles. First, a popover app constrains its interface to a single smallish window, which meant that opening the user’s music library would take away space from the playlist, and further that there would be no way to have multiple playlists open simultaneously. Much time was lost here, first experimenting with an iOS-like navigation and later with dynamically-changing layouts, but in the end it all felt too awkward and contrived for everyday use. The second insurmountable obstacle was aesthetics. Although Flexibits did an amazing job of making it look good (maybe to the point of being the exception that proves the rule), popovers emanating from the menubar are inherently incongruous. I just couldn’t bring myself to do it.
With the popover design ruled out, Nasturtium Player became a small, portrait-oriented window, in the style exemplified by numerous Twitter clients, and indeed Apple’s own iChat. One aspect of the design which was never in doubt was the placement of the current track information and controls: at the top, with the cover image to the left, despite a recent trend for music apps to place their controls at the bottom of the window. I’ve never understood these designs — what’s playing now is the most important piece of information for any music player to show, so surely it should go where the user will look first? In any case, fixing the placement of the current track also made design of the miniplayer very straightforward: just hide the rest of the window!
I was not entirely surprised to learn that Apple had independently arrived at the same answer in the iTunes 11 miniplayer. However, track information aside, there remained the issue of how to place the actual controls, and indeed what controls to make available. One of my perennial media player complaints was the conflict inherent in having a single play/pause button. Either it can show current state or it can show the action triggered by clicking it, but not both. Thus, we end up with situations where the “playing” state looks like this:
Not exactly intuitive, right? After many iterations, I arrived at the solution of displaying both play and pause icons, and highlighting the active one:
You’ll notice that volume and progress controls were also added, but made optional thanks to dynamic sizing of the cover image. Lion’s contraint-based view layout was invaluable here.
Even with these additional controls though, the interface remains relatively minimal. Experimentation showed that having the play/pause etched into the window to the right of the track name felt the most natural to me, perhaps due to left-to-right reading in English. At the same time though, this restricted the space available for adding additional functions. Most notably, there was no room for adding a button to skip to the next track, a feature frequently requested by beta testers, without making the titlebar inelegantly cluttered. I’m very happy with the solution I eventually arrived at, which to my knowledge is unique: since the next track button is typically two play arrows stacked next to each other, why not just accept a double-click on the play button itself?
This trick enabled track skipping in a memorable way, but with one difficulty. Although it’s very memorable once you know it, it’s not exactly easily discoverable. To fix this, I turned to a little bit of subterfuge. I like to peruse the preferences of apps that are new to me, and I suspected that many of my users do the same. Thus, rather than providing an awkward walkthrough or an instruction manual that no one would bother reading, I could instead implicitly document Nasturtium Player by describing the less-obvious actions in the preference window! Here’s what it looks like:
Based on feedback from beta testers, this scheme did indeed lead to serendipitous discovery of less obvious, “hidden”, features.
These are just a few of the many decisions which went into making Nasturtium Player. I haven’t even touched on the design of the rest of the playlist window, or the search panel with its animating accordion view of search results (the single most difficult feature to implement in Nasturtium Player, as it turns out). However, I would like to close this discussion by mentioning one more tiny touch which pleases me out of proportion to its on-screen size: the current track playback indicator. On every other music player that I know of, the current track is indicated by a tiny little speaker icon, for instance here in iTunes:
This is one of those small features that has ossified into place as convention, rather than from any inherent meaningfulness. Does it really make sense for a metaphorical speaker cone to be moving from track to track like a bee pollinating flowers? (And why does it replace the track number? Don’t ask me… Incidentally, my mother thinks the iChat icon is a fish in a fishbowl. I just wanted to mention that.) Fortunately, salvation from arbitrary iconography is at hand: we already have an icon for “play”, and it even looks like an arrow. So, that’s what Nasturtium Player uses to indicate the current track (or album):
The Future
Nasturtium Player is built with simplicity and ease-of-use prioritized over fancy graphics or lots of unused features. As with any first release though, there will be missing features and a few rough spots to be polished over time, but the basic outline is there, and I think it’s a pretty good outline. Nasturtium Player is now available on the Mac App Store for the introductory price of $2.99. Please give it a try!
