It's the keyboard layout.

[ible]

If I want to say something about Slavoj Žižek, it's nice to be able to spell his name correctly, for example.

Well, only if you want to say something nice

I do think international "clutter" is a nice selling point, especially in Europe.  We'll have to see what ED prefers, if he just wants to go English and German mostly.  (That is the biggest market, apparently.)  But In case ED only wants hardware keys up top (i.e., _wb_ can't put Esc up top), with a little more natural spots for vowels and other accented symbols:

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

But if there's no restrictions on keys up top, I thought it more natural to put functions you might actually want to use in game on the outer upper keys.  Those should be quite easy to press in a game using the nubs -- here's a mouse button added (M1 and M2):

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

how certain buttons work in the spoiler.

Spoiler

Here the LED button works like _wb_ had in a few layouts previous -- shift to get keyboard LEDs, Meta to dim. The hardware button could be reduced to one gear button symbol, but this is the functionality I might cram in it if I could.  Perhaps the mouse button could be put in as M3 and M4 (mouse 3 and 4), so they don't duplicate nub presses, but I would probably have a default map to M1 and M2.  (Or vice versa:  hardwire the nubs to M3 and M4, and make them default to M1 and M2.)

 

[Eight Bit]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

Your best keyboard so far imo. I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

 

[Saber]

Thanks to Wikipedia I made the hopefully accurate list below for all these specific language orthographies. Every one of them passed with my v3.0 layout with the assumption that the user isn't hopping from one nationality to another. The exceptions, in only a few cases, are the "very rarely" types which were inconsequential. Bolded letters means they'll need to be(and can be) remapped over one or more of the keys for ä, ö, ü, ß, or the three diacritics(dependent on which are or aren't required for the native alphabet). 

My v3.0 layout again:

Spoiler

Spoiler

Dutch: á, é, ó, ú, ë, ï, and very rarely used â and é.

Estonian: ä, ö, ü, õ, š, ž.

Finnish: å, ä, ö, and very rarely used š and ž.

French: é, à, è, ù, â, ê, î, ô, û, ë, ï, ü, ç, and very rarely used ñ and ÿ.

German: ä, ö, ü, ß.

Hungarian: á, é, í, ó, ú, ö, ü, ő, ű.

Italian: à, è, é, ì, í, î, ò, ó, ù, ú.

Norwegian: é, è, ê, ó, ò, â, ô, å, æ, ø.

Polish: ć, ń, ó, ś, ź, ł, ż, ą, ę          

Portuguese: á, â, ã, à, é, ê, í, ó, ô, õ, ú.

Spanish: á, é, í, ó, ú, ñ.

Swedish: å, ä, ö.

Turkish: â, î, û, ö, ü, ç, ğ, I, İ, ş.

Spoiler

In Dutch we also need ü and ö for Dutch words like "reünie", "vacuüm", "coöperatie", "coördineren", "zoölogie" (ä only for loanwords like "salonfähig"), and ê for words like "enquête", "gêne", ç for words like "reçu", "façade", "Brabançonne" (the name of the national anthem in Belgium, where most people speak Dutch).

So your suggestion is that we remap ä and ß to ë and ï and just avoid writing some words? Or perhaps ü to ¨ and ß to ç, then everything can be typed. I guess that could work. It would be tricky to remember (after all, we don't need those special letters very often, so it's not something you would get used to quickly), but possible. Just using Compose sequences would be what I would most likely do in practice though.

If remapping üöäß to language-specific letters is good enough to say a language "passes", then yes, you can "support" a lot of languages. But I don't think it's very user-friendly to have to remember remappings. E.g. for Spanish you would have to remember that the key labeled ä is really a ñ. Or was it ö?

Nothing tricky(or sneaky maneuvering here) about remapping in my layout. I have full confidence the Spanish user can remember they had mapped their ñ onto ß, or n. Accounting for the dead key diacritics Circumflex, Grave, and Acute, which reduce the bulk of the need for local letter outputting with Compose, my layout, moreover, has ä, ö, ü, and ß for any additional and optional reassignments handy. Most users will find their principal language is comfortable to type on the Pyra keyboard. 

So I think a more multilingual layout like http://www.keyboard-layout-editor.com/#/layouts/d7e5a0dab3f707566068e641e29c84d9  is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

 

[sebt3]

Please, the reply for this was 22 pages ago...

 

[_wb_]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

Yes, my layouts are optimized for handheld use (i.e. shoulder modifiers), while they also work well (though slightly less efficiently) for tabletop use.

I think that makes sense. It is a handheld, after all.

I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.

I honestly don't understand why they wouldn't, if the device is held in the hands.  Frankly if people want to make things difficult for themselves by not taking advantage of all the available modifier buttons that's their own lookout.  

Once the device is on a dock or desktop the ergonomics change and having the modifier on the same side of the keyboard is less of an issue.

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

- Neelix

 

[Neelix]

Please, the reply for this was 22 pages ago...

You mean all this time we've been arguing in circles this whole time??   We'll need to start leaving a trail of diacritics so we can see where we've been.

- Neelix

 

[Saber]

So I think a more multilingual layout like http://www.keyboard-...068e641e29c84d9is worth the little bit of extra "clutter".

... I could live with this lay-out even though I'd rather have the language specific letters hidden and/or on the right side of the keyboard and the common symbols opposite of Fn. I like the fact that you changed your mind and made it pandora compatible with the Fn on the bottom right.

Nail meet head right there. It's very shoulder Fn/Meta biased as are all his layouts by his own admission. Common(high frequency of use) symbols / ? ' " ; : [ ] { } - _ = + should be on the opposite side of the keyboard modifier that constructs them. It flagrantly violates that what should be obvious ergonomic. 

Yes, my layouts are optimized for handheld use (i.e. shoulder modifiers), while they also work well (though slightly less efficiently) for tabletop use.

I think that makes sense. It is a handheld, after all.

I've said this many times now that not everyone will use the shoulder Fn/Meta modifier with the keyboard.

I honestly don't understand why they wouldn't, if the device is held in the hands.  Frankly if people want to make things difficult for themselves by not taking advantage of all the available modifier buttons that's their own lookout.  

Once the device is on a dock or desktop the ergonomics change and having the modifier on the same side of the keyboard is less of an issue.

New users will of course need to be educated, and  I think a good way to make it known to new users that the modifiers are on the shoulder buttons  (and that home, end, etc are on the gaming buttons) is  by putting up a key map as the default wallpaper.

- Neelix

Will this "education" you and Neelix talk of involve a large T.V. screen in a dark room with some hard paddling and gummi bear rewards?  

I don't want the old or new user to be subjugated to "triggergate". I want the device to work without this constraint.

 

[_wb_]

Here is a layout with the punctuation you need for natural language all on the left:

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

(I also made the keys a bit thinner so they have a more realistic aspect ratio)

Features:

• , . ' " ; : / ?  all on the left, so you can easily input natural language without using shoulder Meta.
• - is a Meta-mash combo
• the ÜÖÄ triangle has Ü on U
• ç and ñ on C and N

Disadvantages:

• it looks more like an arbitrary splatter of symbols than some of my other proposals

 

[Urben]

I cant say it looks bad, having them at one place makes it easier to know where to look for it.

 

[_wb_]

Here another one, now with the "foreign stuff" clustered in the middle:

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

The [] /|\ {} cluster is strategically positioned for the command line: ~/ and ./ are easy combos, for example.

On the right you have ? ; : in their expected US-QWERTY locations and around space, for easy [punctuation space] combos.

I kinda like this one.

 

[Urben]

Yea looks very charming!

But from my own experience I think things which are looking good come with a downside...

 

[_wb_]

Still about: http://www.keyboard-layout-editor.com/#/layouts/657a91653495a21fe551349c3ee89ba2
 
I made a diagram to verify that everything is covered. I am trying to be exhaustive here in order to not forget anything.
 
The basis for this exercise is the Multilingual European Subset 1 (MES-1), which is a standardized subset of Unicode which aims to cover all Latin-script languages used in Europe (which implies that North and South America are also covered if you don't consider obscure indigenous languages). MES-1 is the most recent version of a standardization process that goes back to ISO/IEC 6937.
 

This is the list of languages covered by MES-1:
Afrikaans, Albanian, Basque, Breton, Catalan, Croatian, Czech, Danish, Dutch, English, Esperanto, Estonian, Faroese, Finnish, French, Frisian
Galician, German, Greenlandic, Hungarian, Icelandic, Irish Gaelic (new orthography), Italian, Latvian, Lithuanian, Luxemburgish, Maltese,
Manx Gaelic, Moldavian (new orthography, with restrictions), Northern Sami, Norwegian, Occitan, Polish, Portuguese, Rhaeto-Romanic,
Romanian (with restrictions), Scottish Gaelic, Slovak, Slovenian, Lower Sorbian, Upper Sorbian, Spanish, Swedish, Turkish, Welsh

Here is the chart:
https://docs.google.com/spreadsheets/d/1ok7-yZKT2pJ4_3o0LZTLytMxqnQGc5yQtc3mHyyuES4/edit?usp=sharing

It should include all 335 characters of MES-1. For every single character, it is indicated how you can type it most efficiently in my layout proposal. Yes, it is a bit of a mess. Languages are messy things.

I found one 'bug' in my assumptions: even though Ł can in a sense be considered as L with kreska, which is a Polish acute, we cannot use dead acute + L for Ł ł because L with acute (Ĺ ĺ) also exists (in Slovak), which is by the way not to be confused with L with caron (Ľ ľ) where the caron usually looks like an apostrophe. To solve this, and to also cover the Croatian Đđ, the Danish/Norwegian Øø, the Maltese Ħħ and the Northern Sami Ŧŧ, I decided to follow the Compose convention and use slash / for letters with a stroke or crossbar. Shift+/ can act as a dead diacritic to produce ĐĦØŁŦđħøłŧ.

I also added Shift+minus for dead macron, to get ĀĒĪŌŪāēīōū.

Here are the conclusions in terms of coverage:

The only letters that are not covered in two thumb presses by my layout are the following: Ææ Œœ Þþ Ðð Ŋŋ ĸ. For these you would need a Compose sequence (AE OE TH DH NG KK respectively), which takes three thumb presses. This makes typing Danish (5.5 million speakers), Faroese (66,000), Greenlandic (60,000), Icelandic (330,000), Northern Sami (~25.000) and Norwegian (5 million) less efficient to type. (For French, the missing Œœ is not a big deal).

The biggest problem is for Danish, where Æ has a letter frequency of 0.97% (which is between that of K and V in English). In Norwegian, Æ has a letter frequency of 0.26% (about the same as the letter J in English). So having an easier way to type Æ would be useful. Perhaps it would be justified to remove § (so you would have to do Compose S O) and replace it with Æ. On the other hand, it is weird to have one-thumb Æ but still need two thumb presses for Å and Ø, which are more important letters than Æ in Danish and Norwegian. So I think that it makes more sense for Norwegians and Danish people to just remap Å Ø Æ (in their favorite positions, which differs between Danish and Norwegian keyboards) over Ü Ä Ö, which is probably something they are somewhat used to do if they ever typed on a German or Swedish keyboard before.

The other symbols (Þþ Ðð Ŋŋ ĸ) for which you are forced to use the Compose method, are only used for Faroese, Greenlandic, Icelandic and Northern Sami (total number of speakers: less than 0.5 million).

Note: do not confuse the Ðð (eth) of Old English, Faroese and Icelandic, which I don't efficiently support, with the Đđ (dyet or crossed D) of Serbo-Croatian languages (~19 million speakers) [and, incidentally, Vietnamese (~75 million)] which is available in two thumb presses.

To go back over the list of languages: I have indicated the languages that are supported perfectly in bold (meaning that all letters are available in one thumb press, or two thumb presses if the letter would also require two thumb presses on a standard keyboard for that language). The others need at most two thumb presses per letter, which is still quite reasonable, except the ones in red which need Compose sequences (so three thumb presses) for some letters.

Languages with more than 10 million speakers are in a larger font, and languages with more than 100 million speakers are in an even larger font.

Afrikaans, Albanian, Basque, Breton, Catalan, Croatian, Czech, Danish, Dutch, English, Esperanto, Estonian, Faroese,

Finnish, French, Frisian, Galician, German, Greenlandic, Hungarian, Icelandic, Irish Gaelic, Italian, Latvian, Lithuanian,

Luxemburgish, Maltese, Manx Gaelic, Moldavian, Northern Sami, Norwegian, Occitan, Polish, Portuguese, Rhaeto-Romanic,

Romanian, Scottish Gaelic, Slovak, Slovenian, Lower Sorbian, Upper Sorbian, Spanish, Swedish, Turkish, Welsh

I'm quite happy with this coverage. The Scandinavian languages (including the insular ones) are the biggest remaining problem. I see no easy solution for them, except just using something US-International or remapping üäö to åæø.

 

[Hồng Thất Công]

Thanks to Wikipedia I made the hopefully accurate list below for all these specific language orthographies. Every one of them passed with my v3.0 layout with the assumption that the user isn't hopping from one nationality to another. The exceptions, in only a few cases, are the "very rarely" types which were inconsequential. Bolded letters means they'll need to be(and can be) remapped over one or more of the keys for ä, ö, ü, ß, or the three diacritics(dependent on which are or aren't required for the native alphabet).


My v3.0 layout again:

Spoiler

Spoiler

Dutch: á, é, ó, ú, ë, ï, and very rarely used â and é.


Estonian: ä, ö, ü, õ, š, ž.


Finnish: å, ä, ö, and very rarely used š and ž.


French: é, à, è, ù, â, ê, î, ô, û, ë, ï, ü, ç, and very rarely used ñ and ÿ.


German: ä, ö, ü, ß.


Hungarian: á, é, í, ó, ú, ö, ü, ő, ű.


Italian: à, è, é, ì, í, î, ò, ó, ù, ú.


Norwegian: é, è, ê, ó, ò, â, ô, å, æ, ø.


Polish: ć, ń, ó, ś, ź, ł, ż, ą, ę


Portuguese: á, â, ã, à, é, ê, í, ó, ô, õ, ú.


Spanish: á, é, í, ó, ú, ñ.


Swedish: å, ä, ö.


Turkish: â, î, û, ö, ü, ç, ğ, I, İ, ş.

I would love the Pyra could do Portuguese.

 

[Grench]

Here is a layout with the punctuation you need for natural language all on the left:

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

(I also made the keys a bit thinner so they have a more realistic aspect ratio)

Features:

• , . ' " ; : / ?  all on the left, so you can easily input natural language without using shoulder Meta.
• - is a Meta-mash combo
• the ÜÖÄ triangle has Ü on U
• ç and ñ on C and N

Disadvantages:

• it looks more like an arbitrary splatter of symbols than some of my other proposals

Here another one, now with the "foreign stuff" clustered in the middle:

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

The [] /|\ {} cluster is strategically positioned for the command line: ~/ and ./ are easy combos, for example.

On the right you have ? ; : in their expected US-QWERTY locations and around space, for easy [punctuation space] combos.

I kinda like this one.

Both of these are generations backwards from where we already got to.  Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use are all getting kicked to the curb and run over.

You seem to be making layouts at a rate of 1-2 per day.  Any negative comment from anyone seems to result in a completely different structure to satisfy their request at the sacrifice of every other gain that has been found over the course of this process.  I appreciate brain storming and out-of-the-box thinking, but these recent ones seem to be just a scrambled mess.

Let's get back to actual viable alternatives.  You made several.  You inspired several.

Layouts like this are far more viable:

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

 

[ible]

perhaps, but I don't think ED wants more than one meta label per key. (see OP.) otherwise he would have chosen a different layout (we had a few at the time with your qualifications). we might even lose another key to a second keyboard shift.

we are spinning our wheels quite a bit, perhaps over nothing. i agree though, that the latest _wb_ lacks some Je ne sais quoi. (he seems to be breaking his own principles.) i like http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878though.

it's iterative refinement, sometimes you make a good step, sometimes you make a bad one. i like _wb_'s idea of putting /? together and \| together, though, since those are companions on the US keyboard. Inspired by that, does anybody prefer:

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

over:

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

?

 

[_wb_]

Both of these are generations backwards from where we already got to.  Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use are all getting kicked to the curb and run over.

You seem to be making layouts at a rate of 1-2 per day.  Any negative comment from anyone seems to result in a completely different structure to satisfy their request at the sacrifice of every other gain that has been found over the course of this process.  I appreciate brain storming and out-of-the-box thinking, but these recent ones seem to be just a scrambled mess.

Let's get back to actual viable alternatives.  You made several.  You inspired several.

Layouts like this are far more viable:

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

So you claim that

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

is better than

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

in terms of "Ergonomics, location memory, DosBox/QEMU/other compliance, desktop/dock use".

Can you elaborate a bit please, because I don't really see much of a difference:

Ergonomics: not having to mash Meta+Shift for {}| seems slightly less ergonomic than having all of them behind only one modifier. Tab at Meta+Space also seems less ergonomic than a dedicated Tab.

Location memory: except for [] /|\ {} ,.<> and Tab there is not much difference in the locations of symbols. I'll admit that having symbols paired up in the US-QWERTY standard way might help people to find the symbol they're looking for. For people who are not used to US-QWERTY (i.e. most of Europe), that argument does not hold though.

DosBox/QEMU/other compliance: I think there is a consensus that this is a non-issue.

Desktop/dock use: I don't really know what you mean by this, but I don't see much of a difference either.

The way I see it, putting _+{}| on Shift+ -=[]\;/ is certainly a viable option, and it has some advantages.

One of those advantages is that it leaves more keys available on the Meta layer. In a sense that is also a disadvantage though, because we don't really have "useful stuff" to put on all those keys. I mean, sure, we can add £ Å Æ Ø ¿ ¡ and extra diacritics, but the amount of extra 'multilingual gain' we get out of that is rather limited, while it does increase the amount of 'clutter'. In terms of "languages per clutter", it is hard to make good use of the extra room.

There are disadvantages too, though. Plus and minus are on different layers. You have to make `~ a dedicated key if you want to use it for diacritics, instead of being able to apply the trick that Shift+`~ are dead grave and tilde. I can even make Shift+slash dead stroke and Shift+minus dead macron. And a keymat with only 2 labels per key is going to look cleaner than one that has 3 labels per key or more.

 

[_wb_]

perhaps, but I don't think ED wants more than one meta label per key. (see OP.) otherwise he would have chosen a different layout (we had a few at the time with your qualifications). we might even lose another key to a second keyboard shift.


we are spinning our wheels quite a bit, perhaps over nothing. i agree though, that the latest _wb_ lacks some Je ne sais quoi. (he seems to be breaking his own principles.) i like http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878though.


it's iterative refinement, sometimes you make a good step, sometimes you make a bad one. i like _wb_'s idea of putting /? together and \| together, though, since those are companions on the US keyboard. Inspired by that, does anybody prefer:

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


over:

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


?

I do.

I think it's OK to put / together with | and \ too, to make a pattern like \ | / or / | \. The latter even looks a bit like an Atari logo

We all have the problem that there are too many keys that 'belong' in the top-right corner (according to US-QWERTY), and there's no room for them all: -_=+[]\{}| is just too much. That's why I think it makes sense to make an exception for [ ] \ { } | w.r.t. the general principle that keys should be close to their US-QWERTY position (a principle that is violated anyway by , . '), and move them over to the left in a nice pattern. In particular I like it that both ./ and ~/ are easy combos in my most recent proposal.

Another rationale behind my most recent proposal is that the keys in the center are a bit harder to reach and develop muscle memory for than the keys near the edges. So by using the middle area for "international stuff", I hope to optimize the overall efficiency.

 

[Eight Bit]

Layouts like this are far more viable: http://www.keyboard-...b411baa5a39beeb

I don't feel the same way, srry

 

[codifies]

Layouts like this are far more viable: http://www.keyboard-...b411baa5a39beeb

Pros:

Meta on the correct side (oooh contentious)

Cons:

Too many symbols per key

f11/f12 isolated (seriously guys whats wrong with BS / return)

tab key second class citizen

So guess I don't agree either...

 

[TrashyMG]

f11/f12 isolated (seriously guys whats wrong with BS / return)

They are keys that if accidentally hit without the modifier could do bad things like submit or enter text by mistake or hitting backspace may delete something or go back on a webpage or something...  


The Pandora has Insert and Delete on the backspace key so maybe it may not be so bad, however my opinion is that Enter shouldn't have any modifiers on it.