Prototype revision on the the Friday Usability meeting

The recording of the pilot user test that was run during 📌 Drupal Usability Meeting 2023-11-17 Needs work could be watched at https://www.youtube.com/watch?v=4IcfL2y_WLk . After the meeting there was also a discussion in a huddle (https://drupal.slack.com/archives/C1AFW2ZPD/p1700236515722839) that was unfortunately not recorded. After the that huddle I've tested the Tugboat instance a bit more in depth and was trying to express my experience and potential stepping stone for me from a cognitive perspective. In the following the comments:

Intro:
I went ahead and compared the Tugboat state with the implementation Gin currently is at. One thing I’ve realized you’ve solved one detail that bugged me about Gin from the start, you were able to untwine the two level toolbar Drupal Core currently has in a more elegant manner. In Gin you have the Shortcuts, Devel and the link to the User page in the horizontal nav bar at the top which was sort of suboptimal context wise. In the Tugboat instance the Shortcuts and User page got moved to the vertical nav bar. Double thumbs up. In the following I try to articulate a few more things I’ve noticed while I played around some more with the Tugboat instance over the course of the last weekend and also compared it how Gin tackled these problems (some details were impossible to notice in the short test last Friday). In addition I’ve tried to explain my experience for the parts that were challenging for me and I’ve struggled with cognitively.

1. Vertical navbar

1.1 General visual representation of the horizontal and vertical nav bar.

One detail I haven’t really voiced nor was able to express on Friday is that in the Tugboat version the nav bar is sort of a visually dominant right angel. It surrounds the actual content of the page from two out of four sides (left and top). I’ve compared it to the current state of Gin. Sascha took a slightly different approach by making the horizontal top nav bar not with a solid white background but semi transparent instead. That way the two nav bars haven’t felt like a single UI element. It feels more that the horizontal nav bar belongs to the context of the current page while the vertical nav bar in solid white stands for the overall global context.
And the horizontal nav bar took interesting alternative take on the node edit form in Gin. It is placed there in-between the vertical nav bar on the left and the sidebar on the right. That also helps to make it less dominant and more context sensitive. Visually it fits better into the current page.

Question: One detail I wonder is how the vertical and horizontal nav bar behaves with the workspaces modules installed? Not sure if it would be ok and possible to install it on the Tugboat instance and if the installation gets rolled back when the instance gets paused? I don’t wanted to alter anything there. Or is the current state of the Tugboat instance a single experimental module or a collection of MRs? Cuz I wonder if it would be possible to get to the same state locally, then it would be easier to modify the install. That would make that kind of experimentation like installing modules and adding content easier.

1.2 Drupal icon and the hide/show icon on the node edit page

The Drupal icon in the upper left corner is in a solid lighter blue same as the hide/show toggle button in the horizontal nav bar in a strong dark black. Both buttons have a high affordance, stand out and draw the users attention, at least mine is always drawn back to those two each and every time - a source of distraction.

1.3 The font size

Another detail i haven’t voiced and went just over on Friday is the font size. With an expanded vertical nav bar the size was still legible but small enough that it took a certain amount of effort for me to process the text. I was just in a tunnel concentrated to solve the tasks (having that many pairs of eyes lay onto me and being in focus of everybody was an extra stress), therefore I had some extra energy for processing the nav bar labels and icons, but in the daily life, in particular when being stressed or being tired it might be a different story. The icons were on the brink of being too small to recognize their difference when the sidebar was collapsed. By just glossing over the icons I am only able to determine the type based on the position not by the actual icon shape. It is slightly too small. --admin-toolbar-font-size-s: is set to 0.875rem why not use 1rem like Gin? That way the sizing would be also more in line with the main content. At the moment it looks like the pages main content area has some sort of different “zoom level” compared to the horizontal and vertical sidebar icons their labels. Or will the general font size of the main content area get smaller with the upcoming design changes as well?

1.4 Indicate which menu items are expandable

Not sure if I mentioned it but after playing around with the current state a little longer I had to mention it again. In case I already did apologies. In the expanded state of the vertical nav bar it is sort of clear which menu items are expandable based on the chevrons. But as soon as the vertical nav bar gets collapsed it gets more complicated. I have a short working memory lately. With no visual cues by chevrons like in the expanded state you only have the icons to orient. Those are slightly too small (as mentioned in 1.3.) and in consequence hard to process and distinguish. That way it became a guessing game for me on which icon a widget with the child menu items will show up on hover and where not. An interesting detail when I focus on the icons moving my mouse cursor vertically down the different icons I only noticed when a toolbar popover with sub menu items gets shown on hover. That the other icons with no popover had a label with a dark background showing up I was unable to realize for 2 or 3 days testing - cognitively I haven’t recognized nor processed them. But i am not sure if there would be a way to illustrate menu items in the collapsed state that contain child menu items without the need of going through all the icons hovering?

1.5 Create section

@ckrina mentioned the problem of sites having not just 6 different entity types to choose from but 20 or 40+ which wouldn’t work in a single column for the vertical nav bar. One way to approach this might be twofold.
If I remember correctly there were some discussions about the type_tray module ( https://www.drupal.org/project/type_tray → ) in the context of the nav bar? I think it might help with the problem of those overview pages like “/node/add” where you currently only have a title and a description. To process that page right now the only way is to read them, there is no visual cue to orient. type_tray solved that at least for nodes so far. I don’t think it would be worth breaking the pattern for the vertical nav bar of parent menu items being just toggle buttons. But instead one option might be to add a menu item at the top or the bottom of the “Create” list forwarding to such an overview page with all available entity types you are able to create content for there. That page might be also used to choose the 6 to 10 types that are shown in the vertical nav bar (not sure about the exact number possible).
For the vertical nav bar itself you have a plain homogenous short list of entity types to create. But the list is still sort of hard to process since the list of available entity types to create spans across content types, media types, and users. For someone less technical and or less familiar with Drupal that might be challenging and again it still puts a cognitive load on the user. What does recipe mean, what entity type is it in? Is it a content type, a block type, a media type? An option might be to add sub menu items for content, blocks, images, media , users and what ever other type is available and collect the different subtypes underneath as child’s. And for each sub menu item you could also add a menu item to corresponding the type tray of that subtype?

1.6 Blocks missing

A top level menu item for blocks is missing as well as a child menu item in the “Creation” top level menu item for blocks. That is sort of confusing when you visit either Content, Files or Media and notice a “Blocks” tab there but .

1.7 Tab order and keyboard navigation

In general the keyboard navigation looks good. The only potential problem I see is in the context of SC 2.4.7 because the focus is not always visible. and there is also the question of the order in general. In Tugboat the order is:
1.7.A (Tugboat)

1. Skip to main content
2. (not visible on tab ref SC 2.4.7)
3. Preview
4. Save
5. More options
6. Hide/show toggle (in the expanded state it is ok but still challenging to recognize the color contrast with the green outline around darkish black)
7. Drupal icon (the outline is close to invisible with green around the lighter blue ref SC 2.4.7)
8. Shortcut

1.7.B (Gin)

1. Skip to main content
2. Drupal icon (the outline is close to invisible with green around lighter blue)
3. Tools

The question is wouldn’t the following approach be desirable for Claro instead of keeping the order like outlined in 1.7.A . After you reach “Skip to main content” with your initial press of the tab key you get to the vertical nav bar like Gin does in 1.7.B instead of getting to the horizontal nav bar. While if you press return on “Skip to main content” you get to the main content. But if you skipped to the main content the question is where to place the horizontal sidebar in the DOM. At the moment the rough tabbing order on the node edit form page with a expanded sidebar is.

1. Horizontal navbar
2. Vertical navbar
3. Expanded sidebar
4. Main content

With the save, preview and delete buttons potentially getting removed at the bottom of the node edit form and moved to the horizontal nav bar the decision on the order becomes even more relevant. If someone is using the keyboard but not a screen reader the taks of saving a node might become cumbersome and or complicated?
One option to tackle that might be to add a “Skip to list of available actions” link after the last element of the node edit form that directs the user back up to the list of available actions. That way the actions would be one extra key press away as if the buttons would be still there at the bottom of the form. Directly available to keyboard only users.

Question: Would it make sense to ping Camille Davis if she would have time and interest to chime in on the general keyboard accessibility topic for the nav bar. She provided great input on the admin_toolbar end (for example https://www.drupal.org/project/admin_toolbar/issues/3286466 ✨ Tabbing order does not satisfy 508 accessibility requirements Needs review ) and I imagine she might be also helpful here? Perhaps also as a participant in a user test?

1.8 Windows high contrast mode

The icons are invisible in the expanded as well as collapsed state. The blue dot signifying the active page in case you are on a sub menu item page is also invisible. But one detail I have to note even it is just communicated by color but in high contrast mode the navigation is way more clear because you know white means there is no link behind and it is just a toggle button while yellow communicates this is a link. From a a design perspective that would definitively not work in general but I just wanted to noted that such a cue helped immensely to remove a certain constant uncertainty while using the vertical nav bar.

2. Contextual horizontal nav bar

Aside 1.1 and 1.7 there are few observations about the horizontal nav bar:

2.1 Go back to site button label

The word “go” might be striked to make the micro copy shorter. It is slightly shorter and the core task of going back is front-loaded es well. Same for the “Go back to Administration” link.

Question: Is it the expected behavior that “Go back to Site” points to the front page while “Go back to Administration” points to /admin/content. We had a discussion at a local meetup today and someone said currently the destination seems context sensitive in some cases but he was unable to spot a pattern. (I don’t use the go back to site at all personally therefore I ask)

2.2 Open/close toggle button

Is it intentionally that the padding of the horizontal nav bar is larger than the padding of the expanded sidebar underneath? That way the open/close toggle is not aligned with the “Revision log message” and “URL alias” field.

2.3 The structure and function of the horizontal nav bar

The question is if “How the horizontal nav bar on top functions and behaves” is predictable? Me as a user regularly had a challenging time using it over the weekend. First a few examples what is displayed inside the bar in different contexts (always a good way to spot patterns):
/en/node/add/page

1. 1. Go back to Site
2. 2. Breadcrumb (“Add content” - clickable link)
3. 3. Preview-button
4. 4. Save-button
5. 5. Hide/show toggle button

=> If you click “Article” in the sidebar in the create section first, then you change your mind and click “Basic page” and then change it another time to “Recipe”, each time the clicked active content type is on top of the list aka the order changes. If you have a fixed list of entities to choose from I am rather confused as a user and have to reorient if i assume the position is consistent across pages. Plus if you click “Image”, that is not going to the top of the list. Same as “Image”, “Document” or “User”. If you get the positioning into your muscle memory the moving of the current page to the for the content types can be potentially distracting. For media items (Image and Document) that behavior doesn’t happen.
/en/media/add/image

1. 1. Go back to Site
2. 2. Breadcrumb (“Add media item” - clickable link)

/en/admin/people/create

1. 1. Go back to Site
2. 2. Breadcrumb (“Administration > People” - clickable links)

/admin/content

1. 1. Go back to site
2. 2. Breadcrumb (“Administration” - clickable link )
3. 3. Add content

/node/20/edit

1. 1. Go back to site
2. 2. Edit About us (plain text - none clickable link)
3. 3. Preview (also a button at the end of the form)
4. 4. Save (also a button at the end of the form - “(this translation)” isn’t appended for the nav bar label)
5. 5. More options

• Latest version
• Layout (primary tab moved into the horizontal nav bar)
• View (primary tab moved into the horizontal nav bar)
• Edit (primary tab moved into the horizontal nav bar)
• Delete (also button at the end of the form)
• Revisions (primary tab moved into the horizontal nav bar)
• Translate (primary tab moved into the horizontal nav bar)