13 ms·

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.