Best Practices for Modals Overlays Dialog Windows
Why did I choose this article?
- How front end engineers are positioned in the outside world today. A lot of people think that the front-end should talk about architecture, but it’s not just that. We shouldn’t ignore the interactive experience.
- Front-end engineers have never stopped looking for user experience, and there has been a lot of controversy over the appearance of modal boxes in products, and I want to know what we think about that.
2 Content Summary
A modal box is an element located at the application window level. It creates a mode that keeps itself displayed under an outermost child view and disables the main window. The user must interact with it before returning to the main window.
The use of modal boxes
- Capture the user’s appeal
- Requires user input
- Display additional information in context
- Do not display additional information in context
Do not use modal boxes to display error, success, or warning messages. Keep them on the page.
The composition of the modal box
- Way to exit. It could be a button on the modal box, it could be a key on the keyboard, it could be an area outside the modal box.
- Descriptive titles. The title actually gives the user context information. Let the user know where he is currently operating.
- The contents of the button. It has to be actionable and understandable. Don’t try to confuse the user with the contents of the button. If you try to do a cancel action and there is a cancel button in the box, do I cancel a cancel or do I continue with my cancel?
- Size and location. The size of the modal box should not be too large or too small. The position of the modal box is recommended in the upper middle of the window, because too low on the mobile end will lose a lot of information.
- The focal point. The appearance of the modal box must attract your attention, it is recommended that the focus of the keyboard also switch to the box.
- User initiated. Do not frighten users. Use user actions, such as a button click, to trigger the appearance of a modal box.
The modal box is on the mobile side
Modal boxes don’t always work well on the mobile end. One reason is that modal boxes are generally too large and take up too much space. It is recommended to add a device button or built-in scroll bar to operate, the user can move left or zoom in and out to grasp the modal box.
Frictionless access
- Shortcuts. We should consider adding shortcuts to modal boxes for open, move, manage focus and close.
- ARIA. Add aria identifiers at the front code level, such as Role = “dialog”, ARIA-hidden, aria-label
Modal frame positioning
First, models and Toast, Notification, Message, and Popover are all triggered to pop up a floating layer at some point in time, but it is different from Modal. By definition, none of the above components are modal boxes, because modal boxes have the important property of blocking the original action in the main window and only doing subsequent actions in the box. In other words, the modal box completely interrupts user flow from the interface.
Of course, this is also the issue we need to discuss, if it is just a general message alert, you can use message bars, red dots and other forms of interaction, at least not blocking user operations. In the 10 Guidelines to Consider when using Overlays quoted at the end of the original lays, article 8 emphasizes that modal frames should never be used. What are the situations where you really want him to stay on the page and read or do something inside the box?
Conversely, what are the advantages of modal boxes? Remember that modal boxes are a much lighter experience than page jumps. For example, when a user sees a product on Taobao and wants to log in and buy it, the experience of the login modal box popping up is much better than that of jumping to the login page, because the user can directly purchase the product after logging in the modal box. Secondly, the content of the modal box is a derivative or supplement to the current page, allowing users to read or fill in some content more intently.
That said, when timed, a smooth pop-up experience, the necessary context information, and friendly exit feedback can all improve the experience. The modal box is intended to attract attention, but it must provide additional information, either an important user action or an important protocol confirmation. You can complete the process or information on this page.
We also learned some lessons about better use of modal boxes.
- Is the content relevant? The modal box is used as a derivative or supplement to the current page. If the content is irrelevant to the current content, other operations (such as new page jump) can be used instead of the modal box.
- Excessive manipulation should be avoided inside the modal box. The modal box should give users a smooth and natural feeling of watching and walking, rather than using complex interaction to retain or contain users;
- Avoid having more than one modal box. The presence of multiple modal boxes increases vertical depth, visual complexity, and user irritation;
- Do not open the modal box suddenly or automatically. This operation should be initiated by the user.
There are two more definitions based on the actual situation:
- Size. There should be relatively strict limits on the size of the modal box. If too much content causes the modal box or the page to have a scroll bar, it is generally a bad experience, but if it is used to show detailed content, we might consider using a scroll bar.
- Turn animation on or off. There are a lot of designs out there that tend to animate smooth transitions and make Modal less obtrusive, and dribble has a lot of examples of that. However, in some applications with complex processing around data, such as ERP and CRM products, users usually focus on a form and a series of operations around the form, and page switching back and forth or complex and seemingly cool animations may affect efficiency. What the user wants is a straightforward completion, perhaps without animation, and a quick response.
For two examples, Facebook gives us a good demo of this. Its share mode box is in the same location as the main window, giving a very smooth experience. You can also see the detail that fonts from the main window to the focus of the modal box become larger. In contrast to Weibo, it directly displays the form of sharing such as photos, and the focus on the input box does not change.
The second example is Quora. The main page of Quora presents the Feed stream. Clicking on the title opens a modal box showing what it answers, with a scroll bar that can be closed by pressing ESC. Very smooth experience. In contrast, the homepage of Zhihu has to switch back and forth to see the content quickly.
Rethinking accessibility
Accessibility Accessibility is the improvement of the experience for different end users. For each modal box, there should be a function to close it via the keyboard, usually using the ESC key. It seems that we programmers somehow carry our own stereotypes into the implementation of the product, especially when we’re tapping on an external keyboard and using a PC.
The following questions are reflections on accessibility:
- Maybe the user doesn’t have a mouse, or a keyboard, or maybe they don’t have either mouse or keyboard, and they just use voice control? How do you get those users to quit
- Many Windows PCS already have good touch support, but your web page still only supports keyboard and mouse?
- Is a horizontal scrollbar an outlandish design without an Apple trackpad?
- In a web page, using Command(Ctrl) and +/- and using the touchpad zoom events are two different representations, right?
- If your end user doesn’t have a good touch pad, but he really can’t see what’s on your web page. If he uses the former, can you make sure your site still displays the content?
Accessibility has always been a product that has been grossly neglected, and the emphasis on how it is done at the end of the article’s Best Practices is a good nudge for us developers.
Front-end development still requires the implementation of code level, business code for the use of stateful or stateless modal boxes there are general problems.
For stateful modal boxes, many libraries will support.show calls, so the internal rendering logic of modal boxes will be executed when this method is executed, no problem. However, now Stateless Modal box is popular, whether the display of Modal box is controlled by the parent component, we only need to write the code of Modal box in advance, and whether the display is controlled by the external.
This way of stateless modal dialog in the modal dialog to display complex logic scenario, will naturally initialization logic is written in the parent, when a modal dialog appeared in the circulation list, often can cause the first screen to trigger a 2-30 times modal dialog initialization operation, which is the best state to perform a modal dialog displays, because of the modal dialog at the same time only one, The first screen is initialized at most, but the following seemingly fine code often causes performance problems:
const TdElement = data.map(item = > {
return (
<Td>
<Button>details</Button>
<Modal show={item.show} />
</Td>)});Copy the codeThe code initialization above performed N modal box initializers and was clearly inappropriate. For the modal boxes triggered in the table action column, all rows correspond to a modal box, and the display is controlled by a state variable in the parent:
class Table extends Component {
static state = {
activeItem: null};render() {
const { activeItem } = this.state;
return (
<div>
<Modal show={!!!!!activeItem} data={activeItem} />
</div>); }}Copy the codeThis reduces the number of nodes, but the problem is that every time a modal box is displayed, the trigger is a modal box update (componentDidUpdate) instead of a new. Of course, combined with the characteristics of the operation in table, we can optimize as follows:
{activeItem ? <Modal show={true} data={activeItem} /> : null}Copy the codeAdditional reading
This article is about best practices, and it’s UX level. But we still see some students put forward the opposite opinion, I conclude that different products or different users bring us different understanding. Is this the time to cling to “best practices”? At this time, for products, we can collect user research methods to judge, and replace sensory conclusions with data conclusions.
Also, accessibility has been seen in articles from time to time in recent years, but very rarely. This is typical of the long tail requirements, many r & D products only consider 90% of the users, do not know the needs of the part of the users we give up. This is a lack of overall thinking from product to r&d.
If you’d like to participate in the discussion, pleaseClick here to, with a new theme every week, released every Friday.