no, no, no ...
This is a feature.
The iPad's soft keyboard has been caught failing to pass key presses to applications, introducing errors and letting the typist take the fall. The iPad's on-screen keyboard indicates a successful press by turning the key grey, but Reg reader Dave Addey filmed his typing in slow motion and established that a decent proportion …
This is a feature.
Actually it is made on purpose (i.e. a feature), and I've just tested it.
Press any of the keys, it turns grey, now keep holding down your finger and slide over to a neighbouring key. Now release it. The whole key press is ignored.
You need to press *and release* the virtual key while your finger is still over it for it to be passed on the application.
That's what's happening in the video, he's typing quickly and moving to the next key without raising the finger enough from the previous press.
This may be some feature to avoid spurious keypresses.
It's not just "to avoid spurious keypresses", it's the way the whole iOS works!
You press something, but then notice it's not what you wanted - by seeing the wrong thing turning grey - so you just slide the finger off and it's not registered.
It's iOS's cancellation action. Works like that for all UI buttons.
I think this is supported by the fact that the very same two mistakes are made in the short passage: "I have" twice comes out as "iave", though the first one is corrected to "image".
It should behave like one.
We've had n-key rollover since the early eighties in keyboards. Perhaps someone has a patent on it that Apple cant buy and refuses to pay for.
My android-based phone behaves similarly. Also, on regular computers, decades ago, i learned that if I click something inadvertently, I could just hold the press, and drag it off in any directionand then release, and that way that click and release would not register as a normal click and release.
I thought it was a flaw or an annoyance, and then it became second nature.
But, in my HTC EVO 4G, a REAL annoyance (which I don't know about in iOS) is when a phone call is being detected by my phone and suddenly while typing text messages, i get crappy laggy response, jittery/frozen keyboard action. If surfing, sometimes the screen/page will fail to stretch, of stop in mid-stretch.
Lately, the dolphin browser would just crash for no apparent reason (it doesn't even do the "oops" recovery thing anymore).
So, I suspect, as you do, PA, that this really is a feature. I don't know whether it's pointed out in the user manual or any iOS for Dummies books, but if not, it should be told (in books and in the UI and in How-Tos, etc.), not be found as an easter egg thing.
Watching Buddy's slo-mo two-finger typing, one can see that he is occasionally still pressing one 'key' with his right digit while hitting the next 'key' with his left.
Also, the AutoCorrect gave several reasonable choices before settling on "image" in the first line. I have heard many people blame AutoCorrect for mistakes when, instead of taking a half a moment to select the appropriate choice offered,they have just plodded on hoping that their device somehow knows which of a dozen similar words they had intended to type.
I don't want that bloody device to offer me anything. I just want it to let me type what I want, damn it!
I had a brutal contact with this idiotic feature when I tried to add a contact on my shiny new dumb phone. I had to fight with it every time I wanted to add a letter. I managed to get rid of this very "helpful" feature but that was not that easy thanks to an obscure settings menu.
Progress is good but I'm currently tri-lingual and switching to any of the three languages prior to typing anything is not funny. Believe me, there is nothing more stupid than a phone trying to be smart.
If so, it's a feature that introduces mistypes. So either the UI is well-designed, but poorly implemented (dropping registered keypresses) or it's well implemented but poorly designed (using button-like behaviour for a keyboard). In any case it makes the device less usable so it IS a flaw in my opinion. The difference between Apple's view and mine is that I somehow came to expect the device I use to behave as I want it to, whereas Apple expects the user to behave as the device requires them to ("you're holding it wrong", anyone?). Then again, as one commenter in the original article pointed out, the problem disappears when you use a 3rd-party virtual keyboard so that's "not that big of a deal", as someone would say. It would also suggest that the "problem" -be it a deliberate choice or a technical flaw- resides with Apple's own keyboard. The button-like behaviour (if that's the reason) is probably aimed at the keyboard-impaired, who are no doubt the core market for a virtual touchscreen keyboard. It should still be possible to switch between button- and keyboard-like behaviours, in my opinion, but that would be giving the user a choice. It might be confusing for most, frightening even; Apple's motto always have been "don't confuse users by giving them a choice". Not always without merit; it certainly worked well for them to date.
The keyboard should behave like a keyboard. Period.
That means letting the user create typos because they pressed the wrong key, not assuming that a tiny slide of the finger is indicating the user's desire to cancel their keypress.
Just consider the number of times you type something and wish you could take back that last keypress because you hit the wrong key. In my case, it happens about once every 1,000 characters, and it's easily corrected within a second or two.
If normal keyboard behavior had been in effect, then the video would reflect 3 typos, as made by the typist, not 20 typos, 8 auto-corrected, that will take many more seconds to correct, providing the UI lets them be corrected and doesn't continue to introduce typos on his behalf.
While most Apple consumers might be too clumsy to hit the characters they intend to hit, most of the rest of the world doesn't have that particular developmental issue, or has the ability to recognize and repair their own fat-finger typos.
Its perfectly simple ... bad UI engineering. Period.
But Pierre, as you ALWAYS say in your comments you'd never buy Apple anyway. Not surprised you don't agree with Apple's view on this occasion.
However if - after hell froze over - you'd consider the alternative option, accepting all keypresses, maybe you'd find that on a capacitative screen it would introduce even more mistypes, the worse kind of mistypes because autocorrect works best with missing letters, not lots of extra ones.
But no, that's would be agreeing with an Apple design decision and obviously that's not an option for you.
The good news is this won't ever be a problem for you. Just stick to your UUCP and your text terminal (hopefully VT100 compatible, I recommend the Digital VT220) and you'll be fine.
>But Pierre, as you ALWAYS say in your comments you'd never buy Apple anyway. Not surprised you don't agree with Apple's view on this occasion.
I never say never, and the main reason why I don't buy Apple is that their kit is overpriced. I still get to play a lot with their stuff, as the missus is -would you believe it- a fangirl.
>on a capacitative screen it would introduce even more mistypes
Probably not, no. As I mention, at least one person solved the problem by using a 3rd-party virtual keyboard.
>autocorrect works best with missing letters, not lots of extra ones.
In any case, autocorrect is a pain in the nether regions for people who know more than 500 words. And as soon as you're multilingual it is completely unusable. Most people I know have it turned off at all time.
>But no, that's would be agreeing with an Apple design decision and obviously that's not an option for you.
I actually agree with most of Apple's design decisions. They are good at design, there's no denying that.
>Just stick to your UUCP and your text terminal
Will do. I still need a graphical workstation for the final steps of my image processing workflow though. I am looking at a NeXTcube, I hear they dropped in price a bit.
> Probably not, no. As I mention, at least one person solved the problem by using a 3rd-party virtual keyboard.
> 
So a comment in a blog claiming he solved the problem using a 3rd party virtual keyboard is sufficient proof for you, even when the keyboard he mentions has terrible reviews.
However you need a citation when another comment says autocorrect works better at fixing missing letters rather than extraneous ones? Bit of a biased double standard there. But I suggest you give it a try on your missus's iDevice.
ps: You don't really want an old NeXTCube, get an old Sun workstation instead. They're clearly better for your graphical requirements, albeit noisier. Most Sun keyboards are superb too.
That’s certainly a possibility, and it’s something I’d considered during my testing. The behaviour you describe is the standard UIButton control behaviour on iOS, and it may be that the on-screen keyboard is made up of a set of UIButtons. However, this button-like behaviour – sliding off a key to negate a keypress – wouldn’t be appropriate for fast typing, which is much more about the initial impact on a key, rather than the subsequent movement.
If this *is* the cause of the missed keypresses, then it’s a mistake to use this kind of touch handling approach on a keyboard. Unlike a considered button press, typing is all about moving speedily around the keyboard. To put it anther way: if every keypress registered on the keyboard in my video *had* been used, my document would have had fewer mistakes.
Unfortunately, without a high-framerate video camera, it’s very hard for me to find out if this is the likely cause. Personally I’m not convinced – my typing style is very pecky – but it’s certainly worth considering.
In Pages, if you press D, slide off to F and hold F for a few seconds then release, you get a D registered. If you do the same but much more quickly then you get no key registered. This suggests to me that it is an anti-typo feature, not a 'cancellation' feature.
The same happens in other apps but, strangely, the minimum delay varies. In the Google search bar in Safari, for example, the delay period is very short compared with Pages.
>So a comment in a blog claiming he solved the problem using a 3rd party virtual keyboard is sufficient proof for you, even when the keyboard he mentions has terrible reviews.
>However you need a citation when another comment says autocorrect works better at fixing missing letters rather than extraneous ones? Bit of a biased double standard there.
Ah nope. 1 citation vs zero, I still win. No double standard here.
i've actually found typing on my ipad to be pretty painless. not so easy to do while holding the thing (which itself has been helped by the ability to split the keyboard), but prop it up (using the case as a stand) and i can knock out a pretty decent speed / accuracy. Not as good as an old style keyboard, but that's not really that surprising. Is it?
Anecdotal evidence from one person Vs the opposite claims from someone in the comments.
Who to believe?!?
I like Anecdotal evidence from one person Vs the opposite claims from comments, but which is best?
There's only one way to find out...
A fight to the death?
Isn't it possible that this is a fault with this particular iPad?
If you're going to test something like this, you should at least perform it on a larger scale to rule out possible problems like that.
This is Apple and any excuse to knock 'em down must be taken. Don't bother with all that logical processes nonsense, the press will only clip all that out when they print anyway so why bother?!
Although I haven't waded through the video, if I'm reading the article and the summary right, the issue is that the hardware registers the screen press, the onscreen keyboard recognises the key activation, but the keypress isn't passed to the application.
So I don't think it can be a fault, except in the software.
Can someone with an iPad confirm - does the greying of the button that the author refers to happen when the key is lifted, or just when initially touched? Is the problem that the finger presses the key, but is sliding off before the press is lifted?
I've just had a go on my iPad and the greying occurs when you touch the key, rather than after lifting. I wasn't able to get my iPad to miss any keys, but it was only a quick test. I've definitely noticed missed keys in the past, but that's usually when there's something installing in the background and the key doesn't grey in those situations.
I did notice that if you touch a key and then slide your finger off it, it won't count that as a key press. This makes sense as touching a control then sliding your finger off it without releasing is the standard way of telling iOS you touched that control in error and don't want to complete the action.
So it's possible this guy is sliding his finger a bit too much before lifting off a key. Ideally he needs to film with two cameras, with the second one horizontal to the screen so we can see if he's sliding or lifting his fingers when it goes wrong. In some cases it did look like he might have dragged his finger a bit when it went wrong, but from the top-down perspective it's virtually impossible to tell.
Personally, I don't like typing on my iPad if I can help it. The lack of tactile feedback just makes it much slower to use, although I personally think the auto-correction is generally very good. It seems to get better with every major new iOS update and is getting scarily good at interpreting utter nonsense words into what I actually meant to type.
Better have them replaced.
Gummi Bears work well, apparently.
I always type with thumbs down. That can't be the answer
Well I hope you cleaned up afterwards.....
"El Reg contacted Apple, which had not responded at the time of publication"...
And unless a single recent communication is to be taken as a significant change to a long lasting policy, I expect we will have to wait until moments before the official news conference of the long awaited Ski-Resort Hell (complete with frozen over ice-skating rink) before El Reg receives a response from Apple on this topic!
Beat me to it...
If you read past articles hardly anyone ever replies to El Reg "at the time of publication". Reg hacks probably give it 5 minutes before posting the article.
The usual practice is to publish an update after.
If you read past articles, Apple _never_ reply to El Reg. Possibly because articles concerning Apple are not just parrotted press releases, but independently sourced and written, and Apple don't seem to like this, because it damages their reality distortion field.
Well that's false isn't it.
Apple has in fact replied on several occasions to The Register, including twice just in the last 30 days:
Replying to an article like this would need referral to Apple's engineering team and some investigation, like I said I doubt El Reg would wait the time necessary to get a proper answer.
"One can speculate that the keys are deliberately dropped to maintain the smooth performance of the iPad, or perhaps they're just lost in transit."
Or they are so brief they are considered to be "noise" beneath the threshold and thus dropped on purpose
Maybe some background into how capacitative screens work and how much filtering goes on would be of benefit to understand this.
But like any device you eventually get a feel for how reacts and adapt to that. I regularly type one page letters with far less errors than the example in the video, as the post above it gets to be pretty painless.
If they're so brief that the iDevice is ignoring them as noise then why does it highlight the pressed keys as normal?
Also, what are you typing your one-page letters on, a normal keyboard? There are only three errors made in that video and when using a touchscreen keyboard that offers no tactile feedback that seems to be a perfectly normal error rate.
Something like Carrier IQ?
Interesting anecdotal evidence. I would have thought that writing anything vaguely 'long form' would be better suited to a detachable keyboard, or a proper laptop, however others have not noticed the problem... Might just be the way he types.
If it really is because of the cramped screen, as mentioned in the article, one can only wonder what typing is like on a 7 inch screen tablet. A comparison would be interesting.
I don't have this sort of problem using the on-screen keyboard on my HTC Desire, where the individual keys are smaller than my fingertips, so I fail to see how a touchscreen that is an several times the size can have such problems purely attributable to the size.
Actually it's not as bad as you'd think. On my playbook I can touch type but I tend to use less fingers than with a real keyboard. On a real keyboard I can do 80+ wpm, on the playbook it's more like 20-30, no worse than on my Galaxy tab. I've never noticed a key press go missing on either, all errors are my own.
But touch keyboards are never going to be as good as a real keyboard. Not only is there no tactile feedback but it's also trivially easy to press the wrong key. And then we have the nonstandard layout from one device to another and the need to switch mode to get to numbers and symbols.
They are typing it the wrong way.
I was hoping no-one had posted "You're typing it wrong" yet.
It just wrks.
... "it just woks" myself. But then I think "wok" is a funny word anyway. Crazy word, crazy cookware.
Get a sense of humour, you boring cnts.
But the iPad users can't seem to get the press to register
Sorry cheap-shot, I know!
> Or they are so brief they are considered to be "noise" beneath the threshold and thus dropped on purpose
Then surely the device shouldn't have acknowledged them in the first place.
By acknowledge you mean changing the key's colour? Well yes, if it didn't change the colour right away it would give the impression that the UI was sluggish.
It's difficult to do both rejection and give real time feedback, compromises have to be made.
You really believe that providing immediate but occasionally inaccurate feedback to the user is preferable to providing them accurate but occasionally laggy feedback?
If the key colour is changing, this should only ever mean that the keypress has been accepted as valid and passed onto the underlying app, never that the system thinks you might have pressed the key but a split-second later decides that, oh no, actually you didn't.
That's of course your opinion. Maybe from a user interface perspective there's a good reason to grey the key before accepting it as valid and passed on. I'm not going to say either way without testing.
But the problem is actually another, as two posters in comments above already have found.
If you press the key it greys out, but if you then slide the finger off to the side without releasing it the whole keypress isn't recorded.
Not sure why it's done this way - again would need to test both approaches - but to me that explains what's being seen in the video.