Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progress bars still lie

web.eecs.utk.edu

Post reply on HN
Print view View original

51–60 of 232 posts

Re: Progress bars still lie

#51

Post by munro »

pmoriarty wrote: post #6

Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…

I wrote a progress bar for an app where it wait time ranges from 5 to 20 seconds, 20-80th percentile for each different function had a range of like 8 seconds--it doing fancy stuff with Selenium. :)

I mocked it up in Figma, I didn't display any numbers, only a cute lil line. Then built it with React Native, super easy and quick, it looked & felt great to me.

So for the actual estimate, what I did was store how long it took to run the task for my users, and then select the 95th percentile from actual runs to get an estimate. Then when they loaded the app, I would send over the estimates (along with their account info and what not). I figured if it ended sooner than what it was projecting, the user would be happy, or at least I was.

I used my own app, and kept tweaking it until it felt right, and it felt really good. YMMV chef's kiss

Re: Progress bars still lie

#52

Post by news_to_me »

qayxc wrote: post #44
news_to_me wrote: post #38

Earlier quoted context omitted.

A progress bar is a chart, nothing more, nothing less. And as any data scientist will tell you, charts without labels are bad charts. A progress bar should measure exactly one dimension, where a total is known, and a label should show what the dimension is. Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate. For most "loading" scenarios, a s…

> Usually progress bars implicitly measure "time left", but the total isn't known in that case, so progress bars are inapproprate. Are you sure about that? I'd argue that most progress bars explicitly measure tasks/work left and it's the user who wrongly correlates this with "time left" in many cases. Note that the OP didn't complain about time, but about the percentage not going from 0% to 100% for example.

Yeah, you might be right about that. Still, that's not using a progress bar correctly if it's measuring multiple tasks — they should be measured individually, with spinners or a segmented progress bar.

Re: Progress bars still lie

#53

Post by gtsop »

I have only implemented progressbars on the web.

After various progressbars on different projects my approach is this:

- Have an array of tasks

- Have a % progressbar

- Each task adds (100/total_tasks)% once completed regardless of how fast it is

Now comes the fun part. There is this single task that takes up the majority of the time amd your progressbar is stuck at 56% percent for too much time compared to the other tasks. You don't have feedback as a user. Is it stuck? Is it still going on?

Now is the time to optimize for use experience!

Why is this task taking so long? Are you loading a huge asset? Break it up, compress it, optimoze it. Are you doing something CPU intensive? Break up your computation over distinct tasks.

This attitude has led me to implement better technological solutions as well as user experiences

Re: Progress bars still lie

#55

Post by layer8 »

axaxs wrote: post #19

I think I'd rather just have predetermined steps/milestones. Think about it...what does 71 percent really mean? Would you get excited when it goes it 72? It's just an opaque, useless metric. If instead I can see something like...step 1/5, downloading package... that's far more meaningful, at least to me.

I agree in that there should be text with the progress bar showing what the progress bar actually measures, e.g. “57 of 285 records processed” or “3:05 (ETA 10:34)”. If you can’t, then it’s a sign that a progress bar is probably not appropriate.

Re: Progress bars still lie

#56

Post by dkersten »

news_to_me wrote: post #41
fgdelcueto wrote: post #13

When progress bars are not useful it is because the underlying problem is hard to extrapolate faithfully. If you are doing just a few tasks where each one takes a significant different time to execute, it will be hard to estimate. More often than not, they work fine, IMO. When they don't, it is because for that particular problem it is genuinely hard to do. It isn't programmer's laziness, I think, in most cases.

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

It reminds me of the old (maybe it still does it, I dunno) windows install progress bars vs ones where multiple things are wrapped into one.

With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator.

Those old windows installers used two bars: the top one was basically a steps indicator (file N of M, for example) -- just like the single bar for multiple tasks. But the second bar was a per-file bar. So if step 99 took longer, you had a second bar showing you that steps/files progress.

Re: Progress bars still lie

#57

Post by SulfurHexaFluri »

thesuitonym wrote: post #37
SulfurHexaFluri wrote: post #31

Earlier quoted context omitted.

Its incredible how much faster you can make an app feel by just making the UI respond faster and filling in the data later. As long as something happens instantly its satisfying.

Is this the idea behind that? I can't think of anything I hate more than a web page that loads with absolutely nothing useful, then waits for all the JS to load, then loads content. I suppose I understand wanting SOMETHING to show up, but could we PLEASE make it be the raw text first?

People love to see progress rather than start to finish speed. Its why getting stuck in traffic is frustrating while riding a bike is not even if you take longer overall.

A blank page for 2 seconds is worse for the average user than a UI template instantly and 2.2 seconds of content filling.

Re: Progress bars still lie

#58

Post by dkersten »

canadian_tired wrote: post #14
pmoriarty wrote: post #6

Lying progress bars are one of those ubiquitous anti-features which make me suspect the people who write the apps that have it or who decide what features they are to have never actually use their own software, or they'd realize in a heartbeat how incredibly annoying and frustrating lying progress bars are. I'd love to hear an HN reader who is brave enough to own up to implementing one of these explain the rationale…

Well... story time. I had to implement a lying progress bar at the behest of my client. We could not reliably predict much...network speed, file size, moon phases, sock colour, etc would change things all the time. The client wanted to show the customer that "things were happening"... so we made the bar always move. The logic was that once it hit 90% or more, customers seemed to be invested and would wait forever. An…

What's wrong with using something like a spinner in that case though? The big issue with a lying progress bar is that it not only lies when things are happening, it also lies when things are broken, possibly wasting a lot of your users' time.

Re: Progress bars still lie

#59

Post by news_to_me »

A progress bar is only appropriate to show one metric changing between two known points over time.

- A progress bar should not measure multiple tasks, unless each task is of the same type (e.g. converting a batch of files, _not_ system booting)

- A progress bar should not measure "time left" unless it is literally tied to the value of a timer (i.e. _not_ "time left to download big file")

- A progress bar does not show "busy state" — a spinner does that. A progress bar can stop if e.g. it measures bytes of a file downloaded and the network connection drops; a spinner will still spin.

- A progress bar should include a label to explicitly state what it is measuring (otherwise users will assume it means "time left")

People like to see progress bars because they want to know "progress is being made", but a progress bar is not always appropriate, depending on the situation. Instead, consider using:

- Spinners show activity is happening. Use when there isn't a single metric to report, or the "bounds" of the metric aren't known.

- A checklist can show different tasks completed in sequence. Can be combined with a spinner on the "current" task

- A segmented progress bar can replace a checklist when each task could be represented by a progress bar

Just my opinions, I guess, and obviously we don't live in the world where the above is applied, but it feels good to have it sorted in my own head. Curious what others think of this scheme.

Re: Progress bars still lie

#60

Post by news_to_me »

dkersten wrote: post #56
news_to_me wrote: post #41

Earlier quoted context omitted.

A progress bar should not indicate progress over multiple tasks — a segmented progress bar is better, or a series of spinners, or just a single spinner for the whole set. A progress bar should measure exactly one metric, where the total is known.

It reminds me of the old (maybe it still does it, I dunno) windows install progress bars vs ones where multiple things are wrapped into one. With multiple things wrapped into one, you often end up in situations where 0-99% (or whatever) might happen super fast but that last 1% takes ages, making the progress bar useless as a "something's happening" indicator. Those old windows installers used two bars: the top one wa…

Yeah, I think I remember those! If it were me, I would turn the segmented bar into a checklist, since you can add a description and I think it looks nicer. But the approach was a good one imo.
Post reply on HN