A responsive toolbar for Drupal 8
A little history
The Spark team’s main goal is making the experience of Drupal content creators both effortless and flexible, regardless of whether they’re on a desktop or a smartphone or something else entirely. The key to this is responsive design, and right now, the core Drupal toolbar is not responsive:
Any effort in Drupal 8 to create a responsive administration experience must address the design of the core Toolbar.
For more than a year many members of the Drupal community, notably Lewis Nyman and Roy Scholten, worked steadily toward a design of a responsive toolbar and even prototyped possible solutions:
Their efforts informed the direction the Spark team’s first designs for a responsive administrative toolbar, expressed through early versions of the navbar module in Drupal 7, which we brought as a functioning prototype to DrupalCon Munich:
Following discussions and BoFs in Munich that concluded with a general consensus for the design direction, we moved development to Drupal 8, in the pre-existing toolbar issue. A couple weeks later we proposed a preliminary patch meant to start a larger discussion and kick off a larger development effort. Following a third patch, Dharmesh Mistry and Bojhan Somers conducted usability tests comparing the current D8 toolbar designs to the D7 toolbar. Currently, the toolbar is undergoing active discussion, both on design and implementation details. Here’s the toolbar in its current state, on both desktop and mobile:
I have followed all of those discussions closely. It has became clear to me that a successful responsive toolbar solution cannot simply be a mobile-specific solution. A successful solution must take the lessons learned from mobile-focused designs into account and fold them back into the desktop experience resulting in a truly responsive toolbar that can fluidly adapt to any device. In order to form an integrated small screen and desktop administrative experience, we must first understand the needs of the end user.
What are the users’ needs?
One common way of describing the needs of a user is through the machanism of <a href=”https://en.wikipedia.org/wiki/User_story”>user stories</a>, which help identify the features the solution needs to have to be effective. In the case of the toolbar, the primary users are the site administrator and the content author, so these stories are written from their perspective, but most apply to the site builder as well, particularly when that person is a new Drupal user.
Here, we’ll examine some user stories around the toolbar, and illustrate how the current design satisfies those use cases.
“As a content author... I want to be able to manage my site on any device, and have my tools automatically fit the screen size.”
We first needed to have the toolbar somehow collapse to a more manageable size for phones. To save space in the toolbar we reduced the number of items to three: home, menu and user and on phones, the labels are hidden. So now the content author has a compact top bar where they can log in, jump to the home page or open the entire admin menu.
“As a content author... I want to be able to create, find, and edit content I have created, on any device.”
We needed to expose the shortcuts so the content author would have access to the “add content” and “find content “ shortcuts. Inclusion of the shortcuts also partially solves for #11 because the admin can add more shortcuts.
(this design has not been implemented yet)
“I want the experience of finding, creating, or editing content to be similar on all devices so I don’t have to learn something new.”
We put the same vertical toolbar in place for all devices with the plan of adding additional flyouts for desktops where the user has “hover”.
(this design has not been implemented yet)
“I want to have a clear understanding when I’m in the admin of where I am, how I got there, how to get back to where I started, and how to find what I need”
The biggest blocker to the user being able to orient themselves in Drupal has been a constant loss of context. Take the following example:
“As a site owner new to Drupal I want to add an image to the header of my site”
“I see a menu item at the top of my site that says ‘appearance’, images are part of the appearance, let me look there. Hm, themes, well I guess i’m in the wrong place, this lis for changing the whole site. Let’s try content. This shows content that’s already created, let’s try this ‘add content’ link. Hm, ‘article’, ‘basic page’, this doesn’t look like the place. How about ‘structure’? Ok, ‘blocks’, ‘content types’, ‘taxonomy’, ‘menus’. ‘Blocks’ maybe I can put an image in a block. Ok, ‘add block’. ‘Title’, ‘Description’, ‘Body’, doesn’t look like anywhere I can add an image. Maybe this is the wrong place. Let’s try configuration. Here’s something. ‘Image styles’, no, let’s try ‘image toolkit’, ‘Image toolkit is installed and working properly’. good to know. But where do I go to use it, ‘Configuration’? Wait, am I in configure already? it’s not highlighted. What’s the breadcrumb say? Yes I’m in configuration. I think maybe ‘blocks’ was right, but was that under ‘Content’ or ‘structure’. Let me just try help. Ok there’s an image category. Hm, ‘image styles’ again, but how do I add an image? ‘Attaching images to content as fields”. That must be it.’...
The user here is doing what Jared Spool calls “pogo sticking”; returning over and over to the menu because they can’t find what they are looking for, they don’t know what category they are in, they don’t know how to go one level up, and they can’t remember what the categories contain.
When the entire menu is exposed to the user they can drill down without losing the context of the parent item, they can jump from parent to parent and see the children without a new page load and, if they drill down several levels deep then click a link the menu persists through the new page-load with an active trail. If this is not the page the user wanted the whole path they took is still visible.
(Incidentally the user story above can be accomplished in Wordpress in three clicks.)
“I expect the experience of using my site on touch devices to be similar to my experience of using other mobile sites i’m used to like facebook or twitter”
We used interaction patterns and visual affordances for mobile that are already becoming well established.
“As a site administrator I want to be able to jump quickly to a page I already know the location of without wading through menus”
We covered this with the “jump to” box (shown in the shortcuts design above)
“As a site administrator I want to be able to configure the administrative menu so that it fits my work process”
We are working on a horizontal version that will can be enabled on a per-user basis which would still responsively change to vertical on smaller devices.
“As a site administrator I want to be able to control what my content authors see in the administrative menu”
Drupal already covers this but we should spend some time making it easier to configure and providing an affordance for configuration right on the menu itself (not designed)
All participants in the tests saw significant improvement over the current toolbar and all saw the value of responsive design. Some of the feedback will be incorporated back into the designs right away such as:
- “Not enough affordance on the indentation of child items”
More space will be added to the left of the child container
- “Arrow affordance as a toggle to expand child items was not immediately discoverable”
Exploring other affordances/icons. A patch has already been posted on this and we are reviewing it.
- “edit shortcuts” was not discoverable. The new design above covers this.
The prototype can be viewed here: http://toolbar.qemistry.us/
And I have also made a video showing some of the interactions in more detail here: http://youtu.be/bVa5TqmnktI