Uppy: Limit to N number of file?

[mohammadbhuyan]

Can I limit the Dashboard to accept N number of files. My current use case is to limit it to single file upload.

[arturi]

Hi! Yeah, it’s a good idea to add this. Could you specify, how you envision this working, so after one file is selected, if you try to add a second one, Uppy says no and doesn’t let you? And somewhere in the UI it says/indicates “1 file only”. I think this option could be combined with restricting file types, i.e. only accepting images, 2 maximum.

[hpvd]

+1 for this!

btw: seems to be already in backlog of features

core: restrictions — by file type, size, number of files

see https://github.com/transloadit/uppy/blob/master/CHANGELOG.md#todo

[arturi]

btw: seems to be already in backlog of features

LOL, yes, that slipped off my mind. Thanks.

[mohammadbhuyan]

UX is not my forte but we have handled same situation (another web app) where,

1. The UI starts with UI clue indicating user to select files for upload.
2. After selecting one file the upload button is disabled with tool tip (ex: "you are allowed to upload single file" ) and UI clue changes to "ready for upload"
3. If DnD was allowed, the drop target becomes inactive or change the drop cursor to indicate Drop is not allowed.

it is a bit tricky with Browser File Selection dialog where you have no control over to dictate it with N number of files ( 1 or many in the dir - AFAIR ). In that situation I think we are accepting the first N selection form the dialog but also prompting user that we have ignored some selection.

Hope this helps.

PS: Cool work guys! Looking forward to make it part of my production.

[hpvd]

just very rough idea:

show restrictions on top:

if restriction of file number is reached, remove "How to"

if any restriction is active when trying to ad a file: show sign and which/why it's not possible to add a file

[mohammadbhuyan]

Very good start. :)

But if file type is "allowed types", what if they are too long, lets say 20 types are allowed. Or fewer types but the strings are long in themselves.

I am thinking that the "restrictions" are not to be detailed out in the UI in the start. Usually, in any system, once the user is familiar with the system (what to do and what not to do), these types of information are no more useful for the user and ends up taking screen real estate. So where is the balance? Hmm...

Can it be that a visual clue is present to indicate to the user that there are imposed restrictions on this upload process and clicking that UI clue will bring the details in-line.

I personally hate more than 1 modal layers - dialog on dialog is nasty in my opinion.

[hpvd]

But if file type is "allowed types", what if they are too long, lets say 20 types are allowed. Or fewer types but the strings are long in themselves.

I am thinking that the "restrictions" are not to be detailed out in the UI in the start. Usually, in any system, once the user is familiar with the system (what to do and what not to do), these types of information are no more useful for the user and ends up taking screen real estate. So where is the balance?

This are many good thoughts!

On the other site, there are many cases users would be glad to know exactly what they have to "deliver".
Showing details only if something has gone wrong, may frustrate some users because they have to do some double work ( e.g. convert/export their files again before being able to upload)

In addition one may miss a chance, to make users happy because one directly accept "their" filetypes but they didn't know it and do some unnecessary time consuming converting...

One idea to solve these different cases:

One could provide 3 different options what uppy shows regarding restrictions:

• fully technical details (like in example above) [separate for each type of restriction]
• show nothing regarding restrictions [separate for each type of restriction]
• free text (e.g. "we accept all kinds of image filetypes no matter which size") [one textline for all types of restriction]

=> What do you think?

[mohammadbhuyan]

Providing the options is great. That will be a good start. Then there is always opportunity to add more options as more user provides use cases / feedback.

[arturi]

Hi all! Just wanted to let you know, this has been added in Uppy 0.17. Currently works like so:

Uppy({
  debug: true,
  autoProceed: false,
  restrictions: {
    maxFileSize: 300000,
    maxNumberOfFiles: 5,
    minNumberOfFiles: 2,
    allowedFileTypes: ['image/*', 'video/*']
  },
  onBeforeFileAdded: (currentFile, files) => {
    if (currentFile.name === 'pitercss-IMG_0616.jpg') {
      return Promise.resolve()
    }
    return Promise.reject('this is not the file I was looking for')
  },
  onBeforeUpload: (files) => {
    if (Object.keys(files).length < 2) {
      return Promise.reject('too few files')
    }
    return Promise.resolve()
  }
})
...
.use(Dashboard, {
  note: 'Images and video only, 300kb or less'
  ...
})

We’ll have more explanations in the release blog post. Live demo here: https://uppy.io/examples/dashboard/ (check the restrictions checkbox).

[hpvd]

perfect! Looks great!

In this example all types of images are allowed.
just some questions on this (maybe to put in the upcoming blog post..)

• Is there somewhere a piece of information which filetypes are recognised as type "image"?
• Is it also possible to allow only one special type of images? e.g. .png?
• if so, it should work for every, even exotic file types like ".abcd", isn't it?

btw
is there already any possibilty to show "things allowed" directly
(even before resulting message of first faulty try)?

[goto-bus-stop]

Is there somewhere a piece of information which filetypes are recognised as type "image"?

Anything with an image/something mime type, see this list: https://www.iana.org/assignments/media-types/media-types.xhtml

Is it also possible to allow only one special type of images? e.g. .png?

You can also enter a specific mime type like image/png instead of a wildcard.

if so, it should work for every, even exotic file types like ".abcd", isn't it?

Some rarer file formats will not be detected by uppy and anything that doesn't have an assigned mime type definitely won't. However, you can still filter those by providing a custom onBeforeFileAdded function.

[goto-bus-stop]

is there already any possibilty to show "things allowed" directly
(even before resulting message of first faulty try)?

There is now a note option in the Dashboard plugin allowing you to enter any custom text you want on the dashboard. See the example on the website :)

[hpvd]

awesome! Many thanks.

I could imagine, that uppy would be the future "FE" for every one who especially looks for using TUS for uploads. One good reason for this is dealing with huge files. Since these huge files are often special kinds of data (e.g. engineering or scientific data), it would be good to have short docu on providing a custom onBeforeFileAdded function...