Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable configuration of doc navigation menu #3507

Closed
agjohnson opened this issue Jan 12, 2018 · 3 comments
Closed

Enable configuration of doc navigation menu #3507

agjohnson opened this issue Jan 12, 2018 · 3 comments
Labels
Improvement Minor improvement to code Needed: design decision A core team decision is required
Milestone

Comments

@agjohnson
Copy link
Contributor

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.

@agjohnson agjohnson added Improvement Minor improvement to code Needed: design decision A core team decision is required labels Jan 12, 2018
@agjohnson
Copy link
Contributor Author

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.

@agjohnson agjohnson added this to the Admin UX milestone Sep 19, 2018
@stsewd
Copy link
Member

stsewd commented Apr 11, 2019

Related #5570

@humitos
Copy link
Member

humitos commented Sep 15, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Improvement Minor improvement to code Needed: design decision A core team decision is required
Projects
Status: Done
Development

No branches or pull requests

3 participants