GNOME Bugzilla – Bug 634329
Sound menu uses atypical terminology
Last modified: 2010-11-19 22:15:28 UTC
The sound menu uses the terms 'Output' and 'Input' and each has a light switch next to them. 'Output' and 'Input' are technical words which do not correspond to everyday language. Alternative terms could be 'Volume' for output (technically wrong, but will be understood by users) and 'Microphone' for input. The use of light switches to toggle output and input also implies atypical language, namely 'On' and 'Off'. A toggle button labelled 'Mute' would be more appropriate.
Created attachment 174202 [details] [review] Update volume indicator labels It turns out 'Output' and 'Input' are too technical for the novice user. Use 'Volume' and 'Microphone' instead. Also, it is already indicated by the switch when volumes are off, no need to say ": Muted".
(In reply to comment #1) > Also, it is already indicated by the switch when volumes are off, > no need to say ": Muted". Let me argue the case for using mute, because I do think it would be better: * A switch does not have the same meaning as 'mute'. 'Mute' does not just mean turn off. It communicates something more: that this is a temporary state, an interruption. This additional meaning will be instructive to users. * The meanings of the word mute would enable this control to other actions, like pausing music and video playback. These would not fit with the semantics of a switch. * 'Mute' is part of users' natural lexicon regarding sound. Where possible, we should use domain-specific language. [1] [1] http://library.gnome.org/devel/hig-book/stable/principles-match.html.en
Created attachment 174337 [details] [review] Update volume indicator labels It turns out 'Output' and 'Input' are too technical for the novice user. Use 'Volume' and 'Microphone' instead.
Created attachment 174338 [details] [review] Update volume indicator labels It turns out 'Output' and 'Input' are too technical for the novice user. Use 'Volume' and 'Microphone' instead.
Created attachment 174599 [details] Wireframe mockup of the sound menu I'm not sure that we should make one of these changes without the other. 'Volume: On / Off' doesn't make much sense - you can't 'turn off the volume', but you can 'mute the volume'. (You can try it: Google 'mute volume' and then Google '"turn off" volume'.) I've attached a wireframe just to make it clear what I'm proposing.
I'm not sure about this. Two state buttons are not otherwise used in the shell, and to me it would make it harder to discover if volume is muted or not (especially because they're not the usual Clearlooks style users know). Also, the slider cannot be marked "disabled" because it is not: dragging it up, or scrolling, will reenable volume.
Remove the button altogether and do something like: Volume [button] [============X===] And make the button mute, and show the volume bar all the way down. I don't think we should show a state at all, and the old status icon didn't really know about mute. Mute was "0 volume" as far as it was concerned. If people want more fine-grained mute, they can use the sound preferences.
Created attachment 174606 [details] Reworked mockup I've discussed this further with Jimmac and Andreas on IRC. Their view, which I agree with, is that separate mute controls should be removed altogether. Some points in favour of this move: * User testing has shown that people tend to use the volume slider to mute even when a mute button is present. * There is no reason why you couldn't do additional actions (like pausing playback) on volume = 0 instead of with a mute state. * There is an interaction bug wrt the menu and muting: if a user unmutes, they will often want to change the volume straight afterwards. The problem is that the menu closes on the unmute action, so they have to scrabble (particularly if the volume is up loud!) back to the menu again. Unmuting via the slider avoids this by making the setting of the volume part of the unmute action.
Created attachment 174686 [details] [review] Sound Menu: only show the slider Reimplement UI without any indication of percentage or mutedness, and whitout switches. The only interaction point is slider, but it still supports mute changing for applications that track it, and will react appropriately to external changes. https://bugzilla.gnome.org/show_bug.cgi?id=634982
Comment on attachment 174686 [details] [review] Sound Menu: only show the slider >https://bugzilla.gnome.org/show_bug.cgi?id=634982 > >https://bugzilla.gnome.org/show_bug.cgi?id=634329 just mark one of the two bugs a duplicate of the other, and then only list the non-duplicate one here. >+ this._outputSubtitle = new PopupMenu.PopupMenuItem(_("Volume")); >+ this._outputSubtitle.actor.reactive = false; >+ this._outputSubtitle.actor.can_focus = false; it would be cleaner to make the PopupMenuItem constructor accept params and pass them on to PopupBaseMenuItem, so you could just do this._outputSubtitle = new PopupMenu.PopupMenuItem(_("Volume"), { reactive: false }); also, it's not a "sub"-title. Call it outputTitle. Likewise for input.
*** Bug 634982 has been marked as a duplicate of this bug. ***
Created attachment 174890 [details] [review] Sound Menu: only show the slider Reimplement UI without any indication of percentage or mutedness, and whitout switches. The only interaction point is slider, but it still supports mute changing for applications that track it, and will react appropriately to external changes.
Pushed. Designers please reopen if this is not what you meant.