Problem![]()
I’ve been asked to add modal windows to our Appway App. However, I’ve heard that Appway discourages the use of modal windows or
modal dialog boxes. Why is that, and what can I do instead?
Solution
The
problem with modal windows First of all, what's a modal window? Basically, a modal window (Wikipedia) is a window that prevents the user from interacting with your application until she closes the window — that is, it changes the App's mode (Wikipedia). Typically, modal windows are discouraged in user interface design, because they interrupt users and force them into doing a specific action. What's more, modern operating systems have trained people to instinctively and automatically dismiss dialog boxes (for example, interaction designer Aza Raskin notes that "interfaces that don’t respect habituation are very bad" — there are extensive studies about this). Many people simply don't read modal dialog boxes, or are confused by them.
In almost all cases, there is no need to force users into specific actions. As a result, modal windows introduce unnecessary pain points for your users.
Instead, you should aim to create modeless user interfaces. Modeless user interfaces allow users to change their mind at any point. They are not forced into a specific set of actions.
Modal windows also cause another problem: they don't work well on devices with small screens. Modal windows eat up screen space, since they introduce additional user interface elements. If the screen is small to begin with (for example, when the user is using a phone to access your App), the content inside the modal window is even smaller. This is particularly bad if the content doesn't fit inside the screen, and you need to show scrollbars. Nested scrollbars do not work well on mobile devices, since people expect to be able to scroll the whole screen by swiping with their fingers.
So modal windows provide a bad user experience, and don't work well on mobile devices. Fortunately, there are almost always better solutions that you can use instead of a modal window. These alternatives are completely modeless, and work well on any device.
This document introduces some of these design patterns.
Pattern 1: Show UI elements inline
Here's a typical example of a modal window. The user wants to assign a process to another person. Clicking the button opens a modal window that allows her to select another user.
Here's an alternative solution: why not just put the person selector right on the screen, instead of tucking it away in a modal window?
This removes the need for a popup. Moving the user selector and the "Four-Eyes Check" button close to each other ("chunking") allows the user to understand that the two elements belong together, and that she has to pick a user before clicking the button.
Pattern 2: Collapsible UI Elements
In Pattern 1, the UI elements are always visible. Sometimes, you don't want that, though. Here's an example where a modal window was used to enable users to perform a wide variety of actions.
It might be confusing to simply show the drop-down with all of these actions on the main window. Fortunately, avoiding modal windows does not mean that the screen needs to contain all UI elements by default. For example, the UI elements could be shown (and hidden) using a simple collapsible section.
This keeps the screen clean. If there's no room on your screen for an UI element like this, you can even move it into the sidebar.
This solution works well on all device sizes, and once the user clicks on "Perform another Action", she's not forced into anything. She can select an action and click the button, but she also has the option of simply moving somewhere else at any time. For example, the action she's looking for might not be in the dropdown. Instead of having to close a modal window, she can just move on and continue looking for the option she wants.
Collapsible UI elements can be used for all kinds of things. Here's an example of a user interface that shows versions for uploaded documents using a modal window.
This is a perfect use case for collapsible UI elements. Clicking on a document shows that document's versions inline in the screen. This even allows users to review versions for multiple documents at the same time.
The Data Table component supports collapsible sections as a built-in feature. See the section on Interlines in the Data Table documentation to find out more.
Pattern 3: Dynamic Inline Elements
Sometimes, you want to alert your users to something. Here's an example: the user clicks on a download link. Most browsers still have somewhat confusing user interfaces for downloading files, and the user might not notice that the download has started. So you want to show some kind of alert that explains what has happened. A simple solution would be to throw up a modal window that forces the user to acknowledge the message.
But what if the user wants to download multiple files? Now he has to click away the message after clicking on each downloaded file. A much better solution would be to display the message inline in the screen.
Replacing the clicked text with the message ensures that the user will notice it. But there's nothing to click away; the user is free to move on with his task, and is not forced to acknowledge the message in any way.
Pattern 4: Showing a loading screen
There are situations where the user clicks on a button, and Appway starts a lengthy task in the background. To the user, it might not be immediately obvious that something is actually happening. She might try to click on the button again, thinking that the first click was not registered by the browser.
A common solution to this problem is to show a modal window with a "please wait" message.
This is actually an example where a modal dialog makes sense, because you need to prevent the user from interacting with the screen. Even so, clicking on a button and having the whole screen blocked might be disconcerting. A gentler approach would be to simply disable the button to prevent the user from clicking on it again. Next to the button, where the user's focus is, show a throbber and a message to indicate what is happening.
Once the task is done, you can replace the throbber with a message indicating that everything went well, and re-enable the button. After a few seconds, fade the message out, and remove it.
This solution avoids the disconcerting modal overlay, while still retaining most of its advantages. Note, however, that this solution does allow the user to interact with other parts of the screen. For example, she could click on a navigation button, and leave the screen. Of course, for this particular use case, the modal window is purely decorative, and you can easily remove it. Showing a simple overlay with a throbber looks much sleeker than the modal window.
Implementation detail: You can show a loading screen for Ajax Update Areas using the Ajax Throbber Screen component. If you want to show a modal loading screen after the user clicks a button (because it takes a long time to render the next Screen), you can use the Block User Action to prevent the user from interacting with the current Screen while the next Screen is loading.
Aside: If the button triggers a Process action that takes a long time, a design pattern often used is to create a "Please wait..." Screen that submits itself after a few seconds. When the user clicks on the button, the Process forwards the user to the "Please wait..." Screen, and keeps forwarding her to that Screen until the task has finished. Then, the Process forwards the user to the next Screen, and this Screen then shows a "Task has finished" message. Stephan Markwalder explains how to achieve this in this forum post.
Pattern 5: Error Messages
A common use case for modal dialogs are error messages that occur when the user does something that your App can't deal with properly. For example, the user might try to delete a document that is still being used elsewhere in your App, and can't currently be deleted.
As far back as 1987, Apple's Macintosh Human Interface Guidelines recognized this problem, and recommended that user interfaces should not tempt users into trying to execute actions that are currently not available to them. The simple solution recommended by the Human Interface Guidelines is to disable actions that are not available (don't remove the buttons outright, though).
This causes a problem, though. If the button is not available, how do you communicate why it is not available? In the previous solution, the modal window that popped up after the user clicked on the button explained the problem. If the user can't click on the button, how do you explain the problem? Fortunately, there's a solution. Simply show a tooltip that explains why the button is disabled once the user hovers the mouse over it.
Since this does not work on touchscreen devices, it's important to have an alternate solution for these devices. One option would be to show a small "info" button next to the disabled button that shows the tooltip when tapped.
Pattern 6: Warning Dialogs
Closely related to the previous pattern, Appway Apps sometimes use modal dialogs to warn users when they are about to execute a destructive action. For example, when the user tries to delete a document that can be deleted, the App asks "Do you really want to delete this document?"
This is problematic because many users have learned to dismiss such dialogs automatically, without reading them (in fact, whenever you have any text in your user interface, you should just assume that people won't read it, and design your user interface such that it works regardless). A better approach is to either offer the ability to undo the action, once it is done, or to have a timeout. Once the user clicks on "delete", delay the action for a few seconds, and show a "cancel" text in the same place as the "delete" button (where the user's focus is). When the user clicks "cancel", don't delete the document.
If you can't avoid modal windows
There are very few situations where you might not be able to avoid having modal windows. For example, a client might insist on having modal windows. If this is your situation, follow these guidelines for modal windows.
The modal window should have a descriptive title
People might be confused about why the modal window appears. Having a clear, descriptive window title explains the window's usage.
The modal window should have a Cancel button
Even if the modal window has a close button in its header, you should also add a Cancel button. People are used to dismissing modal windows by clicking on "Cancel", and not having this button will cause confusion. If you know that your users are mostly on Windows, make sure that the Cancel button is on the right-hand side, consistent with where Windows displays it. If you have a mixed audience of both Windows and Mac users (where Cancel is on the left), it might make sense to read out the host system, and rearrange the buttons appropriately.
The modal window should have a Close button
This allows users to dismiss a modal window without even looking at its contents.
Escape should close the window
When people open a modal window by accident, many will instinctively hit the Escape key to get rid of the window. Make sure that this works correctly.
Close when clicking outside the modal window
This is a pretty new kind of behavior, but people are used to it from phone operating systems like Android, and from other websites: clicking outside a modal window typically dismisses the modal window. It makes sense to replicate this behavior.
Add a drop shadow and a transparent background
To clearly communicate the nature of the modal window, add a drop shadow (so people understand that it is hierarchically above the other screen content), and dim the rest of the screen with a transparent background (so people understand that the window is modal, and that they can't interact with the rest of the screen).
Don't make the modal window too large
Large modal windows make it look as if the window's full content has changed. This is confusing, because people might not notice
that they are looking at a modal window inside a browser window, and might not figure out how to dismiss it. If you have a modal window that contains a lot of content, you should move the user to a different screen instead.
原文鏈接：https://developer.appway.com/screen/ShowSingleRecipe/selectedRecipeId/1390246496349?useful_click=1
