deskthority

Idea
This thread is an attempt to collect all different ideas what could be changed to the better of current mainstream keyboards. Or asked in a provocant way: If we had no keyboards yet, how would a clever new design from the ground up look like?

I'll try to collect not only the most popular ideas but also more subtle or maybe farfetched ideas. If designs exist that demonstrate the idea, these should also be referenced.

Please throw in your ideas, opinions and experiences, and discuss. I'll try to collect all items.

Findings

• Staggered rows
  • Matrix Layout
• Separated number block/navigation keys
  • Tenkeyless
  • Navkeyless
• Overburdened pinky finger
  • More thumb keys
  • More layers
• Brainless layout
  • Alternative layouts
• Unnatural hand and finger posture
  • Split keybard
  • Curved keyboard
  • Tilted keyboard
  • Staggered rows
• Necessity to switch between keyboard and pointing device
  • Integrated touchpad
  • Touchpoint
  • Integrated Mouse keymouse.com
• Cheap rubber dome constructions
  • Mechanical switches
    • Alps switches
    • Cherry MX switches
• Orientation on the board
  • More: Backlights
  • Less: Unlabled keys
• Limited set of scancodes/possible characters/key mappings at receiver side
  • Extended protocol: One code for every symbol
  • Support for Unicode at KB side

Rationale for this thread:

I want to build my own keyboard. But when I already make that effort I want something that is at least reasonable better than what I get in a shop. Some things really annoy me with standard keyboards, like staggered rows, which has no reason to still exist except for legacy compatibility. Some things are hard to change or on a different level, like keymaps, still they are worth to consider.

What are you most annoyed about that you want to have changed in a "perfect" keyboard?

I have another thing that would be better, alps keys!

For me, the biggest problem is the seperation of the pointing device and the text input device. There are some OK workarounds like the trackpoint but this is not an option when you're using a tablet or something like that.

If I was going to make a better keyboard, I'd incorporate a precise pointing device that doesn't requre the user's fingers to leave the keyboard. Actually, this is a problem that can be solved by using proper software that isn't dependant on a precise pointing device but let's the user use keyboard shortcuts...

Well, the device also has to be super small in order to be really successful these days. It shouldn't force an unnatural position of the hands in order not to put too much strain on the hands or the arms.

Most of the "new" designs for a new keyboard are just some iteration of the same old workaround that exists since a hundred years or more. We don't need a workaround but a real solution in this case

Redmaus wrote: ↑I have another thing that would be better, alps keys!

Seconded!

Also, I still am not completely sure about the point of tenkeyless boards. Why not have a navless one instead, possibly with the down arrow on the 5 to preserve the inverse-t layout?

Well I never use a numpad, so I'd quite happily be rid of it. I use Home/End/PgUp/PgDn a lot, however. For people that make heavy use of a numpad, sure, a navless board would probably be fine.

I guess what all the people building ergo-keyboards here would agree on is:
· split keyboard
· staggered columns that fit your fingers
· more thumb keys in some sort

anywhere besides that is mostly personal preference, like curvature and tilt.
or it is dependent on the use-case like integrated pointing device and TKL (or even Tipro).
and in effort they want to take like a new layout or more than two additional layers.

If you plan to do typing mostly, and in english for that, take a look at plover.stenoknight.com first. I wish I did instead of starting to learn a new layout.

zuglufttier wrote: ↑For me, the biggest problem is the seperation of the pointing device and the text input device.

I have an Eeepc 701, one of the first models. It has a quite small keyboard, and - that's the great thing about it - a trackpad, that is easily usable with the thumb. I love circular scrolling with it.

One more project that seems very interesting to me is keymouse.com. Never move your hands between keyboard and mouse again.

I want to get rid of every reorientation of my fingers after switching/moving to a different input device or area. I noticed that I need very short, hardly noticable reorientation looks down to the keyboard every time I use the numpad or navigation keys. This costs time and concentration.

My take on things:

Rows vs columns: Rows are really not that bad. What is stupid is that the row-offset is different: 0.25 vs. 0.5 and different for the left and right hands.. A symmetric 0.25 or 0.375 is better. A row-oriented layout would fit better those that don't touch-type with the exact "proper" finger on the right keys than a column-oriented layout would.

Cherry MX and Alps vs. Rubber dome: The most desirable property in a keyboard switch is tactile feedback. Classic rubber domes (including Topre) are tactile ... but the tactility is not feedback to anything. Low-profile scissor switches are much better because the tactility coincides with actuation. Linear mechanical switches are bollocks.

Findecanor wrote: ↑The most desirable property in a keyboard switch is tactile feedback. Classic rubber domes (including Topre) are tactile ... but the tactility is not feedback to anything.

I'd heavily disagree with this statement. Some rubber domes are ridiculously tactile, even more than mechanical switches. Furthermore you're saying that linear switches don't just have no inherent use, but are actually NEGATIVELY useful.

I'd say the best thing about mechanicals is that they're not mushy like rubber domes are. As side benefits, they're also often more well-built, and tend to sound much better.

Chyros wrote: ↑I'd heavily disagree with this statement.

It seems to me that you are more out to argue than to contribute to the thread. I'm not arguing that there aren't tactile rubber domes or that there aren't well-built premium keyboards with linear mechanical switches.

I'm saying that the purpose of tactility in the first place is an ergonomic feature: to provide feedback for actuation, to allow the user to avoid pressing too far or too hard.
I'm arguing that there are lots of keyboard designs that have been made without that goal in mind.

Findecanor wrote: ↑

Chyros wrote: ↑I'd heavily disagree with this statement.

It seems to me that you are more out to argue than to contribute to the thread. I'm not arguing that there aren't tactile rubber domes or that there aren't well-built premium keyboards with linear mechanical switches.

And I'd argue that your opinion is a rather drastic one to simply state as fact. To say that the thing that matters most about mechanical keyboards is only tactile feedback borders on insulting, not just to the makers of the keyboards themselves, but to a large part of the community who might look to mechanical keyboards for something completely different, or even avoid tactile feedback altogether.

To say I'm not contributing just for disagreeing with your rather sweeping statement (and I'm pretty sure I'm far from the only one) is similarly not exactly subtle, and frankly quite rude. The topic asks for ideas and opinions, and I gave mine. You just barge in and say "everyone else's opinion is worthless because the thing that matters most is tactility" and then proceed to argue I'm not contributing because I state I look for different things in a keyboard than you do. You even flat-out state linear switches are bollocks - and while I'm not the greatest fan of linear switches myself, I don't presume to say linear switches are bollocks just because I myself don't like them. I know people are very fond of theirs, and there is no reason why my opinion matters more than theirs.

As you're such a big fan of tactility though, I'll happily sell you one of my special rubber dome keyboards. It's extremely tactile, and has more feedback than a Lisp keyboard or an industrial space saver, so even if I ask £2000 for it it's still the best deal you've seen in your life, right?

Chyros wrote: ↑Also, I still am not completely sure about the point of tenkeyless boards. Why not have a navless one instead, possibly with the down arrow on the 5 to preserve the inverse-t layout?

Well, the numpad is one unit wider and the nav cluster. Not to mention the above cluster(prnsc, scrl lck, Ps/brk) is three units so it matches the nav cluster and would not match a 4u numpad. So then the board lines up perfectly when you cut off the numpad.

Not to mention you wouldn't have to mash the shit out of your numlock key constantly.

But yeah, I can see how no nav cluster with numpad would work.

I personally dispise the continued use of generic scan codes. Certainly more of an OS issue than anything else but it sure would be nice to see unicode support across the board in operating systems. It would facilitate not only additional charictor support but would ease the implementation of individualized layouts for the masses.

rsbseb wrote: ↑I personally dispise the continued use of generic scan codes. Certainly more of an OS issue than anything else but it sure would be nice to see unicode support across the board in operating systems. It would facilitate not only additional charictor support but would ease the implementation of individualized layouts for the masses.

I have a split opinion on this. For one it would be nice to have a keyboard that behaves the same on any computer you plug it into, even if if is unusual characters.
But on the other hand, take a look at the keys of your keyboard: how many of them are actual characters? Quite a lot, but saying mostly any of them are woud be bold. There's a lot of control elements on it, like shift, alt, arrow movement, home, end... Think about dead keys as well…
So what you really want to ask for isn't unicode support, but support for an not yet existing set of universal and unified scancodes!

Yes, but for that this "standard to-be" could be implemented (which I higly approve), the different operating systems had to agree on a common denominator. They probably won't.

I sometimes think, keyboards should not be labeled at all, at least for people learning touch-typing and for people already safe touch-typists. Labeled keys are sometimes tempting to look down, which slows one down.

That's the stuff. Screw the popularity of backlights. People shouldn't even be looking anyway. Punish the users with ergonomics!

I touch type just fine, but I still prefer legends. For looks. And I don't mean the kind that confirms where the L key lives again…

My 2 cents.

1. Swap the left control and caps lock keys. Is extremely comfortable for the left pinky. And the cap locks is activated via palm press.
2. IMO, I find the Filco Minila function keys a very smart layout. Having the arrow keys at "esdf" instead of "wasd" is great because is more natural keeping you in the home row initial position. The main problem with the Minila is that it lacks of right control key, so if you need to press CTRL+Arrow key is quite painful. So a right control is needed.
A downside of this layout is the small non standard spacebar, it's not a problem for me, indeed I love it, but difficult to find replacements.
3. ISO over ANSI. ISO has one more key so it's very useful for people who has their own keyboard layouts, like me.
4. Backlight. I touch type but should be great having a dot at F and J (qwerty keys) just to see where is your home row. You know, at night after taking a sip of your coke.
5. TKL or less should be standard, at least any "standard-commercial" keyboard should give the posibility of taking away the numpad.

6. Enter key under space bar. It will be reached with the thumbs. I never tried this but I always think that the enter key kills ergonomics because of the distance you must move your entire arm.

Metalmind wrote: ↑My 2 cents.

1. Swap the left control and caps lock keys. Is extremely comfortable for the left pinky. And the cap locks is activated via palm press.
2. IMO, I find the Filco Minila function keys a very smart layout.
6. Enter key under space bar. It will be reached with the thumbs. I never tried this but I always think that the enter key kills ergonomics because of the distance you must move your entire arm.

Swapping some keys is much to conservative for me. If you can swap keys between different pinky positions, why not farther? Holding a modifier with the pinky limits the possible keys you can reach with the hand. Holding a modifier with the thumb limits the reach of the same hand much less. More thumb keys, new ideas for modifiers!

Removing the extra blocks (num, nav) seems to have a down-side: you need to fully orientate tactile on the letters block to press them, or you need extra labled keys and look it up visual. The extra blocks can also be orientated tactile.

Ray wrote: ↑

rsbseb wrote: ↑I personally dispise the continued use of generic scan codes.

So what you really want to ask for isn't unicode support, but support for an not yet existing set of universal and unified scancodes!

Currently, the keyboard sends a scan code, that is translated to some meaning by the keyboard driver and keyboard layout mapping. Quite a few indirections. If you decide for example to separate [ ans { on an US keyboard, you have to send "[" for the first and "Shift-[" for the second.

When keyboards where kind of standardized in the 1980s they where rather dumb devices, and the easiest technical solution was to relabel the US keyboards and add software mapping. This is limiting us right now.

Nowadays it's affordable cheap and technical no challange to handshake with the keyboard, and ask it for the semantic of the scan codes. This could be a mapping of scancode to Unicode position, or to modifier or non-character, like arrow or F-keys. Shift could be handled in the keyboard itself, but I'm not sure if this is without problems: Ctrl-Shift-Arrow for example needs Shift to be sent to the computer.

So, you want to go back to "smart" terminals, where keyboards did a fair amount of text processing? Well, that kind of terminal is called a touchscreen tablet nowadays.

Funny. I thought you loathed current mainstream layouts. Arbitrary pairings like 4 and $ deserve to be enshrined forever now?

Also, this isn't 2005. Tablets aren't input devices. They are what will displace traditional personal computers. It's happening damn fast. Look at all those billions of man hours the world puts into its "phones" every day!

Muirium wrote: ↑Funny. I thought you loathed current mainstream layouts. Arbitrary pairings like 4 and $ deserve to be enshrined forever now?

4 and $ aren't paired until interpreted by the user-space software stack.

Full Unicode support in the keyboard controller is just asking for trouble. The controller would have to be powerful and run quite complicated firmware. We already have plenty of experience with related (1) security issues and (2) quality of embedded software (ask [Linux] kernel developers). In addition, what would do you do with stuff like, say, right-to-left writing? Various Unicode encodings?

Muirium wrote: ↑Also, this isn't 2005. Tablets aren't input devices. They are what will displace traditional personal computers. It's happening damn fast. Look at all those billions of man hours the world puts into its "phones" every day!

Current tablets are thick terminals and are becoming thinner and thinner (pun not intended). The real computing and data storage/manipulation happens on the server side (or rather in the "cloud" infrastructure).

The cloud's as much a feature in the future of our personal computers as it is for phones. Ever noticed how horrifyingly useless any computer is when Internet connectivity gets flaky? Times like that, I light a camp fire and tell tales of the olden times when we mailed disks around instead!

I don't think there's anything daft in rsbseb's proposal. No more so than the crufty concept of the host defining the keymap, to hell with the keyboard. Why should keyboards confine themselves to the USB HID? Unicode is a table, not an operating system.

Let's put it differently.

Current keyboards are mostly dumb, but the incompetent Asian wage-slave coders, that write controller firmwares, still struggle with debouncing rates or antighosting. Dealing with Unicode adds complexity. Are developers of commercially available keyboard-controller firmwares capable of dealing with the complexity, while under the pressure to keep their products as cheap as possible? I doubt it. The disasters like networking hardware (esp. routers) or AV gadgets are already out there.

…and if the new protocol doesn't gain significant market share, relevant drivers won't get upstreamed by Microsoft or Apple.

Also, complexity means bugs, and Unicode receives updates as well. If the keyboard sends chars, there has to be a user-friendly interface for configuring layouts (e.g., swapping national layouts). Who would maintain it? How would you update the firmware? What about security then (e.g., keylogging)? Again, see blobs, hacks and GPL violations in current commercially mass-produced gadgets or networking hardware. Or mouse drivers.

Is software Unicode-ready? Will it break, if you throw, e.g., right-to-left Unicode text at it?

Too many questions.

davkol wrote: ↑Full Unicode support in the keyboard controller is just asking for trouble. The controller would have to be powerful and run quite complicated firmware.

That is only because manufacturers have got away with cheapening out on the firmware in the past.
Many modern keyboards, even cheap ones, use 32-bit ARM-based microcontrollers that are more powerful than PCs and Macs were in the mid-'90s.. and they handled unicode just fine.

davkol wrote: ↑Current tablets are thick terminals and are becoming thinner and thinner (pun not intended). The real computing and data storage/manipulation happens on the server side (or rather in the "cloud" infrastructure).

In theory. In practice, phones and tablets are getting more and more powerful and are wasting CPU and GPU time on needless tasks. For instance, the standard GUI in the latest Android uses the GPU with OpenGL ES to render tessellated drop shadows under every element.

davkol wrote: ↑Also, complexity means bugs, and Unicode receives updates as well.

The USB HID protocol is quite complex at it is. Breaking free from it and designing thing differently could be a good thing.
Unicode is just a set of numbers. If the design of the new protocol is right, then it could have Unicode and be easier to implement.
I think that there is a need - and an opportunity - for a new keyboard protocol also because of the rise of analogue sensing in gaming keyboards, which is something that HID does not support.

Findecanor wrote: ↑

davkol wrote: ↑Full Unicode support in the keyboard controller is just asking for trouble. The controller would have to be powerful and run quite complicated firmware.

That is only because manufacturers have got away with cheapening out on the firmware in the past.
Many modern keyboards, even cheap ones, use 32-bit ARM-based microcontrollers that are more powerful than PCs and Macs were in the mid-'90s.. and they handled unicode just fine.

Not in $5 keyboards shipped with desktops… or laptop keyboards.

Findecanor wrote: ↑

davkol wrote: ↑Current tablets are thick terminals and are becoming thinner and thinner (pun not intended). The real computing and data storage/manipulation happens on the server side (or rather in the "cloud" infrastructure).

In theory. In practice, phones and tablets are getting more and more powerful and are wasting CPU and GPU time on needless tasks. For instance, the standard GUI in the latest Android uses the GPU with OpenGL ES to render tessellated drop shadows under every element.

While that's absolutely true, the thick client is relevant to actual applications. Contact, calendar, notes, bookmarks, everything shared in the cloud; add social-networking stuff; music/video streaming; "social" aspects of games, "backup" saves in the cloud, perhaps game streaming in the near future… tools for self-quantization are mostly cloud-dependent too (from Endomondo to software for wearables).

I use my "smartphone" completely offline, but it's a PITA. And my offline tablets (as in portable touchscreen computers) are obscure non-mainstream rarities (esp. Asus Eee Note EA-800 and Nokia N800).

I created a concept design that implements several of your factors for improvement. Here is a video overview.

I have the impression, that the big modifier keys are the wrong solution for the problem:
Modifiers (Shift, Ctrl, Alt) are very important. But on standard keyboards they are partly at positions that are not very easy to access. On the other hand they are bigger than standard keys, which makes it easier to hit them correctly.

Why not put them in locations where they are easier to hit, where precission of the fingers is higher? It has to kept in mind that modifiers are to be pressed with other keys. Thus when pressing a modifier, the same hand should not be limited in flexibility as much as possible.

Some press Ctrl with the palm. I tend to press Shift-Ctrl simultaneous with the pinky, and Ctrl-Alt and Shift-Alt on the left hand (German layout, no Alt-R) with pinky and thumb. That all is specific to standard keyboards. I wonder how such "manual shortcuts" could look like on improved layouts.

How do people use the thumb block on Kinesis Advantage or ErgoDox?