sphinx_rtd_theme
sphinx_rtd_theme copied to clipboard
Fix #1177: Usability problem with sidebar on mobile devices
Changes
- Added a close button inside the sidebar just above the toctree
- CSS: Made the button visible only on small screens
- CSS: Made the sidebar 100%, when open, on small screens (before it was set to 85% width so the original hamburger button that toggles the sidebar could still be accessed with the menu opened. now the close button was added inside the menu itself, so there's no need to access that button while the menu is opened)
- CSS: Made the
.rst-versions100% width accordingly.
See bellow screenshots of before and after changes, both displaying the full window with the menu open
Before:

After:

Fixes #1177
Added aria-label and some extra padding to the close button so it's easier to click.
Also, going to wait to merge until 1.0 is tagged.
@agjohnson
Do you think there is anything we can easily to do put the close button at the top of the navigation pane?
I agree that the top of the navigation pane would be the best place for the close button. In it's current layout however, I fear it would cause more problems:
- It would make the top pane, which is already a bit too tall for a good user experience on mobile devices, even taller
- It would invite miss-clicks on the logo link
There are several ways to solve these but all involve more design decisions.
We can continue discussion separately if we want to do this in multiple steps.
👍 Completely agree! A better UX could definitely be accomplished here by redesigning the top pane and integrating the close button.
Sounds like we have a plan then. It definitely does seem like a larger project to do this the way we want, we can address this in stages though.
In it's current layout however, I fear it would cause more problems
These are both good points. I actually almost posted a version with the logo removed. It might be worth considering removing the logo in the mobile menu. It's already hidden in the menu and it feels to me to really interfere with usability of the menu on mobile. We have a horizontal logo too. For projects with square or vertical logos the menu gets even more cramped on mobile.
I want to point out that I also made changes that work towards improving this as part of much larger refactors/rewrites. See: #1122
The PR listed above makes several changes to HTML structure, layout, and breakpoints. Making it a slightly bigger change but also a slightly different UX compared to this patch.
Can you two look at the UX and tell me what you think? I can extract those changes from that PR if we like that UX more than this one.
The one benefit of this patch is that it removes the hamburger icon, which is a plus because the icon is rather confusing and is being removed across global UI design patterns.
@agjohnson
It might be worth considering removing the logo in the mobile menu
Definitely and option. Or maybe have a second logo version, different from the desktop menu.
@Blendify
See: #1122
Removing the hamburger button is a big plus! I don't think that making the sidebar a fixed width would be the best option here. Moving to the new tags would be great thought, but because of Sphinx 3.5 lack of support for html5 I don't think we can do that yet (or could we use html5 on the sidebar, where Sphinx does not interfere?)
I commented on #1122 -- changing the HTML structure of the navigation is tricky because we have customer and users restyling our theme and expecting the existing current HTML structure. We are already discussing a big backwards incompatible change with bootstrap, and users will have to already port their styles to new HTML and classes once, I'd hate to make that twice for users.
I think we'll be in a better place to make better UX on some of the underlying structure after we have dropped some older Sphinx versions, we only have HTML5 output to worry about, and we are done messing around with the main HTML structures with a Bootstrap port. Until then, I think we're mostly in maintenance mode to get a final release out supporting old Sphinx/etc.
We'll be bumping the Sphinx requirements for 2.0, so perhaps that's a good milestone for this?