-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update research reference to more current research #118
Comments
Thanks for noticing this, and for sharing the link. Sharing some of my own notes, in case others find useful... The research starts with a summary of previous findings which I find useful. There is more detail about how these studies compare. I especially find some of the conclusions from some of the "Recent Latency Guidelines" interesting -- e.g.
There are other sections that references multiple responses (both bimodal i.e. visual audio tactile, or simply initial feedback vs feedback after complex task completion). I think this matches our thinking in this space (i.e. distinguishing the very first/next paint after an interaction, from a potential largest/final update). I wanted to call out this result in particular, which I find is often cited as proof of more aggressive latency targets:
But then I'll contrast it to another finding from the same research:
In other words, while the overall guidelines seem quite aggressive (5-85ms range for appearing instantaneous), they still share overall findings that quality scores start to perceivably drop between the 150ms and 300ms thresholds. I at least hadn't read that distinction before. Some of the results for bimodal / tactile feedback are interesting and suggest very aggressive latency expectations. I wonder if this is is something that is at least partially handled at the O/S level. I.e. my device / virtual keyboard will automatically vibrate even if the keyboard handler has very high latency. There are findings that suggest more aggressive target latencies for continuous events (using a pen/stylus to "ink", or dragging with finger, or as I've read in other studies: using a mouse to pan screen in a video game). We should be careful to not mix these expectations with discrete events like taping a button, since perceived latencies are consistently higher there across studies. E.g.:
I think it is interesting to make a comparison between Performance and Perception:
And finally, some conclusions at the end:
I think this is very interesting-- however, I would be careful to apply a broad recommendation that has a latency target which is 2x more aggressive than is actually claimed perceptible to users. Interpreting conclusions:
and
The evidence provided in this paper (and all the referenced research) is incredibly useful and interesting. However, a point I am left with is that: 100ms as a broad target remains fairly consistent, even in modern studies. The more aggressive requirements are typically limited to specific populations or specific use cases. For Event Timing, and the Responsiveness metrics we make measure it (FID & the new experimental responsiveness metric), we are self-selecting for use cases that fall far closer to that broad category (i.e. discrete input only, heavily focused on visual feedback, typical web-platform UX use cases). |
@yoavweiss I'll to see if I can get to it and issue a PR (assuming we agree the new link is better). |
@nhelfman, has there been any work towards a PR? |
Research link in https://w3c.github.io/event-timing/#sec-intro points to relatively old research from Miller 1968 and Card 1991.
A more recent paper from 2017 covers additional research (on top of the one mentioned) can be linked to provide more weight and details to the latency guidelines.
https://link.springer.com/chapter/10.1007/978-3-319-58475-1_1
I propose updating the research link.
The text was updated successfully, but these errors were encountered: