Review of the usability of Overlay in Drupal 8

Over the past months as we worked to improve the user experience for content authors in D8 by simplifying the way users perform the most basic tasks in Drupal an issue that has repeatedly arisen is the overlay module. There has always been some debate about it’s value—and given that changes are already necessary to integrate with new core functionality—this is a good time to drill in and re-assess how overlay is working and see if we can improve it. To set the context here are a few of our observations:

Positives:

1. Katherine Senzee’s implementation of overlay is very robust and flexible and has been made even more accessible and responsive now in D8 by Jesse Beach
2. Because the overlay module uses iFrame it offers an excellent solution to presenting a form in the admin theme over top of the front-end site with no theme bleed-through.
3. #2 enables us to present a modal dialog that looks the same from an admin page (assuming a non-overlay admin page exists when overlay is enabled) and the front-end.
4. We need a consistent, responsive, accessible modal dialog solution for D8 and for views in particular.
5. We have already implemented much of the restyling of the overlay according to the new Seven style guide

Negatives:

1. Evidence suggests that overlay is commonly disabled. The following issue is a good example of it’s reputation http://bit.ly/og0Tr1, as is this article http://bit.ly/17ENkCq. Note: I am currently compiling more hard data on how often overlay is disabled.
2. After overlay was implemented, when issues arose in testing that suggested that the overlay might not conform to user expectations the results and comments (notably from Jeff Burns http://bit.ly/ZylnEZ ) got no attention (the issue is still open).
3. Overlay was based on Mark Boulton and Leisa Reichelts designs, but only implemented fully after their involvement. They and the larger community did to testing after, but no comparative study was carried out if the overlay in itself was an improvement, or just part of many other (positive) variables such as the introduction of an administrative theme.
4. Positive D7 usability test results may have been due to the introduction of overlay, but since the Seven theme was introduced at the same time as overlay we cannot know for sure. Only comparative testing can validate this.
5. The blanket application of Overlay presents an anti-pattern to most commonly used implementations of modal dialogs (for example it directly contradicts human interface guidelines of both Apple and Microsoft.)
6. Overlay did have accessibility and performance issues but AFAIK these have all been fixed.

Detailed review of overlay usability anti-patterns

The intent of Overlay was to provide a modal experience for administrative tasks by drawing a clear distinction the site and the administrative interface. Since at the time there was no separate administrative theme in Drupal there was clearly a need for separation. As I suggested above, however, Seven without overlay has not been tested to prove this out.

We do however have a wealth of other usability research to look at in regards to modal dialogs. Modal dialogs are well defined and carry a rich background of commonly understood behaviors and the pattern that overlay uses breaks many of those rules.

stick with the design conventions that users know. Whatever design you pick should work in the expected manner.-Jacob Nielsen

1) Modal forms should be quick and temporary

In D7, overlay is neither quick, nor temporary. It presents all of the complexity of Drupal in a modal experience. This is a big antipattern.

Modal dialog boxes require users to complete and close before continuing with the owner window. These dialog boxes are best used for critical or infrequent, one-off tasks that require completion before continuing.-Microsoft HIG

An app-modal dialog prevents the user from interacting fully with the current app, although the user can switch to another app. -Apple HIG

2) Modal forms should not contain navigation

Modal experiences serve the purpose of briefly taking the user out of their current context to execute an action on a sub or related object before continuing with their task.

Don't have a menu bar or status bar. Instead, provide access to commands and status directly on the dialog box itself, or by using context menus on the relevant controls.-Microsoft HIG

3) Modal forms should not nest

Nested modals invite confusion

Avoid nesting popovers [modal dialogs]. A popover that emerges from a control inside a different popover is physically difficult for users to interact with and confusing to see. In addition, users can’t predict what will happen when they click outside of both popovers.-Apple HIG

Of course it is possible that, despite being an anti-pattern to common UX patterns, the current overlay pattern is needed for Drupal because of the unique requirements of a web CMS. I don’t think this is true but I am willing to put it to the test, which is why I am proposing we do a comparative study using D8 with overlay enabled versus an altered version of D8 with overlay selectively disabled.

Here is wiki outline of the rules for when to use, or not use overlay that could be used in the altered version for comparative study: http://groups.drupal.org/node/294883 "An alternative approach to overlay in Drupal 8". Please jump in and edit if you have ideas on this.

One final note, per Dries this is an important area to explore but it does not have to be done for Drupal 8 release and UX improvements like this can be continuous enhancements.