Controls, menus and messages¶

Exercise controls-menus-messages-annex.pdf · PDF

A settings screen offers Theme, with two checkboxes: Light and Dark. Both are ticked. So which theme is the app in right now? Further down, Text size is a text box. You type abc. Then 900. It takes both.

Whose mistake is abc? The user's? No. The designer gave them a tool that allows it. A control is a promise about which answers are possible, and the wrong control makes promises the app cannot keep. This page gives you the pieces and the reasons: where a command goes, which control fits a question, and how an app should talk.

The workshop¶

You do not drive a screw with a hammer. Controls are tools, and for this whole page your app is a workshop. Its tools live in three places:

A menu bar is the row of menus that holds every command of a desktop app. A toolbar is a strip of buttons for the most frequent commands. A context menu is the short list that opens on the thing you right-clicked.

The menu bar: the same drawers everywhere¶

Open any desktop app, such as LibreOffice Writer, and read the top row: File, Edit, View ... Help. You have seen it a thousand times, which is the point: this is the consistency of heuristic 4, and the recognition that the 1987 Apple book asked for. Each drawer has a meaning, so a command's place follows from a rule:

So Delete note goes in Edit, because it changes the selected thing, not the document as a whole. Dark mode goes in View, because the notes stay the same. If you can defend a place with a rule, it is a good place. "It felt right" is not a rule.

Open a menu and you will see three conventions:

• Groups and separators. Undo and Redo together, a thin line, then Cut, Copy, Paste. That line is proximity inside a menu.
• The ellipsis. "Save As..." has three dots and "Save" has none. An ellipsis means I will ask you something before I act.
• The shortcut on the right. Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V. Larry Tesler and Tim Mott invented cut, copy and paste at Xerox PARC in the mid-1970s, and you still use the same commands in the same menu.

The pegboard and the tool belt¶

A toolbar holds few tools. Keep it to about four. With 30 it is not a pegboard any more: it is a wall you have to search.

A context menu holds what applies to this object, right now: for a note, Share..., Duplicate, Rename... and Delete note.

Each platform, its own drawers¶

These are the highway codes again. On the desktop, macOS puts the menu bar at the top of the screen, and Windows and Linux put it in the window. A phone has no menu bar: instead there is a tab bar at the bottom, with 3 to 5 destinations, and a "More" menu for the rest. Right-click becomes a long press.

Two questions choose the control¶

Every time you need input from a person, ask two things: how many answers may the user give, and out of how many options?

flowchart TB
    Q1{"<b>How many answers?</b>"}
    Q1 -->|"any number"| CB["<b>Checkboxes</b>"]
    Q1 -->|"on or off,<br>applied at once"| SW["<b>Switch</b>"]
    Q1 -->|"one"| Q2{"<b>Out of how<br>many options?</b>"}
    Q2 -->|"2 to 5"| R["<b>Radio buttons</b> or<br><b>segmented control</b>"]
    Q2 -->|"6 or more"| D["<b>Dropdown</b>"]
    Q2 -->|"a number<br>with limits"| ST["<b>Stepper</b> or <b>slider</b>"]
    Q2 -->|"cannot be listed"| TF["<b>Text field</b>"]

Go back to the screen from the start. Theme is one of three, so checkboxes were wrong. Text size is a number with limits, so abc should have been impossible.

Three refinements for the choices people get wrong:

• Switch or checkbox? A switch acts the moment you touch it, like a light switch. A checkbox waits for a Save or Send button, like a paper form. A switch with a Save button under it is a checkbox in disguise.
• Dropdown or visible options? A dropdown saves space, but it costs a click and hides the options. Under six, and if there is room, show them.
• Stepper or slider? A slider that shows no value cannot tell 16 from 17. If the exact number matters, use a stepper, which shows it.

The dangerous button¶

A destructive action never sits next to the main one and never looks like it. Move it away as well as recolouring it. If it cannot be undone, it asks first, so its label ends in dots: Delete all notes...

Do you remember the Undo in heuristic 3? If an action can be undone, it does not need to ask. Delete note can act at once and offer Undo, so it has no dots.

Four voices¶

Your app also has to talk. It has four voices, from a whisper to a hand on your shoulder.

Use the quietest voice that works.

Material Design calls the toast a snackbar. You will meet both words.

Writing a message people can use¶

Heuristic 9 gave you the anatomy of an error message. It says what happened, why, and what to do now:

And three rules of length and tone:

• Short. A toast is read in one glance: two or three words. Longer is not more polite. Nobody reads it, so short and useful is polite.
• Human. No codes, no "null", no "op".
• Verbs on buttons. "Delete 4 notes" and "Cancel", never "Yes" and "No". People read the button, not the question, and "Delete 4 notes" is clear on its own.

Key takeaways¶

• The menu bar holds every command in a familiar order (File, Edit, View ... Help). The toolbar and context menu only repeat it.
• Separators group commands, an ellipsis means "I will ask first", and shortcuts sit on the right. On a phone, a tab bar of 3 to 5 destinations replaces the menu bar.
• To choose a control, ask: how many answers, out of how many options? Replacing a text field removes whole sets of errors.
• A switch acts at once. A checkbox waits for Save. A destructive button moves away from the main action, and asks first if it cannot be undone.
• An app has four voices: inline, toast, banner and dialog. Use the quietest that works.
• A good error says what happened, why and what to do now, with verbs on the buttons.

Quick check¶

You have the pieces, and you know where each one goes. Now you stop fixing other people's screens and start your own app: Wireframes, prototypes and usability tests.