An alternative approach to overlay in Drupal 8

This is a proposed solution to the problems outlined in the Review of the usability of Overlay in Drupal 8 by the same author.

Terms

Primary Object: anything the user begins editing directly from a menu or list page.

Secondary Object: anything the user begins editing from within the task flow of editing a primary object.

The question the experienced Drupalist is already asking is “well, in some contexts an entity is a primary object and in others same entity is a secondary object, won’t this confuse the user?”. Possibly, but I suspect it will clarify rather than confuse because it keeps the user anchored on the primary task.

IMPLEMENTATION

Don’t use overlay when the user is browsing the admin and has not settled on a specific task or when the user has initiated a task on a primary object.

Use overlay when the user is in a task flow editing a primary object and she needs to perform an action on an attribute of the primary object, or an attribute of a related object, then return to the task flow.

Specific cases:

List UI: Never use overlay

A list UI is simply a recapitulation of a menu with some hierarchical layout and descriptions added. There is no logical reason to put list pages in overlay, the user has not initiated any task and is simply browsing around the admin in search of the place they need to be to initiate their next task.

Examples:

• Structure
• Configuration
• Reports
• Help

Note: currently there are stylistic differences between these UIs. In my view they serve analogous functions and should be revised to share layout and styling.

Decision UI: Always use overlay

The decision UI is a list page that the user lands on after triggering an action to create something where they must choose a single option before they can proceed.

The decision UI should always use the overlay to clearly distinguish it as an action that initiates a task, not merely navigation.

Examples:

• Add content (Content types)
• Add custom block (Custom block types)
• Add block (block types)

Note: currently there are stylistic differences between these UIs. In my view they serve analogous functions and should be revised to share layout and styling.

Object UI: use overlay for secondary tasks

The object UI is where you would edit a single thing, commonly but not always, an entity. When the object is the primary task (any form triggered from a List UI or a Decision UI) overlay should not be used. When the object is a secondary task (any form triggered from another object UI) overlay should be used.

[An alternative approach to this would be simply use overlay for all object UIs, in which case the pesence of overlay becomes a clear indicator that "You are now performing a task". The drawback of this would be that as task UIs evolve and become more "app like" (like views does now and undoubtedly layouts will do), overlay is cumbersome and just gets in the way]

Object UI examples:

• Add/edit content
• Edit view
• Edit menu
• Edit layout
• Edit term
• Edit menu link

A good illustration of this rule would be:

Use case 1: The user opens a menu to edit it then clicks “add link”. The menu UI opens without overlay, the add link UI opens in overlay. When the task is complete the user is returned to the Menu UI.

Use case 2: The user goes to the menus UI and clicks “add link” from the actions drop-button, the UI opens without overlay because adding the link is the primary task, not editing the menu. When the task is complete the user is returned to the list menus UI not the menu UI.

One important exception is that contextual links from a site page can sometimes open in overlay and sometimes open in without overlay. The rule for this would be:

If the link goes to the edit form for the parent item of the dropdown open without overlay (Edit menu, Edit view, Edit custom block)

If the link goes to anything else open in overlay (Add link, configure block, delete)

Note: In this concept the block is not understood as the “parent” just a container for it

Configuration UI: use overlay for secondary tasks

A configuration UI is similar to an object UI but sometimes contains several options that seem to really belong to different objects. The general rule here should be that any link triggered from within the UI should trigger overlay.

Here is a detailed spreadsheet showing a possible mapping of where overlay is used: http://bit.ly/13w0Tom