Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation menu block: Reuse existing design patterns for menu item controls #16974

Open
sarahmonster opened this issue Aug 8, 2019 · 9 comments

Comments

@sarahmonster
Copy link
Member

commented Aug 8, 2019

From #16821:

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

Exploring the problem

Problem:

Introducing a new pattern just for the navigation menu item block controls forces users to learn a new pattern that isn't reusable elsewhere, potentially leading to confusion.

How we determine if the solution has succeeded:

@mtias @mapk @karmatosed How did you want to select the best solution here? Ideas:

  • A/B compare usability tests with original designs
  • Take a group consensus / dot voting
  • Determine a decider responsible for selecting the best path forward

Potential roadblocks:

Whatever we land on needs to allow for vertical and horizontal rearranging in a relatively small space. (This will be explored in more depth next, but it's worth keeping in mind here since it will impact things here.)

We also don't want to lose all the work we did in the accessibility walkthroughs. How do we allow keyboard and screen reader users to easily move elements without drag-and-drop?

Original controls

Original designs

A refresher on the original designs we landed on. These tested well with users but represent a new pattern for users to learn, since they use custom controls.

Gallery style controls

Gallery-style

Following the inner-block pattern used here by the gallery block allows us to keep things a bit more visually simple whilst still avoiding introduction of a new pattern.

This allows us to also extend these changes to the gallery block, should galleries need more advanced controls. We can use a custom ellipsis dropdown for advanced move controls, and move the simple (back/forward) move controls directly into the block controls, keeping things more streamlined.

Technically, the gallery isn't a good example to copy—we aren't providing controls for a block, but rather an item inside a block. But this is a technical distinction. Do users know or care about this distinction? Is it important to their understanding and mental model of how the system works?

The Block Toolbar

Blocks-style

This was modelled after the columns block, which uses blocks inside blocks. The columns block is sort of notoriously hard to use (I keep getting the + icon jumping all around and all over the place whilst trying to use it.) I'm a bit concerned this may become extremely difficult to work with when we'll have a whole lot of pretty small blocks closely aligned.

Can we add anything to the ellipsis menu if we follow this approach? Do we need an extra flyout to represent advanced move controls? Do we need to drop advanced move controls, or move them to a sidebar, neither of which feels like a super accessible solution.

@mapk

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2019

Thanks for breaking this out, @sarahmonster! I really dig the explorations.

Right off the bat, I'm immediately pulled to the Block Toolbar option. The familiar pattern of blocks within blocks just works for me here. I also imagine it would be helpful to see the dotted borders of the parent/nested blocks as worked on here: #14961

The columns block is sort of notoriously hard to use (I keep getting the + icon jumping all around and all over the place whilst trying to use it.) I'm a bit concerned this may become extremely difficult to work with when we'll have a whole lot

This sounds like a great opportunity to figure out within the context of the Nav block and extend to the Columns block.

I'm a bit concerned this may become extremely difficult to work with when we'll have a whole lot of pretty small blocks closely aligned.

Great point. If several of the nav items are 4 letters long, this could be lots of small blocks. Do we use flexbox to equally spread them regardless of the length of word? Should we allow the unselected inner block to size down to the word, while the selected inner block expands to allow editing? I don't like that latter option, but raised it anyways.

Can we add anything to the ellipsis menu if we follow this approach?

I'd say, "yes". I figure you're asking this because of the options like Move right, Move left, and Move to start?

Do we need an extra flyout to represent advanced move controls?

Probably not if they work well within the ellipses dropdown.

@mtias

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

Thanks for presenting the three options.

Technically, the gallery isn't a good example to copy—we aren't providing controls for a block, but rather an item inside a block. But this is a technical distinction. Do users know or care about this distinction?

I think we'll get to a point where we can have child blocks for each gallery item, which will bring a few consistent interactions for free — like drag and drop to reorder, individual control over an image link, etc.

I'll follow up with some mockups of my own for the third option (block toolbar).

@mtias

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2019

The main reasons for following standard block patterns are both familiarity to users but also that it would force us to solve design problems more systematically. If narrow nested contexts are suffering interaction wise, we can solve that generally and improve the experience of not just our core blocks but any 3rd party blocks.

This can be reflected already in some general concerns:

  • Allow inserting child blocks directly if the parent block only supports one. (See #16659.)
  • Allow horizontal movers for non-vertical inner block layouts. (#16637.)
  • Simplify toolbar handling in narrow containers.

One idea I have for simplifying toolbar handling in nested contexts is to optionally allow an inner block container to say that it wants to absorb the toolbar of all the children. In those cases, selecting a child block within that area would change the toolbar content but it would be positioned at the level of the parent. This could be really useful for the navigation menu block, as selecting different items would remain coherent while offering specific tools for the right contexts. cc @jasmussen


Navigation Block

The main block is the Navigation block. It defines the menu area and contains all the menu items. This is already the case in all previous presentations, so let's dive into some of the details.

image

A crucial aspect here is that I think we need to make the block navigator front and center as a viable interaction pattern for this block, as with complicated nested structures it might offer the best and most clear organization. Particularly relevant would be implementing #11408.

The other aspect is that this block needs to be dynamic. (#16810.)

To discuss:

  • Should vertical / horizontal be a property or a block transformation? (I lean on the latter due to complexity.) (See #16829.)
  • Do we want to keep the concept of a "named menu" so that you can insert the same menu in multiple places or is this something that perfectly fits under the "reusable block" paradigm and we should use that instead?
  • How many distinct navigation design presentations do we want to support that we can handle through customization options? (Link color, hover, focus, background for individual items, border radius, current item styling, dropdowns and flyouts, etc.) This can get very large quickly, but the more we can absorb in the top level block, the better.
  • How best to present the option of "List all of my pages"? The "Main" dropdown menu could include that option in my example above, and it can also be placed in the block inspector.
  • The block inspector should have an "import from existing menu" flow for transforming older menus to block based menus.

Link (Child Block)

The only child block allowed under Navigation is the Link block (or Menu Item). It is inserted automatically when pressing the +. (This could be revised if we want to allow the Search block to exist here, for example, or Social Icons.)

One thing I'm interested here is evaluating if a Link block can be something we make available in general to be inserted anywhere. The main aspect is that it keeps a tight relationship with a site property (unless link is custom), so that updates to a site domain, permalink structure, etc, would naturally work.

image

The main interactions here would be adding a new item (expose existing pages, posts, categories, etc) and editing an existing one. The text label should be directly editable always. The relationship to an existing site property (a page, a post, a category view, etc) should be made extremely clear to the user as well, either in the toolbar, the inspector, or both.

To discuss:

  • The movers are placed within the toolbar but I'm not entirely sold on it. In the above example the movers can include a dropdown to have some of the more advance tools (move to start, move to end, etc). How else can we present movers for horizontal inner blocks? I also don't like the gallery example too much as it's very idiosyncratic.
  • This block (or the parent) should have a way of previewing how "Current Item" would look.
  • The most important design piece is to work on the auto-complete / link discovery dropdown (shared possibly with the regular paragraph link interface). It should support search, of course, but it should not be the main interaction. Top level pages, for example, should be exposed prominently in the dropdown to choose from quickly.

Submenus

Nested menus are going to be tricky because we'll have a permanent tension between faithfully representing the front-end and optimizing for managing complex menu structures. This will be generally at odds. That's why I think leveraging the block navigator is going to be crucial for managing this elegantly and efficiently.

That said, we should still find ways to present things directly on the canvas the best way we can. Selecting an item that has children, could automatically show them, for example, or we could have a toggle.

image

@jasmussen

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2019

The movers are placed within the toolbar but I'm not entirely sold on it. In the above example the movers can include a dropdown to have some of the more advance tools (move to start, move to end, etc). How else can we present movers for horizontal inner blocks? I also don't like the gallery example too much as it's very idiosyncratic.

This is definitely tricky to get right, and I hope we can receive a lot of divergent explorations on what this might look like. But I do strongly agree that if we can find a consistent pattern for this, it will benefit every single block.

One ingredient for starters, could be a solid solution to #16681. Another ingredient is to reduce the surface area of the "mover" component. Right now it includes a draggable handle, which has been necessary in the current design. But if there was a way we could improve how drag and drop worked to not need an explicit handle like this, it would simplify the component a fair bit.

I'm unsure if it could work, but if it could, here are some quick and dirty mockups along that vein. Vertical:

vertical

Horizontal variations:

hoz-1

hoz2

hoz3

hoz4

@karmatosed

This comment has been minimized.

Copy link
Member

commented Aug 12, 2019

I am really keen on using child blocks for this and love to simplified explorations. I will also add I think using existing patterns is absolutely the right option.

The idea the toolbar changes I think has the potential for other instances moving on if this happens for navigation. Just to add a point, contextually adapting could open up a lot of potentials and know it's been floated around a fair bit recently as an idea. I really like it as a concept, moving forward.

Should vertical / horizontal be a property or a block transformation? (I lean on the latter due to complexity.)

For me, a block transformation seems sensible there.

Do we want to keep the concept of a "named menu" so that you can insert the same menu in multiple places or is this something that perfectly fits under the "reusable block" paradigm and we should use that instead?

I am torn on this one. I can see a stress case for repeat use but the pattern of reusable blocks is a strong one to lean on.

How many distinct navigation design presentations do we want to support that we can handle through customization options? (Link color, hover, focus, background for individual items, border radius, current item styling, dropdowns and flyouts, etc.) This can get very large quickly, but the more we can absorb in the top level block, the better.

I really think the minimum is:

  • Color: link, background, current, hover, focus (although I'd maybe love to explore some generative current/hover/focus over having to pick)
  • A few styles are pre-made. I think having some good options would be great.
  • As far as color on dropdown/flyouts I sort of would like to see if that could also be generated.

How best to present the option of "List all of my pages"? The "Main" dropdown menu could include that option in my example above, and it can also be placed in the block inspector.

I feel we can lean on link searching for this.

The block inspector should have an "import from existing menu" flow for transforming older menus to block based menus.

Yes! I really like the idea we offer that.

The most important design piece is to work on the auto-complete / link discovery dropdown (shared possibly with the regular paragraph link interface). It should support search, of course, but it should not be the main interaction. Top level pages, for example, should be exposed prominently in the dropdown to choose from quickly.

Yes, so much!

I sort of really like the horizontal variation for movement, this could help with layouts.

@mapk

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2019

Thanks for sharing those additional mockups, @mtias! Very helpful!

Should vertical / horizontal be a property or a block transformation? (I lean on the latter due to complexity.)

For me, I think it's a block property because Transforms seem to transform one block into another somewhat different block. Changing layout doesn't warrant a transform. For example, take a look at the Posts block.

posts


Do we want to keep the concept of a "named menu" so that you can insert the same menu in multiple places or is this something that perfectly fits under the "reusable block" paradigm and we should use that instead?

I'd agree that the reusable block paradigm would be the good route here. Here's an example of how the current reusable pattern works when trying to create a nav within it.

Screen Shot 2019-08-15 at 5 03 20 PM


How many distinct navigation design presentations do we want to support [...] This can get very large quickly, but the more we can absorb in the top level block, the better.

I like this idea. Let's make the inner blocks as simple as possible by moving what we can to the parent block.


How best to present the option of "List all of my pages"? The "Main" dropdown menu could include that option in my example above, and it can also be placed in the block inspector.
The block inspector should have an "import from existing menu" flow for transforming older menus to block based menus.

I think a couple of these might work well in a Nav block placeholder/setup screen. When adding that block to the page, there could be a couple options; 1) Select existing nav to convert to this block, 2) Use all top level pages, 3) Start anew with a blank nav.
Some of these should exist in the block inspector as well as mentioned. 👍


This block (or the parent) should have a way of previewing how "Current Item" would look.

I agree. A toggle in the sidebar might do well.


The most important design piece is to work on the auto-complete / link discovery dropdown

Yes. I remember the original did promote "Search" as the primary choice, but there was thought around a "Browse" tab as well. I don't remember if this was mocked up or not though. Presenting top-level pages in addition to search might be a good exploration.

Screen Shot 2019-08-15 at 5 21 30 PM


Nested menus are going to be tricky because we'll have a permanent tension between faithfully representing the front-end and optimizing for managing complex menu structures.

Very true. I'd like to follow a similar pattern to how we do the Category block today with the "dropdown" option toggled "on." Basically you can click to open the dropdown, but clicking any of the links in the dropdown won't do anything. Example below.

dropdown

@mapk

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2019

In regards to my comment above...

I think a couple of these might work well in a Nav block placeholder/setup screen. When adding that block to the page, there could be a couple options; 1) Select existing nav to convert to this block, 2) Use all top level pages, 3) Start anew with a blank nav.

Here's an example of what I was thinking. It's not the best wording, but something visual to think through.

nav-placeholder

@melchoyce

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2019

Some older mockups around the placeholder:

image

image

image

@sarahmonster

This comment has been minimized.

Copy link
Member Author

commented Aug 21, 2019

Since there's a lot of different pieces to unpack here and more exploration needed on different parts of the problem, let's aim for moving some of the conversations to the relevant issues:

  • Horizontal block movers: #17093
  • Setup/placeholder state: #17096
  • Adding new menu items: #17116
  • Styling & customisation options: #16830

Should vertical / horizontal be a property or a block transformation?

I'd encourage us to think of this question, not from a technical perspective, but from a user's perspective. As a user, is a horizontal menu the same as a vertical menu, or are they different? I'm not entirely certain of the answer here, but my hunch would be that they're the same—they're just styled differently.

Yes. I remember the original did promote "Search" as the primary choice, but there was thought around a "Browse" tab as well. I don't remember if this was mocked up or not though. Presenting top-level pages in addition to search might be a good exploration.

The original proposal included a mock up of the browse interface, but suggested search as a primary action:

Do we want to keep the concept of a "named menu" so that you can insert the same menu in multiple places or is this something that perfectly fits under the "reusable block" paradigm and we should use that instead?

I'd love to see us move away from the named menu paradigm. The majority of users aren't likely to need to insert the same menu in multiple places—you add a menu to your site header, you're good to go. Using reusable blocks seems sensible, especially when this behaviour is unlikely to be the primary use case.

I've updated the mockup here to include the child/parent/sibling dotted borders introduced recently, so we can see how those would impact the visual styling here:

Blocks-style-dotted-borders

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.