A polished local nav component

[fcoveram]

Now that the new Showcase has been released, Developers section is in progress, and other designs are in a solid position, I noticed there is room for improvement to make navigation components more flexible and appealing when displaying location across the site.

I have been exploring different ideas, and this week I landed on a design that addresses key areas of navigation. Before dive into detail, here is a prototype involving four sections of the site.

Desktop.local.nav.v22-compressed.mp4

Mobile.local.nav.v22-compressed.mp4

---

In a previous comment, I mixed up the site depth taxonomy and the nested levels. That ended up confusing more and revisiting the breadcrumb location a few times. So to avoid new misunderstandings, I will refer to the page structure from the following logic.

Level	Example 1	Example 2	Example 3
Level 1	News	About WordPress	Showcase
Level 2	Community	Etiquette	The Line Hotels
Level 3	…	…	…

Components height

One minor spacing tweak across components is making global header, local nav, and breadcrumb components 70px height on big screens and 60px on small ones. This equivalency makes the layout reachable across breakpoints and eases the interaction shown in the video.

Current page visibility

When users are in level 2 pages not displayed in the local nav, the component shows the page name next to the section label. For level 3 and deeper pages, page name is hidden as breadcrumb takes that role. But once you scroll down, all pages, except for the section’s landing pages, show the page name. This will ease page and section recognition as the component remains fixed when you scroll down.

This change makes the site details page in Showcase simpler by removing breadcrumb above the cover image, whereas, deep pages in Documentation keep you in context as you scroll down in text-heavy posts.

Handy breadcrumb

From level 2 and deeper, “section and page” button expands the breadcrumb pages in the local nav, similarly to global header dropdown. When you are in level 3 and deeper pages, the breadcrumb bar appears below the local nav showing all parent pages.

On small screens, local nav and breadcrumb pages are hidden until you expand the chevron button. The full size view allows you to scroll the area in those cases where items listed go overflow.

---

The local nav variant needed per page level, as described above, can be summarized as the diagram below shows

This idea taps into the last changes applied to nav components, and I’m optimistic this change would clean layouts more and make more consistent the way of browsing the site.

What do you think?

[ndiego]

I think this is looking really great @fcoveram 🙌 So long as this approach passes accessibility tests, I love it.

[askdesign]

Very effective solution. Accessibility may be an issue.

• "Current page" treatment on black banner may be too subtle on levels 2 and 3.
• "Current page" treatment on level 3 white area looks good.

[ryelle]

I think this is a good iteration on the current navigation 👍🏻

Some of these technical details are already in place, like the sticky scrolling bar with W, site title, and local nav. The mobile version, where the dropdown includes more than just the navigation, might be tricky- hopefully we can work with the core block instead of needing to make a new one, but that could be a dev quagmire.

Currently this part of the bar is just paragraphs, so to create the dropdown we'll need to custom-build a block. the navigation dropdown will not work because it doesn't support non-link items. This plus the mobile changes could maybe be bundled into our existing Local Nav block.

As for design feedback…

In the "Level 3" pages, I think the dropdown would be redundant— for example the Harvard University mockup, there are 4 items in the dropdown: a heading, link to wp.org (exists in bar), link to showcase (exists in bar), and the current page (not a link). It makes sense for deeper levels (the docs mockup), but I wouldn't show it for L3.

(My note about click targets is more of a dev note— I assume the click target is the whole label, but we want to keep that a consistent string throughout the site (eg, "local navigation", "parent pages", or something) - we can do it by making the chevron the button & making it bigger with CSS.)

Do we need the two "Level 2" options? It's not trivial to conditionally show the page title based on whether the page is in the navigation (since it's a separate block). If we could always show the page title that would be better.

[fcoveram]

In the "Level 3" pages, I think the dropdown would be redundant (…) It makes sense for deeper levels (the docs mockup), but I wouldn't show it for L3.

I agree. And after testing different ideas, I don't see it as a problem. Since this header exists across all pages, I lean towards consistency and showing a single pattern rather than creating variants where some links are visible, or the whole popover is different. At first sight, the redundancy effect is hidden until you expand the dropdown. I'd like to see what other folks think of this (cc @jasmussen)

(My note about click targets is more of a dev note— I assume the click target is the whole label, but we want to keep that a consistent string throughout the site (eg, "local navigation", "parent pages", or something) - we can do it by making the chevron the button & making it bigger with CSS.)

On big screens, the target is label and icon. On small screens, the target area is 52px width and 60px height; slightly different to the current one. Although I can't remember why it couldn't be a box of 60px.

Big screens	Small screens

Do we need the two "Level 2" options? It's not trivial to conditionally show the page title based on whether the page is in the navigation (since it's a separate block). If we could always show the page title that would be better.

Showing the page title all the time, no matter whether it's in the local nav or not, was mainly to avoid visual redundancy. In opposition to the first point. The idea behind showing it while scrolling was the need to stand out the site context in pages strongly visual, like in the showcase details page and, eventually, the plugin details page. Both pages belong to the Extend group, and likely Themes and Patterns will look alike.

[jasmussen]

Thanks for the deliberate work and attention to detail Francisco, this is lovely work and a strong direction.

In the "Level 3" pages, I think the dropdown would be redundant (…) It makes sense for deeper levels (the docs mockup), but I wouldn't show it for L3.

I agree. And after testing different ideas, I don't see it as a problem. Since this header exists across all pages, I lean towards consistency and showing a single pattern rather than creating variants where some links are visible, or the whole popover is different. At first sight, the redundancy effect is hidden until you expand the dropdown.

One of the challenges we have for unification is mainly on Developers and Documentation. If you look at something like the Footnotes Block documentation, you have three breadcrumbs in addition to the link to the main landing page. Unifying that into a single row would be very space challenged, especially with 5 pinned items on the right of that same bar.

I believe that the motivation for the dropdown is to afford that space, an "eliding mechanism", if you will, so that you could fit breadcrumbs and pinned items in a single bar. This is kind of the holy grail that Francisco diligently has been reaching for, and as they say about reaching for the stars, you might not reach one, but you won't end up with a handful of mud either.

So this is a starry design, beautiful, and despite loving it, I'm not entirely convinced it will work for all pages. For things like Showcase, Hosting, Themes, Patterns, Plugins Blocks, — in fact, every section of WordPress except probably, those in the Learn category, it'll work beautifully. Notably the Learn section itself has some extremely long titles and categories, making it very hard to fit in a single bar.

So I still am not sure we're able to avoid having two versions of this — the unified version for most sections, and the stacked version for documentation. This is also because the full breadcrumb path feels valuable as a navigational aid in those sections, much less so for all the other, flatter sections.

And if we do end up with having the two versions, the dropdown in the unified version might not be needed. I also echo Kelly's concern, that it may be a technical challenge.

[ryelle]

I'm looking at it again and I think the "Harvard University" example is actually a "level 2" page, so it shouldn't have the dropdown.

@jasmussen's screenshot is a level 3 page, so it would, and in the dropdown would be "WordPress - Learn WordPress - Lessons - How to create a Lesson Plan". There's still redundancy there, but it's not all redundant. I also agree that it makes sense as a pattern for even more nested items (like this "level 5" handbook page).

[mpc]

Fantastic contribution

[fcoveram]

Sorry folks for not replying timely, I was working on a new iteration that address the redundancy point.

Design (i3)

Since showing breadcrumb in level 2 pages was the main point, removing it creates the variant @jasmussen mention. In that way, going to main homepage and section landing page is reachable from the global header and local navigation.

The page structure and what local header belongs to each remains the same, breadcrumb as dropdown was the only element removed. Here is a diagram with more notes

And here are the big picture per level type you can find in i3 page in the Figma file.

L1A

L1B

L2A

L2B

L3

[fcoveram]

As reported by @ryelle in this comment, the design above doesn't properly address showing local nav links on middle breakpoints. The remaining space stacks up the row and breaks down the layout.

I'm drawn to the following idea as it behaves like a transition towards the full-size menu in small screens

My question here is whether it is possible to detect when the links row overlaps the section name link to shift to this design. As you can see below, not all sections face this problem.

[ryelle]

My question here is whether it is possible to detect when the links row overlaps the section name link to shift to this design.

Maybe? It's possible, but I don't know if it would create too many edge-cases. It's worth exploring though. If it doesn't work, we could probably use different fixed breakpoints for each different site though, like Documentation drops to the chevron at <900px, but About stays with the 600px default.

I think we've got a good path here, and the next step is to start building so we can see if any other issues shake out.

[fcoveram]

…we could probably use different fixed breakpoints for each different site though, like Documentation drops to the chevron at <900px, but About stays with the 600px default.

I like this idea

…the next step is to start building so we can see if any other issues shake out.

I will clean up the Figma file and put all mockups and components in the "Design" page.

[fcoveram]

The designs are ready. I added a few notes to convey the style specs accurately.

[ryelle]

I'm trying to roll out the changes incrementally, so here's a status update:

On production:

• The breadcrumb updates are deployed, they should not wrap, instead they'll scroll offscreen
• The site title appears on scroll on Level 1 pages now, and multiple items can be in the "site title" section (code is on production, but site templates need to be updated)

In review:

• Local Navigation: Improve style and behavior across screen sizes #573 — update the navigation code to collapse the menu to fit on one line
• Header: Use different templates based on page heirarchy wporg-developer#500 — update the templates in Developer to use new variations

A design check on ^ would be good, though I'd like to get these merged before getting any detailed feedback - there are a few different blocks at play here, and it will be easier for you to see it in action on production.

One thing I noticed while doing this was in L3 where the page title appears on scroll, it looks strange with the animation. In the Developer PR above, I've left it appearing all the time. What do you think?

two-appear-on-scroll.mp4

[fcoveram]

A design check on ^ would be good, though I'd like to get these merged before getting any detailed feedback - there are a few different blocks at play here, and it will be easier for you to see it in action on production.

Perfect. Looking forward to reviewing once merged.

One thing I noticed while doing this was in L3 where the page title appears on scroll, it looks strange with the animation. In the Developer PR above, I've left it appearing all the time. What do you think?

I really like the animation. It's subtle and the transition effect does not caught big attention. But I'm open to hear other thoughts.

[ryelle]

I really like the animation. It's subtle and the transition effect does not caught big attention.

Personally, I think it's strange that the middle item stays still while the two around move & drop in. It worked when it was just the logo. Maybe the text could just appear, a fade-in with the same duration? But TBH I prefer all the text always visible, rather than having things changing on me.

[ryelle]

@StevenDufresne's review pointed out an issue with my approach here. In all the designs, there is a page title (h1) in the content on the homepage, so for the site title in the local nav bar, we can use a p tag. This is the same for desktop and mobile on almost all the sites, except Showcase. On showcase, the page title in content disappears, so the site title in the local nav bar needs to be an h1. This works now because the local-nav site title does not appear on desktop, so there is only ever one visible h1. Once we update this, the site title appearing on scroll on desktop will be invalid (there should be only 1 visible h1).

So my question, @fcoveram: Is this a pattern (of the page title in content disappearing on mobile) that will show up on other site designs? Should I account for it here, or could we simply work around it on showcase (likely by leaving the current behavior in place)?

[adamwoodnz]

I left some feedback on the PR regarding the site title being shown on the homepage:

Seems unnecessary to me to show the title on the homepage on tablet and mobile, especially as the local nav isn't sticky on those screen sizes, so it isn't visible once scrolled:

Tablet	Mobile	Scrolled

[fcoveram]

Is this a pattern (of the page title in content disappearing on mobile) that will show up on other site designs? Should I account for it here, or could we simply work around it on showcase (likely by leaving the current behavior in place)?

The logic here is:

• When page title ("Showcase", "News", "Documentation", etc) is in the cover area (just below local nav), then it's hidden in local nav.
• When page title is not in the cover area (like in About WordPress), then it's visible in local nav.

If you see Showcase, the same logic applies. On desktop, page title is only in cover area; whereas on mobile, it's in local nav. That's why L1 has variant A and B.

The general approach of "show or hide" for the page title lies on reducing redundancy. That is also the reason of showing page title when scrolling down as in many pages you might have page title in local nav, breadcrumb, and main content area just by landing on the page.

[fcoveram]

To @ryelle's point

Maybe the text could just appear, a fade-in with the same duration? But TBH I prefer all the text always visible, rather than having things changing on me.

Fade-in with the same duration works for me. My other comment above mentions why we decided to hide page title before scrolling in certain cases.

[ryelle]

@fcoveram I do understand the difference between the A/B variants. The question for Showcase (specifically) is that there's a technical issue with how we hide the page title on mobile (in content), which we don't do on the other sites that L1A. Will there be other sites that hide the site title in the page content (not local nav) only on mobile?

Fade-in with the same duration works for me.

Okay, I'll get that updated and use that for WordPress/wporg-developer#500.

[fcoveram]

Oh now I understand. Sorry for the confusion.

Will there be other sites that hide the site title in the page content (not local nav) only on mobile?

Probably yes. Themes, Plugins and Patterns belong to the Extend group, and given that sites part of a group share design features, there are high chances of make a single content more predominant in the hero section on mobile.

[ryelle]

Quick status update: The local navs have been updated on Developer, About, Downloads (no change), Dev Blog, & the in-progress Pattern Directory.

Sites left:

• Documentation
• Rosetta: News archive & posts — should there be a local nav? what Lx should these use?
• Events — no change needed?
• Showcase
• Forums

[adamwoodnz]

Sites left:

I think we can do Forums in a future iteration when updating the breadcrumbs.