Navigation interaction explorations

[draganescu]

I would like to suggest that we simplify the way the navigation block works today by doing away with a few things from its current functionality:

1. Give up on the block list appender - it is of low use in such a constrained form. If the navigation will allow group blocks that allow us design canvases, in there the appender makes sense. But inside the list of links which is the default navigation, it is more trouble than worth.
2. Give up on the contextual link editing and instead do the link editing in a toolbar dropdown
3. Give up on the in-toolbar editing, by using (2) instead.

I made a few low-fi mock-ups to exemplify what I mean:

• we would add two new buttons to the toolbar: one to add a navigation item, one to remove the current navigation item
• the third action is the link symbol which is basically the edit navigation item action
• adding results in an initial list of item types (post, page, external, tag, submenu etc.). If the list should grow a lot, we could add a filtering way.
• once the type is selected, the result depends on the type. All link types (post, tag, category, page, external) will show in the dropdown the normal link popover content with the URL input and suggestions.

• adding a submenu item would need it's own entry in the list of items that the Add icon shows. It's probably a good idea to have it as a separate icon, but I also thing that lumping it along with all the other kinds of navigation items one could add is a better thing for discoverability
• a submenu item does not add new kind of block, instead it simply opens the link selection with URL in it and suggestions, unfiltered.

• editing a link would be done by opening a dropdown with the link popover in it (URL input plus suggestions). No need for in toolbar editing.
• we would have a separate toolbar button for link settings such as open in new tab or "rel"

• currently it's unclear how to delete a link. It would be the same route as removing a block, but it's a bit hidden, so I suggest we'd add a remove button that removes the currently active navigation item.

---

• we could combine add and remove to save toolbar space

These mock-ups don't contain the other navigation buttons they should like:

• block alignment
• navigation item alignment
• list view

They should remain there.

[karmatosed]

There are some interesting thoughts to dive into here. I wanted to cover them along with what came up as I read through.

This block because of the complexities both exposes and has potential to solve for other complex blocks. This is something to think about when considering it and never consider in isolation, or at least that's the way I tend to come back to thinking about this block.

One thing that strikes me with bringing the actions to the toolbar is concern that the problem isn't just being moved somewhere, over being solved. To explain that a little, there is an established interaction pattern right now in the editor of where you add or don't add something. Similarly, over time the toolbar has simplified to essential context, over being a place for everything, this feels like a step back to using it to solve problems perhaps should be explored elsewhere in the interface.

This all said, it's exposing for me a fundamental problem of flow that needs considering before jumping into the 'how'. Past solutions for navigation I think done by many of us have been trying to tackle the 'how' before the flow and almost going against the existing patterns. From adding line, to adding in the block navigator, to modifying a new way of doing things - these are all covering the problem over, rather than solving.

That's a grand statement, but until the flow of adding and going into depths within a block are solved, this block will always be trying to get around the problem to various degrees of success.

Some points I think are worth continuing to explore, aside from my advise this isn't the only path explored:

• Adding a clear way to delete.
• Adapting the toolbar: There is some crossover here with the alignment work in Iterations on "Absorb Toolbar" mechanisms #26313.

I think it's important to go back to what someone expects to do when adding a block and see how simple this interface could be. Each iteration feels like it's getting more complex and more confusing as new or different interpretations to the UI are added. Maybe some questions can lead into the next step of exploration:

• How could existing patterns be used, refined and polished to draw on?
• What does someone expect as they are creating and building this block? What is their journey of expectations for the interface?
• Do we have any information right now, any data on what is or isn't working? This might be from other blocks like social links for example.
• Over adding a new way to add links, how can the existing link interface be improved?

[jasmussen]

My instinct here is that the appender, regardless of its overlap and lingering behavior, is not the most urgent source of the usability issues with the navigation block, and that the approach outlined here isn't going to work well for other blocks such as Social Links or Buttons, making this a great deal of complexity written just for one block.

The appender is problematic in horizontal situations because of overlap and jumpiness. But this needs to be looked at holistically, like Shaun is doing in #26946.

I have a great deal of faith that we can make a pretty substantial impact on the navigation block with two things primarily:

1. Improving the setup state, which Marcus and I are looking at in Update Navigation block placeholder #27018 (comment).
2. Building the "Pages" block that Shaun outlined in New "Pages" Block: Display a list of links to a site's pages #23689

Combined, you can in a few clicks have a navigation that stays in sync with new pages being added, and doesn't need to be edited unless you really intend to, making the appender interaction more of an edgecase situation.

[draganescu]

Cool friends, thanks for the feedback! I'll close this as it gathered what it needed.