The current view is really confusing and not UX friendly at all. Note this should also apply not only to changing settings, but also when creating a new project.
This has been brought up several times and is definitely a big source of confusion. I've been using this issue for reference, I've linked to it many times:
I think the checkboxes and lack of info make this more complicated and less streamlined. The explanations were very helpful to me as I was first using GitLab. Clicking on the different options and being able to see the explanation of what the change would mean was infinitely helpful in understanding the basics. I would actually like the explanation to adjust for each setting, not just at the Project Visibility level. What do you think @tauriedavis?
@sarrahvesselov Do you mean explanations next to DisabledOnly team members and Everyone with access? What copy do you think would help make it more clear?
I think separating disabled/enabled from visibility, like Victor is suggesting, makes sense.
@tauriedavis I was referring to these explanations, under each heading. As you change the dropdown, the top explanation under project visibility adjusts accordingly.
The checkboxes did not immediately make it clear to me that it was not enabled. Perhaps making the corresponding text in the dropdown say disabled, or not be there at all, would help.
The idea here is that project visibility is first and the rest of the features come secondarily and can change based on the project visibility selected.
Current
Public
Private
Couple notes:
Allowing the ability to request access is dependent on the visibility level and should be connected to that. I moved it to the top under the dropdown and it is present when it is an option (for public and internal projects)
I think a toggle is more clear than a checkbox for indicating that a feature is enabled or disabled
When a feature is disabled, the dropdown changes to disabled and the placeholder text reads "Enabled feature to choose access level"
When you switch the project visibility level, the access levels turn green and fade like they do today
I moved the access levels next to the feature toggle so you don't have to scan across the page to see the level related to each feature.
I changed the title to Permissions since I wasn't sure how it related to sharing?
Thoughts @sarrahvesselov? I battled with making sure the UI was not too overwhelming with the toggles.
I like the visual separation you have created by placing the Project visibility at the top with a white BG.
Allowing the ability to request access is dependent on the visibility level and should be connected to that. I moved it to the top under the dropdown and it is present when it is an option (for public and internal projects)
This makes sense to me.
I think a toggle is more clear than a checkbox for indicating that a feature is enabled or disabled.
I like this implementation @tauriedavis. It is much clearer to me what is enabled/disabled.
I moved the access levels next to the feature toggle so you don't have to scan across the page to see the level related to each feature.
While this looks like a lot of extra white space on the right hand side, I think it is much easier to correlate the feature to the access it currently has.
I battled with making sure the UI was not too overwhelming with the toggles
I agree with your decisions and feel that this is an improvement. I do see that the overall effect is very dense, more so when you look at it zoomed out. I zoomed in to approximate actual screen size and it felt much better. The close proximity of the choices kept me focused on them in a way that the current screen does not.
Did you use the new type ramp for this? I feel like the placement of items is correct but that maybe it is the spacing that is making it feel so dense. I made a rough mock up of what it would look like with a little bit more spacing. It does not greatly increase the height while giving a little bit of breathing space. Not sure if this is much better, just a thought
@tauriedavis looks really nice. Question on the toggle, should the little round toggle bar/cap whatever you call it move from left to right for enabled disabled. It seems like an iOS/mobile toggle, but sort of not at the same time.
I still think there's a broader confusion with permissions...
This is the new project page, but the same settings are configured here, but with more granularity, so bear with me.
I want to create a project that only people in secrettestgroup can access. Which option do I pick?
It's not the first option, right, because that says I need to grant access to people explicitly - so I assume it's completely private and I have to go and individually set access to it.
It's not the second or the third option, because that means that anyone can see it, either authenticated (2nd) or not (3rd).
So, what option do I pick?
The second example, from the (current) settings.
So I've set a project so that anyone on the server can see it, because why not.
What exactly does "Only team members" mean. Is that people in my group? What's a team? We don't call anything a team, right?
Question on the toggle, should the little round toggle bar/cap whatever you call it move from left to right for enabled disabled. It seems like an iOS/mobile toggle, but sort of not at the same time.
oops! Yes! Thanks for catching this, I forgot to move the toggle when disabled. Will fix.
As for your other point, I think a copy adjustment could help:
Private: The project is accessible only by members of the project. Access must be granted explicitly to each user.
Internal: The project can be accessed by any user who is logged in.
Public: The project can be accessed by anyone, regardless of authentication.
For the dropdown, you are right, we don't use "team". Perhaps changing it to "Only project members" would solve this. In your example, anyone logged in would be able to access the project but only project members could access the repository. Is that clear and addresses all concerns?
Great suggestion on "Only project members" that makes perfect sense.
Do we not have an option where you create a project and all members of the group can see it automatically? How would I go about creating something like that or do I have to set that up every time for a project?
Do we not have an option where you create a project and all members of the group can see it automatically? How would I go about creating something like that or do I have to set that up every time for a project?
How would the project know which members to add automatically? Not sure I understand what you mean @mydigitalself
@tauriedavis seems like a separate issue, but if you imagine that groups, or perhaps subgroups effective define permissions, why is it that you have to go and add people to a project each time.