deskthority

hi All

Current methods for evaluating keyboard layouts are usually based on analyzing what the fingers do, using complex measurements to track distance, alternation, repeated use, etc.

When Maltron arrived, they used a different metric: how many words you could type on their home row, compared to QWERTY or Dvorak. Naturally their layout came out best.

So I've written some programs to do similar analysis, for the following categories:

1. home keys (because 'home row' is not always in a straight row, these days)
2. home block (see definition on site)
3. easy block (ditto)
4. one-handed words (where a low score is desirable).

Over 300 layouts analyzed.

Follow the word-based metrics links here: http://www.keyboard-design.com/best-layouts.html

Comments and critiques welcome. Also if you think there are bugs or anything else wrong...

Note: some layouts (many of which originated with Patrick's Keyboard Layout Analyzer) may still have errors in the layouts themselves, which would lead to bad analysis. I'm fixing those as I find them.

Note 2: There are still too many of my own layouts in the mix, I'll cull some once some other tests are done.

Interesting, could you consider how much CFILORUX would stand a chance ?

keyboards-f2/kochise-cfilorux-custom-ke ... 17889.html

Kochise wrote: Interesting, could you consider how much CFILORUX would stand a chance ?

keyboards-f2/kochise-cfilorux-custom-ke ... 17889.html

Well the comparisons are based on English words, and your layout is not particularly designed for English.

I read your thread, I think people got a bit confused because you start by saying you were involved with the design for a replacement for AZERTY but then you post an alphabetical layout.

Here's a similar but different approach to the same thing:

http://www.keyboard-design.com/letterla ... ha.en.ansi
or
http://www.keyboard-design.com/letterla ... ef.en.ansi
or
http://www.keyboard-design.com/letterla ... on.en.ansi

I have seen (in a patent or paper, can't remember at the moment) a similar vertical alpha layout to what you propose.

In general, my experience over the last year or so has taught me:

1. layouts need to be optimised for a given language.
2. alphabetical layouts perform poorly in comparison tests, since they ignore the peculiarities of a given language.

FWIW, A few years back an Australian made a fuss patenting an alphabetical layout for touchscreens, his motivation / sales pitch was much the same, ie for young people and old people not familiar with computers.

eg
http://www.smh.com.au/digital-life/digi ... 21tns.html

There are various other alpha layouts, none very good (compared to good layouts, like MTGap etc).

eg
A B C D E F G H
I J K etc
or
A D G J
B E H K
C F I L etc
or
A B C D M N O P
E F G H Q R etc
I J K L


I can add your layout to my comparisons if you can send me the KLA json file ... create the layout here, then export it.
http://patorjk.com/keyboard-layout-analyzer/#/config

Hope that helps

Cheers, Ian

Any of the analyzer tools can be feed with a keyboard layout directly from KLE?

ideus wrote: Any of the analyzer tools can be feed with a keyboard layout directly from KLE?

Not that I know of ... the problem is that KLE allows "any" form factor, and the analyzers are pedantic about only dealing with known form factors.

I have some code that goes the other way (from KLA to KLE), but still a work in progress.. only handles Matrix layouts at the moment, will do ANSI next.

Thank you for the answer, it would rock if any of the analyzers could do that, it may allow extensive experimentation with different layouts to fit a particular usage pattern, optimizing a design for an specific user.

ideus wrote: Thank you for the answer, it would rock if any of the analyzers could do that, it may allow extensive experimentation with different layouts to fit a particular usage pattern, optimizing a design for an specific user.

I think in theory KLA could be made to do it, but...

1. Need to change the loading code in KLA to also load or generate a "keymap" which is the x/y co-ordinates of the centre of every key. This has to be to a scale -- internal conversion between screen pixels and physical keycap sizes.

2. KLE would need to be modified to allow the creator to specify which finger presses which key, and where the home keys are.

3. KLA would need to be able to understand KLE json.

So in theory doable, in practice, a little tricky

KLA can handle any layouts as long as it has a keymap etc defined ... we've already extended it for Ergolinear and Matrix formats. ("We" being mostly Den (shenafu.com) and a little bit from me)

ideus wrote: Thank you for the answer, it would rock if any of the analyzers could do that, it may allow extensive experimentation with different layouts to fit a particular usage pattern, optimizing a design for an specific user.

In truth, when I started experimenting with KLA/KLE etc I thought it would be useful to have a multi-way conversion, eg convert between KLA/KLE/xkb/Windows layout/OSx layout.

And part of that would be a "unified" layout format (eg Universal Layout Format == ULF) (I was thinking of YAML but XML would probably be safer) as a middle ground between them. So we can go from KLE to ULF, and from there to any of the others, etc.

So my KLA -> KLE is a first step along that way, but going directly rather than via some ULF. This is doable because the form factors in KLA are only five at the moment.

Should be doable to also do KLE -> xkb, even if it is a "full" version rather than one cleverly including predefined bits from elsewhere in xkb like they would like.