This took forever to make using Image Ready. lol
When the spiral is going against the bar direction, it does visually exagerate the speed of the bar movement.
The bars are pretty close to each other, so hide one with your palm and look only one at time. :)
Studies have shown it looks faster and in UX perception is everything ;)
A study (PDF) demonstrates that animations can increase the perceived speed of a download by up to 11% over a bar that is not animated. Having a reverse-animated background as in the Gmail loading bar, or having the background pulse faster as the bar nears completion, both create ...
Jakob Nielsen wrote an article called Response times - 3 important limits.
The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]. He wrote this in 1993:
0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is ...
Root Level Progression
I think a better approach if your sub tasks are completing very quickly would be moving the progress bar to the root elements.
Or outside of the table completely (if it's an option)
which also gives you the ability to use different icons if a sub task fails etc.
Imagine you and I are talking to each other in the street. You've asked me if I have the time and with barely any hesitation I look at my watch and tell you. You don't give it a second thought. You then ask my if I can tell you directions to a decent coffee shop. Some options may occur:
I instantly start reeling off a set of instructions
I appear to be ...
Because most people living in the western world read from left to right, and that's how they imagine how time passes.
It's a good question wether top to bottom would benefit Japanese customers or right-to-left certain Arabic cultures, on the other hand, the cultural influences of western media and western software does change that.
It can be easily ...
If it is possible to traverse the entire tree before beginning processing, I would display an indeterminate progress bar while you discover the branches and then switch to a traditional progress bar once you know the maximum value.
If you cannot identify the total size of the tree before processing, then a progress bar may not be the best option. A ...
Showing details in a form not only developers understand is fine. If you are able to write your installation details in a more funny way than just "Checking Operating System Version" this might have two advantages:
The user gets feedback about what's going on and that there's something going on at all. When installing e.g. a computer game you normally have ...
Note: when this answer was written, the question talked about a "progress bar". The question was later changed to mean "wizard". I am leaving this answer as is because it is still being voted up regularly; thus, it seems to kind of be a somewhat fitting answer for a "wizard"-style form as well.
With all the examples in the question and the answers so ...
Remember 0.1, 1.0, and 10 seconds...
You have about 1 second to show something whether that be the finished result or an indicator that the computer is working (usually some type of spinner)
Not doing anything for 1 whole second after a user initiates an action can still make an application feel sluggish (as noted in the comments below) so I like to ...
TLDR: Never, unless you are not making any progress (losing progress)
A progress-bar in UX has one simple feature, show progress to a user. Progress is a forward motion/movement. This is I especially true from a psychological point of view.
From the Cambridge dictionary:
Progress - movement to an improved or more developed state, or to a forward ...
I would hide the progress bar once a task is completed.
Progress bars communicate to the user that something may take awhile so maybe you could hide the progress bar at 100% and even change the word to DONE.
If all the tasks start out as DONE then awesome I have to tell all my friends how fast you are!
One very possible reason for this is adaption and matching with the context in which the progress indicator is shown.
Think about it, a progress indicator is usually displayed together with a descriptive text that explains what it is that is being processed.
And what do we know about text.. well, for one thing it's written horizontally from left to right (...
The main advantage of visualization is you are just showing the data and nothing else. Adding negative space just to show the ceiling sounds like Chartjunk.
If you just want to show the maximum limit, show a thin line and write what it represents.
download bmml source – Wireframes created with Balsamiq Mockups
This is quite similar to what stack ...
If you are displaying a percentage, it's best to label it as a percentage. The % doesn't have to be the same size or as dark even as the main number, but is gives a lot more clarity at a low cost. In fact, any number without units is meaningless unless it actually has no units.
This is an assumption, but it's likely because it makes the progress bar appear to fill more rapidly.
This effect is achieved because the right edge of the bar, the consequential part, is moving in the opposite direction from the animation, thereby making the increments that bar edge moves appear larger than they do relative to the box containing the ...
Scott Klemmer's rule of thumb is:
Answer shorter than a second: No feedback
Answer between 1 and 5 seconds: BusySpinner
Answer longer than 5 seconds: Progress bar
10 seconds is a long time. You should bring feedback to the user before he/she naturally loses interest in what your software is doing and become frustrated that your software wasted ...
Yes, always show your units. As my maths teacher used to say:
The problem is that people are used to seeing the percentage symbol with percentages. Therefore, it is in fact conspicuous by it's absence. That makes people think and the point is to make a UI where people don't have to think - at least not where they really don't need ...
I believe you need to rely on icons in this case.
The pencil is associated with the edit action, which if I understood correctly is the reason why the step is clickable, while a check icon implies the step is completed and there is no possible edit:
The idea behind is that steps which have already been filled don't need a number anymore and they are either ...
It can be useful for several reasons. One is that the user gets a feeling of that something is actually happening and not just a progress bar increasing. If the UI says "Checking OS Version" or "Initiating virtual processor" she gets a feeling that something good happens, even if she doesn't know the technicalities behind it.
Second, if the process would ...
As an analogy, consider the mirrors universally installed in elevators. While these mirrors give the user a false sense of added space in the lift, they also serve as just mirrors; people tend to look at themselves and do not seem to notice how long the lift is taking to take them wherever they are going. But if they put in a countdown telling people 'xx ...
A lot has been discussed here already, and I think we can take an advantage of user's Mental Model by using border-bottom which will indicate that the step in wizard is clickable.
I've never used this in my work, but it would be a great option for research.
There could be a hardware related answer too. Before the GUI there was the DOS prompt/terminal interface. Progress bars here would have been rendered with characters, e.g. dots or filled squares. When coding it's far easier to show progress as growing from the left of the screen to the right because you can calculate the place the next character goes quite ...
As you've pointed out, forcing speed and progress into one fixed-length bar -- per the Microsoft example -- reveals the inherently non-linear relationship between time and progress :)
But more importantly for your project: make sure you understand your user and determine your motivation before jumping in. What is the purpose of your progress bar in this ...
Displaying multiple progress bars is not a new concept. Your case is an ideal scenario in which usage is justified. One progress bar represents the overall progress and the other represents the current task's progress.
If you want to use just one bar, then it makes sense to show just the overall progress rather than showing the current task's progress.
Real good discussion happening here. Some thoughts and ideas below.
Consider the design attached and multiple scenarios mentioned:
1) Introducing a status message that suggests that the data is saved and also that the section can be re-visited might help.
2) It could act as a confidence measure and an information item, that could help users understand ...
It can work well, but I wouldn't recommend the method that you are proposing.
You can use breadcrumbs as a form of progress bar, which not only solves your navigation issue, but shows what still has to happen better than a pure progress bar. It is also common practice on some of the most used websites, so your users are likely to already be used to it.
A decent heuristic would be whether the negative space has meaning. If the bar represents something like speed or a metric of productivity, the blue part in your graph doesn't have an important meaning. In that case the bars are best left by themselves against the regular backgound. Just make sure that the user can distinguish between the value 0, and a ...
No, don't slow down the job.
There's nothing wrong with having something be instantly 100% done. Your app will actually seem better than if you slow things down so that the progress bar animation is visible.
Users would love nothing more than to have everything happen instantly.