Navigation Block: Enhancement ideas for the empty placeholder

[kjellr]

When it contains no items, the Navigation block currently looks like this:

While implementing the header and footer patterns in #31610, I've run into a few issues with this placeholder appearance. In general, when choosing a pattern in the pattern carousel, it's hard to envision what the final navigation will look like.

In the case of patterns in particular, it would be helpful for the placeholder to more accurately show a realistic version of what the menu may end up looking like. For example, showing:

• Font size and font appearance for the navigation items.
• Recommended "placeholder" items for the pattern preview: Some patterns will be designed to include tens of menu items, others just a few.
• Whether or not to include a search icon. (Search blocks can be added separately, so I'm not sure they make sense in this placeholder?)
• Whether or not responsive navigation feature is enabled

Screenshots

Font size not represented by the current placeholder:

Responsive nav not reflected by the current placeholder:

Example of a pattern where a more curated placeholder state might be helpful (In general, search shouldn't be there twice):

---

cc @jasmussen since I know you're thinking about these things.

[jasmussen]

Thank you for creating this ticket, I meant to myself and have been working on some mockups to that effect.

The key bit is, I feel like we have now tried the ultimate version of the navigation setup state as it exists in the form of gray blobs. It's a good principle — showing a resemblance of the end-state in its unselected form — but we've also found the limitations thereof, some of which you mention here:

• The blobs can be mistaken for a "loading state".
• Creating and making sure this setup state works perfectly for the navigation block has proven to be complicated enough that it's not easy to replicate this pattern for other blocks.
• When you create patterns, the setup state suggests 3 items and a search item, even if you just want one item.

Keeping those items in mind, let's imagine building a pattern such as this:

Admittedly, that design is a bit out there, but it is something I expect us to eventually be able accomplish, and if you squint it's not so far from the item | site logo | item patterns you share as an example in this ticket. In all those cases, and for the reasons you've outlined, the gray blobs aren't useful. The fact is, that it's an opinionated pattern, designed about exactly 4 menu items and a site title, all of them heavily stylized with font, color and even text orientation.

Let's imagine how you might accomplish this. You might start with a site design that featured a header and a footer, and potentially content in between. Based on that assumption, we might have two navigation blocks, one in each template part:

The template itself would be responsible for the overall vertical layout/rhythm, perhaps using a flex container.

In this mockup we imagine the top most navigation block has already been customized by the user — they picked "Home" and "About" as existing pages on their site they wanted to link to, and added "Les Nuits" as the site title. Now zoom in on the two bottom menu items:

Those semi-transparent "Select a page" are menu items, pre-inserted. Much like the existing menu item setup state we already have — click the item to pick the page it should link to:

We'd want to refine it a bit, so that setup state shows the correct font, color and other metrics chosen by the pattern designer:

The user would then pick "Portfolio", and be done. Here shown leveraging the progressively revealing Typography panel from #27331, enhanced with a vertical text option (which uses text-orientation):

---

The key bit is this interface:

Instead of continuing to tweak the gray blobs, perhaps we should leave them as a white bordered classic setup state with a few empty-canvas shortcuts, and instead leverage start creating patterns that leverage an enhanced version of the individual menu item setup state instead.

• As a designer, you'd make recommendations or opinionated choices about how many menu items you'd suggest, but the user would always be able to add more at their editorial discretion
• The pattern you end up creating is ready for permanent page link destinations to be chosen by the user, but still shows typography, color, and other character in its resting state.

Note that the above mockups came together somewhat quickly today, and does not represent a completely formed thought. But I wanted to share it as what I'm thinking about for an evolution of the navigation block setup state.

[kjellr]

Thanks for sharing these mockups! It's helpful to visualize things that way.

What we're talking about here requires an odd balance: It needs to look real and finished (in the pattern preview state), but also be clearly just a placeholder that requires more action. I was thinking about how we handle this for other blocks in the context of patterns, and we largely don't. Patterns include the exact same content they'll include when you insert them. Users will delete or replace most of it after insertion.

I wonder if we should take a similar route for navigation blocks in patterns? I think this is what you're getting at above. So for example, instead of defining a pattern like this:

We would define a pattern + content like this:

It would look like that in the preview, and it would look like that when you insert it. Some of the links might be dead, but the dynamic ones (home for example) should work just fine. If we're smart about it, we could just turn those dead links into placeholders, so folks can click to individually edit them.

Does that line up with what you're thinking?

[jasmussen]

What we're talking about here requires an odd balance: It needs to look real and finished (in the pattern preview state), but also be clearly just a placeholder that requires more action.

Yes, this is definitely the challenge, and one we haven't sufficiently tackled in the past relying mostly on a navigation block state.

I was thinking about how we handle this for other blocks in the context of patterns, and we largely don't. Patterns include the exact same content they'll include when you insert them. Users will delete or replace most of it after insertion.

Yes, and this is where I think we have an opportunity to look at a menu item setup state instead of a navigation block state. So yes, you would create the whole pattern with a single navigation block that includes 2 menu items, a site logo, and 2 menu items.

Your example above has the menu item labels filled out, where just for completeness sake, I was suggesting those meny items were completely unconfigured — simply empty Page Link blocks inserted, so something more like this:

But as you can no doubt see from the above, that's neither a very clear pattern nor very obvious that the "Page" blocks need further configuration. Nevertheless that described my line of thinking, and outlines the challenge:

• Instead of a single Navigation block setup state, focus on setup states for items inside
• Instead of setup states that look like block UI, seek a balance between inheriting fonts and styles, yet still make it clear they need further configuration

Do we include dashed underlines like grammar suggestions, or does that depart too much from the visual appearance of the pattern?

The biggest headache currently is that the menu item setup state is a pretty key part of the flow of configuring menu items: until the menu item points to a destination, you cannot edit the label. This is working well insofar as it makes it impossible to create a dead link in the menu item. I believe this would also benefit patterns — just click the page link and choose its destination, and you get the label for free.

The downside is the mockup shown above with the repeated "Page Page Page Page" being the end result. And that's part of what I need to explore in some mockups.

[jasmussen]

Here's an iteration which assumes the following:

• As a pattern developer, you can pre-fill a label even if that means you might need to go into the code editor to make that happen.
• However without the URL configured, clicking the Menu Item will open a "Page link picker" dialog. In other words, it will remain in a setup state.
• Menu items in setup states look exactly like normal menu items, except they have an additional visual indication.

In this design, I'm exploring that approach and using diagonal stripes as the additional indication:

I don't love that treatment, and I'm essentially thinking aloud in sharing here. Here are some other treatments I'm exploring:

The squiggly line, due to its grammar nature, could potentially work as indicating this needs your attention, but I'm not yet sure it would scale neatly to other things such as Buttons or Social Links, for whom I'd also love to create individual-item-setup-states.

[kjellr]

Yeah, a potential issue for the squiggly line is if a theme happened to use that as their link style. 😅

I've been thinking about this more, and I'm not 100% sure these need to behave differently than other placeholders once they've already been inserted, especially if we can show users how they are supposed to look in a pattern preview.

So for example, let's say someone has a block pattern that looks like this:

Three items, black links. We could show that in the preview. But when the user inserts it, maybe we just convert any broken links to be Link placeholders?

[jasmussen]

Good point about a theme using that squiggly line. But the reason I haven't completely abandoned that idea is that I think it's important we are able to show a compelling pattern like this one:

— and like any other pattern you insert, it should look (mostly) the same in your canvas, as in your preview. That "Les Nuits" pattern is about as opinionated as they come, suggesting 4 menu item labels to be "Home", "About", "Portfolio" and "Contact". But we already do that similarly for a Buttons pattern which suggests "Who We Are" and "Our Work" as preset labels, but with the link information missing.

So I kept at it, even exploring how we might implement squiggly lines in this codepen. What I like about this approach is that it could potentially scale to all patterns that are missing information:

I like that the squiggly line calls back to grammar suggestions from classic word processors: "something here needs your attention". I'm still chewing on the squiggly line, but I like that it's so basic and theoretically scalable to all patterns that need extra user configuration to work.

[jordesign]

Closing this issue as we now have a different placeholder state for new menus - and enough has changed in 2+ years that we can revisit this with a new issue (referencing the current state if needed.