I'm developing a process with a predefined number of steps to complete so while process is running I can know how far the process has gotten and how much is there still to be done.

My process executes somehow in a tree mode where each branch has the same number of nodes, but not all branches lead to a result. which means that process will be stepping back to a node that has a junction and try other branch.

This means that if my branch length is 100 nodes it may happen that while process gets to node 75 it sees a dead end and revert back to node 50 and continues with a branch from that junction.


Since my process can define the point of its execution I would still rather display progress bar instead just a running indicator or indefinite progress bar that provides absolutely no feedback to the user.

Is a jumping back progress bar wrong and should not be used at all?

Additional data

Each progress step is a day of the whole range. There's a complex calculation being done for each day but the process work so that:

  1. it takes next day (first one in first step)
  2. makes the calculation

    1. when calculation succeedes it marks all junction points.
    2. when calculation fails go back as many days until it finds first junction point and continue from that point on.
  3. go to step 1 until no more days.

From this process you can see that I can only determine the number of days to make the calculation but not the number of junctions because they heavily depend on each day as well as the path taken from previous steps.

That's the reason why I decided to increment progress bar in terms of calculating day X of Y. and when going back to junctions means I can go back a few days before I can start new calculations... Hence a jumping back progress bar.

Possible solution

I could show an indeterminate progress bar (which is probably better than a rotating gauge) with quantitative information of which day (of all) is being currently calculated and how many have been backed up totally until now.

Would this make sense to users? Should I display other numbers?

I suppose that something else beside the indeterminate progress bar is needed, because this kind progress bar is the same as static content. It doesn't change. So it provides no actual feedback to the user that something is going on...

4 Answers 4


There is a principle in cognitive science that we feel a loss of something far more than we would feel a gain of that same thing. So if I give you 10% progress, and then take away 10% progress, from a human perspective I'm more like -20% than where the maths would tell me.

Besides the cognitive science aspect above, you should avoid doing anything that will confuse people. If the bar was at 88% and it is now at 70%, then that just doesn't make sense and adds confusion.

Additionally it means that your 88% wasn't really 88%, which may have an impact on whether they trust other things you say.

There are probably some nodes in the progress that once you aren't ever going to have to roll back from. You could only increment the progress when you get to those nodes. That way you will never need to roll back the progress.

However, do you even need a progress bar? What are you adding to the UX by letting people know how far the progress is? (I often like them because I am a technical numbers person and like data, but that doesn't make it needed). Depending on the application it could add a lot to the UX, but very often the only information that is needed is that something is loading. In that case, you can simply use a loading animation. Something like:

enter image description here

Edit: From what you describe, you have no idea how long something is going to take, so you can't show any % progress. What you could do is show a simple counter every time you process another node so that someone can see that the process is still running and not stuck. They could see it progress from 154 to 155 with something like "155 nodes processed" (assuming that a node processed would mean something to them).

  • Well the tree structure may revert to any node theoretically. In practice this is not true and wont' reverse to every node, but you can't know which one will be reverted back... It's like going from A to B while also visiting C–Z. And you're trying to not use more than 24 hours. Every time you cross time limit, you have to revert to a node where junction was possible. This means that any node can be reverted, and some probably will but you can't know which ones will be... Sep 26, 2011 at 9:37
  • 1
    A progress bar is preferred (without quantitative info), because this is a long running process (may run even for hours), so an indication in terms of a progress bar is much better than a running indicator that may as well be understood as hanged after ie. 30 minutes of processing. Sep 26, 2011 at 9:39
  • @RobertKoritnik: I didn't say that you don't need a progress bar - I even said that it "could add a lot to the ux". I trying to get you to think about whether it is really necessary or not, not trying to get you not to use one. If you are going from A to B while also visiting C-Z, then what information does your progress bar actually give? Does it represent progress?
    – JohnGB
    Sep 26, 2011 at 10:12
  • Yes it does. I does show the progress how much of the whole path has already been calculated (not which nodes but that ie. 50% of them have been successfully covered by the algorithm) Sep 26, 2011 at 11:35
  • 1
    Is it only me who's waiting for the middle of this answer to finish loading?
    – user8626
    Sep 26, 2011 at 15:39

Generally, progress bar jumping back is not a good idea and should be avoided. You better let 100% as all of your nodes at all and jump forward in progress as you skip some steps if you see it's a dead end. This way progress will not be smooth, but users will see some guarantees that something has already been done and will not be calculated again.

The only way when jumping progress is allowable is if your users fully understand computational model and know why it could jump back. But even in this case there should be something that moves forward only, for example another progress that displays amount of attempts already taken, or time spent, if there is no other measure.

  • So what you're saying is that I shouldn't jump back but rather stay on the step when it got jumped back and wait until process gets to the same step and progress from there on... Like a stalling progress bar? So it progresses, waits a bit and progresses further etc.? Sep 26, 2011 at 8:44
  • No, I mean that you should report the data you skipped as a progress too, reporting processed data (calculated or skipped). Sep 26, 2011 at 10:05
  • But the problem is I won't be traversing the whole tree... Process will runs just as long as it finds the first possible complete branch. Everything else will be dismissed afterwards. No optimization of getting the best branch will be performed... It's also true that I don't know how many branches my tree has. Tree processing will reveal junction points on nodes. I can't determine them before processing to calculate the total number of steps my progress bar would be showing. All I know are number of nodes in the whole successful branch from root to final leaf. Sep 26, 2011 at 11:25
  • There's also a possibility of jumping back progress bar while also providing the number of nodes it had to revert due to dead ends. Would that make it better from usability standpoint? Sep 26, 2011 at 11:26
  • Ok so if I use a progress bar for the successful calculation (that has the top value). How should I display a progress bar of something that doesn't have a top limit (the skipped ones)? I can only see this info as a number without any other indicator. Is there a visual construct to show this kind of progression? Sep 26, 2011 at 12:15

This depends a lot on what you're processing and how long it usually takes.

If it takes a short period of time(10-30 seconds or less) you can simply take the expected number of nodes times 2 and increase the progress bar as you normally would. (basically you take the top 50% as 'buffer time'). This does depend on you're usual amount of work and the standard divination.

If it takes a longer time (30 seconds or more) I would go for an increasing counter (scanned X nodes from Y total nodes) and simply finish when ready with a little info label saying that the Y number is the worst case scenario and the work might finish sooner.

If the progress reporter is really important you could use a combination of both showing the amount of progress and the amount of expected work left using some real life tested numbers.

  • Execution of this process is estimated in minutes/hours rather than seconds. Sep 26, 2011 at 11:58
  • You can read some more additional info in my question so it may give you some more ideas of how to usefully solve this. The fact is I can't possibly estimate a number of nodes to finish processing. My worst case scenario is number of permutations on all nodes for each day which is a very big number and progress bar would then increment maybe to a few percent... That's also not useful. Empirical data is missing and I'm not sure whether it can be estimated by it. Sep 26, 2011 at 12:07

While progress bars can be nice visually, in some cases it might be more useful to report two values numerically, with an update speed that allows them to be read easily:

1. Amount of work done.
2. Estimated total amount of work that will be necessary.

If initial estimates of the total amount of work turn out to be inaccurate, the second quantity above may increase or decrease substantially, which would in turn affect any estimate of the fraction of work completed. On the other hand, someone who looks at the screen and sees the numbers would be better able to tell what progress was being made than someone who merely saw a progress bar, especially if the person who had done a process a few times knew that the an initial underestimate would get corrected at a certain point in the process. If the process would seem to be 80% done when the estimated total amount of work jumps fivefold, a simple progress bar would have no way to indicate that work was still being performed at the same continuous rate--only the estimated total amount of work had changed. Looking at numbers, however, someone could notice the change in the estimated amount of work and better understand what was going on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.