unity-design team mailing list archive

[Thorsten Wilms <t_w_@xxxxxxxxxx>]

On Wed, 2010-08-04 at 05:51 +0100, Mark Shuttleworth wrote:
> I blogged about the layout of the track metadata in sound indicator at
> http://www.markshuttleworth.com/archives/446

After getting the recipient and then, in a rush, the thread wrong last
time, I should manage to get it right now :}

http://thorwil.wordpress.com/2010/08/06/ayatana-sound-menu-2/

Content of the blog post:

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.
https://wiki.ubuntu.com/SoundMenu

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 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.

http://thorwil.files.wordpress.com/2010/08/soundmenu_tw_c.png?w=255&h=159

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 location 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.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/