Improve settings pages design by prioritizing content: Group settings
Description
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?
Further details
Recently received feedback from a user on Hacker News:
Repo settings are buried under expandable 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.
Current Group settings:
![](/-/project/13083/uploads/54277f459e09ba9ea3331ffc51ae9cf6/image.png)
Proposal
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).
![](/-/project/13083/uploads/590ee6b3378578f5821c2ee899b1406d/image.png)
Solution
Naming, visibility section | Permissions, LFS, 2FA section |
---|---|
![]() |
![]() |
Changes to be introduced
- a better 'no avatar' avatar (being resolved via gitlab-org/gitlab-ce!17271)
- replace the 'help icons' next to input labels with proper links to documentation
- make the section titles more descriptive (for example, users search for 'two-factor authentication' not for 'permissions')
- the Save button should say 'Save changes' and should be disabled by default and become enabled when users make changes (in this case, it makes more sense like this)
- redesign all the form elements to comply with our form guidelines
- move 'Visibility' to the top section
- Clicking on a section title should expand/collapse it
- When there's a Fork relationship and a 'Remove fork relationship' option in the settings, we need to add a separate 'Fork relationship' expandable section after the last one.
- No changes to the third (Path, transfer, remove) section required (except section name).