Depends on the context, but I would go a step further to say a 15 minute operation should run asynchronously (disappear into the background and let you get on with something else). Then you only need to give progress if the user actively wants to find out how soon it is to being done, and you can send notifications. You can see many examples of this pattern, ...
Increase the contrast so users can see the values at a glance. The progress bar can visually support the number without taking up additional visual space.
By trying to keep the number in the bar, users are potentially getting information less quickly, which goes against what a dashboard seeks to achieve: Insight of status at a glance.
You can get more ...
If users really want (and need) the loading details of child elements, show them when they ask for it.
If users aren't getting value out of more data in the majority of use cases, why not give them details on demand.
If there's no debugging needed to be done (which would be the case if a child component fails), let them click for more if they ask for it.
It's been a long time since I've installed a program with this type of interface! From memory:
the leftmost vertical bar was the progress of the current directory being written to
Small directories would be written faster than large directories so they would appear to flash between full and empty, while larger directories would grow from bottom to top from ...
If it is close to 10secs or above then yes an indication of what is being loaded and how much is the progress should be added (source)
Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation.
Nowadays a spinning circle is a good enough indicator of loading.
However it might be a good idea to preload some data for the map, rather than leaving it an empty rectangle. This way people can also see what is loading.
Is there a case where users need to know exactly the percentage for what's being loaded? I'd show just one progress bar indicator for the overall loading process and you could have a list of what's currently being loaded.
Child 1, Child 2
[======================42%-------------------------] 1 MINUTE LEFT
I'd suggest using a circular progress bar with the number / percentage written inside of it, this way you are giving your users a more accurate information, meanwhile also making sure it's still quick to scan. Something like this:
I find the percentage very confusing. It is the percentage of the pieces processed in each delivery state. It might not be clear to the user what these percentages actually mean (well, I don't know your user and there actual needs).
A progress bar always shows a percentage of something. Which means, that the users will have this information in a visual way ...
OP could have added a picture to illustrate the context of use of progress bar. In this answer, I will assume it's the kind that indicates which checkout step the user is at, and each checkout step is on a different page instead of the same page.
Progress bars are good for breaking down a long, complex form into shorter, digestible sections. E.g. a ...
Google analytics has embedded bar charts (not progress bars), which you can right click on to explore further.
In the Analysis (Beta) views, you'll see embedded data graphics:
And here it is in action, when you hover and select:
According to Progress Indicators Make a Slow System Less Insufferable by Nielson Norman Group:
One issue for designers and developers using percent-done animation is the difficulty in calculating how long the process is going to take. Here are a few ways to handle this:
Start the progressive animation slower and allow it to move faster as it ...
In today's reality, many processes are limited to the minimum amount of interaction.
The progress bar function is to show progress or signal at what stage the task is being performed.
If the task is short or easy, it isn't required to create something that indicates its state.
If you consider Shopping-cart as first step of process - I think it's ...
There are a number of general principles that support the use of a progress tracker:
1- Visibility of system status - One of the 10 usability heuristics of Don Norman.
By using a progress tracker, you inform the user on the number of steps in a complex process and where they're up to.
2- Completion or closure principle in psychology: simply getting that ...
I'm unable to share the research but in my testing the wizards I've created or had to support if the steps are less than 6, and the form complexity less than say 5 fields each generally the experience was helpful. Especially if the task is a communicative one where the user has to share where he's at with his co-workers/managers. There is a cliff you will ...
What you described looks like a nested tree structure that you can probably display using a similar strategy to file explorers where you expand and collapse nodes to show or hide more details.
In this case, your nodes are not individual entities/items but progress indicators, which the node representing the overall progress of the individual child elements....
I've notices that progress bars on some applications load slightly quicker at the start than at the end.
Progress bars may appear to move more quickly at the beginning because a move from 1% to 2% represents double the amount of work completed, whereas, a move from 70% to 71% only represents a 1.4% change in the amount of work completed.
There may also be ...
I agree with Mike's answer except that the title of the progress bar could actually be done so that it's on the same row as the percentage value, i.e.
This way you make the design even more compact and I think that was your main goal.
Then, where should you put the percentage value? I think putting it at the end (like in the first and third row of above ...
Always show a number to the full meter, that's when the user needs to know what the number is, since it sets the scale for the meter. Once they start actually moving, what the full number was becomes less important. They've already spent some of it, so their current available number is no longer that (and they probably do remember what they started with). ...
Using a single progress bar is great. In too many case, using a main progress bar plus sub-progress bars is overkill and does not help.
Users generally expect progress bars to advance linear with time. This is hard to implement.
For 1) I recommend not displaying percentage, since the user does not know whether that's time percentage or file size percentage....
Beside making it look like the bar progresses faster, I think the main reason is so the user can tell the page/application is still working. The moving bar basically tells the user that the application is working in the background and not stuck.
If a progress bar is not animated and hasn't moved in some time, the user might thing the application is "not ...