打鍵評価システムにおける評価関数に関しての雑感。
シフトを押すことによる打鍵時間の増加は0.6打鍵分(新JISかな論文における習熟曲線からの推測値)。
では、ホームポジションから指を移動することによる「行く→戻る」のコストは何打鍵分ぐらいなのだろうか。
自由打鍵法で得られた打鍵時間を積算する場合、そのシミュレーション結果が「現実とかみ合わない」理由としては、こういう要素が考えられる。
- 創作入力をする際には、
途中途中でホームポジションへと指を戻さないとタッチタイプが継続できない思考と打鍵のプロセスが交互に発生する。打鍵→思考へのプロセス移行時にはホームポジションへと指を戻すが、その点を評価関数へと含めることが困難である……つまり、バルク打鍵時の性能は容易に評価できるが、創作打鍵時の性能は容易には評価できない。- 適当な文節ごとに区切って指をホームポジションに戻すとか、そういう極端な評価をする関数すら必要になるかも。
- 自由打鍵法は時間のみを評価基準にしているので、「早く打てるけど指が痛みやすい」指使いを検知できず、逆に「遅くしか打てないけど指が痛みにくい」指使いも検知できない。しかも指一本一本の運動能力テストだけでは不足であり、掌の動き・各指がつられて動いてしまう点なども考慮しなければならない……たとえばEnterキーやBackSpaceキーは「早く打てるけど遠い」というのと同じように。
- より突き詰めて考えると、手というデバイスの癖を熟知した上で、手指の動きを関数で表現する必要が出る。
- 自由打鍵法は、キーを「正しく打った」のか「誤打したのか」を記録する「誤打率記録」も重要になる。通常予想できうる範囲では、「ホームポジションから打つにはつらいキー同士の2打鍵」は、そうではないキーを含む打鍵ストリームよりも誤打率が高くなるはず。
- 誤打率まで考慮すると、0.6打のコストをかけてでもホームキーのシフト側を活用するほうがよい場合もありえる……のかも？。
原理的には、「正しい評価関数」＝「全ての入力方法を評価できる関数」で、実際にこれをイコールにするのは無理がある……と。
現実的な範囲で関数を簡素化した上で、「多くの入力方法を評価できる関数」が作成できるのならば、それでかなりの物事が可視化できるのではないかな……と。
