mcdurdin
commented
4 years ago Further commentary
Yes, you've articulated a lot of the problems with the 'one size fits all' of mnemonic layouts and I would agree with you that it's really not a good fit for your use case. I think you've gone the right direction. How could we improve the Developer experience for your use case?
Mnemonic layouts are kinda like pan-language keyboards: better than nothing for a number of situations but not as good as a tailored solution.
As you say, the mnemonic layout cross-platform experience has not caught up and it will be some time before it does :( Show less Jeff Heath Jeff Heath 4:45 PM Feb 26 Yes, but a "tailored solution" for how many keyboards? I like the fact that people can search for the "Chad/Tchad" keyboard (by language if they want), and it works whatever the layout (since it is mnemonic). I think it is a bad idea to have a different version of our keyboard for all of the QWERTY, AZERTY, QWERTZ, false AZERTY, etc. variations - is the user really supposed to choose between them all? (Do I have AZERTY or false AZERTY? ...) And then if some are moving away from national keyboards to keyboards more individualized for a languages, do you need to produce each of those 5+ flavors of the physical layout for each language? So that's why I'm reluctant to give up on the mnemonic capability. Show less Jeff Heath Jeff Heath 4:49 PM Feb 26 But I do see the concern that the touch layout needs to have different formats, QWERTY and AZERTY in our context, for example. I think I need to have two keyboards (QWERTY and AZERTY), but plan at the moment to use menmonic for both of the desktop layouts (i.e. identical desktop layouts, and just different touch layouts) Show less Matthew Lee Matthew Lee 5:05 PM Feb 26 Positional layouts partially mitigate the False Azerty problem, as long as you duplicate anything on the 102nd key elsewhere. I still think QWERTY serves QWERTZ well enough. We just need AZERTY separate. Marc Durdin Marc Durdin 5:09 PM Feb 26 I think there is still heaps of value conceptually in mnemonic. But I think that Azerty in particular has trouble. The principle of mnemonic could be applied to touch layouts -- but we would need to think through how we declare the remapping (it may be a case of multiple touch definitions, with Developer providing tools to automate that). From what I can see, in most contexts there are one or two 'standard' base layouts and the others are far less common -- e.g. we could do the 'QWERTY' as a mnemonic, but do a special positional version for AZERTY.
We would need to do a design study I think to cover the variations, especially in Africa, which are causing us trouble. Something for us to consider for 15.0.
This is a dump of a discussion on mnemonic layouts.
Mnemonic Layouts
I would like to explore that further with Matthew
To be fair, I havenât given mnemonic its fair shot recently.
Challenge 1: AZERTY is painfully awkward. Who in their right mind would hide the period behind shift? A good portion of the RALT Keys are filled, and the go-to QWERTY deadkeys require RALT or shift. The Caps behavior on the upside-down number row creates challenges (Keyman doesnât have a handy âCAPS affects this keyâ flag like MSKLC, so you have to hard-code CAPS behavior on a positional layout).
It makes more sense to intentionally and separately decide where to place each character on QWERTY and AZERTY, finding a combination that is easy to learn and reach.
Nevertheless, Francophones donât want to abandon AZERTY for something âeasierâ. I once created a positional minority keyboard based on Azerty, and the French consultant cried with joy when she realized that the number row worked as expected after working with other Anglocentric developers.
Challenge 2: With the variety of used computers flowing into Africa, typical Francophones are already familiar with positional layouts. Despite my insistence on US International and the idea of using the letters actually on the keyboard, they will (without fail) set a QWERTY machine to French (France) and learn the layout positionally. (Underscore is known in Africa as the âHyphen on the 8â, and that mnemonic helps them find even on a QWERTY physical layout.) Anything they canât âfindâ, they will get via insert character or copy it from elsewhere.
If the keyboard is some weird variation of AZERTY or QWERTY (these are common) with added characters that donât match the base layout, they can press the ÂĽ key on their keyboard all day long without effect.
Often I will install the Cameroon QWERTY (following the physical keyboard) and come back later to find the Cameroon AZERTY installed because they already prefer using French (France) (positionally) to type French rather than US International (which is basically a mnemonic layout). Francophone Africans REALLY do prefer positional layouts, and positional layouts are easy to show with a diagram.
Challenge 3: When Keyman is set up, how does it choose a default base keyboard? Primary keyboard at install? Primary keyboard at runtime? If the right default is not set, this option is buried in the interface and hard to find. (Positional layouts donât require this option to be set/changed). I just set the base keyboard this way manually, and it does work as expected for the IPA keyboard. This was not my experience in some earlier versions.
Honestly, I really donât understand the linkage between Base Keyboard and other settings:
Should setting the âShow underlyingâ flag show up in the onscreen and mobile keyboard? How do you determine the underlying keyboard on mobile (Android with Bluetooth KB)?
Challenge 4 is discoverability. If someone chooses AZERTY or QWERTY positional keyboard, it âjust worksâ as expected. If someone were to choose Cameroon âpositionalâ and Keyman had chosen US English as base, it will not work as they want/expect until I show them the hidden option to change the base KB.
Challenge 5: We also maintain MSKLC and XKB versions of the Cameroon Keyboard, and neither MSKLC or XKB support mnemonic, so the Keyman layout and Documentation would be different from the others. We donât need the keyman reordering features for our latin-script NFD context, so âallâ keyboard managers can be supported (meet the user where they are), but Keyman is an easy bridge to previously unsupported platforms.
So, while mnemonic may now âtechnicallyâ work for a QWERTY/AZERTY environment, it is not ideal for the user from the POV of expectations, finger flexibility, configuration, or training. I canât recommend it in this context.
Challenge 6: In a single-source keyboarding paradigm, no option is reasonable to me that doesnât support all OSâs (at least across Keyman). How would I create/package both Azerty and Qwerty touch layouts with my mnemonic desktop package (and make a bluetooth keyboard work as expected), and how discoverable are the options to choose between them after installation?
I canât understand how a mnemonic keyboard will be more discoverable if you have to 1). Set the base keyboard correctly in KM Desktop after installing the keyboard, and 2). Switch on mobile to the touch arrangement you prefer via some in-keyboard menus (if these exist), but I think you just said they didnât. 3) the user needs to know intimately the peripheral characters of the âbase Layoutâ, which may not be possible to align perfectly with the physical layout.
I canât understand using mnemonic keyboards from a single-source point of view. If Mnemonic is only supported on some platforms, why would i want to maintain a separate mnemonic keyboard for those select platforms (breaking the one-codebase paradigm) and write my documentation 3 times (QWERTY, AZERTY, mnemonic). If I canât explain which keyboard to choose in 50 words or less, I need to simplify the options further.
When mnemonic keyboards become an all-OS feature, and there is a method for choosing between several visual layouts in mobile, then it becomes more technically feasible, but still more difficult in practice for the African context.
~Matthew