Modality Is the One UX Concept That Most Designers Don’t Fully Understand

Modality Is the One UX Concept That Most Designers Don’t Fully Understand

Many — mostly young — designers create digital products based on their gut feeling. Although this may work in many cases, there are proven common standards that help you to logically construct well-founded UI solutions instead of relying on your gut feeling.

In this article, we are going to explore the common standard of modality in user interfaces, discuss the reason why there are only two fundamental types of screens and analyze how apps and websites fail at converting information architectures and user flows into intuitive user interfaces. Oh — and we are going to talk about kittens.

Let’s start the exploration with a bold claim:

There Are Only Two Types of Screens

  1. Modal Screens
  2. Non-Modal Screens

That is it — Let me explain. (Almost) Every imaginable viewport falls into one of those two categories. In order to understand what differentiates a Modal Screen from a Non-Modal Screen, we first have to define a Modal Screen.

What Is a “Modal Screen” ?

Modal Screens can be found in different shapes and sizes:

  • Fullscreen Modal Views (1)
  • Popups (2)
  • Pop-Overs (3)
  • Lightboxes (4)
  • Alerts/Notifications
  • (Multi-step) Dialogs

Both Modal Screens and Non-Modal Screens are child views, meaning they are subordinate to the app’s main window. But there is one important difference:

Most Modal Screens — especially on desktop applications — can be easily identified, because they visually overlay the main window: This is true for popups that fade out the main window in the background, popover menus and popover dialogs, lightboxes, alerts, …

However, screen estate on mobile devices is limited, which is why many modal screens on mobile devices take up the entire screen. They no longer keep the underlying main window visible and therefore make it harder to distinguish them from Non-Modal Screens:

The main difference lies in the way you can interact with each screen. While a Non-Modal Screen allows users to simply go back to the parent screen, the Modal Screen requires users to complete an action before returning to the main window (“save” in our example) or cancel the current action.

The most distinct visual indicator for Non-Modal Screens is the visibility of the navigation (a tab bar in our example). Non-Modal Screens allow users to jump back and forth at the primary navigation level even if they happen to be on a subpage. On the other hand, a Modal Screen requires users to close the window before being able to use the primary navigation again (“Save” or “Cancel” in our example). This distinction is what most apps are failing at and one of the reasons why I wrote the article “Tab Bars are the new Hamburger Menus”:

Why Should Modality Be Used?

Modal Screens solve a simple problem: Users are easily distracted, so you have to grab their full attention sometimes (source). A Modal Screen does exactly that: it requires people to focus on a single task before continuing.

When Should Modality Be Used?

Now that we know what a Modal Screen looks like, how it compares to a Non-Modal Screen and what its purpose is, we have to ask ourselves “What kind of situation should we use it in?”

I promised you kittens, so here we go: Let’s imagine we are creating an ingenious and innovative Silicon Valley app: “purrrfect” — a kitten database that allows users to upload, view and comment on cute cat GIFs. Brilliant concept.

A (simplified) user flow of our app might look like this: The user opens the app, he enters one of several available tabs (our kitten database), clicks on one of the kittens (enters detailed single kitten view) and then clicks on the comment section (enters comment section).

In addition, the user can perform supplementary actions at each stage. For example, he can add another kitten to the database in the kitten database screen. Or he can edit data in the kitten detail screen. Good stuff.

Now, which of these screens is modal and which is not? The classification is anything but simple — this is my personal rule of thumb:

A “self-contained process” is every action that has a clear start- and endpoint to it. For the limited time frame of this action, it takes the user out of the general user flow, lets him focus on the action and then takes him back to where he started.

Also Read:

Lockdown 5.0 : three phases to 'unlock' the country

Post Comments(0)

Leave a reply