It's fine today!
tomoemonさんによる打鍵時間視覚化ツールを使ってみた。きれーなグラフが◎。
http://typer.me.land.to/tool/type_optimize/
……で、ためしに打ってみた。
「honjituhaseitennari」@Qwertyローマ字
ことえり問題。
項目名について、tomoemonさんが悩んでいらしたらしく。
「押下時間」ってのは、「押下間隔」かなぁ。
で、「押中時間」ってのは「指残(り)時間」かなぁ。
そう考えてグラフを眺めてみると……私のロマかな入力って、思いっきり「指残りしまくり」*1なんですね……これがロマかなの打鍵速度を落としている原因なのかもorz。
同時打鍵シフト系の場合、「さいごの文字キーを単独押下したあと」については、
- タイマー設定時間が来る前に離したとき──最後の文字キーを離した時点で確定する。
- タイマー設定時間が来る前にシフトキーを押したとき──シフトキーを押した時点で確定する。
- 押下したまま、タイマーに設定した一定時間が経過したとき──最後の押下開始から、タイマー分だけ時間が経過したときに文字が確定する(打鍵時間測定ソフトにおいては、こういうシーンは考慮しなくていいと思う)。
になる、と。で、そうではない入力法で「さいごの文字キーを単独押下したあと」については、
- 一切の制限なし──最後の文字キーを押した時点で確定する。
になる、と。
……すると、総打鍵時間は同時打鍵シフト系の場合、
- 文字キーを離したとき──最後の文字キーを離した時点で確定する。
- シフトキーを押したとき──シフトキーを押した時点で確定する。
になって、そうではない入力法では、
- 一切の制限なし──最後の文字キーを押した時点で確定する。
になる、と。
全体的な感想。
「打鍵プロセスをそのままアンシフトで記述する」というのは、シンプルでとてもいい方針だと思います。
もちろん「長い文章を記述する」というのなら、これはまるっきりハズレになる……のですが、こういった「短文の正確な測定」を目的としていて、なおかつ「個人製作配列などであっても使えるくらいの柔軟性を狙っている」場合には、「個別対応用の配列データはソフトウェア側で持たずに、利用者側が手動翻訳してから使う」方針がとても有効ですので。