AdminTypefinity
(Support, Typefinity)
My feedback
6 results found
-
2 votes
An error occurred while saving the comment An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
Thanks for your feedback. Do you have any thoughts on potential symbols to remove in order to add this one?
AdminTypefinity
(Support, Typefinity)
shared this idea
·
-
1 vote
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
We have made some changes in the latest release and the frequency should be reduced. We will be working with Apple engineering to get more information about what we can do to eliminate these crashes completely.
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
The kill by launchd for a keyboard extension usually means it has taken too long to launch. Do you notice a pause when this happens, before the system keyboard appears? We've seen such logs ourselves as well and gotten other reports, but we haven't been able to track down the root cause. Usually the UI construction and all other init happen in 2-300 msec. Possibly this occurs when the CPU is saturated by other processes.
-
10 votes
Hi, putting this idea on the forum so we can find out how many people prefer the backspace in one place or the other.
Currently it is in the top row. GOOD because it’s like other (non-phone) keyboards and allows the punctuation keys to be in their normal places. BAD because it makes backspace harder to hit and the keyboard is harder to get used to from other phone keyboards.
We could move it to the bottom row. GOOD because it’s like phone keyboards that people are used to, and allows the backspace to be easily hit. BAD because it’s different from standard keyboards and would move the punctuation keys to a strange, hard-to-hit place.
If opinions are split we might consider making it an option, but options make the keyboard more complicated to configure (and many users never open Settings) and to maintain.
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
We can see many users interested in this and will continue to try to find a way. We will not remove the cursor keys (even optionally) to support this, and in your proposal either the backspace will have to be too narrow (only width of one of the punctuation keys) or both will need to be moved to the top row, which is already crowded. And we need to solve this problem for all 22 layouts.
AdminTypefinity
(Support, Typefinity)
shared this idea
·
-
25 votes
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.
It IS relatively sensitive to the first and last keys touched, so if you hit these accurately, the results will be better.
We continue to work on improving word swipe incrementally. Please vote for this issue if it is important to you, so we can prioritize accordingly.
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
We added context-based word prediction in Typefinity 1.8. These predictions are also used to constrain both swipe and autocorrect suggestions, so some improvement will be seen there.
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
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.
https://support.apple.com/en-us/HT207935
Feel free to post it here or open a ticket and send it privately. It would really help us zoom in on where the problems are. Thanks!
-
3 votes
Update:
What about adding long-press of the ‘X’ causes the suggestion to be suppressed this time but not in the future? This is the opposite of the way Jon Lang suggests but users will be unlikely to discover long-press and their first priority is to “teach” the keyboard not to make substitutions that are not right for them. Aside from that, we don’t want to get into adding manual actions for controlling the dictionary because the goal is this kind of fiddling is kept out of the user’s hands. (Note, ‘ie’ → ‘i.e.’ and similar have been added as hard-coded shortcuts in English.
(Earlier comment):
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…
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
We will start with adding some "i.e." recognition at least.
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. :-)
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
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.
-
14 votes
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,…
An error occurred while saving the comment AdminTypefinity
(Support, Typefinity)
commented
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...
WIth release 2.1 the week before last we've restored the non-standard Apple emoji to English, Spanish, and French iPad layouts.
There have been some other rearrangements as well. @katjawy, if the @ problem persists, please let us know which language layouyt and device (phone or tablet) you are using. Thanks!