Previous Post | Top | Next Post |
TOC
背景
キーボードによるストレス低減のためのMCUを使ったIOTの初等プロジェクトとして、QMKを使うcgc56というQMKを利用したキーボードを作りました。
ストレスのソースと削減指針は2つあり、そのバランスが重要です。
- フィジカルストレス削減には、できるだけ指の移動に無理が無いのが望ましいと考えます。
- メンタルストレス削減には、できるだけ標準キーボードと変わらないのが望ましいと考えます。
このcgc56は元々は中指を伸ばして「E
」を叩きづらいという個人的課題のフィジカルストレス削減のキーボードプロジェクトでした。
これだけなら「E
」と「F
」のスワップで済ますのも良いのですが、それだけでは勿体ないので、苦労しない範囲でDVRAKの交互打鍵に近づけられないかと考えた妥協点案が上記の写真の「QWFRTY配列」です。これはあくまでQMKを利用した自作キーボードの最適化キー配列実験で、私の日常生活はQWERTY配列です。
- cgc56 (4x14) は planck (4x12) よりはキーの数が多い。
- 普通のLaptop PCのキーボードに近いキー配列が可能です。
- 一体型ですが両手間隔がとれ猫背にならずに使えます。
- 2つあるメインのFnキーキャップの前面角が面取り加工されてい、親指の触覚で手の位置が確認できます。
実は、DVORAK・COLMAK・WORKMAN・COLEMAK-DH等の既存の「エルゴノミックキーマップ」でフィジカルストレス削減する方策は、私にとっていずれも学習障壁(メンタルストレス)が高すぎました。(これらの有名配置だと、VIエディターでのカーソール移動も難しくなってしまいます)。
この状況下で思いついた「QWFRTY配列」は使ってみてフィジカルストレス削減手法として意外とおもしろいので、ここに要点等をメモしておきます。
(後記のように、「QWFRTY配列」は結局使っていません。)
QWFRTY配列
「QWFRTY配列」は、11個のキーだけが標準の「QWERTY配列」から移動された配列です。
名前は、1文字違いでややこしいですが、「QWFRTY配列」としました。キーは位置の要点を抜き出すと以下です。
LEFT HAND RIGHT HAND
│ Q │ W │_F_│ R │ T │ │ Y │_D_│_K_│_G_│ P │
│ A │_I_│_U_│_E_│_O_│ │_S_│_H_│_J_│ L │ ; │
│ Z │ X │ C │ V │ B │ │ N │ M │ , │ . │ / │
まあ、所詮実験レベルのお遊びですが、我ながら悪くない気もします。
QWERTY配列からの変更点(覚え方):
キーの移動を以下の様にとらえると覚えられます。
- “IUEO"は50音順に"A"に続けて配列。 (“E"は"F"と場所交換、“SDG"は外しておく)
- “HJKL"を逆Tのカーソールキー位置関係に移動。(“L"を軸に1つづつ移動、ホームを空ける)
- “SDG” をこの順番・位置関係を維持しながらで右の空きスペースに順番に移動。(この移動だけは覚える必要有り)
QWFRTY設計の方針と結果:
- 母音 (AIUEO) を左手に集めるDVORAK/EUCALYN配列のコンセプトは継承。
- 交互打鍵をでき、特に日本語との相性も良い。
- 母音文字順はDVORAK/EUCALYN配列と変えて、頻出の"E"をホームの動きの良い人差し指の下に移動。
- 50音順キー配列としたので、日本人に覚えやすい
- それなりによく使う"S"と"D"は、反対側の動きの良い人差し指操作の範囲に移動。
- キー移動を必要最小限化する COLEMAK/WORKMAN配列のコンセプトは継承。
- QWERTYからの移行のメンタルストレスを最小限にできる。
- EUCALYN配列の VIMのカーソールキー (HJKL) をまとめるアイデアを拝借
- 大きなキー移動を避けるため、“L"は動かさなかった。
- QWERTYよりむしろ使い安くなった(?)
- “S"と"D"がくるアクセスの良いスペースが空いたので一石二鳥。
- 本当のカーソールキーと相似形の配置で、VIMのカーソールキー (HJKL)が使える。
QWFRTY配列のキー移動の統計と可学習性:
- 11/30のキーが移動(下記の他の有名配列の半分近くなので、覚えやすい)
- 気分的には、“SDG"の3つのキーの新場所を覚えるだけ程度の、楽な学習障壁感。
QWFRTY設計の背景事実:
文字数頻度指標
(log圧縮済み、QMKのソース利用)は以下です。(大きいほどよく出てくるので、使いやすいところに置きたい文字)
s=26.2 d=26.2 f=16.9 g=9.4
*.c
*.h
s=20.1 d=14.4 f=8.2 g=6.7
*.md
交互打鍵・日本語入力
“f” は日本ではあまり使わない子音なので、交互打鍵を考えた際にも子音だが母音側にあっても"g"より悪影響が少ない。英語環境では、ともに中以下の頻度なので大差ない。
右配置の移動文字間の優先順位
s > d > g
世の中にある有名キー配列
標準の「QWERTY配列」以外は、新しいキー配列提案が先に並んでいます。
以下は重要30キーにのみフォーカスし、Ortholinear系・ERGODOX系を意識した位置表示です。
QWERTY配列
LEFT HAND RIGHT HAND
│ Q │ W │ E │ R │ T │ │ Y │ U │ I │ O │ P │
│ A │ S │ D │ F │ G │ │ H │ J │ K │ L │ ; │
│ Z │ X │ C │ V │ B │ │ N │ M │ , │ . │ / │
- 0/30キーが移動(デフォルト)
Eucalyn
- https://eucalyn.hatenadiary.jp/entry/saikyo-interface (2017-12-21 初期形)
│ / │ , │ . │ F │ Q │ │ M │ R │ D │ Y │ P │
│ A │ O │ E │ I │ U │ │ G │ T │ K │ S │ N │
│ Z │ X │ C │ V │ W │ │ B │ H │ J │ L │ ; │
-
23/30キーが移動
-
https://eucalyn.hatenadiary.jp/entry/about-eucalyn-layout (2018-08-31 完成形)
│ Q │ W │ , │ . │ ; │ │ M │ R │ D │ Y │ P │
│ A │ O │ E │ I │ U │ │ G │ T │ K │ S │ N │
│ Z │ X │ C │ V │ F │ │ B │ H │ J │ L │ / │
- 20/30キーが移動
Colemak Mod-DH
│ Q │ W │ F │ P │ B │ │ J │ L │ U │ Y │ ; │
│ A │ R │ S │ T │ G │ │ M │ N │ E │ I │ O │
│ Z │ X │ C │ D │ V │ │ K │ H │ , │ . │ / │
- 17/30キーが移動
WORKMAN
│ Q │ D │ R │ W │ B │ │ J │ F │ U │ P │ ; │
│ A │ S │ H │ T │ G │ │ Y │ N │ E │ O │ I │
│ Z │ X │ M │ C │ V │ │ K │ L │ , │ . │ / │
- 21/30キーが移動
Colemak
│ Q │ W │ F │ P │ G │ │ J │ L │ U │ Y │ ; │
│ A │ R │ S │ T │ D │ │ H │ N │ E │ I │ O │
│ Z │ X │ C │ V │ B │ │ K │ M │ , │ . │ / │
- 19/30キーが移動
Dvorak mod-slash
│ / │ , │ . │ P │ Y │ │ F │ G │ C │ R │ L │
│ A │ O │ E │ U │ I │ │ D │ H │ T │ N │ S │
│ ; │ Q │ J │ K │ X │ │ B │ M │ W │ V │ Z │
- 28/30キーが移動
適用対象がOrtholinear配列のため「'
」が「/
」となっている。(どのキー配列でも、「'
」は真ん中の上記枠外の隙間に配置済み)
キーボードの動作確認方法
ちなみに、押されたキーのチェックやNKRO機能のチェックには、以下が便利でした。(キープレスが短いと拾えないことがあることには要注意)
文字頻度 (アルファベット)
QMK のquantum/
中やdocs/
中を統計して、スペースの数を100としている。"*
“はログ圧縮して大局観が分かるようになっています。
Cソースコード ドキュメンテーション中
" " = 100.0 **********
"e" = 61.9 ********* "e" = 37.7 ********
"t" = 41.0 ******** "t" = 27.7 *******
"a" = 32.2 ******** "a" = 22.2 *******
"i" = 38.3 ******** "i" = 22.1 *******
"o" = 31.4 ******* "o" = 23.4 *******
"n" = 30.7 ******* "n" = 19.4 *******
"r" = 30.3 ******* "r" = 19.4 *******
"s" = 26.2 ******* "s" = 20.1 *******
"d" = 26.2 ******* "d" = 14.4 ******
"c" = 23.7 ******* "c" = 13.3 ******
"l" = 18.2 ******* "l" = 13.5 ******
"f" = 16.9 ****** "f" = 8.2 *****
"u" = 15.4 ****** "u" = 10.9 ******
"m" = 14.3 ****** "m" = 9.8 *****
"p" = 13.9 ****** "p" = 8.3 *****
"k" = 10.6 ****** "k" = 5.5 ****
"h" = 10.3 ****** "h" = 11.1 ******
"b" = 9.5 ***** "b" = 6.5 *****
"g" = 9.4 ***** "g" = 6.7 *****
"y" = 9.3 ***** "y" = 6.5 *****
"v" = 5.9 ***** "v" = 3.3 ****
"w" = 5.7 ***** "w" = 4.4 ****
"x" = 5.5 **** "x" = 1.6 **
"q" = 0.9 * "q" = 1.0 **
"j" = 0.5 * "j" = 0.3 *
"z" = 0.5 * "z" = 0.2 *
ここで高頻度の子音文字「tnrsdcl」の非母音側への集中度と母音集中側の母音の数をみます:
キー配列 | 頻出子音字集中 | 母音集中 | 全集中 | キー移動数 |
---|---|---|---|---|
QUERTY | 5/7 | 3/5 | 8/12 | 0 |
QUFRTY | 4/7 | 5/5 | 9/12 | 11 |
Colemak dh | 5/7 | 4/5 | 9/12 | 17 |
Colemak | 5/7 | 4/5 | 9/12 | 19 |
Eucalyn | 6/7 | 5/5 | 11/12 | 20 |
WORKMAN | 5/7 | 4/5 | 9/12 | 21 |
DVRAK | 7/7 | 5/5 | 14/12 | 28 |
QWFRTY
はキー移動を避けたため、最頻出の「T
」が母音側のままという問題が出ています。
でもTH
などの子音同士の連続の交互打鍵は確保できていますので、捨てたものではありません。
とにかく変更が少なく、母音が集中するのがいい感じです。
(確かにT
とY
の交換で改善しますが、キー移動数が増えるのとTH
が隣接等のマイナスもあります。過ぎたるは及ばざるが如しです。)
文字頻度 (記号)
ちなみにC言語のソースの場合、記号でスペース比較で約4%以上の頻度は以下だけでした。
" " = 100.0 **********
"_" = 35.9 ********
"(" = 10.5 ******
")" = 10.5 ******
";" = 7.0 *****
"," = 6.7 *****
"#" = 6.2 *****
"*" = 6.2 *****
"." = 4.4 ****
"/" = 6.4 *****
"0" = 6.3 *****
"=" = 4.8 ****
""" = 3.5 ****
余談
ちなみに、母音文字を集める際に採用した"AIUEO"配列ですが、「なぜ"E"の使用指が変わらない配列や、はたまた他の配列でないのか?」と問われたら、「特段の理由はないが、(左手)中指使用を抑えたい個人的事情と、キー位置の覚えやすさ」というのが実感です。DVORAK配列の"AOEUI"や、頻度での優先順位を考えた"AOIEU"や"AOEIU"でも充分いい気がします。
とにかく、ここまでの細かい個人的事情にも自由に対応できるのがQMKキーボードの良いところです。
最初にハードウエアー設計した地点では、メンタルストレスに配慮して従来のキーボード両端の小指で操作する旧来のシフトキー類も残せる様に考えていました。ただ小指でのこれらの操作はフィジカルなストレスです。
一方、ERGODOX等で見るThumbクラスター風のタイピングでのシフトキー類の操作は小指への負担が少ないので魅力的です。ただ親指で操作できるキーの数は限られてますし、あまり多くするとキーボードが大きくなり実用性が無くなります。交互打鍵解消よりこの辺をどう着地させるのかが、使いやすい「カスタムキーボード」遊びの最重要課題のようです。
この辺を色々試すと、当分楽しめそうです。
後日譚
結局メンタルストレスに配慮すると、QWFRTY等とするのは非常に不便でした。交互打鍵のメリットは小さい一方で、SHIFTやCTRL等のMODキーを押しての打鍵がむしろ大きなストレスと分かりました。 また、小指の利用も1U移動に抑えるなら、それほど問題視することもないと分かりました。
その結果として、HOME-ROW-MODを使いました(QMK (7) – 再キーマップ改善))。
Previous Post | Top | Next Post |