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.

  • And what about wanting to send a message and then discovering that the file I want to send with that message hasn't been put in my repository yet? Would I have to go to the repository and then come back? I'd prefer to have just "choose file to upload" as well and have it linked into the message and put in the repository automatically. – Marjan Venema Mar 26 '13 at 7:12
  • @MarjanVenema the idea was that as long as the user had JavaScript enabled, he could both select a file from the repository or upload one and select it in the moment – federico-t Mar 28 '13 at 20:02

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.
  • While I agree with most of your points, I think your first downside is flawed, why couldn't uploading also automatically select it? Assuming a situation where "selecting" is valid, of course. – Dave McClelland Mar 26 '13 at 12:40
  • Thanks for the answer! When I gave it a bit more of thought I realized that, indeed, the downsides are more plentiful (specially in cases where a user uploads a repeted file to the repository, or wants to delete one after "sharing it"). The way I ended up implementing it, users do have a repository but they don't know it and don't have to manage it – federico-t Mar 28 '13 at 19:59

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.