stroke-input-android
stroke-input-android copied to clipboard
Hold down on a suggested character to view its stroke order
This project is amazing; as far as I know, you're breaking new ground with libre Simplified Chinese keyboards. Only I've typed in Pinyin for too long, so these stroke orders will take getting used to...
This is a learning opportunity, though. As a resource for education on stroke keyboards, a quick method of viewing the strokes that make up a character would be greatly appreciated, such as the above.
Nice feature request! I've been brainstorming some ideas, and would welcome any suggestions/improvements.
Firstly I've concluded that Toast display of strokes is bad, both because they are ephemeral and because they get truncated.
So my idea is that, when a candidate is long-pressed, a popup appears over the main keyboard area to show the strokes of characters.
Use cases
1. Long-pressing a candidate given a partial stroke sequence
E.g. long-pressing 些 given a partial stroke sequence of ㇑㇐㇑㇐ or 2121:
【些】
- ㇑㇐㇑㇐㇐㇖㇐㇐
- ㇑㇐㇑㇐㇒㇖㇐㇐
- ㇑㇐㇑㇐㇖㇒㇐㇐
Sample mock-up (better colours will be used):
2. Long-pressing a phrase completion
E.g. Long-pressing 可小 (a phrase completion of 可大):
【可】
- ㇐㇑㇖㇐㇑
【小】
- ㇑㇒㇔
Sample mock-up (better colours will be used):
Notes for use case 1
-
些 is defined as
(215|2121)(15|35|53)11, to allow for leniency in the strokes of the components 止 and 匕. -
Currently I'm thinking that the displayed results should be filtered for consistency with the partial stroke sequence. For example, in the case of 些 with partial stroke sequence
2121, the stroke sequences beginning with215should be omitted. -
Currently I'm leaning towards wrapping long stroke sequences (rather than horizontal scrolling) for overflow. The longest stroke sequence recorded is for U+4A3B 䨻 (four thunders), which has 52 strokes.
-
Currently I'm thinking there should be colour difference within the stroke sequence of each displayed result, to distinguish the portion that matches the partial stroke sequence already entered.
Open questions
- What should be done in cases where there is an exceeding large number of possible stroke sequences? E.g. U+4D2B 䴫 is defined as
4135221(1515|1535|1553|3535|5353)1(25|45)2(1111|4134|4444)34(152|154|454), so there are5 * 2 * 3 * 3 = 90possible sequences in total.
I'll admit I did not consider the sheer number of strokes in Traditional Chinese characters when this idea came to me. Still, I see a way to improve:
Firstly, I would move the stroke order popup above the keyboard. This would allow users to type while following the character order. Covering more of the screen should not be an issue; the current progress in typing the character is already shown by the keyboard. The display should update automatically by default, but an option can be added to the app to turn the updates off, as well as disable 'learning mode' altogether.
Automatic updates would facilitate a potential solution to displaying too many stroke combinations: strokes may be shown up to the last characer before the second next set of lenient strokes, cut off by an ellipsis. This way we won't have to show multiple lenient sequences, avoiding the multiplicative effect on displayed entries. The lenient strokes can be colored differently for clarity.
The strokes of your 䴫 character would be shown initially as the following:
- 丶一㇒㇖丨丨一一㇖一㇖一…
- 丶一㇒㇖丨丨一一㇖㇒㇖一…
- 丶一㇒㇖丨丨一一㇖㇖㇒一…
- 丶一㇒㇖丨丨一㇒㇖㇒㇖一…
- 丶一㇒㇖丨丨一㇖㇒㇖㇒一…