Improve settings pages design by prioritizing content: Project settings
We seem to be relying on two contrasting approaches when it comes to designing pages with a lot of content: we either show everything (issue view) or break content down and hide it in expandable sections (settings pages in general). I think we need to find a balance between the two by starting to prioritize content. The principle that can guide is in such cases is the 80/20 principle.
For the settings page case: can we prioritize 20% of the content that 80% of users look for and only hide the rest?
Recently received feedback from a user on Hacker News:
Repo settings are buried under expand links. This did not make the page more usable, it made it so I had to guess where the setting I want is.
The problem with this approach is that we need to break content down and then group related things. By doing that and hiding it behind an expandable section we then need to come up with a label that encompasses the content of the section. That usually results in generic labels and users wondering where is the thing that they're looking for.
|Project settings||Group settings||Admin settings|
Change the way we handle settings pages by prioritizing content. We can assume what users look for on simpler and shorter pages (group settings in the above example) but will probably need support from UX research to do that on more complex pages (Admin settings).
We already started discussing how the UX of these pages can be improved in this issue, I'm opening this new issue to continue that discussion.
- Research report: https://drive.google.com/file/d/1iqFqV7QwVp0y8_vYfMLmYHJ0jbw_tL2r/view?usp=sharing
- Top 3 project settings most frequently used by respondents:
- General project settings
- Merge request settings
|MVC||Project settings vision||Service Desk||Export project in advanced section|
Changes required for MVC:
- change section titles and descriptions
- change the sorting as indicated (this is based on UX research findings)
- clicking on section title expands/collapses the section
- ‘Remove avatar’ can be a link button, doesn’t need to be so prominent
- limit width of Project name to input-md (
- limit width of Project tags and project description to input-xl (
- reduce spacing between section dividers to
24px(top & bottom margin)
- Merge request section
- labels in ‘Merge request’ radio selection should be regular font weight. Explanations below the labels should be styled as ‘secondary’ text
- ‘Description parsed with GitLab Flavored Markdown.’ should be regular, not italic and styled as ‘secondary’ text
- labels in ‘Merge request’ checkboxes should be regular font weight. Explanations below the labels should be styled as ‘secondary’ text
- ‘Save changes’ buttons should be disabled until there’s a change to save
- Merge request approvals section
- change the ‘Approvers’ label to ‘Add approvers’
- limit the width of the ‘Approvers’ input field to input-lg (
- ‘Add’ button should be the default (white) style) and disabled until there’s something to add
- ‘Approval required’ input field should be limited to input-xs (
- checkbox labels should be regular font weight
- redesign the ‘Service desk’ section as indicated (button tooltip: Copy to clipboard)
- move ‘Export project’ section into the ‘Advanced’ section (as indicated)
- remove the 'Project name' input from the Rename repository section (duplicate of the same input in the Naming section on top)
- change the title of 'Rename repository' to 'Change path'
- Move forward with work on filtering for settings pages. Existing issue: #50145
- Design and test the proposal to expand the most frequently used settings and collapse the rest of the settings. This decision, in addition to the proposed filtering functionality, will address the majority of the concerns given by survey respondents.
- Key problem to solve: All expanded makes it harder to see the other settings available on the page...but all collapsed leads to a lot of guesswork, especially if the category description is vague.
- Consider adding an “Expand All” button at the top of the page for people who’d prefer to scroll or use browser search. This point was mentioned by some users and raised in these issues: #41230 (closed), #42777
- Think more about the question of how to handle settings that are very important during onboarding, but rarely changed after setup. They may not be the most frequently used (which may favor them being lower on the page), but they could be the most commonly searched for, when setting up a new GitLab instance.
- Consider adding 'Visibility, features and permissions' settings to the top section (expanded by default)