Are Modal Interfaces Really That Bad?
First published Wed Jan 25, 2023
When I say the word “modal” most of you probably think of blocking modal dialog boxes, such as the infamous cookie pop-ups. While these are certainly an example of a modal interface by my definition, I’ll call them “modal dialogs” if I need to discuss them here.
A classic example is vi (and its derivatives). Initially, you are in “normal” mode, where keys are bound to various actions such as moving the cursor, arranging windows, and more. Certain commands switch the mode, for example pressing C will delete the characters on the current line, and put you into insert mode, where the keys now perform different operations. If you press C again, the literal character will be inserted into the document.
Modal interfaces aren’t just keyboard based though - another great example can be found in iPadOS. In the Files app, you can press a file to open it - but if you press “Select” in the toolbar it will enter select mode. Now pressing a file will select it to operate on as a group. The same thing can be done in Photos.
Other examples include modal dialog boxes and even pages of a website!
Mode Error
So if modal interfaces are everywhere, what do people have against them? Mode error describes when a user acts appropriately for the situation they think they are in, but it’s inappropriate for the true situation. I have seen this first hand with iPads, where the user didn’t realise why tapping the photo didn’t open it.
However, mode error can be anywhere from mildly annoying to incredibly dangerous, the most famous example being the plane that crashed into a mountain due to a modal control system. When the pilot needed to input a 3.3-degree descent, the system interpreted this to mean a 3,300-foot-per-minute descent.
The mode cues available to the crew included a somewhat different flight director shape between the two modes, a slight change to the brightness and size of the yellow lubber line on the navigation display, and the position of the decimal point in the vertical speed window of the glareshield controller. However, the Air Inter crew used a head-up display (HUD), so they may not have noticed these cues.
We can reduce the impact of mode error by considering the situation. Thinking of:
- How impactful would an instance of mode error be?
- How easily could it be corrected?
- How likely is it in the first place?
- Is the current mode obvious?
Where mode error would be highly impactful or couldn’t easily be corrected the use of modes should be avoided altogether if possible.
I’m sure almost all of us have been caught out by an unexpected “Do you want to save dialog”, accidentally pressing no and losing days of work. This is a problem that is much better solved by removing the modality entirely (e.g. by autosaving), since making a mode error can be very impactful, and isn’t easily corrected.
Discoverability
Modality in interfaces can both increase and decrease the discoverability of interface features, although it more commonly decreases it. This is because the functions available in different modes aren’t immediately presented to the user, so they might not realise they exist.
The hamburger menu is a perfect example. Studies by the Nielsen Norman Group show “Discoverability is almost cut in half by hiding a website’s main navigation”.
Of course, it’s not possible for every option to be visible, and modality (when well implemented) can often be a great solution. Considering the iPadOS file selection example from earlier, it certainly could be argued that alternatives like gesture-based selection are far worse in most areas - especially discoverability. As long as the mode - and the way out - is clearly communicated, it often works.
A Practical Example
Despite the problems with modal interfaces, they are a very powerful tool for advanced users, allowing complex operations to be performed with minimal effort.
When implementing these interfaces we must carefully consider the downfalls to ensure that we provide powerful options for advanced users without making the learning curve too steep. Let’s look at a few modal features I’d like to see in Jira’s backlog as examples.
For anyone lucky enough to have never come across Jira before, it’s a project management application that has a backlog of tasks that can be assigned to individuals and moved into sprints. The important thing is that there is a backlog page that shows all the tasks that aren’t currently in a sprint. This is where you can create, update and track tasks that need to be worked on.
Jira is complex. It can be configured in all sorts of different ways, but I’m only going to talk about how I have experienced the Jira backlog, and how I would change it without regard for all the other options and features that are already available (but I don’t know exist).
The backlog is organised into a few sections, each containing a list of tickets. Each ticket has a unique ID, priority, title, assignee, and epic (essentially a project). The first sections show the tickets in the active and future sprints (each as a separate section). And the last section is the backlog itself, showing all other tickets.
Clicking on a ticket will normally open it in a pane, side-by-side with the list view of tickets (a feature I’m a big fan of - it’s all-too-easy to shove everything in a modal dialog, but it’s a poor use of modality in many cases). You can hold Ctrl and click individual tickets to select multiple at once, or you can hold Shift to select a continuous range. You can then right-click to perform actions such as moving the tickets into or out of the sprint.
More features could easily be added to this interface without impacting usability with careful use of modality. I would start by replacing the current selection system with a selection mode, triggered by a “Select” button. This would improve discoverability dramatically, as well as make it possible to use without a mouse. I’d also like keyboard shortcuts available, for example pressing s could switch to selection mode, and Esc could return back to normal.
There would also need to be an obvious signal that the mode had changed. I think a floating bar showing the number of selected items would do the trick. It would also provide an easily accessible, visual reminder of the way back to normal mode, with a “Done” button or similar - and buttons for performing an action on all the tickets, such as changing their priority, assignee or epic.
An editing mode would be useful, where you could then directly edit the visible attributes of the ticket. This would be particularly useful for editing several ticket titles since it would remove the need to click into each ticket, and wait for it to load. It doesn’t take long to load, but it adds up if you need to edit 10s or 100s of tickets in a row!
Lastly, I would mention that since these features would increase the chance of making a mistake that’s difficult to correct, there should be a method to undo/redo changes.
I hope this shows the power of highly-modal interfaces and the dangers that always accompany such great power!