Currently, the keyboard only supports entering a primary or secondary ("shift") key. It does not support diacriticals or other "international" characters.
One way to accomplish this would be to use a pattern like that used in Windows or Mac OS X.
In this pattern, a combination of keys indicates that the next character will be modified. Sometimes, the initial "dead" (unprinted) key has a rough correspondence to the diacritical. In windows, colons become umlauts as in ü
. In OS X, backquotes become grave accents as in è
, and tildes are used to make ñ
and other characters.
This "leading modifier" approach requires us to track the fact that some things are leading modifiers, and to define what should be output for which modifier. It also requires that we somehow indicate that the modifier is active, and provide a means to cancel entering a modified character.
Another pattern is to have some kind of modified or long press on the key to be modified, which is fairly common in mobile keyboards. Holding e
or another character to be modified presents a menu with acute, grave, and other variations on that character. In our case, we would probably create a new "special character" latched key.
This seems more compatible with the existing code base. First, we already have the concept of a latched key. We also already have the concept of defining a payload (what to display, what to send). We could use the same concept to add a defined list of variants. When the "special character" key is latched, clicking a key presents a menu centred on the key's position, and selecting an option sends the "variant" key.
This does present some UI concerns that need unpacking, namely, what is focused, how do we move between variants, and how do we cancel the selection. Presenting the non-variant option as the first item and focusing on that seems appropriate.
Movement between options should follow the same convention as the larger keyboard, i.e. either tabs or "arrow only" (see #3).
Clicking outside of the variant menu should obviously close it, but I'm not sure what to do for keyboard navigation. One idea is to have navigating out of the menu in either direction close it, but this seems like it punishes users who explore too far.
In Weavly, there is a similar menu, which presents a focus trap where the original item (the key in our case) is included as the toggle for the menu. That might work, but is a little concerning in that we'd have to manage levels of focus traps when working within our own modal.
Another option is to avoid a focus trap and allow navigating in and out of the variant menu to neighbouring keys. In this scenario, we would close the variant menu when:
- An item is selected from the menu.
- The user hits escape.
- A mouse click outside the variant menu occurs.
- A "close" or other control inside the menu is clicked.
- The "special character" key is clicked again (to turn off the latch).
- The user opens the variant menu for another key.
We could choose to have navigating out of bounds open the variant menu for an adjoining key. In that scenario, making a mistake and navigating too far is easier to reverse.