Design singular navigation

[hoosteeno]

We will collapse our two navigation systems into a single global navigation and footer under the Mozilla brand. This card is about the design work required to specify that navigation.

Here are some principles that I hope we can deliver in a new navigation design:

1. It helps visitors (users & search robots) know where they are, discover what to do next, and move easily to the most important content on our site:
   • Browsers and supplementary information about browsers
   • Other products, in order of marketing priority (VPN, Pocket, FB Container, Monitor, etc.)
   • Information about Mozilla, most importantly information that effectively communicates our excellence
   • Developer and innovation content, mostly links to external sites
2. It anticipates the certainty that we will add new products and content types, and remove products and content types, without requiring a full redesign.
3. It is consistent across the entire website.

We should produce a few options with a strong recommendation and attach to this issue.

Success

• [x] Approved designs attached to this issue

Approvals

• [ ] Marketing executive
• [x] Websites team lead
• [ ] Websites dev
• [x] Websites design

[alexgibson]

We should consider the footer here also as the content is complimentary to the navigation.

[hoosteeno]

Assigning to @justinkropp

[justinkropp]

@hoosteeno @rraue Here's a working draft of the navigation proposal (both primary and footer navigation systems). Attaching here for reference.

[justinkropp]

Following up on the working draft above, attached is a visual skeleton of the proposed navigation.

---

[hoosteeno]

Thanks @justinkropp ! Some questions here for you:

• Are the top-level items clickable? I think @rraue wants them to be.
• The spec should probably note a couple things: When content doesn't exist yet (e.g. product promise) When the text of the thing in the nav is still TBD (e.g. Firefox Blog)

And some questions for @kiiirby:

• Can you confirm the contents & order of items in Browsers/Products section, sometime in the next few days? Don't over rotate -- we can change this. Getting it live with a pretty good set is the goal. And remember: A spot in nav is free traffic to the thing, so if you're on the fence, leaving it in is probably fine.

[Kiiirby]

All these products look good, Tyler and I recommend re-ordering like this:

[Kiiirby]

Firefox Monitor Facebook Container Mozilla VPN Pocket Product Promise Firefox Relay Firefox FPN

(with Beta products below the product promise)

[Kiiirby]

And the two Beta products (Relay and FPN) denoted as such.

[justinkropp]

Thanks for the clarification on order. I'll update the IA doc to reflect the change and to denote the beta products.

[Kiiirby]

Great, thanks!

On Tue, Sep 8, 2020, 12:35 PM Justin Kropp notifications@github.com wrote:

Thanks for the clarification on order. I'll update the IA doc to reflect the change and to denote the beta products.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/bedrock/issues/9286#issuecomment-689090965, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFVBEUMGZEMVNCQ6IXPZM73SE2BONANCNFSM4PWY7N7Q .

[hoosteeno]

@rraue Can you tell us whether "Firefox for Enterprise" needs a spot in the Browsers menu?

[Kiiirby]

@justinkropp actually, let's use this order, please (let's put Pocket before VPN bc Pocket is our #2 source of rev)

Firefox Monitor Facebook Container Pocket Mozilla VPN Product Promise Firefox Relay Firefox FPN

[rraue]

Enterprise not necessarily needs to be in the main nav (depends more on our priorities than SEO) but if not it should be in the footer.

[rraue]

Enterprise not necessarily needs to be in the main nav (depends more on our priorities than SEO) but if not it should be in the footer.

[justinkropp]

@Kiiirby @rraue 👍

[justinkropp]

Updated nav IA. I've reordered items based on @Kiiirby's suggestions above. I've also included a key to denote names that aren't final and new content.

---

[hoosteeno]

@justinkropp to get hi-fi designs in front of us this week.

[justinkropp]

Below are a few screens that illustrate the design work I've been doing on a unified global nav. Some things to keep in mind when viewing:

1. This is an initial proposal
2. I haven't started adding specs yet, as I'd like to get agreement first; but the sizing is largely based on the work JRouse and I were doing on this system before (H2, 2019)
3. I haven't included how the nav works on smaller viewports, but I will resume that work based on feedback on below.
4. Primary nav :hover styles are TBD
5. Items shown in the drop-down menus are simple lists and can wrap accordingly.

---

This unified nav is meant to be as flexible as possible, giving us the ability to add current and new products and services as they arise, and irrespective of brand they live in.

Items that live in the primary navbar should be able to increase or decrease in number.

It should be able to accommodate, where appropriate, various CTA configurations (Join, Download, Sign In, etc.)

Not every item in the drop-down menu needs an icon (I'd actually prefer they don't all have icons).

---

---

---

---

---

I may be forgetting something in the above, so please ping me here for feedback, questions, and suggestions.

[hoosteeno]

I have reviewed this and it looks like excellent work. Thank you, @justinkropp .

@craigcook can you give this a review and call out any gaps/questions/improvements?

[justinkropp]

Below is the high-fidelity design work for the footer (desktop only right now). This reflects the proposed approach to the footer above. Given that the proposal for this footer is that it will be global and live across all our web surfaces, it should be easily adaptable -- color-wise -- to fit in aesthetically with the surface it lives on: a Mozilla product, a Firefox product, or another yet-to-be-built product.

I'm proposing that our Firefox pages adopt the light footer, our Mozilla pages adopt the black footer, and the Ink footer be reserved for edge cases.

I also think it would be worth investing in a "lightweight" footer for pages like Monitor or Relay where our full-content footer might not make the most sense to include from a ux perspective. Exploration of a compact footer is forthcoming.

---

---

---

[rraue]

One thing about the footer: as we move back to one nav/footer, shouldnt be mozilla and firefox social accounts in the footer @justinkropp ?

[justinkropp]

@rraue Ah, yes! Good catch. I've updated the above footer design to include a column that would point to both our Mozilla and Firefox social media account links.

---

[justinkropp]

@craigcook Did you have any initial thoughts or questions regarding the above navigation and footer design work?

[craigcook]

I really like the look of this, and I like the smaller, more focused dropdowns (I especially like the absence of those promo cards our current dropdowns have). The architecture also seems good for mozorg but I'm also thinking about this nav being a reusable component that can work for any other site.

Here's a bunch of thoughts in no particular order, just stream-of-conscious. The tl;dr is that I see no major red flags, just a few details that could prove tricky to build and/or some options to explore. We can solve any more issues during the dev stage and nothing here is blocking us from starting to write code.

• The language dropdown in the footer may take some doing to style it as shown (it's a form select that doesn't look like other form selects). It's doable, but it's breaking away from our established form styles. We may want to at least see how it looks with a more standard form treatment.
• The language dropdown also doesn't have a label. We can include a hidden label for screen-readers but visible labels are nice for everyone. We can see how it looks with a label and figure out what works best.
• The main nav will need responsiveness work, but I think it can follow what we currently do (tightening spacing and reducing the text at mid-size breakpoints, then switching to a hamburger menu at smaller ones). This will be much easier to work out once we have a prototype in a browser.
• We don't yet have a design for what this should look like on mobile. We may be able to keep our current mobile menu mostly as-is but the items inside the collapsed sections will probably look different. Again, I think we can work this out in a prototype without a high-def mockup.
• The gap between the navbar and the dropdown could prove troublesome because we'll need to make sure the dropdown remains open when the mouse pointer is in that gap. There are ways to make this work, just flagging it as a possible problem area.
• The extra wide gaps between some column in the footer seem odd, presumably they're meant to collect columns into logical groups. If that's the case we'll have to think about how to structure those groups in markup that will offer flexibility for different groupings, numbers of columns, etc. But it might also look fine with regular column gaps and no grouping. Worth trying it a few ways.
• I don't think we've had breadcrumbs in bedrock for a long time, we'll have to figure out how best to manage that in our templates. I think we might have had a helper/utility at some point and maybe we still do. Need to investigate.
• We should think about how breadcrumbs might be a modular component that could appear in other parts of the page. Could that same bar appear under the main nav? Or under a subnav? Might it need a style variant depending on where it is? We can tinker with it.
• The footer seems a little low-contrast in the screenshots but we can see how it looks in a browser. Might need to darken/lighten the text.
• We may need to refine some rules for mixing icons/non-icons in dropdowns. Presumably an entire column needs to be one or the other, since mixing within a column wouldn't line things up properly (unless the non-icon items still have space where an icon would go).
• When there's a non-icon column next to an icon column, it feels like the non-icon item is related to the icon item on the same row… The icons are such a strong element I feel like I'm seeing a single column of three rows, not two separate columns. So each row feels visually connected but the actual content is unrelated. Maybe a little more space between columns would help it "read" as a column, or even a line dividing them (but that might be too much).

[alexgibson]

The gap between the navbar and the dropdown could prove troublesome because we'll need to make sure the dropdown remains open when the mouse pointer is in that gap. There are ways to make this work, just flagging it as a possible problem area.

I seem remember an early prototype of the current nav having this gap. I don’t know if this will be useful here, but one way I got around this was to make an invisible pseudo element between the top nav link and the panel open below it, so the mouse pointer would remain in an active hover state when moving between the elements. It was fiddly to get right, but seemed to work out ok.

[rraue]

Two thoughts:

• Next to the language switcher we need a link to /locales/ for crawlers and as fallback. It can be the world bowl.
• Breadcrumb: If we implement the breadcrumb most likely search engines will pick them up and display them in search results instead of the url. What is a good thing. But that means we need to think about the system here: -- By default the url slug should be the breadcrumb slug -- We have - in our urls, we need to replace them with spaces -- We should make the breadcrumb slug translateable -- We should be able to set a different slug easy

Especially the last point is important, as we could change the not really good new on /new with something like Download and make it even translateable, what should get us better ctr in search results.

[craigcook]

Final copy doc: https://docs.google.com/document/d/1itYgUIVud_i7D69ci93KinVekCDOE-pm5R7vH9bN_Pc/edit Demo site: https://www-demo1.allizom.org/