It's the keyboard layout.

[Neelix]

A mental map for a full sized keyboard is almost entirely irrelevant to something completely different that you use with (mainly) two thumbs rather than (almost) ten fingers...

I disagree.   One of my biggest issues with the Pandora keyboard is having to search for relatively common symbols that aren't anywhere near where I expect them to be.  

This layout gives me exactly that,  all the common symbols that I expect to find on the right side of the keyboard are clustered there on the right side of the keyboard, so I don't have to stop and scan the entire layout looking for the one I need.

Give some of these symbols their unseen DOSBox compatibility pairings

There's no point in mapping "unseen" Dosbox compatibility pairings...   Dosbox will map the corresponding symbols there anyway. The entire problem is that they *are* unseen there but are seen elsewhere, and the visible versions of those symbols don't work in that context.

- Neelix

 

[comradekingu]

That works for you, of course. However you have to see all those foreign symbols, thats not good. For international users the functionality isnt there, because keys are missing for a start. If you meet up half-way everyone can be happy. Putting symbols on letters isnt an expected way to deal with lack of buttons. The orange-key is expected when there are no other options, but there is.

A mental map for a full sized keyboard is almost entirely irrelevant to something completely different that you use with (mainly) two thumbs rather than (almost) ten fingers...

Having keys visually easily distinguishable from each other makes keys very much easier to find and makes learning very much faster, enabling a different mental map to be established without difficulty

Additionally its clear layout caters to a wide range of languages without inconveniencing too much the major languages, which is a fair and usable compromise.

How am i then able to touch-type on a pandora? I didnt learn that on a pandora, i brought that along with me.
The important part is that mental map. If you re-position things it doesnt matter if you make a visual thing out of it, its breaks efficiency of habit.

Putting things where they dont belong, done to the extreme, means people question the whole rationality behind the keyboard. There are some very distinct no-no's that your visual argument doesnt account for.

It comes short of explaining how a keyboard works, and its a preliminary stop-gap.

Compare it with real functionality for English and international users, visual pleasantness via extra keymats with little change. The visual nature of these two dont have to conflict.

The problem is now not on the user, nor on the software.

 

[_wb_]

I really like http://www.keyboard-layout-editor.com/#/layouts/59b8d3798a51d7b42872963c7cba7071


Its so clear I could instantly see all the symbols - so "mental mappings" are irrelevant.


Its a shame a very vocal minority will slap this down so they can run some 30+ year old software conveniently....


Have you double checked for language compatibility, how does it do?


Really nice clear layout, well done!

Here is a variant of the above, with the "international" stuff removed:

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

Other than that, it is exactly the same. Everything would do the same, it would just not be labeled.

I personally prefer to have the labels for üäößéèàçñ (and € °) printed, even if I don't really need them myself. But according to the big comparison table (columns J and K), it would be slightly better without those labels, mostly because comradekingu and _jr_ really don't like extra labels.

I would suggest to print the üäößéèàçñ€° in a small font, so it does not add too much visual clutter. Still I think it's useful to have them labeled, so you don't need a manual to find out where those letters/symbols are.

Advanced users can remap stuff themselves, tweak everything to exactly how they want it, and type blindly so they don't care about the labels. The labels printed on the keymat should not aim to maximize æsthetics for advanced users, but it should aim to be "good enough" for "almost everyone", without needing custom remappings.

Maybe you could jetison the Ñ(that was on the N key) and use this spot for something of more importance, since { } and [ ] are too far inward for comfort?

Like this? http://www.keyboard-layout-editor.com/#/layouts/b27512781b9633d89b088d83f3648b6f

Yes, that's much better.

Possibly migrate ; and : to Meta + , and . so ' and " can be on the right(like B-Zar has them). Give some of these symbols their unseen DOSBox compatibility pairings, and add in that Super Meta key I was talking about to the left side where Meta is now(move Shift to where single and double quotes was and carry regular Meta to the left corner for good use). Then we can load up WERT, ASDF, and ZXCF if we must with locale letters and vowels. Borrow my Print Screen, Pause/Break, Scroll Lock idea if you'd like to put on Backspace. Whatever you think helps.

There's a good reason why ,<  .>  ' " do not have Meta labels in my proposals: I propose to let them be dead diacritics in a rather mnemonical way:

Meta +              ,<      .>      ' "

corresponds to   ¸ˇ       .ˆ     ´ ¨

Add greve and tilde at Shift+` and Shift+~ and all important diacritics are covered.

What would you need a "Super Meta" key for?

 

[Saber]

Give some of these symbols their unseen DOSBox compatibility pairings

There's no point in mapping "unseen" Dosbox compatibility pairings...   Dosbox will map the corresponding symbols there anyway. The entire problem is that they *are* unseen there but are seen elsewhere, and the visible versions of those symbols don't work in that context.

- Neelix

Although I'd rather we duplicate these "elsewhere" keys ~ { } | _ + : " ? before, since DOSBox will do this automatically, as it's done at Shift + Fn on the Pandora: http://pandorawiki.org/DOSBox#Keyboard, it doesn't matter when it happens in the chain.

What would you need a "Super Meta" key for?

In your today layout we wouldn't, but it's so people won't need to press Shift and Fn together plus another key.

 

[Saber]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

 

[ible]

I agree we have gone far afield of the original Saber layout which started this thread.

In homage, here's an ible version

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

 

[Grench]

Its a shame a very vocal minority will slap this down so they can run some 30+ year old software conveniently....

[sarcasm]Good point! Nobody would ever want to run 30 year old software on the Pyra. Let's completely ditch any capability to run any emulators. We could then put in a proprietary app store with DRM protection so that the application they purchase can be coded to only be run on the one device that they downloaded it to. Oh, and that Exagear/QEMU thing that is opening up a completely new category of games, but is effected the same way as DosBox? Nobody should be allowed to have the layout match with that either. Let's all dance around a bonfire chanting that we want less compatibility and lowered capabilities![/sarcasm]

The Pyra is a multi-function computing device with game controls. The Pandora was built for old console emulation, but turned out to get used as a multi-function computer too. The Pyra, being much more powerful than the Pandora, will have additional software thrown at it. Yes, this includes X86 games (DOS, Linux and yes some Windows games). That capability is there in the rest of the hardware. Why on Earth would you want to cripple that experience/capability/feature?

 

[szr]

Like this? http://www.keyboard-layout-editor.com/#/layouts/b27512781b9633d89b088d83f3648b6f

Yes this looks good. One question, even though pairs (at least how they are on a US keyboard) are separated, would pressing, for example, Shift + ; still produce a : or Shift + [ yield a {   ?

 

[Grench]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

So you're against the compromise layouts where we actually incorporate other's needs?
We have all learned a lot in this exercise. You're assuming EvilDragon is omniscient and already knew and stated everything that needed to be known. I argue that he wanted to give us a place to start and see where it took us. Unfortunately, it became very clear that his post had requirements that could not be serviced by the layout that he picked as his original favorite.

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.

http://en.wikipedia.org/wiki/Compromise

To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.

Compromise can be a great thing. The layouts that grew through compromise have all of the needs and most of the wants from within the community. They excel in compatibility with legacy software (DosBox & QEMU), support many languages, don't confuse AltGr as anything other than the right Alt, have logical layouts with keys near their 'normal' locations, etc...

These have HIGH functionality with very few negative compromises.

These are light years ahead of any layout that had been created prior to EvilDragon opening this thread.

These were built through compromise and collaboration.

These incorporate more user's needs and wants while remaining relatively uncluttered and simple to use.

These have all key functions neatly labeled in such a way that they should work under ANY environment.

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

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

So, are you sure you're not using the negative definition of "compromise"?

In the negative connotation, compromise may be referred to as capitulation, referring to a "surrender" of objectives, principles, or material, in the process of negotiating an agreement.

 

[Saber]

I think it's time we reacquaint ourselves with ED's initial post as some of these "compromise" layouts have diverted from his opinions, which I think carry a lot more weight toward the final layout then they are being credited for. Do what you like though.

So you're against the compromise layouts where we actually incorporate other's needs?

We have all learned a lot in this exercise. You're assuming EvilDragon is omniscient and already knew and stated everything that needed to be known. I argue that he wanted to give us a place to start and see where it took us. Unfortunately, it became very clear that his post had requirements that could not be serviced by the layout that he picked as his original favorite.

And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.

http://en.wikipedia.org/wiki/Compromise

To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.To compromise is to make a deal between different parties where each party gives up part of their demand. In arguments, compromise is a concept of finding agreement through communication, through a mutual acceptance of terms—often involving variations from an original goal or desire.

Compromise can be a great thing. The layouts that grew through compromise have all of the needs and most of the wants from within the community. They excel in compatibility with legacy software (DosBox & QEMU), support many languages, don't confuse AltGr as anything other than the right Alt, have logical layouts with keys near their 'normal' locations, etc...


These have HIGH functionality with very few negative compromises.


These are light years ahead of any layout that had been created prior to EvilDragon opening this thread.


These were built through compromise and collaboration.


These incorporate more user's needs and wants while remaining relatively uncluttered and simple to use.


These have all key functions neatly labeled in such a way that they should work under ANY environment.

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

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


So, are you sure you're not using the negative definition of "compromise"?

In the negative connotation, compromise may be referred to as capitulation, referring to a "surrender" of objectives, principles, or material, in the process of negotiating an agreement.

Calm down.

I'm taking what ED said as what ED wants which carries significant weight since he is the guy making the device and is whom we will be buying it from.  

 

[Eight Bit]

Small alteration;

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

turtle coming through!

btw, Though a good idea, I think the comparison sheet fluked as just keyboard creators voted in it. By no means it is a viable representation of the to-be user base like this. At the very least a couple 100 people need to vote in it for it to be a decent representation imo.

 

[_wb_]

Small alteration;

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

turtle coming through!

btw, Though a good idea, I think the comparison sheet fluked as just keyboard creators voted in it. By no means it is a viable representation of the to-be user base like this. At the very least a couple 100 people need to vote in it for it to be a decent representation imo.

What keycodes do those three Shift keys, three Alt keys and three Meta keys produce? And why do you have only two Ctrl keys? I want at least 5 of them!!11!!11!

 

[codifies]

[sarcasm] Sarcasm tags really prevent you from giving people the idea that you have a poor attitude [/sarcasm]

I wish when I got hold of a Pandora for the first time that my keyboard skills instantaneously transfered to using just two thumbs on tiny keys, unlike the instantly skilled I had a few days of looking down at the (fortunately) clearly labelled keys, before I was able to thumb touch type as its quite a different skill to using a full sized keyboard which did NOT transfer

Of all the retro platforms to emulate the PC DOS era is by FAR the poorest - the games of the time that used DOS and keyboard only were basically pants compared with their console counterparts, with the exception of some text adventures (were keycodes are less of an issue and better emulated on other platforms (z-machine is everywhere!) )

Later when games became better on PC they were much more configurable (joystick or actual choice of keys :-o ) which makes a rigid keymap less needed

Why wreck a keyboard that could be great for coding, email, letters, browsing, etc etc Just for one retro corner case that's just not worth it ...

 

[Eight Bit]

The shoulder buttons could just be a copy of either left or right meta and Shift. You might think it's too much but I think it'll be awesome having meta or fn or whatever on both sides of the keyboard as well as on the shoulders. Try pressing F11 on the Pandora for instance. it's ackward and uncomfortable.


But anyway, constructive criticism is always welcome so if you (or any one else) has a great idea to improve on this, pls let me know.

 

[comradekingu]

So if we divide all users into first English and International

The English users dont want foreign symbols, ED doesnt want dedicated diactrics symbols. International users want/need dedicated keys, but we cant give up any buttons for it. Because the keyboard doesnt have any extra buttons to spare.

Usecases, Writing, playing games, using the OS, coding (more?)

Writing letters is covered by the above compromise. The most used arrangement of symbols is the US shift-row, that can be combined with US-international diactrics so that you avoid
EDs gripe above and still can input all different things.

Some users are even interlingual, so to deal with this, the interlingual letters can be on the hidden AltGr layer, again respecting english users wish not to have foreign letters visible.
That works well, with German, Spanish and italian, but is not yet solved for French. The symbols from the non-A-Z keys that cant be given up, are also duplicated on this layer, so users are
free to put in their language-modifiers or dedicated letters.

Before we dvelve deeper, do we all agree to give this much so that no big group is excluded?

From my understanding ED wants "all users" and doesnt want to scare away "new prospective buyers" if i remember it verbatim.

Those are good points, I think we should also cater to the very lowest denominator. This is compatible with sleekness.

Are there any special things that need to be implemented that are so good that new/novice users cant use a pyra?

 

[_wb_]

Like this? http://www.keyboard-layout-editor.com/#/layouts/b27512781b9633d89b088d83f3648b6f

Yes this looks good. One question, even though pairs (at least how they are on a US keyboard) are separated, would pressing, for example, Shift + ; still produce a : or Shift + [ yield a {   ?

That could be done. But why?

If qemu/dosbox is the main reason for wanting to have : { } etc at Shift+ ; [ ] etc, then the best solution is to adapt/configure qemu/dosbox so that it provides better emulation for an IBM-PC keyboard on the Pyra keyboard. Just like a C64 or Amiga or whatever emulator needs to be adapted or configured to emulate the C64 or Amiga keyboard on the Pyra keyboard. We shouldn't let legacy devices dictate how we layout the keyboard.

I still don't have strong feelings w.r.t. the main design choice we are left with (besides comradekingu's stuff): do we use Meta+Shift for {}:_+?~ etc, or do we map everything to just Meta?

There are reasons for both:

• Using Meta+Shift means less keys are needed to map the 9 "missing" symbol keys -=[]\;'/`  and their Shifted values _+{}|:"?~, so they can be mapped closer to their normal position, and more keys are available to do other things like non-ASCII symbols / international support. Possibly some applications will work better or require less configuration/bugfixing if they assume standard symbol shift-symbol pairs.
• Using Meta only means all symbols can be inputed using only one modifier (reducing potential chording issues), and two labels per key are possible which means bigger font sizes can be used. There is still room left for e.g. àèéç ñ üöäß € °, and many people seem not to want language-specific precomposed letters labeled on their keymat anyway, so why would everything be cramped onto just a few keys? Keeping all the letter keys free of Meta-labels is impossible anyway (unless you go the comradekingu route and apply tricks like an extra modifier for F-keys and wobbly space effects).

 

[codifies]

The English users dont want foreign symbols,

I'm a UK user and I DO want diacritics but I don't want them to crowd making the keyboard difficult to learn (and they don't need to)

I wouldn't be so ignorant to demand that the keyboard only catered to English - its an international device isn't it?

 

[Saber]

Version 3.0.

• Removed the DOSBox compatibility layer symbol set from my 2.1 layout(though they are still attendant here).
• Added three of the most important dead key diacritics as I see it on Fn + u, n, and m. Shown underlined as they may be on the actual keycaps(like here) they are Dead Circumflex, Dead Grave, and Dead Acute but could as always be remapped by the user into something else. Ä, Ö, Ü, and ß are also user remappable if desired.
• Changed one of the keyboard Shift keys back to Right Shift until it's proved advisable not to have it there.

 

[Grench]

The English users dont want foreign symbols,

 I'm a UK user and I DO want diacritics but I don't want them to crowd making the keyboard difficult to learn (and they don't need to)

I wouldn't be so ignorant to demand that the keyboard only catered to English - its an international device isn't it?

I'm a US English only (OK, some minor Spanish use), but I don't mind giving a nod on the Fn layer to the added support needed to create the characters in more languages.

That is why I like this compromise solution:

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

English use is very clear and easy to find.

The non-English keys are on the left 2/3 of the Fn layer where I don't have to be concerned by them.

The primary diacritics are paired to their base key sets. Easy to get to them if you want them, easy to ignore if you don't.

All key pairs are retained. DosBox should be happy.

All of the symbols are either on the top layer (most commonly used ones are) or near their normal US locations on the Fn layer.

Symbols !@#$%^&*()`~'",<.>[];\-= are all 24 available with either no or a single modifier (none or Fn or Shift) key.

Symbols |_+{} are the only 7 requiring chording Fn+Shift.

 

[_wb_]

This is the best I can come up with for a Shift+Meta layout:

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

It covers English, German, French, Spanish, Portuguese*, Italian**, Scandinavian languages, most Balto-Slavic*** languages

* if tilde is made a dead key so you can type ãõ

** if grave is made a dead key so you can type ìò

*** not very efficiently; you would need to use dead caron, ogonek, etc a lot

(You could of course drop support for some or all of those languages and simplify the labeling, but why have a backlit keyboard and make room for extra symbols by squeezing \|-_=+[{]};:/? together, if all the extra room goes unused and people have to remap&remember anyway?)

This is the best I can come up with for a Meta-only layout:

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

It covers English, German, French, Spanish*, Portuguese, Italian.

* without the ¡¿ labeled; Shift+? is available for ¿