F(x)tec is using the Pro1x as a way to introduce new keyboard layouts, but we noticed the latest proposal on IGG doesn't seem to address the biggest issue with the original Pro¹ shifted qwerty layout: missing slash/question-mark key, creating problems in all OS's and necessity for OS-specific workarounds. Therefore we hope F(x)tec uses this opportunity to not only un-shift but to also improve functionality, especially as alternate OS's like Linux are now clearly targeted.
Fig. 1. Unshifted qwerty layout shown in the Pro1x campaign.
The community quickly showed interest in this topic, with more than 150 posts by users from multiple OS's and about 3k views in just a few days. After one week of vivid discussions to weigh the costs and benefits of each suggestion users came up with, we think we've finally agreed on layout proposals we believe would significantly improve the user experience of the Pro1x on all OS's, keeping future developments of Linux OS's in mind. The changes we would like to propose are minor, yet would make it much better and more functional: Function is key, right?
/?in standard location\|in standard location- Swap Fn (currently
Slant_Arrow) with Alt_R (currentlySym), possibly with label changes
Fig. 2. Proposal with blue functions, no us-intl labels, Sym and blue slant arrow (i.e., the labels closest to what F(x)tec already used so far).
We think of that as a marketing decision, but several people involved in the discussion prefer International style AltGr key over Sym because the former is widespread while the latter seems to be mostly tied to Android systems, and same with just Fn over ➚.
Fig. 3. Proposal with blue us-intl labels, yellow functions, AltGr and Fn. Note that these us-intl labels are partly wrong/custom, see "Erratum" at the bottom of this message.
We understand that having more than two different colours (white and yellow currently, or white and blue) may be difficult/impossible to produce, so please consider the alternative below with just two colours. Overall, if going for a layout with many prints (like us-intl), then blue as a secondary colour would make the overall keyboard less aggressive to the eye and the secondary symbols would actually look secondary by being a little less contrasty (blue), as opposed to yellow which makes them look more important than the white ones. Blue also goes better with the sapphire blue casing of the Pro1x, ultimately making the phone just a lot more feng shui. See an example with just two colours below:
Fig. 4. Layout with all (correct) us-intl labels and just two colours on keys for easier production: white for main keys, blue for AltGr modifiers and symbols, as well as the Fx key (Super) which would be cool for the Pro1x limited edition. us-intl alpha keys could be upper case if preferred. Fn is labelled in smaller size and in the top right of its key as a visual hint of where to look for function key combinations: top right, white, smaller. The same would work with bottom right if preferred. Symbols instead of text are used for function keys for space saving (except Del, as it is both more straightforward and easier to distinguish from ⌫ than ⌦). Keys are overall labelled in larger font than the other examples to make this layout realistic and similar to the current Pro1 layouts. It is still legible, which shows that this layout could work with the actual size of the Pro1/Pro1x keys.
- Adds dedicated
/?key - Allows use of default Android & Linux keyboard layouts
- Adds standard modifier key to right side for use with those layouts, thereby allowing thumb combination with all alpha keys
- Easy modifier combinations with one thumb are the same as with original F(x)tec layouts
- Makes the keyboard more standard overall with alpha-digit-punctuation blocks like full-size keyboard but still thumb-typing friendly, which makes it more appealing to new users, more OS agnostic, and less dependent on OS-specific workarounds
- Those changes are equally applicable to other layouts (qwertz, azerty and scandic, where
/and?are also moved to unconventional keys), for consistency across the Pro1x offering
This proposed layout solves all issues with existing qwerty by putting / and ? exactly where they should be — and most importantly off P and L — so that all layouts (including US or UK-English and US-International) will work exactly as intended and no longer require every OS to find a workaround. The current Sym key is still not correctly assigned in stock Android but is Alt_R/AltGr in Lineage, which allows it to function as the modifier key for standard AOSP layouts, and is a useful key to have in general. This proposal suggests using the existing slant yellow arrow keys as Alt_R (like SailfishOS already does) and freeing up the existing Sym key for Function use. This permits normal shift and slash key functionality on all standard keys without needing nonstandard layouts or weird hacks like Pro¹ qwerty uses now, making the keyboard more robust on all systems and more straightforward for all users, for no real trade-off.
The second example above is the same layout with standard lower case US-international keymap shown in blue (matches the Pro1x casing and also is less aggressive than yellow when many labels are printed, which keeps the layout uncluttered), but we don't know if ther is really room for three symbols on the small digit row keys. One reason we propose this alternate layout is for those who are not familiar with US-international to understand why users of other layouts want the modifier key (Alt_R) on both sides of keyboard. Another reason is despite Qwertz, Azerty and Scandic layouts, there are still countries where the national layout is not in the current Pro1x offering. In many cases, they use specific ISO layouts that can't be replaced easily, except using US-international, and in those cases users might be happy to see that F(x)tec got them covered with a hardware keyboard that supports extra symbols without relying on some annoying OS-specific pop-up for extra symbols, also with convenient yet discreet hints on where the extra symbols are. We assume native English speakers who don't need extra international symbols would not be bothered by the extra capability of their keyboard as long as the extra labels are not drawing too much attention, while those labels clearly send a message to other users: no sacrifices needed. Perhaps this layout could be offered as an extra "International Qwerty Variant", or just replace the base qwerty given that it keeps the same function but is more versatile for international users. If International version is deemed to be a good idea but can't fit three symbols, they could just be printed on the alpha keys but not on the smaller digit keys, which wouldn't change the functionality when US International layout is selected.
Although Fn is not one of the standard PC keys used by default layouts, it is provided as an additional modifier that applications or OS's can chose to use however they want to get keys that are missing; our assumption is Lineage would continue to use it for F1-F12 along the digit row and PgUp/PgDn/Home/End on arrows keys, and if keyboard was labeled that way wouldn't hurt either. Keymapper (an event listener app) appears to be able to support Fn+key to use functions as well, and other Linux distributions like Mobian or Arch likely have the required toolkit to make use of a Fn key too. Additionally Fn+Shift (and Fn+Ctrl) could behave as Shift_R (and Ctrl_R) to compensate for hardwired modifier pairs and corner cases where software or games need to distinguish them, and the same for Fn+\ (or Fn+Enter if not enough space on the \| key for a third label) as Ins. But even without a Function key, this keyboard is more functional that existing qwerty or planned qwerty on Pro1x. And this leaves Fx (F(x)tec logo) for use as what Android calls Meta, what Linux calls Super, and what Microsoft calls the Windows key (all the same keycode).
As a bonus, this also avoids new users' frustration when accidentally hitting Del instead of Backspace. On shifted qwerty, Del is under Backspace, opposite of laptop keyboards and different than full-sized keyboards so often a bit of learning curve. Considering Backspace is most often used to correct errors while typing, while Delete is used with arrows for editing or as a delete action-key in some applications, having it as a function would work well. However if a dedicated Del key is must-have, most of these goals are still achieved by replacing Fn with Del, and using Fx key for function if desired (see examples below).
As to what to print on the Function and Alt_R keys, historically most Android keyboard phones labeled Alt_R as Sym, and Nokia phones additionally had a slant arrow. The label for the Alt_R key doesn't matter, whether it be AltGr like an international keyboard or Sym like a legacy phone, or just Alt like a US keyboard (perhaps in saphire blue to distinguish them from the Alt_L key). Only Alt_L keeps the smiley label which is there because gboard and AOSP keyboard present an emoji menu for Alt_L (AOSP keyboard presents symbol menu for Alt_R). AltGr and Fn labels are more linuxy/techy/international/standard in our opinion, but not the main point of this proposal, which is getting dedicated /? key and making standard keyboard layouts work in standard way while improving user experience in all OS's.
Finally, still along the same idea, we present below a couple more label options:
Fig. 5. Similar as the first us-intl proposed in the body of the text above, but in this case Fn for Function, blue Alt for Alt_R, and us-intl upper case printed on the alpha keys only. Missing us-intl labels on digit keys may or may not be surprising to users. Note that these us-intl labels are partly wrong/custom, see "Erratum" at the bottom of this message.
A. 
B. 
Fig. 6. Two alternatives keeping a dedicated Del key at the cost of the Fn key (Fx then serving as function key, but has to be done in software and comes at the cost of the loss of a modifier). A. Del key moved to the bottom instead of Fn. B. \| key moved to the bottom instead of Fn.
us-intl labels are not 100% standard on Fig. 3 and Fig. 5 and those also have a few mistakes. F, G, H, J, V and B should not have us-intl labels printed on them on standard us-intl, but those free keys could be used to add custom symbols that are convenient in some languages, like £ (normally on Shift + AltGr + 4), ë (normally not represented) and some other extra symbols you might want to add. It would be best to use those empty keys for custom changes and leave other keys as they are on standard us-intl. It makes more sense to print third level characters only because (1) those are the characters that correspond to AltGr without Shift which is what the secondary colour hints, and (2) there is more keys with a the third layer character than keys with a fourth layer character, meaning that printing fourth level characters would result in some keys with no blue labels although they do have an us-intl symbol on AltGr level. Therefore, if adding some keys currently on fourth level to make them more easily accessed (like £) or if adding keys not present on standard us-intl, it is best to make them available on the third level of the empty keys like F, G, H, J, V and B to keep the labels consistent with third level only, while keeping the standard us-intl on other keys (meaning £ would still be available on Shift + AltGr + 4 too, but not printed on 4 because fourth level). In Fig. 3. and Fig. 5, blue characters were actually a mix of third level and fourth characters, which was inconsistent and difficult to follow. Being standard is more robust for the long term and for a wider audience. Please take this into account when reviewing the examples. Fig. 4. shows the correct standard us-intl that should be used in a layout with international labels printed, and which keys are free to add extra symbols on third level for easy access.
