The evolution of the toolbar; Drupal 7 to Drupal 8

Blog series: #1 of 5.

As we saw in Dries’ keynote in Portland there’s a new toolbar in Drupal 8 that looks—and works—quite different to the one in Drupal 7. This series will give some history on how the new toolbar came to be as well as some of the design thinking behind it and how it can be used and extended by content authors, site builders, themers, and module developers.

Why did we need to change the toolbar?

The Drupal 7 toolbar was a big improvement over what we had in Drupal 6 but just in the short few years since it’s introduction the whole landscape of front-end design has changed with the explosion of mobile devices and the toolbar needed to change with it. The image below dramatically illustrates the weakness of the D7 toolbar on a phone.

The Drupal 7 toolbar

Lack of responsiveness wasn’t the only gap in D7 toolbar. The proliferation of contrib menu systems that users were using to replace toolbar pointed to other usability needs:

Admin tools:

“I want to get the menu out of my way by pushing it to the left, right or bottom of the viewport”

“I want other things in the toolbar besides menu items”

Rubik theme: (right)

“I want to see icons as an aid to wayfinding”

Administration menu:

“I want dropdown menus or an expanding tree so I can traverse all of the deeper levels of my information architecture”

In addition to these contributed solutions in Drupal 7 Roy Scholten and Lewis Nyman (now maintainer of the “Seven” admin theme) from the Drupal UX group had already worked on prototypes that solved these and other responsive issues.

Lewis Nyman’s prototype

The Spark team picked up and extended that work with Navbar in Drupal 7 which eventually became the Drupal 8 responsive toolbar.

What does the toolbar do?

The advantages the toolbar in Drupal 8 has over previous versions are that it’s fully responsive, configurable, themeable and extendible. It has a top “application bar” with a home link, menu tab, user tab, shortcuts tab on the left and, depending on your context, an edit toggle, responsive preview dropdown or tour trigger on the right.

Link, tab, toggle dropdown trigger—why all the differences?

The flexibility of the toolbar comes in it’s ability to accommodate different types of user interactions. For instance “home” is a link that always brings you back to the homepage of your site but menu is a tab that opens the menu tray without leaving the page you are on. Shortcut and user are also tabs that open the tray. Edit is a toggle that shows and hides edit-in-place links (contextual links) so users on touch devices can see what’s editable. Responsive preview (a module to view what your content will look like on different devices) has a dropdown, and Tours (A Guided tour of administrative pages) has a trigger that starts the pop-up tour of features of the current page.

As with everything in the toolbar all of these interactions are extendible so if a module developer wants her module to add a link, tab, dropdown, toggle, or trigger to the application bar, she can do that. The most common practical application of this will probably be for distribution developers who want to add an entirely segregated administrative section, eg. “store” in Drupal Commerce.

Application bar with store added

The tray

The tray provides a place for menus and their children. It has four modes: Horizontal left-to-right (LTR), Horizontal right-to-left (RTL), Vertical LTR (screen left), and Vertical RTL (screen right). So if, for example, your content language is english (LTR), and you are viewing the site on a desktop, your toolbar will be horizontal-LTR. If your content language is hebrew it will be horizontal-RTL. By clicking the menu orientation toggle you can change the menu from horizontal to vertical and the menu will move to the left or right depending on your content language.

Application bar and tray (horizontal LTR)

Application bar and tray (vertical LTR)

How is it responsive?

If you shrink your browser window beyond a certain width or view your site on a tablet or phone the menu will automatically change to vertical to fit in the smaller viewport. This combination of responsiveness and configurability is one of the great strengths of the toolbar.

Another responsive feature of the toolbar is that on a phone the labels in the application bar disappear leaving only the icons. This saves a great deal of space and follows current responsive best practices.

Toolbar on iPhone

Is this accessible?

Absolutely. Every feature of Drupal 8 core has to pass the accessibility gate. In fact in the process of creating toolbar, we created two whole new systems for making things accessible in Drupal: The tabbing manager, which tells a screen reader where to skip to next in the UI, and Drupal announce, which is the method for adding spoken text to things in the UI.

What about modules with other types of modals?

The overlay and jquery modals have been refactored to be responsive and to work in conjunction with the toolbar depending on it’s state. Some of the features of this are:

The gray “scrim” that covers the page in overlay mode does not cover toolbar or the tray so all of your navigation is available.

When the toolbar tray is in vertical mode the overlay (or a jquery modal) center between the tray and the opposite viewport edge, not to the whole viewport

The overlay width is responsive and treats the edge of the vertical tray like the edge of the viewport

Blog series: #1 of 5.

As we saw in Dries’ keynote in Portland there’s a new toolbar in Drupal 8 that looks—and works—quite different to the one in Drupal 7. This series will give some history on how the new toolbar came to be as well as some of the design thinking behind it and how it can be used and extended by content authors, site builders, themers, and module developers.