3 ms·

Good enough is good enough. Just like faster computers don’t make new apps any faster (even at the peak of scaling decades ago), they make sure we can write mor

Good enough is good enough. Just like faster computers don’t make new apps any faster (even at the peak of scaling decades ago), they make sure we can write more complex apps without making them too slow, or equivalently, add more things to apps and sites if there is any performance headroom left.

dylan604 4y ago
>Good enough is good enough. Oh to be a mere average computer user. I work with files that can still take some non-instant time after hitting save to complete. Conversely, it still takes some non-instant time to open said file. As long as there's such a thing as progress bars, count downs, spinning wheels, beach balls, etc, there is always room to make things faster.
- alkonaut 4y ago
  I develop very complicated software for a living and as always, there are some features that will take an unreasonable amount of time. On large documents, you have customers wait 5 seconds for a regular operation (that you may need to complete dozens of times in a row). And yet when you ask customers whether they want more features, or a faster program it's invariably features. Fix a bug or add a feature? Add a feature. Improve perf or add a feature? Add a feature. My own tolerance for delays is tiny, but my "average users" seem to not suffer from it at all. I guess the reason is this: they know how much time something took before. They know that if this takes 10 seconds and it took them an hour to do on paper, that's quick. Meanwhile for me I'm in the IDE having a 200ms keystroke delay and I'm almost having a heart attack.
  - dylan604 4y ago
    >And yet when you ask customers whether they want more features, or a faster program it's invariably features. Fix a bug or add a feature? Add a feature. Improve perf or add a feature? Add a feature. Of course this is what they want. To the user, the damn thing should have been working when you released it. To the user, you shouldn't have to ask to have something that's broken but is meant to be a feature to be fixed. If it's not working, why is it there in the first place. Fix it. Duh. But also add new features before your competitor does and takes your users. This is such a weird excuse on discussions about a progress bar.
- midoridensha 4y ago
  Go re-watch "Office Space" from the 1990s, in particular the scene where the main character is trying to save his work and shut down before the boss comes by and asks him to work over the weekend. 25 years later, progress bars are no better: they steadily go to 15%, then stop there for a while, suddenly zoom to 80%, then slowly progress to 99%, then stop there for a long time.
  - alkonaut 4y ago
    Writing a progress bar is basically still impossible. If you are doing a single slow thing like rendering or uploading etc then you can make a progress bar. But if you are making something that has multiple phases and you want to use a single progress bar then that isn't goingt to progress nicely from 0 to 100 it's just impossible. You'll either have to make an overall progress bar for the different phases, or just indicate that this is phase 4/5 and the progress of that phase is 82%. This solves the jumpy progress bar issue, but doesn't solve the underlying issue of actually showing an estimate of time remaining. You have no idea whether phase 5/5 is going to take 1 second or 1 minute. When a progress bar stops at 99% it's just because some final task that was expected to not take very long, did. E.g. it could be deleting a file at the end of some install process, and that for some reason blocks. There is obviously no way of knowing the actual time that will take without trying it, at which point it's too late for the progress bar to adjust of course. So: we'll have general artificial intelligence on smartwatches, before we have smooth multi-phase progress indication (because that's never).
    - moring 4y ago
      > There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take. What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.
      - 4y ago
fmajid 4y ago
https://danluu.com/input-lag/ https://danluu.com/input-lag/

dylan604 4y ago

>Good enough is good enough. Oh to be a mere average computer user. I work with files that can still take some non-instant time after hitting save to complete. Conversely, it still takes some non-instant time to open said file. As long as there's such a thing as progress bars, count downs, spinning wheels, beach balls, etc, there is always room to make things faster.

alkonaut 4y ago
I develop very complicated software for a living and as always, there are some features that will take an unreasonable amount of time. On large documents, you have customers wait 5 seconds for a regular operation (that you may need to complete dozens of times in a row). And yet when you ask customers whether they want more features, or a faster program it's invariably features. Fix a bug or add a feature? Add a feature. Improve perf or add a feature? Add a feature. My own tolerance for delays is tiny, but my "average users" seem to not suffer from it at all. I guess the reason is this: they know how much time something took before. They know that if this takes 10 seconds and it took them an hour to do on paper, that's quick. Meanwhile for me I'm in the IDE having a 200ms keystroke delay and I'm almost having a heart attack.
- dylan604 4y ago
  >And yet when you ask customers whether they want more features, or a faster program it's invariably features. Fix a bug or add a feature? Add a feature. Improve perf or add a feature? Add a feature. Of course this is what they want. To the user, the damn thing should have been working when you released it. To the user, you shouldn't have to ask to have something that's broken but is meant to be a feature to be fixed. If it's not working, why is it there in the first place. Fix it. Duh. But also add new features before your competitor does and takes your users. This is such a weird excuse on discussions about a progress bar.
midoridensha 4y ago
Go re-watch "Office Space" from the 1990s, in particular the scene where the main character is trying to save his work and shut down before the boss comes by and asks him to work over the weekend. 25 years later, progress bars are no better: they steadily go to 15%, then stop there for a while, suddenly zoom to 80%, then slowly progress to 99%, then stop there for a long time.
- alkonaut 4y ago
  Writing a progress bar is basically still impossible. If you are doing a single slow thing like rendering or uploading etc then you can make a progress bar. But if you are making something that has multiple phases and you want to use a single progress bar then that isn't goingt to progress nicely from 0 to 100 it's just impossible. You'll either have to make an overall progress bar for the different phases, or just indicate that this is phase 4/5 and the progress of that phase is 82%. This solves the jumpy progress bar issue, but doesn't solve the underlying issue of actually showing an estimate of time remaining. You have no idea whether phase 5/5 is going to take 1 second or 1 minute. When a progress bar stops at 99% it's just because some final task that was expected to not take very long, did. E.g. it could be deleting a file at the end of some install process, and that for some reason blocks. There is obviously no way of knowing the actual time that will take without trying it, at which point it's too late for the progress bar to adjust of course. So: we'll have general artificial intelligence on smartwatches, before we have smooth multi-phase progress indication (because that's never).
  - moring 4y ago
    > There is obviously no way of knowing the actual time that will take without trying (...) How is that obvious? Deleting a file doesn't just block for no reason. The OS (usually) or disk hardware (rarely) are the ones that decide to block it, and they have the information needed to know how long it will take. What actually happens is that the advantages of showing a correct progress bar simply don't justify the complexity needed for it, and a decision to show a crappy incorrect progress bar is made.
    - 4y ago

fmajid 4y ago

https://danluu.com/input-lag/ https://danluu.com/input-lag/