Design Permission screens

[echappen]

Existing permission screens need a design refinement pass, to bring them in line with our new designs.

Acceptance Criteria

• [x] Designs are accepted and ready for build

[beepdotgov]

@sknep @hursey013, I’ve got some initial designs for you to review! As always, the designs are in Figma, and I’ve attached them below.

A couple quick highlights:

• Since we’re asking the user to (potentially) cycle repeatedly between the user management table and various forms, I think overlays could make for a nice UX solution here.
• These are widescreen-only for now, but they’ll adapt nicely to any breakpoint.
• At the risk of becoming That <details> Guy, I think the Access Permissions screen could benefit with a collapsible element that defines the various roles.

Once we’ve got an initial direction nailed down, I can adapt these for smaller screens, and also work in some error/update messages. But I wanted to see how these felt to you! What feels like it’s working well? What needs refinement?

(If you’d prefer to talk through these in person, say the word! I can find time on our calendars for early next week.)

Mockups

Organization roles:

Access permissions:

Access permissions (with expanded definitions):

[sknep]

I love it. One thought is that the list of roles in the table should match the order that they are in the dropdown for people who are trying to read what each one is for... I know they're alphabetical in the dropdown but I think I like the order you've sorted them in the table better.

I really adore this treatment. Thanks Ethan!

[beepdotgov]

@sknep, I am delighted to hear this looks good to you!

One thought is that the list of roles in the table should match the order that they are in the dropdown for people who are trying to read what each one is for... I know they're alphabetical in the dropdown

Oh, that’s a great catch, Sarah — thank you. I’ll do a quick editing pass on those definitions, and make sure they line up with the order in the table. Thanks again!

@hursey013, how’re things looking to you?

[beepdotgov]

Okay! Here’s some tweaked help text for roles on the Access Permissions overlay:

(Also available in Figma.)

@sknep, how’s that feel to you now?

@hursey013, let me know if you have any additional thoughts! Once this feels solid to both of you, I’ll work on some small screen-friendly layouts, and set up some error/update message styles.

[sknep]

This is great! BTW I often see an implied pattern in the use of multiple buttons together in USWDS where the secondary button is in the outline variant. Is that something you've considered? If you've thought about it and prefer the primary / base pair, I understand. I imagine this is one of many situations where Accept / Cancel action buttons are going to be proximate, so what you choose here can be extended elsewhere.

Edit: I found some more details: https://designsystem.digital.gov/components/button/#guidance

• Use standard buttons for actions that go a next step.
• Use outline buttons for actions that happen on the current page.

[hursey013]

@beepdotgov I love the use of overlays for this! As with our other modals/overlays I think the main a11y concern is making sure we get the focus state correct and trap focus within the overlay. Visually everything looks wonderful! My only (non-blocking) feedback would be that the collapsed What do these roles mean? isn't immediately identifiable as clickable to me. Maybe it's the less rounded borders or the color, but wanted to pass that along since I imagine we'll want to use similar collapsible <Details /> panels elsewhere in the app.

[sknep]

I will have to gently disagree with brian that to me, the collapsed accordion looks eminently clickable, between the underlined text, the button-ish treatment, and the caret :D however, that's just my reaction! If yall wanna keep working on that, I get it

[beepdotgov]

This is excellent feedback all around. Thank you both! I’ve attached a couple updates below I could use your feedback on — namely,

1. Updated button styling
2. Updated collapsible styling
3. Error/success messages (with a bonus UX question I could use help on)
4. Small screen overlay layouts

As always, let me know if you’d like to discuss these in a call!

(And also as always, the updated art is in Figma, and attached below.)

Button styling

@sknep, thanks so much for pulling out that USWDS guidance! Since this is taking place in an overlay, I think we could comfortably settle on either outlined or solid? But that question aside, I rather like how the outlined version looks:

What do you two think?

Collapsible treatment

@hursey013 and I paired for a bit, and we settled on a style for our collapsibles a little more accordion-y, which could potentially extend to other parts of our UI.

Closed/default

Expanded

I agree with Sarah, that the original version had a nice CTA-ish feel. At the same time, I think this version works a bit better? It’s still noticeable, but it feels less dominant in context: it doesn’t draw too much attention/focus from other nearby (and more important) elements. But I’d love to hear what you think!

Alert/update messages

I’ve also included some styling for alert and error messages. My hope is that they’ll work well not just in the overlays, but also throughout the UI. Let me know what you think!

That said, I have one UX question for both of you: when an overlay form submits successfully, do we:

1. close the overlay automatically, and display the success message on the “parent” page?
2. keep the overlay open, and display the success message in the overlay?

Generally, I’d recommend option 1. But if there’s a cloud.gov case for letting the user continue to work in the overlay, let me know!

Small screen layouts

I’ve adapted the overlay layouts for smaller screens — would love any thoughts you might have!

---

Mockups

Update organization roles

Update access permissions

Collapsible closed

Collapsible open

Success+error messages

Small screen layouts

Update organization roles (small screen)

Update access permissions (small screen)

Update access permissions (small screen, terms expanded)

[beepdotgov]

Quick update from Slack: we did a quick refinement pass on the collapsible to brighten it up a bit.

(Figma’s been updated as well.)

[hursey013]

@beepdotgov I think since the form allows folks to make several selections (selecting various checkboxes) prior to submitting, I think they will be able to accomplish everything in one submit action. Given that, I agree closing the overlay and then displaying the message within the context of the main page is the way to go (ideally moving focus to it when the overlay closes).

[beepdotgov]

Sounds great, @hursey013 — thank you! We’ll plan on closing the overlays on a successful form submission.

Just to check: any other design notes from you or @sknep, or can we consider these ready for implementation?

[hursey013]

Looks great to me! @sknep is out today, so let's move forward with these designs to keep things moving and we can do a follow up PR to address any additional tweaks @sknep may have. Overall though, these are ready to move to implementation! Thank you!

[beepdotgov]

Wonderful. Thanks, Brian! Excited to move these forward.

@echappen, I’ll get Figma prepped for handoff; would it be possible to do a feasibility review next week?

[echappen]

@beepdotgov certainly! I'll put something on the calendar

[beepdotgov]

Figma’s ready for tomorrow’s discussion: artwork’s here!

[beepdotgov]

Marking as done now that we’ve had our feasibility review, and #468 has been opened. Onward! 🚀

[mogul]

I'm late with this feedback, sorry:

Managers can do everything Developers can do [...]

SpaceManagers cannot do everything that the other roles can do. This is a common misconception that comes up a lot; people frequently forget that they need both the SpaceManager and the SpaceDeveloper role to manage both users and apps in a space.

[beepdotgov]

Thank you very much for catching that, @mogul — much, much appreciated, and we definitely want to get that language right.

If we dropped that “can do everything” clause, and swapped in something like this:

Managers administer Spaces, which allows them to manage users, and to enable features.

Would that be more accurate/appropriate, do you think?

(cc @hursey013, #468)

[hursey013]

@beepdotgov The best reference for this is https://docs.cloudfoundry.org/concepts/roles.html. I think the only potentially confusing aspect is that only org managers can create spaces. Space manager appears to be able to edit and rename a space, but as already noted, no ability to create or Deploy, run, and manage apps.

[mogul]

Yes, that's better. You could also leave a link to the docs in there to find exact details.

[beepdotgov]

@hursey013, thanks so much for that note; @mogul, I really like the suggestion to link out to the docs. (I think there’s only so much summarization we can do here, anyway.)

Here’s another quick riff:

Here’s the revised text:

Here’s a brief overview:

• Developers can create and manage apps and services. They can also view logs, reports, and settings for a Space.
• Supporters can troubleshoot and debug a Space’s apps and service bindings.
• Auditors can view logs, reports, and settings for a Space.
• Managers can view and edit Spaces, which allows them to manage users, and to enable features.

Our documentation has more detailed information about these roles. (And if you have more questions, please contact us at support@cloud.gov.)

Does that feel more accurate? Once this looks good, I’ll update the designs, and work to get this into the prototype.

[mogul]

Yes, although unfortunately it's not "our" documentation, in that it doesn't live under the cloud.gov domain/ownership.

[beepdotgov]

Oh, good catch — thanks again, @mogul. Let’s go with “The documentation”, then?

[mogul]

SGTM!

[beepdotgov]

Updated Figma, and pinged https://github.com/cloud-gov/cg-ui/issues/97#issuecomment-2344622702 for implementation.

@mogul Thank you again for catching this! Seriously, the feedback is a massive help, and I really appreciate you taking the time to review some copy changes.