Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

We're developing a web application which has a feature to upload local files to a server. The application is developed using a rich web application framework called Vaadin

The framework is very capable as a whole but I've discovered a problem for users using Firefox. If a user that uses Firefox double clicks in the file browser window (something I always do when selecting files in a file browser dialogue) there is a bug in the framework which will forward one click in the double click to the application which is in the background.

The forwarded click may have some unsettling effects such as the view switching and sometimes the application crashing.

This is a very serious problem since it will make the application look unreliable.

The bug is reported to Vaadin but hasn't really caught enough attention, so the problem will persist for some time.

The problem is avoided if the user simply selects a file and clicks "Ok" or selects a file and clicks "Enter", it's only when double clicking that the problem appears.

My question now is how I should adjust to this. There is a risk of error and we know it, how should I communicate this to the user in a way that it's registered and observed?

share|improve this question

3 Answers 3

Can you get an 'instruction' message into the workflow:

To Upload: Select a file and click "Ok" - (Do not double click)

share|improve this answer
    
I'm not a great believer in messaging; I'm not convinced they're often read. I don't have any alternatives though. –  Jimmy Breck-McKye Aug 13 '12 at 14:16
    
Agreed. It's not ideal. –  PhillipW Aug 13 '12 at 15:17

You can't really communicate this since this will be habitual. It's like trying to stop halfway in sneezing - yuo can do it but it takes enermous concentration.

Instead, what you can do, is to leverage cognitive speeds on this habit: you know that double click occurs within about 100-200 ms (I don't remember the exact timing), and that it's far lower than the user's ability to switch between tasks: that is, if you've got a click in 200 ms when using a file selector in Firefox, it's pretty unlikely it was deliberate.

So, if you can detect when the file dialog is opened, do the following algo:

if browser=='firefox':
     add transparent fullscreen div to window
     on(transparent div).clicked:
          remove transparent div
     on(file).selected):
        wait 200ms
        remove transperent div
    on(filewindow).cancelled:
        remove transparent div

The only problem here is when the framework doesn't allow you to handle cancel, so the user can close the window and click elsewhere instead.

For this, you could create a modal dialog with a gray semi-transparent background (meaning that the interface behind is temporary disabled), which would express the system state. The modal dialog can have any texts basically, the users will hit "OK" anyway.

You should still hide this dialog along with the disabling layer after the user has clicked anywhere, or 200 ms after the file was chosen.

If you can't grab the "file selected" event, you could try to grab it with starting a timer and check at every 100ms if a file was already selected.

Edit A javascript solution for those who're in need for it.

share|improve this answer
    
Thank you Aadaam. I was thinking the exact same thing that you propose, but I unfortunately found that it doesn't work. The upload component is using the webbrowsers' native file browser, and to through the framework trigger a modal window/screen lock upon opening the file browser seems impossible. The button to click to open the file browser is not perceived as a button by the framework and therefore I can't add any additional behaviour when the user clicks on it. It's all managed under the hood outside of my control unfortunately... I really like your reasoning, but I won't get it to work... –  AndroidHustle Aug 14 '12 at 11:20
    
@AndroidHustle: well, I created this fiddle and here it works (Tested in firefox 14 for OS X): jsfiddle.net/hf8Mx . I don't know if Vaadin is opensource so that you could check its internals, at worst case, I'm pretty sure you can assign an HTML ID for that button from the java side, and insert a client side snippet somehow. –  Aadaam Aug 14 '12 at 15:06
    
You're right, it does work. But I'm not able to inject custom JS that freely into the application. It's all handled with Java and the HTML and JavaScript is generated upon compiling the code. I've posted the question on the Vaadin forum also, to be honest it's probably as much a code question as it is a UX one, perhaps even more. I really like your suggestion though, and if I find a way to make it work I'll mark this as correct. –  AndroidHustle Aug 15 '12 at 6:38

If you think it's worth the effort, you can develop a custom file upload dialog. Either a basic one, mimicking the standard dialog, or, since you're already investing the time in it, you could do something smarter, with multiple selection, drag and drop or other supportive features. With drag&drop you don't need to worry about clicks in either case.

EDIT Thanks to Aadaam for pointing it out to me that it can't really be done. But the drag&drop solution holds :). When users click on "upload file", you can open a region encouraging them to drag&drop their files onto it, like many advanced webapps do (gmail and dropbox among others). As backup, you also provide a link to use the standard uploader, which is also common practice in such cases. This won't terminate the problem you're having with the standard uploader, but it will make it much less common, because less users will ever reach the standard uploader. Also, you will have added a useful, usable and cool feature to your product :).

share|improve this answer
1  
Vitaly: this is technologically close to impossible in browser environments for security reasons. If a webapplication had a right to browse the file system programatically, it would be able to do it without telling you as well, which means every webpage could be a virus, a trojan horse or anything else. Worse, even a malicious comment on a poorly-secured webpage could turn an ordinary webpage (like UX.SE) into a virus. –  Aadaam Aug 14 '12 at 16:21
    
@Aadaam Seems like you're right, didn't know that, thanks! See update. –  Vitaly Mijiritsky Aug 14 '12 at 16:41
    
Thanks Vitaly, I like your solution now after the edit. Perhaps I could open a modal window, similar to how Google does, where the user either can browse a file or drop a file. In that way I could let the modal window be focused and lock the background. So maybe that's actually the best way forward for me. I've been having some problems getting the drop component to work though, it delivers the file as an Html5File object and that does not behave the same as a conventional file object you get from browsing. But I'll look deeper into it, thanks. –  AndroidHustle Aug 15 '12 at 6:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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