[madsbuch]

Its a bit harder than that, I'd say. Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed.

I am having that exact problem in an application I am developing.

[thaumasiotes]

> Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed.

Display a progress bar for downloading, and then another one for processing. You can caption them, too.

[masswerk]

Downloading is an async operation of unknown duration, which is best represented by a spinner. Processing, on the other hand, should be deterministic. I'd say, have a spinner and a progress bar (dimmed, while the spinner is active, then switch to a dimmed, but filled spinner and an active progress bar.)

[atoav]

Imagine a train network operator who says: we cannot say how long a trip will take with 100% accuracy, therefore we are not going to tell you at all. And evwn more evil: on the trains they blind the windows and rob you of every clue that would tell you where you are and how fast you are going.

This would be pretty uncomfortable.

What train riders (and users) are interested in is how long a thing should take in principle as well as clues about whether they are on track. When reality differs from that it is ok, as long as the ETA is somewhat in the ballpark area of the actual time of arrival.

[masswerk]

On the other hand, time tables should provide actual data in linear time (not some "apparent time" – "You'll arrive in 'just fine' at your destination."). I don't know the extent of the download, but, if not not substantial, it should just add a small offset prior to the main operation. Otherwise, if you're downloading a huge database, you can draw estimates from progress and display a sub-progress of this first task. (There are APIs for this).

In the now gone days of usability, it was considered good practice to annotate the progress bar of a complex task by displaying textual information regarding the sub-task and the progress made. This could be considered here as well. (E.g., "Loading data, estimate: 3.4 secs.")

[ancarda]

Why use a spinner for downloading? Don't you know how many bytes you need to fetch and how many you have received so far?

wget has a progress bar, and it works perfectly fine.

EDIT: Though, if the server does not have a Content-Length header, you will get an indeterminate progress bar (a kind of spinner, I suppose) in web browsers, if that's the kind of thing you mean?

[_jal]

Downloads can occupy some fuzzy middle ground between unknown and deterministic.

The normal case is that bandwidth throughput can be estimated well enough to make humans happy. But a broken network throws that out the window and will do its best to find ways to make your progress bar behave weirdly.

I can't remember what it was, but there was a Mac app a very long time ago (System 7 era, in the 90s) - maybe a news reader? - that would eventually hide the progress bar and show a message about bad networking when that happened.

[masswerk]

There are browser APIs, as well. However, network performance may vary. Personally, I would add textual information, like an estimate of the time required.

[Fargren]

I'm pretty sure in most systems I use, processing time is not deterministic and it depends on what else the system is doing at the time and it's temperature, among other factor of which the progress bar won't be aware.

A progress bar will usually present the "expected" duration of several operations, [almost] none of which have a deterministic duration, or a deterministic ratio from one to the other. The best we can do is put heuristics in place to estimate how long the operations will take. We have some choices, such as estimating the total time or estimating each sub-operation separately. We can even use AI for the estimation, if we want to get fancy. But the problem is not tractable, and we'd rather given estimates where we can that just use spinners everywhere.

[elcomet]

And yet users prefer progress bars. You know the average duration of a data transfer and can show a progress bar even if it's not very accurate.

[reaperducer]

Wasn't this solved back in the days of floppy disk OS installation?

You have one progress bar showing progress for this floppy, and another showing progress for the entire operation.

[madsbuch]

That is indeed a solution :)

I was merely constructing a case for using fancy progress bar calculations. And conflating two non related operations into one might be one of those.

[WorldMaker]

I had great results using a circular progress bar instead of a linear one. If you allow the tail to "catch up" towards the head, but the head always moving forward (rotating clockwise) you can allow the progress bar to shrink without losing the illusion of forward progress. In the worst case where lots new tasks/sub-tasks are discovered on the fly, it acts directly as its own "spinner".

It's probably easier to visualize than describe, but I have longer descriptions on the thinking behind it on my blog/GitHub repo. Unfortunately, my demo site succumbed to JS CDN bit rot and I keep forgetting to update the demo to something more recent.

(ETA: Forgot the link: https://github.com/WorldMaker/compradprog Also thought I could point out that the idea mostly jives with the findings in the paper here.)

[atoav]

This is hard because predicting a duration for each process is hard. For some processes getting feedback that granular might be hard (for a download this is more or less easy, you get the moving window average downloadspeed and the total filesize and use simple arithmetic to get the duration). For other things this can be hard, e.g. if the peocess you use doesn't offer that kind of granular metrics.

[madsbuch]

Download speed is not too important when showing a progress bar (unless one wants to do somethings fancy). If you know total content length and how much you have downloaded you just calculate the fraction and update the progress bar according a couple of times a second.

[cjaybo]

That's fine if the progress bar is only indicating the progress of the download. As mentioned elsewhere in this thread, if the download operation is only one part of the overall process, things get quite a bit trickier -- what percentage of the overall progress do you assign to the download operation when external factors like network speed and system load come into play?