5 ms·

This matters more than one would think. I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like peop

This matters more than one would think. I've once worked on a system that was objectively slow. Some actions would take seconds to complete. It's not like people would refuse the use the system, it was the only way to do their jobs. The public had no choice, either. Initially, I didn't think it was such a big deal. Yes it was a bit slow, but nothing _terrible_ and why did it matter, since there were so many other procedures that took way longer than the software step. It was a government facility, lots of red tape. Surely optimizing some of the paper processes would be more beneficial. But we optimized it anyway. Not because the UI was slow(which we didn't even measure directly), but because it was slow for a reason - backend processes were taking time, and resources. If we could optimize, we thought, we would save resources (and also increase the runway until we had to expand again, buy hardware and the like). First round of optimization was completed. Lots of low hanging fruits(many database-related). Testing indicated that the backend would be faster by almost an order of magnitude. Deployed. THE SYSTEM BECAME SLOWER. How was that possible? Maybe we had missed something. We found more bottlenecks, optimized those. Deployed again. Everything is slow again. What's happening?! We went to the 'field' - as in, talked to the users. Well, this is what we discovered: we saw the backend working harder - because the users were more productive! Instead of staying after the facilities were closed to the public and then catching up on whatever paperwork they were unable to enter in the system, they could process everything almost as fast as people came in. Which means that they could go home early. What we saw as "the system being slow again" was due to bad metrics - we were watching backend load, not UI response times. Because, admittedly, that didn't bother us directly. Not until we talked to the poor souls that had to use the system. Lots of async processes got triggered and queues filled up, but it didn't really matter to the users, as long as the UI said things were submitted and they could move on. After that, we optimized the heck out of all the UI interactions we could find.

eyelidlessness 6y ago
This is great for two reasons (and probably more): 1. It highlights that user impact determines success more than resource metrics. 2. It shows that assumptions infect even when you think you’ve accounted for assumptions. Honorable mention: don’t just prove the abstraction and call it done. It’s got to prove itself in real world scenarios before you can trust its claims!
zwaps 6y ago
As a user forced to use many apps and websites with a terrible user experience, I conclude that you can certainly have well-communicated loading times without me hating the product. However, I will always avoid - if I can - using a product where the UI itself is slow, sluggish or bad. This includes many modern websites and also quite a few apps. Responsiveness is the key. If I click on something, then something needs to happen. People can deal with a loading bar, but everyone gets terribly confused and / or annoyed by a sluggish drop-down menus, buttons that seem to fire only after a couple of seconds, or, my favorite, a scrolling action that is either sluggish or leads to load processes that interrupt itself.
- greggman3 6y ago
  I'm am shocked how bad Apple is at this. They used to harp on it. It was in their Interface Guidelines in the 80s. Now every time they do a major OS update I get greeted by a bunch of setup screens like to enable Siri or iCloud etc and clicking on Ok or Cancel there is often no response for 2-5 seconds. No idea if I did it correctly or anything. I expect that from bad ATMs or Gas Pumps but not from Apple.
doctor_eval 6y ago
I had a similar experience using my own web app over a satellite link (750ms+ latency) many years ago. What took minutes at the office literally took hours over the air, which I found really surprising. I knew it would take longer but it was much more than 10x longer. This was when I first realised that UI delays have a non linear effect on productivity. The productivity loss from 10x latency increase is more than 10x. I don’t know how to explain it other than by example, but if you have multiple 1000ms delays you’re more likely to be distracted - to check your email or get a cup of tea or answer a slack message - than if you’re just ploughing through the work. That was my experience anyway. A few years later I saw the problem in a different context (ETL), so I drew up an informal scale from small to long delays using this kind of human centred thought process, and I realised that, for example, a 1 hour delay to process ETL data is effectively identical to a 6-12 hour delay, because the user will set the process off and go do something else productive for the rest of the work day, which had a huge impact on project delivery (of course). Once I had seen this in action, I couldn’t unsee it, and I spent the next few years getting rid of a pile of bottlenecks to make the UI performance and feedback loops as fast as possible, for example by refactoring complex operations. My proudest moment was reducing a very complex, 8 hour process down to a 5 minute (perceived) process by doing most of the work in advance, so the data was almost entirely ready before the user needed it. Our users thought the system had broken because it finished so quickly! I’m sure there are formal studies about this phenomenon, but it was so obvious once I’d experienced it, and our focus on UI latency made a huge difference to both the quantity and quality of the work we and our customers could get work done in a given time period.
- branko_d 6y ago
  Indeed, this non-linear effect of UI latency on productivity is real, and has been studied/known for decades. I think the "The Economic Value of Rapid Response Time" from 1982 is rather illuminating: https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html https://jlelliotton.blogspot.com/p/the-economic-value-of-rap...
  - doctor_eval 6y ago
    That’s a great article. Thanks!
noisy_boy 6y ago
The UI should be the last thing thats slow, relatively speaking. Database could be slow, network could have some issues, the backend code could be inefficient and so on. But if the UI is objectively slow, discounting above things, then that should be addressed asap. Because if that continues to be the issue, it doesn't matter how much quick the backend/database is - user just won't see the performance behind the scenes.

eyelidlessness 6y ago

This is great for two reasons (and probably more): 1. It highlights that user impact determines success more than resource metrics. 2. It shows that assumptions infect even when you think you’ve accounted for assumptions. Honorable mention: don’t just prove the abstraction and call it done. It’s got to prove itself in real world scenarios before you can trust its claims!

zwaps 6y ago

As a user forced to use many apps and websites with a terrible user experience, I conclude that you can certainly have well-communicated loading times without me hating the product. However, I will always avoid - if I can - using a product where the UI itself is slow, sluggish or bad. This includes many modern websites and also quite a few apps. Responsiveness is the key. If I click on something, then something needs to happen. People can deal with a loading bar, but everyone gets terribly confused and / or annoyed by a sluggish drop-down menus, buttons that seem to fire only after a couple of seconds, or, my favorite, a scrolling action that is either sluggish or leads to load processes that interrupt itself.

greggman3 6y ago
I'm am shocked how bad Apple is at this. They used to harp on it. It was in their Interface Guidelines in the 80s. Now every time they do a major OS update I get greeted by a bunch of setup screens like to enable Siri or iCloud etc and clicking on Ok or Cancel there is often no response for 2-5 seconds. No idea if I did it correctly or anything. I expect that from bad ATMs or Gas Pumps but not from Apple.

doctor_eval 6y ago

I had a similar experience using my own web app over a satellite link (750ms+ latency) many years ago. What took minutes at the office literally took hours over the air, which I found really surprising. I knew it would take longer but it was much more than 10x longer. This was when I first realised that UI delays have a non linear effect on productivity. The productivity loss from 10x latency increase is more than 10x. I don’t know how to explain it other than by example, but if you have multiple 1000ms delays you’re more likely to be distracted - to check your email or get a cup of tea or answer a slack message - than if you’re just ploughing through the work. That was my experience anyway. A few years later I saw the problem in a different context (ETL), so I drew up an informal scale from small to long delays using this kind of human centred thought process, and I realised that, for example, a 1 hour delay to process ETL data is effectively identical to a 6-12 hour delay, because the user will set the process off and go do something else productive for the rest of the work day, which had a huge impact on project delivery (of course). Once I had seen this in action, I couldn’t unsee it, and I spent the next few years getting rid of a pile of bottlenecks to make the UI performance and feedback loops as fast as possible, for example by refactoring complex operations. My proudest moment was reducing a very complex, 8 hour process down to a 5 minute (perceived) process by doing most of the work in advance, so the data was almost entirely ready before the user needed it. Our users thought the system had broken because it finished so quickly! I’m sure there are formal studies about this phenomenon, but it was so obvious once I’d experienced it, and our focus on UI latency made a huge difference to both the quantity and quality of the work we and our customers could get work done in a given time period.

branko_d 6y ago
Indeed, this non-linear effect of UI latency on productivity is real, and has been studied/known for decades. I think the "The Economic Value of Rapid Response Time" from 1982 is rather illuminating: https://jlelliotton.blogspot.com/p/the-economic-value-of-rapid-response.html https://jlelliotton.blogspot.com/p/the-economic-value-of-rap...
- doctor_eval 6y ago
  That’s a great article. Thanks!

noisy_boy 6y ago

The UI should be the last thing thats slow, relatively speaking. Database could be slow, network could have some issues, the backend code could be inefficient and so on. But if the UI is objectively slow, discounting above things, then that should be addressed asap. Because if that continues to be the issue, it doesn't matter how much quick the backend/database is - user just won't see the performance behind the scenes.