私を含め「はてなアンテナの管理画面は使いにくい」という声があるようです。私も便乗して書いてみることにしました。一般的な話として書いてみます。書きはじめたら思ったより長文になってしまって。なんだか仕事用のドキュメントみたいになっちゃうし。いうわけで文体が「である調」になってます。ここの戯れ言ではなく本屋へ行ってしかるべき本をチョイスする(またはそのための正規の教育を受ける)ことを強くお勧めする。ここに書いたことは私の体験にもとづくものであり必ずしも全てのケースに当てはまるわけではないからだ。アプリケーションにおけるユーザ操作とは何なのか考えてみよう。アクセスであることが分かる。操作の基本は検索と表示(select)追加(insert)更新(update)削除(delete)の4つに集約できる。これら4操作が(ユーザにとって)ストレスなく行われるように画面設計をすればいいのだ。設計について(大雑把ではあるが)ある「法則」が見えてくる。設計が下手な人が大抵やってしまうのが「ひとつの画面にたくさんの機能を盛り込む」ことだ。それは単に設計の怠慢に過ぎずユーザの要求を必ずしも満たしていない。場合はレイアウト設計が比較的簡単にできるためこのような間違いに陥りがちである。私もやってしまった経験がある。この手の間違いの最悪のケースが「はてなアンテナ」の「詳細編集」画面だ。ひとつの画面の中にスプレッドシート形式で上記の4操作が全て組み込まれている。情報を追加するのに既存のデータが見える必要はない。ある情報を更新するのに更新に関係ない情報まで見えている必要はない。情報を「ブラウズ」するだけなら更新機能は必要ない。操作の結果が画面に表示されている全ての情報に影響が及ぶと感じる。操作に関係のない情報や機能を相乗りさせることはユーザにとってストレスになるのだ。余計な情報を表示することによる「待たされ感」もユーザにとってストレスとなる。画面単位の機能は最小限に。操作に必要な情報の表示も最小限に。ブラウザをプラットフォームとするアプリケーションにおける「原則」だ。アプリケーションが「Wiki」である。画面設計によって「小さな悪戯心」を起こさせないようにしているのである。ひとつの画面の中で機能が完結していれば状態管理はそれほど複雑にならない。これは設計センスの問題である。「ウィザード形式」のアプリケーションにとりつかれている人には難しい要求かもしれないが。「削除」機能は表示画面または編集画面に含めてもよい。削除機能を表示画面や編集画面に含めることは合理的である。削除操作が対象データ以外のほかの情報にも影響を及ぼす場合は(影響範囲を示した)確認画面を別途用意すべきだ。ブラウザの「戻る」とか「再表示」とかいった機能は既定動作としてユーザに対して許可されている操作である。ブラウザを立ち上げて並行作業をしたり作業の途中でアプリケーションを強制終了してしまうのも「あり」なのだ。したがって作り手はこれらの操作イベントも考慮に入れて設計する必要がある。等で禁止しようとするからおかしなことになる。ユーザは操作のどの時点でも手順の巻き戻しやショートカットができる。状態管理を行うのは結構大変である。これに対する解決法は以下の2つ。他画面の状態に依存する設計を極力避ける。ユーザが操作を間違えた場合でも簡単にリカバリできる手段を提供する。アプリケーションに限定した話ではない。設計全般に共通する話だ。状態管理が複雑にならないよう工夫されている。ブラウザ」というプラットフォームにはそのような仕組みがない。使って擬似的にダイアログ・ボックス風の画面を出すことはできる。モーダルではない)手順の巻き戻しや再表示やショートカットを許容するということは多重登録される可能性があるということだ。これはユーザ・サイドがどんなに気をつけてもおこり得る。テーブル設計にも気をつける必要がある。安易なテーブル設計を行うと多重登録を許してしまうことになる。(特にデータが大量がある場合には)意味がない。それよりもユーザからのリクエストに対しサーバ・サイドで多重登録をチェックする方が「親切な設計」である。ユーザは作り手の想像もつかないような操作をする。これはいたちごっこの世界で禁則行為を増やしてもしょうがない。それよりも常にどの時点でもリカバリが効くような設計を心がける方が賢明である。リカバリがない画面設計はユーザを不安に陥れ操作に「決断」を強要してしまう。いうのはどうしても操作手順が多くなる。操作では手間がかかり過ぎると感じるようになってしまう。一括処理ができるような仕組みを用意すべきである。一括処理の場合は最低でも「追加」と「削除」が用意されていればよい。全削除してから全追加するといった手順で代用できる。データのバックアップ機能とリストア機能もあった方がよい。この場合はバックアップとリストアでフォーマットを合わせておけば必ずしも「標準」にこだわる必要はない。同種の他サービスとの互換性を意識する場合にはフォーマット変換機能を持つインポート機能やエクスポート機能も必要になるだろう。設計する人は一括処理について深く考えないことが多いように思う。一括処理はどのような規模のアプリケーションであれ(保守を行う段階で)必ず必要になる。設計上の問題でうまく実装できないことがある。一括処理機能は「必須の機能」として設計の初期段階から考慮しておくべきである。もてはやされた時代もあった。クライアント・サイドのスクリプトはセキュリティ上の要請から敬遠される傾向にある。推奨してないのを皆さんご存じだろうか。アプリケーションを運営しているサイトが(特に企業サイトに)多く見受けられる。これらの機能を操作手順のクリティカルな場面で使用すべきではない。メソッドを使ったポップアップ・ウィンドウである。アプリケーションが実に多い。そのポップアップ・ウィンドウで情報を設定しないと手順が進まないような設計になっているところがあるのだ。メソッドは広告表示やブラウザ・クラッシャ(通称「ブラクラ」)を嫌うユーザによって無効になっている場合がある。このようなユーザに対して上記のような画面設計ではまるで使い物にならないことになる。使うのなら必ず代替え手段を用意すべきである。派手で美麗なサイトがもてはやされる時代は終わった。ユーザが欲しているのはどんな環境でも「確実に機能する」サイトである。