Traditional file upload vs repository

Question

I'm working on a b2b web application where users might want to upload files for several purposes: assigning images and/or documents with specifications to their products or businesses, attaching files to private messages (PDFs, DOCs, XLSs), etc.

Now, instead of allowing the traditional method of file upload in each form, I'm wondering if it would be better to let the user have a repository where he could upload whatever file he wants, limiting the repository to a certain max size (depending on if the user owns a premium account or not) and then letting him link the file he wants from each form.

So, for example, in the Send private message form, instead of displaying the typical choose file input, I'd display the user's repository so that he selects the file he wants to attach, or even adds a new file to it in the moment and selects it.

Is this a good approach?

The only downside I detected so far is that users who have JavaScript disabled in their browsers would have to manually specify the ID of the file.

Answer 1

The potential upside of using a centralized repository is that if your customer reuses the same file many times over, he/she won't need to upload it on the server each time.

The downsides are more plentiful:

• Instead of a single action (select file for upload), the users are now forced to do 2 actions: (upload file to the repository + select file from the repository).
• Once the number of files gets large, you will need to add some hierarchy structure to keep it organized – for example, create folders. The folders are not inherently bad, but they lengthen the time it takes to find and select a file.
• Uploading a file may now require a considerable mental effort (in which folder do I put this file? do I need to make another folder? man, my repository is such a mess... I should clean it up sometimes...)
• What do you want to do if the user deleted/renamed a file that he sent with a message earlier? The recipient of the message may want to have access to the original file.
• Users will likely have security concerns about storing their files somewhere.

Answer 2

If it is likely that someone will have to send any given file many times, it is best to use a repository. If that is not likely to be a common use case, then I would suggest a simple file upload.

This is especially the case with BnB's as they are often out of the way in rural areas with poor internet connections. If they have to upload a file every time they send it (and possibly wait a long time for each file), they will tend to avoid sending high resolution images, and/or send fewer images. This unlikely to be what you want to happen.

My suggestion (in your caes) would be to use a repository, but not your own. Rather use people's existing Dropbox or Google Drive as a repository and just use their API's to connect to them. This is easier for users, faster to develop, and fewer maintenance issues.

Answer 3

If the users often sends the same files then this might be a good idea. But I would definitely also put a "file upload" on the message itself. What if, as Marjan said, the file isn't uploaded before - the user has to cancel the message, find the upload page, upload it, go back and rewrite the message...

The upload file in the message could put the file into the repository so that the next time a message is sent, that file could be selected instead of uploading it again.