This blogger has moved! |
![]() I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
Click the image to see the animation (It opens in a new window).
Please note that the text below is necessary for understanding the animated example above. Well, I think so anyway :-)
The content itself is the interface
I've been thinking a bit about "content is the interface" lately. The idea is to avoid deep hierarchies of thin information by intensifying the information resolution on the screen. Edward Tufte is the great proponent of this idea and lately it has been made current by the MEX conference as their Manifesto #1: Content itself will be the interface of the future.
It is easy to see how to employ this paradigm when the information is manageable, when it's on a "human scale" so to speak. The in-flight entertainment selection in an airline seat, the variety of coffees in a coffee shop, the selection of cars at a dealership. You can take in the information and hold it all in your head at once. (Deciding what to choose is of course a different matter…)
It is certainly both possible and advantageous to use the content itself for most navigation and interaction tasks. But when I tried to apply "content is the interface" to music there were a few additional issues. A typical device can store 8GB of music; that is 2000 songs or about 250 full albums. Many devices can store a lot more. Not to mention the millions of songs you can browse when you want to buy music. Presenting all this music directly is not possible.
In addition, music is sound; you can't actually see it or touch it. You have to choose a visual representation and I've used album art because that’s an abstraction that most people understand and are used to. With digital distribution, there is some movement away from albums in favor of individual songs. I've considered using images of the artists as visual representation but it does not work well. Album art has a strong visual identity and is associated with a particular selection of songs. Is scales well; you are able to make out the album even when scaled way down. This is not the case for photos of artists or bands. They change randomly over time and they don't scale well.
Spatial reasoning
In addition to this, I wanted to try to take advantage of spatial reasoning and spatial memory to make it easier to find and navigate stuff. Let the user see the scope of information available. Start by showing the big picture. When it makes sense, let it behave more like real-world objects. You can normally pick up objects where you left them off. They don’t move when you are not watching, something digital objects often do. (Insert your favorite joke about spouse here.) Over the last couple hundred thousand years our brains has developed a fantastic ability to take in and store where stuff is in our immediate surroundings. Since mobile screens are a part of our immediate surroundings, we should try to take advantage of this ability. It might sometimes make user interfaces a bit less confusing.
This is version 2 of the concept player that I fiddled with over at OTA. This time I've used a larger touch screen (the size is equal to the upcoming Nokia Tube).
Current music players
Screens from a Nokia Series 40 phone and the Sony Ericsson 960W phone.
The problem with the illustrated players is that the vast majority of the screen is décor and "computer administrative debris". The information value is extremely small. All that fits on the 240 x 320 pixel screens are three band names (Nokia) or four song names (Sony Ericsson).
Nearly all players use a hierarchical presentation where the user steps through levels; Genre, Artist, Album, Song. The icons are genetic and do not add any information value. The layout of the W960 music player only uses half the screen width for the song name. The result is that most song names have to be truncated even if they are rendered in a small font.
Playlists
Terminology problem alert: Playlists are normally used to describe a (small) selection of songs on your device. For lack of a better word, I also use playlist to mean the collection of all songs on your device including their metadata.
Going forward I expect that playlists may become more important than the music files themselves. Renting (subscription) may well be the way to consume music in the future, and the list of your music will be more important than the files themselves. A development similar to how bookmarks has moved away from individual browsers and computers and up in the "cloud" from where they are accessible regardless of device. Obvious example: del.icio.us. If you change your music subscription from, say, Rhapsody to Napster, you just take along your playlist and continue enjoying your music.
I don’t think there should be any significant difference between a streaming player and a file player. If you add an album, it should appear in your music collection the same way as empeethree files does. ("Internet radio" streaming is different of course, as you don’t select music, you select a station.) For performance reasons subscribed music probably have to be stored or cached locally.
Hardware
These design sketches are made with the nascent/emerging trend of high resolution widescreen touch phones in mind. Examples are Sony Ericsson Xperia, Nokia Tube and Apple iPhone.
Note that the sketches focuses on the interaction model, not on the feature set or graphic design. Also, the intention has been to work on something that might be useful on actual emerging hardware, so no Jetson style 3D holographic interaction models at this time. Most of the sketches are so called Hi-Fi sketches because it's easier to convey the ideas with something that resembles a product than with plain wireframes.
The basic structure of the app
- The layer named “Albums” holds the music library. It is divided into rectangular sections (labeled Indie, R&B etc…)
- "Hype" is a closable panel. It has an, um, "river" where info related to the music floats by slowly. It has a drop area where you can drag and drop content that you want to subscribe to. (No, let's not call it the shore or the riverbank :-))
- "Shop" is another closable panel that contains a music shop.
Albums (the library)
The busy impression of this well filled music library is intentional. The library contains about 200 albums. (And movies. I'll stick to music to avoid distractions, but I don't see any reason a movie player needs to be distinct from a music player.)
- No particular distinction is made between music that are streamed and music that are files.
- The albums are not sorted alphabetically. New and recently played albums appear on the top of each pile. The reasoning behind this is that the human brain understands space well. We know approximately where things are when they have a position in a physical space. If you want play a song you tend to remember that it was "somewhere in the middle of the pile over there".
- Albums that are played often grow bigger in size.
- Classification (Rock, Indie, R&B etc.) is based on metadata for the music. The user can change classification to fit personal preference. Missing album art is automatically retrieved from relevant web services. It is also possible to identify unknown music tracks via something like Gracenote.
- Suggestions are based on playing patterns and/or suggestion engines like last.fm, Pandora and social engines "people you know listens to…".
The bottom part of the screen displays a bar when music is playing. It holds player and volume controls. If the hardware has separate player and volume controls, that's good. That will make it possible to control the player when in the pocket.
The top part of the screen needs a back button and probably a search function (not shown).
Clicking on a category zooms/expands the category to fill the screen. I have show the albums organized in a grid in this example. But keeping the position and size-difference when zoomed-out needs to be investigated.
Clicking on an album opens it and starts playing.
Individual songs
The player needs a mechanism to access individual songs. Tapping the album above the play-control in the lower left corner could pop up a more detailed player.
Discovery
The closable panel labeled "Hype" is for exploring. Discovery of new artists and bands is an important function.
- Contains related hype (blog posts, news, etc) about the artist or band.
- Can be accessed while listening.
- Displays information related to the currently selected music or to music in general if no particular album is selected.
- The hype blurbs or "story boxes" flows down from the top.
- You can subscribe to any of the sources you find there by dragging them over to the leftmost column.
- I've used last.fm to illustrate one source of info, but sources can be anything, HTML-based, API-based, RSS based, etc.
Accessing hype content
Tapping any story box in the Hype panel zooms to the full content.
Shop
The Shop should display its content in a nice and tidy fashion, as shops do. Since it's so tidy, gridlines between sections don't seem necessary. Navigation should probably be a combination of Tap-to-zoom and Drag-to-scroll. I haven't spent a lot of time on the shop to be honest.
End notes
The Flat Music Player version 2 ended up having only play/pause controls, a back-button, and two closable panels that are manipulated by gestures. An actual product would need a little more; it has to be possible to type in names for sections, probably URLs, and ways to connect to friends. But I think this shows that you can get quite far using the content itself as the interface.
I was looking for more plasticity and viscosity than I could wring out of Flash, hopefully the animation gives some sense of the intent.
[UPDATE] I entered the The Flat Music Player in the MEX Design Competition. If you like it, you can vote for it.
Inspiration
Lumines
Amaztype
last.fm
Hype Machine
Universe by Jonathan Harris
NokiaDesign
absolutely amazing work!
we're building out the grooveshark API and i'd love to get you an early testing account to see if you can put together a masterful piece
-andrew
Posted by: Andrew Wise | May 25, 2008 at 19:45
Okay, so I wrote about 10 mins of comment here, but thanks to the wonderful IE, it all got deleted, so I'm gonna try again, but shorten it abit down - I'm liking the looks. Fancy :) Having troubles however, picturing myself manouvering around on it when trying to hold on to something while on a packed, moving bus, trying to change the song or the album. Also, how would "home made" albums look, who doesnt have album art? And playlists? Personally, 90% of the music I listen to on my iPod is playlists with about 15-40 songs in it. Could there possibly be an option to make playlists while on the run, not sat behind your computer at home? That's the main thing I've missed when it comes to iPods anyway, not being able to easily make a long playlist, when you don't have a pc nearby, without using your entire day on it.
I have close to no idea when it comes to this stuff really, I'm just giving my 2 cents.
GJ tho.
Posted by: Oppvaskbenk | May 25, 2008 at 00:07
I understand for the sake of this post, you had to explain your player idea, but do keep in mind: If you need to explain your interface to users, your device has already failed.
Nevertheless it looks very interesting and I am looking forward to play with it.
Posted by: AJK | May 13, 2008 at 15:22
Steven: You are suggesting the exact opposite of what I'm aiming for: I'm trying to show the big picture on a small screen.
An audio browser is strictly sequential one-at-a-time and probably would have to be linear too. My experience with audio browsers is limited, I've only attempted it for short commands and that worked very well.
But how do you propose an audio browser can be used to select between 2000 songs?? I remain highly skeptical! :-)
Alexander: I've heard both. Some prefer to click, some ask for video. I can easily pull out the stop commands, but it would become a really short video. I'll see what I can do.
Posted by: Morten Hjerde | May 06, 2008 at 19:58
> In addition, music is sound; you can't actually see it or touch it. You have to choose a visual representation
Why? Why do you have to choose a visual representation? Why not snippets of audio? Sure, probably /along with/ the visuals, but its a reasonable bet anyone browsing the music library is willing to put up with noise during it.
We actually designed a couple interfaces (not launched, maybe ever) that had audio browsers. I think it could work, and could be extended up (to album, artist or genre) to snapshots-of-style in the way that album art is extended down...
... which leads me to another annoyance. I think the "abstraction that most people understand and are used to" is lame. I may or may not have seen a physical album anymore. Collections often have pretty uninspired art. And tracks have NONE.
Now, it would be nice if artists would figure this out, and start building track-level art, then software folks start supporting additional metadata, but until then, I am disappointed in album art browsers.
Otherwise nice, btw. I just always focus on the negatives areas of opportunity.
Posted by: Steven Hoober | May 06, 2008 at 17:39
Hi there, this looks quite interesting but the demo flash is a bit confusing... any chance you can make it move automatically without needing to click?
Posted by: Alexander Baxevanis | May 06, 2008 at 10:33