タグ: flow

  • #OSH2014 感想と懇親会LT #nvdajp

    オープンセミナー2014@広島に参加しました。
    懇親会LT(ライトニングトーク)の私のスライド「テスト駆動開発とアクセシビリティ(仮)」は下記の通りですが、スライドだけではわからないでしょうし、トークも言葉足らずだったので、昼間のセッションの感想をふくめて補足します。

    NVDA 日本語版 の紹介。NVDA の開発には Python が使われています。
    実は「NVDA日本語チーム」を立ち上げる前に、私はまず「NVDAユーザ会広島」を立ち上げて、地域コミュニティ活動を始めました。
    オープンソースカンファレンス2013広島への参加の後、活動が滞っていますが、暖かくなったら再開したいです。
    アクセシビリティ、Python、Windows API、テキスト音声合成、自然言語処理、バージョン管理など、NVDA の開発を語る切り口はいろいろあるので、いろいろな団体と交流が必要だと思い続けています。
    NVDA は Web 開発者の方々にも、アクセシビリティチェックツールとして注目されています。
    NVDA は誰にでも無料で使えて、視覚障害をもつユーザーに実際に利用されている(され始めている)ツールです。
    一方で、ソフトウェアの自動テストという文脈からは、例えば Selenium でスクリプトを書いて Web アプリのテストをされる方も多いでしょう。
    NVDA が動いている状況で Selenium で Firefox を制御するスクリプトを書いて実行するとどうなるか、最近少し試してみました。
    Tab によるフォーカス移動、フォーム要素(コントロール)の操作、文字入力などはうまく制御できるので、Firefox でウェブを操作する様子を読み上げながら自動テストすることができます。
    しかし、NVDA が提供しているのは単なるフォーカス移動だけではありません。ブラウズモードという特別な操作が追加され、例えば数字キーの1から6で見出しジャンプができたり、文字単位で任意のテキストの内容を確認できたりします。
    こうした機能は Firefox ではなく NVDA がキーイベントを受け取って、NVDA と Firefox のプロセス間通信(IAccessible2という専用プロトコルが使われます)を通じて Firefox を制御しているため、Selenium で Firefox に ‘1’ や ‘2’ などのキーイベントを送っても見出しジャンプは実行されません。
    残念ですが、もうちょっと何かできないかなと検討中です、というのが最初に言いたかったネタでした。
    2個目のネタですが、NVDA を Windows 7 以降で使うと UI Automation という技術がデフォルトで有効になります。
    この技術は Windows システム・スクリーンリーダー・アプリケーション、というレイヤーをつなぐ一種のプロセス間通信で、特に GUI をリモートプロセスから制御するモダンなオブジェクトモデルを備えています。
    そして UI Automation は「ソフトウェアの自動テストの技術」でもあり、Microsoft のエバンジェリスト(当時)だった長沢さんが、そういう文脈でいろいろ記事を書いておられたわけです。
    しかし、和田さんの朝一番のセッションで FAQ として触れられた「GUIはテスト駆動開発に向いていない」という話は、私もうすうす気づいていた事実でした。
    Python 界隈では「Selenium は負債」という認識 がちらほら聞こえていましたが、どう「負債」なのかは、和田さんの講演で腑に落ちました。
    GUI テストは一般にターンアラウンドが長すぎて、「黄金の回転」が回せない、「ただのテストがある開発」になってしまうのです。
    「早くて小さい回転をうまく回す」という「TDDのこころ」を、テスタブルでアクセシブルなUIの開発という目標にどうつなげていくか、新しいチャレンジが必要と痛感しました。
    3番目のネタですが、NVDA 日本語版は点訳エンジンを「テスト駆動開発」しています。
    こう書くと大げさですが、実は liblouis という(日本語に対応していない)多言語対応オープンソース点訳エンジンはちゃんとテストを Jenkins でチェックしながら開発が行われています。
    それに倣って、日本語点訳エンジンを、まずテストを書いて、テストが落ちることを確認して、それから実装を直す、というサイクルで作ってみました。
    実際の作業は2012年春から2013年春にかけて行ったのですが、実は最初はタッチカーソルのカーソル位置を処理する「ポジションマッピング」というアルゴリズムを入れていませんでした。
    点訳エンジンをあちこち書き換えつつ、既存の処理を壊さずに最小限の修正でタッチカーソル対応できたのは、テストケースという命綱のおかげでした。
    最後に2枚追加したスライドは、昨日のオープンセミナーを通じて感じたことでした。
    私はチクセントミハイの「フロー体験理論」を1990年代後半に知り、最初はヒューマンインタラクションの評価手法などに応用したいと思っていました。
    スライドに張り付けた「技能と挑戦のモデル」はちょっと古いモデルの図ですが、要するに「いきなり難しいことをする、身の丈に合わないことをすると、不安になり、挫折する。自分の技能にあったちょうどよいレベルのチャレンジを繰り返していくと、人はその作業に集中でき、没入でき、自己目的的な楽しさを得られる」ということです。
    このフロー体験理論のことを最近ふっと思い出したのは「アジャイルサムライ」の読書会でした。
    フロー体験理論という社会心理学のモデルは、日本ではゲームデザインの研究者に着目され、近年ではモチベーションの研究で参照され、もはや古典なのかも知れません。
    しかし、テスト駆動やアジャイルというプラクティスの根幹に、フロー体験というシンプルな社会心理学のモデルが、やはり無視できないかかわりを持っているように、あらためて感じた、和田さんや長沢さん、そのほかの貴重な事例報告のセッションでした。

  • #wit58 二日目

    第58回福祉情報工学研究会、二日目の @24motz の記録。
    途中で フロー理論 の話がタイムラインに流れ込んできて、忙しい一日でした。。
    (さらに…)

  • 研究とリスク分散

    2009年の最後に起きた「「何かが欠けている音声認識研究」についての話。」事件について書いておきたい。
    私も彼と同じ場にいて、この講演をTwitter中継していた。
    (さらに…)