Nav component: Header

[fcoveram]

I recently revisited the whole site and created this Information Architecture (IA) map to outline the site's page structure, understand how the navigation works and find room for improvement. I’m calling L1 (level one) to all pages presented in the header such as Learn, Make, About WordPress, etc; and L2 (level two) to the first child pages like News/Releases, Photo Directory/Submit, About/Features, and others.

Although the site is not deep, each section has its distinct navigation style. Here is a quick recap of all existing layouts.

As a result, the site provides inconsistent navigations and forces users to learn how each section works, especially new visitors. The subnavigation area is more problematic as it shows either internal pages or customized links in similar layouts without clear distinction.

I proposed tackling this inconsistency with two header variants: Header with hero and Header with subnavigation.

Header with hero (L1)

For the first header, I suggested making the following changes:

• Keep a link to L1 page visible all the time to reinforce where users are.
• Divide the internal pages and customized links sections to avoid confusion in the site location.
• Show the page name. Especially where page name and H1 are different, or the latter doesn’t even exist. “Forums” heading is “Support”, and “About WordPress” has a different heading.

Here is a wireframe with all possible links and actions, based on the header audit.

And here is a quick mockup exercise for existing pages.

Header with subnavigation (L2)

For the header with a subnavigation, we have two possible paths where I would like your thoughts.

1. Idea 1 → Treat the header as a site menu that shows all L2 pages. For multiple L2 pages, the menu shifts to a dropdown, like in News. In cases where the site is deeper, showing a breadcrumb might be necessary, but the main point is reinforcing the idea of section identities and how diverse the WordPress site is.
2. Idea 2 → Show a breadcrumb that mixes a dropdown behavior to strengthen the site location. This work well where you dive into posts and jump between sections, like in “Documentation” and “Forums”.

Here is a wireframe for the two paths described above

And here are mockups picking some internal pages.

Idea 1

Idea 2

---

Note: These suggestions put aside the Make blogs as they likely would inherit a different navigation layout.

This idea is not written in stone, so please leave your thoughts and possible use cases I’ve missed.

Tickets related:

• wporg-mu-plugins#360
• About Page: Consider breadcrumbs for The People, The Technology, The Details wporg-main-2022#255

[ryelle]

Whoops, I read too quickly and saw the global nav difference in the News screenshots and thought this was about the global nav— you had the right repo first 😅

[ryelle]

tl;dr — Idea 1 feels more straightforward, I have more questions about Idea 2.

Idea 1 → Treat the header as a site menu that shows all L2 pages. For multiple L2 pages, the menu shifts to a dropdown, like in News.

The idea mocked up in the Developers screenshot would be significantly easier to implement, since that could be a menu dropdown that uses the existing Nav block. For example, I could make that happen almost immediately:

The News-style mega-menu dropdown (like this) would need to be a custom block, and would probably mean we need to code up at least two variations of the local nav bar — one with a plain nav menu and one with the mega-menu. Again, this isn't meant to say we can't, just that it increases the complexity.

In cases where the site is deeper, showing a breadcrumb might be necessary, but the main point is reinforcing the idea of section identities and how diverse the WordPress site is.

In the mockups with breadcrumbs, they're now outside of the local nav bar. Can we assume that the left part of the nav bar will always be the section title (ex, About, Download - or site title, when they're separate sites like Plugins, Themes)?

Will this be too many nav-ish bars when we're on archive pages of the directories? On the homepages they'll have the big header to separate nav & filter, but archives typically use the internal pages pattern, for example, Patterns

Also, are we dropping local search boxes from the header area?

semi-related but nitpicky, when this is finalized can we also set one breadcrumb separator for all instances? We've got mid-dots, slashes, and now arrows.

Idea 2 → Show a breadcrumb that mixes a dropdown behavior to strengthen the site location. This work well where you dive into posts and jump between sections, like in “Documentation” and “Forums”.

Maybe I'm stuck with the "old site" way of doing things, but this seems like an unexpected interaction pattern to me. I feel like I wouldn't know what level of nav to appear under these dropdowns (sibling or child pages).

Would we stop using the nested breadcrumbs like Documentation, or would it be possible to have multiple dropdowns?

It looks like this is still using the dropdown top right nav in some examples, would that be a simple nav dropdown or might we still need the mega-menu pattern in this version?

[jasmussen]

Do we need a border below the 2nd navbar?

[fcoveram]

The idea mocked up in the Developers screenshot would be significantly easier to implement,

I don't follow the idea. The screenshot you added is based on Idea 1, but it shows the breadcrumb in the subnav area and the menu doesn't list all L2 pages, just the ones in "The people" category.

In the mockups with breadcrumbs, they're now outside of the local nav bar. Can we assume that the left part of the nav bar will always be the section title (ex, About, Download - or site title, when they're separate sites like Plugins, Themes)?

I hear your point, and I'm not sure how to solve the name duplication. Having the page name in the subnav area and in the breadcrumb at the same time looks visually odd, but necessary for location and consistency. Here is a quick mockup of my point.

I'm open to any ideas for this.

Will this be too many nav-ish bars when we're on archive pages of the directories?

In this transitional stage, it does look busy and stacked. But in the current redesigns, there is always a section between header and filter bar as the latter refreshes the content area placed below. This is visible in Showcase, Themes, and Patterns figma files.

Also, are we dropping local search boxes from the header area?

This is open to discussion. But I'm drawn to move it to the hero section and make it consistent across Showcase, Themes, Patterns, and Plugins.

when this is finalized can we also set one breadcrumb separator for all instances? We've got mid-dots, slashes, and now arrows.

Very much agree.

…this seems like an unexpected interaction pattern to me. I feel like I wouldn't know what level of nav to appear under these dropdowns (sibling or child pages). Would we stop using the nested breadcrumbs like Documentation, or would it be possible to have multiple dropdowns?

I was thinking of multiple dropdowns. The navigation is definitely not common and seeing sibling pages felt obvious to me as the breadcrumb layout shows parent pages on the left and child pages on the right. But I might be wrong so I would appreciate what other folks think.

This is still using the dropdown top right nav in some examples, would that be a simple nav dropdown or might we still need the mega-menu pattern in this version?

For related links a simple dropdown. I can't envision the mega menu in other sections, it fits with News content only.

[ryelle]

I don't follow the idea. The screenshot you added is based on Idea 1, but it shows the breadcrumb in the subnav area and the menu doesn't list all L2 pages, just the ones in "The people" category.

Ah, I spent about 5 min hacking this into an existing branch so yeah, it didn't cover everything. I just wanted to differentiate the default dropdown from the mega-menu design.

How's this attempt?

I hear your point, and I'm not sure how to solve the name duplication. Having the page name in the subnav area and in the breadcrumb at the same time looks visually odd, but necessary for location and consistency. Here is a quick mockup of my point.

I didn't really mean that as a critique, just confirming my assumption of what each item is in the mockup.

[StevenDufresne]

I hear your point, and I'm not sure how to solve the name duplication. Having the page name in the subnav area and in the breadcrumb at the same time looks visually odd, but necessary for location and consistency. Here is a quick mockup of my point.

Original Image

I'm open to any ideas for this.

Is there an argument for using the top level category to tie the sub-sites together? I don't really like having breadcrumbs share a container that also has variable width. See context.

Edit
I see one downside; the related links are based on sub-site and not top level category.

[fcoveram]

To @ryelle's point

How's this attempt?

The dropdown looks good, but splitting the L2 pages into three dropdowns would be confusing. Idea 1 shows all pages in the available or one dropdown with all pages. For this case, it could look like the following mockup.

Note: The category sections and active style in the popover are for the argument and don't intend to establish a frontend decision.

To @StevenDufresne's point

Is there an argument for using the top level category to tie the sub-sites together? I don't really like having breadcrumbs share a container that also has variable width. See context.

I agree with not putting the breadcrumb next to another variable-width element. That's why Idea 1 places it below the subnavigation while Idea 2 has a single dropdown on the right side that occasionally exists. To your concern, Idea 1 fits better for tackling long breadcrumbs.

I see one downside; the related links are based on sub-site and not top level category.

With the top level category you mean "Download & Extend", "Learn", and so on? If so, I don't understand why showing a related link dropdown in subsites (Themes, Documentation, for picking some) that nowadays have it in the subnav area could be a problem.

[ryelle]

The issue with a long dropdown is what happens on short screens, since the nav bar is sticky:

nav-scroll.mp4

I don't find it confusing that there are 3 dropdowns, to me it makes it clear the structure of the section. Besides, "the technology" "the details" etc are not real pages, which works nicely if these are "click to open" nav menus.

Is the label for the dropdown meant to be the current page title? For consistency (and a11y), it would be better if the menu label was the same for all pages in a section (or said differently, any time a menu is used, it should have the same top-level label).

[fcoveram]

You're right. The dropdown does look long.

I explained myself wrongly. It's not confusing in terms of understanding their purpose and what displays, but confusing as it adds a new subnav variant, either if we go with idea 1 or 2. This would be the only site section with three dropdowns and I think we should avoid creating customized navigations.

In that vein, the hiding the menu suggestion looks better to me as the About WordPress section has a component at the end of the page listing all pages.

Is the label for the dropdown meant to be the current page title?

That was the initial idea. But if it affects a11y, then we would need to find a static label. "Menu" is the first idea that comes to me, but it feels outdated.

[ryelle]

It's not confusing in terms of understanding their purpose and what displays, but confusing as it adds a new subnav variant, either if we go with idea 1 or 2.

I don't see how this is a significantly different variation on Idea 1 — this is how menus work. Technically, there's no difference between a flat menu, a single submenu, & multiple submenus, it's all just a Navigation block.

There's also already a possible second dropdown in the header with "related links" (and I don't think that would exist on About), so it's just one more jump to the 3-submenu list.

In that vein, the WordPress/wporg-main-2022#255 (comment) suggestion looks better to me as the About WordPress section has a component at the end of the page listing all pages.

I'm fine with that solution too — I'm only pushing about this to make sure we have something that will work in all future use cases too.

That was the initial idea. But if it affects a11y, then we would need to find a static label. "Menu" is the first idea that comes to me, but it feels outdated.

Maybe it's dated, but that just means it's understandable, IMO. Though that could be another point in the 3-dropdown menu's favor, we can use the section titles as top-level menu items (won't help much for other sites, though).

[StevenDufresne]

This is a great discussion, let me try to summarize so we can align and find action items.

Points:

1. We appear to be leaning towards Idea 1.
2. We are leaning towards having breadcrumbs under the subnav and not in it.
3. We aren't sure whether to use the Sub-site title or the top level category title in the subnav, above the breadcrumbs
4. We like the idea of a dropdown for subsites with many L2 pages, but listing them vertically would make the menu too long. We could use the news mega menu, just a bit more work.
5. Instead of a mega menu, we could go with multiple dropdown menus. We're a bit hesitant because we would have both a mega menu paradigm and a multi menu paradigm. We should probably choose only one.
6. For the dropdown, we aren't sure what label to add when the dropdown is closed, probably just "menu" or "pages".
7. We are tempted to remove the menu items from the about section.
8. We are leaning towards removing the search bar from the nav and repurposing it elsewhere in the pages/directories.

Is this a fair assessment of where we are at in this discussion?

[ryelle]

I think we've just about dismissed the mega menu — it would require a new custom block, and a separate header pattern, while using regular menus (flat, single dropdown, or multiple dropdowns) would all use the nav block.

We are leaning towards removing the search bar from the nav and repurposing it elsewhere in the pages/directories.

Regarding search, there's feedback here that having the search where it is on documentation & developer does not make much sense from document-structure point of view (because it's visually in a sidebar, but technically it's inside the article, right after the title — the small-screen view makes this clear). I don't know if search placement is part of this site-header discussion, but if we pick a consistent place for it that might help those sites too.

[fcoveram]

Going back here after several days.

Now that Showcase designs are done, I want to share and idea I had when made the first wireframes on how global and subsite headers can work together.

Header.idea.i1.2.mp4

The idea's core is to keep the subsite navigation visible to provide more context of the content displayed as subsites are different to each. Specially when landing on a specific page without going through the global nav.

Both headers have small spacing tweaks to make them look similar, and global nav items that expand a menu in hover are now single elements that show the menu with a click. This latter point is based on the idea of disabling the redirect to the first page, like Download & Extend > Get WordPress and Community > Make WordPress.

I'm unaware of its feasability, but sharing it here to sparkle discussion and see your thoughts (cc @WordPress/meta-design)

[jasmussen]

I like it, it feels valid to me, and should mostly be a matter of applying a position: sticky;

[ryelle]

position: sticky would only control the stickiness, not the hide/appear logo & local site name, or the menu appearing on scroll up. We can give building it a try if this is a go, but just to be clear, it's definitely not going to be that simple 🙂

Personally, I dislike the menu-on-scroll-up since it changes the header size, often it ends up covering the thing i'm scrolling up to read.

[StevenDufresne]

I tend to agree with @ryelle. These menus feel nice but I don't find the links compelling. I don't know why I would be browsing the showcase sites and decide I all-of-a-sudden want to submit a site and even "view all sites" because that doesn't provide me with a more useful view of sites until I exhaust the list i'm currently viewing (get to the bottom). I would also make the same argument for most of our sub-sites.

[jasmussen]

This may be more valid on some sections, like Documentation, Learn, Developer Resources, than Showcase. I don't know if we'd want this as a generic one for all.

[ryelle]

For what it's worth, my issue isn't with the local site navigation, it's the fact that the global nav appears when you scroll up (see at 0:21 on the video above). I would prefer it stays at the top of the page, so I scroll all the way to the top and let the local nav unstick to see it.

I don't know if we'd want this as a generic one for all.

So if a site like showcase didn't have a local header, would the global header still be sticky at the top of the page when scrolling (current behavior)? If so, there's a divergence, and we should be very clear about when that happens.

[jasmussen]

Right, that the "home" logo fades in! I'd be happy to omit that bit entirely,so it's literally only the local header that sticks, and no change to the content of it.

And no, I don't think we'd want any divergence if we could avoid it. The sticky is most useful for the local header.

[fcoveram]

I agree with the odd effect caused by two headers.

The main reason for showing it was to keep the global navigation visible "all the time," acknowledging the scroll-up interaction to see it.

But I'm very drawn to only show the local navigation ✨

[ryelle]

This scrolling question has come up again since Showcase now needs breadcrumbs, so I'd like to get this sorted out. For easier reference, I've mocked up the different options in code & have some screen recordings. The admin bar is visible for me because I have access to the site. For most people it would not be visible.

First, a quick reference for what these are called in code & block names so we're all discussing the same things.

Sticky variations

Global header stays sticky, local nav bar is sticky, breadcrumbs are not sticky. This is basically the current behavior if we just drop the breadcrumbs in.

trunk-muplugins.mp4

---

Everything is sticky — this takes over ~250px of screen height, so I doubt we want this :)

allsticky.mp4

---

Global header is not sticky, local nav bar is sticky, and breadcrumbs are sticky. This changes the global header behavior on all sites, not just ones with local navigations.

two-bars.mp4

The unstickied global header on a classic theme

classic-no-sticky.mp4

---

Global header is not sticky, local nav bar is sticky, and breadcrumbs are not sticky. This version only has one sticky bar, but it might be weird that it's the middle bar?

one-bar.mp4

---

I have the code for all of this in local branches, and I'd love to figure it out before I go on sabbatical, just so it's in place for all the other redesign sites (this already affects Documentation & Developer which took different directions 😑 ).

cc @WordPress/meta-design @ndiego @adamwoodnz @StevenDufresne @renintw

[jasmussen]

I would lean towards two-bars.mp4, with one-bar.mp4 as another option that would be acceptable.

I believe both of those also honor Franciscos concept here, even if we won't be making the logo-moving-down change.

[marko-srb]

Yep, @fcoveram's proposal seems great, for scroll down (loose global nav) when start going back (appear global nav)...

So, two bars example from Kelly + putting back global nav whenever user scrolls up...

[ryelle]

Right, this expands on @fcoveram's idea, trying to flesh out how it should work in all cases, not just the ideal redesign homepage case, and iterating based on the conversation that followed.

So for "two bars": It would show both local nav & breadcrumbs when both exist, or just local nav when there are no breadcrumbs, and no sticky header at all on classic themes.

"One bar" would leave only the local nav sticky, regardless of breadcrumbs.

putting back global nav whenever user scrolls up...

I feel strongly about not doing that, it's probably my most hated web pattern TBH. A header appearing like that almost always covers the thing I've just scrolled up to read, then I end up wiggling my scroll to get rid of it, and now I'm annoyed at the website. I would rather keep the 3 bars sticky always and reduce vertical space than surprise people with randomly-appearing banners.

even if we won't be making the logo-moving-down change.

I did add the "logo moving down" in my prototype, you can see it in both two-bars.mp4 and one-bar.mp4.

[jasmussen]

I did add the "logo moving down" in my prototype, you can see it in both two-bars.mp4 and one-bar.mp4

Oh you're saying that's possible? If yes, I'm into it! I'm mostly noting, if it wasn't possible, that particular sticky behavior would still be good.

[ryelle]

Yes, the prototype was working code :)

Should I make that into a PR? It might be a good idea to bundle this change in with the other header menu changes, since it will change the behavior of the global header menu.

[jasmussen]

I'm into it! I also know you've got some AFK coming up, might be nice to store in a PR for someone else to potentially pick up.

[ryelle]

Since this was shared in slack as part of moving it to wporg-mu-plugins, here's a quick summary — all the component parts exist now, the global header, local navigation bar, and breadcrumbs are all custom blocks. There's a separate issue for whether the mobile menu for local navigation should use the "menu" word or a chevron #463.

The last task out of this issue is deciding how all the bars should scroll. From the conversation above, I've made the PR #466, which unsticks the global header and makes the local navigation sticky, with the option of sticking the breadcrumbs bar (two-bars.mp4 in the prototype videos).

[fcoveram]

Thanks for continuing iterating on this idea. From @ryelle's examples, I'm definitely drawn to the one-bar.mp4 version. Keeping the breadcrumb sticky is a little bit redundant as the local nav allows going to similar pages.

Reducing the global header's height to mirror the local nav one was based on the existence of the admin bar to make the whole header area smaller. Having the admin bar and local nav sticky when scrolling down does not overwhelm the page.

Finally, I agree with not showing the global bar when scrolling up, as per the reasons shared by Kelly.

[jasmussen]

One bar would also be a better place to start, if we are even slightly in doubt, then it would be easier (presumably) to change to two-bars if feedback suggests it.

[adamwoodnz]

Closed by #495

[adamwoodnz]

Trac updated in https://meta.trac.wordpress.org/changeset/12966