Navigation Block: Design Pivot

[mapk]

As noted in the older Nav block issue, a discussion between @sarahmonster, @melchoyce, @karmatosed, @mtias and myself, lead to a few design pivots on this block. They are outlined below and will be edited with individual issues once each has been created.

Native block patterns #16974

• Use existing block patterns whenever possible (ie. the block toolbar).

Refinements #17093

• Refine the horizontally aligned inner blocks.
  • Explore how this pattern can extend to other blocks like button, columns, etc.
• Improve how child blocks perform in narrow spaces.

Adding a new block & Block Library #16659

• The add block icon + should add an inner block with one click.
  • The inner block can then be defined as to whether it's a category, page, post, etc.
• Explore how the Nav block works when added to the page.
  • Does it default to the primary menu?
  • Does it offer an empty state for creating new Navs?
    • Are there helper messages?
    • Tips?
    • Place holders?

Nesting blocks

• Moving into/out of nested areas.
• Data tree structure: Navigation Block: Data View  #16812
• (idea) Possible drag and drop interactions similar to Reordering of blocks inside block navigation #11408
• (idea) Possible document outline repositioning? Enhance the tools for selecting child/parent blocks #9628 (comment)

URL and permalink structure #17204

• First iteration should offer a link in sidebar to the permalink page.
• Any changes in the settings should reflect in the Nav block.

Customize options #16830

• Backgrounds (possible Group block)
• Link colors
• Font sizes
• Background colors/gradients for dropdowns
• Current menu item color/background options

Backward compatibility #16659

• When editing a Nav block that was created from existing wp-admin menu screen, should this action create a new menu?
  • Allow for manual conversion.

[mtias]

The biggest architectural change is #16810

[draganescu]

@mapk I think that the biggest challenge for the interaction design of the navigation menu is that:

• making a menu and navigating the menu are two different modes
• and we're trying to make the navigation block as mode less as the rest of the core blocks

I would love us exploring an UX where the selected block shows the edit mode and the un-selected state shows the navigation mode, but in a way that the difference between the two is obvious.

As I explored here, and as @mtias suggested as well, using the tree view of the block navigator as a central menu editing mode (not semi mode, in the sidebar/block inspector) opens up the possibility for a frictionless interaction while creating the menu.

I am advocating this mode based approach also because the cost of changing modes is so small, client side rendering allows for instant preview of results.

Moreover, block styles in the case of the navigation block can mean a pack of features, all of which affect only the navigation mode: colors, fonts, animations and orientation! In all cases, indifferent of the style of the block the edit mode is the same, with a clear tree indicating what the menu contains.

It is so hard, for me at least, to escape this paradigm of "editing mode" because when one is building a hierarchy you need to represent at the same time the content, relationships between the contents and the relationship of each content item to other parts of the system. All this provokes clutter and adds to a clumsy navigation mode, both visually and to what concerns interactivity.

Other parts of Gutenberg already have semi modes baked in, the sidebar is one where some actions are done in steps (publish) and also the new hiding of the appender in groups when the group is not selected are two examples.

[karmatosed]

@draganescu I am going to link your comment to the discussion of various mocks as don't want it to get lost out here when discussion is happening elsewhere. #16974

[karmatosed]

I am going to link all the navigation issues here so we can try and keep record:

• Navigation menu block: Reuse existing design patterns for menu item controls: Navigation menu block: Reuse existing design patterns for menu item controls #16974
• Navigation menu block: Explore horizontal move controls: Navigation menu block: Explore horizontal move controls #17093
• Navigation menu block: Revisit placeholder/default state: Navigation menu block: Revisit placeholder/default state #17096
• Navigation menu block: Refine how users add new menu items: Navigation menu block: Refine how users add new menu items #17116
• Navigation menu block: URL & permalink structure: Navigation menu block: URL & permalink structure #17204:

[mrcn]

I am going to link all the navigation issues here so we can try and keep record:

• Navigation menu block: Reuse existing design patterns for menu item controls: Navigation menu block: Reuse existing design patterns for menu item controls #16974
• Navigation menu block: Explore horizontal move controls: Navigation menu block: Explore horizontal move controls #17093
• Navigation menu block: Revisit placeholder/default state: Navigation menu block: Revisit placeholder/default state #17096
• Navigation menu block: Refine how users add new menu items: Navigation menu block: Refine how users add new menu items #17116
• Navigation menu block: URL & permalink structure: Navigation menu block: URL & permalink structure #17204:

How about

• Navigation Block: Add support for style customizations: Navigation Block: Future navigation block customization improvements. #16830

[sarahmonster]

Following a discussion in Slack today (Note: You may need a Slack account to log in.), we've made some progress in determining next steps here and action items, although we didn't have time to discuss everything.

Here are my notes!

Constraints to keep in mind

From @mtias:

1. Use already established patterns and improve upon theme generally (child blocks, toolbar, movers).
2. Recognize menus have different degrees of complexity (simple few pages navigation to huge site structures with nested trees).
3. Make the block dynamic (handle changes in permalink structure, domain, slug updates) and handle the UX that comes with it.
4. Be able to import from existing menus (not retroactively update them).
5. Include customization options (style variations, color, size).

What we need from design

From @mtias:

• Establishing what goes in the toolbar and how horizontal movers are presented.
• Designing the contents of each child block (this is the most substantial design task, as it includes the searching interface, the direct editing, and the page listing). Where are we on this?
• A design that uses block navigator for structure as an additional editing interface. I think this will allow us to keep main editing “simple”, and handle complex tress in a modal.

Horizontal move controls

Mockups for this already exist here: #17093.

It seems from discussion none of the options presented are good to work from. We don't necessarily want to use the existing move controls, and should try instead introducing a completely new pattern for horizontal move controls, rather than using the existing move controls.

Solution: We agreed to work from this mockup:
https://files.slack.com/files-pri/T024MFP4J-FMH07V3QB/image.png
https://files.slack.com/files-pri/T024MFP4J-FMTVAN1GC/image.png

and iterate directly in code.

If that doesn't work and we need to go back to the drawing board, here are some suggestions that were given:

• Put controls into the ellipsis menu.
• Put controls in the toolbar.
• Put controls inside of the block itself (inline).

I’ve closed the issue exploring these to reflect this new course of action.

Navigator mode

This is basically two things:
Making the navigator mode more flexible, so it can be used to reorder items. This is being worked on already in #11408
Bringing the navigator mode to the navigation block, so it can be used as a secondary interface for rearranging and manipulating complex blocks.

Action items:
@mapk will leave feedback on #11408.
@andrei will code a prototype following @matias’ mockup, showing the navigator in the navigation menu block

Adding new menu items

Designing the contents of each child block (this is the most substantial design task, as it includes the searching interface, the direct editing, and the page listing). Where are we on this?

See #17116, which is currently blocked due to unclear requirements. If we’d like more explorations here, we’ll need to clarify what we’re looking for, but it looks like we may not need to explore further.

@karmatosed and @matias shared some mockups on #16974 that may be more in line with what we’re looking for than our original designs. Can we move forward with these designs and iterate in development?

Next steps

Beyond the action items identified above, is there anything else that we need from design at this stage?

[noisysocks]

Let's turn our attention towards shipping a v1 of the Navigation block. I've summarised the remaining developer tasks remaining over in #17544