38

I have a progress bar that takes place after a user uploads a file while the backend is running some processes. It looks like a standard progress bar that fills as the processing completes, like so: enter image description here

When the upload/processing is complete the bar is replaced with a text that says "Upload Complete".

If the file is larger it takes upwards of a few seconds to complete and provides a nice visual progression to let the user know nothing is frozen. The problem is if the user inputs a small file the processing time is quite low, this results in the user clicking "Upload", a progress bar flashing up and shifting some elements down then disappearing to be replaced with the success text all in fractions of a second.

I see a couple ways to combat this but I do not know which would provide the best UX.

1. Do nothing

One course of action, and surely the simplest from the development side would be to do nothing. Let the bar flash up and disappear in the whatever time it takes. If this happens too quickly it may be confusing or even disorienting to the user but it follows the natural progression the user would expect.

2. Add a small delay

Intuitively one would think purposefully adding any extra time to an application is a UX sin. But this article on adding delays to increase perceived value shows how Blogger added a small loading .gif that increased user satisfaction and reduced fear that something went wrong, which would be a real concern with my flashing loading bar.

3. Hide loading bar for small files

One course of action would be to determine which files will cause too short of a loading time and simply not display the bar in the first place. Users that upload large files will receive the same loading progression then completion status as before but users that choose small files will hit upload and momentarily see "Upload Complete". The problem I see with this is users who are familiar with seeing the progress bar may be throw off, I've been trained consistency is key but this would involve different UX experiences for different users. Plus, if I were to take this route how would I choose this threshold to display or hide the bar. Some users may take 3 seconds to fully perceive the bar being shown while some may only need 1 second.

4. Leave the bar up after 100% completion

Inversely to option #3 I could just leave the bar up reading 100% with the completion status "Upload Complete" under or beside the bar. This would eliminate the progress bar flashing up and disappearing immediately. However, on an already cramped mobile display showing a finished progress bar takes up precious real estate and isn't exactly the most appealing visual element. I could make it disappear after a set interval but that removes some locus of control and could still cause user confusion. It also brings back the threshold issue of #3 where I am unsure of how long to let the bar remain there, too quickly and it defeats the purpose, too long and it may be expected to be persistent and cause confusion when it is removed. I could make the user dismiss it themselves but that adds extra clicks to the process.

So I ask? What provides the most friendly UX for handling loading times that vary?

  • 1
    #3 is fine. Make the threshold ~1 second. – Lightness Races with Monica Jul 27 '15 at 23:10
  • 26
    Oh how do I want to punch everyone into the face that makes me wait a bit longer. I had once an upload application that had a ~1.5s "upload finished" animation per file, and then I selected hundreds of small files that all were transferred in fractions a second, and then waited in anger for all the animations to finish. – PlasmaHH Jul 28 '15 at 8:27
  • 4
    @LightnessRacesinOrbit: Wouldn't the primary issue with this be that you do not know how long it will take (and you can only guess based on what you consider a small enough file size, even though the user's network connection might have a slightly different opinion on the matter)? – O. R. Mapper Jul 29 '15 at 12:44
  • 2
    for starters, make sure your progress bar does not push you other elements around. If real estate is an issue, you can use a different progress bar. can be a simple line, or a morph of the button. something like github.com/dmytrodanylyk/circular-progress-button – njzk2 Jul 29 '15 at 12:45
  • 1
    "The progress bar is moving but the remaining time is going up!"Matrix Runs on Windows XP – Mazura Jul 30 '15 at 4:21
104

Here's another alternative: You mentioned you don't find the progress bar the most appealing, and it's taking up precious real estate. Would you consider a more compact preloader and success message that do not impact layout? Just as an example:

enter image description here

I don't know if that particular example would fit your situation. But if you can achieve a more compact design, you could leave up the success message (the check) after it's done loading without taking up a lot of space.

If something like this were used, there should be no issue with adding a small delay and forcing the animation to run (as per your idea #2). If the preloader does not impact layout, and if the user can continue doing whatever he's doing while the animation runs, it's not really delaying the user and shouldn't hurt user experience.

  • This will actually work perfect! Nice and compact, informative, and handles the small file problem well. – DasBeasto Jul 28 '15 at 0:05
11

Progress indicators are generally implemented to reduce the user's perception of system latency. It's this need to eliminate the perception of system latency that gives progress indicators value. Conversely, if there isn't any lag at all between a user action (clicking 'Upload' in your example) and the system response (uploading of the file), displaying a progress bar actually works against this need (flickering/vanishing UI elements may indicate an error in the process/system).

What you as the designer must determine is whether or not displaying a progress indicator strengthens the user experience. If it's important to the user to 'see' the upload happen (via the progress indicator), adding a minimum load time for the indicator to display (only as long as necessary) makes sense. Otherwise, displaying an 'upload successful' message is sufficient for rapid processing times. For processes longer than a few milliseconds your current progress indicator/message should be good.

Without knowing your users and the context of the process, I would venture to guess option #3 is likely the best option, based on your description. If the upload process happens too fast for users to perceive visual indication of its progress, simply letting them know the success or failure of the upload should be sufficient. As always, know your users.

FYI, Microsoft recommends displaying progress indicator if a process takes longer than one second.

  • 11
    I'm not sure taking UX advice from Microsoft is advisable – Lightness Races with Monica Jul 27 '15 at 23:11
  • 1
    In a course with UX author Bruce Tognazzini he presented a hierarchy of loading indicators, e.g., less than half a second do nothing, half to a few seconds can be a spinner, more than a few seconds a progress bar, even longer something more informative/entertaining. If it's a JavaScript/web application at least it's pretty simple to have a progress animation appear after a 500ms timeout if the process hasn't completed sooner. – Marc Stober Jul 29 '15 at 12:56
5

One potential option is not to explicitly hide the progress bar for small files (how do you know what "small" is for a given network?) but to delay showing it for a small period of time. If the upload completes in this period, you can show the "Upload complete" message, but if the upload takes more than the delay, then you show the progress bar.

The Psion 3/5 handhelds used a similar technique for the built-in "Busy" messages of their OPL programming language: you could enable a busy message, but it would only be shown if not disabled within a given time-delay.

The delay was usually relatively small: a half second being typical.

There's still a chance that the upload will take fractionally longer than the delay, resulting in a brief flash of progress bar, but I suspect that in many cases, most files will be "very short" or "a [few] second[s] or more".

  • Midnight Commander does something like that too. – Bodo Thiesen Jul 30 '15 at 10:55
  • You could also delay showing the progress bar and if the processing is more than 50% done within the first half second, not showing the progress bar even though the time for showing it has already reached. (like nwp suggested in his answer already) – Bodo Thiesen Jul 30 '15 at 10:57
4

I would make the progress bar appear after some time if the process has not finished by then. That way fast uploads never get screen flickering or progress bars and you still have the progress bar for slow uploads.

The time that still feels "instant" is around 200-400ms. I would not show the progress bar for 200ms. If the process is then less than 50% done I show the progress bar. The user perceives this as the progress bar popping up "instantly". That way uploads either finish "instantly" or "instantly" get a progress bar with somewhat significant screen time.

  • 1
    What if you decide to show bar after - say - 200 ms and the process took 201 ms? You return to the same problem. – Voitcus Jul 29 '15 at 19:56
  • @Voitcus If the process takes 201ms it is not done less than 50% after 200ms, so no progress bar will be shown. The minimum time a progress bar is visible is 200ms when the process takes 400ms, assuming the speed does not vary. That case would need to be handled separately or ignored. – nwp Jul 29 '15 at 21:13
  • Ok, now I get it – Voitcus Jul 29 '15 at 21:19
3

#3 (not showing the progress bar for small files) seems bad to me. First, even a small file can take a long time to upload if there are network problems. Second, your idea of a file that's small enough to upload quickly on your whizzy broadband connection might not be the same as that of somebody in a third-world country using a very slow link. Third, if you were able to reliably predict how fast files would upload, you'd just quote that estimate, instead of using a progress bar.

  • 1
    Relativity is important here, so I have to agree. We take for granted the technological advances one location over another and it's hard to find a safe cutoff when it comes to time/size. – Xrylite Jul 28 '15 at 18:14
0

The only good option that works is “4. Leave the bar up after 100% completion”.

You do not know how long the upload will take and the internet speed is changing all the time. So if you say delay putting the bar up for 2 seconds, what if the upload then completes in the next half second?

Updating the bar must be flicker free and not done too often, say no more than ever half second.

Personally I would move the “62%” into the end of the bar or remove it altogether, then write “Upload Completed” onto the bar once it is done. So that once the upload is done, there is a green background with the words “Upload Completed” overlaid on it.

(Updating the xx% text will flicker as the same pixel is being swaped from wight to black then to wight. Fill the bar just changes each pixel from weight to block.)

Making your bar into a "pie charge" as done so nicely by Nick Todd is a way to take up less space while leaving the bar showing after the file has completed.

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.