This is actually quite an important link. I spent a fair bit of time reminiscing last year when it first made the rounds. I am a FIRM believer that some things are “measurable”, some things are “perceptible” and obviously, some things are both.
The trick is when something is both but people think it is only the former (ie - measurable, as opposed to perceptible). I think, frequently, our input devices (be they keyboard, mouse, or other) are all assumed to be “good enough” and that differences between them is only measurable.
This chart is clear evidence to the contrary. In an area you’d be forgiven for expecting to have progressed only forward (ie, better), we have, in point of fact, regressed. This means that we actually now have cases where the user will feel the computer is less responsive than it should be or than it once was (ie, in eras past).
Reality is (and feel free to fight me on this one) that the PERCEPTION of lag in input devices has arguably more bearing on the users’s Impression of the responsiveness, speed, and general pleasantness of a device than anything else. Please realize that this is COMPLETELY different than whether that very same user would ever know that this was what was influencing them. In fact, I’d expect that the same people that might say “this computer SUCKS” or “this thing is just so SLOW” wouldn’t be able to (nor should they have to) express that this was largely because of slow input responsiveness.
This stuff matters. And it matters more than people give it credit for. Ironically it matters most, in some ways, to people that do not understand what something like “input lag” even is! Great post, great, important topic.
Truth is - we are in the world here of bluetooth devices. So even the best possible hardware responsiveness is now beholden to the bluetooth protocol. Waytools may be able to comment on how this compares to “best of class” hardware (ie, wired) keyboards. I don’t know the answer to that. I just know when my Logitech bluetooth keyboard is slow to respond, when either the computer, the keyboard, or both seem more interested in INSTANTLY going to sleep a nanosecond after I finish typing a paragraph just to save some battery life... it SUCKS.
This actually brings up a reasonable point, in my opinion.
@waytools - After general release, I’d like to heavily advocate for a few things in the TextBlade as well as whatever mouse pointing device you end up inventing.
It would be great in my opinion to give the user the ability to control the battery saving features of your devices. Maybe something like a slider to control when the device would try to “sleep” to save power, going from say “1 second after last input” to “ten minutes after last input”.
Might it be possible to do some sort of input “profiling” on the fly? To be clear, I’m talking about some means for the device to decide “this user is generally doing INFREQUENT input, so we can safely go to sleep a second or two after input stops”. Equally valid would be the ability for the device to say “wow, since we were turned on, we have never gone longer than ten seconds between inputs, so there is no reason to sleep at all right now....”. This could be done on the fly - I know my own keyboard habits vary depending on what I’m doing, for example. Also, maybe this could be done on a device specific basis? Something like “it appears that when this user is on Jump 2, they have only very sporadic input with lots of time in between (say a web browsing type of experience with a lot of time spent reading)” and also “it appears that this SAME USER, on Jump 3, almost never stops - they are mousing or using the keyboard continuously so there is no reason to ever go to sleep (perhaps this is a gaming session, for example)”.
I think many bluetooth hardware devices have some forms of these types of controls, but it would be good to explore the specific utility of the TextBlade and mouse devices that Waytools creates to see how well they handle these scenarios.