Modes are a frequently misunderstood UI concept: they are often confused with different visual representations of the same data, or features located in a separate part of an application. Even UX practitioners who understand what modes are argue about their appropriate use, with many famous UXers advocating for modeless interfaces. However, modes can be beneficial and helpful, if implemented carefully and thoughtfully.
Definition
Definition: Modes are different interpretations of the user input by the system, depending on the state which is active. Same input, different results.
The most classic example of a mode is the use of the Caps Lock key on a typical keyboard: With the Caps Lock key off, pressing the key for the letter a in a text editor will display lower-case a. With Caps Lock on, the same action will result in an upper-case A. Thus, the Caps Lock key is a mode switcher.
A system is modeless if the same user input will always have the same result, regardless of the system state.
Why Modes Are Useful
Modes become useful when we have too many different options that we want to make available to users, and not enough available types of input to accommodate them all (in a usable, discoverable, and sensible way).
For example, in an image-editing application like Photoshop, it’s useful for the standard mouse click to have many different functions, because being able to point to specific parts of the image is critical for these functions — other input types (like keyboard commands) would not be sensible. Therefore, mode-switching tools (such as the marquee, pen, magic wand, eraser, and all the other toolbar icons) are used to change the result of a left mouse click.
Common Mode Errors and Usability Problems
Modes can cause a range of usability problems, including mode slips (occurring when the user is not aware of the currently active mode) and low discoverability of mode-specific features.
Mode slips happen because the system doesn’t clearly indicate its status to the user, violating the very first of the 10 usability heuristics. Mode errors have been a longstanding problem in our discipline, and, especially in complex systems, can have deadly consequences. Famously, in 1991, a plane crashed into a mountain due to a mode error — in different modes, the same control could be used for either the degree or the speed of descent, but it was not sufficiently clear which mode was currently active. Tragically, the pilot’s intention of a 3.3-degree descent angle was interpreted by the system as a negative vertical descent of 3,300 feet per minute — all because the same control was used to enter these numbers and the dashboard didn’t have a clear mode indicator.
Another, far more common mode error involves email, and is unfortunately still present in every email application I’ve ever encountered: the dreaded Reply All instead of Reply to sender. This mode slip has been around since the invention of email, and yet remains unsolved, despite the fact that it causes embarrassment to users everywhere (and inspires advice articles on how to handle this disastrous slip). If you want to do truly impactful UX work, come up with a design that solves the Reply All error once and for all. You will save literally billions of hours of human lifespan.
Mode slips can be reduced with a few key design considerations:
- Clear visibility of the current active mode. Use strong visual signals such as different backgrounds, emphasis on active-mode indicators (such as high-contrast highlighting or borders), or changing the cursor to indicate which mode is active. Redundancy in indicators is a wise idea: we strongly recommend at least two visual indicators (such as the combination of highlighting on mode-selector controls combined with a cursor change) for which mode is active, to ensure that users are aware of the currently active mode even when they are not fully paying attention.
- Indication of the effects of the mode. Clearly named modes, text labels for mode-selector icons, and tooltips that help establish what happens when that mode is active help users to understand what the mode does.
- Avoiding modes entirely when mode slips can have unsafe outcomes (such as accidental loss of work, deletion of data, embarrassment, or physical-safety consequences). Even if two features are conceptually similar (such as the aforementioned plane’s descent controls), if accidentally mixing them up can cause real harm, go for other design alternatives — like two separate controls.
- Constructive error messages when you can deduce that a certain user action was most likely intended for a different mode than the one that’s currently active. A classic example is password entry while Caps Lock is active: the user may type the password in all-capital letters without realizing it in systems that mask password entry. However, the system knows that upper- and lower-case characters were swapped during text entry and can warn the user to deactivate Caps Lock and try again (or even prevent the error by showing a symbol indicating that the Caps Lock key is active while typing).
- Confirmation dialogs that clearly explain what the computer is about to do, while possibly mentioning the current mode. As always, confirmations should be used sparingly, or they won’t do any good because the user will unthinkingly answer Yes if you ask them to confirm too many times. But confirmation dialogs can be a last chance to save the user in cases where usability testing, analytics, or other data indicate that people are likely to forget what mode they’re in.
An alternative to modes are spring-loaded modes (also known as quasimodes); such modes are active only while a modifier is engaged. For example, holding down the Shift key on a keyboard is the spring-loaded equivalent of the Caps Lock key — the quasimode is only active while the Shift key is being pressed. Quasimodes prevent mode slips, but make it less likely that the users will discover the features associated to these modes. (Also, of course, spring-loaded modes are less efficient in cases where the user wants to remain in the mode for an extended set of actions. THAT SAID, HOW OFTEN DO YOU REALLY WANT TO TYPE AN ENTIRE SENTENCE OF ALL-CAPS TEXT, WHICH IS THE MAIN CASE WHEN CAPS LOCK IS MORE EFFICIENT THAN THE SPRING-LOADED SHIFT KEY.)
Discoverability Problems and Modes
Modes also make it tough for new users to find and remember where certain features or commands are. If a feature or command is only available to users in one mode, the likelihood that a user will encounter it naturally (known as discoverability) or be able to locate it later (known as findability) is much lower than if that feature were always available.
For example, I have a pair of Bluetooth earphones that block out most outside sound when I’m wearing them. They have a useful toggle that allows me to selectively pass through some outside sound for situational awareness when I need it, such as when I am walking down a busy street. I toggle this mode by double-tapping the button on the earphones while I’m listening to music, and it turns it off or on, with a nice short beep as audible feedback.
This ambient-awareness feature also comes in handy when making a phone call, as it reduces the odd feeling of talking but hearing your own voice very muffled. However, when there’s a loud noise around while I’m on a call (I live in NYC, where there are often loud noises around), I’ve often wanted to switch this feature off for a bit. Unfortunately, the double-tap control doesn’t work while you’re in phone call mode – double-tapping the button does nothing in this case except make the audible-feedback beep. As it usually happens when I’m distracted (by focusing my attention on the conversation, not on the UI of the headphones), it took me forever to understand what was happening – I was running into a major findability problem related to my headphones’ mode.
Modals: a Special Case of Modes
Modal windows are a specific type of mode; they present as popups or slide-over panels and they restrict the user’s ability to interact with the content behind the modal, even though that content will remain visible (and typically darkened). Modal windows or dialogs demand that users interact with them before returning to whatever they were doing before. A modal restricts user input to its window until it is dismissed. If the user taps or clicks on the background behind the modal (attempting to interact with the content), the modal can be either dismissed or nothing may happen. Therefore, a modal window moves the interface into a special mode where the same input (clicking on a link in the background) produces different results depending on whether the modal is active.
Importantly, not all popups are modal — if a user can still interact with the content below it, the window is not modal (many GDPR-compliance popups are nonmodal, which at least makes them slightly less annoying). Modals are a heavyweight design choice that are only appropriate when users truly must interact with them in order to continue their current task.
What Modes Aren’t
Not Different Views of the Data Space
Modes are not different ways of looking at the same data. For example, in the Mac Finder, the list view and the icon view take the same data (the files and folders stored on the computer) and present them differently, with the list view showing additional metadata absent in the icon view. However, the same user input has the same effect in both cases: clicking on an object highlights it, double-clicking on it opens it. The same input has the same effect in both cases, so the icon and list views should not be considered different modes, just different views of the data space.
However, even this simple interface also includes access to a mode. Normally, typing a letter in either of the views will highlight other items, based on their names. However, if you click on the text label once, after that item is already selected and highlighted, the name of the item flips into edit mode. At this point, typing will change the name of the item. So, even though the icon and list views themselves are not modes (just different views of the data), they both include access to other modes (navigate and edit, respectively).
Summary
Modes are useful for managing a large number of features that would all benefit from using the same input control. If either the total number of input controls is limited, such as on physical devices with a limited number of buttons, or if several actions are best signaled by the same input (e.g., both scrolling and drawing are well signified by dragging a finger on a touchscreen), using modes will be an appropriate design choice. However, the currently active mode must be clearly indicated, with a strong visual differentiation, and modes should not be used in critical scenarios where mode errors can produce disastrous consequences.
Learn more in our full-day Application Design for Web and Desktop course.
References
The Humane Interface, Jef Raskin, 2000
Asaf Degani. “Modeling Human-Machine Systems: On Modes, Error, and Patterns of Interaction.” Ph.D. Thesis, School of Industrial and Systems Engineering, Georgia Institute of Technology, 1996.
Share this article: