feat(windows): mnemonic layouts need improvement

This is a dump of a discussion on mnemonic layouts.

Mnemonic Layouts

> no, Mnemonic doesn't work for AZERTY
there are almost no deadkey-letters that are un-awkward on Azerty
(from Qwerty)
To be fair, there's almost nothing at all that's not awkward with AZERTY 😂. You can use baselayout() statement along with mnemonic layouts to give finer control - e.g. to use alternate keys for AZERTY instead of [ and ].

> the second problem is that I've almost never been able to convince Keyman that Azerty was my base layout...it always assumes QWERTY
so Mnemonic fails.
Matthew • Mon, 11:40 PM

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