4 ms·

I made a fake progress bar to shut up clients complaining about my app freezing

6 points by vincent_s 3y ago

jacknobody 3y ago
My progress bar froze?
- coldtea 3y ago
  The algorithm was done so that it almost never froze, by giving enough time for most of API calls to finish (based on him knowing the response times it usually got). And even when it did, clients are conditioned to expect progress bars to freeze and then suddenly finish, from Windows and lots of other software.
  - Someone 3y ago
    And better keep them conditioned, because otherwise they would start expecting decent UI? This is a solved problem and its solution isn’t hard to implement. IMO not doing it the right way is an insult to your users.
    - coldtea 3y ago
      It's waiting for a slow remote customer endpoint. TTFB would be slow too. Unless you have access and/or reimplement the endpoint, there's no "solution" and it's not a "fixed problem". The most true thing would be to just show a label "Query send, waiting for results. Don't know how much it will take".
      - Someone 3y ago
        Sorry. I thought it was clear from context that I replied to the conditioning remark. The indeterminate progress bar/spinner were invented decades ago for this use case. There’s no need to assume users are “conditioned to expect progress bars to freeze and then suddenly finish”, and reinforce that. If you don’t know when bytes will start arriving or how many will arrive, don’t pretend you do know.
Someone 3y ago
> We were calling their API, and the app was clearly just waiting for results, which sometimes would take half a minute. Clearly to whom? You shouldn’t expect your users to know that your client’s API may be slow. > I added a progress bar that started at 5% went +10% every second till 65% That’s bad. If you don’t have a reasonable estimate for how long something will take, you should use an indeterminate progress bar. https://m2.material.io/components/progress-indicators#usage https://m2.material.io/components/progress-indicators#usage: “Determinate and indeterminate Progress indicators may be determinate or indeterminate: Determinate indicators Determinate indicators display how long a process will take. They should be used when the process completion rate can be detected. Indeterminate indicators Indeterminate indicators express an unspecified amount of wait time. They should be used when progress isn’t detectable, or if it’s not necessary to indicate how long an activity will take.” For this case, I would wait a second or so to see whether an answer returns rapidly, then pop up an indeterminate progress bar and keep it up for at least a second, even if the reply comes sooner.
- raverbashing 3y ago
  For real If you think your client will wait 30s without any visual feedback of what's being done you need to study about UX. This is one of the reasons why tech people "I'll just write an app" fall flat on their attempts. UX matters, a lot
  - ksaj 3y ago
    The Raspberry Pi OS Install (and some other Linux installs) simply change the image on the screen detailing various features or whatever. You may or may not see them all. You may or may not see them repeat. But what you do see, is that the system hasn't crashed and is still doing something. So a fake progress meter isn't really necessary.

6 points by vincent_s 3y ago

jacknobody 3y ago

My progress bar froze?

coldtea 3y ago
The algorithm was done so that it almost never froze, by giving enough time for most of API calls to finish (based on him knowing the response times it usually got). And even when it did, clients are conditioned to expect progress bars to freeze and then suddenly finish, from Windows and lots of other software.
- Someone 3y ago
  And better keep them conditioned, because otherwise they would start expecting decent UI? This is a solved problem and its solution isn’t hard to implement. IMO not doing it the right way is an insult to your users.
  - coldtea 3y ago
    It's waiting for a slow remote customer endpoint. TTFB would be slow too. Unless you have access and/or reimplement the endpoint, there's no "solution" and it's not a "fixed problem". The most true thing would be to just show a label "Query send, waiting for results. Don't know how much it will take".
    - Someone 3y ago
      Sorry. I thought it was clear from context that I replied to the conditioning remark. The indeterminate progress bar/spinner were invented decades ago for this use case. There’s no need to assume users are “conditioned to expect progress bars to freeze and then suddenly finish”, and reinforce that. If you don’t know when bytes will start arriving or how many will arrive, don’t pretend you do know.

Someone 3y ago

> We were calling their API, and the app was clearly just waiting for results, which sometimes would take half a minute. Clearly to whom? You shouldn’t expect your users to know that your client’s API may be slow. > I added a progress bar that started at 5% went +10% every second till 65% That’s bad. If you don’t have a reasonable estimate for how long something will take, you should use an indeterminate progress bar. https://m2.material.io/components/progress-indicators#usage https://m2.material.io/components/progress-indicators#usage: “Determinate and indeterminate Progress indicators may be determinate or indeterminate: Determinate indicators Determinate indicators display how long a process will take. They should be used when the process completion rate can be detected. Indeterminate indicators Indeterminate indicators express an unspecified amount of wait time. They should be used when progress isn’t detectable, or if it’s not necessary to indicate how long an activity will take.” For this case, I would wait a second or so to see whether an answer returns rapidly, then pop up an indeterminate progress bar and keep it up for at least a second, even if the reply comes sooner.

raverbashing 3y ago
For real If you think your client will wait 30s without any visual feedback of what's being done you need to study about UX. This is one of the reasons why tech people "I'll just write an app" fall flat on their attempts. UX matters, a lot
- ksaj 3y ago
  The Raspberry Pi OS Install (and some other Linux installs) simply change the image on the screen detailing various features or whatever. You may or may not see them all. You may or may not see them repeat. But what you do see, is that the system hasn't crashed and is still doing something. So a fake progress meter isn't really necessary.