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

Add block: Navigation menu #13690

Open
sarahmonster opened this Issue Feb 6, 2019 · 17 comments

Comments

@sarahmonster
Copy link
Contributor

sarahmonster commented Feb 6, 2019

Since creating a block for navigation menus is one of the priorities for 2019, @melchoyce and I have been spending some time working on some ideas for a navigation menu block.

Lots of great work toward exploring a navigation block has already happened in #1466. In the interests of refocussing the conversation, I'm opening a new issue for this as we attempt to reach a solution.

First, let's establish a framework for understanding and evaluating the proposed solutions.

1. What’s the problem we’re trying to solve?

Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of your site often requires manual work.

2. What existing research do we have?

Menus came up a few times in our sitebuilding research. Relevant takeaways: some people model the structure of their menus on the structure of their sitemap (or vice-versa).

Competitive analysis: http://simp.ly/publish/fTQTQB

Mel reviewed existing explorations to compile the discussion and ideas that have emerged around navigation blocks over the years.

Functionalities to consider:

  • sticky menu
  • horizontal or vertical menus
  • nested menus
  • social menu
  • mega menu: image, description, button, etc

3. What are our guiding principles?

After discussion with developers, accessibilities, and other designers, we've decided that in order to support the problem:

  • building a menu should be as WYSIWYG as possible
  • menus should be as flexible as possible
  • there should only be a single experience for building and editing a menu, even if that experience is duplicated in different parts of the UI
  • the menu-building experience should be consistent with existing Gutenberg design patterns
  • the solution should allow for all functionalities identified in “existing research” section
  • should allow for adding pages and defining page/sitemap structure

4. How do we choose a successful solution?

Using prototypes, we’ll test and time the creation of a simple menu and a complex menu. We’ll also ask users to rate their experience from a scale of 1-5.

This quantitative data (experience rating and time to creation) will be used alongside the qualitative data (user feedback, your feedback!) to determine which solution is the most effective and should be pursued. @melchoyce will be responsible for this selection. We'll then iterate on the solution until we hit on what we think is the best approach.

@sarahmonster

This comment has been minimized.

Copy link
Contributor Author

sarahmonster commented Feb 6, 2019

In exploring solutions, @melchoyce and I narrowed down to two paths.

These particular prototypes focus on creating a new menu from scratch. Not every state or setting has a mockup — the focus right now is to go broad, not deep, in this exploration. We'll test these two approaches and then narrow down in iterations, based on your feedback as well as user feedback.

Concept: Going all-in on child blocks

gutenberg-nav-menus-block-desktop

Desktop: https://www.figma.com/proto/PtDJhniObeJ2Po6TZAMiHCKv/Gutenberg-Navigation-Menu-Block-Child-Blocks?node-id=0%3A1&scaling=min-zoom

gutenberg-nav-menus-block-mobile

Mobile: https://www.figma.com/proto/PtDJhniObeJ2Po6TZAMiHCKv/Gutenberg-Navigation-Menu-Block-Child-Blocks?node-id=2%3A13829&scaling=min-zoom

This approach takes advantage of some smart patterns introduced by the Jetpack contact form block and WooCommerce products blocks. Each page type is its own child block. We focused on two things: using as many established Gutenberg patterns as possible for consistency, and retaining existing navigation menu features so the block can be a direct port for backwards-compatibility purposes.

Questions:

  1. We’ve introduced a “hide menu” setting, which is to tackle the issue of some themes providing default menus, some setting fallbacks, etc., which means there’s no consistent way to get rid of a menu. In the future when we have full site editing, this could come in handy for themes or sites that don’t allow you to delete global blocks. For now, it’s a bit superfluous and we might remove it.
  2. The navigation menu should include a “Login” and “Logout” item, as well as an RSS feed link menu item — should these be their own menu types, or listed in “Pages?” Maybe they should be in a “Meta” page type?
  3. We’ve included menu descriptions inline, but we're wondering if, since not a lot of themes currently support them, if they should live in the sidebar?
  4. Should we deprecate any menu features, like XFN, from the block?
  5. Should any other menu options live in “Advanced Settings?”
  6. Anything missing?

Concept: Menus are just links

gutenberg-nav-menus-links-desktop

Desktop prototype: https://www.figma.com/proto/2boguPnkQ8r2aCeovzBHwY/Menus-are-just-links?node-id=83%3A15896&viewport=402%2C418%2C0.5&scaling=min-zoom

gutenberg-nav-menus-link-desktop

Mobile prototype: https://www.figma.com/proto/2boguPnkQ8r2aCeovzBHwY/Menus-are-just-links?node-id=83%3A15896&viewport=402%2C418%2C0.5&scaling=min-zoom

Inspired by Material Design’s chips, this option aims to present the menu as closely as possible to the way it looks on your live site.

This uses the some interface as adding links elsewhere (when creating an inline link, or when adding a button) so there’s consistency any time users add a link. (Note that this only works if users think of navigation in the same way they think of inline links, which may not be the case.) This is a good opportunity to refine and unify how this interface works (#6392) as well as evaluating other search interfaces. We can unify these experiences across the entirety of the product whilst also making a teensy accessibility win.

It tries to make as many smart default guesses as possible for the user: it allows for converting menus if you already have some saved, but if you don’t, it defaults to a small menu based on existing pages. Finding items to add to the menu is primarily based around a smart search that searches across all types of content on your site, as well as including pages for archives and recognising and adjusting for social media links. Pasting a link will work as expected, so the interaction will be immediately accessible in as few inputs as possible.

Questions:

  1. Does the chip approach work here to add clarity and usability, or does it feel too divorced from existing Gutenberg patterns? Is there a better way to clearly communicate a link in a navigation menu while it's being edited? (See alternate style ideas.)
  2. This approach avoids putting settings in the sidebar as much as possible but doesn't include many fine-grained controls (beyond a horizontal/vertical option and alignment for the menu, and a few options for individual menu items). Are there other settings that should be included here?
  3. How can we improve on the existing "add link" interface to make it more accessible, usable, and flexible? (For instance, the ability to upload a file directly here would go over like gangbusters; see also #8322.)
  4. This isn't included in the prototype yet, but we'll want to include some options for adding new content here as well: maybe just a "Create new page" option below search results? Are there other types of content we should allow for dynamically creating from this menu?
  5. Sub-menus haven't been fully explored here yet either, and they open lots of questions. Should we allow for unlimited layers of sub-menus, or restrict the number of children? Should sub-menus be expanded by default, or should there be a way of expanding and collapsing them? Can you select a sub-menu individually? Would the toolbar be specific to the parent menu, or to the sub-menu? Is there such a thing as sub-menu settings, or are those settings owned by the parent menu and applied across all sub-menus?
  6. What happens when a user has a lot of items in their menu? How can we make it as easy as possible to navigate through those items across a range of devices?

What do you think?

At this point, we'd especially appreciate overall feedback about:

  • Technically feasability: Can we do all this? Are there ideas here that are too wishful thinking?
  • Accessibility: Are there things we could improve here? Does anything in particular raise a red flag? What can we do to ensure these approaches are as accessible as possible?
  • Experience: Do these feel like natural approaches? Are there any parts of the flow that feel awkward?
  • Settings & functionalities: What functionalities and settings are critical to meet the needs of the majority of users? Are there settings we can drop, or that we should be sure to include?

Leaving comments directly in Figma would be great, and you can also comment here. We'll work on refining these prototypes and running some lightweight usability testing to get a sense of how natural the interactions are.

@deckerweb

This comment has been minimized.

Copy link

deckerweb commented Feb 6, 2019

Login, Logout, RSS etc. should be a "Meta" type, NOT "Page"

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

  • nofollow / dofollow (for SEO purposes)
  • noopener and noreferrer (both for security purposes)
@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 6, 2019

XFN should be kept, since it must be possible to optionally set these meta params for ANY menu item link:

  • nofollow / dofollow (for SEO purposes)

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

  • noopener and noreferrer (both for security purposes)

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

@deckerweb

This comment has been minimized.

Copy link

deckerweb commented Feb 6, 2019

Can this be applied to the entire menu, or does it have to be on a menu-item-by-menu-item basis?

Yes, that was what I meant. I often times have a few menu items which I explicitely set to nofollow - for example an external link to a donation service or the internal link to the privacy page (because I don't need both to be indexed in Google...). I know lots of other devs and users doing this similar.

Is this something WordPress should handle by default, rather than leaving it up to the menu creator?

In my opinion yes, for all links that open in a new tab/window (_blank target).

Also, the option to set an optional link target (to open in new tab/window) must be kept - at it is currently. This is an essential user option.

@sarahmonster

This comment has been minimized.

Copy link
Contributor Author

sarahmonster commented Feb 6, 2019

"Meta" may not have any meaning to the majority of non-technical end users, but you're right that log in, log out, and RSS links aren't the same as static pages. What's a way to communicate this clearly to users? Maybe the login and logout could be classified as "action" links? Perhaps the RSS feed is a special "feed" type, or maybe it acts the same way as a social media link (basically as a special type of link.)

XFN is pretty user-hostile as it currently stands, but it's helpful to get a sense of how that feature might be being used. It's actually intended to show a personal relationship and used to be more explicit when Blogrolls were still a Thing. I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 6, 2019

I wonder if exposing those options directly (nofollow, dofollow, noopener and noreferrer) in the Inspector (since these are rather advanced settings, but we could include them in the link interface if we think they're important to all users) might be the way to approach this.

That would also allow for some inline explanations, which would definitely help.

@getdave

This comment has been minimized.

Copy link
Contributor

getdave commented Feb 6, 2019

Thank you so much for this. Great to see this moving along. Some thoughts...

Concept: Going all-in on child blocks

Technically feasability

Everything I see looks doable.

Experience

  • What would re-ordering items in the menu look like?
  • Veritcally displaying the Menu whilst editing is good when constructing a Menu that maps to a Sitemap in the user's mind. However visually I feel the preview will need to better reflect the reality on the frontend (ie: most menus are't vertical). However will the change between the two states be too jarring?
  • Visually the items don't feel like "menu items" they just feel like links. I appreciate this is fundementally what they are but a Menu item implies much more. If each item were more of a contained "unit" then you could give them their own controls. Perhaps more closely aligned to the existing WordPress menus?
  • Once added there isn't a way to visually see the type of the menu item (eg: Page, Post, Category...etc) without interacting.
  • How do I remove a Menu item once added? Nothing visually shows up? Also an a11y concern.

Concept: Menus are just links

Technically feasability

Everything I see looks doable.

Experience

  • I like the "chips"
    • make it easy to remove an item
    • the inline auto complete is a nice touch*
  • I believe adding Social to this is a step too far. See notes below.
  • It's not immediately clear to me as a user how I crate hierarchies
  • Can we stress test the design a bit with the horiztonal layout? It's fine with 3 items but what happens when you have 10? You can't easily wrap as that could be confused with a hierarchy. How will this scale? (see comments above re: vertical layout when in editing mode)
  • I preferred the explicit choices (Page, Post, Link...etc) in the "child blocks" prototype. It was clear what you were adding to the menu and the search was a nice extra. Could we merge the two?
  • How do I reorder items?

General: Settings & functionalities

  • Login/out and RSS should be separated under Meta as suggested
  • Gut feeling is that Description is rarely used. Put that in sidebar. Prioritise the UI space elsewhere.
  • I'm fairly against muddying the concept of creating a Menu with the concept of adding new Pages. The act of creating a Page feels like it needs to be explicit and not part of creating a Menu Block.
  • I'd say remove as many "rarely used" (TBC) features as possible. Keep the UI nice and focused wherever possible. We can always add more settings later if user demand dictates it.

Relationship to "Social Links"

There is an existing Issue for Social Links. I (and others) don't believe the Menu Block precludes the need for a dedicated Social Links block.

Most users won't cognatively assiociate "Menu" with "Social Logos". When searching Blocks they'll expect "Social Icons/Logo/Links" not "Menu".

I appreciate at a deep level Social Links and Menu Items are similar in concept but to me they feel like distinct Blocks. I fear that if we get too "meta" on our Blocks and try and require overconfiguring them then UX may suffer.

I'm very interested in hearing your thoughts on this as I am (was going to be) taking on the Social Links Issue...

Again, thanks for moving this conversation forward.

@LukePettway

This comment has been minimized.

Copy link
Contributor

LukePettway commented Feb 6, 2019

Some of the accessibility concerns that come to mind would be:

Keeping control of user focus throughout the flow

When clicking the Add a Menu Item button, a dropdown appears which then provides a search input as well as several sections to locate a page or pages to add to the navigation. Once a page or pages have been added to the menu, the dialog closes and returns the user back to the block. That is a lot of moving around between different components on the page.

The most important thing here is to make sure that we are updating the focus and placing it in the next logical spot. I also wonder to what extent focus might need to be trapped within these elements because it might be really easy to escape the component before the workflow of adding a page has been completed.

Providing Additional Context to Assistive Technology

When selecting any number of menu items, having some way to inform assistive devices about their current selection state is crucial. This could be notifying them that the number of selected items changed from 3 to 5 for example.

Another area of consideration is the approach to nested page structures. To a user who is not blind, it is easy to infer the hierarchy of content when adding a category and pages under that category for example. This might become an issue for those using assistive technology. Am I adding these pages inline?, how do I know that the pages I am adding will be children of the parent they are currently under. This is especially the case if selecting the parent could potentially also select the children (solved again by announcing the selection to the assistive device).

I'll spend some more time thinking about this experience and please let me know if you have any questions about my comments. Thank you for all of this!

@alexislloyd

This comment has been minimized.

Copy link
Contributor

alexislloyd commented Feb 6, 2019

My hypothesis is that there are three primary types of user intent when inserting a nav menu:

  1. I’m a business owner who wants a menu linking to all the top-level pages
  2. I’m a blogger who wants a menu linking to all the top-level categories
  3. I want to make something custom from scratch

I also suspect number 1 is the most common, and that users who are in the number 1 category have the highest likelihood of not being experts.

I was originally thinking that we could give users a choice between 1, 2, and 3, like option A in the sketch below.

However, it occurred to me that instead of confronting the user with a choice, number 1 could just be the smart default, and you could make it easy to infinitely customize from there. I imagine most “custom” menus are actually just variations on one of the first two, so having that populate as a default and then be able to take out a link here, add a link there, add a social button, etc. is likely easier than starting from scratch anyway.

So, in option B below, the user inserts a menu and it defaults to a menu of all the top-level pages, with an easy toggle to switch to categories. Each menu item is selectable, editable, movable. You can add new items. And the sidebar could support lots of more advanced options like adding additional levels to the navigation.

untitled_artwork 6

@getdave getdave referenced this issue Feb 7, 2019

Closed

Social Links Block #13725

0 of 5 tasks complete
@sarahmonster

This comment has been minimized.

Copy link
Contributor Author

sarahmonster commented Feb 7, 2019

Thanks for the feedback! We're going to keep collecting more feedback and then iterate on these designs based on feedback and testing. A few quick-ish notes:

@getdave We've definitely seen some evidence that indicates users tend to think of adding pages (building their site structure) and building a menu as an intertwined process, and they can often become confused when pages they've created don't automatically appear in their menu. The social links is just a hunch, though, and it might be based on the existing pattern of themes registering social menu areas, so it's worth evaluating if that's how users see things.

I'm going to see if I can test these hypotheses a bit when we usability test these designs. If you have any insights on users' thought processes around these components, it'd be super useful to incorporate those!

@LukePettway Thank you so much for the accessibility feedback! For the focus consideration, do you think either of these methods of adding a menu item (the child block interface vs the link interface) presents fewer hurdles?

Your point about nested page structures is especially helpful, since nested structures are a bit tricky to design for. Thinking about how to non-visually indicate this hierarchy to users of assistive technology may actually be key to unlocking some good ideas here—I'm adding to the list of "things to explore more".

@alexislloyd it sounds as though what you're suggesting here is similar to the "auto-populate" option presented in the "Menus are just links" option, where users who haven't already created menus are given a menu populated from their pages, rather than an empty menu, and users with existing menus are shown those menu.

screenshot 2019-02-07 11 03 38

The idea here is that we'd try to make smart guesses for what they'd want in their menu, but immediately allow for customisation of those items, which I suspect most people would immediately want to do.

I think we could possibly take this a step or two further and try to add other helpful, smart defaults, so rather than just including top-level pages, leverage certain common naming patterns to determine order, or which pages to include or exclude. My suspicion, based on a cursory evaluation of common menu patterns across blogs, is that #2 is actually a less likely scenario than we might think, and that most blogger sites use a combination of categories and pages in their menu.

Rather than asking users to reckon with the choice between pages and categories, we can skip this step altogether and provide them with a ready-to-go menu that includes pages as well as categories (perhaps above a certain threshold), along with other suggested links based on common patterns and their existing site structure. I have a few thoughts for how this might work, but I'm going to look for some data to back them up and explore a few alternate ideas. This should also allow us to test if our smart defaults will actually feel smart for the majority of people.

@scruffian

This comment has been minimized.

Copy link

scruffian commented Feb 7, 2019

Following on from @alexislloyd's point, something I have seen in usability tests and research, time and again, is that users conflate their navigation with their site structure. If they add a page they expect it to appear in the navigation. If they add an item to their navigation, they expect a page to be created.

I wonder if we should consider creating two different blocks. One very simple "page navigation" block, which maps 1:1 to a user's pages - when they add an item to the navigation a new page is created; when they add a page to the site, its added to the navigation.

Then we can add a second "custom navigation" block which will allow for all of the complexity that many users need.

@alexislloyd

This comment has been minimized.

Copy link
Contributor

alexislloyd commented Feb 7, 2019

@scruffian you make a very good point about the conflation of navigation and site structure. That might be a secondary problem to try and solve once the fundamental insertion of the block is nailed down.

As to insertion, I still think we could do it with one block — I think the ideal experience would be one where someone doesn't have to stop and think "Do I want a page navigation block or a custom navigation block?" Ideally, we can remove any friction that makes someone stop and wonder if they understand the choices. If we provide something relatively smart but make it incredibly easy to modify, it seems like it would be able to satisfy everyone's needs, whether simple or custom, without having to create any friction or potential confusion for the user up front.

@sarahmonster I like how you're going even further with the smart defaults idea — the approach you're suggesting also really supports users who don't know the difference between pages and categories (and shouldn't have to!).

@sarahmonster

This comment has been minimized.

Copy link
Contributor Author

sarahmonster commented Feb 8, 2019

Thanks for all the helpful feedback here! In the interests of maintaining focus and ensuring that we've fully explored all parts of the problem before moving toward a solution, we're going to break the problem into smaller parts to explore individually:

  1. What happens when I add a menu? (smart defaults, onboarding)
  2. How do I add an item to my menu? (child blocks, link interface, types of content to include)
  3. How do I edit that menu item? (renaming, settings)
  4. How do I rearrange items in my menu? (ordering, hierarchy, sub-menus)
  5. How are menus and menu items presented visually? (focussed state, horizontal/vertical styling)

We’re going to discuss each of these problem areas individually in more detail, then return here with the resolution once we’ve reached a consensus. (Links coming as new issues are created!)

We’re also going to do some additional research to inform these explorations:

  • digging up insights from support forums
  • collecting common menu patterns from a range of different sites

If anyone would be interested in helping with any of these tasks, we'd definitely appreciate the help!

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 11, 2019

@deckerweb Circling back around to menu item settings for a second — would something like this make more sense for handling nofollow?

image

@deckerweb

This comment has been minimized.

Copy link

deckerweb commented Feb 11, 2019

@melchoyce Thank you, this is perfectly fine in my opinion and an improvement over the current nav menus.

It has clear user guidance with the labels/wording, and the setting toggles are faster and easier. I hope this will go in the final version in future. Thanks for this great work!

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 11, 2019

Awesome, thanks!

@jwold

This comment has been minimized.

Copy link

jwold commented Feb 13, 2019

Amazing work here! I'm going to comment individually, but just wanted to say that the progress here is wonderful. :)

@karmatosed karmatosed moved this from To Do to Navigation in Phase 2 Feb 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment