6 ms·

As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". I think the best option is simply X/Y bytes do

As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". I think the best option is simply X/Y bytes downloaded, like Blizzard does on WoW patches. The fraction indicates how much is left to download, and the rate of the numerator changing informs how quickly the download is going.

paxys 6y ago
You're bringing up the easiest use case though. Most complex flows cannot be easily expressed by a single determinable metric.
- kazinator 6y ago
  Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
  - fomine3 6y ago
    Or just show verbose logs like Apt GUI frontend.
    - kazinator 6y ago
      Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.
      - yellowapple 6y ago
        It's invaluable from a troubleshooting perspective, though. "Hmm, it always seems to get stuck when installing this particular package"
        cgriswald 6y ago
        This is the most infuriating part of progress bars to me. When it hangs I don’t even have a jumping off point for Google. I can only search “foo hangs during install” which almost always results in issues that are not the problem I’m experiencing because usually the most common reason isn’t the reason the majority of the time. “Foo hangs during ‘reticulating splines’” usually has far more useful results.
    - yyx 6y ago
      Had problem when GUI closed after trying to install a package. No error, no logs. (or was it defaulting to the normal state with install button and no logs, I don't remember) Found out about package conflict only after running apt from the terminal.
  - admax88q 6y ago
    If you can reliably break down your complex flow into a tree of checkboxes, you could just as easily render a truthful progress bar based upon how many sub tasks are done.
    - eru 6y ago
      Yes, but that bar would still get hung intermittently whenever a specific task took a long time.
      - karottenreibe 6y ago
        How is the checkbox thing any different? If one task blocks progress, the tree also doesn't update
        eru 6y ago
        I don't know whether it _will_ be any different, but there was some speculation about that: > If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
        TeMPOraL 6y ago
        Context. You see not just the thing currently executing, but also the things remaining to be executed - which allows you to mentally gauge which of them may slow down.
        coldtea 6y ago
        At least I know what it is doing at the moment its blocked (and in many cases I can tell whether that is justified to take N time or not). With a progress bar I don't know anything.
  - cbhl 6y ago
    A tree is insufficient for flows at $dayjob, you need a directed acyclic graph to handle fanout/parallelism. For which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.
generalizations 6y ago
> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or not the whole thing was frozen and needed the power cord pulled.
- hutzlibu 6y ago
  Well, not necessarily, if the GUI with the progress bar and the installation or whatever are on seperated threads.
  - generalizations 6y ago
    That's true on the backend, but it doesn't help the end user much, since they don't know that.
    - rini17 6y ago
      Heh, I've imagined a message like: "Your task has started and is processing in the background where it can't be observed. Please wait." [OK]
- jbay808 6y ago
  I've seen Google display progress bars showing that my page is loading, even when I've totally lost internet connection and I know it will never load. The progress bar goes as something like 1-e^-t, so it just asymptotically approaches 100% but never gets there. When it's that kind of lie, I don't think it's conveying any essential information.
  - ploxiln 6y ago
    IE6 also did this back in the day, it was infuriating.
  - 6y ago
cm2187 6y ago
Alternatively you can flash actions on the screen, even if the user cannot read or understand what these actions correspond to, it conveys the message that work is being done (it’s not hung) without lying on how far you think we are into the process (if you don’t have that visibility).
woodrowbarlow 6y ago
if you give numbers of any sort, users will try to mentally do the math to convert that to a percentage -- and at that point, you might as well give them a progress bar. If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage. i'm a fan of "checklists" that get ticked off as the process progresses; possibly with progress bars for specific tasks, if they have a straightforward way of measuring that (like % downloaded). but i almost never include an overall progress bar for a multi-step process. it keeps the user's focus on the current task, while still providing some information about what's to come.
- quacked 6y ago
  That works for completion status, but I don't think it works for task failure notification. Do you know of any clever way that reliably informs the user whether or not the process is frozen?

paxys 6y ago

You're bringing up the easiest use case though. Most complex flows cannot be easily expressed by a single determinable metric.

kazinator 6y ago
Complex flows can be represented by a tree control full of checkboxes that tick off for things that are done, which can be hidden behind a "show details ..." button next to a regular progress bar. If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
- fomine3 6y ago
  Or just show verbose logs like Apt GUI frontend.
  - kazinator 6y ago
    Problem with just logging the progress is that the user has no idea where he "bottom" is. A log might as well be a spinning cursor or any other animation.
    - yellowapple 6y ago
      It's invaluable from a troubleshooting perspective, though. "Hmm, it always seems to get stuck when installing this particular package"
      - cgriswald 6y ago
        This is the most infuriating part of progress bars to me. When it hangs I don’t even have a jumping off point for Google. I can only search “foo hangs during install” which almost always results in issues that are not the problem I’m experiencing because usually the most common reason isn’t the reason the majority of the time. “Foo hangs during ‘reticulating splines’” usually has far more useful results.
  - yyx 6y ago
    Had problem when GUI closed after trying to install a package. No error, no logs. (or was it defaulting to the normal state with install button and no logs, I don't remember) Found out about package conflict only after running apt from the terminal.
- admax88q 6y ago
  If you can reliably break down your complex flow into a tree of checkboxes, you could just as easily render a truthful progress bar based upon how many sub tasks are done.
  - eru 6y ago
    Yes, but that bar would still get hung intermittently whenever a specific task took a long time.
    - karottenreibe 6y ago
      How is the checkbox thing any different? If one task blocks progress, the tree also doesn't update
      - eru 6y ago
        I don't know whether it _will_ be any different, but there was some speculation about that: > If the users can see the detailed tasks, maybe they will be less ticked off by a jumpy progress bar.
      - TeMPOraL 6y ago
        Context. You see not just the thing currently executing, but also the things remaining to be executed - which allows you to mentally gauge which of them may slow down.
      - coldtea 6y ago
        At least I know what it is doing at the moment its blocked (and in many cases I can tell whether that is justified to take N time or not). With a progress bar I don't know anything.
- cbhl 6y ago
  A tree is insufficient for flows at $dayjob, you need a directed acyclic graph to handle fanout/parallelism. For which a visualization exists internally, but every time someone decides to "fix" the progress bar problem they do a one-off analysis and only wire up the three biggest steps to the bar.

generalizations 6y ago

> As another commenter pointed out, static "processing" messages are indistinguishable from "your system is hung". This is an important point. "Lying" progress bars are still conveying essential information - that the installation is progressing and isn't frozen. I remember from my days working with W98 and early Ubuntu versions, one of the most important bits of information coming from progress bars was whether or not the whole thing was frozen and needed the power cord pulled.

hutzlibu 6y ago
Well, not necessarily, if the GUI with the progress bar and the installation or whatever are on seperated threads.
- generalizations 6y ago
  That's true on the backend, but it doesn't help the end user much, since they don't know that.
  - rini17 6y ago
    Heh, I've imagined a message like: "Your task has started and is processing in the background where it can't be observed. Please wait." [OK]
jbay808 6y ago
I've seen Google display progress bars showing that my page is loading, even when I've totally lost internet connection and I know it will never load. The progress bar goes as something like 1-e^-t, so it just asymptotically approaches 100% but never gets there. When it's that kind of lie, I don't think it's conveying any essential information.
- ploxiln 6y ago
  IE6 also did this back in the day, it was infuriating.
- 6y ago

cm2187 6y ago

Alternatively you can flash actions on the screen, even if the user cannot read or understand what these actions correspond to, it conveys the message that work is being done (it’s not hung) without lying on how far you think we are into the process (if you don’t have that visibility).

woodrowbarlow 6y ago

if you give numbers of any sort, users will try to mentally do the math to convert that to a percentage -- and at that point, you might as well give them a progress bar. If you instead just show a description of the current task, users will want to know how many tasks are left. if you tell them how many are left, they will revert to thinking of it as an overall percentage. i'm a fan of "checklists" that get ticked off as the process progresses; possibly with progress bars for specific tasks, if they have a straightforward way of measuring that (like % downloaded). but i almost never include an overall progress bar for a multi-step process. it keeps the user's focus on the current task, while still providing some information about what's to come.

quacked 6y ago
That works for completion status, but I don't think it works for task failure notification. Do you know of any clever way that reliably informs the user whether or not the process is frozen?