- 🇪🇸Spain Carlos Romero
carlos romero → made their first commit to this issue’s fork.
- 🇺🇸United States w01f
Wondering if this improvement will also work for images stored in cloud storage options such as S3, Azure, etc. via modules such as the S3 File System → and Flysytem → ?
Once the images are stored in the external cloud storage, will this still work in capturing exif data on demand for already loaded/saved images and media? - 🇩🇪Germany rkoller Nürnberg, Germany
Usability review
We first discussed this issue at 📌 Drupal Usability Meeting 2024-09-27 Active . The link to the recording is https://youtu.be/cWtwA63z-IE. For the record, the attendees at the usability meeting were @amazingrando, @anmolgoyal74, @benjifisher, @rkoller, @simohell, and @zetagraph.
We revisited this issue at 📌 Drupal Usability Meeting 2024-10-04 Active . The link to the second recording is https://youtu.be/JPxvcpNXY0Q. For the record, the attendees at the second usability meeting were @AaronMcHale, @avani.bhut, @benjifisher, @rkoller, @shaal, @simohell, and @zetagraph.
Yesterday we revisited this issue for a third time at 📌 Drupal Usability Meeting 2024-11-15 Active . The link to the recording is https://www.youtube.com/watch?v=8DqSpKVK768. For the record, the attendees at the usability meeting were @benjifisher, @rkoller, and @simohell.After taking a look at the current state of the MR, we’ve mainly focused on the points raised in #138 → , since those cover most of the remaining open questions from an UX perspective, and we’ve assessed their validity and relevance.
1. First, we went through the different scenarios that might happen aside a successful update:
Scenario A (No changes and therefore nothing to update):
It was considered as a nice to have but optional, not a blocker at this point, since it is a difficult task to determine if a media item is changed or not. So we leave it up to the people working on this issue if they want to cover scenario A already within the scope of this issue or if they would prefer to move it to a followup issue. Our consensus for the status message was:Nothing to update. Media item [x] remains unchanged.
In contrast, the other two scenarios should definitely be covered within the scope of this issue, since in both cases content might be removed and/or lost. As Laura Klein stated in her book “Build Better Products” -
Good design doesn’t lose data or state just because a user has performed an action in a surprising way.
. To prevent any potential data loss, like missing thumbnails in the frontend, the group agreed on adding a confirmation step to each of the two scenarios. So that the user becomes aware, that something is off and that they might experience a potential subsequent data loss, when the metadata of a media item is updated from the source. In the case of remote media items, the source might simply be temporarily unavailable due to an outage, just as, for example, source files where the file folder is being mounted from a file system and that file system is unavailable - without a confirmation step, the data would get removed when the metadata is getting updated. Our recommendation for those two cases are as follows:
Scenario B (The local source of the media item is missing):
Description:
The source file for media item [x] is missing, unable to refresh.
Buttons:
Remove thumbnail
Cancel
Status message after...
…theRemove thumbnail
button is clicked:Thumbnail removed for media item [x].
…theCancel
-button is clicked:Canceled. Media item [x] remains unchanged.
Scenario C (The remote media item the source is unavailable):
Description:
The remote source for media item [x] is unavailable.
Buttons:
Retry
Cancel
Status message after...
…theRetry
button is clicked and the refresh was successful:Updated metadata on media item [x]
, while if the refresh fails, the confirmation form is shown again.
…theCancel
-button is clicked:Canceled. Media item [x] remains unchanged.
It has to be noted that we had a clear consensus about the importance of having a status message after a button on a confirmation form was pressed. There is always the possibility that someone is clicking a button on a confirmation form, either absent-minded or by a stray mouse click. The subsequent status message keeps the user in the loop and informed about the made choice.
Aside from the refresh of a single source, there is also the case of refreshing more than one source at once via bulk actions. Question is, how to handle things with more than one case of scenario B, more than one case of scenario C, or even a mix of both? You can’t run someone through a chain of tens of single confirmation pages. One option is that the confirmation pages for scenario B might be combined into a single page, the same as the confirmation pages for scenario C, or all confirmation pages for scenario B and C might be combined into a single confirmation page. But due to the fact that there is no existing UI pattern in Drupal Core yet, we don’t want to hold back the current issue, and we would recommend moving the bulk refresh of media items into a follow-up issue.
2. In regard to the microcopy, we considered the term
Refresh
as suggested in #10 → to be the more clear and accurate choice.Update
is a loaded term, in combination with the fact that all the other options (edit
,delete
,translate
) on theOperations
drop-down point to forms on other pages. That way, the user’s assumption might be thatUpdate
also points to a dedicated page or dialogue that entails an active manual interaction. In addition to that, all the other options in theOperations
drop-down are single-worded verbs. Therefore, we would recommend the following change to theOperations
drop-down option:Update metadata
->Refresh
The term
metadata
is also sort of an abstract and ambiguous term in regard to its scope in this context. It is not clear what kind of data is getting refreshed by the optionUpdate metadata
. Is it only the associated fields or also something like the thumbnail, as already mentioned in the issue summary. To make things more explicit we would recommend the following change to the bulk action option label in the follow-up issue (again in line with the suggestion in #10 → ):Update metadata
->Refresh from source
3. We also checked if there were already help topics for the other options available on the media page, but we were unable to find any. So we had the consensus that it wouldn’t be necessary to add any instructions about the
Refresh
option to the help topics at this point.4. One additional detail we’ve noticed during our testing. If you are manually replacing an image in the file system, then hit the
Update metadata
option, the thumbnail is properly updated onadmin/content/media
. But if you now click theEdit
-button for the media item and then click the link to the source file, the old replaced image is still shown. Could that be a caching issue? We haven’t had the time to investigate in more detail.I am setting the issue back to
Needs work
and remove theNeeds usability review
tag. If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack. - 🇪🇸Spain vidorado Pamplona (Navarra)
@r-mo, ¿Could you tell us if this is solved by using this module?
https://www.drupal.org/project/static_asset_cache_buster →
If so, ¿Should we get along with this issue queue and commit this into core, or should we rely on that module?
I'll change the issue status to "Needs review" in order to any maintainer could answer to that, after your feedback.