You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One request we get commonly is how to disable parts of the navigation menu. I've consider some how we might overhaul our navigation menu, and this probably overlaps with a version 2 of the menu.
Whatever the technical solution is, the outcome would be:
User decides they don't want a section on the navigation menu
User sets an option
Navigation menu no longer includes the section (downloads, versions, edit on github, etc) -- either on future builds (build files are altered), or on all builds (api return is altered).
We don't necessarily need to wait for a version 2 to implement this, we can alter the HTML return as well. I think JSON data return from an API and client side JS to display the navigation menu is a stronger approach however, and gives a great amount of flexibility.
What is the UX for hiding?
There are several options, control of the navigation menu could be:
A theme option, or html context data
Performed in a RTD dashboard page
Which route we go also alters how we technically approach the problem.
Theme options to control this make sense perhaps, but how does this interact with RTD? Going this route means future builds are altered through the use of a theme option, existing builds wouldn't be affected. This is probably fine.
Javascript to display the theme would be templated and altered through the Sphinx build process.
If we go the route of changing the JSON return, or even changing the HTML return for now, we can do this dynamically for all built versions, but would need a dashboard page for configuring this. This wouldn't be awful, but is against our current focus to reduce the dashboard UI.
The text was updated successfully, but these errors were encountered:
Nevermind. I think API driven flyout menu is what we actually want. We've discussed theme support and our flyout as well, and offering a flyout api that themes can consume probably would make the most sense.
This is an ongoing conversation that we are having now with the new addons project: readthedocs/addons#51. I'm closing this issue from here so we can continue talking in the other repository.
One request we get commonly is how to disable parts of the navigation menu. I've consider some how we might overhaul our navigation menu, and this probably overlaps with a version 2 of the menu.
Whatever the technical solution is, the outcome would be:
We don't necessarily need to wait for a version 2 to implement this, we can alter the HTML return as well. I think JSON data return from an API and client side JS to display the navigation menu is a stronger approach however, and gives a great amount of flexibility.
What is the UX for hiding?
There are several options, control of the navigation menu could be:
Which route we go also alters how we technically approach the problem.
Theme options to control this make sense perhaps, but how does this interact with RTD? Going this route means future builds are altered through the use of a theme option, existing builds wouldn't be affected. This is probably fine.
Javascript to display the theme would be templated and altered through the Sphinx build process.
If we go the route of changing the JSON return, or even changing the HTML return for now, we can do this dynamically for all built versions, but would need a dashboard page for configuring this. This wouldn't be awful, but is against our current focus to reduce the dashboard UI.
The text was updated successfully, but these errors were encountered: