The suggestion is to replace some of the Greek, mathematical, and other symbols on the Opted layout on iPhone with standard punctuation characters, so, for example, you don’t need Opt and Shift to get the secondary symbols under K and L in the US English layout.

Thank you F Hiew for your analysis and suggestions, as well as others who have taken the time to write before. We will try to address some of this in the next release but one. (The next release is coming out later this month and has many improvements but in different areas.)

Word swipe in PadKeys is good enough for many users and certainly better than keyboards such as the system default that don’t have it at all. It also needs to be understood it will always seem worse than other keyboards on the same device simply because the keys are smaller.

We continue to work on improving word swipe incrementally. The next release will bring significant improvement in certain respects, and we will not stop there.

Please vote for this issue if it is important to you, so we can prioritize accordingly.

Thank you for the feedback so far. Adding some specifics like device and language could help us better understand if swipe is working more poorly for some use cases than others. But even better would be to send a short video snippet.

Well, some people DO like having the forward delete, but it’s not for everyone so we have thought about making that a customizable key. But for now we’ve been holding off in the name of keeping things simple.

As far as the shortcut bar, we are unfortunately not able to access or turn on/off Apple’s own shortcut bar. However in the next PadKeys version we will be including undo, redo, and paste buttons in our own suggestions bar. We hope this will make it more feasible for iOS 9 users to turn the Apple shortcut bar off completely to gain the extra space. (And of course iOS 8 users will benefit from the functionality which isn’t available at all otherwise.)

The problem you mention is an annoying one. But I’m not sure about solving it by taking up a slot on the suggestions row for (typed) or “typed” every time there is an auto-suggestion. The constant presence of that item is one of the things I hate about other keyboards. Is there any other way we could address this issue?

As far as breaking a link by hitting 'x', the link is just as easily restored by selecting the choice manually the next time it is presented. All of this could be made more sophisticated of course, but it hopefully suffices to not be TOO annoying. :-)

This sounds pretty good, at least for the 'X'. Tapping other suggestions besides the blue one will already affect the future presentation of choices, just not in the drastic all-or-none way the 'X' does. So I'm not sure if it would be beneficial to change the behavior for all taps.

Thank you for the suggestion. It makes sense and we will schedule it for a future release.

(I hadn’t realized third-party keyboards did things this way, probably because it’s difficult to end up in the middle of a word without cursor keys.)

UPDATE: We haven’t implemented this yet mainly because we haven’t found any other keyboards / autocorrect implementations that work this way, and we’re worried it will clash with most users’ expectations. If anyone has any examples to point out to us, that might help. Thanks!

Hmm, maybe that's an iOS 9 change? As I posted before system keyboard when I tried it did not work this way. (I do know some keyboards, like Windows Phone, operate this way if you select the entire word you want to correct, but unfortunately third-party keyboards are not given information about the selection contents.)

Actually, I just tried SwiftKey and the iOS system keyboard and they operate the same way PadKeys does ("splitting" the word). Can you let us know which 3rd party keyboard(s) with which you've seen the behavior you describe? I would like to see how it works.

We’re interested to hear more feedback on this, but… One of the main motivations behind PadKeys is to avoid the need for learning special layouts. The thought is that the advantages of having those keys available without Shift is actually outweighed by the hesitations caused by having a different layout from the one present in hardware keyboards everywhere.

Even something that may seem an obvious win like a “.com” key, which saves 3 keystrokes when typing in a URL, is of unclear benefit when you have to stop and hunt around for it, it takes up space that could be used for making larger letter keys, and it doesn’t help when typing in .de, .net, .org, or the site name itself.

Of course, none of these arguments hold for users more used to phones than regular computers. But PadKeys is not trying to be a keyboard for everyone, but to fill a perceived gap in the choices that were out there.

Hi,

We’re interested to hear more feedback on this, but… One of the main motivations behind PadKeys is to avoid the need for learning special layouts. The thought is that the advantages of having those keys available without Shift is actually outweighed by the hesitations caused by having a different layout from the one present in hardware keyboards everywhere.

Even something that may seem an obvious win like a “.com” key, which saves 3 keystrokes when typing in a URL, is of unclear benefit when you have to stop and hunt around for it, it takes up space that could be used for making larger letter keys, and it doesn’t help when typing in .de, .net, .org, or the site name itself.

Of course, none of these arguments hold for users more used to phones than regular computers. But PadKeys is not trying to be a keyboard for everyone,…

Thanks for these comments. We will consider the forward-delete / opt flip, although the opt is matching the position on Macbook keyboards and the symmetry of forward delete opposite backward delete is nice. Another option might be to remove that key and make shift-delete to it, though that's not particularly standard.

Speaking of standard, yes the opt maps are funky, but again we're just following Apple computer keyboards here, rather than trying to forge our own path. It's hard to know what people are used to and what can be freely optimized, so we took the path of following the existing example.

Shift to operate by words is another one of those expectation things. Normally one would hope that would create / extend the selection, but Apple's APIs don't let us do that anyway, of course...