Deleting Image within List-of-Image leaves behind an empty Image Widget.

[onetapbeyond]

I noticed an unexpected behaviour when working with the "image" type widget.

Deleting an image within a List-of-Image leaves behind an empty Image Widget. This can be potentially problematic in two ways:

1. After explicitly clicking "Remove" the user still sees an empty image widget in their display. From a usability perspective this seems a little counterintuitive.
2. Beyond usability issues, the empty image widget can later fail validation checks on Save. And that feels like a bug.

For a little background, I am using the following configuration for the tests that follow:

  - name: natural
    label: Natural World
    label_singular: Photo Gallery
    create: true
    i18n: true
    fields:
      - name: naturalPhotos
        label: Photos
        widget: list
        required: false
        i18n: duplicate
        fields:
          - name: src
            label: File
            widget: image
            i18n: duplicate
            required: false

Scenario 1: A Usability Issue

Step 1: The user uploads a few sample images.

Step 2. The user clicks "Remove" on one of the sample images.

Notice the area I have highlighted in red in the above screenshot. On clicking Remove the image associated with the widget has been removed as expected. But the empty widget itself is still shown in the display.

Step 3. The user clicks "Save" and then re-opens this Entry...

The image that they previously deleted is still gone. But the empty Image widget that corresponds to that deleted image is once again displayed. This may prove quite confusing to an user who might reasonably expect a deleted image to be...well, deleted :)

As you can see above the "empty" widget for the previously deleted image is still displayed as if still a valid part of the entry's content.

Expected Behaviour?

If possible, when the user clicks Remove on an Image Widget the image and the widget for that image should both be removed so the user can see and truly feel that their deletion has completed successfully.

Scenario 2: A Potential Bug

In the Scenario above the required configuration option for my list-of-images was set to false. But if that configuration is updated so the required: true is enabled then the usability issue described becomes a potential bug. Again let me explain with a series of screenshots:

So what follows is the same as before only this time the required: true config option is enabled on the list-of-images for this collection.

Step 1: The user uploads a few sample images.

Step 2. Delete one of the sample images.

Same as before, delete one of the images in the list-of-images:

As you can see the image is gone. Although the empty Image Widget is still displayed. And this is about to become a potential bug...

Step 3. User tries to click "Save" on the Entry

Notice the "This field is required" and "One field has an error" error messages in the above screenshot. This time when I try to Save the entry validation fails because the empty Image Widget associated with the deleted image (which ideally should no longer be on the page) is failing validation tests because required: true is enabled.

Expected Behaviour?

The "Remove" action deletes both the underlying image and the Image Widget associated with that deleted image. In this way the "deletion" would be clear and explicit to the user (no intermediate state where they now see empty Image widgets) and the situation where validation fails on content that the user has already explicitly removed would never occur.

Final Observations

I have tested a different few use cases by changing the values of the i18n config setting including disabling duplicate etc. But no difference, the problems described above are still present. So it does not seem that activating i18n on the list is contributing to the problem. I just mention this as it might make your own debugging a little simpler.

[kyoshino]

I don’t see a problem here... That’s how the List widget works with required: false 😉 Deleting a parent list item when deleting an image is rather confusing as the behaviour is inconsistent/unexpected.

But I understood the situation and came up with an idea.

First, if you want to have only one field, use the field (singular) option instead of fields according to the document.

Then, I’ll hide the Remove button on the Image widget for that particular configuration, just like the Image component does in the Markdown widget:

Currently the Remove button on a list item is under the 3-dot menu, which is hard to find, so I’ll also change it to a button. The result would look like this:

[onetapbeyond]

Keeping the "Replace" button and getting rid of the "Remove" button on the image itself makes a lot of sense. I honestly can't think of a use-case where you would want to "Remove" an image but not the encompassing widget. "Replace" seems to cover all practical use-cases.

Your proposal to expose the "Remove" functionality from the 3-dot menu at the top-level providing users with a single-click on X to "Remove" that widget from within a list of widgets looks great. Whenever you push these changes I'll be happy to try them out and provide feedback.

[kyoshino]

I’ll hide the Remove button also if the image widget has required: true. If it’s false, it’s possible to make it an empty, so the Remove button should remain.

[kyoshino]

The Remove button display condition changed in v0.71.2.

[onetapbeyond]

Having just tested out this latest update I can say that the user experience feels much improved...much more intuitive.

When testing a single Image widget that is configured as required the absence of the old "Remove" button feels exactly right. You either keep the image you have or you "Replace" it. But definitely some image is required to be there.

In the case of the a List of Image widgets the addition of the one-click X button on each Image widget in the list to cleanly delete any image from the list again feels very intuitive and easy to work with.

Thank you very much for these updates.