It's the keyboard layout.

[_wb_]

Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.

 Having those characters printed wouldn't bother me much in and of itself.   As I've said before, I'm not terribly concerned about visual clutter.

It's just that the idea of of having multiple good keymaps with no conflicting symbol information on the keys (as opposed to just one all-inclusive layout with a lot of compromises) really appeals to me. 

- Neelix

True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.
I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.

 

[Neelix]

Multiple layouts can break positional key bindings (key bindings chosen because of their absolute or relative position on the keyboard) . See example in my previous post. Because of this I think the primary key functions should be the same in all layouts, if there are multiple.

What happens behind modifiers mainly affects software that expect certain shift-pairs as has been said here before. I consider this a lesser issue though, because key bindings rarely depend on what symbol comes out of X using a modifier.

My intention was always to have a static primary layer and static US-keyboard key equivalents on the meta layer.  That's what would be printed on the keys.   It would only be the meta layer of a specific subset of keys that would change between layouts.

True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.

A blank keymat provides no points of reference at all.   Here the primary QWERTY layer provides a point of reference.   Yes there's an extra translation step for the international characters this way, and that introduces a learning curve but for commonly used characters there would quickly be a learned association.  (eg  À is on A, É is on W)  

I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.

The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.

- Neelix

 

[comradekingu]

Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.

 
Having those characters printed wouldn't bother me much in and of itself.   As I've said before, I'm not terribly concerned about visual clutter.


It's just that the idea of of having multiple good keymaps with no conflicting symbol information on the keys (as opposed to just one all-inclusive layout with a lot of compromises) really appeals to me. 


- Neelix

True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.

I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.

Depends what kind of information you convey. A layout is already in muscle memory, not in knowledge. Adding a different than usual visual layout, is a serious de-tour. Meta layer is only good enough for interlingual use. I dont understand what polish or Norwegian has to do with AltGr.

 

[_wb_]

Depends what kind of information you convey. A layout is already in muscle memory, not in knowledge. Adding a different than usual visual layout, is a serious de-tour. Meta layer is only good enough for interlingual use. I dont understand what polish or Norwegian has to do with AltGr.

 For Scandinavians, an US-International AltGr layer suffices to cover their Å Æ Ø Ä Ö (and even Þ and Ð) : http://en.wikipedia.org/wiki/AltGr_key#US-International

For Polish, AltGr is an established method to efficiently input their Ą Ć Ę Ł Ń Ó Ś Ź Ż : http://en.wikipedia.org/wiki/AltGr_key#Polish

For German, French, and quite a few other relatively big languages (Spanish, Portuguese, Italian, Dutch), my proposal works well "out of the box": no AltGr layer needed, no remapping needed, all letters can be typed efficiently already by default, and the labels are there so you don't need muscle memory or whatever kind of memory to know how to type. Sure, there will be a learning curve, nobody will type fast on a new device from hour 1. There is no way around that: two-thumb handheld typing is something completely different than ten-finger touch typing, there are plenty of things to adjust to. Even disregarding physical differences like the size of the keys, the number of keys, the position of space etc, there will be differences anyway, because not everyone will be used to QWERTY:

     QWERTY

     QWERTZ

     AZERTY

     National layouts (Turkish FGĞIOD, Latvian ŪGJRMV, Lithuanian ĄŽERTY, Portuguese HCESAR)

     Non-Latin scripts

And then there's the people who rather use something that attempts to optimize the efficiency of typing like DVORAK, COLEMAK, Neo, BÉPO, or whatever. [Actually for thumb typing, the key positions that are easy to reach are completely different than for ten-finger typing, which means none of those "optimized" layouts would actually be very efficient: they put the important keys in the center of the home row, while for thumb typing, that is exactly the worst position.]

Anyway, adjusting from AZERTY or QWERTZ to QWERTY is not that big of a problem, you get used to it auite fqst

My point is: most people will have to adjust, there is no way around that, but we can try to make life easy for most people by providing a keymat labeling that covers most languages.

 

[_wb_]

I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.

 
The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.


- Neelix

But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:

There is no way, even if you arrange the missing US-QWERTY keys on Meta and Shift+Meta in the most compact way, to accommodate something like the above just by assigning new Meta actions to unlabeled Meta keys.

Also, I don't see much reason to put letters that are already labeled at different places than where they already are in the combined layout. Would ÜÖÄ at Meta+UOA or at Meta+OKL (or where would you put them if you were a German?) really be much better than at Meta+FCV, where they happen to be now in my proposal? I don't think so. I think the main thing you want to do is add new letters (currently unlabeled). And for that, the AltGr layer is a better option than adding stuff into the Meta layer.

Keep in mind that we can have both Meta and AltGr at a shoulder button. Together with Shift that means you can have up to eight symbols per key if you want, all efficiently chordable using just one thumb press. I propose to make a good default for the first four layers (primary, Shifted, Meta and Shift+Meta), where only two or three layers are printed per key: I would say three for the number row (primary numbers, shifted symbols, Meta F-keys) and two for the letter keys (primary (uppercase/lowercase is implicit) and Meta), to keep it visually clean. For the next four layers (AltGr, Shift+AltGr, Meta+AltGr and Shift+Meta+AltGr), US-International would be a good default, but it does not need to be labeled, and I would disable the AltGr behavior of R_Alt by default (since it makes Alt+letter menu shortcuts impossible), using R_Ctrl + R_Alt instead as the default AltGr mechanism.

 

[Neelix]

The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.

But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:

There is no way, even if you arrange the missing US-QWERTY keys on Meta and Shift+Meta in the most compact way, to accommodate something like the above just by assigning new Meta actions to unlabeled Meta keys.

My proposed layout has 17 unlabelled Meta keys, and still has all your dead-keys in place.   I only count  9 specific Alt-Gr symbols in that polish layout, so creating an optimised layout including them all should be no problem.   My suggestion is not to try to replicate the Alt-Gr layouts of the specific regions, as obviously the placement of the static portion of the  meta layer would block that, rather it is to allow people in different regions to have a layout that is tailored to that region. 

Also, I don't see much reason to put letters that are already labeled at different places than where they already are in the combined layout. Would ÜÖÄ at Meta+UOA or at Meta+OKL (or where would you put them if you were a German?) really be much better than at Meta+FCV, where they happen to be now in my proposal? I don't think so. I think the main thing you want to do is add new letters (currently unlabeled). And for that, the AltGr layer is a better option than adding stuff into the Meta layer.

You've said it yourself, different languages have different letter frequencies for the same letters, so they have different priorities for the letters they have in common. In some regions Meta+A might be the optimal position for Ä, in other regions it would make more sense to have À there.

Keep in mind that we can have both Meta and AltGr at a shoulder button. Together with Shift that means you can have up to eight symbols per key if you want, all efficiently chordable using just one thumb press. I propose to make a good default for the first four layers (primary, Shifted, Meta and Shift+Meta), where only two or three layers are printed per key: I would say three for the number row (primary numbers, shifted symbols, Meta F-keys) and two for the letter keys (primary (uppercase/lowercase is implicit) and Meta), to keep it visually clean. For the next four layers (AltGr, Shift+AltGr, Meta+AltGr and Shift+Meta+AltGr), US-International would be a good default, but it does not need to be labeled, and I would disable the AltGr behavior of R_Alt by default (since it makes Alt+letter menu shortcuts impossible), using R_Ctrl + R_Alt instead as the default AltGr mechanism.

You can, and perhaps some users would want to take advantage of that. I wouldn't recommend it for the default layouts though. The idea here is to have some predefined regional layouts and to allow the user to select a regional layout on first boot, (later switchable though the configbutton applet) optimised for their region.

- Neelix

 

[comradekingu]

Muschle memory isnt a detriment, its how people know how to type. Without it, they dont. Zero languages other than english work out of the box. I dont understand the point of re-learning because some amount of learning is required.

There isnt even a AltGr key, how do you explain that? Why not use the explaining on something that makes sense for a lot of people?

People are fast right away when its their layout, if part of the layout is missing, they will never be fast. Thats the part that there isn't any way to get around.

If i was german, i would put ÜÖÄ on ÜÖÄ. Do you honestly believe anyone will put up with pressing shift+AltGr+letter instead of just letter placed where letter is supposed to be? Thats absurd.

The fact that not everyone uses QWERTY only makes it a really bad idea to hardcode QWERTY by adding other symbols to the keys so they cant be switched around.

 

[_wb_]

There isnt even a AltGr key, how do you explain that? Why not use the explaining on something that makes sense for a lot of people?

People are fast right away when its their layout, if part of the layout is missing, they will never be fast. Thats the part that there isn't any way to get around.

If i was german, i would put ÜÖÄ on ÜÖÄ. Do you honestly believe anyone will put up with pressing shift+AltGr+letter instead of just letter placed where letter is supposed to be? Thats absurd.

The fact that not everyone uses QWERTY only makes it a really bad idea to hardcode QWERTY by adding other symbols to the keys so they cant be switched around.

AltGr does not have to be labeled: just like Compose it is a user-configurable key that can be put anywhere you want. The usual default position for AltGr is RightAlt or Ctrl+Alt.

"Putting ÜÖÄ on ÜÖÄ" is not really an option, if you mean dedicated primary keys by that:

A "wider keyboard" (with room for ÜÖÄß as dedicated keys at or near their expected position) has one big problem: there are only three keys left for comma, period, shift, Meta/Fn/AltGr, Enter and Tab. In other words, you have to eliminate three out of those six keys (i.e. make them non-dedicated keys or move them away from the main keyboard section). To me, that is an unacceptable trade-off.

Meta+FCV is what I proposed for üöä. That is one shoulder button and one thumb press. Yes, that is worse than just one thumb press, but that is an inevitable consequence of having less keys than usual: Germans will also have to learn to live with non-primary keys for + - #  ß < acute and circumflex, for example.

But labeled üöäß Meta-keys, available in one shoulder and one thumb press, while not as good as a full-size German keyboard, is still much better than what the Pandora layout offered Germans: [ Shift+Enter ] [ Fn ] [ S ] [ U ] just to get ü, that is one shoulder and FOUR thumb presses.

And arguably, labeled üöäß Meta-keys are better even than a layout like the one you propose, where Germans are supposed to map their letters to [ ] < Shift, then recursively remap [ { ] } < > elsewhere, live without keyboard shift, and get used to a wobbly space key that may or may not accidentally produce dots instead of spaces and spaces instead of dots. And they cannot rely on any "visual muscle memory" because Z and Y are still wrong, the number row is misaligned, Tab, Enter and Space are not where they should be, ß is not where it should be, and all of the punctuation symbols are in completely different places than on a normal German keyboard. So they have to remember a lot of things, and looking at the keymat is not going to be of much help because it is not accurate.

 

[_wb_]

The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.

But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:

There is no way, even if you arrange the missing US-QWERTY keys on Meta and Shift+Meta in the most compact way, to accommodate something like the above just by assigning new Meta actions to unlabeled Meta keys.

My proposed layout has 17 unlabelled Meta keys, and still has all your dead-keys in place.   I only count  9 specific Alt-Gr symbols in that polish layout, so creating an optimised layout including them all should be no problem.   My suggestion is not to try to replicate the Alt-Gr layouts of the specific regions, as obviously the placement of the static portion of the  meta layer would block that, rather it is to allow people in different regions to have a layout that is tailored to that region.

Yes, but having the AltGr keys at their expected position (Ę at E, Ł at L, Ą at A, Ó at O etc) is what makes the Polish layout work. Mapping them to Meta+something else is in theory just as efficient, but it would be much harder to learn, especially if there are no labels on the keys themselves, just an on-screen cheat sheet.

Note that things are different for German and French: they have their extra letters as dedicated keys, separate from the letter keys. We have no room for that (though comradekingu disagrees with me on that), so they have to map their extra letters elsewhere anyway. I don't think it matters very much where we put them, it will be something the Germans and the French will have to get used to anyway.

If we would go with your proposal (only ASCII and dead diacritics labeled, no precomposed letters for German and French), then I think that a lot of French/German people would prefer to simply use the default, labeled layout (using dead diacritics, even though it's less efficient), instead of selecting a language-specific layout where they have to remember the locations of the keys (or look at on-screen cheat sheets).

For me personally, that would be fine (I rarely use French and I don't really use German at all), but I think that a lot of French/German people would only consider the device to really support their language if their (important) letters are actually labeled on the keys themselves.

 

[comradekingu]

You are making it less keys, its a consequence of choice, not of limitations. Within limits you can do it, but then you will have to have altGr on columnkeys.
 
With needing altGr and there not being one, my best guess would be the one keyboard alt, that isnt any better.
 
A lot of things are better than the pandora keyboard, in terms of saleability, i dont think another arbitrary way to type is a good idea.
 
I can pay whatever it costs for germans to get their keymat. Will you believe me then? Because for me, and everyone else that wants efficiency, reduced layout isn't an option.
 
Here is how it works, you type a language using the letters, notice how many letters there are in this post. Secondly the punctuation-sequences matter, with that out of the way, its smooth sailing.
 
Its easy enough to cut things out of the keymat and add them in other places. For things other than AZERTY-german, if thats the only additional keymat, this is a viable option.
 
ß is used a lot less than üöä in german. And the key used to do it, is the one two places to the right of 0, its not there. It is also not strictly mandatory. Thus a keymat made to omit it, wont look out of place.
 

Who are these people who dont know how to use a typerwriter/keyboard? They arent any of our users. Even my mum can use a british keyboard and type norwegian on it.

The space-bar idea for a non-centralized non-stabilized key is a misnomer. It is wobbly in any event, just like pressing tab on the pandora is. You dont need to make it dual action, but its preferable, etc etc. Lets hope it doesnt come to that.
 
Muscle memory isn't visual. Typing isn't visual. You can learn it visually, and that lowers the threshold of entry, but that's as far as it goes. In no known universe is a keyboard with A-Z only better for anyone who doesn't use A-Z only. That is at best an anti-typing argument made for novices, the kind of users I don't think an A-Z only layout appeals to, because given only the one option, it would have to have all sorts of cruft on it. The type of stuff that is supposed to be on the right.
 
The layout i propose
Has A-Z+3 extras  +4 if you can do without keyboardshift
All 15 US dead diacritics, and a one-press compose key
A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default
Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.
Fn available for everything besides F-keys and FN+power
 
What more is there to implement? Where can it be better?

 

[Saber]

This thread is like the movie Groundhog's Day. These "fresh" ideas and the ensuing comments to them are the stale regurgitated ones from days previous. Pat on the shoulder and a hear hear from the audience when the alarm clock goes off, again.  

 

[Eight Bit]

/me shamelessly plugs his own keyboards again and grabs popcorn

 

[Grench]

The layout i propose

Has A-Z+3 extras  +4 if you can do without keyboardshift

All 15 US dead diacritics, and a one-press compose key

A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default

Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.

Fn available for everything besides F-keys and FN+power

What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.

CK's layout is dead on arrival. It has 4 Alt keys. Only two can be mapped, Left Alt and Right Alt. Right Alt and AltGr are the same thing.

It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.

Four Alt keys or three shift keys are not minor things to get past. They are fundamental flaws.

 

[Neelix]

If we would go with your proposal (only ASCII and dead diacritics labeled, no precomposed letters for German and French), then I think that a lot of French/German people would prefer to simply use the default, labeled layout (using dead diacritics, even though it's less efficient), instead of selecting a language-specific layout where they have to remember the locations of the keys (or look at on-screen cheat sheets).

For me personally, that would be fine (I rarely use French and I don't really use German at all), but I think that a lot of French/German people would only consider the device to really support their language if their (important) letters are actually labeled on the keys themselves.

Well I can only speak for myself, but I use a keyboard with no international symbols printed on it at all. I use the US International layout which has É but no È. The latter I need to use dead-grave to compose. For the former, while I could compose it manually, I always use the unlabelled É that I know is on AltGr-E. Similarly, If I want ç I know I can find it on AltGr-,. I don't even type that much in French, but I learned those locations after only a couple of uses. My point is that the fact that these pre-composed letters are not printed on the keyboard doesn't make them any less useful.

I'm not saying don't have a default French/German letter layout on the dynamically assigned keys, just that those letters don't necessarily have to be printed on the keymat to be useful, and that not printing them gives us greater flexibility to cater to a wider audience.

- Neelix

 

[_wb_]

I guess there is something to be said for that, Neelix.

Something like this then?

http://www.keyboard-layout-editor.com/#/layouts/f602dae8275387d97e65ccc2a735639f

It has room for a German/Scandinavian triangle cluster at FCV, for ÜÖÄ (with ß at S which makes sense) or ÅÖÄ or ÅØÆ or ÅÆØ.

Iberians could have ç and ñ at their natural places. And so on.

I could certainly live with that.

 

[WizardStan]

CK's layout is dead on arrival. It has 4 Alt keys.

Remember, CK is defying wisdom and calling fnmetamodsym "AltGr". That is a problem but it's not why his keyboard fails.His keyboard fails immediately because he is treating the space bar as two distinct keys when ED has made it quite clear that it is going to be one wide key. Take that extra key away and he'll have a hard time maintaining his "clutter free" stance.

 

[Neelix]

I guess there is something to be said for that, Neelix.

Something like this then?

http://www.keyboard-layout-editor.com/#/layouts/f602dae8275387d97e65ccc2a735639f

It has room for a German/Scandinavian triangle cluster at FCV, for ÜÖÄ (with ß at S which makes sense) or ÅÖÄ or ÅØÆ or ÅÆØ.

Iberians could have ç and ñ at their natural places. And so on.

I could certainly live with that.

I could live with that too. (though my preference is still for making use of meta+shift to for the punctuation symbol pairs)

- Neelix

 

[_wb_]

I can live with Shift+Meta pairs, but I have some minor objections against it:

• 3 labels on some letters and 1 label on most other letters feels a bit "unbalanced", as in: why put all the symbols cramped together when there is plenty of room to spread them more evenly?
• two modifiers for some symbols, even if the modifiers can be mashed on the keyboard and easily chorded on the shoulders, is somewhat harder to do than just one modifier per symbol
• I would like the Pyra keyboard to be strictly better than the Pandora one in all respects, including the ease of typing symbols like _+:"?
• If we can cover ASCII with only three layers (primary, Shift, Meta) then the basic layout is conceptually somewhat simpler than if we need four layers
• for dead diacritics it is nice if Shift " ' - / are available for dead umlaut, acute, macron, stroke respectively

 

[Saber]

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


...


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

 

[Grench]

The layout i propose

Has A-Z+3 extras  +4 if you can do without keyboardshift

All 15 US dead diacritics, and a one-press compose key

A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default

Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.

Fn available for everything besides F-keys and FN+power

What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.

...

It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.

...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

Not interested in applying the effort to testing someone else's bad idea. This falls into the category of, "Even if something is possible, that does not make it a good idea." Three shifts is bound to be confusing AND is a colossal waste of a key.