フォーム vs. アプリケーション

フォームが、コンピュータとの複雑なインタラクションを表す最良のメタファとなることは稀だ。にも関わらず、多くの大企業が、紙ベースのフォームを受け継いでいる。結果として、イントラネットには、ニーズに応えようとするオンライン・フォームが散乱している。アプリケーションを使えば、リアルな対話と本格的なGUIで、そのニーズはもっと上手く満たされるというのに。

最近、ある人から１本の電話があった。イントラネット用のフォームを見て、ユーザビリティ上の問題点を指摘して欲しいと言うのだ。単独のページにフォーカスをあてて評価するのはあまり好まない。ウェブサイト全体とか、イントラネットの対象エリアといった、所謂コンテクストが見えない状態では、巨大なプロジェクトの中の限られた一部、狭い範囲を見てユーザビリティ評価をしても意味を為さない場合が多いからだ。今回は、良いお付き合いを続けてきたお客様からの依頼だった。これまでのご恩に報いるつもりで、この依頼を受けることにしたのだが、引き受けて良かった。このフォーム、ユーザビリティ的には課題の宝庫だったのだ。ファイナルレポートにはなんと27もの指摘事項が記述された。

このフォームには57個のインタラクション・エレメント（ラジオボタンを使った選択肢群やテキスト入力欄、メニューなど）があり、加えて、ヘルプへのリンクも多様に用意されていた。長さは 3,350 ピクセル — 標準的なモニター（1024×768）で見ると5画面分に相当するほどのものだった。

皆さんのウェブサイトやイントラネットに、こんなフォームがあったりはしないだろうか？ あるとしたら、アプリケーションを使って構造化し直してみよう。フォームのメタファは、シンプルなものにはうまく機能する。eコマースサイトで送付先住所や請求先住所を入力してもらうような場合だ。たとえこのデータが、複数のステップに横断的な関わりを持ち、32項目に及ぶユーザビリティ・ガイドラインを有する買い物カゴや支払いプロセスから成る巨大なワークフローの一部だとしても。

フォームを使うべきとき

単純なデータ入力以外に為すことがほとんどないという場合にはフォームが機能する。テキスト入力欄を並べ、ユーザには何も考えずにただ入力をしてもらうのだ。何らかの意思決定を促す設問も、数が多くならなければ受け入れられるだろう。送付先住所と請求先住所を同じにするか、あるいは別にするか、といった典型的な設問が考えられる。ここでも、ほんの少し双方向性を持たせるだけでユーザビリティは向上する。たとえば、“請求先住所は送付先住所に同じ”のチェックボックスをユーザ自身が外さない限りは、請求先住所の入力欄をグレイアウトさせておくのだ。

もっと複雑なインタラクションの場合は、単純なフォームだとかえって苦労を強いることになる。フォームとするか、インタラクティブなデザインにするか、以下の基準を参考にしていただきたい：

• 要求される情報の複雑さ。苦労することなく、頭を使わずに入力できるデータが求められる場合には、フォームを使おう。頭を使って考えたり、資料を参照したりする必要が出てくる場合には、アプリケーションを使う（ことにして、参照資料へ簡単にアクセスできる機能も提供したい）。
• ステップ数。少なければフォームを使い、多くなるならばアプリケーションを使ってステップを分割し、自然なワークフローを構成してあげよう。
• 条件付きの入力エリア。設問や選択肢が常に一定ならば、フォームを使おう。入力項目が、ユーザのとってきたそれまでのアクションに応じて変わってくるならば、アプリケーションを使い、当該ステップに関係する選択肢のみを表示するようにしよう。
• 線形性。条件付きの入力エリアは、非線形性の一例である。他の例を挙げるならば、たとえば、ただひたすら前進あるのみで、前のステップに戻ったり、修正したりする必要がない場合はフォームを使う。ステップ同士が相互に影響しあうことがなければフォームを使うのだ。ステップ間を行き来したり、予測不可能な順序でステップを完了していく必要があるならば、アプリケーションを使おう。

フォームの単なる長さが、分割するかどうかの決め手になるわけではないことは注記したい。確かに、フォームは１～２画面程度におさえることが望ましい。それ以上になるなら、設問や選択肢の削減をまず真剣に考えるべきである。そうでもしなければ、ユーザの負担が増し、回収率は低くなってしまうだろう。しかし、どの項目も削れないのであれば、長くなっても１枚ものとして作成しよう。いずれの項目も簡単なものにしてあげるのが肝要だ。ユーザは、ひたすらスクロールを（ため息交じりに）続け、ステップを一つずつこなしながら、最後にお出ましになる送信ボタンを待つのである。

アプリケーションの利点

将来的には、タスクやデータの種類に応じて最適化されたユーザ・インターフェイスを有するスタンドアロン型のインターネット・アプリケーションが、数多く見られるようになるだろう。Napsterのsubscription managerやiTunesのmusic store、Google mapsなどは、その先端を行く恰好の例である。Windows Vista (コードネーム Longhorn)が一般的に使われるようになれば、ネイティブコードで作られるユーザ・インターフェイスと見た感じなんら変わりのないものを、インターネットの機能として、コードのダウンロードだけで提供できるようになるだろう（XAML/Avalon）。ただし、そうなるまでには相当の時間が必要だ。（よく言われるように、テクノロジーが世に出始めても、自分のウェブサイトに採用するには少なくとも２年は待った方が良い。）

現時点で私が“アプリケーション”と呼ぶものは、スタンドアロン型のバイナリーとしてダウンロードされるものや、FlashやJavaScriptのようなVista以前、現世代のインターネット用プログラミング言語に実装されているものである必要はない。ここで言っているユーザのタスクで主に必要となるのは、サーバー上に、プログラミングの大部分、あるいは全部があって初めて意味を持つウェブページの一部として実装され得る一時的なアプリケーションなのである。

アプリケーションが、巨大なウェブサイトやイントラネットの中に埋め込まれたページの集合体の一部にすぎないとしても、プログラマブル・ロジックとワークフローを持つという点でフォームとは異なる。フォームと比べたときに、アプリケーションには以下のような強みがあると考えられる：

• ユーザを集中させる。ワークフローが複数のステップに分割されることで、ユーザは、一度に一つのトピックを集中的に考えられるようになる。ユーザの集中力を取り合うことになる他の要素が画面上にないおかげで、注意が散漫になることは減り、ユーザの負担は軽くなると考えられる。これが利点となるためには、ユーザが納得できるようにアプリケーションをモジュール化し、外にある情報を参照しなければならない状況を最小限におさえることが望まれる。
• コンテクストの中にヘルプを置く。画面上のアイテム数が減るのだから、それぞれを丁寧に解説する余裕が出てくるはずだ。ボタンやメニューにはテキストや例を添えて、正しい使い方を補足説明できる。こういった情報は、メイン画面に配置されるのが望ましい。なぜなら、別ウィンドウで表示されるヘルプ画面へ遷移することをユーザは好まないからだ。ヘルプ画面を別に出さざるを得ないならば、ユーザがワークフローのどのステップに対峙しているかにあわせてヘルプテキストが表示されるようにして、少しでも使いやすいものにすることが、アプリケーションならば可能である。
• 画面が混み合うのを避ける。画面に表示されるアイテム数が少なくなることのもう一つの利点は、スペースの制約が減ることで、レイアウトがしやすくなることだ。たとえば、ドロップダウンメニューを使わずに済むし、小さなリストボックスに、スクロールしなければ見られないほどの選択肢を詰め込む必要もなくなる。代わって、選択肢を一覧できるゆとりのあるメニューを置くことができる。そうすれば、選択を素早く済ませられるうえ、エラーも防げるだろう。
• 関係のないステップを見えなくする。自分には関係しない設問や選択肢を目にする必要はない。ご自身のビジネスでは、たとえば、顧客が既婚者かどうかを知ることが肝要だとすると、独身のお客様に対しては、そもそも存在しない配偶者に関する設問は見せる必要がない。“問25に「はい」と回答した方は、問26へお進み下さい。そうでない方は問27へお進み下さい。”のようなインストラクションをユーザがいちいち読まなければならないフォームは、長くて厄介なものになるはずだ。
• ワークフローを柔軟にする。アプリケーションを使えば、ユーザ自身が一番納得のいく順番で進めるようにしてあげられる。参照が必要なデータにも、その都度、容易にアクセスできるようにしてあげられるだろう。たとえば、買掛金を管理するアプリケーションが支払いプロセスを進めるために仕入先番号を必要とした場合、検索のインターフェイスを作動させて、ユーザに仕入先を名称から特定してもらうだけで、番号をはじめとする必要情報を他のアプリケーションへ自動的に転送されるような仕組みを作ってあげられるのだ。（フィールド・スタディでユーザを観察していて、ユーザが画面に表示される情報を、別の画面に入力するためだけにメモ用紙に書き写している様子を目撃したら、データの転送を自動化することで、生産性を高め、エラーを減らすチャンスがそこにあることを確認したことになる。）
• フィードバックを提供する。プログラムが可能であることを利用して、コンピュータがユーザの入力や選択をどのように解釈することになるかを示し、ユーザに確認してもらうのだ。たとえば、ユーザに仕入先番号を入力してもらうなら、仕入先の名称を表示することでフィードバックを返す。これだけで、仕入先番号の誤入力に起因するエラーを劇的に減らすことができるだろう。
• カスタマイズを可能にする。アプリケーションが繰り返し使われるものならば、頻度の高いアクションには、ユーザが自分でショートカットを作れるようにしてあげるのだ。たとえば、経費の申告に使うアプリケーションが、自家用車を使ったときの仮払い精算を行うために走行距離の入力を求めるとしよう。従業員が同じルートを頻繁に使うような場合（空港まで、大切なお客様の事務所まで、など）、アプリケーションなら、入力頻度の高い距離をワンクリックで表示できるようにしたり、名前を付けて（“オフィスからJFK空港まで”といった具合）リスト表示できるようにすることも可能だ。
• ボックスやボタンを超えたインタラクション・エレメントを提供する。スライドはもちろん、ユーザに画像の中で興味のある部分に印をつけてもらうようなことまで、アプリケーションなら、どんなGUIも搭載できる。

アプリケーションの弱点

アプリケーションには、二つの深刻な弱点がある。一つ目は、プログラミングとテクノロジーに依存するため、それなりのコストとバグの危険性が避けられないことだ。かなりの品質でデバッグできるときでなければ、コードをゼロから作るようなことは避けた方が良い。さもなければ、ユーザを助けるどころか、かえって困らせることになるだろう。

二つ目に、アプリケーションは、全容の見えない状態で新しいコマンドを理解することをユーザに求める。もし、出来が悪ければ、以上二つの弱点がアプリケーションのユーザビリティを大幅に下げることになる。ユーザに求められる行為がシンプルで（スクロールのみ）、何も隠れていない（ページの下方を見えるようにするためにスクロールは必要になるとしても）１ページもののフォームと比べても、それは劣ることになるだろう。ウェブ・ベースのアプリケーション46種をテストした結果、アプリケーションによるタスク構成や目指すゴールをユーザが前もって理解しきれていないことが、もっとも深刻な問題の一つであることが明らかとなった。

結論としてガイドラインを示すならば、アプリケーションの概要をまず呈示し、ワークフローや期待される成果を見えるようにすることが肝要と言えるだろう。もちろん、オーバーヘッドの増加に繋がり、ウェブサイトやイントラネット上に置かれる一時的なアプリケーションの更なる弱点となってしまう。しかし、ユーザに課せられるタスクの多くは非常に複雑で、かつてのフォーム・メタファを廃止し、インタラクティブなユーザ・インターフェイスによる支援を提供することが、結局はユーザビリティの向上に繋がるはずだ。

2005 年 9 月 19 日