Explaining keyboard layout proposals. Fn hotkeys updated, language switching, powertoggles etc

[TrashyMG]

Printscreening is not a very known use, nor a particularly common use-case.

really!? in an office/work situation where you need to capture something on your desktop and share it with others it's used quite often.

 

[_wb_]

Here is another one, not very minimalistic but quite neat imo:

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

Features:

- F-keys on number row, with F11 and F12 more or less in line

- Has all the symbols of a full ANSI US QWERTY keyboard and a standard DIN T1 German keyboard and a standard UK keyboard (except the broken bar, which I could put on Pyra+I, but it's just too silly a key to have).

- Symbols on positions that make sense: € on Pyra+E, ¥ on Pyra+Y, £ on Pyra+L, Ü Ö Ä on Pyra + UOA, ß on Pyra+S, µ (mu) on Pyra+M, PrintScreen on Pyra+P

- Bracket-like symbols (<>{}[]) all nicely together on the bottom row

- Dead key diacritics: can't use ^,*,( with Pyra as dead circumflex, dead ring above, dead breve anymore, could use Shift >,°,{ instead

- If you don't count the small red/orange F for the F-keys as a third label, it's still only two labels per key

I still prefer my previous proposal (http://www.keyboard-layout-editor.com/#/layouts/65dd2bc5c4c4bd8b750b55b27ba4dc9b), it looks cleaner by avoiding the unimportant or locale-specific symbols (²,³,§,°,ß,Ü,Ö,Ä,µ,€,¥,£,­¬).

 

[_wb_]

As an example:

Given my proposal: http://www.keyboard-layout-editor.com/#/layouts/65dd2bc5c4c4bd8b750b55b27ba4dc9b

a German could set the layout to "German" in software, and the keyboard would behave like this:

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

(where I've indicated in magenta what is different from the default)

 

[Silent-Hunter]

I do not want to lose the print screen key.

 

[Grench]

Here's another one, this time with all three Lock keys:

ScrollLock (⤓) at Pyra+X

CapsLock (⇪) at Pyra+C

NumLock (⇭) at Pyra+V

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

Requires an extra color for the numeric keypad.

I think this probably makes the labels too complicated, and I doubt people would actually use it; the staggered keyboard rows are not very well suited to emulate a number pad (although with proper care, the labels themselves could be arranged in a perfect grid). But maybe it would be nice for spreadsheet number entry stuff on-the-go. Or for calculator stuff.

If the color of those number keys is changed to something non-distracting (dark blue maybe, or to save on printing costs, just a darker shade of orange/red, like this), then I could live with it. I probably would rarely use it myself though.

Any thoughts?

I know you cut this one and moved on based on another response - who clearly doesn't do any office work.

What you have above is VERY close to ideal in my opinion.

I -like- the idea of having a numeric 10 key set embedded within the keyboard.  I think you simply missed something when trying so hard to make the numbers align vertically.  I think that the green symbols can all be 1/2 the size of the white ones to tone them down a bit.  Right now there is a mixture in the on-key positioning.  White symbols should be the left 1/2 of the key.  Green should be the upper right, orange the lower right.

In cases where one key has two white symbols (different shifted symbol other than case change), the left side of the key should be split upper/lower with the shifted version printed upper left and the un-shifted version on the lower left.

This yields the possibility for 4 mappings on each key.

Normal key press lower left  (Lower case not shown).

Shifted key press upper left (Upper case letter takes entire left 1/2 of key).

Numlock characters upper right.

PYRA (Fn) characters lower right.

Proposed Changes  to make that 10 key idea really work:

Green 7, 8, 9 stay put.  Though I would label the keys in White AND small green even though it's the same symbol.

Green ÷ gets replaced with Green -.  Nobody uses the ÷ symbol for division in modern math.  See /.

Move Green 4, 5, 6 one space to the right.  

Green + moves one to the right.  White + stays put in white and green on the same button.

Move Green 1, 2, 3 one space to the right.

Green x goes away.  Nobody uses the x symbol for multiplication in modern math.  See *.

Green 0 moves one to the right to align it down and right of Green 1 (K) where ,; is.

Green *  gets added to M key.

Green / gets added to J key.

What this accomplishes is to align the keypad in a 45* slant from top left to lower right - which happens to be the angle the fingers of the right hand will be at when interfacing with this in 10 key form.  I.e. go naturally with the slant - the hand using it will be coming in at the same angle as the slant anyway.

On INS and DEL, you had unicode symbols for those before - no reason not to keep them.

The closer we get to a finalized keyboard, the less place gigantic Greek letters on the most visible keys have in the mix - they look more and more out of place.  I may have a solution - which you will either like or hate or find humor in.  Use German vowels for those key labels - in big orange typeface.  Use the Pyra key - key combination to type them.  ED wanted them there - this is a highly humorous and very practical way to add them in.  They're not ABXYcz and they're not Greek.  They're practical AND they appear in ASCII font lists so they can be incorporated into the menu system on emulators where applicable.  (Reality is those buttons will be mapped to Pg up, pg down, home, end, ins, del - but they can still have brilliant orange German vowels on them.  Though that only covers 4, so we'll need to find another common language that just needs 2 more symbols beyond English and German ones...   Maybe French or Spanish?

 

[comradekingu]

There can only be 3 prints per key. No two symbols can be atop eachother.  Omlauts are not meant to be on the ABXY, it is not practical.

Edit: Updated firstpost.

We need more input from people who are basic computer users. Someone who is able to use a standard keyboard, but for the most part as a typewriter.

Also we need some input from ED before voting. Also to clarify what colours are available.

 

[Grench]

There can only be 3 prints per key.

Mmmm... Rule sounds very arbitrary. Where did this originate?

No two symbols can be atop eachother.

You mean in the key cap printing? Interesting - that eliminates most of the proposed designs.

Omlauts are not meant to be on the ABXY, it is not practical.

It's FAR more practical than Greek and does not have the fault of appearing in the main keyboard (ABXYcz). Using them as PYRA (Orange) characters celebrates the German origins of the system, gives a solid nod to our international audience AND gives us something in the ASCII character set to print on the keys that isn't present on the main keyboard. It's a triple win.

Edit: Updated firstpost.

Not sure what body grants you the authority to write the rules, so I'm treating that introductory material as your humble opinion or suggestion.

We need more input from people who are basic computer users. Someone who is able to use a standard keyboard, but for the most part as a typewriter.

You're berating one now. I use my Pandora primarily as a portable workstation computer - not a game machine. The keyboard and it's organization are highly important to me.

Also we need some input from ED before voting. Also to clarify what colours are available.

ED's always welcome to step in and create/validate/fabricate rules that the rest of us should follow in our creations - or even to just create a keyboard layout by his proclamation.

 

[TrashyMG]

Mmmm... Rule sounds very arbitrary. Where did this originate?

Something ED said in one of the many Pyra threads.. has to do with the smaller height of the keys.

 

[Grench]

Mmmm... Rule sounds very arbitrary. Where did this originate?

Something ED said in one of the many Pyra threads.. has to do with the smaller height of the keys.

Interesting. That would eliminate _wb_'s brilliant 4 function wireless & USB toggle - which is a shame as it's the only design yet to make efficient use of those top row buttons.

 

[TrashyMG]

Interesting. That would eliminate _wb_'s brilliant 4 function wireless & USB toggle - which is a shame as it's the only design yet to make efficient use of those top row buttons.

Well maybe symbols could be used instead to save space.

 

[_wb_]

I'm sure we can do something like on the START and SELECT buttons of the Pandora; those buttons are about as small as the Pyra keys will be, and they manage to fit the words START // ALT and SELECT // CTRL on top of one another. If that is possible, then 3G USB // wifi BT should also be possible.

Grench: something like this? http://www.keyboard-layout-editor.com/#/layouts/6ebfd384cb4ec4e4645b66ae6ae8a78f

I personally don't think Ä Ö Ü ß are good game key labels just because they happen to occur in some extension of 7-bit ASCII.

What about dropping the Greek and just using the Unicode symbols for Home/End/PgUp/PgDn? ( ⇤ ⇥ ⇞ ⇟ )

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

Still not sure about the numeric keypad though. Too much clutter imo.

 

[comradekingu]

The keys arent as tall on the pyra as they were on the pandora, and ctrl/select was a bad idea there...

Keys are 7x3 and max 3 prints per key

 

[Grench]

I'm sure we can do something like on the START and SELECT buttons of the Pandora; those buttons are about as small as the Pyra keys will be, and they manage to fit the words START // ALT and SELECT // CTRL on top of one another. If that is possible, then 3G USB // wifi BT should also be possible.

Grench: something like this? http://www.keyboard-layout-editor.com/#/layouts/6ebfd384cb4ec4e4645b66ae6ae8a78f

I personally don't think Ä Ö Ü ß are good game key labels just because they happen to occur in some extension of 7-bit ASCII.

What about dropping the Greek and just using the Unicode symbols for Home/End/PgUp/PgDn? ( ⇤ ⇥ ⇞ ⇟ )

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

Still not sure about the numeric keypad though. Too much clutter imo.

Game key labels:

The "actual" game key labels are the Unicode symbols. Do you have those for Delete and insert as well? Ideally those would be floating behind the scenes for the two additional buttons just like they are on the other game buttons.

The -PYRA- (function/shifted/orange) versions of them make easy to get to German vowels - AND just happen to be easy to incorporate as labels into emulators that don't speak Unicode. See also nearly every DOS game ever ported.

We would need two more 'missing keys to support international languages' for the Insert and Delete buttons. Maybe Ñ for insert and Ç for Delete? I'm not a linguistics expert so there may be better candidates - what non-English alphabet characters would be the most used by the Pyra audience?

Your option of just labeling them with the Unicode symbols is good - with the exception that anything written prior to 1996-2000 won't know what to make of it or how to make said symbols. It would be good to have -something- as a secondary label. Using it to sneak in non-English ASCII compatible characters may be a bit much visually - but it would have a very high rank from a functionality standpoint.

/**************/

Number keys embedded in keyboard as a 10 key calculator input would be nice for those of us using the Pyra as a calculator or for spreadsheet inputs. Needs the * on M and / on J. Would be handy if ^ on 6 worked in blue shift too. Blue parenthesis would be handy too ().

Done right, it's ignorable by those that don't care and very handy for those who do.

 

[comradekingu]

ABXY discussion is here

I think ED is open to calling abxy+2  + and -  and using them for browser-zoom.

http://www.keyboard-layout-editor.com/#/layouts/ec2c9a66283def1264bb9d4ad5bfab4b  is what i thought of on abxy to get the most convergence to + -

( + ) (  ^  )
(  :  )       (  *  )
( - ) (  √  )

The biggest problem i see is that Gray and Green start with the same letter.

 W   R

 G         G

 B    B

Semi-sensical. My problem is i cant seem to come up with anything better.

There were no less than 3 polls. All building on the oversight that the first one forgot that there is no standard arrangement of ABXY. And people were not made aware of this.

Im hoping ED has some clever ideas, but i honestly dont care that much. Swap them around, make new keysets, figure it out. It is a evolutionary seperate concern because it doesnt need to have much to do with the rest of the layout, and ideally shouldnt.

It seems this thread is drawing attention to the things that dont work, but it was intended as a clarification of how things do work, on a basic level.

 

[_wb_]

I'm sure we can do something like on the START and SELECT buttons of the Pandora; those buttons are about as small as the Pyra keys will be, and they manage to fit the words START // ALT and SELECT // CTRL on top of one another. If that is possible, then 3G USB // wifi BT should also be possible.


Grench: something like this? http://www.keyboard-layout-editor.com/#/layouts/6ebfd384cb4ec4e4645b66ae6ae8a78f


I personally don't think Ä Ö Ü ß are good game key labels just because they happen to occur in some extension of 7-bit ASCII.


What about dropping the Greek and just using the Unicode symbols for Home/End/PgUp/PgDn? ( ⇤ ⇥ ⇞ ⇟ )

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


Still not sure about the numeric keypad though. Too much clutter imo.

Game key labels:


The "actual" game key labels are the Unicode symbols. Do you have those for Delete and insert as well? Ideally those would be floating behind the scenes for the two additional buttons just like they are on the other game buttons.


The -PYRA- (function/shifted/orange) versions of them make easy to get to German vowels - AND just happen to be easy to incorporate as labels into emulators that don't speak Unicode. See also nearly every DOS game ever ported.


We would need two more 'missing keys to support international languages' for the Insert and Delete buttons. Maybe Ñ for insert and Ç for Delete? I'm not a linguistics expert so there may be better candidates - what non-English alphabet characters would be the most used by the Pyra audience?


Your option of just labeling them with the Unicode symbols is good - with the exception that anything written prior to 1996-2000 won't know what to make of it or how to make said symbols. It would be good to have -something- as a secondary label. Using it to sneak in non-English ASCII compatible characters may be a bit much visually - but it would have a very high rank from a functionality standpoint.


/**************/


Number keys embedded in keyboard as a 10 key calculator input would be nice for those of us using the Pyra as a calculator or for spreadsheet inputs. Needs the * on M and / on J. Would be handy if ^ on 6 worked in blue shift too. Blue parenthesis would be handy too ().


Done right, it's ignorable by those that don't care and very handy for those who do.

I don't understand why you focus so much on some particular legacy extension of ASCII, codepage 437. There are many other extensions of 7-bit ASCII with another 128 symbols: see e.g. http://en.wikipedia.org/wiki/CategoryOS_code_pages


That is exactly why Unicode was invented in the first place. Because no, 8 bits is not enough for everyone.


ASCII is a 7 bit encoding, not 8 bit. ÜÖÄß have never been part of ASCII. They are in one particular 8-bit extension of ASCII called codepage 437. In another codepage, codepage 737, you'll find the Greek letters, including Δ Π Ω χ. So you could say Δ Π Ω χ is exactly as ASCII-compatible as ÜÖÄß. I would say both are not ASCII compatible at all, but there are ways to make either of them work in legacy software like MS-DOS (emulated I guess).


Unicode dates back to the late 1980s. The first standard was published in 1991. It is widely available and supported for a long time now. Arguably, it's easier to make it work in current software than legacy encodings like MS-DOS Latin US (aka codepage 437).


If the Pyra would have been released in 1994, you would perhaps have had a point. But it's 2014 now, and it will be 2015 by the time the Pyra gets released. Do you want us to use 2-digit years so we can relive the millennium bug too?


Anyway, I see no potential scenario at all in which it is easier to make a piece of software call a button, say, Ö than it is to make it call it, say, Ω.


Let me do some case distinction to further show my point.


A ) Software is open-source, and then if it doesn't support unicode yet, it can and should be modified to support unicode. It's no more effort to make it call the button Ω than it is to make it call it Ö. If it doesn't support unicode yet, then it will most likely only support 7-bit ASCII. Can you point me to an important open source project that supports codepage 437 but not Unicode? If you're lazy and you don't want to bother with non-ASCII, you can call it "End", or use ||   ()    /\   )(  or something like that to approximate the shapes of those Greek letters in plain ASCII.


B ) Software is closed-source, and then there are two possibilities. The key bindings can be changed by the user or they can't.


B1) If they can't be changed, we're screwed anyway, because we can't make it use the action buttons (unless it happens to already use Home/End/PgUp/PgDn for its important actions, which is highly unlikely).


B2) If they can be changed, they will call those buttons Home/End/PgUp/PgDn no matter what. There's no way it's going to call the key that sends the keycode for End by the name "Ö", or "Ω", or even "B" for that matter. It's highly unlikely that you'll get to choose what names it uses for the keys.


So in what circumstances is it more practical to give the button a 7-bit ASCII name (e.g. "B") or an 8-bit extended ASCII name (e.g. "Ö"), instead of a Unicode name (e.g. "Ω")?


Anyway, your proposal to use Pyra+[action button] to get Ü Ö Ä ß plus Ç and Ñ is flawed for several other reasons.


If you make Pyra+[action button] do something different than what they do without Pyra, then it becomes tricky to use the shoulder buttons and the action buttons at the same time, since e.g. a game will suddenly see Ö instead of End.


Picking 6 special letters to make as many people happy as possible is like picking 6 letters from the English alphabet. Sure, you could statistically determine that ETAOIN are the most important ones, but would you want a keyboard with just those keys? Actually, to make the analogy more accurate, some of those keys would be letters you don't need. Imagine a keyboard where some keys are missing, e.g. B, E, T, P and L are missing, but instead you get these 6 extra keys:

A E и α ب ה


How would that make you feel? Would it make you feel like they did a nice effort and improved the functionality significantly?


Sure, и is a very important letter in the Russian alphabet, and so are α in the Greek one, ה in the Hebrew one and ب in the Arabic one. Still, I don't think you would be very happy.


I hope this "the button label has to be extended ASCII [codepage 437 to be exact] or things won't work" myth that Grench has been propagating for months now, can finally stop now.


We can discuss whether it should be Δ Π Ω χ or some other symbols, but as long as they're in Unicode, it's fine.


* * *


The Unicode symbols for Insert and Delete are as follows:

⎀ for Insert and ⌦ for Delete.


The one for Delete looks good enough imo (especially if you also use ⌫ for Backspace instead of the alternative, ←). I don't really like the one for Insert. I get what they're trying to do, but the "a" is an arbitrary letter and I don't really like that, because Insert has nothing to do with the letter "a". Can anyone come up with a better symbol for Insert?


About the numeric keypad: I would assume that * as Shift+8 still works even with NumLock on, and so does ( as Shift+9 and / as Pyra+D. So to keep the visual clutter to a minimum, I would avoid duplicating them. As for the symbol, instead of using the not very descriptive official Unicode symbol ⇭, I would use a number in a lock, like this:

(on my laptop it also looks like that, but with the number 9 instead of the number 1. I would use the number 2, 4, 8, or 5, because those are imo the most easily recognized as being a number -- 1 looks a bit like i or l, 0 looks like O, 3 is a bit like an inverted E, 6 like b, 7 like T, and 9 like g -- remember it will be a tiny font)


I could live with a minimally invasive numpad that just has the strict minimum of duplication: 0123456. I still doubt it's really useful to have this on a thumb keyboard -- I don't see how it can be more efficient than just the number row. Forget about muscle memory from real numpad use, that's not going to work anyway, it doesn't even work on a laptop with big keys you can use for finger typing -- the key staggering kills any muscle memory.


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

 

[_wb_]

How about this:

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

⌶ symbolizes Insert (does that make sense?)

The main action buttons are▲ ◼ ⬟ ✖ (Triangle, Square, Pentagon, Cross). Simple geometric shapes. We could give them colors too, but that is probably too expensive.

 

[Silent-Hunter]

Why not circle instead of pentagon? Or does Sony have some sort of trademark on it?

 

[Grench]

How about this:

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

⌶ symbolizes Insert (does that make sense?)

The main action buttons are▲ ◼ ⬟ ✖ (Triangle, Square, Pentagon, Cross). Simple geometric shapes. We could give them colors too, but that is probably too expensive.

An embedded 10 key looses nearly all of it's value if the +, -, *, / and Enter keys are not readily available without shift-key combinations. Look at the 10 key board on the right 1/4 of a full size desktop keyboard. /*-+. and Enter. Remove those or make them shift-key combinations and it's purpose is, frankly, ruined. I can go extensively into use-case scenarios involving spreadsheet, calculator and HP calculator inputs if you'd like.

My theory - which is up to emulator maintainers to state yes/no issue/not for:

Unicode wasn't even available in a shipping desktop OS until 1996. See UCS-2 in NT4.0.

Many (most?) of the system ROMs that are used in emulators predate Unicode.

Many of the emulator OS ROMS and game ROMS were very efficient on how they used space and storage.

Throw a Unicode character set at it and it will likely come back as a series of squares on the screen instead of the intended symbols.

Using an I beam to symbolize insert could work fine.

I'm not sure how it appears on your machine, but on mine, running Chrome browser, your Pentagon symbol looks 100% identical to the square.

When imported into a hex editor, the string ▲ ◼ ⬟ ✖ reports as -- 20 -- 20 -- 20 --. THAT is how anything made prior to 1996, and a fat lot of it after 1996 will interpret Unicode - as junk.

Stating that all of the emulators would need to be updated to use the modern code base is simply silly. In many cases they leverage the OS ROM - which is, from their perspective, unchangeable.

If there is a Pentagon in your string - Chrome certainly cannot interpret it.

In a retro handheld gaming console, compatibility with old code sets must trump the aesthetics of new code sets. We have to make sure that the device is speaking what the old systems can understand. It simply doesn't work logically to demand it the other way.

 

[Silent-Hunter]

We can still print the shapes on the buttons though. And say in the applications 'Press the Pentagon button.'

 

[_wb_]

Why not circle instead of pentagon? Or does Sony have some sort of trademark on it?

It wouldn't surprise me if Sony owns a patent on the circle. Greek mathematicians such as Pythagoras claim prior art, but their lawyers suck so Sony is not impressed.

No, seriously, I guess circle is also fine. Just wanted to be different. If you see the cross as two lines, triangle as three, square as four and pentagon as five, then ✖▲ ◼ ⬟ kind of makes a sequence (2 3 4 5). With a circle it would be more like 2 3 4 ∞.

In a retro handheld gaming console, compatibility with old code sets must trump the aesthetics of new code sets. We have to make sure that the device is speaking what the old systems can understand. It simply doesn't work logically to demand it the other way.

I don't see your point. What are you talking about? Are you planning to write a Pyra manual on the Pyra in WordPerfect 5.1 in DOSBox or something?

Are you planning to write a Pyra-specific game in QuickBasic 4.5? Or why exactly do you feel the need to have labels on the Pyra keys that can be represented in some legacy encoding?

Can you give a concrete example of some kind of use case where it makes an actual difference whether the End button has the label Ö instead of Ω or ⬤ ?

An embedded 10 key looses nearly all of it's value if the +, -, *, / and Enter keys are not readily available without shift-key combinations. Look at the 10 key board on the right 1/4 of a full size desktop keyboard. /*-+. and Enter. Remove those or make them shift-key combinations and it's purpose is, frankly, ruined. I can go extensively into use-case scenarios involving spreadsheet, calculator and HP calculator inputs if you'd like.

Well, Enter and Space are readily available, as well as Tab. Minus is also a dedicated key. So you can enter lists of numbers (positive or negative ones) without needing shift.

You could add dedicated NumLock duplicates for *, /, and +, but where does it end? You know, the brackets ( and ) are also pretty useful, as well as ^ and sqrt and log and ln and of course the sin, cos, and tan and perhaps also the *h and arc* variants of those and perhaps we also need Ans and % and mod and ! and so on.

Sure, all of that is useful, but the line has to be drawn somewhere. We don't want to make it look like a calculator.

I would personally rather have no embedded numeric keypad at all; I don't think a slanted numpad really works. I have one of those on my laptop and I never use it. You can use an external USB numeric keypad, or just a full keyboard, if you want to do lots of number entry.