Unified approach to edit, contextual links, and overlay

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!


“As a content author I want to make a quick change to a block on a page I am editing without having to wade through many levels of navigation or a sea of options.”
“As a site administrator I want to make a quick change to something from outside the UI I am working in (eg. I want to edit a menu item from a menu), and I want do it without having to leave the page or get bogged down by all of the options from the secondary UI.

“As a module developer I want to apply a standard pattern for adding modal experiences on either the front end or the back end that does not force me to maintain two versions of a form or employ custom javascript and css specific to my module”

“As a themer I want to be able to use a single class or set of classes to theme all modals”


A single modal triggered from either contextual links on site pages or action links or operations links on administrative pages that enables users to quickly and efficiently make a small change then return to the place where they triggered the action.

So you might say “well that’s overlay isn’t it?”. Well, yes and no. Yes overlay is a modal experience, triggered from a contextual link that presents the user with an admin form. But does this experience enable the user to “quickly and efficiently make a small change”?. When Mark and Leisa first introduced this concept the idea was to “Make the most frequent tasks easy and less frequent tasks achievable” (see: http://bit.ly/RTqotw). What happened over time, though is that the overlay acquired some attributes that were not originally intended:

  1. It went from a quick point of access to admin tasks to the only point of access to admin tasks
  2. It went from having a few navigation tabs to having the complete administrative navigation structure
  3. It went from a focused set of options to every possible option

So while the overlay did create a modal experience that indicated to the user that they were in an administrative form it did not “Make the most frequent tasks easy and less frequent tasks achievable”. Fortunately as I outline below, overlay offers us a good foundation to build something that comes closer to that original goal.


  • Disable overlay for administrative pages accessed via the toolbar or primary and secondary tabs
  • Enable overlay for pages accessed via action links or operations and on other incidental links that occur inside #content on admin pages
  • Remove close button on overlay, add “cancel” button next to edit-submit (whether this button group should be floated left or right is up to the admin theme)
  • Remove all navigation from overlay (breadcrumb and primary and secondary tabs)
  • Implement method to mark form fields as 80% or 20% use case options so that overlay can show 80% tasks and collapse 20% tasks.
  • Display 20% options as a collapsed fieldset with a list of the hidden fields in the label
  • Close overlay on edit-submit.
  • Display confirmation DSM on the referring page.
  • Default to the above rules for triggering/not triggering overlay but implement a method for modules to create exceptions.
  • Refactor all outlier modal implementations in core (views) to follow this pattern.
  • Eventually move from requiring a page load on submit to (ajax?) partial page rendering.


  • Use this pattern to determine which fields are “80%” and which are  “20%”
    • Define the primary task the form provides. This should be as short as possible even for complex tasks. For example the primary task of views would be to “display a set of items that share attributes.”
    • Put the primary task into this sentence “Without the field [field in question] it would be impossible to [primary task]. For example, in the case of “add menu link” if we the primary task is “add a link to a menu” and the field in is “parent” then the test sentence would read: “Without the field ‘parent’ it would be impossible to add add a link to a menu” Since a menu link can be added without specifying a parent, ‘parent’ is not an 80% use case field.
    • If common sense suggests that a non-essential field is still commonly expected by the user, a good heuristic is: “Would adding this field cause the user to spend more than an additional 10 seconds completing the form? (if ten seconds seems short to you, try counting out ten seconds while looking at the modal.)
  • Because this approach works best when a form executes a single task, avoid combining different tasks into a single form. It’s tempting to suggest keeping forms atomic by creating a separate form for each data object but this would probably not work in all cases. Here are two examples current UIs that succeed or fail at this:
    • Menus (as it now exists) contains fields that update two data objects, the menu and the link table. For the user however these are understood as one object “my menu contains my links” and “when I click to edit my menu I expect to be able to re-order the links” (as we have seen) so here the data object and the user expectation are out of sync. The new implementation correctly favors the users mental model. Issue at: http://drupal.org/node/663946
    • Site information is an instance in which the form combines data that should not be combined, “edit site name” and “edit error pages” are clearly different tasks. The effect of adding a contextual link on error page text would be that the user would see an option to edit the site name at the top of the modal which would be very strange. In this instance the experience would have benefitted from atomizing these forms based on the data object. Issue [TBD]


Sometimes on edit-submit the user should not be returned to the referring URL. For instance if the user clicks “add content” from a contextual link on a site page (assuming we had such a link), after saving the content the user should be returned to the new page.

Alternately if the user is on the list content page and she adds content then she should be returned to the list content page and shown the content she just created highlighted in the same list.

The reason is that the expectation of the user comes from her context when she made the decision “I am browsing a list of content and I see I want to add a page, once I add it I expect to see it added to the list “ or “I am browsing my site and I want to add a page, once I have added it I expect to see it in my site”. In both cases the rule is that the underlying context (admin vs. front end) should be maintained.


Great stuff! I remember first

dsnopek's picture

Great stuff!

I remember first hearing about the overlay and getting really excited. However, on seeing it in practice in Drupal 7, I've eventually resolved to keep it disabled on all my sites. :-/ Having something more like modalframe/automodal in Drupal 6 which we can use on any URL when we want to improve UX for a certain action would be ideal!

I hope this gets some traction. :-)

Best regards,

We have to solve admin tables UX

andypost's picture

Now we have a views, form-tables, tables and actions with pagers that can have own URLs to be accessed from anywhere. Most of entity-lists in "admin-overlay" are used tables and sortable tables and the issue here that some of them forms and some not so introduced by render-element table but their definition is different.

Proposal here: the default entity list controller should have ability to easily switch the table to table-form element http://drupal.org/node/1855402

awesome post. thanks for

proxyninjas's picture

awesome post. thanks for sharing this.

Emma Wilson
Private Proxy Ninjas