4 ms·

It’s my observation that only developers really notice or care about speed. As long as something is “fast enough” (and the benchmark here is pretty low), most p

It’s my observation that only developers really notice or care about speed. As long as something is “fast enough” (and the benchmark here is pretty low), most people won’t specifically choose a fast app over a slow app with more features. This means that sometimes we put too much emphasis on speed. But it is not as important to everyone else as it is to us. A product with the defining feature “it is fast”, usually fails to get noticed except by other developers.

californical 4y ago
I understand where you’re coming from, but when you have expert users of your software, they’ll be extremely sensitive to speed. Maybe a casual user won’t care, though. For example, my company has a team of experts who use our internal tool for managing company-related tasks. They use this tool every day as a core part of their job. It’s a team of literally hundreds of people who use this tool. If we add a feature which adds a click to some step of something they’re used to doing, we’ll never hear the end of it. Their team celebrates whenever we can add any sort of speed increase to something they’ve been using for a while. Adding shortcuts to common functionality is always a big user request. It’s obviously not a core part of our job to consider only performance, we add and change lots of features all the time. But if we ever neglect performance for too long, it can really start to weigh their team down. It’s interesting working so close to the people who use the software, because they don’t hesitate to give feedback like that, which you’d never get from just an internet software release. Lots of other software will have these “expert users” too, but you won’t hear the feedback.
alkonaut 4y ago
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
imron 4y ago
> As long as something is “fast enough” (and the benchmark here is pretty low), most people won’t specifically choose a fast app over a slow app with more features. The author chooses to use all sorts of slow software. Speed won't stop people using it, they'll just use it and think it's poorly designed/engineered.
dan-robertson 4y ago
I’m surprised by this experience because I think most user studies seem to find that speed improvements can have a big impact on important metrics for apps/websites used by many people. Presumably your users don’t have much choice in what software they get. Another argument for speed is that developers tend to have high-end hardware so things that are bearable for them may be significantly slower for users. This matters more for phones (wide range of performance) and things that depend on network speeds.
thfuran 4y ago
I work in medical software and can think of multiple times where we ended up with a slew of tickets when we made some change that ended up adding a single additional click to radiologist's workflows. I suspect that a lot of software with professional users would draw similar UX complaints.
usefulcat 4y ago
Sort of, though games seem like a fairly obvious counter example.

californical 4y ago

I understand where you’re coming from, but when you have expert users of your software, they’ll be extremely sensitive to speed. Maybe a casual user won’t care, though. For example, my company has a team of experts who use our internal tool for managing company-related tasks. They use this tool every day as a core part of their job. It’s a team of literally hundreds of people who use this tool. If we add a feature which adds a click to some step of something they’re used to doing, we’ll never hear the end of it. Their team celebrates whenever we can add any sort of speed increase to something they’ve been using for a while. Adding shortcuts to common functionality is always a big user request. It’s obviously not a core part of our job to consider only performance, we add and change lots of features all the time. But if we ever neglect performance for too long, it can really start to weigh their team down. It’s interesting working so close to the people who use the software, because they don’t hesitate to give feedback like that, which you’d never get from just an internet software release. Lots of other software will have these “expert users” too, but you won’t hear the feedback.

alkonaut 4y ago

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

imron 4y ago

> As long as something is “fast enough” (and the benchmark here is pretty low), most people won’t specifically choose a fast app over a slow app with more features. The author chooses to use all sorts of slow software. Speed won't stop people using it, they'll just use it and think it's poorly designed/engineered.

dan-robertson 4y ago

I’m surprised by this experience because I think most user studies seem to find that speed improvements can have a big impact on important metrics for apps/websites used by many people. Presumably your users don’t have much choice in what software they get. Another argument for speed is that developers tend to have high-end hardware so things that are bearable for them may be significantly slower for users. This matters more for phones (wide range of performance) and things that depend on network speeds.

thfuran 4y ago

I work in medical software and can think of multiple times where we ended up with a slew of tickets when we made some change that ended up adding a single additional click to radiologist's workflows. I suspect that a lot of software with professional users would draw similar UX complaints.

usefulcat 4y ago

Sort of, though games seem like a fairly obvious counter example.