キー配列頂上決戦!さいつよなレイアウトはどれだ!

自作キーボード Advent Calendar 2017 の 24 日目の記事です。

最近、Helix という自作キーボードキットの GB を行いました。参加頂いた方ありがとうございます!
現在は来年の発送に向けて準備を進めているところで、GB を取りまとめるのもなかなか大変な事だと思いながらも楽しく毎日を過ごしています😀

Helix の配列

さて、その Helix のデフォルトキー配列は現在の所以下のようになっています。

これは Preonic のデフォルト配列を元に拡張したものになっています。

キー配列の好みは人それぞれですから、デフォルトをそのまま使うという人はあまりいないかと思います。なのでそこまでこだわって決めたわけではありません。

強いて言えば日本語対応で英数、かなキーを入れたところでしょうか?(Windows は Alt +` になります)

デフォルトはそれで良いとして、でもせっかく新しいキーボードを作ったわけですからもうちょっと配列にも踏み込んでみたいなぁという気もありました。

また今まではあまり感じていませんでしたが、キー数の少ないキーボードを使うようになって無駄な動きをしたくないという気持ちが強くなっていました。でも配列を変えるというのは結構勇気のいることで、今まで伸ばし伸ばしにしていたのです。

そんなところで、先日のゆかりさんの記事の「ぼくのかんがえるさいきょうのインターフェイス」で火がつきまして、ちょっと考えてみようかと思った次第です。

効率の良い配列とは

今までさんざん語りつくされてきた話題かと思いますのでくどくど書きませんが、概ね以下のようなものと思います。

  • 指の動きを最小限にする
    • 良く使うキーはホームポジション付近に置く
    • 親指も活用する
    • 小指に負担をかけない
  • 手や指に偏りがなく交互に打てる
    • 母音を片方に寄せる
    • 同じ指を連続で使わないようにする
  • 学習コストを下げる
    • QWERTY からの変更を少なくする
    • ショートカットに使うキーは出来るだけ変えない

つまり、指の動きをいかに少なくして交互打鍵が出来るかということになります。

学習コストに関しては、生涯コストを減らすためには必要なコストと考え、あまり重要視しないという方向で行きたいと思いますが、vim などで使いたいキーも残しておきたいという葛藤もあるので辛いこところです。

また、日本語入力を考えるとかな入力+英数などが良いのかと思いますが、今回はローマ字入力を前提で考えていきます。

総合的に考えると先ほどの記事の Eucalyn 配列(仮)が良さそうでしたので、オリジナルの配列を考える前にまずは他の目ぼしい配列とも合わせて評価してみたいと思います。

評価方法

ベンチマークプログラムは Keyboard Layout Analyzer など有るようですが、Pythonの勉強がてら簡単なものを書いてみました。

https://github.com/MakotoKurauchi/keyboard_layout_benchmarker

テストに使う文字列ファイルと、キー配列とコストそれぞれの json 形式のファイルを読み込ませると、指先の移動によるコスト(Position cost)と交互打鍵出来なかった時のコスト(Hand/Finger cost)を元に評価値が出ます。

$ python klbm.py data/sample.txt keymaps/qwerty.json data/cost.json
Position cost   : 237
Hand/Finger cost: 241
Total cost      : 478

Position cost は後述のキーの位置によるコストです。Hand/Finger cost は交互打鍵にならなかった時に追加加算されるコストで、異なる指を使うより、同じ指を連続して使った方がより高く加算されるようにしています。

また、ヒートマップも出すようにしたのでどの位置のキーの使用頻度が高いかが視覚的に分かるようになっています。

(ヒートマップは seaborn を使っていますが、キーの文字を入れるやり方が分からなかったので以下のヒートマップ画像はそこだけ手で合成するというカッコ悪いことになっています…)

使用データ

Position cost は以下のようになっています。

ホームポジションを1として、離れるほど入力しづらいほど数字が高くなっています。小指はなるべく使いたくないので数字は高めになっています。また、人差し指も行が変わるより列が変わるほうが高くなるようにしています。

また、評価に使うテキストは、QMK からC言語のソースの一部の約 50 万文字と、ローマ字用として自分のブログの記事データ約 10 万文字分を使いました。英文用のテキストは用意していませんが、C 言語のソースに含まれるコメント文で賄えるのではないかと思います。

結果

以下のようになりました。

C言語 ローマ字
名称 変更率 Position H/F Cost Position H/F Cost 総合
QWERTY 1874 261 268 234 270 1033
Dvorak 1936 93% 236 224 177 216 853
Colemak 2006 57% 218 243 180 256 897
Workman 2010 63% 216 254 175 251 896
Minimak 2012 13% 237 245 227 248 957
Norman 2013 50% 217 261 183 268 929
Eucalyn 2017 77% 227 245 180 182 834

 

Eucalyn の優勝ですw

Eucalyn は C 言語の時も悪くないですが、やはりローマ字入力を考えられているので交互打鍵評価の H/F Cost が圧倒的に良いです。

私は研究家でもなく深く考えられた評価プログラムでもないので、スコアはあくまでも参考程度ではありますが、使ってみようかなという気になる結果でした。

以下は各配列の評価です。なお、スペースキーに関しては使用頻度が高すぎたため、集計から除外しています。

QWERTY

明らかに分散しています。ホームポジションから動くことが多いので当然スコアは悪くなります。

QWERTY – C言語
QWERTY – ローマ字

Dvorak

母音が左手のホームポジションにあるので交互打鍵に優れています。さすが平均して良いです。ただ QWERTY からかなり変わっているのでショートカットで良く使うC V Zキーが右手にあるのが辛いところです。といってもショートカットは別レイヤーにマクロを組むという方法もあると思うので割り切ればそれでも良いかもしれません。

ローマ字では、K が左手側にあるのでカ行とア行が続くと左手が辛くなりそうです。

Dvorak – C言語
Dvorak – ローマ字

Colemak

QWERTY をベースにしているのでショートカットに使われるキーは残されているようです。スコアも悪くなく良いと思います。しいていえば vim でカーソル移動に使うH J K L が並んでいないので乗り換えづらい感じ。まぁそれも別レイヤーで…

Colemak – C言語
Cokemak – ローマ字

Workman

https://github.com/ojbucao/workman

今回の評価で Position cost  が一番低くかった配列です。人差し指の列の変更が少ないのが特徴的に見えます。

Workman – C言語
Workman – ローマ字

Minimak

http://www.minimak.org/

QWERTY から4キーだけ変更している配列です。効果は出ているようですが、特に魅力は感じないですね…

Minimak – C言語
Minimak – ローマ字

Norman

https://normanlayout.info/index.html

Position cost は高いですが、Hand/Finger cost は QWERTY とあまり変わらなかったので代替配列の中では一番スコアが悪かったです。きっと評価基準が違うのでしょう。

Norman – C言語
Norman – ローマ字

Eucalyn

http://eucalyn.hatenadiary.jp/entry/saikyo-interface

交互打鍵を意識した配列ですが、Kが右側にあることでローマ字入力に置いてDvorakより優れていると言えそうです。

ショートカットに良く使うキーは残しつつ、vimのカーソルで使う H J K L も一列ではないですが通常のカーソルキーのような形を守っています。

Eucalyn – C言語
Eycalyn – ローマ字

まとめ

時間の関係で新しい配列づくりまでは行けませんでした。でも実際の評価は使ってなんぼですから、まずは Eycalyn 配列を使ってみようかと思っています。

最後までお読み頂きありがとうございました。

(この記事はHelixで書きました)

参考サイト

PythonのCounterでリストの各要素の出現個数をカウント
https://note.nkmk.me/python-collections-counter/

Seaborn でヒートマップを作成する
https://pythondatascience.plavox.info/seaborn/heatmap

Dvorakのその先へ(その2)
https://qiita.com/miyaoka/items/4f363059e831bd003775

投稿者:

ないん

30半ば過ぎで突然電子工作にはまりました。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です