2017年10月9日月曜日

IMEの状態を認識しづらいので、誤入力が絶えない問題の解決例

PC上で日本語や英語の文字列を入力したいとき、IMEの状態がわかりにくいので、誤入力してしまうことが多く、ずっと悩んでいる。


IME状態のわかりにくさと誤入力


ここでいう誤入力とは、たとえば「google」と入力したいのにIMEをオフにするのを忘れて「ごおg」と入力したあたりで気づき最初からやり直すようなことをいう。逆に「グーグル」と入力したいのに「guuguru」と入力してやり直すようなこともある。
IMEがオンになっていることに気づかず入力している

IMEの状態はタスクバーの「あ」「A」表示などでたしかに確認できるが、スクリーンの端に小さく表示されているだけなので、およぼす影響に対して、見た目の差が小さすぎて違和感を覚える。またカーソル位置からタスクバーへの視線移動距離が長いケースでは、特にユーザーの支払うコストの高さを感じる。

各IMEの状態表示の工夫


この問題に対し、カーソル位置近くにIME状態を表示する解決方法をとるIMEもある(Google日本語入力、ATOK等)。これは良い方法だが、IME状態が切り替わった瞬間から数秒間表示されるだけでなので、「IME状態を認識するためにIME状態を切り替える」ことになりかねず、解決される場面が限定的である。
Google日本語入力

Windows10付属のIMEでは、切り替えた瞬間にスクリーン中央に大きく入力モードを表示できるようになった(窓の杜より)。これも良い方法だが、やはり「現在のIME状態を前もって認識して、スムーズに入力したい」という要求の解決からは少しずれている。あらかじめIME状態を知る手段ではないからだ。

マウスカーソル近くに常時IMEモードを表示するフリーソフトもあった(ImeTray64)。
このアイディアはかなり良いが、Windowsの「IMEの切り替えはテキストエリアがキーボードフォーカスを持っているときに限定される」という仕様のせいで、「あらかじめIMEをこれから入力したい文字種モードにしたい欲求をWindowsによって抑止されてしまう」気分を何度も味わうことになると思う。
ImeTray64

WebブラウザのテキストエリアをIMEの状態によってハイライトする、Chromeの機能拡張「IMEチェッカー」というものもある。

ユーザの状態認知とそれの改善


手元のWindows環境はアプリケーション(のスレッド)ごとにIME状態を保持しているようだが、それが不便に感じられることも多い。たとえば「このアプリでは日本語しか使わない」とか「このボックスは英文しか入力しない」ことがわかっている場合であれば合理的かもしれないが、英文と日本文どちらを入力するか、入力するまでわからないようなアプリを横断的に利用するような場合においては、全てのアプリごとのIME状態をユーザー側があらかじめ認知しておくことを前提としたデザインにも見える。このため、いたずらに大きな記憶負荷を要求しているように思えた。

以上の問題は、おそらく「アプリ個別ではなくシステムが共通のIME状態を保持する」モデル上で、「ユーザーの注視点近く」に「認識しやすいカラー・形状」でIME状態を「常時表示」して、しかも「常時切替可能」にすると解決しそうな気がする。
昔のDOSや現在のスマートフォンではだいたいできていることだと思うが、スクリーンの大きなPCではこれが実現できていないケースがあり、文字入力UIの障害のひとつになっていると思った。

IMEオン専用ボックスとオフ専用ボックスを作ってみた


ところで、発想を変えて、これまで説明したようにIME状態をユーザーが能動的に切り替えるのではなく、固定化されたIME状態を持つUIをユーザーに選択させるという方法を考えてみた。
この場合、ユーザーは最初に必ず選択をしなければならないので、「IME状態を知らないから誤入力してしまった」という状況はありえない(ただし呼び出すUIを間違えることはある)。
というわけで、IME有効・無効状態それぞれの検索ボックスを、ホットキーであらかじめ選択して、Google Chromeの検索文字列を入力するUIを作ってみた(下図)。

IMEオフ専用テキストボックス(ホットキー[Insert]で出現)


IMEオン専用テキストボックス(ホットキー[PrtSc]で出現)




テキストボックスはホットキーを押すとスクリーン中央に出現するようにした。
Chromeの検索にしか対応していないが、いまのところ結構使いやすいように思える。自信をもって誤入力なしにキーをうちはじめられる気がする。
ホットキーをどれにするかは改善の余地があるかもしれない。色調で区別できるようにし、大きめのフォントを使うようにした。C♯で作った。

2017年4月15日土曜日

Managed DirectX を Windows10 で導入して DXPresentation を動作させる

次のリンクからdirectx_Jun2010_redist.exeをダウンロードする。
実行すると、ファイルの展開場所を聞かれるので適当なフォルダを指定する。
フォルダの中のDXSETUP.EXEを実行するとDirectX9cをインストールすることができる。

DirectX End-User Runtimes (June 2010)

これでDXPresentationを実行できる。しかし、マウスカーソルの表示がおかしいようだ。

2017年3月4日土曜日

チューリッヒのドライブレコーダーZ-Assistを取り付けた

チューリッヒ保険のドライブレコーダーZ-Assistを自分の車に取り付けた。
Z-Assistはチューリッヒの自動車保険を契約すると貸してもらえる、緊急通知機能つきのドライブレコーダーである。3G通信モジュールを内蔵しているのが面白い。

細かい仕様の情報がネットに少なく事前にほとんどわからなかったので、箇条書きで書いておく。(特にスマートフォンを使った通信と内蔵3Gモジュールを使った通信の使い分けがよくわからなかった)
  • Z-Assistは事故などで強い衝撃をうけると、加速度センサーから得たG値とGPSから得た位置情報を、3G通信を使ってチューリッヒに自動的に送信する。このため3GのSIMカードが挿入されている。
  • そしてチューリッヒから利用者に対しては、あらかじめ登録しておいた電話番号へ連絡・プッシュ通知がおこなわれるらしい。
  • 緊急通知ボタンがあり任意のタイミングでチューリッヒに通知することもできる。
  • Z-Assistは事故などで強い衝撃をうけると、そのとき記録していた事故のビデオや走行データを、Wifiを使ってスマートフォンのアプリに渡し、そこからチューリッヒに送信することができる。
  • Z-Assistは東芝製。動画の画質はとても悪い。動画フォーマットはMP4、15fps、640x480ピクセル、ビットレートは600kb/sくらい。白飛びがひどい。この画質では事故時の調査資料やある程度の証拠になるとは思うが、ドライブ動画として楽しむような用途には適さないと思う。音声はない。超広角。
  • Z-Assistは電源がはいっていれば常時録画する。録画データは8Gbytesの内蔵メモリに記録される。車両が停止するたびに別のファイルになっているように見える。時刻が#時:#0分になるたびに、つまり10分毎にファイルが生成されているようにみえる。それらをスマートフォンのアプリを用いてWifi経由でダウンロードできる。このときユーザーはサムネイルを取得し、ダウンロードリストを作り、そしてダウンロードする必要がある。この手順はタスク志向なUIとはかなり離れたものなっていて、タスク分解をユーザー自身がする必要があり理解はできるが使いにくい。また車の運転が終わったあとエンジンを切らずに結構な時間をかけて手動でダウンロードする使い方になり、もどかしい。
  • スマートフォンにダウンロードしたドライブ動画をPicmvrで転送しようとしたが、保存場所がよくわからなかった。MTPで見える場所に動画ファイルが無いような気がする。とりあえず共有機能を使ってOneDriveにコピーすることはできた。(追記:SDカードのAndroid\data\jp.co.toshiba.zassist\Videoに動画ファイルがあった。MTPで見ることはできない)
  • トヨタのアクアにDIYで取り付けた。説明書通りにフロントガラス上20%以内でドライバービュー的に邪魔にならずなおかつワイパーの動作範囲内で、というと一箇所しか取り付け場所がないと思った(下図)。

Picmvr 0.75を公開した


変更点は以下の通り。
  • 転送ルールの削除・複製・移動が全くできなくなっていたので修正した
  • 転送準備中においてを処理を中止するボタンが表示されず、そのほかのUIも意図通りに表示されなくなっていたので修正した

ダウンロード:
http://www6.plala.or.jp/nyk/Picmv.html

2017年2月25日土曜日

Picmvr 0.74 を公開した / MTP/PTPを使ったファイル列挙が恐ろしく遅いデジタルカメラの問題

0.72からの変更点は以下の通り
  • 転送終了後の処理としてファイルを読み取り専用化できるようにした(設定メニュー)
  • MTP/PTPを用いたファイル名列挙が非常に遅いデジタルカメラ機種があった。これに対処するため転送除外フォルダの設定をできるようにした(設定メニュー)。
  • MTP/PTPポータブルデバイスの名前が取得できないスマートフォン機種があったので修正した。
  • 読み取り専用ファイルに対する上書き処理はこれまでエラー扱いだったが、スキップ扱いに改めた。
  • MTP/PTPポータブルデバイスのコピー履歴によるスキップ処理において、小文字が含まれているファイル名に限り、正しくスキップされないことがあったので修正した。
  • UI調整

MTP/PTPを使った転送処理で、ファイルの列挙がとても遅い機種があった。具体的には手持ちのニコンとソニーのあるカメラだ。あまりにも遅いので苦肉の策としてver.0.73において転送除外フォルダ設定をできるようにした。

ここで不思議なのはファイル列挙は遅いがファイル転送は遅くないことである。

それらのカメラのファイル列挙はWindowsのエクスプローラーでも遅かった(ファイルが徐々に現れるさまが目視できるくらい遅い)。だからPicmvrのコード・アルゴリズムのせいではなさそうだ。
また、手持ちのiPhoneやAndroidスマートフォンのMTP/PTPによるファイル列挙はとても高速に動作した。だから、プロトコルとしてのMTP/PTP自体の問題ではない。
ということは、それらのカメラのMTP/PTPファイルの列挙する処理の何かが重いように見える。