Pro1 X Qwerty Layout (Not Shifted)

[Slion 1,200]

Now that we do know Del can easily be moved to a secondary function of Backspace on Android I've updated my suggested layout there:

For clarity those layouts are only showing the unmodified and shift modified layers.
I've put Del as Shift + Backspace even though to be correct and since this is a device specific feature it should really be Fn+Backspace however those kind of details don't really matter at this stage and if implemented properly this could all be fine tuned using custom layouts.

Edited November 2, 2020 by Slion

[Slion 1,200]

Now the big question is how do we make sure FxTec is taking those suggestions into account?

@Erik @Waxberry

[EskeRahn 5,399]

1 hour ago, Slion said:

Now the big question is how do we make sure FxTec is taking those suggestions into account?

@Erik @Waxberry

Well maybe if we could summarize the pros and cons of various ideas, including those completely abandoned (and why) , it will be easier to consume than six pages of suggestions and comments....

[matf-kabouik 414]

I tried to add arguments to strengthen our proposal, and also emphasized that all this was a discussion where everyone was welcome, not just one isolated community member's suggestion (but I'm very grateful to Craig for starting the initiative and taking leadership here).

I wanted you guys to see the revision history but didn't want to force anyone (myself included) into using a word processor and eventually get cancer, so I put my changes in a Gist that you can all review, comment and maybe edit directly (not sure). You can view the revisions from the "Revisions" tab at the top.

Those are just humble suggestions to make our point more robust, but maybe what I did doesn't go in the right direction. You tell me. I initially put more arguments in my first draft, but I got punished after criticizing word processors when Firefox crashed and lost all my edits before I commited them, I had to restart from scratch and forgot some points.

Edited November 3, 2020 by matf

[brunoais 317]

Looks really good!

The 4-6 pictures are missing, though.

[matf-kabouik 414]

Thanks! Yep I didn't have them and don't have the permalinks of other ones to avoid starting from scratch. I added the placeholder text so that we don't forget to add them.

[matf-kabouik 414]

I just updated the gist with the missing pictures, and fixed a couple aesthetic issues in the others (no layout change, just fixing some alignment inconsistency when having or not having us-intl labels, and removing us-intl labels that were actually visible in dark grey in the first layout). Looks OK to me now.

If you guys agree, maybe we shouldn't wait too much before sending it to porters and to Liangchen. It would maximise our chances to get it reviewed before they start production (the Xmas perk should already be under production actually).

Edited November 3, 2020 by matf

[brunoais 317]

@matfI think that even if we send the recommendations now, it won't affect the Christmas units.
However, we hopefully should still be well on time for the March units.

Out of those options, my current favorite is number 3.

Edited November 3, 2020 by brunoais

[matf-kabouik 414]

Absolutely, and maybe F(x)tec won't deem our proposal relevant anyway. :> In any case, I guess if they accept a layout change, it will be featured in an IGG update and those who got the Christmas perk should get the opportunity to get their device as announced and for Christmas, or wait more for a unit with the upgraded layout, so it'd still be better to send the suggestion early enough.

My personal favourite is now the 2nd one (with full us-intl labels). Initially I was not a big fan of printing all labels, yellow international labels used to make the keyboard very busy and I thought non-us-intl users would be annoyed. However I think blue is discreet enough and does not clutter the keyboard, while making it a very robust option in all languages. Having a Linux phone with the normal us-intl layout and fully standard alpha-digit block would be quite something in the tech world, in my opinion. It all also depends on whether they would replace the basic qwerty with that one, or just add an the international variant while keeping the simple one as an option.

Edited November 3, 2020 by matf

[brunoais 317]

Yeah. I agree. The 2nd suggestion (picture 3)

[EskeRahn 5,399]

In principle I like the US/international print idea. But the blue labels might be so discrete (Even with back-light) that only the most eagled-eyed among us can distinguish them Try to scale this 1:1 on your monitor. I bet it will require substantial brightness&contrast for most people....

[matf-kabouik 414]

That's true but given those labels are just for third-level symbol, that would probably be acceptable anyway in my opinion. People who need them just need to be able to find them until they get used to the layout (which they might already be since it's standard). 

At worst, F(x)tec could always change the hue for something slightly lighter, or go for a layout with just intl labels on the alpha keys. Also, here we used the online editor because it is convenient and looks good, but in practice the labels seem to be printed in bigger and bolder font on the Pro1.

Edited November 3, 2020 by matf

[EskeRahn 5,399]

Repeating myself here in reaction to the complex print suggestions

• Three prints on the keys is going to be crowded especially in the numbers row.
• if we want different colours, F(x)tec will need to change more hardware than just the top black print layer
• It will also require hardware changes to have double print on keys that are not prepared - at the least it would be white if not.

If you look carefully at the keys that got yellow print (+caps) at the exact right angle, you can see a minute difference in the surface indicating a coloured film at the top left of these keys. (Yellow except on Caps) It is not present on ALL keys, but it is present even on the shifted qwertY on the physical keys that got yellow symbols for qwertZ. The difference in reflection is a lot easier to spot on the early keyboards than the later ones.

Frankly I'm not sure if we can persuade them to change more than the top print layer (the black), so with Del on ⌫ expect both to be white on black. And the same for any other keys that currently only got one print, if we suggests two (I could easily live with that, though, I still think it would be a great idea moving Del to free up a key)

[rkjnsn 14]

On 10/27/2020 at 12:14 PM, Craig said:

Just wanted to weigh in that this particular layout looks fantastic to me! Especially if the slant arrow also got me F1 (slant+1) through F12 (slant+equals).

[matf-kabouik 414]

After @EskeRahn's comment, I heard from someone I can't name that, indeed, distinct label colours in addition to white are unlikely (but we never know). Blue might be possible, but I mentioned that this would mean changing the Fx label so there's no firm answer on that either.

In any case, I believe we could send our message almost as is and keep the images we have, but add a couple sentences to acknowledge that layouts with multiple label colours are difficult to produce. However, this could be dealt with by printing only us-intl labels and not Fn keys (I think it's fine if they're hidden but learned by users, it's only 5 or 6 key combinations). Or the opposite if us-intl is deemed too specific, but we already cover this in the message.

Other workarounds include printing Fn combinations in white like normal keys, but have them written on the right instead of the left or the center, which shows they are secondary keys and the left symbol is primary. Backspace would become `⌫ Del` instead of just `⌫`. Another way could be to mark functions with brackets (just an example), i.e., the modifier would be labelled `[Fn]` and then functions on other keys could be between brackets too, like `◀ [Home]`. This would make labels longer for no huge benefit, but those functions usually have dedicated symbols too: `◀ [↖]` would work too and keep that relatively short. I personally think just writing two white labels on keys, left- and right-aligned, respectively, would work, but it doesn't hurt to give them additional suggestions to make sure they don't rule out all our proposal because we based it on multiple colours.

Edited November 8, 2020 by matf

[brunoais 317]

I prefer the brackets option.

[Slion 1,200]

On 11/3/2020 at 8:38 PM, rkjnsn said:

Especially if the slant arrow also got me F1 (slant+1) through F12 (slant+equals).

You know you can already get that today on your Pro1 using some custom layout?

[matf-kabouik 414]

If we suggest symbols to keep the labels short, I think those are more or less common (maybe not conventional, but at least straightforward):

Page Up: ⇞

Page Down: ⇟

Home: ↖, ↸, ⭶, ⤒, ⇤, ⌜, ⇱

End: ↘, ⭸, ⤓, ⇥, ⌟, ⇲

Del: ␡, ⌦

Ins: ⎀

Source. Some are my own invention and may not make sense, some others are actually borrowed from Tab, but there wouldn't be any ambiguity in our case.

We could propose a keyboard layout with that and only two label colours, with or without brackets.

Note that ⎇ is also standard for Alt, albeit rarely used. This could be another way to distinguish Alt and AltGr too, but I must admit I prefer the modifiers to be written in letters as they are currently. Looks tidier and easier to understand in my opinion. I wouldn't mind the 6 functions (PgUp, PgDn, Home, End, Delete, Backspace) to be using their icons if that's the only way to have them printed large enough and convince F(x)tec, though.

My personal preference would be ⇞, ⇟, ↖, ↘, ⌦, ⎀, because they look minimal yet self-explanatory and keep the keyboard relatively clean.

Edited November 10, 2020 by matf

[brunoais 317]

8 minutes ago, matf said:

My personal preference would be ⇞, ⇟, ↖, ↘, ⌦, ⎀, because they look minimal yet self-explanatory and keep the keyboard relatively clean.

I prefer ⇞, ⇟, ↸, ⭸, ⌦, ⎀, but I don't mind your choices.

[matf-kabouik 414]

Note that the home and end symbols you selected don't have the same bar length (I couldn't find any long bottom bar), so if we go with the bar, we'd better use the short ones for both keys.

[EskeRahn 5,399]

37 minutes ago, matf said:

Home: ↖, ↸, ⭶, ⤒, ⇤, ⌜, ⇱

I like your ideas, though one symbol is already used for backward jump to tab-stop (Shift+Tab)  ⇤

I really like the principal idea of e.g. ⇱indicating a jump to a boundary, and not just an indication of something in a direction

 

[matf-kabouik 414]

Yeah I would discard those ⇤ and ⇥ from the potential candidates too.

[EskeRahn 5,399]

4 minutes ago, matf said:

Yeah I would discard those ⇤ and ⇥ from the potential candidates too.

....and ⤒, ⤓ too. The second would be natural for the seldom used VT (Vertical Tab). I have never seen Back-VT though, but for consistency, I would remove that one as well. (also close to the symbol often seen for caps)

[matf-kabouik 414]

Works for me. At this point I think what would determine whether we use the most minimal symbols or those more visually complex with corners or bars is whether we enclose them between brackets or not.

Note that we could also just write "Fn" on the top right corner of the modifier key, and then show those symbols on their respective top right corner too, I may be equally clear that Fn is needed to use those functions. While AltGr would be in a distinct colour similar to us-intl symbols. Of course for layouts with no us-intl symbol labels, the issue vanishes because only two label colours are needed.

Edited November 10, 2020 by matf

[EskeRahn 5,399]

Though I like the boundaries, I bet they will be hard to get legible on such small keys, so I bet some exaggeration will be needed compared to the suggestions. Wider lines and wider space, that is a more 'fat' symbol. But the principle is great IMHO. Look at how they did the Tab & BackTab on the qwertZ variant. 🙂