3 ms·

The F1166 standard permits up to 250ms latency for touch screen response. That is ridiculously high. It practically guarantees people will think it's not workin

by mrob 2y ago

The F1166 standard permits up to 250ms latency for touch screen response. That is ridiculously high. It practically guarantees people will think it's not working and tap again, undoing any toggle function they might have activated. They won't necessarily notice their mistake. I once accidentally ran a washing machine at 90C temperature because of high-latency touch controls. I instinctively double-pressed the touch surface to reduce temperature because I thought the first touch hadn't registered, causing it to wrap around back to maximum. It did some minor damage to the clothes before I noticed. And that was with more like 200ms latency, not 250ms. Latency on touchscreens is more important than with physical controls because there's no tactile feedback. Even 10ms is obviously imperfect for drag controls. Microsoft Research published a demonstration video: https://youtube.com/watch?v=vOvQCPLkPt4 https://youtube.com/watch?v=vOvQCPLkPt4

kryogen1c 2y ago
> permits up to 250ms latency for touch screen response. That is ridiculously high. It practically guarantees people will think it's not working and tap again You're saying people evaluate and react to checkbox feedback faster than 4 times/sec? I'm not a UX person so this claim seems laughable. I might believe twice that as beyond reasonable, but there is no way the average person waits less than a quarter of a second before assuming their input failed and duplicate the effort. One can hardly even observe and process that quickly - even when paying attention.
- the__alchemist 2y ago
  250ms is significant in this context, and is a longer period than you evidently think.
  - vsuperpower2021 2y ago
    The user is either a web developer or has some neurological disorder that dulls his ability to react. There's no other explanation for not knowing how long 250 ms is.
- mrob 2y ago
  Your actions are pipelined. The waiting happens in parallel with doing the next action. The 250ms delay causes a timeout exception and flushes the pipeline.
- danielvf 2y ago
  Imagine you have a system that ignores taps a substantial percentage of the time (either because it required more precise finger placement, or because that's life). Also most successful taps complete quickly, with only some having 250ms latency. Combine these two and most of time when nothing has happened after 250ms, it's because the tap failed to register and a new tap attempt is needed. There's been plenty of research for decades showing that 250ms response time in UX is a noticeable slowdown.
  - maicro 2y ago
    I had a similar comment so I'll just add-on here - jitter definitely is a huge issue. If an interface is _consistently_ slow you know to slow down, space out actions and wait for visual confirmations; if an interface is generally responsive, though, you can get into a "rhythm" of actions which, which can lead to chaos and confusion as you try to figure out both the new state of the system, and what actions you need to take to get back on track.
    - QuercusMax 2y ago
      This is exactly what triggered the Therac-25 radiation therapy defect: the UI was very slow to update, but experienced users knew what order to hit the buttons to go through the screens quickly. Except that there was a bug where if you go too quickly, some of the software safety interlocks didn't work right, and they had removed the hardware safeties in the update from Therac-20.
  - NoMoreNicksLeft 2y ago
    What's the latest research show for a reasonable latency for something like this, anyone know?
    - shepherdjerred 2y ago
      https://www.semanticscholar.org/paper/How-Much-Faster-is-Fast-Enough%3A-User-Perception-of-Deber-Jota/cd4c54600245f906667d469b02ed551350ee64ff https://www.semanticscholar.org/paper/How-Much-Faster-is-Fas...
- kurthr 2y ago
  As someone with long industry experience, I share your disbelief. I'd need to see the Fitts tests results for 250ms max delay (<150ms median?) on button state, as long press is also a thing. On touch/trackpads typical double tap rate is 4-5Hz and maximum tap rate is about 10-15Hz, achievable by relatively few. It's notable that you're dealing with a touchscreen here and not a mouse (people are faster at that). Most premium Android phones in 2016 were 120-30ms motion-photon response time (low to midrange probably hit 250), while iPhones were ~80ms. Haptics add another ~30ms delay. There have been massive improvements since 2016, as it has been a competitive metric, but even with >120Hz screens sub 60ms max true latency is uncommon. As (actually my long term memory of) the MS video shows faster refresh and lower latency greatly improve smoothness and are useful for moving objects, especially scrolling (though tearing is a real issue). The problem is much more pronounced in VR/MR as eye tracking of diagonal motion is VERY discriminating. That's why they shoot for >240Hz refresh rates. Over 1kHz there doesn't seem to be a lot of improvement (2ms latency) due to a combination of cone/rod/neural filtering. If you want a very generic worst case latency calculation based on the touch acquisition rate and display refresh rate assuming no position calculation delay it is: Latency = 2/Ftouch + 2/Fdispl = 2/16Hz + 2/16Hz = 250ms
  - mrob 2y ago
    Comparing latency with maximum tap rate is the same kind of fallacy as comparing it with reaction time.
    - kurthr 2y ago
      "It practically guarantees people will think it's not working and tap again" Please provide a link to your data and analysis. Seriously, I hope you don't work for a major touchscreen supplier. A good UI can deal with relatively high latency input, a bad UI can make any latency unusable. Finger motion before/after contact and rapid high force contact bounces are common problems. Many high performance interfaces "gracefully" degrade report latency to similar levels under high interference conditions.
      - mrob 2y ago
- dialup_sounds 2y ago
  250ms definitely noticable, even when touch typing a continuous input, not just a single tap: https://input-delay.glitch.me/ https://input-delay.glitch.me/
- deleted 2y ago
  [deleted]
stonemetal12 2y ago
In electrical engineering there is the concept of "bounce" where IO, i.e. switches sensors whatever, are in a state of close to change, they can bounce back and forth between on and off. When writing controls for them you have to debounce, that is wait for the signal to switch from off to on for say 10ms before you act on the transition. When dealing with users, and slow processes (that you can't make faster for some reason), it is often necessary to "debounce" user input. Whether that is graying out a button, displaying a loading popup, or something else is entirely situation dependent. Whatever you choose, you should be preventing people from annoyance clicking their way into trouble. The amount of software that doesn't seem to get that is rather surprising.
- mrob 2y ago
  >wait for the signal to switch from off to on for say 10ms before you act on the transition That is the worst way to debounce, because it adds 10ms latency for no good reason. The better way is to act immediately but ignore further inputs for 10ms. You might also want a little bit of analog filtering to improve EMI tolerance, but that shouldn't add more than 1ms latency.
  - stonemetal12 2y ago
    Yeah, I probably should have put it your way. It gels better with the next paragraph about ignoring user input for some amount of time after the initial signal.
  - appplication 2y ago
    It depends on the application. If you wanted to debounce, for example, user autocomplete inputs that will be fed as a search term into your service, generally you would not want to start returning results when a user types the first letter “a” and continues typing, but instead wait for the user to stop typing for a fraction of a second. If you have exceptional resources you may choose to not debounce at all, but for applications with latency behind it, it can make more sense to just wait for the user to signal they are done.
- kryogen1c 2y ago
manarth 2y ago
User-input speed vs system-interpretation speed is a decades-long problem with a history of incidents and warning signs. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25
LeifCarrotson 2y ago
I work in industrial automation, and the amount of polling and high-latency touchscreen issues I encounter is embarrassing. The default latency of a Rockwell Panelview Plus screen with their FactoryTalk software (the dominant HMI system in North America for custom automation) is 1000 ms. Fixing that solves 80% of the complaints I encounter. https://i.imgur.com/gEBAA28.png https://i.imgur.com/gEBAA28.png (Unfortunately, it's a dropdown selection list with a limited set of values of 0.05, 0.1, 0.25, 0.5, 1, 2, 5, 10, 60, and a whopping 120 seconds). > Maximum Tag Update Rate: Specify the maximum rate at which data servers will send data to the tags used in the display, including tags used in expressions and embedded variables. The default update rate is 1.0 second`.[sic] If the update rate is changed, the new rate will not take effect until the display is closed and re-opened. And it's worse than that - often, response time is on the order of 3 seconds, as described here: https://theautomationblog.com/when-factorytalk-view-displays-are-slow-to-update/ https://theautomationblog.com/when-factorytalk-view-displays... > Well, if you press the button just after the update occurs, you’ll have nearly a whole second go by until it’s read. And once it’s read and sent to the PLC, you’ll then have close to another second until the screen updates again to indicate its on. I set most of my displays to 0.25 seconds or 0.1 seconds if I can, 50ms is not achievable because Rockwell's Ethernet/IP fieldbus protocol is terribly inefficient and the update rate is a polled refresh of every tag on the screen, you can't have fast buttons and slow production history string arrays.
QuercusMax 2y ago
I have a Hario coffee scale that is absolutely maddening. It works just fine, but gives absolutely no feedback (no flash, no beep, nothing) when you press the 'tare' button, and it also waits about a second before updating its display. The button itself doesn't have any tactile feedback either - one of those membrane-type buttons that seems to have a pressure sensor, but no 'click'.

by mrob 2y ago

kryogen1c 2y ago

> permits up to 250ms latency for touch screen response. That is ridiculously high. It practically guarantees people will think it's not working and tap again You're saying people evaluate and react to checkbox feedback faster than 4 times/sec? I'm not a UX person so this claim seems laughable. I might believe twice that as beyond reasonable, but there is no way the average person waits less than a quarter of a second before assuming their input failed and duplicate the effort. One can hardly even observe and process that quickly - even when paying attention.

the__alchemist 2y ago
250ms is significant in this context, and is a longer period than you evidently think.
- vsuperpower2021 2y ago
  The user is either a web developer or has some neurological disorder that dulls his ability to react. There's no other explanation for not knowing how long 250 ms is.
mrob 2y ago
Your actions are pipelined. The waiting happens in parallel with doing the next action. The 250ms delay causes a timeout exception and flushes the pipeline.
danielvf 2y ago
Imagine you have a system that ignores taps a substantial percentage of the time (either because it required more precise finger placement, or because that's life). Also most successful taps complete quickly, with only some having 250ms latency. Combine these two and most of time when nothing has happened after 250ms, it's because the tap failed to register and a new tap attempt is needed. There's been plenty of research for decades showing that 250ms response time in UX is a noticeable slowdown.
- maicro 2y ago
  I had a similar comment so I'll just add-on here - jitter definitely is a huge issue. If an interface is _consistently_ slow you know to slow down, space out actions and wait for visual confirmations; if an interface is generally responsive, though, you can get into a "rhythm" of actions which, which can lead to chaos and confusion as you try to figure out both the new state of the system, and what actions you need to take to get back on track.
  - QuercusMax 2y ago
    This is exactly what triggered the Therac-25 radiation therapy defect: the UI was very slow to update, but experienced users knew what order to hit the buttons to go through the screens quickly. Except that there was a bug where if you go too quickly, some of the software safety interlocks didn't work right, and they had removed the hardware safeties in the update from Therac-20.
- NoMoreNicksLeft 2y ago
  What's the latest research show for a reasonable latency for something like this, anyone know?
  - shepherdjerred 2y ago
    https://www.semanticscholar.org/paper/How-Much-Faster-is-Fast-Enough%3A-User-Perception-of-Deber-Jota/cd4c54600245f906667d469b02ed551350ee64ff https://www.semanticscholar.org/paper/How-Much-Faster-is-Fas...
kurthr 2y ago
As someone with long industry experience, I share your disbelief. I'd need to see the Fitts tests results for 250ms max delay (<150ms median?) on button state, as long press is also a thing. On touch/trackpads typical double tap rate is 4-5Hz and maximum tap rate is about 10-15Hz, achievable by relatively few. It's notable that you're dealing with a touchscreen here and not a mouse (people are faster at that). Most premium Android phones in 2016 were 120-30ms motion-photon response time (low to midrange probably hit 250), while iPhones were ~80ms. Haptics add another ~30ms delay. There have been massive improvements since 2016, as it has been a competitive metric, but even with >120Hz screens sub 60ms max true latency is uncommon. As (actually my long term memory of) the MS video shows faster refresh and lower latency greatly improve smoothness and are useful for moving objects, especially scrolling (though tearing is a real issue). The problem is much more pronounced in VR/MR as eye tracking of diagonal motion is VERY discriminating. That's why they shoot for >240Hz refresh rates. Over 1kHz there doesn't seem to be a lot of improvement (2ms latency) due to a combination of cone/rod/neural filtering. If you want a very generic worst case latency calculation based on the touch acquisition rate and display refresh rate assuming no position calculation delay it is: Latency = 2/Ftouch + 2/Fdispl = 2/16Hz + 2/16Hz = 250ms
- mrob 2y ago
  Comparing latency with maximum tap rate is the same kind of fallacy as comparing it with reaction time.
  - kurthr 2y ago
    "It practically guarantees people will think it's not working and tap again" Please provide a link to your data and analysis. Seriously, I hope you don't work for a major touchscreen supplier. A good UI can deal with relatively high latency input, a bad UI can make any latency unusable. Finger motion before/after contact and rapid high force contact bounces are common problems. Many high performance interfaces "gracefully" degrade report latency to similar levels under high interference conditions.
    - mrob 2y ago
dialup_sounds 2y ago
250ms definitely noticable, even when touch typing a continuous input, not just a single tap: https://input-delay.glitch.me/ https://input-delay.glitch.me/
deleted 2y ago
[deleted]

stonemetal12 2y ago

In electrical engineering there is the concept of "bounce" where IO, i.e. switches sensors whatever, are in a state of close to change, they can bounce back and forth between on and off. When writing controls for them you have to debounce, that is wait for the signal to switch from off to on for say 10ms before you act on the transition. When dealing with users, and slow processes (that you can't make faster for some reason), it is often necessary to "debounce" user input. Whether that is graying out a button, displaying a loading popup, or something else is entirely situation dependent. Whatever you choose, you should be preventing people from annoyance clicking their way into trouble. The amount of software that doesn't seem to get that is rather surprising.

mrob 2y ago
>wait for the signal to switch from off to on for say 10ms before you act on the transition That is the worst way to debounce, because it adds 10ms latency for no good reason. The better way is to act immediately but ignore further inputs for 10ms. You might also want a little bit of analog filtering to improve EMI tolerance, but that shouldn't add more than 1ms latency.
- stonemetal12 2y ago
  Yeah, I probably should have put it your way. It gels better with the next paragraph about ignoring user input for some amount of time after the initial signal.
- appplication 2y ago
  It depends on the application. If you wanted to debounce, for example, user autocomplete inputs that will be fed as a search term into your service, generally you would not want to start returning results when a user types the first letter “a” and continues typing, but instead wait for the user to stop typing for a fraction of a second. If you have exceptional resources you may choose to not debounce at all, but for applications with latency behind it, it can make more sense to just wait for the user to signal they are done.
kryogen1c 2y ago

manarth 2y ago

User-input speed vs system-interpretation speed is a decades-long problem with a history of incidents and warning signs. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25

LeifCarrotson 2y ago

I work in industrial automation, and the amount of polling and high-latency touchscreen issues I encounter is embarrassing. The default latency of a Rockwell Panelview Plus screen with their FactoryTalk software (the dominant HMI system in North America for custom automation) is 1000 ms. Fixing that solves 80% of the complaints I encounter. https://i.imgur.com/gEBAA28.png https://i.imgur.com/gEBAA28.png (Unfortunately, it's a dropdown selection list with a limited set of values of 0.05, 0.1, 0.25, 0.5, 1, 2, 5, 10, 60, and a whopping 120 seconds). > Maximum Tag Update Rate: Specify the maximum rate at which data servers will send data to the tags used in the display, including tags used in expressions and embedded variables. The default update rate is 1.0 second`.[sic] If the update rate is changed, the new rate will not take effect until the display is closed and re-opened. And it's worse than that - often, response time is on the order of 3 seconds, as described here: https://theautomationblog.com/when-factorytalk-view-displays-are-slow-to-update/ https://theautomationblog.com/when-factorytalk-view-displays... > Well, if you press the button just after the update occurs, you’ll have nearly a whole second go by until it’s read. And once it’s read and sent to the PLC, you’ll then have close to another second until the screen updates again to indicate its on. I set most of my displays to 0.25 seconds or 0.1 seconds if I can, 50ms is not achievable because Rockwell's Ethernet/IP fieldbus protocol is terribly inefficient and the update rate is a polled refresh of every tag on the screen, you can't have fast buttons and slow production history string arrays.

QuercusMax 2y ago

I have a Hario coffee scale that is absolutely maddening. It works just fine, but gives absolutely no feedback (no flash, no beep, nothing) when you press the 'tare' button, and it also waits about a second before updating its display. The button itself doesn't have any tactile feedback either - one of those membrane-type buttons that seems to have a pressure sensor, but no 'click'.