[HN Gopher] Rethinking the Progress Bar (2007) [pdf]
___________________________________________________________________
Rethinking the Progress Bar (2007) [pdf]
Author : subsubsub
Score : 30 points
Date : 2021-03-02 07:49 UTC (2 days ago)
(HTM) web link (chrisharrison.net)
(TXT) w3m dump (chrisharrison.net)
| intrepidhero wrote:
| When a program is performing a task that is going to make me wait
| I want lots of communication. Imagine I ordered a sandwich in a
| restaurant and its taking longer than expected. I'm now faced
| with a decision, do I wait or do I leave? I could make a better
| decision about what to do if I could see how many orders are
| ahead of me or if I can watch the kitchen and see a stack of
| ingredients ready to go, but the chef paused to clean off the
| grill. In the case of computer it can be hard to know beforehand
| exactly what its going to do and how long it will take. Maybe
| there is some kind of issue I need to fix before the task will
| ever be complete. As computers and networks evolve and improve
| (or degrade) it can be really hard for the programmer to have a
| good idea of how long a task will take to complete. In light of
| that, I would always err on the side of giving the user _more_
| information about what the program is doing and how long its
| taking.
|
| On a file transfer I'd really like to know, how much has been
| copied, how much is remaining and the current (5 sec average
| maybe) bit rate. That gives me enough information to know whether
| its worth waiting around for it to finish or I should find an
| alternative or the connection has dropped.
|
| Staring at a spinner, with no idea how fast or slow things are
| going is the worst and I'm going to give up a lot sooner than if
| I knew what was happening.
| jxy wrote:
| As computers and networks evolve and improve, a lot more things
| would get involved and it is going to be hard to tell how long
| any operation is going to take. Operating on an assumption of
| always instant feed back does not scale.
|
| Ordering a sandwich in a restaurant apparently becomes less
| normal nowadays. Instead we order it online for delivery. I
| would find it extremely annoying if the delivery service keeps
| sending me messages about his status. If the delivery is going
| to arrive at the time frame I asked for, I don't want any extra
| information from them. While I wait for the sandwich delivery,
| I can order other stuff too. I only want any messages about
| anything I ordered is if the delivery is not going to make it.
| If I received such delivery error, I can submit another order
| from a different delivery service.
|
| Now you can go down a level and consider how the restaurant
| operates in this case. The restaurant receives orders from a
| queue and make those in batches. Whenever the delivery person
| comes, the restaurant hands out packaged orders each with their
| endpoint addresses. The restaurant does not need any extra
| information from you or the delivery person, unless something
| unexpected happens. There is no need for extra communication
| unless there is an interruption.
|
| If you are the restaurant owner, of course you need to manage
| ordering ingredients for the restaurant, and ordering
| sandwiches for yourself. Whatever you need to order, your
| system can be transparent to it. Once you make the decision
| what to order, you can go back to paragraph two above and start
| from there.
| 88840-8855 wrote:
| Results:
|
| Participants tended to prefer (i.e., perceive as faster)
| whichever function they saw first. Of the 990 paired com-
| parisons, the first function was preferred 376 times (38%), the
| second 262 times (26%), with no preference 352 times (36%).
| keithwhor wrote:
| As a summary;
|
| - Participants preferred whatever they saw first
|
| - Otherwise, accelerating or rapidly accelerating progress bars
| were generally preferred
|
| If you're designing progress bars with an unknown time to
| completion, my recommendation is to use an accelerating function
| for the first 95% over the predicted median time to completion.
| Then linear timing function for the next 4% and set the time to
| 3x the median time to completion. Automatically fill the bar when
| progress completes, no matter what.
|
| e.g. if an action takes a median time of 4s to complete;
| f(0 <= t < 4) = 0.95 * ((t / 4) ^ 2) f(4 <= t <= 16) =
| 0.95 + (0.04 * ((t - 4) / 12)) f(t > 16) = 0.99
|
| You can adjust this however you see fit but I find it gives a
| pleasant experience.
| toomim wrote:
| These researchers presume that their goal is to make users think
| that an operation is happening quickly, even if it is slow.
|
| I thought the goal of a progress bar was to report reality, not
| manipulate users into thinking that your slow code is faster than
| it actually is.
|
| Since when have dark patterns infiltrated academic HCI?
| marcosdumay wrote:
| Progres bars have several goals, but making yours users happy
| secure that they know how long they'll spend and not feeling
| like they waited too long is certainly one of them.
|
| Why do you classify that as a dark pattern? It's not harming
| people in any way, but the opposite.
| reaperducer wrote:
| _Why do you classify that as a dark pattern? It 's not
| harming people in any way, but the opposite._
|
| It's lying. Lying is inherently harmful. Just because a
| computer is doing it doesn't make it unethical. Especially
| since people trust computers to be precise and correct.
| [deleted]
| marcosdumay wrote:
| It's only lying if your users are completely rational
| aliens that have linear perception of the passage of time.
|
| By the way, people do really not expect progress bars to be
| correct. They may with they were, but not expect.
| nullserver wrote:
| Back in 90s the progress bar was so bad it was more
| entertainment.
|
| 5 minutes left, 4 minutes, 23 days, 1 minute, 4000 years
| left.
|
| The last 1% Taking longer the first 99%
|
| If you installed the same software repeatedly get an idea
| of how long each section of the bar would take.
|
| Windows 3.1 I'm looking at you.
| cldellow wrote:
| Yeah, this used to be a real pain point.
|
| Page 311 of the .NET Framework Design Guidelines has this
| quote from Chris Sells (then a program manager for .NET,
| I think):
|
| > Please make progress reporting move forward, if for no
| other reason than my family makes fun of me when they see
| a progress report going backwards, as if it's my fault.
| Personally, I've implemented several progress percentage
| algorithms and while I often can't get the timing to be
| smooth through all stages of an operation, at least they
| always move forward. In fact, I think you'd have to work
| extra hard to make them move backwards.
| nullserver wrote:
| Oh I had forgotten about the going backwards ones! It was
| like the machine was personally taunting you.
| marcosdumay wrote:
| I've seen that on the Windows 10 file copy dialog just
| yesterday... but yeah, they existed back in the 90's too.
| [deleted]
| toomim wrote:
| > It's not harming people in any way, but the opposite.
|
| Please explain how lying to your users is good for them.
| madsbuch wrote:
| 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.
| reaperducer wrote:
| 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 wrote:
| 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.
| masswerk wrote:
| 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.)
| elcomet wrote:
| 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.
| Fargren wrote:
| 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.
| atoav wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There are browser APIs, as well. However, network
| performance may vary. Personally, I would add textual
| information, like an estimate of the time required.
| atoav wrote:
| 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 wrote:
| 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 wrote:
| 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?
| WorldMaker wrote:
| 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.)
| WorldMaker wrote:
| My understanding (and I believe studies back this up) is that
| primary goal of a progress bar is to assure the user, in
| priority order: 1) the app has not crashed, 2) the app is busy
| doing something, 3) the app is busy doing something relevant to
| the user.
|
| As a software developers things like % complete and estimated
| finish time are general far more useful (for debugging things
| like "what stage is taking too long", for instance), but those
| specific details are rather further down the list of priorities
| for most average users.
| kebman wrote:
| The best progress bars I see, are double ones, where there's one
| general bar, and one with a thinner bar for each item. That way I
| always know that there's progress. Perhas even some info text
| would be nice too, like it is in most games, for when the
| progress requires some CPU time.
| jayd16 wrote:
| I'm still waiting for a neural net progress bar as a service that
| pipes in all available device data, measurable progress and a
| task id and spits out a prediction based on previous runs across
| _all_ previous tasks.
|
| Should eventually figure out what tasks are IO bound, what are
| CPU bound, what are fixed time, etc. as well as what device
| configurations effect that. Could also predict a service is down
| given enough scale...
| ravi-delia wrote:
| It's a somewhat silly idea, but actually what would really make
| it shine would be if the OS provided an api. You could give it
| some identification, and maybe a listing of tasks. That way it
| could pool learning data from all programs.
| jayd16 wrote:
| Yep, very silly...and yet...
|
| If it wasn't clear, I completely agree that the data should
| be aggregated across all apps, all tasks.
| tshaddox wrote:
| How would that work exactly? Do you mean that you'd ship the
| monitoring code to all users in production, and it would
| monitor losing times, system attributes, etc. and phone home to
| your servers, where you'd use that to train a NN and ship that
| model back to all users?
| jayd16 wrote:
| The NN part is a bit tongue in cheek but yep, you got it. You
| could also just poll the cloud model without having to
| actually run it locally.
| nahuel0x wrote:
| Inside this concept there is a Douglas Adams like short-history
| about a self-conscious progress bar.
| [deleted]
| snapcaster wrote:
| Cool to see article by someone I know on here! Really liked this
| paper, something else I find tricky about them is how hard it
| often is to accurately measure/report/track progress when writing
| software. In my experience a lot of these bad behaviors in
| progress bars come from programmers not having good way to
| actually track the real progress and instead just have to
| aggregate or estimate progress from each "stage" or "step" or
| whatever your software abstraction for a unit or work ends up
| being
| thehappypm wrote:
| Good to see Chris Harrison doing good work after being fired from
| hosting the Bachelor.
| subsubsub wrote:
| Also:
| https://chrisharrison.net/projects/progressbars2/ProgressBar...
| randomstring wrote:
| I had a friend who implemented what he referred to as Zeno's
| Progress Bar. After every unit of time passed, the progress bar
| would progress half the distance to completion. So 0 -> 50% ->
| 75% -> 87.5% and when the task finished it would jump to 100%. It
| didn't bother to measure the actual progress at all. Key factor
| was making users think something was happening and not give up
| before it was done. In hindsight, it leverages the human's
| susceptibility to the sunk time fallacy.
|
| They may not have been the first to invent the idea or implement
| it. I found this description of the same idea here:
| https://cerealnumber.livejournal.com/27537.html
|
| and an online implementation and demo here: https://jan-
| martinek.com/etc/zeno/
| ancarda wrote:
| Watching that progress bar was physically painful. I'd rather
| not use software that lies to me.
| WorldMaker wrote:
| I've used NProgress for years in JS apps and it defaults to a
| similar progress (though it uses a smoother "ease-out" curve
| than pure "Zeno").
|
| Though one interesting thing to note is that both of these
| curves violate one of the findings in this article that users
| seem to prefer the bar to move slower at the beginning than the
| end and what you like want is more of an "ease-in" curve.
| luhn wrote:
| I'm pretty sure Github does this when navigating from page to
| page. Makes sense--The browser has no way of knowing the
| progress of the HTTP request.
|
| It seems to me that most progress bars are lies.
| umvi wrote:
| Someone should make a JSFiddle that demos these different
| progress bar mathematical functions so you can visually compare
| them side-by-side.
|
| Also relevant: Tom Scott's recent video[0]
|
| [0] https://www.youtube.com/watch?v=iZnLZFRylbs
___________________________________________________________________
(page generated 2021-03-04 23:01 UTC)