Dash

Scaled Screenshot of Ubuntu 11.10 Unity’s Dash on a neutral background:

Full size

The 8 items in the home screen of Ubuntu Unity’s Dash have been found to be confusing in user testing and will be replaced for the next release.

I think the initial content should be similar to the search results that will be listed once there is text input. Basically the first n matches for a search for everything.

The search should be sub-string based, maybe even fuzzy and even support the categories that can be used in the filter section, to make the most of the user’s input. Especially when searching for files, one might remember a part of a name, not necessarily the beginning. Fuzziness should help with typos or variations in either input or searched content.

Turning the top panel transparent on activating the Dash suggests a connection to the right-side indicator menus, where there is none. It necessitates a variation of the window Close, Minimize and Maximize buttons.

The lense-switching buttons at the bottom seem odd. This placement almost maximizes the distance from the Dash trigger button. It gets ridiculous, if you maximize the Dash, especially on a large display. These buttons determine the entire content, which suggests they should be at the top or maybe on the left side. But what if the layout can be simplified by using the lense buttons both as section headers and pathways to their sections?

Rough, explorative mockups:

Full size

Full size

A second click on the Dash button closes the Dash, making it have the same function as the window Close button in this state. Could this be visualized? An admittedly brutal attempt, just to illustrate the idea:

I wonder if avoiding the potentially disruptive impression of the entire screen being taken over is worth having a Maximize button for the Dash and a layout that increases the need for scrolling (or paging as alternative). The button is yet another detail on the screen and costs the user a decision, not necessarily only once. Without it, the always disabled Minimize button could go, too.

Affects me, too!

Launchpad has a feature where you can specify whether a bug affects you. Different from me too comments, this is useful in producing a number and not clogging up the comment thread.

But it’s at the top, between lots of stuff, while the comment box is all the way down. Me too style comments do happen. Maybe their number could be reduced by having the affects me feature close to the comment box. A label that emphasizes that comments should add information, instead of the current Add comment, could also help:

Ayatana Sound Menu 2

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.

Ayatana Sound Menu

2 Mockups in reaction to Mark’s post, this other mockup and also Troy’s interesting but wordy article.

I think the prioritization based on assumed frequency of use should be as follows:

• Mute All
• Volume
• Play/Pause
• Skip Forward
• Preferences
• Set Position (via slider)
• Skip Backward

I left out Choose Playlist, because bringing up the player window could well be  more convenient than using a sub-menu and the menu is rather crowded. I’m least sure about Set Position, it’s another candidate to be dropped.

There are 3 scopes in the menu:

• global,
• per player and
• per track.

While Preferences is of low priority (one could argue for leaving it out entirely), placing it at the bottom while all other global elements are at the top is problematic. So I chose top right to have one nice block with global controls.

The transport controls belong to the player, not the track, since playing on or Skip Forward will lead to the next track. This is a reason against putting them to the side of the track/album art. Note that my Skip buttons are in reverse of the usual order. That’s good regarding prioritization, but bad regarding breaking common patterns.

Placing track attributes to the right of the track/album art could look better, but the the menu should be much wider to avoid ellipsis or wrapping, then. Given how attention grabbing pictures can be, it should be considered to leave the art out, or to show it in something to a sub-menu.

There should be a clear differentiation between controls to interact with and static elements. One option would be a different background like above, another a different color like below.

This volume slider design allows to use the full width as active area for best control. There would be countless styling options, of course, this is just a rough one. I much prefer sliders that allow dragging on the entire area, instead of making you aim at some tiny button. Middle-click could be use to make the value jump to the pointer position.

Inkscape Fill and Stroke Panel

Inkscape’s Fill and Stroke panel is rather large and wider than the Layer and Align and Distribute panels I use often, causing the whole sidebar to take even more space away from the canvas area.

Screenshots of Inkscape 0.48pre1 (edited to remove rendering glitches on the color sliders):

So I wondered how this panel could be made more compact. Rough mockup:

The fill-rule toggle buttons in the top right of the original are mutually exclusive, so I reduced them to one icon for toggling here. Never once had a use for them. The legend for the color sliders doubles as combobox. For the Wheel mode, there would have to be either vertical text or an icon. Sliders with labels right on them save space, but the contrast has to handled with care, of course. For whatever reason, Inkscape uses two visual styles of comboxes, I used only one in the mockups.

Integrated gradient editing:

Window Control Marking Menu

While it’s actually about a marking menu implementation in Flash, this gives a good introduction: Extremely Efficient Menu Selection: Marking Menus for the Flash Platform.

Marking menus vs linear menus on Youtube.

Could marking menus be used for window management?

There could be a menu button, but that would often put the menu in a corner so that fewer directions could be used efficiently. The menu would have to be designed for either the right or left edge of the screen.

Requiring a right click makes the functionality hard to discover, but one could provide a hint attached to the mouse pointer.

The menu appears on pressing the right mouse button. The center is neutral and allows to cancel the operation by simply releasing the mouse button again. Selection of options happens based on direction alone, distance beyond the initial threshold plays no role. This allows fast gestures. It might be worth consideration to place Maximize in the center, as it is a rather safe command, but one might want to offer a different way to cancel the operation, then.

During menu-use, the pointer disappears and a line is shown to indicate the chosen direction / the gesture being drawn. Sub-menus are reached by changing direction or pausing, although there are variations of marking menus where the mouse button has to be released.

The current workspace can’t be selected. Sticky (always on visible workspace) is presented as exclusive option instead of a separate state as in the current linear menu.

Marking menus can be combined with other elements, here an alternative for workspace selection. Sticky is presented as a kind of parenthesis.