Align navigation bar UX on mobile to Docsy or Bootstrap

[SayakMukhopadhyay]

Right now, the nav bar collapses to a hamburger icon that opens a drawer menu from the right on smaller screens.

This is very different from what Docsy provides by default, which is a horizontally scrollable menu below the logo,

Right now, the current drawer is implemented by customising the navbar partial along with quite a bit of JS for handling clicks and the drawer itself. As part of our efforts to align with Docsy as much as possible, I wanted to propose that, post the Docsy 0.7 upgrade, we change the UX to align with either Docsy or, alternatively, Bootstrap. This would let us avoid maintaining our own JS logic to handle navbar responsiveness.

0.7 Docsy Navbar

Bootstrap 5.2 Navbar

Personally, I am fine either way. Using Docsy would mean we won't need to override the partial, too, which is always good. But, I think from a UX POV, Bootstrap's left and right drawers are better than Docsy's UX.

[Caesarsage]

Thanks @SayakMukhopadhyay

I agree the Boostrap is more ux friendly. But I will suggest if we need a to do a redesign for the navbar, we should go with the Docsy as the UX is still very much great and require less or no override on the existing partials.

[ritorhymes]

I think a Bootstrap implementation has great promise, but I would strongly recommend against using the Docsy UI, as it would create additional pain points and friction for users navigating on mobile.

I also think the current mobile menu navigation UI is pretty good in terms of usability and appearance, which is why I recently reworked it into a Bootstrap-based structure with steps to migrate to BS 5.2 in PR #54700 (coincidentally, @SayakMukhopadhyay you are the reviewer!). Building around the current design seems a good foundation.

My breakdown on using the Docsy UI vs the current design
The obvious and clear benefit of using the default Docsy UI as is would be the code maintenance with things working out of the box.

The 3 biggest UX issues introduced by the Docsy UI:

1. The menu remains at the top of every page, requiring users to scroll up every time to access it.

That is a significant burden on mobile users, consuming time and energy that may reduce people's willingness to navigate. Compare that to the current design where the menu icon is fixed at the top of the viewport, following the user so they can access the menu immediately at any time.

If the Docsy UI were edited to simply make it fixed to the top of the viewport, that would be distracting and disruptive, because that means a long list of options follows the user at the top of the screen everywhere while they are trying to read. It would also require an override, which would eliminate the main maintenance benefit. There may be other ways to enhance it, but at that point you're still overriding it and it loses its main appeal compared to using Bootstrap for a more user-friendly design.

2. Having all the menu options on one line is not great for visibility.

a. People are often unaware that you can scroll to reveal more options.

b. Reading everything on one line can feel cluttered.

Both issues are amplified by the fact that the current total number of menu items is at basically the upper limit of what's reasonable to include inside a one-line scroll container, with 8 items, 2 of which have dropdowns.

The current design, on most devices, allows for all the main options to be immediately visible, with the exception of the full language accordion list that requires a bit of scrolling but still provides clear awareness that it's there.

3. It makes it more challenging for users to find their language version by hiding the options from a clear and accessible view.

With the current order (it's last), the user would need to scroll to find the option, but the option would say "English", and they would have to know to press that to reveal the other options in the dropdown. This should definitely be reworked to make it more seamless.

The current design is very effective for allowing users to navigate to their language with minimal bandwidth. The user navigates to the English version by default, they recognize the hamburger icon, they click it, and they can immediately see an opened list of languages and can find theirs.

In terms of resolving an already documented UX issue with the current design:

For #22021 it does technically resolve the hamburger icon ambiguity by removing it altogether, but that problem is localized to only two sections (docs/ and blog/), so a global change is not a warranted solution, especially if the trade-off is a net negative experience overall.

---

Bottom line:
If we are going to accept Docsy as-is, we must accept its mobile interaction model.

If we are not willing to accept that model (which I hope we are NOT), then we are already in override territory, so we might as well choose a more user-friendly architecture intentionally with Bootstrap.

[ritorhymes]

Following up on this, I opened #55189 as a concrete implementation of the Bootstrap-based direction discussed here.

It builds on #54700 and applies the same mobile navbar drawer approach to docs/blog page navigation by adding a left-side page-navigation drawer for /docs and /blog on mobile.

That keeps the docs ToC / blog list accessible while scrolled, removes the hamburger ambiguity discussed in #22021, and addresses #53998 by avoiding the need to return to the top-of-page sidebar area just to navigate.

At this point I think the value of the Bootstrap direction is that it is no longer just theoretical: #55189 shows a concrete pattern that solves a real navigation problem in docs/blog while staying aligned with the Bootstrap-based refactor from #54700.

@lmktfy, you have been invested in resolving some of these issues for some time now, what are your thoughts on this direction?

[ritorhymes]

@SayakMukhopadhyay following up here because this discussion directly informed the revised PR that I opened after reworking the earlier approach, and you’re also listed among the maintainers on that review.

I reworked the implementation to align with the direction discussed here, and then followed up with an additional iteration based on one of the suggestions raised in this thread. At this point, I’m trying to understand whether this direction is actually being considered, or whether I should treat it as a dead end.

If there are specific concerns with the implementation, scope, or overall approach, I’d appreciate those being called out directly. Otherwise, a clear signal that maintainers do not want to pursue this path would also be helpful so the work is not left in limbo.