Is dialogue part of navigation or not?

Introduction

Not long ago I started developing own library for navigation in client applications on Kotlin Multiplatform. Making such a solution fit the fantasies of every designer and product manager is difficult. Therefore, I started talking about the library and its concepts at the development stage in order to understand how it could suit developers, especially those who already have a large code base. One of the controversial topics that came up in our discussion was: “Should the dialog be shown through navigation and stored as part of the user's navigation history?” My answer: “It depends on what we mean by dialogue and the purpose of its display.”

My name is Kirill Rozov and in this article I will tell you what I mean by dialogue in Material Design and my opinion on how to work with dialogues in navigation

If you are interested in following the latest Android development news and receiving a selection of interesting articles on this topic, then you should subscribe to Telegram channel Android Broadcast and my YouTube channel “Android Broadcast”

What is dialogue

Dialogue in the user interface (UI – User Interface) is a pop-up window, panel or screen that is temporarily displayed on top of the main content of an application or site.

Dialogues are used to attract the user's attention and usually require some kind of interaction or response from the user. They can perform various functions such as confirmation of actions, data entry, error messages, event notification, settings or parameters within a page. The dialogue does not take up all the space and you can see the screen underneath it to understand the context in which the dialogue is shown.

Do not confuse dialogs with windows that do not occupy the entire screen. For example, a common technique is to display the dialogue over the entire screen area on smartphones, while on a tablet the window display mode is used. The screen on the tablet does not become a Dialogue, but has a visual style similar to it, although Material Design calls this case “Full Screen Dialog”

Material design has a component Bottom Sheet (used on smartphones and tablets) and Side Sheet (used on large screens), which can also be classified as dialogues because replace those functions for which dialogs are used.

In general, the way something is presented as a dialogue or not seems so conventional to me that even the context menu can be classified as dialogue.

Dialogue modality

There is no obvious division by place of use of dialogues, but they can be divided according to their influence on the ability to interact with the UI into modal and non-modal.

Modal Dialogs visually block interaction with the rest of the application until the action requested in the dialog is completed. For example, confirmation of an action or notification of an error that prevents you from continuing to work normally with the application. In some cases, they allow you to close it and continue working with the application further.

Modeless Dialogs allow you to continue working with the application because do not require immediate interaction with him. This includes prompts or notifications. They are often presented as a Banner or Snackbar.

Dialogue in navigation: to be or not to be

By user navigation in the UI I mean transition through the Application Screens. Navigation history is returned after the application is restored. The loss of any such navigation element is critical for the user.

If we look at the Jetpack Navigation library for Compose, then right in the method documentation dialog() it says:

… This feature is intended for when the dialog box is a separate screen in your application that requires its own lifecycle and saved state, independent of any other screen in the navigation graph …

Showing the Screen in the form of a dialog in the Jetpack Navigation code, although the functions are highlighted, is only a visual wrapper in Dialog and essentially has little difference with displaying a regular Screen

// Пример использования Jetpack Navigation для показа Composable
// во всплывающем окне в стиле диалога
NavHost(
  navController = navController,
  startDestination = startDestination,
  modifier = modifier
) {
    dialog<PopupScreen>{
      // Показываем Composable функцию, которую обернут в диалог
    }
    composable {
      // Показ Composable функции на всём доступном пространстве
    }
  }

As a result, I adopted a number of rules for myself regarding screens in navigation:

• All contextual UI elements are not navigation relatedfor example Context Menu

• All modeless dialogs are NOT app navigation relatedsince these are only visual notification tools. They may refer to the Screen state or be part of the global state

• The confirmation and selection dialog is not part of the navigationas it is considered a visual tool to prevent accidental action and is contextual. May be part of the Screen state

• The application screen, shown in a dialog style, is part of the navigation. Here the dialogue is just an overlay style. Such a Screen on some devices can take up all the available space

• Application content that is shown in a conversational style is considered part of the navigation because it is saved across screens and placed in the back stack

IN your decision navigation, I don’t see any point in highlighting the work with dialogs; it’s just the visual style of the Screen in the navigation state, for which the UI part of the navigation should be responsible.

I'm interested to know your opinion and how you approach working with dialogs in UI navigation. Share it in the comments and let's search for the truth together!