Archive

Archive for June, 2010

New Keyboard Layout Project: Have We Been Mistaken All Along?

Everyone who has designed a prominent keyboard layout, and I mean everyone, assumes that finger travel distance is by far the most important factor. It makes sense on an intuitive level: we should move our fingers around as little as possible. Colemak places the eight most common keys on the home row, as does Arensito, Michael Capewell’s layout, and others. I used to agree.

But have we been mistaken all along?

Enormous benefits can be gained if we are willing to sacrifice a little finger travel distance. I was running my keyboard generator program and it came up with this layout:

b l o u ; j d c p y
h r e a , m t s n i
k x ‘ . z w g f v q

This surprised me at first. I thought, I must have something wrong. The ‘o’ isn’t on the home row. That can’t be right. But then I considered further. Maybe it’s worth it to sacrifice some finger travel distance in order to gain other benefits. This layout boasts great inward rolls (notice ‘he’, ‘in’, ‘is’, ‘re’, ‘it’) and very few outward rolls. With four vowels on one hand and only one on the other, it also has pretty good hand alternation, thus pleasing both the “rolls” crowd and the “alternation” crowd. Same finger usage is amazingly low — lower than any other major keyboard layout.

The trouble is, I’ve never tried a layout like this, nor do I have the time to. I want to stick with the layout I have and try to get faster using that one layout; remembering both it and QWERTY is not too hard, but remembering three layouts is far more difficult. It would be really nice if I had a research grant and could hire a group of 50 or so college students to learn this layout, and compare it to one where finger travel distance is valued more highly.

Perhaps a different sort of layout is better than the conventional type. The trouble is, we don’t really know. But there’s still the possibility that we’ve been mistaken all along.

MTGAP’s Keyboard Layout 2.0

I am deleting this information from my Keyboard Layout Project page. In order to preserve it, I am putting it up in a blog post. All this was written at some point back in late 2008 or early 2009.

MTGAP’s Layout 2.0

Shortcuts at zero value
Ease to learn at zero value
Designed for standard (non-ergonomic) keyboard
Score: 9.67

, f h d k j c u l .
o a n t g m s e r i
q x b p z y w ' v ;

This is a revised layout, designed to be optimal for any keyboard.

HOW DOES IT COMPARE TO COLEMAK?

Colemak is, in my opinion, the best publicly available keyboard layout other than my own. Here’s how it compares in the 8 criteria that my program uses.

Best travel distance: MTGAP’s evolved standard layout = 68069
Worst travel distance: Colemak = 71162

Best same finger: Colemak = 0.34%
Worst same finger: MTGAP’s evolved standard layout = 0.34%

Best same hand: Colemak = 21.16%
Worst same hand: MTGAP’s evolved standard layout = 25.45%

Best jump home: MTGAP’s evolved standard layout = 0.02%
Worst jump home: Colemak = 0.2%

Best hand warping: Colemak = 0.79%
Worst hand warping: MTGAP’s evolved standard layout = 0.92%

Best row changing: Colemak = 7.55%
Worst row changing: MTGAP’s evolved standard layout = 11.71%

Best to center: MTGAP’s evolved standard layout = 1.16%
Worst to center: Colemak = 1.79%

Best rolls: MTGAP’s evolved standard layout = 14.48%
Worst rolls: Colemak = 6.82%

So my layout wins 4 times and Colemak wins 4 times.

MTGAP’s Layout for an Ergonomic Keyboard

---------UNSHIFTED--------------------------- SHIFTED
[ 1 2 3 4 5 6 7 8 9 0 ] || { ! @ # $ % ^ & * }
TAB , f h d k j c u l . / || TAB ( F H D K J C U L ) =
CAP o a n t g m s e r i - || CAP O A N T G M S E R I _
~ q x b p z y w ' v ; ! || ` Q X B P Z Y W " V : ?
thumb pads
----LEFT-------------------RIGHT
ctrl/cmd_alt/opt____copy_paste
S___B__________________E___S
H___K__altGr______undo_N___P
I___S__________________T___A
F___P__ctrl(Mac)___esc_E___C
T___C__________________R___E

Hmm…I really can’t make a picture of thumb pads using text. Well, the 2 main buttons are shift and space, with backspace and enter on the other big buttons. On the left is ctrl, alt, altGr, and Mac ctrl. On the right is copy, paste, undo and escape.

MTGAP’s Layout for a Standard Keyboard

The designer of Arensito had 2 really great ideas. The first was to have a whole different layout for special characters, accessed with AltGr. I’ll get to that later. The second was to a way of using thumb pads on a standard keyboard. All the keys are moved up 1 row, and the thumbs go on the bottom row.

---------UNSHIFTED--------------------------- SHIFTED
q , f h d k j c u l . - = BKSPC || Q ( F H D K J C U L ) _ +
TAB o a n t g m s e r i / [ ] || TAB O A N T G M S E R I ?
CAP q x b p z y w ' v ; ! || CAP Q X B P Z Y W " V : &
shift 5 3 2 1 4 shift
AltGr(used to be space)

I put Q in the tilde position because of the Mac shortcuts CMD-TAB and CMD-Q.
1: space
2: backspace
3: shift
4: enter
5: a dead key that causes the next key pressed to be its QWERTY position. This is mainly for keyboard shortcuts: hit this key, then hit CTRL-C where C is in its QWERTY position.

About that special characters layout. You press AltGr to access this layout.

9 7 5 3 % $ 2 4 6 8
/ = * 1 \ _ 0 : ; #
^ + | @ [ ] { }

This layout puts the most common special characters on the home keys. It’s also easy to remember: I spent no time trying to memorize it, but I have no problem remembering it. Odd numbers are all on the left, and evens are on the right. All the paired symbols (like brackets) are on the bottom. All the mathematical symbols are on the left. \ and |, which are on the same key in QWERTY, are next to each other. As a little bonus, % is in its QWERTY position.

What if you want to use this keyboard?

I can’t help you there. I designed these keyboards for the fun of it. If you want to use a better keyboard, go to Colemak.com
Maybe my keyboard is better than Colemak. But it’s not much better. If we all use Colemak and endorse it, it will have a better chance of overthrowing QWERTY than a bunch of random layouts.

Categories: Keyboards

The Interpreter, Chapter 5

June 17, 2010 2 comments

The continuing story of one man’s quest to write an interpreter.

Jackson’s interpreter was working great. Most of the features he wanted were working. There were still a few annoying bugs that needed to be worked out, but all in all, things were going very well.

The way that the interpreter was changing scope was painfully slow. Jackson did some research to try to find a solution, but decided that the only way to speed up the program would be to make some fundamental changes. One thing led to another, and before he knew it Jackson was up until midnight creating plans for a whole new evaluation system.

Up to this point, the interpreter’s interpretation system was pretty jumbled. Compiler and interpreter were hopelessly mixed, with no possibility of separation. Some parts were being evaluated before optimization, and some parts after. It just didn’t make much sense, and was hard to work with. To make any serious headway, things had to change.

The most important alteration would be to separate compile time and run time. The whole internal representation of functions would have to change as well. Blocks, instead of being unoptimized chunks of code, would become fully optimized expressions.

Of course, big changes also means big mistakes. Jackson spent hours tracking down all the new bugs that had been created.

Conceptually, the new interpreter was far superior to the old one. It was simpler, easier to understand, theoretically faster and just a whole lot neater overall. The real trick was making the code look like the concept.

Chapter 6

Categories: The Interpreter

Our World of Lists

The world we live in is quite an interesting place. Its structure, and especially the way that we perceive its structure, is worth observing.

When we read or write, we do so linearly. We only read one word at a time, and when we’re done, we go on to the next word. Sentences are treated as lists, where only one element at a time can be read. Our inability to comprehend anything other than lists is remarkable.

You may object to this. Sure, we read linearly, but we can also read non-linear graphs, flow charts, and even just clusters of words. While it is true that we can read such structures, we always convert them into lists, taking in one word at a time. Because time is linear, we can only perceive one thing at once before moving on to the next one. Sometimes we are able to package multiple things together and perceive them as one thing, but we cannot truly perceive more than one item at once.

Although we perceive things as lists, it is difficult to imagine things being any other way. How else could we perceive things? Perhaps in a data structure other than lists, for example binary trees, language would be more versatile. Language, of course, is not the only instance of our list perception — it is simply a very common one. What would language be like if we perceived it as a binary tree?

Well, it would be a lot less linear, that’s for sure. The whole idea of language would be a lot different, and perhaps more expressive. It’s difficult to imagine, though, just because our minds are so fundamentally grounded in lists.

The world outside of lists is an interesting one to speculate about. Where might this speculation lead?

Categories: Language, Math

The Interpreter, Chapter 4

June 3, 2010 1 comment

The continuing story of one man’s quest to write an interpreter.

Most of the basic data types — numbers, strings, arrays, lists, hashes — were supported. Next, the interpreter needed control structures. But before those could be added, they needed some sort of support. So Jackson created blocks.

Blocks began as chunks of code in between curly brackets. They were pretty simple. Getting them to work was a bit tricky, but nothing too difficult. Even before control structures were implemented, blocks still proved useful. They could be packaged up, and the same code could be called multiple times.

Jackson used this to implement if statements and while loops. To keep control structures as pure as possible, he treated if statements and while loops as functions. While loops became functions that took two blocks, one for the condition and one for the body. If statements became functions that took either two or three blocks, depending on whether there was an “else” block. After blocks were implemented, if statements and while loops were easy.

Now that blocks were possible, they could be used not just for control structures but also could be passed as arguments into functions. The first such function was the times() function, which took two arguments: a number and a block. It would execute the block a number of times equal to the given number, and it looked like 10 times { do stuff }.

For blocks to really achieve their full potential, they needed to be able to take variables. Implementing this required making the internal data structure a good deal more complicated. But when it was finished, the interpreter was all the more powerful.

At last, Jackson’s programming language was Turing complete. He successfully implemented a program to calculate every prime number from 1 to 100.

Chapter 5

Categories: The Interpreter