Apparently typing latency doesn't annoy me at all. I think I just queue up what I'm going to type "in my fingers"; it's a one-directional process, and in general I don't have to see the letters before I keep typing whatever is in my queue.
What does annoy me about user interface latency: when a page loads slowly, I try to click something, the layout changes at the last minute, and I end up clicking something else. That's an example of a full feedback loop where my actions aren't coming directly from me. They're dependent on what I'm seeing on the page.
Now, finally, why might input lag for keyboards be less frustrating than on tablets?
My theory is: because the keyboards themselves provide an important source of feedback. Namely: the tactile feedback when a key is pressed tells you that you did what you set out to do. At the very least it’s possible to feel whether something was pressed or not; experienced typists will also easily be able to tell whether it was the correct key or not. And thus you yourself are taken out of the equation as a potential source of error, removing any self-doubt while waiting for the screen to catch up with your action.
When you’re working on a tablet, you’re never provided with such tactile feedback, and are thus forced to wait for the lag to complete whether a mistake was made or not.
The search page on docs.python.org was like that until recently. You typed a search key, results started to appear, and then when the search was complete a line "Search finished, found xx pages" appeared above the results, pushing them all down at some difficult-to-predict point in time.
I feel you, once a control is displayed it should never move. To me the main offenders are autocomplete suggestions that continue to load on top after some fields were already displayed.
I thought the buttons at the top ("Fine", "Could be worse", ...) were survey answers. Nope, they are how you choose the input latency.
The "We're done here" button is only 200 ms, and "Surprise me" only goes up to 500 ms. I have experienced far worse and variable latencies over Windows Remote Desktop and SSH due to bad Internet connections - like multi-second delays. This demo pales in comparison to the real world.
I think the experience of annoyance would be very different if you are forced to "break your flow". E.g. if you need to correct some characters at the end or insert something in the middle of what you have already typed because then the feedback is much more important.
If I just keep typing typing typing without need to worry about correction, the annoyance is probably minimal. I could just ignore the latency, close my eyes, and keep typing, assuming I have really high touch-typing accuracy. (I know that's something I sometimes do when I face high latency in real usage.)
Maybe a better and more meaningful simulation is to show some random sentences that you have to read and type, and then randomly force you to make some corrections as you go along (e.g. suddenly change the last word from "their" to "they're"), to simulate you having mistyped something.
On my iPhone I find everything up to maybe 0.6 seconds to be just fine. Part of this may be being used to using SSH over VERY poor network connections.
I think the biggest frustration with latency is not the latency itself, but rather when latency is combined with the possibility that what you entered didn't register at all and the time pressure of having only 15 seconds of signal to submit your command - situations that often occur when using Internet based sessions in the wild.
The other source of annoyance is trying to "not crash the system". Often when a system presents high latency like this, I tend to consciously pay attention to how many "buffered" inputs I'm sending for fear of crashing something, and that self-throttling can get tiring.
Bonus points if this results in mis-clicking something dangerous or irreversible, like "delete", "cancel","post","send", "close", "exit without saving" or the like.
This page is super misleading at least in Safari on Mac. The latency number appears to actually be a minimum delay between each letter. 200ms latency should mean that each letter appears 200ms after you press the key. But if you type reasonably fast on the 200ms setting, the screen gets farther and farther behind the keyboard, to the point where I can end up waiting many seconds for the text to finish showing up after I'm done typing.
As a result, this is going to make moderate to high latencies look way, way worse than they really are.
Yep. What you describe would be the expected behavior over a high-latency, but otherwise unloaded, connection. However, I'm wondering now: In the case of an ssh session over someone's fully-loaded typical home Internet connection, might it be a mixture of both? Especially with buffer bloat and lacking any traffic shaping, can I expect that each individual packet (which can be reasonably mapped to a key press in interactive sessions) is queued right after the previous one? Assuming many many packets waiting for egress without any prioritization, when each keypress packet actually makes it out vs. any other will essentially be random, no?
Latency on a loaded connection can be really bad but it won’t be related to how fast you type unless the connection is really slow (like, early dial up modem slow).
When you press a key, it will take a while to see the result. Depending on how things are set up, your computer will either send all subsequent keypresses immediately while you’re waiting, or it will buffer then and then send them all together once you get the reply. Either way, you won’t get this long term buildup.
You need much larger variable latency range to be truly annoying.
I'm talking high enough that someone backspacing over a mistake will think that the interface didn't receive the input. So they do another backspace.
To get it just right you'd probably trigger the initial backspace callback immediately after the user types a 2nd backspace. Then wait a long time before triggering the 2nd backspace callback. Since the original problem character has been removed the user will most likely try to continue typing. Finally, update the queue of characters all at once-- starting with the 2nd backspace. Now the latency has caused a character right before the queue to get eaten.
This is how you cause people to throw their device against a wall.
Overzealous autocorrect has a similar effect. Apple has apparently decided that any editing in the vicinity of a word it considers misspelled is meant to replace that word. The other day, I tried to refer to a HN user by username and I must have accidentally overwritten it half a dozen times before managing to get my comment through the OS to be submitted.
For me nothing much changed up to "really not great" - only then did I start to notice the delay.
But "variable latency mode"? That made me more nostalgic than annoyed.
It was an instant flashback into the 90s, running Irssi in screen over SSH on a slow dial-up connection while downloading MP3s. Happily chatting away.
Funny you mention it. I posted a question about this on superuser. Its currently the second result when doing a google search on "visual studio input lag". The issue disappeared when running in single monitor mode, but I couldn't determine the root cause.
Readit News
What does annoy me about user interface latency: when a page loads slowly, I try to click something, the layout changes at the last minute, and I end up clicking something else. That's an example of a full feedback loop where my actions aren't coming directly from me. They're dependent on what I'm seeing on the page.
Now, finally, why might input lag for keyboards be less frustrating than on tablets?
My theory is: because the keyboards themselves provide an important source of feedback. Namely: the tactile feedback when a key is pressed tells you that you did what you set out to do. At the very least it’s possible to feel whether something was pressed or not; experienced typists will also easily be able to tell whether it was the correct key or not. And thus you yourself are taken out of the equation as a potential source of error, removing any self-doubt while waiting for the screen to catch up with your action.
When you’re working on a tablet, you’re never provided with such tactile feedback, and are thus forced to wait for the lag to complete whether a mistake was made or not.
http://www.remarkablyrestrained.com/keyboard-lag-and-frustra...
That is fixed now, and it is so much better.
The "We're done here" button is only 200 ms, and "Surprise me" only goes up to 500 ms. I have experienced far worse and variable latencies over Windows Remote Desktop and SSH due to bad Internet connections - like multi-second delays. This demo pales in comparison to the real world.
If I just keep typing typing typing without need to worry about correction, the annoyance is probably minimal. I could just ignore the latency, close my eyes, and keep typing, assuming I have really high touch-typing accuracy. (I know that's something I sometimes do when I face high latency in real usage.)
Maybe a better and more meaningful simulation is to show some random sentences that you have to read and type, and then randomly force you to make some corrections as you go along (e.g. suddenly change the last word from "their" to "they're"), to simulate you having mistyped something.
I think the biggest frustration with latency is not the latency itself, but rather when latency is combined with the possibility that what you entered didn't register at all and the time pressure of having only 15 seconds of signal to submit your command - situations that often occur when using Internet based sessions in the wild.
The other source of annoyance is trying to "not crash the system". Often when a system presents high latency like this, I tend to consciously pay attention to how many "buffered" inputs I'm sending for fear of crashing something, and that self-throttling can get tiring.
As a result, this is going to make moderate to high latencies look way, way worse than they really are.
When you press a key, it will take a while to see the result. Depending on how things are set up, your computer will either send all subsequent keypresses immediately while you’re waiting, or it will buffer then and then send them all together once you get the reply. Either way, you won’t get this long term buildup.
I'm talking high enough that someone backspacing over a mistake will think that the interface didn't receive the input. So they do another backspace.
To get it just right you'd probably trigger the initial backspace callback immediately after the user types a 2nd backspace. Then wait a long time before triggering the 2nd backspace callback. Since the original problem character has been removed the user will most likely try to continue typing. Finally, update the queue of characters all at once-- starting with the 2nd backspace. Now the latency has caused a character right before the queue to get eaten.
This is how you cause people to throw their device against a wall.
But "variable latency mode"? That made me more nostalgic than annoyed. It was an instant flashback into the 90s, running Irssi in screen over SSH on a slow dial-up connection while downloading MP3s. Happily chatting away.
Individual perceptions are weird.
https://superuser.com/questions/715607/improving-resolving-k...