4 ms·

Exactly this. I develop really “heavy” desktop apps for a living and this is my experience too. End users are solving a problem and that problem might be “produ

Exactly this. I develop really “heavy” desktop apps for a living and this is my experience too. End users are solving a problem and that problem might be “producing a quote for a machine for a customer”. If that took them an hour in the snappy but feature-lacking old software, and a new new software does it with enormous bloat, frustrating pauses, crashes but in half the time, then customers will love it and praise it. When there is a bug report for a performance issue it’s rarely some minor delay but usually something absurd like a 15 minute wait due to something accidentally quadratic. If you ask customers of course they won’t prefer the 2 second improvement for the function they use hundreds of times per day because it only saves them a few hundred seconds. They’d rather have one more feature that saves them 30 minutes every week instead. And the thing is there is an endless number of such features even after 200 man years of dev. At the same time, as a developer I have almost no understanding for this mindset. If I was forced to work with slow and frustrating software all day I’d quit and grow potatoes for a living instead (and I use visual studio so my treshold for bloat and frustration is pretty high).

kragen 4y ago
this take could hardly be further from being correct your users just aren't telling you they're frustrated and having trouble using your software; they may not even be aware of it, but it profoundly shapes how they interact with the software https://ai.googleblog.com/2009/06/speed-matters.html https://ai.googleblog.com/2009/06/speed-matters.html > All other things being equal, more usage, as measured by number of searches, reflects more satisfied users. Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment). That's 0.2% to 0.6% fewer searches for changes under half a second! > Furthermore, users do fewer and fewer searches the longer they are exposed to the experiment. Users exposed to a 200 ms delay since the beginning of the experiment did 0.22% fewer searches during the first three weeks, but 0.36% fewer searches during the second three weeks. Similarly, users exposed to a 400 ms delay since the beginning of the experiment did 0.44% fewer searches during the first three weeks, but 0.76% fewer searches during the second three weeks. Even if the page returns to the faster state, users who saw the longer delay take time to return to their previous usage level. Users exposed to the 400 ms delay for six weeks did 0.21% fewer searches on average during the five week period after we stopped injecting the delay. https://danluu.com/term-latency/ https://danluu.com/term-latency/ > There’s a great MSR demo from 2012 that shows the effect of latency on the experience of using a tablet. If you don’t want to watch the three minute video, they basically created a device which could simulate arbitrary latencies down to a fraction of a millisecond. At 100ms (1/10th of a second), which is typical of consumer tablets, the experience is terrible. At 10ms (1/100th of a second), the latency is noticeable, but the experience is ok, and at < 1ms the experience is great, as good as pen and paper. If you want to see a mini version of this for yourself, you can try a random Android tablet with a stylus vs. the current generation iPad Pro with the Apple stylus. The Apple device has well above 10ms end-to-end latency, but the difference is still quite dramatic -- it’s enough that I’ll actually use the new iPad Pro to take notes or draw diagrams, whereas I find Android tablets unbearable as a pen-and-paper replacement. ... > Curiously, I rarely hear complaints about keyboard and mouse input being slow. One reason might be that keyboard and mouse input are quick and that inputs are reflected nearly instantaneously, but I don’t think that’s true. People often tell me that’s true, but I think it’s just the opposite. The idea that computers respond quickly to input, so quickly that humans can’t notice the latency, is the most common performance-related fallacy I hear from professional programmers. ... > Why don’t people complain about keyboard-to-display latency the way they complain stylus-to-display latency or VR latency? My theory is that, for both VR and tablets, people have a lot of experience with a much lower latency application. For tablets, the “application” is pen-and-paper, and for VR, the “application” is turning your head without a VR headset on. But input-to-display latency is so bad for every application that most people just expect terrible latency. https://danluu.com/input-lag/ https://danluu.com/input-lag/ > For very simple tasks, people can perceive latencies down to 2 ms or less. Moreover, increasing latency is not only noticeable to users, it causes users to execute simple tasks less accurately. If you want a visual demonstration of what latency looks like and you don’t have a super-fast old computer lying around, check out this MSR demo on touchscreen latency. there are mountains of research on this from every angle and it turns out that users do not love and praise software that has high interaction latency they hate it and reorganize their life if necessary to use it as little as possible (but it is true that often there is no snappier software that does what they need) also sometimes customers do love and praise it if they aren't the users
- midoridensha 4y ago
  >also sometimes customers do love and praise it if they aren't the users This is important and often overlooked. Many times, the customers for some software are not the same as the users of that software. The customers are the only ones who matter: they're the ones who pay for the software. The users don't matter at all: even if they absolutely loathe the software, so what? They have no power to change things and aren't writing the checks. Screw 'em. If they don't like it, they can find another job. As a result of this, we get "enterprise software".
  - alkonaut 4y ago
    This is true (in most cases I assume), but it's users that make the free marketing, not the managers that pay the bills. They might say "productivity is up", but they don't say "I like using it". If you don't want to spend money marketing software, you probably want both of those kinds of free marketing.
    - midoridensha 4y ago
      I don't think most enterprise software users actually talk about the crappy software they use outside of work, or to other people in the same industry but at other companies. For instance, at one job I had to use time-keeping software to track my hours, vacation time, etc. Like all employees, I was just a user of that software, but it had nothing to do with my normal job, it was just to track attendance and such. Except for complaining, I never went around to other competing companies to talk to them about their time-keeping software. And my company's upper management sure as heck didn't bother to ask me if I liked the software, or if they should contract with a different vendor. Even if they did, it's not like I had a lot of experience with different, competing products. Plus, being enterprise software, it was heavily customized for that company. The users of this software weren't providing free marketing to anyone. The marketing was probably done with backroom deals over expensive dinners and sports event tickets, I'm guessing.
- alkonaut 4y ago
  > (but it is true that often there is no snappier software that does what they need) I think this is the key phrase. Given the choice between snappy but doesn't do all they need, or does it slowly. They will rearrange their lives and use the slow/bloated software that does what they need. It's exactly the same question answered as "should we improve performance or add a feature" that we ask users all the time. > they hate it and reorganize their life if necessary to use it as little as possible My particular software is of the kind that all users use it 100% of the time (i.e. 40h a week more or less). So there really isn't any way to use it more or less. They just get N dollars of work done in a week and that N will beat any amount of frustration, apparently.
Marsymars 4y ago
This sounds weirdly similar to my job. Expectations like that aren’t only around speed - a while ago I was asked to investigate a certain hardware/software platform combination, and with the constraints given, text came out perpetually blurry, so my answer was just “it’s unusable”, but then some non-devs had a look and were like “eh, it’s legible, we can make this work.”

kragen 4y ago

this take could hardly be further from being correct your users just aren't telling you they're frustrated and having trouble using your software; they may not even be aware of it, but it profoundly shapes how they interact with the software https://ai.googleblog.com/2009/06/speed-matters.html https://ai.googleblog.com/2009/06/speed-matters.html > All other things being equal, more usage, as measured by number of searches, reflects more satisfied users. Our experiments demonstrate that slowing down the search results page by 100 to 400 milliseconds has a measurable impact on the number of searches per user of -0.2% to -0.6% (averaged over four or six weeks depending on the experiment). That's 0.2% to 0.6% fewer searches for changes under half a second! > Furthermore, users do fewer and fewer searches the longer they are exposed to the experiment. Users exposed to a 200 ms delay since the beginning of the experiment did 0.22% fewer searches during the first three weeks, but 0.36% fewer searches during the second three weeks. Similarly, users exposed to a 400 ms delay since the beginning of the experiment did 0.44% fewer searches during the first three weeks, but 0.76% fewer searches during the second three weeks. Even if the page returns to the faster state, users who saw the longer delay take time to return to their previous usage level. Users exposed to the 400 ms delay for six weeks did 0.21% fewer searches on average during the five week period after we stopped injecting the delay. https://danluu.com/term-latency/ https://danluu.com/term-latency/ > There’s a great MSR demo from 2012 that shows the effect of latency on the experience of using a tablet. If you don’t want to watch the three minute video, they basically created a device which could simulate arbitrary latencies down to a fraction of a millisecond. At 100ms (1/10th of a second), which is typical of consumer tablets, the experience is terrible. At 10ms (1/100th of a second), the latency is noticeable, but the experience is ok, and at < 1ms the experience is great, as good as pen and paper. If you want to see a mini version of this for yourself, you can try a random Android tablet with a stylus vs. the current generation iPad Pro with the Apple stylus. The Apple device has well above 10ms end-to-end latency, but the difference is still quite dramatic -- it’s enough that I’ll actually use the new iPad Pro to take notes or draw diagrams, whereas I find Android tablets unbearable as a pen-and-paper replacement. ... > Curiously, I rarely hear complaints about keyboard and mouse input being slow. One reason might be that keyboard and mouse input are quick and that inputs are reflected nearly instantaneously, but I don’t think that’s true. People often tell me that’s true, but I think it’s just the opposite. The idea that computers respond quickly to input, so quickly that humans can’t notice the latency, is the most common performance-related fallacy I hear from professional programmers. ... > Why don’t people complain about keyboard-to-display latency the way they complain stylus-to-display latency or VR latency? My theory is that, for both VR and tablets, people have a lot of experience with a much lower latency application. For tablets, the “application” is pen-and-paper, and for VR, the “application” is turning your head without a VR headset on. But input-to-display latency is so bad for every application that most people just expect terrible latency. https://danluu.com/input-lag/ https://danluu.com/input-lag/ > For very simple tasks, people can perceive latencies down to 2 ms or less. Moreover, increasing latency is not only noticeable to users, it causes users to execute simple tasks less accurately. If you want a visual demonstration of what latency looks like and you don’t have a super-fast old computer lying around, check out this MSR demo on touchscreen latency. there are mountains of research on this from every angle and it turns out that users do not love and praise software that has high interaction latency they hate it and reorganize their life if necessary to use it as little as possible (but it is true that often there is no snappier software that does what they need) also sometimes customers do love and praise it if they aren't the users

midoridensha 4y ago
>also sometimes customers do love and praise it if they aren't the users This is important and often overlooked. Many times, the customers for some software are not the same as the users of that software. The customers are the only ones who matter: they're the ones who pay for the software. The users don't matter at all: even if they absolutely loathe the software, so what? They have no power to change things and aren't writing the checks. Screw 'em. If they don't like it, they can find another job. As a result of this, we get "enterprise software".
- alkonaut 4y ago
  This is true (in most cases I assume), but it's users that make the free marketing, not the managers that pay the bills. They might say "productivity is up", but they don't say "I like using it". If you don't want to spend money marketing software, you probably want both of those kinds of free marketing.
  - midoridensha 4y ago
    I don't think most enterprise software users actually talk about the crappy software they use outside of work, or to other people in the same industry but at other companies. For instance, at one job I had to use time-keeping software to track my hours, vacation time, etc. Like all employees, I was just a user of that software, but it had nothing to do with my normal job, it was just to track attendance and such. Except for complaining, I never went around to other competing companies to talk to them about their time-keeping software. And my company's upper management sure as heck didn't bother to ask me if I liked the software, or if they should contract with a different vendor. Even if they did, it's not like I had a lot of experience with different, competing products. Plus, being enterprise software, it was heavily customized for that company. The users of this software weren't providing free marketing to anyone. The marketing was probably done with backroom deals over expensive dinners and sports event tickets, I'm guessing.
alkonaut 4y ago
> (but it is true that often there is no snappier software that does what they need) I think this is the key phrase. Given the choice between snappy but doesn't do all they need, or does it slowly. They will rearrange their lives and use the slow/bloated software that does what they need. It's exactly the same question answered as "should we improve performance or add a feature" that we ask users all the time. > they hate it and reorganize their life if necessary to use it as little as possible My particular software is of the kind that all users use it 100% of the time (i.e. 40h a week more or less). So there really isn't any way to use it more or less. They just get N dollars of work done in a week and that N will beat any amount of frustration, apparently.

Marsymars 4y ago

This sounds weirdly similar to my job. Expectations like that aren’t only around speed - a while ago I was asked to investigate a certain hardware/software platform combination, and with the constraints given, text came out perpetually blurry, so my answer was just “it’s unusable”, but then some non-devs had a look and were like “eh, it’s legible, we can make this work.”