When crafting mobile app interfaces, designers continually encounter the necessity to make decisions. There are numerous ways to convey the same information to users. At times, designers find it challenging to determine which element is most fitting for accomplishing their goals. For instance, how should the information be presented within a given scenario? Should it open on a new screen, a sheet or dialog, or maybe a snackbar? If a designer goes with a sheet, they face a new question — which closing mechanism to choose, a close button or a swipe gesture?

This article is a collaborative effort by Ksenia Toloknova and Igor Dolgov. We are working on creating guidelines and patterns for the Alfa Business Bank application. In this article, we will attempt to discover answers to these questions and identify established patterns in the market.

Clarifying some definitions

Let’s start by clarifying some definitions. It’s important to note that terminology in interface design is complex and not always well-standardized.

Dialog (alert, action sheet, pop-up)

This element is known by various names depending on the operating system. In iOS it’s referred to as alert for warnings and action sheets when you present a choice of 2 or more actions. In Android, it’s simply called dialog for all these cases. You can also come across a wide variety of custom dialogs.

A dialog is a modal window that appears on top of the page’s content. It can contain important warnings or request user confirmation for a particular action. Such elements are often referred to as pop-ups. The concept of pop-ups originated on the web and has evolved into a wide range of variations.

Sheet (bottom sheet)

This element also goes by different names depending on the operating system: bottom sheet (Android) or sheet (iOS). However, we’ll refer to it simply as a sheet.

According to the definition from the NNgroup website, a sheet is an overlay anchored to the bottom edge of a mobile device’s screen. It is used to display additional details or actions.

Snackbar and Toast

Both a snackbar and a toast are types of pop-up messages featuring short text that relates to a user’s action. These messages are displayed briefly and disappear automatically. According to Material Design Guidelines, it is suggested to display toasts at the top and snack bars at the bottom of the screen. Nevertheless, in practice, this is not always followed, but we will delve into this further.

We’ve encountered an interesting phenomenon — in Human Design, such an element is not described, yet it is widely used. It appears that systems cross-pollinate, with elements from one system partly influencing another.

In addition to the elements described above, there are a few more options for addressing similar tasks, but they are not utilized in our application and therefore are not covered in this article.

Diving into the details

Now that we’ve clarified what’s what, let’s dive into the details.

Sheet (botton sheet)

Let’s start with the most intriguing part. The sheet is commonly used in applications on both platforms (iOS and Android) because it can accommodate a substantial amount of content.

There’s no universal pattern for how a sheet should behave correctly. Therefore, let’s explore the available options below.

A sheet can be:

• Modal or non-modal
• It can occupy the entire screen or a portion of it
• It can have fixed or dynamic height

Non-full-screen modal sheet

This type is used to display a small amount of information, such as showing additional details or offering extra actions.

Typically, this sheet is closed by tapping on the overlay area (the darkened area) or swiping it down, and it does not respond to a swipe upward. However, there are exceptions. In Instagram, for instance, we observed an unusual sheet for displaying comments — the content within the sheet can be scrolled, but if you pull the sheet upwards, it expands to occupy the entire screen.

Full-screen sheet

This type of sheet is used when there’s a substantial amount of information to display, and it’s essential to utilize the entire screen height.

Closing such a sheet can also be done by swiping it downward, but this mechanism may not always be evident to users. We’ll touch on this issue a bit later.

Non-modal sheet

Non-modal sheets are used in complex interfaces when it’s necessary to directly impact on the current task in the parent screen. For instance, in Notes, a non-modal sheet is used for note editing, and in Google Maps, it ensures that the map and object details remain connected.

Sometimes, the non-modal version of a sheet can take on rather intriguing forms. In a podcast app, it functions as a mini-player. When tapped, it expands into a full-fledged sheet.

Swiper, X, or “Close” button 🙆‍♂️

An attentive reader might have noticed some differences in our examples — some sheets have an X, some have a swiper, some feature a “close” button, and at times, you might even find several of these elements together. The reason is that, as of 2023, there’s still no clear-cut guideline. The Human Interface might suggest using everything, and Material Design might not suggest anything at all.

Even in major applications, there’s a wide variety of approaches (sometimes within the same application).

Lately, a new player has emerged — the arrow swiper. This addition is in response to the fact that users don’t always realize they can pull the sheet upward. You won’t find such an arrow in the guidelines, but it has already won the hearts of many designers. For example, WhatsApp updated its call interface, adding such a swiper to make it clear that the sheet can be expanded.

For our guidelines, we’ve established the following rules:

The X is used for full-screen sheets. Swiping down in such sheets also works, but the action can be challenging or less obvious.

Regular swiper — for non-full-screen sheets, we display only the swiper. In this case, the darkened area of the screen serves as the “close” button for users.

Arrow swiper is used for non-full-screen sheets that can expand. It makes it much more evident to users that the sheet can be expanded.

We recommend using multiple elements simultaneously in cases where they serve different functions. For example, the X handles the complete closure of the sheet, while the swiper controls its size.

When to choose a sheet?

Sheets are suitable when you need to help the user complete a clear, specific task or get background information without losing previous context.

Actions within the sheet should be straightforward and brief. It’s worth noting that, in some applications, sheets are used for complex scenarios, but this rarely leads to a positive outcome.

Dialog

To grasp the essence of a dialog, let’s draw a parallel to a real conversation. A dialog is like a conversation between two individuals. In user interfaces, a dialog is a “conversation” between the system and the user.

When a dialog appears, it effectively blocks all application functions and remains on the screen until other necessary actions are completed. However, in many applications, this element is often repurposed to convey reference and promotional information. This practice has its origins in web design, where pop-ups are commonly employed.

For example, in the Yahoo Finance application, a dialog is used instead of a welcome message. While there might be valid reasons for this choice, it’s generally more suitable to employ different tools for greetings and onboarding. In the Instagram app, we see an example of a native dialog in the classical sense, in line with the guidelines.

Recommendations

Use a dialog when further progression in the scenario is impossible without the user’s response.

In Material Design and Human Design guidelines, it’s emphasized that this component should only be used for information of high importance since it blocks the content on the page.

We recommend using it when you need to:

- Confirm an action related to the user’s finances or personal information.

- Delete something important, especially if it’s irreversible.

- Exit a scenario without saving, resulting in the loss of progress.

Dialogs are not recommended for displaying reference information. People do not like interruptions in their actions for a warning that only serves informational purposes and does not require any immediate action.

Snackbar and toast

To be honest, it was quite challenging for us to grasp the difference between a toast and a snackbar. They appear very similar visually, and in some design systems, these terms are even conflated. For instance, in the Adobe Spectrum, both of these entities are merged into the concept of a Toast.

A bit of technical insight:

Toast is an Android UI component that has been around since API 1. It is primarily used for informational messages. Unlike a snackbar, it’s inflexible and cannot be customized; you can only set its display duration. A toast cannot be dismissed by user action (you can’t swipe to close it); it will disappear on its own after the specified display time.

Example: You have received a new email.

Snackbar exists in the Material library and has been available since API 23. It came later than the toast and is much more versatile. Users can interact with a snackbar; for instance, they can swipe it away or tap on a button (Action) to navigate to another screen.

Example: You have received a new email → View.

Material Design guidelines recommend placing both snackbar and toast at the bottom of the screen, although this isn’t always the best choice. In our view, to determine the ideal placement for this element, it’s essential to consider the context.

Let’s look at some examples. In the PayPal application, the snackbar appears at the top in an area where no critical information is present. In the Instagram app, the snackbar is displayed directly on the photo because the user’s attention is focused there. In the Google Fit app, the notification about an update fits best at the bottom of the screen.

When to choose a toast or snackbar

Toasts and snackbars are excellent choices for cases where you need to provide immediate feedback to the user for their actions (e.g., button clicks) without disrupting the scenario flow, and when the action’s outcome doesn’t require additional explanations.

We recommend using it when you need to:

- When a user has completed an action, such as sending a message, and you need feedback from the application.

- When you need to capture a user’s attention without pulling them out of the current context.

In our own application, we prefer snackbars as they are more flexible. They can resemble toasts and appear on any part of the screen. Additionally, they can include extra information or actions, such as countdown timers and cancel buttons.

Conclusion

When designing mobile applications, it’s crucial for designers to study guidelines and existing patterns. This is the path to achieving excellent results. Trends and solutions are constantly evolving, and they are not always reflected in the foundational guidelines.