UX for design for module admin

It is a lighter lift, if the admin page just listed the rules and had an edit and maybe a delete button. Then the rules editing would take place on its own screen (similar to the way nodes are edited)

Hi @swirt,
I have some ideas regarding the design and I am sharing it with you.

This image shows the state when the alt text validation is not enabled. We can see that 'Length Restriction', 'Prevent using filename in Alt Text', 'Validation Rules' sections are in read-only state.
Now when we are enabling the validation we see that all these sections turn operational.

Now when we start configuring and click on the 'Enable Length Restriction' checkbox, we are given a field where we set the max length.
Also when we click on add rule option we get somewhat this kind of interface.

Please do let me know about your opinion on this.

Thanks @arijit acharya I appreciate you working on this. I can not see the images you have embedded. They don't seem to have uploaded correctly.

Hi @swirt, sorry for the inconvenience, some some reasons I think the images got failed to upload. I have added it again, please review.

@arijit Wow these are really a very nice start on this. Thank you so much. I have a meeting with some UX friends in a few days and will go through these with them.

Thank you @swirt. I look forward to hearing their perspectives. Moving this issue in needs review state.

swirt → credited adriancooke → .

swirt → credited kesmith → .

I think for the guidance on the message fields we want something like "The pattern should begin with 'What's wrong". Followed by "How to make it right"
example: The alt text contains the filename. Please reword your alt to not include the filename."

@arijit acharya thanks for the mockups and thought process you shared. It was very helpful to get my head around what we’re doing here. I had a chance to discuss with @kesmith and @swirt, get some feedback, and came up with some ideas to consider:

Reworking of admin UI fields:

• Enable/disable all alt text validation (off switch preserves config)
• Customize alert headings
  • Warn heading text (e.g. “Alt text errors found on page.”)
  • Prevent heading text (e.g. “Alt text errors found. Page cannot be saved.”)
• Individual rule configuration:
  • Rule type
    • Alt cannot match image filename
    • Alt cannot match image title
    • Alt cannot exceed length (Max characters)
    • Alt cannot begin with, contain, end with (text, regex)
    • Alt cannot be empty unless decorative (how do we check for this?)
  • Rule status
    • Off, Warn, Prevent
  • Rule message (HTML)
  • Rule scope? (not MVP)
    • Global
    • Out out specific field?
    • Out out content type?

Alert the author sees:

Suggested pattern for message fields: “what happened” followed by “what’s wrong and where,” then “how to fix” and“how to get help”. For example (where the bolded text may be a heading):

Alt text errors found. Page cannot be saved.
The alt text in the {filename} image contains the filename. Please replace the filename with a description of the image. Get help with alt text →

The idea is that there would be default text but it can all be customized and we can provide authors with a link to get more information.

@adriancooke. These are fantastic! I am so appreciative of your work building atop @arijit acharya's work.

I have a couple of thoughts for possible change:

Global Validation status

I fell like there might be some confusion with the language of "all rules active" since that might be contradictory to individual rules having a status of "off". I appreciate kesmith's desire to not use "disabled" as the status option, but that does make it hard to say things in the global option like
"All enabled rules active". "All non-offed rules active" sounds funny.

Maybe the global status option descriptions could be

• on (all active rules applied)
• off (no rules applied)

Regex simplification

The pattern of regex being a separate option after selecting the rule type I think might be a bit confusing to code but also confusing to administrators because they could come up with odd combinations like choosing a "rule type" as "Can not begin with" and a regex that expresses end of string. That rule would never trigger. I think Regex might be better as a rule type option

@swirt @adriancooke I have a few thoughts around the language specifically, but also something else to suggest for the rules:
- For the individual rules - I don't see any way to edit or delete a rule (which just might not appear in the "rule building" part, so if that's the case, ignore this comment :) ) but for the "View rules" page we should have a way to edit or delete a rule.
- For the language: I wonder if we could say "Your page won't be saved" instead of "Page cannot be saved"? It's a bit friendly and avoids using passive voice.
- I love the "tell me what's wrong and how to fix it" language suggestion, @swirt, but I'm wondering if each rule having its own warning or prevent message will result in overload for the user reading through each one? For instance, if I have 7 images, none of which is decorative, and 5 of them get an error for 5 different rules, that's now 5 different pieces of feedback I have to read, understand, and fix. Don't get me wrong, I *love* "teach a man to fish" but I wonder if a more generic message suggestion for each might result in a better experience. I'm guessing most people, even with the option to write their messages, will stick with the proposed default message we're giving them, but I might be wrong!
- @adriancooke - this looks amazing! Should we include a tooltip or helper text with "Rule status" to explain what those different options mean? Or do you think users can infer the statuses from the "Customize alert" information?

@kesmith. These are all great points.

- For the individual rules - I don't see any way to edit or delete a rule (which just might not appear in the "rule building" part, so if that's the case, ignore this comment :) ) but for the "View rules" page we should have a way to edit or delete a rule.

This is covered by default drupal handling of multi cardinality. It provides the removal method. Also there is only this one form which is already an edit form, so you will edit right where you see them.

- For the language: I wonder if we could say "Your page won't be saved" instead of "Page cannot be saved"? It's a bit friendly and avoids using passive voice.

By the time they see the message on the back end validation, they have already attempted to save, so I think it makes sense to use past tense language.

- I love the "tell me what's wrong and how to fix it" language suggestion, @swirt, but I'm wondering if each rule having its own warning or prevent message will result in overload for the user reading through each one? For instance, if I have 7 images, none of which is decorative, and 5 of them get an error for 5 different rules, that's now 5 different pieces of feedback I have to read, understand, and fix. Don't get me wrong, I *love* "teach a man to fish" but I wonder if a more generic message suggestion for each might result in a better experience. I'm guessing most people, even with the option to write their messages, will stick with the proposed default message we're giving them, but I might be wrong!

This is a good point. if they have 7 images and they all fail the same way, I don't know how to coalesce the errors into one generic one that would still represent all the places they might have to fix it. If you have something in mind I want to hear more.
Also there is no default message for any rule, only the pattern we are suggesting.

I forgot one element on the call for a UX design. I neglected to reference the cron settings.

• cron on /off
• number of days between cron runs.

This is what is present currently but can be adjusted with any feedback.

@swirt - if I understand the cron setting correctly, each time I run the cron a new alt text report gets published, correct? And apologies if this is a silly question, but is there only one cron to rule them all? I know we used to force cron to run if our sites had updates that weren't appearing, but I don't know if there's like a whole-site cron, a report cron, an update cron, etc. I think this UI is ok as-is, but in the event that there's more than one cron (or you have an admin who is ignorant about cron like I am) maybe including why you would want this rebuild feature to be on or off and a suggested/best practice number of days?

@kesmith. Great question. Most sites run cron every so often (every 5 - 15 minutes usually). It is a way of handling tasks that no individual user needs to see/run. Cron is not usually something that a user/admin needs to run. It is the server running it. Yes Drupal provides an interface to run cron by hand, but it should rarely be something a human is running.

In this particular case, if the admin sets this module to rebuild the alt text audit report on cron and sets the number of days to 7, when cron runs. this module will look to see when it last ran, and if 7 days has passed since then. If 7 days have past, it will rebuild the report. On a site with a ton of content rebuilding this report can be pretty intensive, so we don't want it rebuilding often.

@swirt, @kesmith here are some ideas for how the report screen might be laid out:

Or see the higher-resolution atv-report-and-config-admin-screens.pdf (PDF) → version.

In the first diagram you can rebuild the report, query the report, and view the results in a table. In thinking this over, it seems like there are many variables that might mean some fields/columns are more important than others depending on your use case.

So before spending more time on thinking about the right filters and columns I wanted to share another idea, covered in the second diagram: might it be possible on the config screen to choose which columns to include in each of these places:

1. The filter section
2. The results table
3. The CSV output

My thinking is that these things don’t even have to be the same. The module could ship with some default suggestions, but if the user thinks that it’s helpful to have an image name or be able to query by it, they can add it (or remove it if not).

It seems like this could help get around the issue of making it hard to update the view later if we want to change it - instead, build it to be customizable from the outset. If users want to change their report screen layout they can.

Of course, easy for me to say. Not sure what it would take to implement or if it would be possible, so just sharing for consideration.

@adriancooke. This is great, thank you.

The report section makes sense and is completely attainable. The second section though for the admin settings is not really attainable.
The filters and the columns on the report are entirely controlled by a sub system in Drupal called "Views". Views gives any admin the ability to alter the View to move/add/remove filters, add/remove/re-arrange columns and much more. Any site will have the capability of modifying the report to meet their needs with Views. There is no reason that we need to rebuild that functionality with Alt Text Validation module's admin.

Is this the image title if the media library is used?

Yes and no. Image fields can have their own title field just like they have an alt field. Then when they are rendered, this populates the title attribute and alt attribute on the img tag. Image title column will surface the img title attribute if there is one.

I suggest swapping the locate of 'Image title' and 'File' columns so that it is easier to compare title and alt as many times those can be too similar.

Do these refer to any rule that was applied...

Yes this would list any rules/warnings that were violated. It would likely display them as an html list.

@adriancooke @swirt
I took a stab at Adrian's ideas with Steve's feedback - made a few personal adjustments to how much information is displayed and filterable, and added some additional guidance and supporting text. Feel free to take a look - I'm not totally sure the "chip" idea (where I list the filters I searched for directly above the results) is possible, but I thought having just a quick view of what I filtered by could be useful to the end user. Quick question for @swirt - will all the data in the table populate _even if I don't filter by it_? Or does it only populate when no filters/that specific filter is employed? I mocked it up to where that data only appears if it's filtered by it, but I think there is likely a use case for all the data appearing in the table all the time - but I'm sure there's just a "drupal does it this way" answer that I'm just not familiar with yet :D
Figma link

I think we might have veered off a bit here and crossed areas of concern here. This issue is about the admin screen, The other issue is for the Report ✨ UX design for alt text report Active .

Yep - moving my comment to the other thread!

@swirt @kesmith oops, that was my fault.