Rework Desktop and Mobile Nav UI

[ritorhymes]

Description

This PR reworks the theme's desktop and mobile nav UI to significantly improve usability and make browsing and wayfinding feel like first-class parts of the experience.

Closes #3

Demo site: wg-eips.ritovision.com

What's Changed

• Reworked the desktop navigation into a compact sticky header that keeps primary navigation accessible while preserving reading space.
• Added logomark to the site title (See screenshots in the Table of Contents Nav section)
• Added bottom bar mobile navigation UI
• Replaced light mode low-contrast mobile menu with a legible dark mode modal
• Updated the desktop header layout to use flexbox for cleaner alignment, spacing, and future maintainability.
• Added the homepage / to site navigation
• Added a table of contents button, represented by an open-book icon, that opens a modal for navigating page sections whenever a TOC is available on a page.
• Replaced search button with a simpler, compact magnifying glass icon
• Made the search modal consistent with dark mode styling (instead of white background)

Design and Rationale

Why sticky navigation on desktop and mobile?

The EIP site experience centers on browsing proposals, scanning long documents, jumping between sections, searching, and comparing related pages. Browsing and wayfinding are core parts of the experience, so navigation should remain easy to access throughout the page. Requiring users to scroll around to access navigation adds friction.

A sticky UI makes navigation more seamless by keeping key actions available while users move through long pages.

Persistent navigation also needs restraint. On desktop, the header height is intentionally limited so the nav can stay available while taking up as little vertical space as possible. On mobile, the bottom bar keeps key actions reachable without crowding the header or competing with the page content.

Why add / to the site navigation?

The homepage should be represented as an explicit navigation option alongside the other main site pages. Relying on the logo as the only way back to / treats the homepage feel like a fallback destination rather than a clear part of the site navigation.

This creates real usability confusion. I have personally run into this for years: whenever I land on the homepage first, navigate elsewhere, and then later want to return to it without thinking carefully about the URL structure. In those moments, the path back to the homepage is not obvious and I have often ended up clicking “All” instead and then getting confused when landing on the wrong page.

Adding / as a visible nav item makes the site structure easier to understand and gives users a direct, predictable way to return home.

Why flexbox instead of float-based desktop UI?

The desktop header is a row-based navigation layout with multiple elements that need consistent alignment and spacing. Flexbox handles that directly, making it a better fit than float-based layout for this UI.

Using flexbox also makes the header easier to maintain and adjust. The logo, nav links, and actions can be positioned through the layout model itself instead of relying on float behavior, manual clearing, or layout side effects.

This gives future contributors a more predictable structure to work with as the nav changes over time.

Bottom Bar

The bottom bar is a persistent nav UI system that appears on mobile/tablet breakpoints with 4 quick action buttons available and a responsive structure to accommodate additional buttons if needed.
It currently includes 4 buttons:

• Scroll-to-top button that appears when the user scrolls away from the top of the page; some pages and proposals are very long, this is a powerful convenience tool.
• TOC button that only appears when a page has a TOC, pressing it opens a modal displaying that page's TOC to quickly navigate around the page sections.
• Search button for opening the quick search modal.
• Hamburger icon for opening the main menu modal to navigate the site.

All four buttons visible

Bottom bar with additional 5th button

Notice the original buttons resize and reflow to allow an extra button to fit

The bottom bar also includes:

• Stable button positions: when buttons are hidden, such as when no TOC is available or the user is already at the top of the page, the remaining buttons keep their positions. This preserves a consistent muscle-memory feel instead of shifting controls around based on visibility.
• Footer-aware visibility: the bottom bar hides when it would overlap the footer. On very short pages, such as a 404 page with minimal content, the bottom bar takes precedence because navigation remains more important than avoiding footer overlap.

Why a bottom bar in the first place?
The initial constraint to manage on mobile is the length of the “Ethereum Improvement Proposals” title in the header. That text is long, but it is also the site’s identity, so I wanted to keep it prominent in the header instead of compressing it, wrapping controls around it, or forcing the whole navigation model into a single hamburger button.

A hamburger-only approach would make common actions less immediate. Even the hamburger button itself still competes for room in the header, and putting everything behind it would make the mobile experience feel less direct.

Moving key actions into a bottom bar solves both problems. It keeps the EIP branding clear at the top of the page while creating dedicated space for quick browsing actions: scroll to top, table of contents when available, search, and the main menu.

This also makes the mobile experience feel more deliberate and app-like rather than creating the impression that mobile navigation merely was bolted onto a desktop-first experience.

Table of Contents Navigation

All EIP pages include a table of contents, so the TOC is a consistent navigation structure across the site. This PR makes that structure easier to access from the nav UI, turning an existing first-class page element into a faster way to move through long documents.

The TOC button appears in both the desktop nav UI and the mobile bottom bar only when a page has a TOC. It opens a modal populated from the page’s TOC, letting users jump between sections without scrolling back to the inline TOC.

This is especially useful on mobile, where long pages are harder to scan and section navigation benefits from being compact and close at hand.

Since there is not a single universally recognized table of contents icon, I chose an open-book icon to represent the TOC action in the nav UI while placing it inline in the “Table of Contents” heading to create a meaningful association for users.

Mobile icon

Notice the bottom left open-book icon, matching the icon in the TOC page heading

Desktop icon

Notice the top right open-book icon, matching the icon in the TOC page heading

Opened modal

Screenshots

Mobile Menu — Before and After

Before

After

[SamWilsn]

I'm no UX expert, so maybe this is dumb idea, but it seems odd that the bottom bar buttons change positions based on what page you're on and/or are off centre. Would something like the above make sense for "jump to top" and "open TOC"?

[ritorhymes]

When sharing portrait images in these threads here it would be good if you could use the html tag with a set width of 400px or so like:
<img width="400" src="https://github.com/user-attachments/assets/etc" />
so that the image is fully viewable on the screen without being cut off and needing to scroll to see it. Currently the image on desktop renders so tall, the height doesn't fit within the viewport here, which is typical of portrait images.

[ritorhymes]

it seems odd that the bottom bar buttons change positions based on what page you're on and/or are off centre.

Based on your impression of the offset appearance when certain buttons are contextually hidden, I updated the styling now so that the buttons are never really visually hidden anymore, they appear faded out when inactive/disabled so the positioning of the bottom bar buttons stay clear and consistent across all pages.

Just to clarify, the buttons are not changing positions, they remain in the same layout across pages (missing buttons had placeholder spaces). The two buttons that appear on every page (search and menu) just appeared offset when the other half of the buttons were missing/hidden because I didn't want to reflow the spacing and reduce muscle memory of the buttons' locations.

I was leaning heavily into efficient displaying of things only when absolutely necessary because I see EIP's spirit as largely championing form over function (minima FTW), but this little update costs nothing and may avoid similar impressions from others.

[ritorhymes]

I'm no UX expert, so maybe this is dumb idea, but it seems odd that the bottom bar buttons change positions based on what page you're on and/or are off centre. Would something like the above make sense for "jump to top" and "open TOC"?

I'll level with you, I'm not going to frame choosing the best approach as distilling the most scientifically sound option. We don't have that data... there's different ways to go about this and without user testing or fieldwork it's trial-and-error for how it's received, so I use my best judgment to predict the psychology.

I do think the change I just made based on your feedback should resolve the matter, but I will address your proposed implementation since you brought it up as an option.

---

I would strongly recommend against implementing your proposed approach for a few reasons:

1. Inefficient use of space; we want to avoid taking up space on the viewport within reason.
   • The middle reading area starts to get (close to) cut into (especially for small devices) by stacking the height of the bottom bar, plus 2 buttons on top of each other. The nav height in that area starts to account for a notable proportion of the screen height.
   • There's plenty of space inside the bottom bar to contain all four buttons, the unused space is wasted without utility.
2. It doesn't make enough use of the bottom bar to strongly justify it existing in the first place. It's a significant UI landmark to include, but if it only has 2 buttons and modals are being used instead the bottom bar itself as a drawer, then it isn't doing all that much.
3. It's kind of strange not having the hamburger icon positioned outside of something. It's usually found horizontally on the outer part of a component or container, I feel a weird tension seeing it as the centerpiece of the bottom bar. At least with 3 other buttons, even if the button set itself is centered, it's still positioned on the outer part of that button set and feels okay.

Granted the top-of-page icon floating on the bottom right is a common UI pattern, I don't think it's strong enough to significantly guide the overall direction here, and it fits well positioned within the bottom bar.