Combined settings has made these pages difficult to use
From our user study:
The ‘Project settings’ page is overwhelming, it contains a long list of options and it’s hard for users to find what they are looking for. In addition, we also provide ‘Sharing and Permissions’ on the Settings page, subsequently some users thought they could add a new member to a project / see all members of a project from this page.
Proposal
We should review all settings pages to ensure they are not too overbearing. They should be simple to use, despite the amount of content.
Collapse/expand long sections
When reloading the page (for example when creating a new variable) we should make sure the correct item is opened again and scrolled to for the user
Note that not all setting pages will need expandable sections but all settings pages should be reviewed to ensure the design is in line with the new design of the sections.
Thanks so much for making this issue @dimitrieh. I was also thinking along the lines of an expand/collapse per section in order to keep the page more orderly.
This is great @dimitrieh! Would really help make settings approachable! If we can't do this in 9.0, we should definitely do it in 9.1. @mydigitalself - not sure if this falls in your area, but if it does -- this is really important for us to improve the Settings experience.
It would be nice to keep the Ctrl + F find-ability for the text inside each section. Here is a small demo of that kind of thing working http://codepen.io/MadLittleMods/pen/NdQVOq
Thanks @dimitrieh . This is sorely needed. Thanks for creating the designs. Would each section be it's own web form that can be submitted itself? And should that section refresh/update by itself, without refreshing the entire page?
Victor Wuchanged title from Improve glanceability of long combined settings vies to Improve glanceability of long combined settings views
changed title from Improve glanceability of long combined settings vies to Improve glanceability of long combined settings views
@victorwu if we are going to do this for 9.0 I could provide full designs. Those designs will basically be as true to what they are now, but with the added expand/fold functionality and extra save buttons where it makes sense. So in that regards, try to keep the work to a minimum.
@MadLittleMods I like that it finds it with Ctrl + F. It's kind of frustrating that when collapsed it doesnt say where. Just a thought - Is it im/possible to expand the content when searching for keywords?
Thanks @dimitrieh. Should this design be sort of like a reference design as we move forward with any settings pages updates?
I don't want to do a massive overhaul of settings pages all at once. But there's definitely individual sections I care about. I'll tag you and UX in those areas.
And I assume UX can make sure to enforce the new design on individual pieces of work as PMs and @awhildy schedules them?
Perhaps we can do a proof of concept for 9.0 for just the CI/CD Pipelines setting page, as that one is in a really bad shape at the moment. And then we get that out of the way. It should be pretty simple to do and with that close this issue and use it for referencing only.
@dimitrieh . That's fine by me. For settings in general, @mydigitalself should be at least aware of the work, and I suppose @joshlambert would want to drive it with UX here. I'll let them and you folks coordinate with engineering if you want to squeeze this in for 9.0.
For Discussion, we might be able to get gitlab-ee#1738 in soon. Take a look there if you want to follow along.
Note here for whoever fixes this: when reloading the page (for example when creating a new variable) we should make sure the correct item is opened again and scrolled to for the user:
@dimitrieh I was working on this view for another issue and had some questions. The design you posted shows lines that go outside of our container. We don't do this anywhere else on GitLab that I know of. Was this on purpose?
I worked on some of the spacing. What do you think of this:
Also we should define some of the interactions. For example, if a user expands one section and goes to expand a second section, does the first section collapse or stay open? I imagine some sections might need to be referenced at the same time so keeping each section open could be helpful.
Secondly, the mockup above includes an expanded state. I removed the design that we currently have that uses two columns: 1 column for the section description and one column for the information. Is this what you were thinking? If so, we should make sure all settings sections will transition well to this new design.
Great, thanks @victorwu! That will make it easier to transition the design to the other sections I imagine Even if that doesn't happen in 9.1, it's a start.
Also we should define some of the interactions. For example, if a user expands one section and goes to expand a second section, does the first section collapse or stay open? I imagine some sections might need to be referenced at the same time so keeping each section open could be helpful.
yes!
Secondly, the mockup above includes an expanded state. I removed the design that we currently have that uses two columns: 1 column for the section description and one column for the information. Is this what you were thinking? If so, we should make sure all settings sections will transition well to this new design.
Yes i was thinking of 1 column.. as the folded settings already show the gist of what that section is about.
I wonder if showing headers only by default is really the right way to go about it. It seems like we are further burying the settings, and making them harder to discover requiring a user to click into ones they might find helpful.
Is there a model where we could show Basic then have an 'Advanced' expander? For example on the Services screen, it may be helpful to show configured Services without needing to expand it.
I am primarily worried common (hopefully) Integrations like Kubernetes or Prometheus will be even harder to find.
@joshlambert I agree with you! However i vouch for letting this be a first step.. after which we can promote certain setting to be on display without having to unfold.
Due to the nature of us merging the settings pages we have to take some measure in making the content more manageable. If our descriptions are good enough the discoverability will be improved the most, with the most recent design for that being: https://gitlab.com/gitlab-org/gitlab-ce/issues/28451#note_24666375
So in steps:
convert settings to be in this fold/expand sections
promote certain settings to be always on-display without section being unfolded.. creating a normal (folded) and advanced (unfolded) state
Note there are also some performance implications to consider here, we should look to load the section data asyncronously - perhaps not in all cases, but certainly for particular ones.
Can we make a fast and simple step as adding Table of Content at the top of the page with anchors to specific section? I believe its a good temporary solution that does not require much design/frontend work
@dzaporozhets@tauriedavis i think the approach proposed here is much better than a ToC and achieves the same thing and we are heading in this direction, so I'd rather focus effort on this than a very short-term solution that we'll end up changing again very soon.
@mydigitalself@tauriedavis if its a matter of 1 release wait I am ok waiting for Slack approach. Otherwise I would rather do ToC (which is less than a day of work) and help thousands of users for several month.
Hi Guys, can you be so kind and please make sure to apply the change consistently on all pages. The UI changes very often, I would prefer a solution where the changes result in something which stays for a while.
One thing you should also care about is consistent naming. Currently the Webhooks.Settings use different terms for the triggers such as CommentEvents, NodeEvents.
I have a little bit mixed feelings about putting everything on a single page. However if you need other examples how this could be done, have a look at the eclipse preferences dialog (yes, it's a desktop application, but they have a very smart filtering option) and Jenkins. Both products have to deal with a huge a mount of preferences where the developers have to deal with the fact that any plugin must be able to place their own settings.
@MadLittleMods have you tested this ctrl+f scroll event trick in a few different browsers? In Safari, this only seems to work when I CMD+G to go to the next match. The first match does not "scroll into view" in the same way as I type it out.
Related to this issue I believe Group settings - General is definitely something that should be organized in few expandable sections in a way we did for Projecy settings - General. Right now avatar, name, 2FA, and visibility are all messed together in one group settings form.
@tauriedavis do you mind if I create an issue for updating Group settings - General?