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 ...
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!
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 his/her time....
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.
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 ...
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.
Are you performing a depth first traversal?
When processing a node do you know how many children it has?
If so then one approach is, for any given node assign equal weight to each of the children.
When examining the starting node we find it has two children:
100 / 2 = 50 so each of these is assigned 50% of the progress bar.
When examining ...
Here you have 3 options.
In the first sample, you have 2 states with "voids" that are filled as the tasks are completed
The second sample is useful if your tasks are numbered in an amount sequence (x amount of tasks completed) and the order doesn't matter
Finally, the easiest and most clear option: a big number with progress status. Straight and to the ...
"Scroll Spy" generally refers to a top or side navigation that dynamically changes as the user scrolls down the page.
I think scroll spy is specific to dynamic navigation, but maybe something like "Scrolling Progress Bar" is fine.
Here is a fiddle that may give you some more insight with JS and CSS.
Your graphic seems to require far too much information to describe what it means. Github does this through a table of Longest Streak next to Current Streak. It is easier to understand with just text.
To keep it compact you could remove everything but the most important information:
download bmml source – Wireframes created with Balsamiq Mockups
Going off Simon Richter's answer and O. R. Mapper's comment, what about something that looks sort of tab-like to help indicate it's clickable, but has an arrow shape communicating the flow of the wizard steps?
Rough ugly example:
Deutsche Bahn are using a tabbed interface, adding tabs as the user progresses along the wizard, and with green lines indicating that the respective pages contain valid data. The user can go back by selecting an old tab.
(German) report with pictures.
My honest opinion is that the time spent / total time label is enough, and that also adding the percentage is redundant information.
So why do I think that, especially considering Khan Academy has both a Done / Total label + a percentage label? The answer is in what differentiates your two scenarios. In your design you have a progress bar which doesn't ...
Using a progress bar to show the completion of steps is utterly wrong, IMO.
I use progress bars strictly for those task that,
I can predict the time/size of the task, in one single unit (e.g. seconds/megabytes).
I can divide the task to progressive units, and all units have equal weight.
I can calculate how much of progressive units has been completed.
Bend that bar into a circle!
A donut chart is perfect for 'percent of total' visualizations. And using color to indicate account "health" adds another layer for the visual thinker. It makes for a fairly compact presentation that delivers the all the critical data.
For smaller spaces, I would limit the displayed data to balance only and tap/click to ...
showing what the program is doing while working on a progress bar gives an additional indication of progress. There is also a nice way of doing this involving a details screen:
This method doesn't just show the progress of the installation as a whole, it also shows what the current step is, what the previous steps is and sometimes even the progress of the ...
How about making the length of the status bar grow as well? That way, progress goes up even when percent done goes down.
[###-------] |30%| 3/10
[####----------------] |20%| 4/20
[#####---------------------] |19%| 5/26
It's easier to think about it as two status bars: "work completed" overlaying "total work." The ...
I was thinking in a similar line as @Yako:
Do not slow down any tasks, but think on what gives a nice user experience separately.
Don't slow down the task, slow down the bar
Just let your tasks run, and measure their progress, but rather than displaying the updated progress immediately, do something more smooth. For example: define a maximum ...
My recommendations are mostly based on the book Designing and Engineering Time by S.Seow:
Use non-temporal units for progress indicator, e.g. number of paths, etc. At least, it adds meaningful indicator and shows responsiveness of the long process.
Inform user on lower time bound, e.g. "This takes at least 20 min". This allow user to decide if the process ...
I think it's your markers that are causing confusion, I believe something like this would make it easier to read.
The colours are from Lucid Chart Android elements, there's no reason not to change them to your design guidelines or for something more pleasing.
You could also stick a label under the gray area with "Available to spend: 5800"
Example of above:...