Drupal Usability Meeting 2023-01-27

It would be great to review the User Personas discussed last week to come up with a proposal for the ideas issue queue to get feedback from the rest of the community.

The group is actively tracking progress on:

• #3318110: [meta] Reorganize Block items in the administration menu

Issues brought forward from the previous meeting:

• #2591323: Workflow and text for installing themes is confusing
• #2860419: [Meta] Appearance page is too long and confusing
• #2035079: [PP-1] Figure out what to do with the install/uninstall modules page with notes:
  • #3307567: Drupal Usability Meeting 2022-09-09: started discussing the proposed options but ran out of time, possibly splitting the confirm form into its own issue (we may want to look at that for both modules and themes, standard pattern, consider implications of project browser), worth considering parity with Drush (and other extension/package managers).
  • #3310096: Drupal Usability Meeting 2022-09-23: @simohell presented the various proposals, but we again ran out of time to have a in-depth discussion, using the drop-button pattern on the module page for the existing links + Uninstall was suggested.
• #2569785: Placement of batch progress messages with notes:
  • #3322499: Drupal Usability Meeting 2022-11-25: We started looking at the issue but ran out of time.
• #3081500: Accessibility bugs with vertical tabs
• #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget with notes:
  • @AaronMcHale: Issue could use some guidance.
    In comment #109 the issue was marked as postponed for needing input from UX, accessibility and media initiative. Apparently there are some outstanding UX/accessibility questions (but I'm not sure what they are). This was echoed in comment #111.
    Comment #144 is asking what is needed to move the issue along (the postponed state seems to be causing some delays/confusion as to how to proceed).
    Perhaps we can at least take a look at what the issue is doing and provide some recommendations/guidance on how it could be implemented.
• #3325167: Revisit the redirect to 'add block' form in the 'add block content' form

#2245767: Allow blocks to be configured to show/hide on 200/403/404 response pages was mentioned in Slack. Looks like some questions around the exact wording and whether a "negate" option should be provided instead of the 200 status code checkbox.

@xjm tagged #3325445: [Policy] Remove tour module from core for review and sign off from the usability group before it can go ahead, noting that Tour is seen as a usability module and the core committers were not able to reach a consensus.

There is an open question about the wording of the warning message on #3333383: Create a redirect for the new Block types path.

This is an important issue for moving the Custom Block changes forward, I feel we should prioritise this issue at the meeting.

Followup info on #5, #2245767: Allow blocks to be configured to show/hide on 200/403/404 response pages. 1400 UTC is 3am my time, I regret I will not be able to attend.

This previously had a UX review as "Error pages", which asked us to remove the 200 response option, because "200 is not an error". Doing that required us to add a "negate" option to cover all use cases, and that introduces confusing possibilities. We did attempt to address that using radios and javascript #states to hide confusing choices, running into js bugs and complication.

We decided to simplify and rename it "Response status" instead, restore the 200 response as an option, and avoid the need for negation. Since a 200 response is the only other user-facing response apart from 404/403, this covers all use cases:

• Display a block on all pages (error and non-error)
• Display a block only on all error pages
• Display a block only on all non-error pages
• Display a block only on 404 or 403 (not both)
• Display a block on all non-error pages AND 404 or 403 (not both)

We would prefer not to revisit the above. Remaining adjustments are hopefully just labelling and the description text:

• @Lauriii asked for clarification in the description of what happens if nothing is selected. This is done, but no other core block condition plugin bothers to mention this.
• The word "Page" is ambiguous in Drupal, also used in the Path condition label (why?), but we do need a way to talk about a generic web pageview and its associated response status.

I have been checking this one https://www.drupal.org/project/drupal/issues/2492171 on sanitizing filenames on upload.