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):

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.

In T360919#9662259, @KStoller-WMF wrote:

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:

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

In T360919#9658466, @Urbanecm_WMF wrote:

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? 🙂

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).

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:

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.

In T360919#9705017, @JFernandez-WMF wrote:

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?

In T360919#9707320, @JFernandez-WMF wrote:

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.

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

In T360919#9707859, @Tacsipacsi wrote:

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!

In T360919#9708233, @KStoller-WMF wrote:

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'.

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:

Any feedback/thoughts? cc @KStoller-WMF

Looks good, thanks!