YosukeM's

非同期に対するUIの戦略

ファイルやネットワークなどの比較的遅い処理を伴うアプリケーションにおいて、ユーザーには処理の遅さを感じさせないようにしたい。そんなときどうするか。

・とりあえずユーザに応答
　ウェブアプリケーションでよくやる。とりあえず、ユーザに対するUIの応答（画面への描画や効果音の再生）だけ先にやっておき、実際の書き込み処理はバックグラウンドでやる。
　書き込み処理が失敗した場合に、画面表示をリセットしたり、書き込みキューをクリアしてやる必要がある。
　これをより推し進めて、書き込みキューをGUIで操作できるようにしているソフトウェアもあるが、これを有効に使えている人を僕は見たことがない。

・単一画像/テキストの表示
　読み込み/書き込み中に一枚絵を表示する。いわゆるスプラッシュスクリーン。手抜きっぽいが、何もしないよりは遙かにマシである。
　よくあるパターンとして、ロード画面を利用して、操作説明やヒントを表示するものがある。なんども同じヒントが表示されると、ユーザは飽きてしまい、まともに読まなくなるので、効果が薄れるという欠点がある。

・進捗状況の表示
　ダウンロード率や、プラグインXXを読み込み中……といった情報を表示する。ダウンロード率を表示することによって、ユーザーは残り時間を予測し、他の作業をすることができる。待ち時間が非常に長い場合には効果的。
　インストーラやダウンローダなど、事務的なアプリケーションでは、こうした表示を出した方が信頼感があってよい。
　一方で、待ち時間が短いことがあらかじめわかっており、かつ、ユーザにシステムを意識させたくない場合には、この手法は適していない。

・アニメーションを表示
　アニメーションを再生して、読み込みが終わるまで待つ。一口にアニメーションと言っても、いくつかのパターンが考えられる。

・ループアニメーション
　昔のゲームでよくあった。開始と終了をなめらかに結ぶために、フェードイン、フェードアウトくらいはつけることもある。フェードイン途中でロードが完了した場合どうするのか。フェードアウトはどのタイミングで開始するのか、などが問題になる。完全にロードが完了するのを待ってフェードアウトしていると、ユーザーを拘束する実時間は長くなってしまう。ロード時間が極めて短い場合には、あえてアニメーションを流さない方が体感時間を短くできる。

・ノンループアニメーション
　近年採用例が多い。見せ方によっては、読み込みを全く意識させず、2つのシーケンスがきちんと繋がっているように見せることができる。
　アニメーションがロード時間より早く終わってしまった場合はどうするのか考えておかなければならない。よくあるパターンは、ブラックアウトしてごまかすか、ループアニメーションに移行するかのいずれかである。

・画面のスナップショット
　これもノンループアニメーションの一種だ。現在の画面のスナップショットを取り、それをフェードアウトさせることによって、アニメーションの代わりにする。スナップショットを取った瞬間に現在のシーンに関する情報を破棄することができるので、メモリを無駄遣いしない。WiiとGCで出てたゼルダ（タイトルは忘れた）がこれだった。クラッシュバンディクーもこれだった。

・インタラクティブアニメーション
　開き直ってロード中もユーザに操作する余地を与える。採用例は少なくないし、ユーザの反応も悪くないが、ユーザ体験に大きな影響を与えるので、企画段階からそれなりに考えておく必要がある。

・音楽を流す
　BGMのあるソフトウェアであれば、ロード中も音楽を流し続けることによって、ユーザの体感時間を短くできる。ロード前とロード後で同じBGMを使うことが許されるならこれでいい。問題は、BGMを変えたい場合だ。音楽が演出に与える影響は大きいので、なるべく細かく制御できることが望ましい。

　変更すべきBGMが事前に分かっているかどうかによっても、取り得る対応が異なる。
　二つ以上のサウンドを同時に読み込むのが苦しい環境では、前のサウンドをある程度バッファリングしておく必要がある。バッファが切れたときはどうするのか。ストリームしながら読み込むと、当然のことながらロードにかかる実時間は長くなる。悩みが多くなるので、機械の性能が限られているときは、素直に音を消した方がいいと思う。

・BGMを繋ぐ音を生成する
　インタラクティブミュージック的なアプローチ。採用例は少ない。JSRFとか。

・逐次表示
　ウェブブラウザなどで採用されている方式。読み込みの完了を待たず、今あるリソースを使って、不完全でもいいので画面を描画する。今コンピュータが頑張ってますよ感をアピールできる。プログレッシブJPEGやLoDなど、これを意識したデータ構造を用意するとよりよい。
　利点としては、ユーザを待たせる実時間が最も短くなる。データの先頭が重要で、それ以外は子葉末節であるという場合に効果的だ。
　欠点としては、不完全な画面をユーザに見せてしまう。どうしても見せたくない場合には、他の手法と組み合わせる必要がある。それから、自分で実装しようと思うと結構大変。

・隣接ノードの先読み
　これまでに上げた手法は、UIのシーケンスが非連続的に繋がることを前提としていた。しかし、メモリに十分な余裕があるのであれば、連結可能なシーケンスを先読みすることによって、シーケンス間の断絶を避けることができる。
　この応用の最たる例としては、ワンダと巨像のオープンフィールドなどがある。しかし、きちんと実装するのは非常に難しい。例えば、先読みが間に合わなかった場合にどうするのか。遠景をどのようにして描くのか。メモリの断片化を避けるにはどうすればいいのか。考慮すべき事柄は多い。

・全部一律で遅くする
　UIの応答をあえて遅くするという方法がある。重要なのは、一時的に遅くするのではなく、常に遅くするということだ。ユーザーの操作に対して、画面が常に2〜5フレーム程度遅延していたら、人は遅延になれてしまう。そこで、処理時間を稼ぎ、ファイルやネットワークに関する処理を行う。
　複数のフレームの処理を並列に行うための仕組みを用意する必要があるが、それさえ用意してしまえば、そこから先は早い。全てのユーザー入力が遅延するため、柔軟性に乏しいのが欠点だ。
　何かのアーケードゲームでこの方法を使っていた。たしか、バーチャファイター5だっただろうか。

・読み込まれる情報の予測
　これはUIには応用しがたいかも知れないが、一応書いておく。具体例はPSOである。PSOでは、味方プレイヤーの位置をネットワークから持ってくるよりも先に、位置を予測して描画してしまう。
　この位置の予測はそれほど狂わない。なぜならPSOのキャラクターの動きはもっさりしていて、慣性によるところが大きいからだ。それに、PSOではプレイヤー同士が殴り合ったりするわけではないので、多少、位置がずれていても問題ない。
　Google Mapの読み込み戦略はこれにあたる。

・まとめ
　なんとかがんばって一般化できるんじゃないかと考えたけど、難しい。

最初は、義務を増やせば部として安定するだろうと思った。
たとえば、展示会を定例化するとか、年一回は作品を出すよう部員に義務付けるとか。
だけどそれをやってしまうと、発展性がない。自由な発想の余地がない。
同じことの繰り返しの中から、生じるクリエイティビティもあるかもしれないけれど、やっぱり、自分としては、常に環境に応じて変化を続けられるサークルであってほしいなと思った。
それに、サークル創立時のコンセプトからすれば、クリエイティビティを失った時点で、もはやこのサークルがサークルとして存続する価値はない。

というわけで、あまり義務を作らないことにした。

テントはぶっちゃけ失敗だったと思う。
参加者するといっていた人が予想を下回ったというのも正しいし、そうなることを予測できなかった運営の、事前のリサーチが足りなかったというのも正しい。
当初の目的を見失っていた感じがある。
つまり、黒字を出して利益を獲得することに対する意欲が足りない。
去年結局あまり利益が出せなかったという点も、それなりに影響を与えていると思う。
個人のポケットマネーになるはずが、部費になってしまったというのがよくない。
人にお金をあげて、自分が利益に貢献したという実感を与えるべきだった。

そう、実感。
所属意識がどうこうというのならば、まず先に、部員たちが部としての利益になんらかの形で関わってもらうことが必要だったかな、と思う。
たとえば、僕にとっては、春先にやったウェブサイト制作。あれが部としてのメリットになると同時に、自分の評価を高める材料として作用した。
そういう、部にとってメリットがあると同時に、各個人にとっても、役に立った！人から評価された！という感触が必要なのかな、という気がする。
結局、団体としてうまくまとまっていくためには、義務を増やす必要がある。
ただし、対外的な義務ではなくて、体内的な、もっとメンバーに運営側としての自覚を持ってもらうための義務だ。

昔やっていた某仮想週刊誌では、ある時期運営メンバーがものすごく不足して、それに危機感を感じた古株が、新人を編集部に引き込むキャンペーンを展開した時期があった。
そのときに引き込まれたメンバーは、今でも中心的ポジションで、腕を振るっている人たちが多い。
その理由を考えてみると、やっぱりなんだかんだといって、「編集部にはいった」というそのこと自体が、一番大きく関与しているのではないかと思われる。
編集部にいれば、何ヶ月かに一度、企画を立てようという話になるし、結果として運営に関わることになる。
そのときの経験が、後に愛着心となって、人を居残らせる。

というわけで、何かしら強制的に、今までなら運営がやっていたような仕事をヒラの部員にやらせるというフェイズが、必要なのかな。
責任の所属を明確にして、逆にいえば、この部分は俺がやったと、他人にアピールできるような部分を作ってやらないといけないのかな。