Navigation menu block: Smart defaults

[sarahmonster]

This is intended to splinter conversation from #13690 and allow us to focus the conversation on one part of the problem at a time. We'll loop back to the tracking issue when we've determined a path forward. For this issue, we're focussing on onboarding:

What happens when I add navigation menu block?

When a user first adds a navigation menu block, we want to help them get to the menu of their dreams as quickly as possible. Given that navigation menus can be rather complex, what can we do to make this process as painless as possible?

Here's a super rough outlay of my thinking here:

There are three potential options here, each with different merits. Let's look at them each in detail.

1. Use a "smart menu" as a default.

In this solution, the user adds a menu block and is immediately presented with a "smart menu" that reflects their site structure. The menu updates when they add new pages or categories. If the user wants to customise their menu, they need to convert it to an editable menu.

Pros:

• Requires minimal user input
• This is the only solution that really allows for a menu that updates when new content is added
• No more "automatically add top-level pages"!

Cons:

• I'm guessing most users would want to edit their smart menu, meaning they wouldn't benefit from the automatically updating side of things.
• If most users want to edit their menu, the intermediary step is just added friction.
• Requires an undo mechanism or a way to revert back to the "smart" menu.
• Updating with new pages only sometimes could be confusing.

2. Jump straight to an editable menu, auto-populated with "smart" items

This is basically #1, without accounting for the intermediary step of an un-editable magic menu. A user adds a menu block, we do a bunch of behind-the-scenes work to figure out what we think they want there, based on their existing site structure and common patterns, and then give it to them:

They can then edit to their heart's content.

Pros:

• Super easy, super straightforward.
• Allows for a way to provide better defaults whilst still retaining user control.

Cons:

• If users start with a menu (before adding page content) this isn't going to be super helpful.
• Need to manually add new pages to the menu in order for them to show up.

3. Take me to the wizard

This option gives users the choice of what kind of menu they'd like to create up front, so they can add a menu of all their pages, or all their categories, or they can select a legacy menu or smart menu or no menu at all!

Pros:

• Allows for a variety of smart menu options (so footer menus, for instance, tend to be much more detailed than a header menu is, and we could allow for a page menu or a category menu or something else entirely)
• Allows the user to start from scratch easily, so they don't need to delete "smart" items that aren't all that smart
• Allows for (potentially) fine-grained "magic menus" that could then be used as footers or similar (make a menu with all the child pages of "About us", make a menu of all my categories, etc)

Cons:

• Presenting a decision like this introduces cognitive friction. Is this better than just guessing for the user?
• It feels like we're introducing a lot of complexity without really adding value for the majority of users.

A quick note about legacy menus

Depending on which approach we opt for here, legacy menu support will be baked in. This means that, for instance, if you have one saved menu on your site, that will be used to populate your smart menu. If you have multiple menus saved, you may be presented with an initial choice to select from one of these menus. Some of this has already been presented in the prototypes shown in #13690. For now, we're just going to focus on the new user experience first and optimise for that.

How do we build a smart menu?

Obviously this will require some technical work and testing to get right. I'm working on getting some data to support my assumptions, but my initial thinking here is:

• any top-level pages (up to a maximum number, perhaps 10?) and one level of pages beneath that
• exclude pages from a blacklist of common names ("privacy policy" probably doesn't belong in a header menu)
• whitelist pages too (so “about” always appears)
• if the user has 2+ blog posts, include a “blog” or “news” page (archive of all posts)
• if the user has categories set up, include links to those categories under the “blog” parent

Once I have some data here, I'll work on a refined ruleset.

What do you think?

1. Are there alternate approaches we should explore?
2. Which of these approaches feel most user-friendly?
3. Are there considerations we haven't considered yet?

[melchoyce]

re: the wizard — what if it was contextual? If, in the future when we have block areas for your header, footer, etc., we suggest options based on where you're adding the menu. So, if you're in the header, we suggest some of your "common" pages (about, contact) as a menu, and also a social menu option. If you're working in your footer, we could suggest showing all your pages, or just showing Privacy Policy / ToS / Contact, or social again.

Building on the idea of a wizard, I wonder if we could make something that provides a set of guided choices? I like the idea of "smart" defaults and guiding the menu creation process, but I worry the wizard option doesn't really show what each of those menus means. Please excuse this incredibly half-baked thought:

Similar idea, but providing some default pages you could check off. If you only have a few pages (let's say, under 5), it would also suggest pages and would create them for you if you select them. If you already have a bunch of pages, we populate the list with your parent pages instead. We'd have to figure out a way to scale upwards if you have more than, say, 20 or 30 pages.

If your site already has categories, we can present the categories screen, and if not, we could provide an interface for creating categories (or skip it entirely).

I'm hoping by providing a faux-preview, we can also provide additional context.

[sarahmonster]

re: the wizard — what if it was contextual?

YES PLEASE. I love this idea so much I could cry. ❤️🌟💯 Any of these solutions should be contextual and consider the menu's location. That may be trickier in the context of a full-site editor (how do we know if we're in the header or footer?), but that will likely depend pretty heavily on what that full-site editor looks like, exactly—and there are ways that we could approach this.

I'm very torn between offering a wizardy experience and just making decisions for the user and allowing for them to correct us when we're wrong. I do love a wizardy approach, but I wonder if this might be better suited for a new-site onboarding experience rather than something that happens inside the block. The wizard here is super comprehensive, but I wonder if people would feel overwhelmed by the number of options available.

We could either offer an initial choice: "Would you like to use the wizard, or would you like us to build you a menu?" For most users, I suspect that they'd choose "build me a menu". If we get it right, this option is the least hassle for the majority of people who aren't interested in making all these decisions.

An alternate option would be to give an interstitial smart menu, which they could then quickly edit:

I'm not sure this solution offers many benefits over "here's your smart menu, edit away" beyond slightly quicker adjustments.

In exploring these and landing on a solution, it would be super helpful to have some data about when people typically make menus for their sites: do they create all their content first, and then create a menu? Or do they start with the menu, and then create pages?

[melchoyce]

In exploring these and landing on a solution, it would be super helpful to have some data about when people typically make menus for their sites: do they create all their content first, and then create a menu? Or do they start with the menu, and then create pages?

Based on my own experience building sites, it's a little of both. I usually try to start with the menu to stub out my site and get the structure built, but there's usually a bit of back-and-forth depending on what content I have already and if I get distracted working on a specific page. If I'm working in WordPress, I usually create my new empty pages either rapidly from Add New, or I create them in the Menus interface in the Customizer.

[melchoyce]

We could either offer an initial choice: "Would you like to use the wizard, or would you like us to build you a menu?" For most users, I suspect that they'd choose "build me a menu". If we get it right, this option is the least hassle for the majority of people who aren't interested in making all these decisions.

How would people know the difference between these two?

[mapk]

• I'm guessing most users would want to edit their smart menu, meaning they wouldn't benefit from the automatically updating side of things.

I agree. There might be some interesting research here, but my experience has been that editing a menu is akin to the experience of making the site yours. In this case, option 2 feels good, especially in light of the ways in which you proposed to build a "smart menu."

The wizard concept feels more like a version 2 of this block. There's a lot there. When I look at the "Preview" of the block from Mel's wireframes, it makes me just want to do all that IN the block while seeing the real navigation (not a preview) and making the edits below.

[jasmussen]

The explorations in #13786 (comment) seem like they are on a good path.

Stepping back just a little bit, there's a lot of complexity here, and although we know that users love their custom menus a lot, are we sure that highly tailormade menus are widely used, and do we know whether highly customized menus are made in such a way simply because it's the only way to make a menu?

In a previous life, in my time as a freelancer, nearly all the menus I created were simply that — a list of the pages you already had in your Pages section. Occasionally with a social link added. In that vein, it seems to me that the first suggestion is right on, except for the name:

1. Use a "smart menu" as a default.
   In this solution, the user adds a menu block and is immediately presented with a "smart menu" that reflects their site structure. The menu updates when they add new pages or categories.

To me, and I suspect, to the majority of users, this is the menu block. No need for the "smart" (I sense by the quotes you never meant for them to be included as the name, but in that case just consider this a +1 validation of your idea).

If the user wants to customise their menu, they need to convert it to an editable menu.

Yep. This would be an advanced menu block. I love the idea that as soon as you choose to edit the menu, it essentially becomes detached from the pages section and is a customized collection of links.

What happens then is the hard part: how do you customize it? Maybe in the V0, the way you customize it is in the current Menus editor, and the edit button just takes you there, in a way.

[sarahmonster]

How would people know the difference between these two?

Yeah, I'm not convinced this is the best approach and I'm wary about introducing a decision for a user to make when we can make a good one for them. In light of our conversation about distilling in-block actions to the simplest options necessary for the majority of users to get a menu that works for them and moving more complex fine-grained interactions elsewhere, I'm thinking something more along these lines might work:

These ideas are super rough at this stage, but I'm going to have a go at exploring them a bit more today. I'm still not certain if the "smart" menu would be better if it updates as the user creates new content, but that might be something that can reveal itself in testing.

Quick clarification here: the concept of a "smart menu" is just that we'll provide smart defaults and attempt to use computers and data to build the type of menu we think that users would want, based on the content of their site and common patterns used. It's not intended as a term we'd expose to users or a separate block, just a more-intelligent default state that can then be customised further if needed. I promise not to put "smart" anywhere in the UI—it's always better to

This is all one "Navigation Menu" block—all the same block, but attempting to reveal complexity progressively and only as needed, so that the majority of users can get a menu they want without needing to fiddle with many knobs and buttons.

are we sure that highly tailormade menus are widely used, and do we know whether highly customized menus are made in such a way simply because it's the only way to make a menu?

We're working on getting some data to support this assumption, as well to determine what people tend to put in their menus. That will inform a great deal of how we build out the default "smart" menu. 🙂

What happens then is the hard part: how do you customize it?

We're working on some ideas for that over in #13789, #13790, and #13792. We could certainly start with deferring users to the existing menu editor, but the end goal is definitely to allow for menu manipulations within the block itself, or in concert with previewing the block.

[sarahmonster]

Since design explorations have largely concluded here, I'm closing this ticket as non-actionable, and we can loop back to #13690 or new issues for any further conversation that comes up as development work progresses.

Thanks everyone for all the feedback! 🙌

[kishanjasani]

@aristath How to use different header for different pages? Any Idea? Is it Possible in current version?

[aristath]

@kishanjasani I don't understand... What do headers have to do with this ticket? If your question is not related to this thread, then please open a new issue instead.