What I’m talking about are often called “modal windows,” “overlays” or “light boxes.” there’s no official rule about how and when to use an overlay. However, I consistently see inappropriate use of overlays on the web. I also must consistently explain why using an overlay isn’t the best solution to a problem. Maybe this post should be called when NOT to use an overlay.
Overlays are great for short, minimal interactions that comfortably break the workflow.
Good overlay examples:
- Login/signup screens
- Short multi-step wizards
- Tutorials
- Help content
- Video/image gallery content
Often abused overlay examples:
- Advertising
- Error messages
- Content that scrolls (like an iframe site)
- Absolutely positioned large overlays that don’t let you scroll to the close button!
Here are some questions you should ask when deciding whether or not to use an overlay.
Is the text short?
If you are asking the user a simple yes/no question, then consider displaying the query inline with the action that triggers prompt. Lots of confirmation dialogs fit inline with the content, such as confirming whether or not you want to delete a table row. You can even leave the row in place with an undo button if you follow this model.
Is the text long?
If the content overflows the screen, it should be on its own page. You don’t want to make the user face the awkwardness of a scroll bar inside or out of the overlay. End User Agreements are probably the only exception to this case, because nobody scrolls to read it anyway.
Should the workflow be interrupted?
Often times, you want to focus the user’s attention on one action, and stop them from clicking on anything else on the page. This means either bringing them to another page, masking all other content on the current page, or allowing the user to click off the current action.
Does the overlay contain a form?
You need to validate that form both client-side and server-side. If the transaction fails, how will the user get back to the form? Returning them to overlay after a page refresh can be an awkward and difficult interaction. Get around this with AJAX calls, or put the form on its own page.
Other best practices
- Dragging an overlay by the header is almost never the right answer. Use a different design that doesn’t cover up what you’re working on.
- Don’t use an overlay to communicate success or failure of a form. Consider instead using a sticky banner message at the top of the screen, or scrolling to the field that needs help. The exception to this case is if an action requires further steps, like (like declined credit card) needs further steps, then
- Make the close button obvious and consistent. Clicking outside should also close the overlay.
- Don’t forget about accessibility. Screen readers and keyboards need to be able to navigate within.
- Never use javascript alerts.
- Test in all browsers. Although most overlay libraries are compatible back to IE 6, some have positioning and z-indexing quirks.
- Remember mobile devices! Small screens with absolutely positioned overlays leads to trouble if you can’t get to the stupid close button off-screen.
I’m sure there’s lots more to cover, but I’ll leave it to the comments to fill in the gaps!