4 ms·

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt

> Something like a quarter-second lag when you opened a dropdown or clicked a button So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

ziddoap 7y ago
Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?
- ChrisSD 7y ago
  Because that's literally the complaint as given. If the UI had reacted "instantly" it would be more user friendly. Even if the performance of the (non UI) code was slower. EDIT: Or to put it another way: "perceived performance can be more important than actual performance".
  - juliangoldsmith 7y ago
    Responsiveness is a result of adequate performance. The dropdowns that the article refers to are probably populated by a database, as opposed to being static. It doesn't matter if the dropdown opens instantly, what matters is that the information it contains is available.
- 0xDEFC0DE 7y ago
  My take is that responsiveness has a cap of speed that’s pinned to human perception. Once you get here you can stop worrying about needing more. Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception. Feels like I’m splitting hairs though
  - viraptor 7y ago
    No, that's a very good split :-) Even when responsiveness is great, you can still work on performance to improve: resources utilisation, energy usage, jitter of responsiveness, etc. Users may not notice, but the spending account may do. This distinction is more relevant with multi-user or time sharing systems, less so with single-user game consoles. (If you're hitting the right framerate at the most demanding scenes, why bother?)
- BubRoss 7y ago
  Responsiveness is about latency and feedback. Performance could mean that or it could mean throughput. If I'm using an interface I want responsive feedback without latency above everything else. I know it's easy to dump on electron, so I will. Multiple electron apps, especially the ethereum client, are the worst programs I have ever used, because there is enormous lag on a computer that runs everything else flawlessly. It's so bad it can't even be all blamed on electron, but more than bloat or memory use, interactivity is what I consider the most important factor in an interface. I even put it above great design or intuitiveness. I would take blender's ridiculous interface choices over something better that lags like the ethereum client any day of the week.
- snaky 7y ago
  Performance is about how it works, responsiveness is all about how it feels.
- alkonaut 7y ago
  If I click a button and it instantly shows me a dialog with a progress bar, and the progress bar progresses smoothly for one hour to complete the task, that is responsive (the UI responds to my click and the background update as quick as anyone could desire). That the task takes an hour to complete may or may not indicate a problem with performance. The fact that the task shows a progress bar at all is likely because at some point the task would complete synchronously and without a progress bar in say 10 seconds or 60 minutes. In that case, the programmer mistake was to allow the problematic performance of the program affect the responsiveness of the program. So a progress bar is used when the performance can't be easily fixed but the program must be responsive.
- hoorayimhelping 7y ago
  You can make a UI feel responsive even if the underlying system is not performant. Let's say you have a client app with checkbox that toggles some boolean variable that communicates with a server. If you're on a 3g connection in an ambulance, it might take a few seconds to send that request to the server and get a response back. An unresponsive UI would sit there and make you wait for the request/response to complete. You click the checkbox, then nothing happens, then suddenly, some time later, the checkbox is checked and the page refreshes, or a state change happens. It's jarring and weird. A responsive UI would update the state of the app based on the user's actions even if the request hasn't completed yet. Tightly related to this the concept of optimistic UIs - the UI acts optimistically and updates the state of the app under the assumption that server-backed state changes will work. The iPhone's messages app sending messages is the prototypical optimistic UI interaction. You send a message, the blue / green speech bubble shows up on your messages app while the message is in flight. If it succeeds, nothing changes and you're none the wiser. If it fails, you get an option to delete the message or resend.
  - wool_gather 7y ago
    Some (subtle) confirmation is nice, too, when the user is actively aware that the process is fallible. The Messages example you chose has this: a small gray "Delivered" tag is added below the message when the sending device hears back from the server.
  - mcguire 7y ago
    Ever used one of those product search forms where you click that you want to see products with attribute A, a check appears, you go on to click on attribute B and a check appears there, and then the product list updates showing attribute A with a complete loss of B? A responsive UI is necessary, but it's not sufficient to make up for a slow back end.

ziddoap 7y ago

Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

ChrisSD 7y ago
Because that's literally the complaint as given. If the UI had reacted "instantly" it would be more user friendly. Even if the performance of the (non UI) code was slower. EDIT: Or to put it another way: "perceived performance can be more important than actual performance".
- juliangoldsmith 7y ago
  Responsiveness is a result of adequate performance. The dropdowns that the article refers to are probably populated by a database, as opposed to being static. It doesn't matter if the dropdown opens instantly, what matters is that the information it contains is available.
0xDEFC0DE 7y ago
My take is that responsiveness has a cap of speed that’s pinned to human perception. Once you get here you can stop worrying about needing more. Performance does work as fast as possible regardless. You always want more but you’re capped by the system, hardware, and algorithms and not human perception. Feels like I’m splitting hairs though
- viraptor 7y ago
  No, that's a very good split :-) Even when responsiveness is great, you can still work on performance to improve: resources utilisation, energy usage, jitter of responsiveness, etc. Users may not notice, but the spending account may do. This distinction is more relevant with multi-user or time sharing systems, less so with single-user game consoles. (If you're hitting the right framerate at the most demanding scenes, why bother?)
BubRoss 7y ago
Responsiveness is about latency and feedback. Performance could mean that or it could mean throughput. If I'm using an interface I want responsive feedback without latency above everything else. I know it's easy to dump on electron, so I will. Multiple electron apps, especially the ethereum client, are the worst programs I have ever used, because there is enormous lag on a computer that runs everything else flawlessly. It's so bad it can't even be all blamed on electron, but more than bloat or memory use, interactivity is what I consider the most important factor in an interface. I even put it above great design or intuitiveness. I would take blender's ridiculous interface choices over something better that lags like the ethereum client any day of the week.
snaky 7y ago
Performance is about how it works, responsiveness is all about how it feels.
alkonaut 7y ago
If I click a button and it instantly shows me a dialog with a progress bar, and the progress bar progresses smoothly for one hour to complete the task, that is responsive (the UI responds to my click and the background update as quick as anyone could desire). That the task takes an hour to complete may or may not indicate a problem with performance. The fact that the task shows a progress bar at all is likely because at some point the task would complete synchronously and without a progress bar in say 10 seconds or 60 minutes. In that case, the programmer mistake was to allow the problematic performance of the program affect the responsiveness of the program. So a progress bar is used when the performance can't be easily fixed but the program must be responsive.
hoorayimhelping 7y ago
You can make a UI feel responsive even if the underlying system is not performant. Let's say you have a client app with checkbox that toggles some boolean variable that communicates with a server. If you're on a 3g connection in an ambulance, it might take a few seconds to send that request to the server and get a response back. An unresponsive UI would sit there and make you wait for the request/response to complete. You click the checkbox, then nothing happens, then suddenly, some time later, the checkbox is checked and the page refreshes, or a state change happens. It's jarring and weird. A responsive UI would update the state of the app based on the user's actions even if the request hasn't completed yet. Tightly related to this the concept of optimistic UIs - the UI acts optimistically and updates the state of the app under the assumption that server-backed state changes will work. The iPhone's messages app sending messages is the prototypical optimistic UI interaction. You send a message, the blue / green speech bubble shows up on your messages app while the message is in flight. If it succeeds, nothing changes and you're none the wiser. If it fails, you get an option to delete the message or resend.
- wool_gather 7y ago
  Some (subtle) confirmation is nice, too, when the user is actively aware that the process is fallible. The Messages example you chose has this: a small gray "Delivered" tag is added below the message when the sending device hears back from the server.
- mcguire 7y ago
  Ever used one of those product search forms where you click that you want to see products with attribute A, a check appears, you go on to click on attribute B and a check appears there, and then the product list updates showing attribute A with a complete loss of B? A responsive UI is necessary, but it's not sufficient to make up for a slow back end.