It's the keyboard layout.


Is this really too much clutter?
I personally like it, but I suppose as an English only speaker my opinion is weighed less.
Au contraire, mon frère! English-only speakers are an important minority in this community, according to the language poll!

Especially when it comes down to judging the "burden" of multilingual "clutter", English-only speakers is pretty much the most relevant group to consider, because they have to "suffer" the most "foreign stuff".
 
Last edited by a moderator:
Is this really too much clutter?
Dont get me wrong, I think it is way cleaner than some that has been proposed and I have loads of respect for the work many here has put into the layout and keymat. but I count 7 red prints that i with 100% certainty will never use (german and french?)- I will still have to Spend time on them every time i try to find a symbol my fingers dont know. When i look at it, i clearly see it is not really inteded for norwegians. Compose key for for æ and å, and a presumably dead strike key for ø will take a long time getting into my fingers, these are dedicated on all norwegian keyboards and I will need to remap these.


I have not gone to any length exploring keyboard layouts though, but I believe in the functional area concept.


Cheers.
 
After 71 Pages I come to the personal conclusion that one single layout does just not satify everyone. So the logic suggests to make various layouts to cover the different regions, at least the major ones.
It really took you 71 pages? For the latter part of your statement, I don't believe making different keymats for other regions is feasible due to cost.
 
I don't think region-specific keymats would be a good idea, because:

  • Other than shuffling the letters and number row symbols around to the QWERTZ and AZERTY positions so people feel more "at home", there are not enough keys to really make it significantly more efficient than one universal layout, e.g. a German keymat cannot look like a real German keyboard with dedicated keys for ÜÄÖß, because we simply do not have room for them.
  • It would add cost.
  • It would make ordering and shipping more complicated.
  • It would make the logistics harder (how to estimate how many of each regional keymat to order? there will be more "wasted" / unsold keymats)
  • It would make software support harder, because Pyra devs cannot count on one single default layout
In other words, relatively little gain, big loss.

I do think that it is possible to make one single layout that satisfies everyone. Not everyone will love it, obviously, and there are lots of things that are mostly a matter of taste, even stupid things like the color for the auxiliary labels. But I do think that it's possible to have one single layout that works 'well enough' for everyone*.

* where "everyone" is defined as Europeans, Americans (North/Center/South), and Australians, to the extent that they use Latin-script based languages, and they are not comradekingu.
_wb_, ghostpatch, Sepulep, comradekingu, Ziz, EvilDragon, FIQ, Lykurgos, LEOXD, hns, Mute, WizardStan, rygD, Pritchy, Kiga, Ryo Hazuki, _jr_, Levi, Burb, N3Cr0, khalismur, nobgu, 3xcl4m4t10n, xiongxioi, Fahrstuhl, pndrsky, Djhg2000, Ligachamp, F_Slim, Lafazar, gardrek, Majin Wamu, laserbeams, mzw, ible, Lennaick, Løra (Lolla)

 

Those are the people that voted for having a wider keyboard. Including you, in your vote. The majority actually. Thats all they asked for. Otherwise top notch attempt to marginalise me.

 

In my vote, the winner was
bullet_star_rated.png
Fullest possible english layout by default against
bullet_star_rated.png
Reduced english layout by 25-7.

 

You can have a look at the map, or ekis work, same story. Its all very clear when you dont lump europeans together, but instead look at what their languages are, and what their keyboards look like.

 

Why is it that going from azerty to qwerty has a discernible benefit, but taking away whole typewriter keys is supposedly irrelevant?

 

There is room for ÜÄÖ and keyboardshift. By your own less used admission, that is a lot better than having none of them. If you are sufficiently advanced to use shouldershift, there are enough keys for all of them. AltGr+s to type ß is in terms of standards, as close as it gets.

 

It should come as no surprise that the same is possible for other western european nations.

 

Printing anything on the keymats adds cost too, and it shows how your argument doesn't account for adding value. The prospect of unsold devices (costing 500+ €) is a lot more costly than sitting on an inventory of unsold keymats. I should think the lesson has been learnt, and that overstocking will not occur.

 

People have already shown interest, there is no reason to doubt they will lay money on the table. Even upfront.

 

It doesn't have to happen right away, but making additional keymats adds little trouble if you have software issues in mind at the design stage. Designing for helping with that issue is a bonus, not a detriment.

 

If we go back to the ED argument, who are the «normal people» that are fine with everything mixed? Its not English people, because they are largely monolingual. And it sure isn't international people, because they have non A-Z layouts.

 

People that can make due with diacritics in the wrong places, with non-dedicated invokers, is not a huge market that I can see. And its very much an untested one.
 
Last edited by a moderator:
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.

Is this really too much clutter?
Dont get me wrong, I think it is way cleaner than some that has been proposed and I have loads of respect for the work many here has put into the layout and keymat. but I count 7 red prints that i with 100% certainty will never use (german and french?)- I will still have to Spend time on them every time i try to find a symbol my fingers dont know. When i look at it, i clearly see it is not really inteded for norwegians. Compose key for for æ and å, and a presumably dead strike key for ø will take a long time getting into my fingers, these are dedicated on all norwegian keyboards and I will need to remap these.
Yes, Norwegians will have to remap, or use something like US-International with Æ Å Ø on the AltGr layer (where AltGr would be a shoulder button). They are in my opinion too small a language (even if you add Danish too) to "deserve" three extra labels. If more labels are added, ç and ñ would get higher priority than å æ ø.
 
Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)

By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.

One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.

- Neelix
 
Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)

By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.

One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.

- Neelix
Trying to keep track of _wb_'s layouts is like herding cats.

So what you would like is something like this with the non-English characters in the Fn layer not printed?

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

Yes, that is one of mine based on a _wb_ layout. I didn't want to sort through his to find one similar.

Another option would be to do something like this with the English standard Fn layer characters in bold and the rest 'standard'. I wish we could sneak in a 3rd color - actually just a darker shade of the 2nd color - but that would be a 3 color print job and more expensive. I'm not sure if I would want to 'just leave them off' though.

If you give the attached one a mental run-through, I think you'll find it very efficient for most tasks.

Edit: Oh, almost forgot - for those keeping score, this one meets the all of ED's suggested features and functionality, with the exception of the few that have been proven illogical (DosBox without Fn+shift, no Fn) or silly (3 shift keys).
 
Last edited by a moderator:
Scandinavia bought a lot more devices than their numbers constitute. And thats _without_ language-support. Did you forget your own language poll too? Flurg4life.

So if a poll was made asking what is more important, the wider keyboard that people want or AltGr closer to its 10-finger position, you think people would come down on the side of the latter?
 
Last edited by a moderator:
Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)

By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.

One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.

- Neelix
 That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?

Another option would be to do something like this with the English standard Fn layer characters in bold and the rest 'standard'. I wish we could sneak in a 3rd color - actually just a darker shade of the 2nd color - but that would be a 3 color print job and more expensive. I'm not sure if I would want to 'just leave them off' though.
We don't need a third color for that: just big and bold for the ASCII symbols, and small and thin for the (default) foreign letters.
 
Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)


By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.


One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.
Trying to keep track of _wb_'s layouts is like herding cats.


So what you would like is something like this with the non-English characters in the Fn layer not printed?

http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb
I was thinking more along the lines of this one, but leaving the meta layer of W-T, A-H and Z-M unprinted.

That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?
Yeah,  I'd say that sounds like a good basis for the default assignments for those keys.

- Neelix
 
I was thinking more along the lines of this one, but leaving the meta layer of W-T, A-H and Z-M unprinted.
I can live with that layout - it is very similar to the one I posted in the above example.

Personally, I would be just fine with leaving all of the non-English characters off - it wouldn't change my use of the device a bit. However, I can understand the need to 'Internationalize' this so that the one key mat can 'work' for the broadest spectrum of Western European languages.

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.
 
Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)

By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.

One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.

- Neelix
 That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?
Why not provide a default that works even better for English, French and german, and do the rest as per described? That is the compromise.
wb said:
PERFECT: All commonly used letters are available as primary keys
 I should think language is more important to the target demographic than symbols. Maybe we should ask the userbase if greek and extra math provisions are wanted too.
 
Last edited by a moderator:
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
 
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
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.
 
Last edited by a moderator:
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.
 
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
 
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.
 
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:

Latin_keyboard_layouts_by_country_in_Europe_map.PNG


     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.
 
Last edited by a moderator:
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:

Polish_programmer%27s_layout.PNG


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.
 
Back
Top