Web ブラウザをプラットフォームとした UI 設計

（この記事は「もっと辺境から戯れ言」に投稿した記事からの転載です）

最近，私を含め「はてなアンテナの管理画面は使いにくい」という声があるようです。（まさか私が言い出しっぺじゃないですよね）

この件に関して結城浩さんが「はてなアンテナの使いにくさについて」という優れた文章を書かれているので，私も便乗して書いてみることにしました。といっても今更「はてなアンテナ」をターゲットにするのもナニなので，もっと一般的な話として書いてみます。本当は本家に載せるつもりだったのですが，書きはじめたら思ったより長文になってしまって。しかもなんだか仕事用のドキュメントみたいになっちゃうし。というわけで文体が「である調」になってます。ご了承ください。

あらかじめ言っておくが，本気で UI 設計について考えるのであれば，ここの戯れ言ではなく本屋へ行ってしかるべき本をチョイスする（またはそのための正規の教育を受ける）ことを強くお勧めする。ここに書いたことは私の体験にもとづくものであり必ずしも全てのケースに当てはまるわけではないからだ。

まず基本に立ち返って Web アプリケーションにおけるユーザ操作とは何なのか考えてみよう。するとユーザ操作のほとんどは M/W またはバック・エンドの DB へのアクセスであることが分かる。 DB 操作の基本は

検索と表示（select）
追加（insert）
更新（update）
削除（delete）

の4つに集約できる。つまりこれら4操作が（ユーザにとって）ストレスなく行われるように画面設計をすればいいのだ。そう考えると Web ブラウザをプラットフォームとした UI 設計について（大雑把ではあるが）ある「法則」が見えてくる。

「一画面につき一機能」を原則とする

UI 設計が下手な人が大抵やってしまうのが「ひとつの画面にたくさんの機能を盛り込む」ことだ。しかしそれは単に設計の怠慢に過ぎずユーザの要求を必ずしも満たしていない。特に HTML の場合はレイアウト設計が比較的簡単にできるためこのような間違いに陥りがちである。私もやってしまった経験がある。

この手の間違いの最悪のケースが「はてなアンテナ」の「詳細編集」画面だ。ひとつの画面の中にスプレッドシート形式で上記の4操作が全て組み込まれている。

しかし考えてみて欲しい。情報を追加するのに既存のデータが見える必要はない。（「多重登録を防ぐためには必要じゃないか」と思うかもしれないが，それについては後述する）ある情報を更新するのに更新に関係ない情報まで見えている必要はない。単に情報を「ブラウズ」するだけなら更新機能は必要ない。

ユーザはある画面で操作するとき，操作の結果が画面に表示されている全ての情報に影響が及ぶと感じる。したがって，操作に関係のない情報や機能を相乗りさせることはユーザにとってストレスになるのだ。また余計な情報を表示することによる「待たされ感」もユーザにとってストレスとなる。画面単位の機能は最小限に。そして操作に必要な情報の表示も最小限に。これが Web ブラウザをプラットフォームとするアプリケーションにおける「原則」だ。

この原則に忠実で非常によくできていると思われる Web アプリケーションが「Wiki」である。 Wiki はよく「善意のシステム」と呼ばれるが，それだけではない。画面設計によって「小さな悪戯心」を起こさせないようにしているのである。

「画面が増えればそれだけ状態管理が複雑化するのではないか？」と思うかもしれない。しかし，ひとつの画面の中で機能が完結していれば状態管理はそれほど複雑にならない。これは設計センスの問題である。「ウィザード形式」のアプリケーションにとりつかれている人には難しい要求かもしれないが。

もちろん例外もある。例えば「削除」機能は表示画面または編集画面に含めてもよい。削除操作の場合ユーザ側で対象となる情報を確認する必要があるので，削除機能を表示画面や編集画面に含めることは合理的である。ただし，削除操作が対象データ以外のほかの情報にも影響を及ぼす場合は（影響範囲を示した）確認画面を別途用意すべきだ。

「戻る」や「再表示」は既定動作として扱う

本家の話の繰り返しになるが， Web ブラウザの「戻る」とか「再表示」とかいった機能は既定動作としてユーザに対して許可されている操作である。もちろん URI を直接ロケーションバーに書いて手順をショートカットしてしまうのも「あり」だし，もっと言えば複数の Web ブラウザを立ち上げて並行作業をしたり作業の途中でアプリケーションを強制終了してしまうのも「あり」なのだ。したがって作り手はこれらの操作イベントも考慮に入れて設計する必要がある。設計ををサボって下手に Javascript 等で禁止しようとするからおかしなことになる。

ユーザは操作のどの時点でも手順の巻き戻しやショートカットができる。このことを考慮に入れて UI の状態管理を行うのは結構大変である。これに対する解決法は以下の2つ。

他画面の状態に依存する設計を極力避ける。
ユーザが操作を間違えた場合でも簡単にリカバリできる手段を提供する。

しかし実はこれ，別に Web アプリケーションに限定した話ではない。「ウィンドウ」を単位にした GUI 設計全般に共通する話だ。

普通の GUI プラットフォームにはモーダル・ダイアログやウィザードといった仕組みが提供されており，状態管理が複雑にならないよう工夫されている。しかし「Web ブラウザ」というプラットフォームにはそのような仕組みがない。（Javascript などを使って擬似的にダイアログ・ボックス風の画面を出すことはできる。ただしモーダルではない）

手順の巻き戻しや再表示やショートカットを許容するということは多重登録される可能性があるということだ。これはユーザ・サイドがどんなに気をつけてもおこり得る。これを防ぐには画面の状態管理設計のみならず DB のテーブル設計にも気をつける必要がある。安易なテーブル設計を行うと多重登録を許してしまうことになる。既存のデータリストを表示して多重登録をさせないよう配慮している（つもりの）アプリケーションも見受けるが，（特にデータが大量がある場合には）意味がない。それよりもユーザからのリクエストに対しサーバ・サイドで多重登録をチェックする方が「親切な設計」である。

ユーザは作り手の想像もつかないような操作をする。これはいたちごっこの世界で禁則行為を増やしてもしょうがない。それよりも常にどの時点でもリカバリが効くような設計を心がける方が賢明である。リカバリがない画面設計はユーザを不安に陥れ操作に「決断」を強要してしまう。

一括処理を考慮する

Web ブラウザを含め GUI 全般に言えることだが， GUI というのはどうしても操作手順が多くなる。 DB 上のデータが少ない場合はそれでも問題ないが，データが増えてくると通常の GUI 操作では手間がかかり過ぎると感じるようになってしまう。そこで，あらかじめ一括処理ができるような仕組みを用意すべきである。

一括処理の場合は最低でも「追加」と「削除」が用意されていればよい。更新系の処理の場合は，いったん全削除してから全追加するといった手順で代用できる。またデータのバックアップ機能とリストア機能もあった方がよい。この場合はバックアップとリストアでフォーマットを合わせておけば必ずしも「標準」にこだわる必要はない。ただし同種の他サービスとの互換性を意識する場合にはフォーマット変換機能を持つインポート機能やエクスポート機能も必要になるだろう。

GUI を設計する人は一括処理について深く考えないことが多いように思う。しかし一括処理はどのような規模のアプリケーションであれ（保守を行う段階で）必ず必要になる。その時になって慌てて一括処理機能を追加しようとしても DB 設計上の問題でうまく実装できないことがある。（実は私もそういう経験がある）一括処理機能は「必須の機能」として設計の初期段階から考慮しておくべきである。

Javascript を信用しない

かつては「Dynamic HTML」などと呼ばれ Javascript がもてはやされた時代もあった。しかし今や Javascript などのクライアント・サイドのスクリプトはセキュリティ上の要請から敬遠される傾向にある。実は，あの ASP や ASP.NET でも Javascript や cookie をあまり推奨してないのを皆さんご存じだろうか。

このような時代に逆行するように Javascript をふんだんに使った（一見美麗な） Web アプリケーションを運営しているサイトが（特に企業サイトに）多く見受けられる。しかし Javascript を嫌うユーザがいる以上，これらの機能を操作手順のクリティカルな場面で使用すべきではない。

特に問題になるのが javascript::open() メソッドを使ったポップアップ・ウィンドウである。このポップアップ・ウィンドウをダイアログ・ボックスのように使い情報を設定させる Web アプリケーションが実に多い。（この cocolog もそう）しかもそのポップアップ・ウィンドウで情報を設定しないと手順が進まないような設計になっているところがあるのだ。しかし， javascript::open() メソッドは広告表示やブラウザ・クラッシャ（通称「ブラクラ」）を嫌うユーザによって無効になっている場合がある。このようなユーザに対して上記のような画面設計ではまるで使い物にならないことになる。

Javascript を使うなとは言わないが，使うのなら必ず代替え手段を用意すべきである。派手で美麗なサイトがもてはやされる時代は終わった。ユーザが欲しているのはどんな環境でも「確実に機能する」サイトである。よく言うではないか。「美人は三日見れば飽きるがブ○は三日見れば慣れる」って。

その他

以上，思いつくまま書いてみたが，今回は敢えてセキュリティに関する記述を省いている。それでもこれだけのことを考えなければならないということである。 Web アプリケーションってのは簡単じゃないし安くもないのだ。