#Needs usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-05-17 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMchale, @benjifisher, @rkoller, @shaal, @skaught, and @simhohell.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

While exploring the new responsive image form display widget we ran into one problem. On a standard 11.x-dev install with the responsive image module installed, and MR4628 applied, we had the following three options available for Preview responsive image styles:

2. Narrow
3. Wide

Our assumption was that based on micro copy you would either get the preview image added in the dimensions of the chosen responsive image style or you have no preview depending on your choice. But problem was no matter what setting we set the resulting preview looked like this:

Our expectation, based on the micro copy, would have been that this would only be the result in case option 1, no preview, was chosen. So we were not sure if this is a bug, and in general we've asked us how this feature is intended to work? We would need some clarification in that regard before we are able to make any recommendations.

We will also continue our initial discussion we've started in regards of the micro copy. There was already a clear consensus to change the label Preview responsive image style to Responsive image style for preview. "Technically" a user isn't "previewing a responsive image style", instead a preview image based on that responsive image style is being generated. About the corresponding description, there was the consensus to clarify where the image is shown (aka that it is shown on the edit form), and that "preview responsive image" is too verbose as well as misleading (There is only a single image being used, based on the responsive image style - but again we need to know how the feature is supposed to work).
One radio button option is called Bar with progress meter while within the description it is referred to as a progress bar. Aside this inconsistency in terminology it was also noted that the first sentence of the description is imprecise, the throbber actually is communicating the status of the upload, it is telling the user if the upload is still underway or was already finished. But the microcopy about the progress indicator would apply to regular image widgets as well. So making adjustments in that regard would be more suitable for a followup issue to keep things consistent between image and responsive image widgets.

But we will finish the discussions about the micro copy as well as the functionality in general as soon as the feedback is in. Thank you in advance!

Not sure what the best status would be in this case? I went with needs work but to postpone with maintainer needs more infos felt wrong since i am not the maintainer nor person working on this issue. I'll go with needs work, but please adjust accordingly if that is not the right choice and there is a more suitable one. Apologies in that case.

Resolved the Linting issue appearing on MR.

Mithun S → made their first commit to this issue’s fork.

Darren Oh → made their first commit to this issue’s fork.

Mithun S → made their first commit to this issue’s fork.

Think the MR needs to be opened.

Also feels like something we can add a test assertion somewhere to an existing test, if one exists know the tests are still WIP.

updated issue summary

For the record, the attendees at the usability meeting (Comment #64) were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @skaught, and @worldlinemine.

We all agreed that the two submit buttons ("Save translations" and "Delete translations") were confusing. Given that, I do not think we should implement a confirmation form.

Deleting a translatable string is temporary. As soon as someone visits a page where the string is used, the string is re-added to the list of strings available for translation. This whole approach seems confusing from a usability perspective.

Opinions at the usability meeting were divided. Some of us were in favor of each of these proposals:

1. Close this issue as "won't fix".
2. Add a checkbox as in the current MR, but not a second submit button. When the form is submitted, the checkbox has the same effect as deleting the text in the "Translation for ..." column.
3. Add help text to clarify that deleting the translation means the source string will be used.