Real life example: “Sorry not sorry”

I love how much power understanding the fundamentals of UI/UX design can give you to build experiences that really flow smoothly! One of these fundamentals is modes – and how to use them well.

Modes are sometimes necessary, but they can be a risky choice in a user interface. This is true especially if the UI does not make the modes and their states clearly visible.

I’ll first discuss challenges when using modes. Next, I’ll offer some alternatives and finally, offer some quotations from literature to provide deeper understanding.

When designing user interfaces, it is often tempting to leverage modes, or different states in which the user’s input is interpreted differently. While modes can sometimes add value by controlling and guiding input, they often present significant risks that can hinder usability and user experience.

1. Confusion and Errors

Modes can easily lead to confusion if their states are not clearly visible or understandable. For instance, a user may not realize that the system is in a different mode, and consequently, their actions may yield unexpected results. The likelihood of user errors increases in such scenarios, potentially leading to frustration and even abandonment of the software. To avoid these issues, it’s crucial to make the modes and their states highly visible and intuitive.

2. Inconsistency

Inconsistency is another significant risk associated with modal interfaces. Users may be disoriented if the same input yields different outcomes in different modes. They might struggle to remember the functionality of each mode and the available actions therein, creating a steep and unnecessary learning curve.

3. Break in User Flow

Modal dialog boxes that demand immediate attention can be disruptive, breaking the user’s workflow. Imagine being deeply engrossed in a task, only to be jolted out of your focus by a dialog box that requires an immediate response before you can proceed. It’s not just annoying; it also impairs productivity.

4. Increased Cognitive Load

Modal user interfaces place an extra cognitive burden on the users. They need to remember the current mode, its implications, and how it alters the interface’s behavior. This increased cognitive load can make the interface more challenging to learn and use, particularly for novice users.

5. Lack of Transparency

If the system doesn’t clearly communicate the modes and their effects, users may perceive the interface as unpredictable. This lack of transparency can diminish trust in the system and make users feel less in control.

6. Habituation Risks

Modes can interfere with the process of habituation, a process through which users gain expertise with interfaces. If the same gesture or command yields different results in varying modes, it confuses users and hampers their ability to form useful habits.

Alternatives to Modal User Interfaces

To counter these risks, it’s essential to clearly indicate the current mode, ensure modes are simple and intuitive, and provide clear feedback about the effects of user actions.

Moreover, it’s often beneficial to minimize the use of modes where possible, favoring a modeless design that behaves consistently, irrespective of context. Many situations call for alternatives that can provide a smoother, more consistent user experience. Here are a few notable alternatives to consider:

1. Modeless Interfaces

Modeless interfaces are designed to keep the user’s interaction consistent across the interface. All commands or gestures yield the same outcome, no matter where or when they are used. This predictability can significantly reduce confusion and cognitive load, providing a more seamless user experience.

2. Progressive Disclosure

I’ve discussed Progressive Disclosure in more detail in another post. It is a strategy used in UX design where information and options are revealed to the user gradually, as and when they need it. This approach can help to simplify interfaces and reduce cognitive load, while still giving users access to a wide range of functionality when they’re ready for it.

3. Context-Sensitive Interfaces

Context-sensitive interfaces adapt to the current task or context, providing relevant options and information to the user. While this can be considered a form of modality, it differs in that the changes are directly linked to the user’s current task or selection, making them more intuitive and less prone to confusion.

4. Quasimodes

Coined by Jef Raskin in “The Humane Interface”, a quasimode is a temporary mode that is active only while a particular key or button is pressed. This can be seen in the use of the Shift key to type capital letters. Quasimodes reduce the risk of users forgetting which mode they’re in, as the mode ends as soon as the key or button is released.

5. Undo Functions

Providing robust undo functions can help to mitigate the risks associated with modes. If a user makes an error because they didn’t realize they were in a particular mode, being able to easily undo their last action can reduce frustration and help them to recover quickly.

Conclusion

While it’s important to be aware of the risks associated with modal interfaces, it’s equally important to remember that there are many alternatives that can provide a more consistent, intuitive user experience. By carefully considering the needs of your users and the context of your application, you can choose the right strategy for your interface design.

See also: Visual Feedback and How Modes Kill (via Sasha Maximova)

youdontneedamodalwindow.dev

Collected quotations

Usability First Glossary:

modal

a type of interface where the user moves between different states, or modes. In each mode, input from the user is interpreted in a different way. When a user is in a given mode, it’s a good idea to provide an extremely salient indicator of which mode is currently active, e.g. by providing a large icon or shifting the color of the screen.

Modes are usually good to avoid because users are restricted in their available actions and they may be confused that the meaning of their actions changes as they change contexts. However, modes can sometimes be helpful to control and guide input (providing security and preventing accidental errors), and modes may be appropriate when they are short and actively maintained by a user (e.g. the fact that keys refer to capital letters only when the Shift key is held down) and when they follow well-understood conventions, such as painting tools.

Examples of modes include:

– Choosing a painting tool in a paint program. When the Line tool is selected, for instance, all mouse clicks create lines. When a brush tool is selected, the user is in a different mode because all mouse clicks are then interpreted as painting.

– Old text processors, such as ‘vi’ in UNIX, often used a command mode and an edit mode. In a command mode, keystrokes issued commands. In an edit mode, keystrokes were entered into a text document.

– Moving between pages on a website. Each page is a mode which limits the kinds of actions a user can take (where they can go).

– Modal dialog boxes are ones that force a user to respond to them before the user can go back to using other aspects of the application.

The Art of Unix Usability, Chapter 1, Section 3:

Rule of Modelessness: The interface’s response to user actions should be consistent and never depend on hidden state.

This rule could be taken as a consequence of the Rule of Transparency, but violations are so common and such an important cause of interface problems that we have chosen to foreground it by making it a separate rule.

An interface with “modes” responds to the same input gesture in different ways depending either on hidden state not visible to the user, or on where you are within the interface. Since the early days of the Macintosh, which eliminated mode dependencies almost completely, it has been widely understood that modes are a bad idea.

The classic bad example in Unix-land is vi(1), a commonly-used editor in which typed characters are either inserted before the cursor or interpreted as editor commands, depending on whether or not you are in insert mode. This is a well-known cause of confusion to novices, and even experts at this editor occasionally trash portions of their documents through having lost track of what mode they are in or inadvertently switched modes. Modern versions of vi(1), partly mitigate this design flaw by providing a visible mode indicator. We know this is not a complete solution, because even expert users can overlook the state of the mode indicator and find themselves in trouble.

We’ll see in the Wetware chapter that modes interfere with the process of habituation by which users become expert with interfaces; indeed, they turn habituation into a trap. A computing system ideally designed for human use would have one single set of gestures and commands that are unformly applicable and have consistent meanings across its entire scope.

The Art of Unix Usability, Chapter 4, Section 4:

Raskin makes the empirical point that human beings cannot be prevented from forming habits about routine tasks, and elegantly defines good interfaces as those which encourage benevolent habituation. We can go a bit further and observe that “benevolent habituation” — the ability to do the right thing by unconscious or half-conscious reflex — is precisely what we normally mean by expertise.

Thus, our Rule of Modelessness. Users will form gestural habits, and it is a bad thing when gestural habits they form in one part of the system become inappropriate or even destructive in another part. When this leads to problems, the fault lies not with the user’s habits but with system designers’ failure to maintain consistency.

Also some of Nielsen’s heuristics seem relevant:

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

A Dictionary of Computing:

dialog management The methods and procedures governing the way that information is exchanged between the user and the computer system. It involves the consistent formatting of prompts, check boxes, lists of options, sliders, messages, and other constructs. There are modal dialogs, where the user can do nothing else until the action required to satisfy the dialog has been taken; this can be as simple as acknowledging a message. Conversely, a modeless dialog is one that may be returned to after attending to other matters. See also dialog box. (Ed John Daintith and Edmund Wright. Oxford University Press, 2008. Oxford Reference Online. Oxford University Press. Tampere University. Looked up on 14 November 2011)

Originally published in my Moodle usability blog

Leave a comment

Your email address will not be published. Required fields are marked *

Comment moderation is enabled. Your comment may take some time to appear.