Communicated the status/state of a module in one of the upper corners of a module card

Please review the icons for communicating the status/state of a module in one of the upper corners of a module card.
There are three for three different states:
- Available
- Added
- Installed
Communicating the status of a module card with a colour is not correct from an accessibility perspective, that's why it's all about the shape of an icon. As there was not size specified, I made them 31x31px

Updating with a plan of action for this issue:

1. Decide if this is enough of a usability issue for MVP
2. Design an accessible solution for reflecting these statuses
3. Implement design by reflecting status

I believe that there are a few things that need decisions:

• Language - the three states are (1) "module is not in your codebase yet, and needs to be downloaded" (2) "module is in your codebase but not installed/enabled/active" and (3) "module is in your codebase and is installed/enabled"; we need to decide on one-word, clear terms that describe these states.
• Iconography/Color - Simple icons like the ones Antonia came up with make sense; however, you're also not suppose to ever convey meaning with ONLY an icon, it should have text with it. I think we will need both. Similarly, I think color differentiators are OK if you don't ONLY differentiate with color. I think a combination of color, icon, and text would be good - however, is that too much to cram onto a card?
• An actual design - we need to come up with a mockup of how this should look before proceeding (and of course a decision whether or not we'll even include before that!

I would love to hear some opinions from outside users to first ascertain the seriousness of the usability issue. (Note, it did not come up at our Univ of Minnesota real-user-testing; however, I'm not sure we had tasks directly related to that.)

hello! I took a stab at looking at this issue.

Language - For the three states, I was thinking of going with "Available" for a module that is not installed or enabled. "Installed" for a module that was downloaded to your codebase but still not enabled. "Enabled" for a module that is both installed and turned on.

Iconography - For the icons, I went with a simple + for Available, a downwards arrow for Installed, and a checkmark for Enabled. I also utilized the new marketing colors for each state, dark grey (#4F4F4F) for Available, the Drupal Blue (#009CDE) for Installed, and Drupal Green (#397618) for Enabled.
Installed:

Enabled:

Available:

Design - Here is a design of the grid and list view in project browser. I also attached the icons as SVGs.

Designs:
Grid View

List View

Thanks for working on Project Browser, it will be a huge improvement. About naming the actions and present situation of a module, it can be a source of confusion ... I recently posted this comment:

It's important to discern between downloading and installing modules, they are two very different things in Drupal.

1. You download the module and its additional necessary libraries (defined in the module's composer.json file) with Composer.
2. Then you install the module either via the GUI on the Extend page, or with Drush -- the module gets enabled, changes are made to the database (the configuration), necessary folders are created, etc.

See https://www.drupal.org/docs/extending-drupal/installing-modules → as well as these two issues for more discussions:

• #3315858: Make the micro copy for adding and installing modules consistent with the general plan for Drupal Core →
• #2888657: [meta] Less confusing and more consistent wording needed in module/theme add/install/update →

From Download ≠ install → .

Perhaps these words best convey the states and options?:

1. Module is not in your codebase yet, and needs to be downloaded: "Available"
2. Module is in your codebase but not installed/enabled/active: "Downloaded" -- OR -- "Added"
3. Module is in your codebase and is installed/enabled: "Installed"

Yes, the language choices need to be obvious here, and I believe the design needs to be (1) validated and (2) clarified. I'm still not convinced we can't do this with the existing button text, making it clearer what will happen, like "download & install" or "add & install"

But current state of this MR is not ideal. ("Active" especially)

After some discussion which can be found at https://drupal.slack.com/archives/C01UHB4QG12/p1724856671910839 we've agreed on not to go with the state label in one of the upper corners shown in #18. This issue dates back to a time where there still was a drop button the more than one possible state. And we currently have already an area of focus that could be used in this case to also communicate the state aka the button. you have the state of a module not added yet with the button label "add and install", in the drupal core source type modules already in the file system with the "install" button and then you have the "installed" state which currently is just a span. the problem is the span is not focusable by keyboard and screenreader users and is therefore not directly accessible. current plan is to change the markup for the installed state being also a button and add the aria-disabled="true" attribute. that way the button is still focusable, the button is not getting greyed out and can still be styled as wanted PLUS screenreader users still get the note that the button is disabled.i am updating the proposed resolution reflecting plan for the installed button.

the only thing that could be considered and discussed is to add other visual cues to the button. meaning that the user not only needs to read or skim (install and installed is close) but also has additional cues like color and icons in addition to that? so all the current three states, "add and install", "install" and "installed", are clearly distinguishable

Hi @rkoller, as ✨ GUI install multiple modules at once. Needs work is in, I think IS needs to be updated.

Updated IS with work to do on this one for now. I will leave iconography to a separate issue if we want it; however, my belief is that the Installed DOES have a checkmark currently and we should KEEP it when converting to a button element.

We can also discuss iconography in the Queue/Dequeue language issue: 📌 [PP-1] Decide on naming Queue/Dequeue button text Postponed

utkarsh_33 → changed the visibility of the branch 3315859-communicated-the-statusstate to hidden.

utkarsh_33 → changed the visibility of the branch 1.0.x to hidden.

I have created a new MR which implements what is suggested in the proposed resolution, thought we might need some CSS to style the button as per Drupal standards but still marking this as NR to get initial feedbacks on the work.

2 issues I found while testing manually:

• Size of Installed button is not same as other buttons
• Voiceover does not announce this disabled installed button(Not sure if I tested this correctly)

Addressed the feedbacks from #30.

Changes looks good to me. Marking as RTBC

I've tested the latest state of the MR. There are several issues to note. At first a video illustrating the aural interface (current.mp4). As you can see and hear the button is excluded from the tabindex. reason is aside the newly added aria-disabled="true" attribute there is still the disabled attribute on the element which overrides the aria-disabled attribute behavior. i've manually removed the disabled attribute in the web inspector and recorded a second video (disabled_removed.mp4). as you can see and hear the button is now included in the tabindex and the "dimmed" label is being added and announced. in addition to that the mouse cursor should use the cursor not-allowed on hover or click as used for example on the tour module as an example for pages that have no tour available:

Removing the disabled attribute solved also color contrast issues for the button (SC1.4.11) and its label (SC1.4.3). So contrast wise it looks fine the only thing to note, the button style feels quite unusual having a grey to white gradient it looks like? styling wise wouldnt it better to have a button styled as an action link where you only have the checkmark and button label visible?

So the current state of the MR has the button as it was earlier. See the below SS for reference:-

I am not sure about the colour contrast part of the button but removing disabled property makes sense.If we want to keep it this way then i think it's ready for a review.

Alternatively i also tried

styling wise wouldnt it better to have a button styled as an action link where you only have the checkmark and button label visible?

which looks something like the below SS:-

This is not currently the part of the work in this MR as i was not sure about whether we are taking this approach or not.

I need further confirmation from other for what could be better approach to follow in this context.

Marking this NR as it needs feedbacks.

Yes thank you removing the disabled attribute made the installed button keyboard accessible. the only thing i would still add is the not-allowed cursor so for keyboard users it is signified it is not clickable in case they try. cuz with aria-disabled one can click but it has no effect.

In regards of the styling of the button. the styling of the button in your first screenshot looks not in line with the drupal design system. the styling in the second link goes in the direction of the action link i've suggested. problem, the label (installed) has a too low color contrast. the grey has a color conrast of ~2.5:1, but bold typography should have at least 3:1. and the checkmark also looks not in line with the drupal design system. i guess if the button label would use the color used on the example here: https://www.figma.com/design/OqWgzAluHtsOd5uwm1lubFeH/💧-Drupal-Design-system?node-id=5315-242&node-type=frame&t=gS098wgWgrUhycl8-0 (stylguide -> action link -> lists and spacing ) as well as the checkmark it might look more consistent with claro? (but not sure where the svg for that checkmark is located)

I'm picking this up today as part of NEDCamp's contribution day

updating IS with remaining issues since they're hard to parse out

and i'll set the issue back to needs work

I have addressed the feedbacks regarding the color contrast.I am not sure about which checkmark icon is @rkoller talking about as this was not changed in this MR any where, it is what it was on 2.0.x.
Also the cursor: not-allowed was already added in prior commits.
@rkoller can you now verify that the changes?

This is the latest look of the card.