Ayatana Sound Menu 2
2010-08-06 13 Comments
After creating the previous mockups, I have been reminded of the need and value of taking a step back and asking the big questions of design, like: What are we trying to achieve exactly? What is the problem we are trying to solve? Who’s gonna use it in what for a context?
I would think everyone in the design team at Canonical knows about all that, but the specification for the sound menu does not reflect it.
The original reason for the existence of the sound indicator should be quick access to the master volume control. Sound preferences can be accessed by the same means as other system preferences, but it is so closely related to the master volume, that having it right next to it is reasonable. Especially as the speaker icon makes it likely that a user looking for sound related preferences will look there before they would open the System menu.
Having 2 user interfaces for the same things is something to be avoided due to the costs of design, implementation, testing, maintenance, documentation, learning and the decision a user has to make every time. It can be worth it, if there are differing needs that can’t be met as well, otherwise.
I really don’t see how I could define an audience in a useful way here. Everyone who listens to music played back from the same computer they are doing something else with it at the same time doesn’t help much. But the context I just described could.
To me it looks like the motivation for adding playback control and family to the menu is just getting rid of the per-player panel items. It is not a given that playback control in a panel menu is a good idea.
Why would you go through the menu, instead of using the player window? I think if you have your mind primarily on the music, it is a foreground task and the player window should be a much better interface than a menu could ever be. Playback control in the menu should then be about cases where you want to minimize the interruption from another task, where music is a background thing. You might have to listen to something else and want to mute the music, the entire computer, quickly. Or you go for a break and want the playback to stop. Now some will likely mention keyboard buttons for sound control on laptops or on special keyboards. Not everyone has one of those and some might find it more convenient to use the mouse.
Mute and pause all is based on the need to make the computer shut-up quickly. No reason to play on if muted. The user will likely prefer to continue to listen from the position where he muted the system (at least if it is for longer than a few seconds). I’m not quite sure what the label should change to. Unmute all if nothing was playing, Unmute and restart playback or even Unmute and restart playback for Rhythmbox?
The Show items are far from being necessary within my reasoning, as one would hope other means of window management are good enough. But they do show what will be affected by Mute and pause all.