Uploading files has been done since the ice age of web development. In fact uploading a file using Html4 and an iFrame is pretty easy and does not even require a page refresh and about 0 line of code on the front-end, obviously you won’t get a progress bar but does it really matter?
Uploading in a nutshell:
<form method="POST" id="frm_upload_logo" action="/ui/settings/logo" target="upload_logo_iframe" enctype="multipart/form-data">
<input type="file" name="logo">
</form>
<iframe src="/blank.html" name="upload_logo_iframe" class="upload_frame"></iframe>
<script>
$("iframe[name='upload_logo_iframe']").load(function(){
if ($(this).contents()[0].URL.indexOf('/blank.html') == -1)
{
// Upload is complete, do something
}
});
</script>So… Html5
Looking for a easy way of implementing desktop drop file upload for CakeMail I was confronted to 2 issues. One, I’m not sure anyone is using drop file uploading beside web developers using Gmail. And also, my current implementation require 0 lines of code & is stable in every browser. Should I even think about implementing a point of failure with a different behaviour in older browsers when I got this solid solution?
Dragging, really?
Trying to look for articles on the usefulness of the drag and drop file api is futile, you will be greeted only by articles talking about implementation in 50 ways possible. Only thing left to do? Asking friends if they ever dragged a file in their browser. The response is overwhelming, 0 ever tried it.
Frankly even me when I do it I don’t find it’s a great experience even if, I agree, that it is sometimes convenient. It always involve bringing my finder window at the forefront, closing the multiple finders I had open, moving the finder so I can see at least a part of the upload box, and finally dragging it in a partially shown box. Not what I would consider a great user experience.
Really not sure this is helping normal users navigating your app, finding that file in their folder in another window also gets them completely out of your app. Personally I think we just like it because we drool at the fact we are dragging files in our web apps and it works, not because it’s really useful.
The Html5 file api
Then there is when you need to upload big files, now you get a bit of trouble with html4 upload. There is no api giving you progress on your upload and that arguably can be pretty useful. But in this day an age, you need to really think what a big file is when most people upload at 300k per seconds I rarely see a use case for that (beside for video and big archived files).
I’m I saying that you should absolutely not implement those api’s? I’m not, if you have time on your hand and want to add some alternative paths in your app great, or if you are uploading big files then you need a progress bar instead of just a gif loader. But I think you should really think about the usefulness of those integration.
In the end you still have to default to HTML4 form uploading for IE users and having 2 implementations for the same functionality always add complexity, testing time and bugs.
Got any articles or paper on uploading files user experience design? Please post them in the comments, I would be more than happy to read them!
When you are certainly not the first person needing a particular feature, chances are that there exist a library that already does it. No need to reinvent the wheel. I recently had the need for big upload inputs in our CMS and tried plupload (http://www.plupload.com/). File upload being a complex matter, I prefer to use such a library because it might address bugs that I would not be aware of if I tried to develop it from scratch myself. It has a fallback for html4 browsers, with stripped down features (no chunking, so no progress), and it does almost anything you’d need out of the box. It does not support drag and drop right away, but if you need it it’s easy to find tutorials by people who already done it.
That said, I agree that drag and drop is not a must-have feature. It might even do more harm than good… Nothing more frustrating than writing a long email in gMail, drag-dropping an image in it and seeing your browser loading the image in the main window instead of adding it to the email. You hit back, and poof, your long email has disappeared into oblivion. They made it better now, so you have a visual indication that you are about to drop the image in the content. Still, that kind of feature needs to be 100% tested, bug-free, and bulletproof, otherwise its better not to have it.
Then you send an important feature to a 3rd party that you rely to work, even on untested new browser like ie10 that never been taken into account on older plupload versions.
Also, if you are using plupload only for html4 uploading, i’m sorry but you are doing it wrong. You introduce hundreds of line of code for something that takes 5 lines.
2 years ago, custom implementations of plupload was also nothing like stable on all browsers (would not load the folder window on ie7), I guess they do better now.
Well that’s true of any third party library, from TinyMCE and plupload, to form validation. After all, when you validate a form, you rarely (if ever) need every functionnality that the library offers, so you also import hundreds of lines of code for nothing. Yet, your form validation script is very useful to a lot of people.
Using any third party library is always a risk. You never know, for example, how long they will take to update to account for new browsers, as you point out. That’s why you have to check how serious the authors are, and you also have to be prepared to change strategy at any time.
The trick is to implement any functionnality in its own encapsulation so that you can switch solutions easily. If you implement a file upload through an iframe, all the process should be managed by an object, that for example returns a $.Deferred with the tmp server file name in the result. If then you need to switch to any library or custom solution, all you need is to implement the same interface and your code will still work.
File upload is a situation I had to deal with recently. My older method involved a javascript-generated invisible iframe that loaded a php with a json-encoded response. It has been working for years, except in the case where the files were so big that I needed chunking and a progress. That’s the main reason why I switched to plupload, and it works just fine. I certainly won’t say that iframe is not a good solution, it is. But if you need a more complex solution, yes there are libraries out there that you can rely on.
There is a faily big difference between plupload and tinymce in the sense that creating something like tinymce is hard and takes time, html4 upload is all the contrary, it’s easy.
Like I said in the article uploading big files is one of the situation where it makes sense to use a more complex tech. That being said plupload got 244 issues in their repo, that speaks for itself for me, but if you can own that code, all the better.