Build a dedicated settings context
Details
Our current Settings menu contains quite a few items, and there are plans to add more in the future as we pull in features that are currently only available on self-managed. This can make it difficult for users to navigate these items and maintain a good understanding of where they are at.
During the North Star research (#365403 (closed)), we explored a more dedicated experience for Settings for when a user is navigating those options to keep the experience more focused and less overwhelming. This issue is for moving to this direction, as it also sets us up better for the future to allow for searching across Settings pages (&5198 (closed)).
Intended users
Implementation Guide
Resources
When selecting the Settings navigation item...
-
Direct the user to the first page of the Group/Project Settings section.
When on a Settings page...
-
Only show the Settings menu within the left sidebar navigation -
Group related Settings items together underneath subheadings -
Replace the settings
icon with thearrow-left
icon -
Clicking on the Settings heading/button (not just the arrow-left
icon) navigates back to the page the user was on when they navigated to Settings (fallback of the project/group overview page)- This means, that if a user has navigated to one of the Settings pages directly without use of the contextual navigation (ex: by URL, Global Search in future, etc.), we would default the Back button to take them to the associated Group/Project overview.
Implementation steps
-
backend (see #378545 (comment 1212182131)) -
When on a non-settings page, expose an URL to the general settings page. -
When on a settings page, expose the settings pages' tree.
-
-
frontend -
Consume the data being exposed by the backend. -
By default, render the standard nav along with a link to the general settings. -
From within the settings, render the settings nav along with a "back" link (see below).
-
-
-
backend/frontend -
Keep track of the last visited non-settings page within a context. That page's URL will need to be passed to the sidebar so we are able to direct the user out of the settings and back to wherever they were before. This should fall back to the context's root page. - There are several ways to deal with this. We might be able to achieve this behavior client-side only by persisting each non-settings project/group page's URL to the session storage. In this case, the backend should expose the context's root page to be used as a fallback. Alternatively, the whole logic can be done in the backend, in which case the proper URL can be passed down to the frontend which then just needs to link to it.
-
Documentation
Testing
What does success look like, and how can we measure that?
Edited by Paul Gascou-Vaillancourt