Most Japanese keyboards using the 12-key Layout support flicking from the center of a key off to one of four sides.
[image 1] (https //join biglobe ne jp/mobile/sim/gurashi/wp-content/uploads/2017/03/flick_or_toggle_06.png)
↑ In this example, tapping on this key would produce ま, but since the user swiped down, it produces も.
[image 2] (https //news mynavi jp/article/20171113-windows10report/images/001.jpg)
↑ Here’s a more modest example where flicking from letter keys enters symbols or numbers. (SwiftKey)
[image 3] (https //live staticflickr com/2523/3900136064_a9072c8fc9_n.jpg&h=822b9b60fec66588dd50e63e409654c95bc8a474b1ac1460eb7f0d8a8a1613b4)
↑ I’ve seen layouts with up to 8 flick directions (4 cardinal + 4 diagonal). Although this example (MessagEase) uses drags instead of flicks, the principle remains the same for dragging to an adjacent key (e.g. from “o” to “s” enters “j”).
If Keyman implemented this missing feature, it would be one of the very best ways to design a keyboard for touchscreen devices. For example, this layout for the Shavian alphabet I’ve designed myself:
Requirements:
- Ability to define up to 8 flick directions for each key
- Warn the creator if swiping left from the leftmost key, swiping right from the rightmost key, or swiping down from the bottom row of keys
- Ability to show all letter previews, instead of hiding the extra letters in a dot, as is done with long press
- Detect the closest defined flick direction
- e.g. if up-left, down-left, and down are defined, flicking exactly right should not input any letters, but any trajectory between right and down should input the letter defined in down
.