navigation: flatten menu hierarchy #593
Conversation
|
Hmm, not sure about this. If later we want to add more pages then we'll need to redo something like this again. Curious what @pastelsky and @bebraw think about this. |
|
Losing "Documentation" category and flattening it up might not be a bad idea so 👍 from me. I'll leave the final decision to @skipjack and @pastelsky, though. |
|
I split it up because we were running up against the limit. Although 7 isn't really a UX issue, as your article states, we have plans to add other top-level links (e.g. to the blog) there as well. And in our setup on certain screen sizes we were starting to run up against other elements. So as @SpaceK33z mentioned I think we would end up going back to something like this pretty quickly. What about renaming the Documentation link to Reference or otherwise re-organizing the links to address the confusion? |
|
For instance: while rewriting the shimming docs, I found myself jumping around between the following pages:
Another approach would be to list /concepts, /guides also in the submenu of /documentation. Whether we then keep their top menu entries is a matter of taste. |
|
I don't see any harm in flattening now esp. due to that jumping issue (annoying extra clicks). Maybe secondary links, like blog, can go to some other place. |
|
@simon04 yea I'd definitely lean towards the second approach:
@bebraw as per your point:
I've heard a few times now that the sidecar links are fairly undiscoverable and I'm starting to agree. Looking at some other docs sites like React, Babel and ESLint they all link to their blog and github pages in their top navigation. Regardless of this, even adding one more regular link to the nav will put us over the limit and likely cause UI issues with links overlapping the logo on smaller screens. We're bumping into the limit in the footer as well, and while maybe we should expand it to a larger height and different layout, those links are much less discoverable than the ones in the banner. I can see this going either way right now, but I do think we're going to end up going back to a similar setup at some point. |
Also aligning the submenu to the right or parts of the main menu to the left doesn't look so bad:
|
|
It is good to note how ESLint tackles it. You can access the hierarchy from the front page without having to visit the pages themselves. Based on that I would say if you could hover on top of documentation and see the submenu below it while you are on some other page, that would go a long way. |
|
@bebraw that's true, displaying the menu on hover could work. |
|
What about (with improved spacing):
|
|
@simon04 yea something like that but without the multi-colored backgrounds and we'd probably leave the gitter link out and add some kind of fixed "Find Help" button or something for it instead. Personally, I'd prefer "Concepts", "Guides" and "Reference" (instead of Documentation) with the hover behavior @bebraw mentioned. Either way though, I'm going to close this for now and open this discussion again in an issue soon. We're working abstracting the banner (and other stuff, see #301), so I'll make sure to keep all this stuff in mind (icons, hover, etc.) as I get react-banner ready for it's first working release. If others bring up the navigation as a problem before then, then we can push one of the quick fixes we've discussed. |
One says (e.g. here) that it's okay to have up to 7 menu entries. I find the current splitting rather confusing (why is "guides" not part of "documentation"?)