The most basic upload mechanism is the file picker. This can be difficult to use on desktop devices, but works well on mobile devices. You should support using a file picker as a minimum before adding alternatives.
From working on Passports, I'd say this is one pattern where the type of audience will have a big impact on what sorts of patterns you use. If users are generally comfortable with file upload dialogs, then something 'standard' is ok. If they struggle - then they really struggle. Many of our issues come from users needing to get the file off of another device before upload. This has proven to be especially hard.
I did research looking at lots of 'social' type websites when I started on passports - those that do photo uploads or avatars. The overwhelming majority use the word 'upload'. We've found in research that less technically proficient users don't know what upload means, but they have a general idea that it's something to do with computers.
Tim - sorry, missed this before. Brain spew commences. John - can you also contribute? Will add some screenshots later.
We've gone quite far down the route of different upload methods because it's by far the hardest part of our service. I feel for many services (possibly with a more technical audience), a more typical upload picker may be suitable.
Basic file upload (aka file picker)
This UI can work well if users are familiar navigating a file system and selecting files. Some users can still struggle if they're unsure where the file they want is.
If users are unfamiliar with file system navigation (many are), then a file picker can completely block their progress.
Drag and drop is used alongside 'browse' as our user research showed some users would upload many reports in a single visit and not many users knew how to do this through browse. We did try multiple 'browse' buttons but that tested terribly – users repeatedly clicked the first 'Choose file' button and didn't realise they were overwriting previously chosen reports.
We create the list of reports above the drag and drop box irrespective of how the user selects the files because we perform report-level checks, like file type, size and length of file name, that stop the file from being checked for formatting errors. It gives the user more control and provides earlier feedback.
For The Queens Awards for Enterprise we require more information with each file, so we have come up with the following interaction. The upload button can also be pressed multiple times to attach more than one file.
Michael - you could tackle the above another way: Firstly, just let users enter URLs in the main body of the text. I'm guessing some users will do this anyway. That way there's only one kind of additional action - 'Upload a file', which will make it significantly easier to design. Given that there's a maximum of 4 attachments you could even just offer 4 file attachment controls on the page, and do away with the whole 'Add another' headache altogether.
Users familiar with drag and drop from other software or things like Gmail have used the feature during testing. They've found it easy to use and like the visual changes to the area when they are about to drop a report.
Those who didn't use it said they were unfamiliar with it and are used to browsing for a file. There was uncertainty about how to drag and drop without having to resize windows and opening Windows Explorer.
People with more than one monitor found it easy too.
We don't have any mobile device users – due to security and not being able to access their files – so it hasn't been tested on phones or tablets.
Many users have email set up on their device and feel comfortable with the idea of emailing. This can be an effective route to receive files (particularly from mobile devices), but presents several challenges:
getting users to enter the correct address,
slow upload times
email often miss-configured
if something goes wrong, it's hard for the service to know where it went wrong
On passports we considered two different email routes:
Give the user a custom email address that identifies them.
This may work well for repeat sending (it's a pattern Flickr use), but may present difficulties in getting the user to correctly enter the address.
Have the user email a generic address, but reply to them with a code they can use.
Using the code means you're effectively building an email confirmation route. A service could ask up front for the user's email address and check for that, but sender addresses can easily be faked. Replying to the address with a code tested well with Passports (provided the user could send the email in the first place).
Upload from a mobile device
File uploads from a mobile device (particularly photos) can often be much easier for users. If they can be directed to access the service from a mobile device, they may be able to upload much more easily.
For passports, once they've uploaded from their other device, they can either continue to use the service on that device, or get given a code to 'retrieve' their file from another device.
Third party integration
Letting users upload through a third party may be an easy way for them to provide files, so long as it's likely the file exists with the third party, and they're already connected with the service. However, this method is likely to target more 'advanced' users - it won't help users who don't know what 'dropbox' is.
Filepicker is an example of a 'drop-in' way to let users connect multiple services.
Several users have queried in Passports user research whether we could 'link with Dropbox'. It's something we may consider, but right are concentrating on users who aren't capable enough to know how to use dropbox. Ie Dropbox integration may be convenient, but these users tend to be capable enough to use other methods.
this makes email address a requirement. What do we do with people who don't have them? Or share an account. I would recommend they open one and provide links to Gmail, Outlook. I think the complexity of supporting alternative models is too great and could impact too much on the large majority.
Some users want to be able to share their sign in with trusted parties to review their application. A time limited email doesn't work in this scenario. Ideally you'd set up user accounts with separate access for each of the individuals but for some services this might be overkill. Having username and password allows users to easily share access.