-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A polished local nav component #535
Comments
I think this is looking really great @fcoveram 🙌 So long as this approach passes accessibility tests, I love it. |
Very effective solution. Accessibility may be an issue.
|
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. |
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)
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.
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. |
Thanks for the deliberate work and attention to detail Francisco, this is lovely work and a strong direction.
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. |
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). |
Fantastic contribution |
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. L1AL1BL2AL2BL3 |
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. |
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. |
I like this idea
I will clean up the Figma file and put all mockups and components in the "Design" page. |
The designs are ready. I added a few notes to convey the style specs accurately. |
I'm trying to roll out the changes incrementally, so here's a status update: On production:
In review:
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 |
Perfect. Looking forward to reviewing once merged.
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. |
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. |
@StevenDufresne's review pointed out an issue with my approach here. In all the designs, there is a page title ( 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)? |
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:
|
The logic here is:
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. |
To @ryelle's point
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. |
@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?
Okay, I'll get that updated and use that for WordPress/wporg-developer#500. |
Oh now I understand. Sorry for the confusion.
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. |
Quick status update: The local navs have been updated on Developer, About, Downloads (no change), Dev Blog, & the in-progress Pattern Directory. Sites left:
|
I think we can do Forums in a future iteration when updating the breadcrumbs. |
Regarding the separate section in the Learn local nav for My Courses, I've added a temporary styling solution until we support this properly in the local navigation block. Issue: WordPress/Learn#2481 |
Do you need me to create an issue for including the links related to the user account? |
Yes please! |
Sorry for being late @adamwoodnz, I created #621 introducing the idea. |
- Updates the style of Rosetta news header to black, fixes the top-border on local nav - Add archive & page title to the news posts - Fix the site title link color on Download subpages See WordPress/wporg-mu-plugins#535
The site title should be visible on scroll on the homepage, and always visible on interior pages. See WordPress/wporg-mu-plugins#535. git-svn-id: https://meta.svn.wordpress.org/sites/trunk@13866 74240141-8908-4e6f-9713-ba540dce6ec7
I think at this point all of the sites have been updated with this iteration of the local navigation bar styles. If anyone notices any pages that were missed, or are using the wrong L* layout, open a new issue in the respective github project. |
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.
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?
The text was updated successfully, but these errors were encountered: