Improve consistency between various file interfaces

[martijn-dev]

There are 3 different kind of file field types:

File: A single file field.
Image: A single file field for only an image. Which is actually a file, so you could say, the same kind of field as "File" but with a slightly different interface. (So it could be just a file field with an option to only allow images? Correct me if I'm wrong)
Files: A M2M structure with file fields.

This results in these 3 different kind of interfaces:

In my opinion, and from a standard UX experience kind of view, I think these interfaces could be slightly more the same.

• A drag & drop window is not really something that only works with images. This could work with any kind of file.
• If you place the drag & drop functionality on the "single file" kind of interface you would get an interface that could work for both.

I actually found out that I am able to drag a random other file (a .txt) into the drag & drop field (of an image field) and this does not give any errors. I'm also able to save this. So an image file field actually accepts any kind of file. This could be considered as a bug.

Here we come to the point that I don't really see any difference between an image file field and another file field. It's just a slightly different interface that is still accepting any kind of file.

Wouldn't it be easier to merge the file and image field back to just 1 field type: file. And then create a consistent interface for a file field that is the same as for a file field rn + drag & drop functionality.
And next to that create a good filter system for files. That makes it possible to only select images, or videos, or pdf's etc. so you cover all kind of files. I guess this would be on extentions. In the normal interface we could cover a set of extentions under a 'group' called images and this as well for videos etc. and then in the advanced interface the possibility to select specific extentions (*.jpg, *.png etc.)

Let me know your thoughts.

---

To test the new feature #9285 of filtering on subfolders I added the subfolder "test" to all of these different fields:

I found out that this functionality is only working on the "image" kind of interface, not on the file and multi file interface. This could also be considered as a bug.

---

In addition to feature request #8999. I found out that it is actually possible to restrict users to only take files from the local asset library. But this is only possible on the multi files field. Again, by making the interface for all these file kind of fields the same this feature could be implemented on every file field in the same kind of way.

Next to that I found a bug under the button "Add existing" in the multi file interface. It is overwriting files that have already been add to the field, by the new ones. Where you would actually expect the files to be added to the rest.

---

I covered a few things in one post. Let me know if I should split some things up for the overview.

Cheers!

[rijkvanzanten]

Great ideas all around! I've moved it to a discussion, as everything is technically working as intended currently 👍🏻

[benhaynes]

This should probably be a Discussion, not a Bug Report (Issue), but I know you've reported some inconsistent UX in here too... though those should probably be separate tickets to track. Still, I appreciate all this insight! My thoughts:

Yes, the only difference here is the interface... that is the purpose behind these being different Interfaces! Haha. While the core logic, etc might be the same, the purpose of an interface is to provide different GUI options for the same data type (files/images in this case). There are many ways to accomplish this, and it will always be difficult to know if something should be TWO interfaces or ONE interface with options to change UI. A big part of this comes down to how much code is needed for the individual GUIs, and does it make sense to keep them separate so the code stays readable/maintainable.

That said, here are some ideas:

• Yes, all image/file interfaces should support drag and drop
• Yes, each of these interfaces should probably support all file types (not just images)
• Yes, we can get the GUI similar for each

I would recommend:

Single File

• This works with images or any other file type.
• Always includes a dropzone for drag-and-drop, full width/height of the interface
• By default this would be the "input" style (with tiny file/image thumbnail on left) so it fits well within forms
• Preview needs to show file type/extension when preview image isn't available (no broken image icon)
• In Medium/Large mode (see below), I think it might be nice to have the different upload options as buttons on the interface itself, instead of in the context menu. This makes it easier to click on what you want.
• Options
  • Preview Mode: Small: Input Style, Medium: Thumbnail, or Large: Thumbnail
    • Small would look like the file GUI now
    • Medium would look like the image GUI now
    • Large would be a taller version of the image GUI
  • Thumbnail Mode: Cover or Contain
  • Uploading Files: Toggle
  • Select Items: Toggle
  • Upload Folder: Choose Path
  • Allowed Types: A CSV of allowed file types, maybe tags interface

Multiple Files

• This works with images or any other file type.
• If uploading is enabled, there should be a drop zone on top of the whole interface... you should NOT have to click a button to get that modal. Also, not sure if we always SHOW the drop zone (dotted line border) or only on the drag-enter event.
• Options
  • Preview Size: Small (current size), Medium (slightly larger rows), or Large (even larger rows)
  • Thumbnail Mode: Cover or Contain
  • Uploading Files: Toggle
  • Select Items: Toggle
  • Upload Folder: Choose Path
  • Allowed Types: A CSV of allowed file types, maybe tags interface
  • Display Template: Should have a smart default already there... or we remove this and just hardcode what is shown.

[benhaynes]

@martijn-dev — not sure if this is something you want to take on, but I agree that these improvements are important and should be done. The Core Team is a bit slammed, but I'm happy to guide you (or anyone else) through what we need for a PR. ❤️

[rijkvanzanten]

Heya! Thank you for taking the time to submit this request!

It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊

This request will now be closed to keep our discussions tidy. Please reach out if you have any questions!

For more information, see our Feature Request Process.