Summary
I’m a headphones type of gal, and most of the time if I’m opening iTunes it’s because I need to sync my iPhone. I know I don’t use most of the toolbar functionality, much less the functionality of the whole application, but I wondered, who does? And, most pressing, what should the application be to best support the way people use it, or could use it?
This document summarizes some background of the application, three very informal user interviews I conducted to get a better sense of usage beyond my own, my redesign process, and my recommendations for a more flexible, customizable iTunes toolbar.
How We Got Here
The iTunes 10 toolbar is, compared to other ways Apple’s software has evolved, surprisingly not that far off from its predecessors from even a decade ago. Based on SoundJam MP, iTunes has looked functionally the same since its first release on OS 9 in 2001, down to the equalizer display, radio handling, progress bar, volume slider, and play controls. Apple generally makes iterative changes to their designs, but the strong adherence to the original version of iTunes is surprising, especially as Apple has been moving away from a device look for some time.
Elements of the current interface include:
- Standard OS window control buttons
- Audio control buttons, for navigation to the previous and next tracks, and playing or pausing (or stopping, depending if the user has navigated to another section of the sidebar) a track
- Volume slider
- Main display window, which contains various elements:
a. The LCD-like window itself
b. Equalizer display
c. Track progress bar, with time elapsed and time remaining
d. Track information, including title, artist, and album (or video information as appropriate)
e. Genius button, for triggering a genius playlist based on the current track
f. Jump link button to the current track in the library - Standard OS application name
- Library view toggle buttons, for viewing in various types of lists, grids, or Cover Flow
- Search
a. Faceted by selected sidebar area
b. Filtered within a selected sidebar area facet
Interviews
I conducted three brief interviews with friends over instant messenger to gather additional ideas about pain points and suggestions about the toolbar. I’ll call these friends Users A, B, and C. All are men in their early 30s, Mac and command-line users for work and at home, and all work in various developer roles in software and accessibility. Quotes have been cleaned up from IM formatting to have standard English capitalization and punctuation.
As a prompt, I asked simply how they felt about iTunes toolbar.
A’s Interview
Screenshot of User A's Sizzling Keys display
iTunes 10 search filters for the Genius facet
User A heavily uses a third party application, SizzlingKeys, to interact with iTunes. He feels limited by the way iTunes handles keyboard shortcuts in general, and hardly uses mouse interactions with the application. He prefers SizzlingKeys’ larger display of track information and its handling of album art. In fact, he suggested expanding the toolbar to include album art instead of hiding it in the sidebar drawer or inline in the library.
His main additional concern about the toolbar revolved around the search interface. “Why not actually search everything you’ve got?” he asked, but followed with: “It would take a better search results view.” Overall, A’s advice for a redesign was, “Give up on the ‘iTunes looks like a device’ thing.”
B’s Interview
Center display screen for iTunes information and select controls
User B’s first criticism of the toolbar was of “that window in the middle of it.” He continued, “Especially when multiple things are happening and you need to click that little arrow button to cycle through them? I didn’t realize you could do that for the longest time…It’s like the LCD in a car stereo. I have a big monitor. Let me see that information if a want it.”
Library display toggle with explanatory tooltip
I went on to ask User B some specific questions about elements in the toolbar. Regarding the view buttons, he said, “I have switched it before, I’m sure, but I can’t remember why…I think it’s the kind of thing where you determine which one you like once, and then you generally go with that.”
C’s Interview
User C’s main comments were also about the “window” and search. “I don’t like how the search bar is too small,” he said, “and I don’t like the little thing that lets you switch between four different view modes, simply because I don’t switch.” He then went on to suggest, like User A, that search be less faceted.
iTunes DJ
User C, like User A, also interacts with iTunes in a very specific way: “All I want iTunes to do is load the right playlist into the DJ mode and start playing.” He described his typical use case, which is to start iTunes DJ (which is currently managed in the sidebar), maximize the application, and let it run in the background.
Interview Summary
As the center display and search came up in multiple interviews, my suspicions that these elements could be vastly improved or modified gained some weight. I was also pleased to find an edge case in User A and his heavy reliance on a third-party application to interact with iTunes. However, his general preference for keyboard shortcuts would easily fit into further revision of the application to fall more in line with other Mac applications and OS X in general.
Since the general trend in the interviews was toward simplifying the experience of using iTunes, I feel comfortable considering User A’s interest in displaying album art and actually increasing the size of the toolbar to be an edge case as well. I am not convinced that User A would not continue to use a third-party service, at the very least out of convenience and habit, even if modifications were made to iTunes to support his requests. User C’s use of iTunes DJ could also potentially be an edge case, but perhaps one more easily managed in the schema that was developing.
Interestingly, no interviewees brought up any aspects of using iTunes for video, and it wasn’t until I began writing up this review that I even thought about iTunes as a video player. This is probably a bias in my peer group, and should probably be explored in more depth for a more thorough redesign. However, I think the direction I ended up taking is agnostic enough to cover use cases for video as well.
Obviously, this was a very small (and technically biased) interview group, and more thorough user group studies would benefit further work.
Process
To begin my redesign, I translated the current toolbar into a lightweight paper prototype, element for element.
I then considered tweaks to a few things that have always bugged me, specifically:
- I changed the control buttons to more closely match those found elsewhere in the OS (2 in the diagram).
- I removed the line from the leftmost volume icon, to indicate that it actually mutes (3 in the diagram).
- I changed the order of the view toggle buttons (6 in the diagram) to more closely match those in Finder.
The scale of the prototype, even with my admittedly chunky slips of paper and poor photographing light, made me look again at how busy, tall, and unwieldy the iTunes toolbar is. Based on trying to reconfigure the current layout and on the interviews, I believed the answer was in stripping out and simplifying elements.
An early prototype with a simplified information display, more OS X-like buttons, and all library layout related elements removed
As I began to consider different ways of handling functions in the toolbar, these ideas fell into one of four main categories, in no particular order: buttons, sliders, track information, and search.
Buttons
The button situation in iTunes is, in comparison to Apple’s other software, strange, and all tied to its legacy look and feel. Some buttons are obvious if inelegant (like the control button set: 2 in the initial diagram), while others provide little feedback and look more like indicators that the user toggled something on (like the equalizer, genius, and jump-to-track buttons: 4b, 4e, and 4f in the diagram). Overall, button treatment is inconsistent, sometimes nearing the look and feel of other applications, sometimes completely on its own.
Sliders
A permutation with more OS X-like and browser-like buttons
Audio players traditionally display progress bars and, sometimes, volume sliders. iTunes displays both. Increasingly on the web, volume sliders are mimicking OS volume controls by being collapsed in a single icon that expands to reveal a slider on-click. This seemed like a good solution for the volume issue, since it is one already in use in OS X. Progress bars, meanwhile, are still frequently displayed in full. However, do they need to be? Based on my own preference and that of my interviewees, listening often takes place in the background of other tasks, where tracking progress or jumping around a track aren’t frequent use cases. I speculated that there could be a more minimal way to display progress and reveal the progress slider when necessary to jump around a track.
Track Information
Display text overlapping in iTunes 10
Background listening requires little information, and what information it does require is minimal; frequently a listener will wish to check the track title, artist and album. iTunes prominently displays this information in a quite outdated look that is mixed up with other elements, busy, and potentially confusing for casual and active listening alike.
For a focal point of the application, it contains small text mashed into a busy section of the interface. Track information and nearby buttons often overlap if the window is narrow or the track information is long. An obvious solution would be to bump up the font sizes and move the buttons to the upper corners of the display element, but this answer does not get to the root of the issue, which is the questionable grouping and layout of these elements in this way at all. It contains very important information displayed in a way that unnecessary mimics LCD device interfaces, a format that needs not be perpetuated to accomplish the display goals of the application.
Search
A version with additional icon buttons and more browser-like search and display
Whether users are interacting directing through the interface or with a third-party tool, the beginning of much interaction with the the application starts with search for a song, artist, or other piece of data, to kick off listening, playlist creation, or other use. In an age of smart, contextual search results, the forced facets of the search bar, which limit the user to one particular area of search, and consequently one particular set of filters, based on the area selected in the sidebar, are unnecessarily limiting.
If search is such an important feature, why not make it more prominent and function more like the type of search most of us do every day online? Like the track information display, this is a troublesome element that seems like it may need more than a gentle reworking.
In each of these areas, my web bias is obviously showing. But the more I thought about what the basic functionality of iTunes is, the more I started thinking about it as a media browser, that is, an interface to content, like Safari (or Google Chrome), not an application for managing or creating content, like iWorks or OmniGraffle, or even Mail. I decided to go down the route of making iTunes’ toolbar as transparent, flexible, and slim as seemed reasonable. The end result was, not surprisingly, very similar to a web browser.
Recommendations
My recommendation is to dramatically streamline the toolbar to bring it more in line with Apple’s current aesthetic, as well as to place focus on important features while providing simple interactions and the option for further customization. The result is a more flexible, pared-down interface that reduces the amount of default real estate taken up by the toolbar while maintaining its core functionality.
This wireframe revision includes the following areas:
- Standard OS window control buttons
- Revised, more OS-like and browser-like audio controls
- Customizable icons area, with Genius as a default
- Condensed volume control, with on-click slider interaction
- Standard OS application name
- Combination display and search bar, with Safari-like search
- Condensed track progress display, with on-click slider interaction
Audio Controls
Standard OS X navigation buttons
Audio controls would retain the exact same functionality while gaining the appearance and interaction quality of the back/forward buttons found in Safari, Finder, and other OS X native applications. This would be a departure from iTunes consistent look, but would better match Apple’s look and feel.
Customizable Icons
With a slimmer look and fewer defaults, iTunes could be easily customizable by the user to add additional functionality to the toolbar, as Safari is now. Additional toggles and triggers like iTunes DJ, library views, and visualizations by leveraging the existing logic provided by Safari’s Customize Toolbar… interface, accessible by right-clicking on the toolbar. It was User B’s comment, “Let me see that information if a want it,” emphasis mine, and User A’s edge cases, that made me consider creating a more flexible layout for the toolbar.
Safari's drag-and-drop toolbar customization interface could be re-used for iTunes features
Volume Control
Suggested volume interaction
Mac users are already familiar with the on-click interaction with the universal volume control of OS X, so using the same interface for iTunes would be a low-impact transition. Additionally, the volume icon could animate like the one in the menubar to provide feedback as the user moves the slider up and down, eliminating the need for multiple static icons, and unify the user’s experience regarding volume control.
Display and Search Bar
While I am not a Google Chrome user in general, I feel that the browser’s combined address and search bar could be a beneficial addition to iTunes in the form of a combined information display and search bar. Along with some removed elements described below, a heavily revised information display area would slim the toolbar and provide multiple uses for prime real estate in the center of the toolbar. The toolbar display would show the current track information until the user clicks in the text area, triggering search, which would target all media, not just that associated with the current sidebar facet. Additionally, search would behave more like web search, specifically a combination of Safari and Chrome’s suggestions, recent searches, and facets.
Suggested search interaction with richer results
Progress Display
For a stripped-down version of the track progress bar, I looked to GrooveShark‘s handling of track time. GrooveShark has ample room at the bottom of the screen for two full progress bars, but its handling of progressive and total track time is a excellent way to show progress without displaying a full bar.
GrooveShark progress bar, showing elapsed time in white and total time in gray
Similarly, iTunes could display dynamic progressive track time and static total track time. A progress bar would be triggered by clicking on the progressive time, which would changed to indicate track location as the slider is dragged.
Proposed progress slider interaction
Removed Elements
Several current elements have been removed from the toolbar in this design, including the equalizer toggle (4b in the original diagram), the jump-to-track button (4f in the original diagram), and the view toggle buttons (6 in the original diagram). Features like these are not primary to iTunes’ function, and could be added as customized icons in the toolbar in the manner described above.
