Ubuntu's Audio Panel - Who's Fooling Whom?

It's All New Design This Time! No Really!

This is a good exercise that touches on why building a culture is so important. Every time I look at the new Ubuntu music-applet-sound-all-in-one-super panel I struggle against my instinctive reaction.

I see a long standing history of art, design, presence, aesthetics, and emotional experience being neglected. It chases us like a dark spectre of our past.

This isn't new. These are the same old patterns repeated while professing to be different.

The lady doth protest too much.

What the Hell Has Gone Wrong?

I ask you to look at the following samples. Even a passing glance at this should prick the hairs up on your arms with the same morbid reaction to looking at a decaying corpse.

There is nothing to love here. Nothing. And yet our community cheerleaders seem absolutely blind to the inherent kludgey issues.

It is, for all intents and purposes, hideous. And better still, it is hideous wrapped up with some absolutely questionable design.

Chic. Right?

First, we roll out an implementation. Then we retroactively fix it. Right? So the original implementation for the sound panel thingamajig rolls out, and what do you know, there's an issue. To quote Mark Shuttleworth:

Note the tight space for the track data, and hence the ellipsis.

And the result?

Now somewhere, someone might be going "That's hip right? Overlapping text on an image is pretty stylish right?"

It sure can be. Is this it? Unequivocally not. It's a solution to a self made problem.

Let's ask ourselves exactly what this applet is supposed to be doing? I'll guess at:

1. Provide a central interface that allows us to control all of the audio.
2. Provide a region that shows related audio elements. In this case, it is the output of the music player.

I would ask you though, is this about the application or the data it represents? Why? Because in this case, I would make a strong argument that the audience could care less about the application level. In fact, what is important here, and likely why we are including it in a menu, is the music.

What music is it? Is it playing? Can I skip a track? Can I replay a track?

Does the target audience care what the music application is?

In the above 'design', the data has taken a second-rate-low-end-back-seat. We jam ellipsis in that effectively destroy a meaningful representation of the data. If we subscribe to the idea that the data itself is what is important, we have completely destroyed the entire purpose of this design element.

Secondly, if the data is indeed the purpose here, why is the album art given the same back-seat-third-rate-representation? What might be more effective?

I'll try to touch on why I believe these sorts of decisions get made later, because I do believe there is an underlying rationale to the unfortunate choices.

Visual Flow

Graphic layouts will pull eyes along a path. This is a complex series of interactions between colour, value, dimension, and other such areas wrapped up in the audience's experience. With this panel applet, I'd make a strong case that there is a lack of visual flow.

Why?

There are many minor details in this presentation that I would suggest destroy the visual flow and leave a general sense of hodge podge.

1. Inconsistent padding and gutter room. Of note would be the strange padding between the two sound icons on the main volume control and the distinct lack thereof on the timestamps on the progress meter.
2. Visual flow. The weight of the buttons comes to mind. It is one thing to draw attention to something using dimension, but another entirely when the element in question is nothing short of an acrylic Elvis painting on black velvet.
3. Much information. If the intentions were to be a quick panel, the information provided suggests otherwise. If we were to try and figure out why we would need these sorts of things in a quick-to-access menu, we might make some gain. How often is the target audience requiring to choose a playlist? How often is the audience needing to make adjustments to the sound preferences? Are the features presented useful when analyzed in conjunction with the audience that is using it? 

Some wide open questions that would need further thinking and, more importantly, perhaps some research.

Broken Semantics

This one seems glaring. At the top we have two elements that appear to control system level audio. Then, again, way down at the bottom, we have a preferences menu item.

If we use proximity, should we deduce that the sound preferences are a part of the music playing application?

Stuff-it-in-a-Text-Menu(TM)

This trait has been appearing with ever more frequency. It drives me to distraction.

Putting something in a menu is not design. It is lazy.

I'll predicate this with a hypothesis: The tools inform the design as the chisel informs the wood it carves.

If all of the work you do is trapped in a prototyping sketcher, Flash, or Inkscape, or GIMP, what is the inevitable byproduct of that? How do predefined notions of user interface libraries shape a perception of design interfaces? Should they? When all you have is a hammer, everything tends to gets treated like a nail.

Much like the above ellipses 'solution', it is mired in the tools used to arrive at a solution. GIMP is strictly two dimensional. If we start hacking away in GIMP before we have arrived at a vision, our solutions will inevitably be informed by the tool in which we are hacking it out.

At no point did someone stop and develop a vision / solution first and then develop in the direction of that solution. No, instead, the path of least resistance was presented. Solve a problem that we actually created.

Had the starting point been a vision, multiple viable solutions may have presented themselves. Could we animate it? Could we elevate the experience in doing so? What other contemporary examples harness representational data in a way that is unique? Is there anything to be learnt from them?

Many possible paths, and yet we are stuck with the data destroying ellipses.

So how do we present options now?

In addition to being a lazy solution, in this context, one could make a pretty good case that the menus and resultant text heavy presentation are pulling away from the visual flow. There is much to read and, as a result, much visual noise. Indeed, the top most "Mute All" isn't even a menu. Is it a button? Why isn't it a button? What cognitive dissonance is created as we present our audience with entirely different interaction semantics? "Choose Playlist" also has the added triangle that somewhat disturbs the right gutter.

What might a viable solution have been that didn't require a menu? We certainly could have used some sort of iconic button to reduce the visual noise and elevate the flow, but should we stop there? Are there other innovative solutions to be had that we aren't seeing?

The Best Biggest for Last

It is far to easy to simply cringe at those buttons and walk away. But why do some cringe? What is wrong there?

Let me roll through a subjective romp of neural firing:

1. A new styling. There are drop shadow cues on the interface glyphs. This appears new. I was unable to find another sample of this technique anywhere in the system. Currently, with no other examples anywhere in the system, this is an issue as it draws significant attention to itself in terms of the visual flow.
2. Base form does not reflect interaction frequency. There is an awkwardness of the base button forms. The forward and back seem to be getting too much visual say as though their importance is, strictly in terms of visual gravity, as important as actually playing or stopping the music. Compare against the Firefox interface explorations which each have a much more stable set of visual gravity that parallels their frequency. They also exhibit much more craftsmanship than the above buttons.
   
   
   
   
   
   
3. Bevel styling. Tied to (1) above, we have to ask ourselves a question. I am entirely for making changes and adjustments if they have been thought through. This doesn't appear so. If this is indeed a new anchor for a new aesthetic style, should we should be pursing it?  Has there been a visual series of studies or explorations to back up an entirely new aesthetic direction using this as an anchor? Should there have been? How would this element handcuff future elements in terms of design direction and presence?

Not Convinced

All in all, I'm not convinced that we have any more design thinking here than we did four years ago. Personally, this looks like the same patterns repeated.

I am not criticizing Canonical's desire to forge ahead with their plans. In fact, I'd be of the opposite belief. I strongly encourage more Libre companies to push ahead with dramatic and radical changes. We need that sort of stubborn resilience. Unfortunately, in this case, I believe it is seated in some questionable aesthetic, design, and interactive issues.

As a complete outsider, I can see this effort as an extension of the heroic hacking that has taken the Libre movement so far. "Shut up and code!" Indeed, if it weren't for that attitude there would be nothing here to discuss, and for that reason alone it should be applauded.

However, when it comes to raising the bar for interaction paradigms and interfaces, I have to question the validity of not stopping at intermittent design checkpoints and re-evaluating the plan. At which point does the hacker creed of code first create a series of problems that now require hackish solutions, such as the ellipses issue? At which point do we stop and ask ourselves just what the hell we are trying to accomplish?

Was there any thought given to what will dictate whether this has been a success or failure? What are they?

Art, design, presence, aesthetics, experience, and emotion are nebulous creatures. They cannot be tackled with the same tools that has brought our rich culture to where it currently rests. The patterns that may have yielded success cannot be assumed to provide success in other areas. The same logic may not apply. The process may need to be different.

It appears to be the same hacker ethos, the same hacker sensibilities, the same hacker solution process, all over again but now applied to art and design.

It looks like history repeating itself.

A tremendous thank you to all of the people that have spoken up, sent email, instant messaged, and otherwise to voice your caring. We need more people like you to engage the culture. Please do.

A Postscript

Mr. Shuttleworth left a comment here that I believe deserves some attention in the main body of this article. As much as it is easy for idiot monkeys like myself to throw out yet-another-worthless-and-empty opinion, he is the one that has invested a ridiculous amount of his own money into Ubuntu. Without him, all of this discourse is moot.

On key values of the panel indicator:

"provide a home for all the apps influencing "what I'm hearing" with suitable metadata and interaction opportunities"

At some point this will likely need to be regulated, no? What applications? Every single one with an isolated sound control pipe? How massive will that applet get? Should this goal be more restricted in scope? I'd certainly think it should.

"do it stylishly"

And here is a core problem with our current Libre software approach.

What the heck is stylish? Seriously. Please give that some thought. Your economic and ethnographic details are specific to you, and as such, they define the words.

What is worse is that not many see how empty such terms are, and instead, go off rendering or clawing at their own take on 'stylish'. It takes us right to where we are now in Libre design - no focused discourse and a mish-mash of directions.

While it is completely acceptable to work with loose semantics in casual conversations, when we start talking about gettin'-it-done, they fall apart. It is rather like the empty allusions to "elegant" I've been seeing popping up in GNOME circles.

In practical terms, providing a more rounded brief or even mood boards would likely have helped to get more people on the same page, perhaps?

You have specifically called this "classy", and I can't disagree with you. Perhaps to you it is in fact, "classy". This is a difference in fundamental perspectives. And in the end, it is really irrelevant what you and I think. This is about an audience. Who is it? They are the barometer, and in the end, we need to speak their language.

"Let's design a panel applet for music control aimed at 20-30 somethings with North American / Western European music magazine sensibilities." and build up around the other design constraints of being a panel applet. Alas, I didn't try to provide a brief on this.

At any rate, you have your own design team there. Start with them perhaps? Surely a productive and creative explosion could happen if the design goal is framed appropriately?

I've kept mocks out of this discussion. I don't believe they are worthwhile. If there is any value at all in this post, it could rapidly be washed away with a subjective response to a mock. Strictly on aesthetics, I'd suggest this one in a heartbeat over what is currently presented. It is certainly in the vein of the clinical presentation, so personally I'd question the validity of such an approach. That said, the execution is far superior to what is currently in place. The other design concerns still stand.

Thanks again for taking the time to drop by...