Drupal Usability Meeting 2023-11-10

@sime brought up ✨ Allow end date to be optional Needs work in the #ux channel on the drupal slack

Add ✨ Allow end date to be optional Needs work and 📌 Make Description Field Labels Consistent Needs work

benjifisher → credited AaronMcHale → .

benjifisher → credited Emma Horrell → .

benjifisher → credited simohell → .

Here is the summary provided by the Zoom "AI Companion". I have not edited it except for formatting.

Quick recap

The team discussed the usability of the Admin form and the content editing form for entering data in the field. They considered various aspects such as the usability of checkboxes and radio buttons, help text, and validation timing. The labeling of the 'optional end date' field was also discussed for clarity. The team agreed to further investigate and improve the usability of these forms. The use of radio buttons for required fields was also discussed for consistency. The team also identified the need to improve the error message for clarity. A more thorough review of the form errors was proposed by Benji, which the team supported. The idea of creating a more usable field to encourage site usage was also raised.

Summary

Optional End Date Feature in Drupal

Benji moderated a discussion about an issue related to the optional end date feature in Drupal. Ralf presented the issue and demonstrated some scenarios, expressing confusion over the intended functionality and pointing out discrepancies between his expectations and the actual behavior. The team also identified a need to review the merch request and discussed the potential impact of the optional end date on validation when the field is not required.

Admin Form Usability Discussion

The team discussed the usability of the Admin form and the content editing form for entering data in the field. Various aspects were considered, including the usability of checkboxes and radio buttons, help text, and validation timing. The labeling of the 'optional end date' field was also discussed, with Simo suggesting it could be clearer and Aaron proposing the use of progressive disclosure for easier understanding. The team agreed to further investigate and improve the usability of these forms. Benji proposed a couple of ideas to improve the user experience for a field in a form, which were discussed and considered for implementation. Ralf expressed concerns about ambiguity when the required field is not checked, yet there are still constraints, and Aaron suggested a demonstration of the issue. Simo noted the need to fix the error message.

Radio Buttons vs Checkboxes: Form Field Discussion

Simo expressed concerns about the use of radio buttons for required fields, as people are accustomed to seeing check boxes for such fields. The team agreed on the importance of consistency across field types. They discussed the configuration of an admin form for a link field, deciding to turn the field from a checkbox into radio buttons. The team also decided to keep the scope of the form simple for now, with the possibility of expansion or change in a follow-up issue. Simo and Benji suggested moving a certain feature to the instance level, which Aaron supported. The team also discussed the change of a component to radio buttons, with Benji feeling it would make the form more clear. Ralf raised a question about the necessity of the description when the component changes to a radio button, which remained unresolved.

Date Range Field Form Confusion

Aaron, Simo, Benji, and Ralf discussed the challenges with a date range field in a form where the end date was optional. They agreed that the setup was causing confusion and considered it a potential follow-up issue. The team also identified that the error message was unclear and needed improvement, but decided it was out of scope for their current discussion. Benji proposed a more thorough review of the form errors, which the team supported. The idea of creating a more usable field to encourage site usage was also raised. Furthermore, Benji provided a boilerplate for Sime to use as a framework for his comment, and the issue of consistent description field labels was briefly mentioned, referencing a previous review.

Assessing Text Readability: Team Discusses Guidelines and AI Tools

Simo inquired about the methods used to assess the reading level of text. Benji clarified that there were no specific standards, but guidelines exist. Aaron proposed that the interface text standards might need updating and suggested that AI could be beneficial in this process. Simo noted issues with the text highlighted by a reading level website. The team agreed on the value of having guidelines or instructions on how to check and improve readability. They also acknowledged the importance of reliable tools, but they agreed that these tools could not entirely replace their roles in reviewing and recommending improvements. Ralf suggested incorporating automated tests for text quality in their workflow, which Benji found promising and suggested exploring further. Simo brought up the possibility of automation helping to identify areas that need more thought. The team agreed on the potential benefits of such tools and decided to further explore them.

Next steps

• Ralf will post a draft for an issue related to the extent page for review in the slack channel.

@benjifisher added the links to the transcript and the recording to the issue summary and @sime left a comment on the issue we've discussed: #2794481-209: Allow end date to be optional → . so all remaining tasks are done.

Automatically closed - issue fixed for 2 weeks with no activity.