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

Functional layout vs reduced layout


  • Total voters
    38

I'm not arrogant. Assume im really as stupid as it looks, just trying to learn. 

If you think "oh, hes obviously doing this because ...."   No, im really that dumb, please explain.
If only this were true of more people.  Anyway, I may change some of my answers, because I prefer clean letter keys if possible.  I am not English, but that is the language I use...

It means, for example, that Meta-a is left without a default binding along with other key combinations. These can be mapped by the user to whatever (in the case of meta-a a good candidate would be ä for me) as needed. In that option the additional characters do not have primary key functions. It's a compromise between them having their own keys (as would be when using layouts) and the horror of compose key. Leave key combinations unused, let the user sort it out
I like this, too.  This should make it so that shift symbols on letters can be returned to standard US locations, right?
 
This is how i logically see everyting being the numbers row.  Since inputting dead-keys is second rate to +4  they cant have F-ing, this also means F-ing is hacks only. (f-keys and mediabuttons) which is what i want.

Swipe combos for dead key accent aigu retroflex and grave  on  Fing 5 6 7 was neat, but easy access to F5 is also nice.

Inputting  what other people use +4 for on numberkeys is regional, they have to come last (which means you have to enable it) selecting french or czech layout is exactly when that should be done, not have it default, because it may cause problems.

Which means, 

Dead keys:                                                                                 ctrl+alt+       the whole number row and various punctuation letters    (see section about dead-keys in firstpost)

Inputting selected accentuaded letters on number row:   ctrl+             numberrow     ctrl+2 4  9 and 0  for frech people

Inputting first modifier:                                                            shift+           numberrow for natural language symbols and letters for capitalization aA

Inputting second modifier:                                                      altGr+          numberrow and the standard functionality on letters  altgr+e for €

Inputting F-keys:                                                                       F-ing+         numberrow

This last one is where it gets tricky, because there is only 10 keys on the numberrow, and there are 12 Fkeys.

So F2 F3 F4 F5 F6 F7 F8 F9  is smooth sailing, and can be input as if there were F-markings on the letterkeys.   F10 on 0 doesnt make much sense, so lets keep that in mind.

This leaves F1  F10 F11 and F12

To input F1:     Fing+1(release button)

To input F10:   Fing+1+0     (alternativly Fing+0)

To input F11:   Fing+1+1

To input F12:   Fing+1+2

The primary downside to this is that F1 takes a bit longer to press (on release instead of onpress)  and F10-F12  require an additional press.

Primary downside to having F11 and F12 on a different row to the number row:  Its ugly and it questions the whole layout, because it makes it look unprofessional and hacky.

Primary downside to having F1-F12 on QWERTY   its tricky to remember what key corresponds to which number, (F4=Fing+R for example) especially considering the number-row is shifted with respect to a regular keyboard. Dont want to draw attention or rely on this.
Just label them F1 F2 etc. in blue or something.
 
Sure, it would look clean (although I'm not a big fan of the two background colors, I think that would look weird and in any case those background colors are arbitrary -- what do Tab, Enter, Backspace and numbers share to give them a different color from the other keys?).

But once you start using it, it won't feel clean. Two or three thumb presses just to press an F-key? No standard shift + number row? Dedicated keys for [ ] < but not for much more frequently used symbols like ' / -, and that's not just for prose, but also for coding.

You're imitating one particular aspect of standard full keyboard layouts: having keys at P+1 and L+2 available for remapping so people can put their Ü Ö Ä or whatever there. But you're deviating from nearly all other aspects of standard layouts. You have space between comma and period, Enter below Shift, no Super and Insert (maybe Ins is F-ing Del, but without the label I can't tell). If I'm looking for a symbol in the set !@#$%^&*()`~/?'"_-+=\| and I know where it is on a regular keyboard, then that does not help me at all to find the symbol in your layout. Essentially I have no other choice than to let my eyes do a slow sequential search on the number row.

Keeping the letters "clean" is a nice goal in itself, but the price to pay is too large. Essentially you are compacting all the messy bits into the number row, which is heavily overloaded with numbers, F-keys, and two non-standard layers of symbols. It's too much. Too much of a learning curve to find the symbols.  Too much implicit stuff, conventions you have to remember. Are the labels in the order [normal, shifted, AltGr] or [shifted, normal, AltGr] or [normal, AltGr, shifted] or what was it again? When I'm trying to type the symbol & on your layout, I might very well type a ?, then ` , then ^ before I get it right. That sort of thing is really annoying.
 
Some of those are good points.  It may be worth it to keep F keys on qwerty.  How much would be broken by putting symbols back on the correct number?

_wb_, there is no way around a minimum of 2 presses for F keys unless we devote primary key functions to them.  If the number key shift symbols were in a standard location, and F keys are on qwerty what major problems do you see with comradekingu's layout that weren't mentioned in your last post? I think the dedicated infrequently used keys to the right of P and L were selected so as not to disrupt linguistic use of punctuation should those keys be sacrificed for remapping. 
 
Last edited by a moderator:
Input movement manipulation. Its more that they arent letters, which is the focus. Commonly seen by mixing keycaps or ordering custom sets.

There is no insert for the time being, is abxy+2   going to be insert?   It cant be printscreen, and if - inputs -  then + should input +.

There is no standard number row to be had, because there isnt any full number row to fill in. As for standards, there are many different ways of arranging a number row.

A german one is different from a US one. For the most part the symbols are on the same key, but the positions of modifiers are often swapped.  This is also means there is one dead-key symbol per number key.

Its hard to keep that with dead-key symbols only on AltGr, because then you break being only dependent on normalpress and shift, as some of those symbols are important in typing    '   for example.

Id much rather have the confusion limited to the number row than the whole keyboard. Yes it is problematic that there is no one standard, but deviating to the point of arranging things somewhere else is less standard.

Shift works like shift, altgr works like altgr. The learning curve is being able to use a keyboard for those. Albeit one that has a semi-standard number row.

The arrangement is normal shifted altGr.      Where Shift and AltGr buttons are to the right on the layout.

I would rather have no keyboardshift, but for sake of keeping basic input simple, its on the keyboard and you can input all standard natural language with it. Meta for things that should have been either shift or AltGr just doesnt appeal to me.

On a related note, yes Fkeys are mostly 2 keypresses. But none of those are shoulders. "Oh, its on the back" is quite a difficult concept to explain and use. Its an advanced method of input, and i dont think assuming it works for most people is more or less true than any solution there is to pick from.

The punctuation is the least awkward arrangement i could come up with, it is streamlined.  Looking like a 105-key is very far down the list of priorities.

The whole world was able to use T9 keyboard for a while, and the problem wasnt how it looked strange, it was how inefficient it was.

Try lifting your keyboard up and using it with thumbs only, it doesnt work. Imagining a streamlined layout while holding a pandora worked much better for me.

Ill see what i can do about improvements.  Moving F-keys to the numbers means typing dead-keys has to be less central, so 5 and 7 can change along with a whole bunch of other things. F5 is one swipe, and that is more valuable than aigu retroflex grave swipes.

My brain started working again, but i have to sleep. Got some ideas though.

Thank you for feedback.
 
Last edited by a moderator:
A too "clean" keyboard looks boOring to me. I'd rather see a full but lisible keyboard with a clean upper side (action button and all) than an empty keyboard which looks like a kid's computer one. Maybe because I don't like half-finished things.

Well I prefer all letters clean than only 2 or 3.
 
Last edited by a moderator:
In my layouts Version 1 and 2, umlauts for a and o are those vowels under Meta(which I call Sym). For å, remap over ß and be done with it. If you have a fourth, replace Section Sign, Euro, or Micro. I put them all over to the right for people like yourself to add whatever you need without any complications.
The problematic parts in that were "remap over" and "replace". My suggestion requires only additive changes, as in no destructive changes at all. The moment you start mapping over stuff you're right back in the same problem I described with layouts. Applications working funny and positional keyboard bindings fly out of the window. See the "["-problem I menitioned earlier for an example. There have been even worse examples, like an application using P+1 and L+3 for WASD-style input (two-player game on one keyboard). Now have a layout move those symbols all around the keyboard behind various modifier combinations and you'll see how the intended easy WASD-style navigation melts away.
I like this, too.  This should make it so that shift symbols on letters can be returned to standard US locations, right?
Yes. Although I'm not sure if those are the best places for them. IMO, the proposed layouts are doing a nice job of optimizing the symbols for two-thumb use. I'd value well thought-out thumb usability over proximity to any existing layout.
 
If you switch from default layout to another language to add special letters, you have to lose something that was on those letters, what is it going to be?

No answer is suitabe. For me it would be: 1234567890, and it shouldn't matter to the design decisions of the Pyra keyboard.
 
Some of those are good points.  It may be worth it to keep F keys on qwerty.  How much would be broken by putting symbols back on the correct number?

_wb_, there is no way around a minimum of 2 presses for F keys unless we devote primary key functions to them.  If the number key shift symbols were in a standard location, and F keys are on qwerty what major problems do you see with comradekingu's layout that weren't mentioned in your last post? I think the dedicated infrequently used keys to the right of P and L were selected so as not to disrupt linguistic use of punctuation should those keys be sacrificed for remapping. 
When I say presses, I mean thumb presses (because those are the ones that count for efficiency on a thumb keyboard). In my layouts, the F-keys are always just one thumb press, because the Pyra modifier is on a shoulder button. In comradekingu's layout, the F-keys are behind a strange modifier called "F-ing" which is not available as a shoulder button.
 
In my layouts Version 1 and 2, umlauts for a and o are those vowels under Meta(which I call Sym). For å, remap over ß and be done with it. If you have a fourth, replace Section Sign, Euro, or Micro. I put them all over to the right for people like yourself to add whatever you need without any complications.
The problematic parts in that were "remap over" and "replace". My suggestion requires only additive changes, as in no destructive changes at all. The moment you start mapping over stuff you're right back in the same problem I described with layouts. Applications working funny and positional keyboard bindings fly out of the window. See the "["-problem I menitioned earlier for an example. There have been even worse examples, like an application using P+1 and L+3 for WASD-style input (two-player game on one keyboard). Now have a layout move those symbols all around the keyboard behind various modifier combinations and you'll see how the intended easy WASD-style navigation melts away.
If I understand your English, you want something like an AltGr combo? I guess for that we'd have to decide what gets which placeholder or "borrow" one of the AltGr established mappings. It would be interesting to see which shoulder button or pair of them to use for this purpose. All Alt, Shift, or Ctrl with a keyboard key shortcut lists would then have to be analyzed. Ctrl and Alt in sync sometimes become an AltGr key under Windows so we could use that. It does seem like more work than reward to circumvent legacy program key misinterpretation than necessary all for just an å, but people's needs are different. 
 
Saber: Let me put it another way: Throw out all ßäö stuff from your layout, and don't put anything in their place. Leave those key combinations unused. Let the user decide and add the mappings for those combinations. If you happen to leave (if I understood your layout correctly) sym+a, sym+s and sym+o unbound, the user can nicely bind äßö to them. If the user doesn't need äßö, he can map whatever else to them. This way nothing is being mapped over and app developers can count on the keys mapped by default being in the places they should.

(EDIT: I'm genuinely surprised how difficult this idea is to get across to people. I don't mean getting them to agree with me, but just understand what I mean. Maybe I should work on my delivery :p )
 
Last edited by a moderator:
Saber: Let me put it another way: Throw out all ßäö stuff from your layout, and don't put anything in their place. Leave those key combinations unused. Let the user decide and add the mappings for those combinations. If you happen to leave (if I understood your layout correctly) sym+a, sym+s and sym+o unbound, the user can nicely bind äßö to them. If the user doesn't need äßö, he can map whatever else to them. This way nothing is being mapped over and app developers can count on the keys mapped by default being in the places they should.


(EDIT: I'm genuinely surprised how difficult this idea is to get across to people. I don't mean getting them to agree with me, but just understand what I mean. Maybe I should work on my delivery :p )
If reality didn't exist...

ED wants his a, o, and u with umlaut sauce and a side of Eszett so you need to convince El Capitan of your boundless whim. 
 
Last edited by a moderator:
If reality didn't exist...


ED wants his a, o, and u with umlaut sauce and a side of Eszett so you need to convince El Capitan of your boundless whim.
I wasn't aware of that. No actual complaints from me since I need them (well, Ä and Ö) too :p


I wonder if "somewhere" means 1) as a primary key, 2) as a modified key printed on the layout, 3) as a non-printed modified key, or 4) as some combination of button presses (compose/dead-key)
 
Last edited by a moderator:
ED said he had been missing äüö when i showed him that there was a way to input those in the standard places. There isnt anything better than that to be had, so we can safely assume it covers the criteria.

I had some time this morning:  http://www.keyboard-layout-editor.com/#/layouts/a3e2660eadba25a17a99dbeabaccb742

Reinstating the lost coding keys with altGr isnt a bad idea, because thats what AltGr does on a regular keyboard (one that isnt US layout)

I also tested shift+altGr and found it to actually do something by default, which was interesting. You can then reinstate the second letter on the coding cluster aswell.

So if you want regional stuff on those keys, altGr is the regularclick, and shift+altGr is the shiftclick.

That is if you dont want to switch layouts back and forth.

Its not very pretty, nor is the F11 or F12, but its not too ugly either, and it works.

I thought about F11 on tab and enter or backspace enter.   But i dont know about that.  

Missing insert           Was FN+backspace ok for insert on pandora?  Its not really something everyone needs to know about, so it doesn't have to be marked.

Would be nice to have a '

Clean altGr on 2490 would be nice for french, but 2 is the german "

Those are the issues right now, modified number row is currently not a big deal in the vote. Would be nice with more votes.

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

Only AltGr to reinstate, its things you need though, so its a bit iffy. Even though ' is better for english, anyone else is pretty much required to write english, so it becomes a bit of a hack for non-hacky people.

only 1 dead-key per key, little bit better for english as far as frequency goes. Its all over the place though, doesn't seem welcoming to use.
 
Last edited by a moderator:
If reality didn't exist...


ED wants his a, o, and u with umlaut sauce and a side of Eszett so you need to convince El Capitan of your boundless whim.
I wasn't aware of that. No actual complaints from me since I need them (well, Ä and Ö) too :p


I wonder if "somewhere" means 1) as a primary key, 2) as a modified key printed on the layout, 3) as a non-printed modified key, or 4) as some combination of button presses (compose/dead-key)
I wonder if ED would be inclined to prepare a custom firmware for you gentlemen who want Ä, Ö, Ü under Sym/Meta without key codes. The umlauted wowed prints on the keycaps wouldn't be altered obviously but the slate will be clean for mapping their now empty values. The other less extreme way is to put any chosen characters to unfilled Sym/Meta + Home, End, PageUp, or PageDown.

Just thinking out loud is all.  B)
 
Last edited by a moderator:
It doesn't need custom firmware. It's almost trivial to change the mappings with xmodmap on your own.

EDIT: The problem is, of course, if they're mapped OVER something and then an application assumes the button working differently and hilarity ensues.
 
Last edited by a moderator:
Those are the issues right now, modified number row is currently not a big deal in the vote.
It is something that matters to some people.  I think most would prefer something that functions well, even if some things are not in places commonly found on real keyboards.  Thanks for moving ampersand in your most recent layout.  Honestly, I haven't really looked at it closely to evaluate usability.  It looks like some things moved around and disappeared.  Is the current location for backspace going to be a problem for non-English letters, or are the symbols found on numbers sufficient?  I am still a little confused about a few things.
 
No more so than you are inclined to write P when you mean to type L or enter.

I looked up the sources, and it turns out ' is of the least commonly used characters.  Factoring it in, to make more sense for english, takes away from a more deeply rooted functional and input-aware question of efficiency (for all). So i'm not concerned any-more. Its one chorded keypress that its possible to pull off with one hand.

Unless coding ruby, or some other language unbeknownst to me, ' doesnt matter at all. For the case of ruby, _ matters a whole lot more, apparently.

Computer QWERTY Keyboard Key Frequency:
Space e t Shift a o i n s r h Del l d c u Enter
m f p g w y b , . v k ( ) _ ; " = ' - Tab x / 0 $ *
1 j : { } > q [ ] 2 z ! < ? 3 + 5 \ 4 # @ | 6 & 9 8 7 % ^ ~ `

As per usual things suggest against QWERTY being clever, but it is what people expect, and a breakdown in frequency doesnt tell the whole story. When you use tab, you are likely to use it a whole lot, in conjunction with dpad, for example.

Moving  @  %   from shift+ to altgr+     and  &  from 7 to 6    isn't  a change I think people will be impacted by in any major way.

If anything, having " on shift+2 is going to be greatly appreciated by germans.

# will have moved up with irc and microblog users, so to have that directly on 3 is better. (alluding to abxy+2 being - and + here)
 
Last edited by a moderator:
&  from 7 to 6    isn't  a change I think people will be impacted by in any major way.
I think this is probably true.  It might bother some with passwords or something (I don't understand why letters not aligning with numbers as they do on a full keyboard is a problem).  In the last link in your post above you moved & back to 7, however you are using AltGr for it.  Is this where you want it?

Out of curiosity, does changing the shifted output of number keys bother anyone?  It will probably take me a day or two to adjust, but I don't see it being any more of a problem for me than other suggested layouts.
 
Last edited by a moderator:
Back
Top