Now that we have defined what/whose problem we’re trying to solve, and debated about the implementation details, it would be worth asking why a graphical XMMS2 client would be a good fit.

After all, we have a brand new korving CLI (nycli), isn’t that enough? In a sense it is, but it fills a different niche. GUI applications are good at things that CLI applications aren’t, and vice-versa. So the goal is to exploit the specific advantages of graphical music players.

For instance, even the most hardcore fans of the command-line will admit that the following tasks are easier with a graphical player:

• Edit a playlist, using mouse selection and drag-and-drop.
• Browse albums by cover.
• Organize music manually into playlists or using dynamic collections.

But these are just simple examples that are now expected of any standard graphical music player.

Can’t we get something more exciting?

As Obama taught us, “yes, we can!”

Three main aspects usually poorly supported and under-exploited in music players are powerful tools to:

• Browse
• Organize
• Explore/discover

Browsing

Graphical applications provide a rich visual experience that can be exploited to navigate large amounts of information, in particular using the spatial aspect and our ability to recognize images quickly.

Typically, users have become familiar with widgets like iTunes Cover Flow, which exploit the visual clue of album covers to quickly flick through releases. Several XMMS2 developers have expressed their interest in a more “album-centric” client, which essentially means supporting album entities in the interface, as opposed to just tracks.

An extra step would be to also promote the artists, and possibly other properties (e.g. genre, year, label), as premium entities. So rather than “album-centric”, the client would be “entity-centric” (in the sense that most existing music players are track-centric). Each entity could have its own fullscreen pane (or “page”), with corresponding information (more below) and links to browse the related entities. This would lead to a web-like navigation, where for instance each artist would get a page with the list of his releases (plus a photo, bio, etc), and clicking on a release would bring the page for that release, with the list of tracks.

However, browsing doesn’t have to follow a rigid path: we’re used to browsing inside categories (e.g. releases) alphabetically, and to jump between categories using the explicit hierarchy from the data (e.g. from an artist to its releases to their tracks), but that’s just one of many possibilities.

The user may want to browse a subset of her media library, for instance filtering by a range of release years and genre (e.g. “70’s rock”), or a custom collection she assembled herself. She may want to follow connections from an artist page to pages of “related artists”, to use tags to jump from a track to a list of albums, to find all the music she added the same week as a given release.

It’s time to think beyond the simple local data and harvest The Cloud to enrich the user experience; services like Last.Fm already provide an API to retrieve Similar Artists, social Tags, etc. And with our Collections API, it’s just a whole lot of power waiting to be unleashed!

Organizing

While browsing is the passive process of visiting what’s there, organizing is the active process of applying your own order on the content.

Playlists are the most common organizational tool, usually directly tied to playback, and the usual editing features should naturally be supported (insert, enqueue, move, remove). Special playlist behavior (queue, party shuffle, random, etc) should also be configurable easily. (Note: fancy playlist formatting is outside the scope of this post.)

The second main organizational tool is collections. A collection is akin to a “themed-bucket”, i.e. a set of music that the user has put together in order to reuse it later. But rather than focusing on the underlying nature of a collection (a graph of operators), the interface should emphasize the organic process of someone creating a custom group of music. Any search, or essentially any “view” of music, should be recordable as a collection; and it should always be possible to refine or further filter a collection, as well as add custom content to it. It should be as easy as typing a search or dropping content in a folder, rather than as complex as setting up a network of mail filters.

Finally, tags should be at the user’s disposal for applying a minimal description to content. There is a subtle difference between tags and collections (and how they play together), and I don’t have much in mind regarding tags so far, but I think they will definitely be a powerful addition.

Exploring/Discovering

In the browsing section above, different new ways to navigate one’s music have been evoked. The next logical step after that, however, is to help the user discover new music he doesn’t yet know about, by giving pointers to music and information outside of his media library.

Many online services offer to make you discover new music, but this feature remains unusual in desktop music players, except Spotify (with a tab of related artists) and recent versions of Banshee (with custom recommendations, perhaps based off Last.Fm?).

Those illustrate two interesting directions.

First, providing pointers from a certain point in the user’s media library to complementary information and new music. For instance, on an artist pane, show the list of all its releases, including those missing from the user’s music files, show related artists, both present in the user’s media library or not, show the artist’s news feed, etc. Or show reviews for albums, or lyrics for individual tracks. Basically, gather information from external sources about the user’s music, and invite him to discover new music as well.

The second direction is more general: given the user’s music profile and playback history, suggest new artists or genres he might be interested in exploring. For instance, using all the artists present in the media library, infer what will be the user’s next favorite band. Or suggest popular releases, based on the kind of music recently played. Here, suggestions are made spontaneously, based on the behavior of the user.

The goal of these two features is to get the user excited about not just his current music files, but the whole portion of the music world they span. They should invite the user to be curious about his or new music.

One place to put these suggestions on would be the music player’s “home screen”. Without entering into too much details yet, the player could provide the user with ideas on what he might want to listen, based on what he played recently, his collections, tags, etc. Rather than a long table of “all the tracks”, the entry screen could be a richer, custom view of different ways he could start playing his music.

Obviously, this post hinted at a lot of potentially complex features, which would take a lot of time and effort to all put together perfectly. The main point, however, was to point at various ways of making the experience of this music player a little special. In particular, most existing players are still nothing more than a fancy dressing over music tracks (i.e. files).

But to make a really rich and complete experience, I believe that one must embrace music as a culture; promoting entities (e.g. artists, genre, releases, etc) to key navigation points and tying it to all the information available on the web would be a good start in that direction.

Darth Cee-Lo, by Ethan Hein