Page MenuHomePhabricator

Design: Special:CommunityConfiguration should display in an inactive state to non-administrators
Closed, ResolvedPublic

Assigned To
Authored By
Urbanecm_WMF
Mar 25 2024, 4:41 PM
Referenced Files
F48622693: Ex. mentorship form is protected (1).png
Apr 25 2024, 1:47 PM
F48621845: Module 'protected'.png
Apr 25 2024, 1:47 PM
F45882737: Form for mentorship+personalized praise (1) 1.png
Apr 11 2024, 2:22 PM
F45685532: Form for mentorship+personalized praise.png
Apr 10 2024, 6:05 PM
F45677546: 5.png
Apr 10 2024, 6:05 PM
F43471605: lock opened.png
Mar 26 2024, 11:26 PM
F43471603: 4.png
Mar 26 2024, 11:26 PM
F43346893: image.png
Mar 25 2024, 4:57 PM

Description

When a non-admin accesses Special:CommunityConfiguration, they should see it in a non-active state (as they are not actually able to press Submit and change the configuration itself). We still want non-admins to be able to see the configuration, similarly to Special:EditGrowthConfig in GrowthExperiments.

All logged in and logged out accounts should have access to view the Community Configuration dashboard and forms.

When a non-admin user goes to Special:CommunityConfiguration and selects a provider to edit, they are unable to change any of the form fields or to submit the form.

Designs

TBD

Acceptance Criteria

Given I'm logged out or logged in as a non-Admin,
When I access a Community Configuration form,
Then the form is clearly inactive and I'm unable to edit it.

Given I'm logged in as an admin,
When I access a Community Configuration form,
Then the form is clearly active and I can edit it.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Urbanecm_WMF moved this task from Inbox to Backlog on the Growth-Team board.

Technically-speaking, let's treat anyone with editsitejson permission as admins.

@JFernandez-WMF @KStoller-WMF Do you have any thoughts on the changes needed in Special:CommunityConfiguration itself? From my perspective, it is trivial to mark the form fields as disabled and disable (or remove) the Submit button, but I am not so sure about the dashboard. Right now, it looks like this (for both admins and non-admins):

image.png (932×2 px, 180 KB)

However, from a dashboard that looks like this, it is not clear what level of access I have for "Mentorship" settings (for example), and whether I can only see the current configuration, or whether I can also modify it. Note that in this task, all users will either have access to everything (as they are an admin) or nothing (as they are not an admin). In T360920, we would also add support for a provider that can be accessed by non-admins (so you could have write-access to a single provider, and the rest could be read-only). If you have any thoughts on how to solve this from a Design/Product perspective, I'm curious to hear them :).

I think @JFernandez-WMF should own this decision, as I see this as a design/UX decision.

However, since I was asked, here's my two cents:
Perhaps it's OK if the dashboard looks the same to all viewers. It is simply a dashboard to link out to all the available configuration pages. The configuration page is where the UI/UX differs based on account permissions.

If we greyed out certain options on the dashboard (or some other UI pattern to indicate they weren't editable), then I would be concerned that they might not look clickable. As the dashboard is meant to aid navigation, and not editing, I personally don't think it needs to differ based on account permissions.

As the dashboard is meant to aid navigation, and not editing, I personally don't think it needs to differ based on account permissions.

I was having this thought, anticipating we would eventually want to complete T360920: Make CommunityConfiguration support providers that are editable by non-admins, at which point the access level might be different for each section (and knowing which you have access to might help navigate you around as well). But, if we want to leave changing the formatting of the boxes for later, fine with me as well – up to @JFernandez-WMF :).

thank you, Martin! I agree with Kirsten on not making the dashboard look inactive even if you don't have permissions for certain configurations, since it is purely navigational. but I do think that it would be nice and informative to have some sort of disclaimer/info pop-up that communicates the availability of the config. maybe a lock icon with a tooltip on click? something like this:

4.png (169×377 px, 13 KB)

lock opened.png (207×671 px, 21 KB)

PS. this mockup uses the OOUI tooltip component. so maybe a great use case to bring the tooltip to Codex? :)

I also think that we should change the UI of the form itself, maybe by making it inactive or in read-only mode.

That sounds good to me! @Sgs also mentioned in Slack using cdxIconEditLock and cdxIconEdit (but I guess that might better fit as an icon-label for an edit button, rather than for a box-level description). Or maybe not?

Agreed, I think those icons may relate more to the setting itself and not the module

Technically-speaking, let's treat anyone with editsitejson permission as admins.

Actually, it’s editsitejson + editinterface, isn’t it? (Without editinterface, I think no page in the MediaWiki namespace can be edited.)


As I wrote in T354463#9674655, this not being implemented helps testing by non-admins, so could you please do it as late in the MVP development phase as possible? 🙂

KStoller-WMF renamed this task from Special:CommunityConfiguration should display in an inactive state to non-administrators to Design: Special:CommunityConfiguration should display in an inactive state to non-administrators.Apr 4 2024, 5:43 PM
KStoller-WMF assigned this task to JFernandez-WMF.
KStoller-WMF updated the task description. (Show Details)

Hi all — curious what you think of these approaches for an inactive state.

Dashboard:

In my previous comment, I commented on the possibility of using a tooltip/popover to convey the meaning of the 'lock' icon. Since this component is not in Codex (yet!) we should find an alternative that allows for Codex usage. One option is using an InfoChip with the editlock icon and an explanation (we could change the 'Read-only' language to something more appropriate or more explanatory).

5.png (169×377 px, 14 KB)

Form:

There are two issues with marking the form fields as disabled and as read-only. Disabling elements means that people with a screen reader are not able to read it, so we may want to avoid that. Marking all form elements with the read-only state isn't possible, since it only works for text inputs.

I suggest we have the form with the labels and the values chosen in plain text (meaning no radio buttons, fields, etc.) Example below:

Form for mentorship+personalized praise.png (1×1 px, 145 KB)

What are your thoughts on these options? Feel free to suggest other alternatives :)

Thanks, @JFernandez-WMF!
I don't have strong preferences on how this is displayed or conveyed, but we might want to make it clearer why the form isn't editable by everyone.
Could we add some sort of notice on the form? Perhaps simply adding a sentence to the Warning message: like "This form is only editable by Admins."

Thank you for the feedback @KStoller-WMF!

I wonder if for users with non-admin rights we could just switch the warning message to a notice message that is a little more explanatory on why the form is not available to edit. That is assuming that non-admins do not need to see the warning message since they're not making changes, but I could be wrong.

Form for mentorship+personalized praise (1) 1.png (398×1 px, 35 KB)

Dashboard:

In my previous comment, I commented on the possibility of using a tooltip/popover to convey the meaning of the 'lock' icon. Since this component is not in Codex (yet!) we should find an alternative that allows for Codex usage. One option is using an InfoChip with the editlock icon and an explanation (we could change the 'Read-only' language to something more appropriate or more explanatory).

I actually like the info chip even better: tooltips are designed for pointing devices – in particular mice – in mind, so they’re less accessible on touchscreen devices or in text-only browsers; and they also have discoverability issues (how do I know that I have to hover over/tap the icon?). An info chip works equally well everywhere.

For the language, another option is ‘Protected’, which is a well-known term in wiki context (and the pages are indeed protected, using namespace protection). I don’t know which one is better, though.

Form:

There are two issues with marking the form fields as disabled and as read-only. Disabling elements means that people with a screen reader are not able to read it, so we may want to avoid that. Marking all form elements with the read-only state isn't possible, since it only works for text inputs.

I suggest we have the form with the labels and the values chosen in plain text (meaning no radio buttons, fields, etc.)

The problem is that this way, users cannot see what the other (unselected) options are. Isn’t it possible to achieve, using ARIA or anything else, that disabled controls are still announced?

Thank you for the feedback @KStoller-WMF!

I wonder if for users with non-admin rights we could just switch the warning message to a notice message that is a little more explanatory on why the form is not available to edit. That is assuming that non-admins do not need to see the warning message since they're not making changes, but I could be wrong.

Form for mentorship+personalized praise (1) 1.png (398×1 px, 35 KB)

Agreed, that makes far more sense than showing that warning.

For the language, another option is ‘Protected’, which is a well-known term in wiki context (and the pages are indeed protected, using namespace protection). I don’t know which one is better, though.

I was actually thinking the same thing and almost suggested the full protection language, but it seems like that might not be a common term across wikis. Perhaps the notice could be something like:
"This page is protected. Configuration of this feature is only editable by administrators."

The problem is that this way, users cannot see what the other (unselected) options are. Isn’t it possible to achieve, using ARIA or anything else, that disabled controls are still announced?

Ohhh, good point. :/
It would then be difficult for any non-admin to suggest changes when it's not clear what other options exist.

Thank you both!

Let's use the 'Protected' language, perhaps only using the word 'Protected' in the Infochip and then expanding that meaning on the notice message inside of the form.

The problem is that this way, users cannot see what the other (unselected) options are. Isn’t it possible to achieve, using ARIA or anything else, that disabled controls are still announced?

That is a great point, let me get into this and come back!

I was actually thinking the same thing and almost suggested the full protection language, but it seems like that might not be a common term across wikis. Perhaps the notice could be something like:
"This page is protected. Configuration of this feature is only editable by administrators."

It’s actually a permanent protection in enwiki’s terminology. Probably many wikis don’t name this restriction at all, but it’s pretty similar to a usual protection (the only real difference being that these pages cannot be unprotected). This language is just for the info chip; on the provider page, I’d just display whatever the standard edit form displays, which explains all the reasons for which the page cannot be edited (namespace protection, content model-based protection, eventual usual protection, blocks etc.).

FYI we are following up with DST on this and we'll have a workaround soon.

Here's an update/resolution on this:

Dashboard:

We will be using InfoChip with 'Protected'.

Module 'protected'.png (169×377 px, 14 KB)

Form:

For the form — we are switching the Warning message to a Notice message. We are also disabling the 'Save changes' button only so non-admins can still play around with the different options and see the different values but not being able to save any changes. Also we can add an inline message on top of the button. See example screenshot:

Ex. mentorship form is protected (1).png (1×1 px, 153 KB)

Any feedback/thoughts? cc @KStoller-WMF