WIP: Navigation

[dromo77]

Overview

This isn't quite ready for review so I'm creating a draft PR. Most of the stylistic feedback has been addressed. The changes from the last iteration include:

• Increasing the touch target size for navigation links
• Update the cursor to be consistent for buttons, accordions, and links
• Increase color contrast to pass WCAG’s AAA specification
• Fix spacing between elements on the home page
• Implement a version of headsup.js to improve the sticky the header experience
• Increase the height of the menu on small screens to cover the screen. When content was visible behind the menu it felt distracting.

Issues that Need Feedback

To help provide a better idea of how the navigation works with a larger number of items I added some placeholder content (which will need to be removed before a PR). This introduced some new challenges around handling overflow, specifically the sidebar on large screens.

I kept the sidebar fixed, which I think works well on the “Prototypes” overview page where the list is shorter. If the page content is really long and the user has scrolled to the bottom of the page, they don’t have to scroll back to the top to view the sidebar. However, I think it’s less successful on the “Patterns” overview page, where the sidebar overflows. All three big containing elements on the page (header, sidebar, content) have different scrolling mechanisms and it feels a bit odd.

I’m curious what others think about the fixed sidebar.

Next Steps

I'm not sure what changes will be needed for the final dev implementation, but I'd love to get this to a point where it's ready for a PR.

[Paul-Hebert]

Hey @dromo77 ,

This is looking great! 😄

I agree that the fixed sidebar feels odd when the sidebar content extends past its container. It also introduces some funky behavior with the sticky header. I'm inclined to remove the fixed behavior of the sidebar. What do you think?

I noticed one other nit: The links in the top level nav don't appear to be centered vertically.

If we can address the fixed behavior and the nav centering I think this is good to go from a design perspective!

Next Steps

I think we should chat about the best way to proceed from there. I know you mentioned that you'd appreciate help on the final dev implementation. It seems like there are a few different ways we could handle this:

1. Treat this as a "prototype" branch

One option is to handle this how we would on a client project with defined prototyping and implementation phases. We could treat this as the "prototype" and have a dev make a new branch off master where they recreated your design work, with a focus on accessibility, performance, best practices, etc.

The downside of this approach is we may be reinventing the wheel a bit.

2. Continue work in your current branch

Another option is to have a dev start a branch off of your current branch. They would then go through and make changes to your existing work where necessary.

3. Merge this branch and make Github issues for changes

We could also look through this PR, flag any potential issues, then merge your PR and circle back to resolve those issues afterwards.

---

When we both have some time today or tomorrow maybe we can sit down and chat about our next steps to see what makes sense?

Thanks!

[dromo77]

Thanks for the feedback @Paul-Hebert. It sounds like we're getting close! I think the best way to decide is to remove the fixed positioning so we can get a feel for it. I'll also fix the header alignment.

I agree we should chat through the next steps, my schedule is open 🙂

[Paul-Hebert]

@dromo77 and I chatted and decided the best way to proceed would be for me to do an initial review of the WIP work.

From there we can catalogue what (if anything) needs to be changed for the final implementation. Once we know that we can determine the best course of action.

@dromo77 , I'll likely be adding some comments to this PR, but don't feel like you need to respond or change anything until we chat in person 🙂

[Paul-Hebert]

I decided to make a separate branch and remove the dummy patterns and prototypes to make the changes easier to code review: #46

Overall this is looking really good and is close to the final implementation! I think with some changes this will be ready to merge in. :slightly_smiling_face: Because of that I think we should continue to work in the same branch, resolve issues there, and then merge this in! :tada:

There are a lot of comments on the PR linked above, and we should be sure to resolve all of them before merging. Broadly, these can be grouped into a few categories:

1. [x] EP prefix class names: All class names used should be prefixed with EP_. The reason for this is so that our boilerplate styles don't leak out and affect the patterns end users create. For example, if they create a no-scroll class, it shouldn't take on the styles of our no-scroll class. So we call ours EP_no-scroll. (Danielle)
2. [x] EP_js prefix javascript hooks: If a class is used for javascript functionality we should prefix it with EP_js-. The js- part tells future devs that the class is used for JS so they don't change it when making CSS changes. js- classes should not directly receive CSS styles, so sometimes we need to add redundant classes to elements. e.g. EP_menu-toggle EP_js-menu-toggle. (Danielle)
3. [x] Watch out for CSS bloat: In a couple places we copied in large config files from other projects (e.g. a bunch of transition config options). I think these are likely overkill for a boilerplate like this. I'd prefer to keep this slim until we need to expand it. (Danielle)
4. [x] Design nits: Doing a deeper review I had a few design nits about links and buttons. Maybe we can chat about these to find a solution we both like? (Danielle)
5. [x] Use partials for repetitive markup: There are a couple places where we're copying around basically identical markup. (e.g. the pattern and prototype sections in the mobile menu, or the pattern and prototype page sidebars). Ideally these would use shared partials or layout files. (Paul)
6. [x] a11y review: I see you've already done a bunch of a11y work for the menu which is awesome! I had a couple nits and questions. We should chat about those, and then be sure to do some a11y testing before we merge this in. (Paul)
7. [x] Misc.: Beyond that there are some miscellaneous nits. (???)

I'm happy to chat through all of this more if you would like. I think a lot of this is stuff that you're more than capable of resolving, but I'm happy to help as well :slightly_smiling_face:. Let me know if you have any questions. Maybe we can spend a few minutes chatting after you've reviewed to figure out the best way to split this up between the two of us?

Thanks for all your work on this. I'm so excited to merge this into the project! It's looking great!!

P.S. Sorry that the comments on the PR are very terse and aren't very informative. I was initially just writing them as quick notes to myself, but realized afterwards they might be helpful for you as well. I'm happy to expand on any of them.

[dromo77]

These changes were merged in a different PR.