Wasted place all over the place, too small text placed within too large widgets, inconsistent style, a festival of duplicated information in the playlist view on the right, the ever-dreaded tabs on the left (yes, tabs are usually evil).

Seriously.

Someone has to wake up and fix this but hey, guess what, it’s just a mockup, so they might!

What is more interesting, however, is the shift of focus in the way users are supposed to interact with the player. The developers make it clear that they want to make the “context browser” central, and reduce the importance of the playlist. I’ve been advocating something similar since the early days of Collections (already in my initial manifesto), but I find it bold of them to push this change in an already widely popular program.

Users will be shocked and disturbed, so it better be polished enough to prove how superior this approach is. In particular, the interaction between the context view and the playlist needs careful attention, and the edition of playlists should be facilitated.

In the current mockup, I find it worrying that they don’t seem to find it useful to give easy access to multiple saved playlists. Right now, you need to go from the playlist to the other side of the screen, and hunt for the (two?) playlist tabs (which seems to require cocking one’s head sideways by 90° unless you’re Mad-eye Moody). I certainly hope they will optimize the interaction flow as much as the interface.

Whether the idea and its implementation are good isn’t even as relevant as the observation that you cannot satisfy all users with a single program. User interaction and preferences is a multi-dimensional space, and you can never span it in every dimension.

An interface is a compromise. Usability defines how large the compromise is, and how much the application satisfies the goals it aims for, in the user’s experience.

I believe that this is one of the qualities of XMMS2, which solves the technical problems for the end-developers and lets them focus on providing a wide variety of complementary interfaces, all backed by the same daemon. Of course, this modularity is a performance tradeoff, and the daemon isn’t optimized for every possible use. Still, it calls for new experiments and ideas. And with the approaching end of the Summer of Code, new possibilities (GenIPC, service clients, visualization, test framework) are at the door!