Switches in Unity menus

Plans for the next iteration of the network status menu in Unity include the use of switch widgets.

As has been brought up on the unity-design list, their placement on the right is likely to make the issue of diagonal movement often opening adjacent menus worse. Independent of improving the menu mechanics, enabling/disabling could be handled differently in style and placement of the widgets.

I think the adoption of light-switch style widgets in point-and-click interfaces is a mistake. Their look implies a sliding movement, not just a click. They are unclear about whether the labels refer to the current state, or the state to change to (only the use of bright coloration for the On state helps here, but does nothing, if all you see is an Off).

If all you have to communicate is On/Off, what is wrong with checkboxes? They do have unclear target areas (in proper implementations, the label is clickable, too), but are well established and do not suffer from the problems switches have, as listed above.

In the middle: a different take on the switch widget, trying to do without separate label and state-labels. The state that can be switched to is represented by a button, while the current state is flat, as it is not clickable.

Finally an experiment, to see whether a strike-through approach could work for a very compact solution. It is hard to find a balance between legibility of the label and making the stroke clear.

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.

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:

Theming Buttons

It would be great to have a theming engine that exposes basic drawing operations to theme authors. Instead of having a number of options per widget, you would deal with primitives like lines, rectangles and gradient fills.

Let me just say that I know of 2 developers who are on it 🙂

Now if you want to draw a button that way, it appears to be simple enough. Just a usually rounded rectangle with one or several outlines (stroked rectangles), with gradient fills per outline and one for the body. If you assume light straight from top, vertical gradient fills with 4 stops for the outlines are sufficient for a somewhat realistic look.

Not so if you assume lighting from the top left. What I would like to have for such a case is one gradient per outline, with 8 stops placed exactly between the segments (= curves in the corners and straight lines on the sides). Extra points for the ability to add stops between the 8 fixed ones.

In Inkscape, you have to take the rectangles apart to get to that level of control, making it rather laborious and inflexible, as you can’t change the corner radius in a single step anymore, afterwards.

Example construction of a button:

1. Outlines. It would be most comfortable to define the corner radius once, for the outermost rectangle. It should be possible to add up to at least 4 outlines, defaulting to 1 px strokes and inset.
2. For each outline, there should be the option to have 8 gradient stops between the segments. The implementation could treat the segments separately, each with a simple linear gradient, just like I had to construct it in Inkscape here.
3. Just a vertical linear gradient fill for the body.
4. Plus a horizontal fill with 34 % opacity. It should be possible to layer linear and radial fills, with alpha per gradient stop.
5. A shadow. This button doesn’t gain much from it, but it illustrates that drawing and layering rectangles with offsets would be useful.
6. A plain black label.
7. Gradient fill for the label. This can reduce legibility, but if handled with care, it makes button and label appear more like a whole.
8. Luxury feature: sunken or raised (see 9.) look for the label. I used a crude approach with stroked and offset duplicates here, which works only on small scale. A clever implementation would take the angle of the character stroke and the lighting direction into account to render a smooth surrounding.