[meta] Improve the navigation layout page

Created on 21 May 2024, about 1 month ago
Updated 22 May 2024, about 1 month ago

Problem/Motivation

Per agreement with @ckrine this meta issue is a collection of potential problems on the new navigation layout page moving from the block UI towards a layout builder based solution. The problems were raised in one part during 📌 Drupal Usability Meeting 2024-04-26 Active (attendees were: @benjifisher, @BlackBamboo, @rkoller, @SKAUGHT, @worldlinemine, recording: https://youtu.be/RlVJilPxNUA) and subsequently supplemented by my additional explorations and testing. The potential issues in the problem section are numbered; those raised during the usability meeting are labeled because they have already received a broader consensus. There are corresponding numbers in the proposed resolution section in case there is an already-existing issue or if there is an idea or suggestion how to tackle the problem. The whole meta issue is supposed to be mainly for evaluation purposes. As soon as there is an agreement on a problem a dedicated child issue should be created:

1. GENERAL
1.1 Lock-in on the Navigation blocks page (usability meeting)
By clicking the Navigation blocks menu item, you get right into an edit mode without any warning. The navigation is gone, replaced by a dysfunctional preview, a placeholder of the navigation sidebar, and the only regular way left exiting the page is the breadcrumb navigation. That way, the page is breaking with many expectations and assumptions by the user navigation-wise.

1.2 The site icon is hidden (usability meeting)
While being in edit mode on the navigation layout page the site icon gets hidden in case it is set and used. In addition, the icon functions as part of the navigation; hiding it is not an exact preview.

1.3 Discard changes
Clicking the Discard changes button breaks the "lock-in" on the confirmation step. The functional navigation sidebar is available to the user. Instead of confirming or canceling the user is able to use the navigation sidebar without limitations - all changes are getting discarded without confirmation. In case you click Save or Discard changes instead, you return to the lock-in state with the dysfunctional preview of the navigation sidebar.
The micro copy on the page of the confirmation step is suboptimal. It is wordy; it doesn't matter what tool, in the form of layout builder, the user is using here, nor is it necessary to explain at this point. The copy is talking about forms and links, in the context of the layout builder tool on this page these are abstract terms, which is sort of confusing. Technically speaking these forms and links are not even disabled when a user is reading this description, as mentioned before, the navigation sidebar is fully functional on the confirmation step.

1.4 A lot of screen real estate on the navigation blocks page stays unused
The layout and presentation is not ideal in the current form. There is a huge gap between the areas of attention on both ends of the screen; the bigger the display the more apparent and pressing this issue becomes. Out of the box you have the main content area with a help text and the preview of the navigation sidebar on the left end of the screen. It is not directly apparent that this is a dysfunctional preview instead of the previously functional navigational sidebar. If you try to add a block or click a contextual link for any of the added navigational blocks, the off-screen tray is shown on the other end of the screen on the right:

  • If you resize the window width around in the limits of the desktop viewport with the off-screen tray open, the tray isn't sticking to the right end of the screen, sometimes it even moves outside the visible viewport.
  • On smaller viewports (tested on an iPhone) the preview is collapsed per default and the "top bar" with the Expand sidebar button is underneath the Show content preview checkbox. If you click the Expand sidebar button the preview opens for a second or two and then immediately auto-collapses again. During the expanded state the menu item labels are not shown and only the icons are being displayed. It is not enough of time to either click the Add block button or any other contextual link. When testing on the desktop by narrowing down the browser window the expanded off-screen tray is right underneath the Expand sidebar button.
  • One of the most significant problems becomes apparent if you open the navigation layout page on a widescreen monitor (a 36" display in my case), you then have the preview on the left end of the screen and the off-screen tray on the right end of the screen. In between those two regions of interest you have the main "content" area containing help text, two buttons and a checkbox. A lot of screen real estate stays unused with not much functionality while the two sidebars, the areas of interest where all the "action" happens, are pushed to the margins. If you are applying the straw test (https://scottvinkle.me/blogs/work/proximity-and-zoom) these two areas of attention with the sidebars are not anywhere near in close-proximity, and it is nearly impossible for people with the condition simulated by the straw test to visually jump in between the two sidebars. For anyone else, it is a challenging task, manageable but still challenging.

1.5 [Regression] Impossible to set block visibility settings with Layout Builder
With the block UI the user had the ability to set block visibility settings for the different menu and navigation blocks. With the move to Layout Builder that option dropped out. But even with the “block UI”-based interface it would have been challenging to create different layouts for different sets of navigation and menu blocks per user roles.

1.6 Visual representation of draggable regions
For dragging a menu or navigation block you don't have to activate the Move option for a block in the context menu. You are able to directly drag and drop a block, but the visual affordance is not available, the only visual feedback is that the mouse cursor changes to the horizontal/vertical drag icon even though you are solely able to drag and drop vertically. Plus if the changing mouse cursor on hover is the only visual indication for the “movability” that could easily be missed by the user.

1.7 Drag and Drop of menu/navigation blocks is not working across browsers
Firefox works, while Safari and Edge are not working.

1.8 Region labels are only shown when the move mode is active for a block (usability meeting)
At the moment region labels are solely shown when the Move mode for a menu or navigation block gets activated. The rest of the time the user only sees the blueish dotted lines. It is not necessarily clear what those blueish dotted lines stand for.

1.9 Redundant and verbose micro copy for the h1 inconsistent with the menu item (usability meeting)
The h1 contains the term layout twice, which is sort of redundant. On the other hand the menu item for the page as well as its description refer to Navigation blocks instead of Navigation layout.

2. ADDING
2.1 Add button (usability meeting)
Currently there is a single Add block button within the content region. There are three different perspectives to mind.
First you have the sighted user using the mouse. Based on the location one might assume that adding a block is exclusive for the content region.
When a keyboard user gets to the page, they first tab by the Skip to main content link, past the breadcrumb, then the Add default shortcut, then the Save button, then the Discard changes button, then the Show content preview checkbox, then the three context icons for each navigation block in the sidebar and then they finally reach the Add block button. Same as sighted mouse users they might be under the impression a block can only be added to the content region on top.
A screenreader user can confirm that assumption, the aural interface announces a link called Add block in section 1, content region. That information is only communicated implicitly visually and it is not clear what Section 1 refers to or what it actually implies? It looks like all default regions belong to the same Section 1. To add a block to the footer region a sighted or screenreader keyboard user first has to add a block to the content region, activate the block's Move action and finally change the region in the select field - a cumbersome process overall.

2.2 No indication how many times a nav/menu block was already being added
If you are adding a new block there is no indication in the off-screen tray if and in case how many times a block was already being added to the navigation layout.

2.3 Group labels (usability meeting)
The group labels are single words and missing sort of a context. In case someone with a small working forgets the off-screen tray title or someone else barley scanning, the context might be either missed or one has to recheck the title for reassurance, instead of having the context (blocks) in place. In addition the form of the two group labels is inconsistent, menus is in a plural form while navigation is in the singular form.

2.4 Group label rows are missing toggle icons
Currently the toggle icons signifying that block groups can be collapsed and expanded in the off-screen tray are missing. That way the block group bars are in lack of affordance. This fact is even more relevant on the configuration step when a block is being added, where the Menu levels group is collapsed by default and the available settings are hidden.

2.5 Difference between User and User account menu is unclear
You have the User block in the Navigation group and the User account menu block within the Menus group. Based on the labels it is not clear what their difference is and why there are two different blocks in two different categories with similar names. In addition it is not self explanatory what the difference between navigation blocks and menu blocks actually is and in case that difference matters to a certain degree.

2.6 Adding a second shortcuts block has different title
The title of the Navigation shortcuts navigation block added per default is Shortcuts. The title when another Navigation shortcuts navigation block is added, is Navigation shortcuts. So one block is called Shortcuts the other Navigation shortcuts, even though they are identical which might potentially confuse people.

2.7 Create content block (usability meeting)
The Create content block button is completely misplaced in the off-screen tray. It is creating an actual content block, the purpose of this step is about adding one of the already existing menu or navigation blocks instead.

3. CONFIGURING
3.1 There are two competing titles
First you have the total unspecific title Configure block in the headline and then another title Block description Main navigation where the information, the user is most interest in, is appended at the end. The user has to scan both lines to get and process all the necessary information, the cognitive load is high.

3.2 Description for menu levels is hard to understand
The point of reference for the menu levels is hard to comprehend. It is referred to that the menu is only visible if the menu link for the current page is at this level or below it. With a numeric scale in place my first association for "below 2" would be 1, 0, -1 or -2, but below means into the opposite direction by counting up.

4. MOVE
4.1 Remove "the" from the title

4.2 Clarify the purpose of the region select list
It might make sense to clarify the purpose of the region select list with a short description. Otherwise it might be potentially confusing in terms of point 4.3

4.3 Section 1 is redundant and front loaded
Section 1 is the label of the optgroup within the region select list and in addition for each available option Section 1 is front loaded. That is redundant and as already mentioned in 2.1 it is not clear what Section 1 refers and stands for. Does a Section 2 exist at all?

4.4 Section title Block label seems unspecific and imprecise
This setting is about the order of navigation and menu blocks within a certain region instead of the order of block labels.

4.5 Drag icon not inline and horizontal/vertical drag icons
The drag icons are horizontal/vertical drag icons even though the use is solely able to sort blocks vertically but not horizontally. The mouse cursor sticks to the pointer on hover instead of switching to the drag icon (ref Differentiate visually dragging with and without hierarchy Needs work ). And the drag icons are stacked onto the block labels instead of being displayed inline.

4.6 How to recognize the current block
In the off-screen tray, to recognize the current block you have to read/scan until (current) which is appended at the end of one of the block labels. There are no additional visual cues helping to distinguish the current block. The users only chance is to read/scan the list of all available labels. Plus the corresponding preview in the navigation sidebar has a way too strong black rectangle which is sort of an attention magnet.

5. REMOVE
The confirmation dialog might even go unnoticed. The user is triggering the removal of a navigation block in the contextual menu of one navigation block and has then to look across the entire screen to first notice and then reach the upper right corner of the window (also see point 1.4). The confirmation is not even in close spatial proximity nor would me as a user expect a confirmation dialog within the off-screen tray.

6. ACCESSIBILITY IN GENERAL
6.1 Quick edit buttons have a too low color contrast
Quick edit buttons are failing WCAG SC1.4.11. Hovering the block, the circle and the pencil both failing to reach a color contrast of 3:1, hovering the quick edit button itself, fails to reach the color contrast of 3:1 for the circle but the pencil reaches the required contrast. But that is a problem for core in general.

6.2 Add block button has a too low color contrast
The blueish background of the Add block button fails WCAG SC1.4.11. The button background is EEF6FC against FFFFFF which leads to a color contrast of 1.1:1. And the button itself is missing a change of color on hover and when active aka with a pressed mouse button.

6.3 Show content preview checkbox redundant and too verbose
Ticking or unticking the Show content preview button repeats "block previews are hidden block labels are visible" x number of times in a row in voiceover in macOS.

6.4 Aural interface for the navigation sidebar is challenging depending on if the preview is active or not.

6.4.1 Show content preview unticked
The only elements available in the AOM and the tabindex are the four quick edit buttons and the Add block button. Problem is that out of the box the output for the four quick edit buttons is for example:

open shortcuts configuration options, toggle button
open configuration option toggle button
open configuration option toggle button
open configuration option toggle button

The Add block “button” on the other hand is just a link.

6.4.2 Show content preview ticked
Same as 6.4.1 the four quick edit buttons and the Add block button are available in the tab-index, but with the preview of the navigation sidebar active all the top level menu items are available in the AOM alongside. In consequence if you open the rotor in VoiceOver you are able to go to the form control of for example Extend structure collapsed button, pressing the return button and you are able to expand the drawer for a second (but it collapses immediately right after). So technically all the top level menu items are available to a certain degree to screenreader users in the preview mode.

6.5 Landmark region labels are not necessarily clear
You have two complementary regions, one for the help text within the main landmark and the other wrapping the navigation sidebar, no matter if preview is active or not. The off-screen tray has no landmark region at all.

Steps to reproduce

Proposed resolution

1.1: @SKAUGHT is actively working on 🐛 Enhance Navigation admin workflow with Managed Tabs. Needs review

1.2: Not being hidden, the logo might function as another loophole to escape the lock-in alongside being a more exact preview of the navigation sidebar. Problem is that all links within the preview are disabled and the logo belongs to the preview.

1.3: The micro copy should be about informing the user that one is in the process of discarding recent changes to the set of navigation and menu blocks, not about the "layout builder tool" itself. The sidebar shouldn’t switch back to the full functional version.

1.4 & 1.5: One rough idea might be the following, when Add visibility control conditions to blocks within Layout Builder Needs work gets in have a list table on the navigation layout page listing the different navigation layouts, for example one for administration roles and one for content editors. The navigation sidebar would be fully functional on that page. When you add or edit a layout the sidebar switches into the preview mode. That way it would be clear that the sidebar would be a preview then and on save the user would return onto the layout overview page with the full functional navigation sidebar. While editing or adding a layout one idea might be to move the off-screen tray right next to preview (not sure if that is possible or intended but it would avoid the huge cognitively challenging gap in-between the two sidebars).

1.6: Add styling for a navigation block on hover and use the vertical drag icon instead of the vertical/horizontal drag (see Differentiate visually dragging with and without hierarchy Needs work )

1.8: Having the region labels shown all the time, the inherent structure within the sidebar would be clear and no matter if the content preview option is active it would be clear that the sidebar is a dysfunctional preview.

1.9: The suggestion here depends on the outcomes on 🐛 Enhance Navigation admin workflow with Managed Tabs. Needs review

2.1: During the usability meeting we’ve thought it would be a good idea to add an add button for every navigation region. But the probably cleaner approach might be to move the Add block outside the sidebar preview into the main content area. On the first step of adding a new block, add a select field to the off-screen tray letting the user select the region the block is being added to.

2.2: One approach might be adding a confirmation step asking the user something like are you sure you want to add the content block another time. The block is already used x number of times.

2.3: Change the group labels to Menu blocks and Navigation blocks

2.4: Display the toggle icons again

2.6: Rename the default title for the second added block from Navigation shortcuts to Shortcuts

2.7: Remove the Create content block button from the Add block flow in the off-screen tray

3.1: Remove the "sub title" Block description Main navigation and move it to the top bar front-loading the title changing it from Configure block to Configure administration block description

4.1: Strike "the" and simply use Move [title] block

4.5: Use the new icon for vertical dragging instead of the horizontal/vertical currently used (see Differentiate visually dragging with and without hierarchy Needs work ) and make the icon inline instead of block display. Plus change the mouse cursor on hover to it as well.

5: I wonder if the confirmation step for removing a block should be displayed in the main content area instead of displaying it inside the off-screen tray?

6.1: 🐛 The toggle that makes Contextual Links visible at all times might not be sufficiently discoverable Active

6.2: Increase the background color of the button in contrast to the white background to at least 3:1 as well as add color variations on hover and when active that satisfies at least a color contrast of 3:1.

6.3: Avoid the repetitive announcement of "block previews are hidden block labels are visible" x-number of times.

6.4: In each case either with the preview hidden or the preview shown it would be important to add a context aka adding the title of the block to the quick edit toggle button. For screenreader users there is also the question if the preview functionality brings any additional benefit. Would a screenreader user inspect all the available top level menu items or not? In case they would it might be an idea to add something like the aria-disabled attribute to every top level menu item?

6.5: The landmark region for the help text might be dropped since that help text is contained within the main content area already. The complementary role might be considered to be added for the off-screen tray. To the aside element the preview is wrapped in an aria-label or aria-labeledby could be added with the label Navigation preview that is getting announced as Navigation preview complementary.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component
Navigation 

Last updated 2 days ago

No maintainer
Created by

🇩🇪Germany rkoller Nürnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Comments & Activities

Production build 0.69.0 2024