Modals. Popups. Overlays. Dialog Boxes. No matter what you call them; ugh. I can't even. If I were being gracious, I'd say that nine times out of ten, modals are the lazy way out of solving a hard (or sometimes not so hard) design or development problem. We should stop doing that.
Have you ever entered a room and totally forgotten why you had gone in there in the first place? Of course you have; we all have. There's a name for that: The Doorway Effect
The Doorway Effect, more formally known as the location-updating effect describes: "the finding that when people pass through a doorway to move from one location to another, they forget more information than if they do not make such a shift.… Essentially, a shift at an event boundary introduces a need to update one's understanding of the ongoing events, and this updating process is effortful." In their work Walking through doorways causes forgetting: Further explorations, Gabriel A. Radvansky, Sabine A. Krawietz, and Andrea K. Tamplin of the Department of Psychology, University of Notre Dame explored whether the Doorway Effect was dependent on how the environments are experienced. Their conclusion is that no, be it physical objects in the real world or virtual objects on a small screen, the Doorway Effect was not dependent on how the way the environments are experienced.
Now why is the Doorway Effect so bad? Well, results showed that people make more errors when they had moved and that their response times slowed down to probes when their conditions were shifted as compared to when they were not shifted. Their conclusion? Needing to mentally update the model of what is happening winds up compromising memory.
In the paper, the researchers discuss an event horizon model of event cognition and memory. The relevant parts to the Doorway Effect are: "(a) Events can be segmented, and different event models are created with people processing one at a time", "(b) information in the current event that is being actively processed is foregrounded", and "(d) there is retrieval interference for competitive retrieval".
The first, event segmentation, occurs when an event boundary is encountered, such as a person moving from one room to another, and a new event model may be created and stored in memory, making the event model for the prior event decline in availability.
The second, the event model that is currently active in working memory is foregrounded, makes it easier to retrieve information from that event. The current event model occupies working memory, and available processing capacity is directed to it.
The third, retrieval interference of competitive retrieval, makes a person choose one memory trace to verify that information. When people move an object from one location to another, it is now associated with two location - the location it started in and the location it ended up in. Thus, there may be two event models that contain the target information, which compete with one another at retrieval, producing interference and making retrieval slower and more error prone.
Now, how does this relate to the dreaded modal? Well, let's take the most common use case for a modal: contextual actions/task/information/etc… Modals by design take over the whole screen, stripping context from our contextual needs (which kinda defeats the purpose in and of itself), but more damning, thanks to the Doorway Effect, will cause more errors and slower response times from our users than not doing so. Modals are a harsh enough switch that they wind up creating a new event model for our users, creating an event boundary, and triggering the Doorway Effect. When we close the modal? Another event switch, a new event model for our users, a new event boundary.
How about the other uses for modals besides contextual information? One modal for our login, one for our lightbox, one for this, that? All may be wrapped in the same modal wrapper, but all contain different inner layouts, different inner content models, different contexts. The research in Walking through doorways shows that increasing the number of new areas a user enters substantially increases the number of errors users have, and each new creative use for a modal is a new area for our users.
Here comes the grumpy, kneejerk reaction to all of this: "Fine, then what should we use instead?" Ya know what sucks? There isn't a single drop-in replacement for modals. They've become the deus ex machina of user experience design. In order to replace such a seemingly omni-functional tool, we need to be creative. Being creative is hard, for both designers and developers, and we can be tempted not to do the hard work needed to solve our users' problems in the best possible way for a large number of reasons, including some that can be out of our control. But we should try.
The first, and most obvious thing to do, is determine if clarity of context can be improved by bringing users to another page. I find this solution is best for administrative tasks as users are entering a new mental model and the cost of event switching can be justified by this new context switch while also providing ample context for users to orient themselves. I also really like this solution for user login, especially if an entire site isn't secured (for security reasons, never let users send their passwords over non-encrypted connections). When using a new page, ensure that the URLs (and breadcrumbs, messaging, etc…, if you have them) provide users with some contextual reminders of the action they are going to perform to help ensure they don't loose their train of through. Consider this: in places where an entirely new context is loaded into a modal, that's probably a good place to create a new physical page for a user to navigate to.
The second, and one I've become a really big fan of, is what I'm going to call the contextual slide open (that's a terrible name, someone suggest a better one). I first saw this pattern used in the iOS view of Google Image search, and has since expanded to all versions of Google Image search. The basic idea is that, instead of a modal, make the relevant content appear in-line, on the same page, contextually connected directly to the triggering element in both UI and animation, while keeping that trigger in view, with deep links to animate-in the contextual area on load, that can be closed through an obvious close indicator, by toggling the selected item, or by simply ignoring and moving on with the page, all without covering anything else on the page. While this doesn't resolve all of the issues we encounter with the Doorway Effect, it helps to mitigate them all in a fairly elegant way as it isn't an entirely new area, allowing for faster recovery from the event boundary by only requiring a tweak in the current event model instead of needing to build an entirely new one and removing the possibility that information is stored across two event models.
<video src="http://snugug.github.io/videos/google-images-modal-replacement.mp4" controls loop> <p>Download a video of the <a href="http://snugug.github.io/videos/google-images-modal-replacement.mp4">Google Image Search modal replacement</a></p> </video>
With this information in had, and a couple of new patterns to consider and grow from, we should grab our bootstraps and pull ourselves out of the modal murk. As designers and developers, we are creatives, and being creative is hard. Our answer, like always, should be to do the hard work to find the best solution for our users, not simply use the same 'ol stuff without sitting back to consider if it's actually doing what we think it is. Modals are the prototypical example of a pattern that gets used and abused without though. We should stop doing that.