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.