Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI and functionality over different file field types inconsistent #9473

Closed
3 tasks done
martijn-dev opened this issue Nov 4, 2021 · 0 comments
Closed
3 tasks done

Comments

@martijn-dev
Copy link

Preflight Checklist

Describe the Bug

There are 3 different kind of file field types:
image

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:
image

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.
image

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:
image

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.
image

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.
multifile_bug


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

Cheers!

To Reproduce

Just follow me in the above story

Errors Shown

none

What version of Directus are you using?

v9.0.0-rc.101

What version of Node.js are you using?

v16.6.1

What database are you using?

Postgres 13.3

What browser are you using?

Chrome

What operating system are you using?

Windows 10

How are you deploying Directus?

Docker

@directus directus locked and limited conversation to collaborators Nov 4, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants