Progress bar completing too quickly

Question

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:

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?

Answer 1

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:

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.

Answer 2

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.

Answer 3

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".

Answer 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.

Answer 5

#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.

Answer 6

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.