前回の記事、(使い勝手に関する氷山のたとえ) では、Webベースの設計とグラフィカル・ユーザー・ インターフェース (GUI) ベースの設計の違いについて少し触れました。今回の記事では、この点をもっと詳細に説明します。GUI環境とWeb環境とが具体的にどのように異なっているかを比較し、こうした違いを踏まえた上で取るべき設計方法を示唆します。相違点のほとんどは、両者のユーザー・モデル が根本的に異なっているのが原因です。もう1度、氷山の例えで言えば、この相違はいわば水面下に隠れた部分であり、見かけ上の単純さよりもはるかに奥の深い要因です。

ユーザー・モデルの違いに対処するための方策を指摘することは、この連載記事の範囲を超えています。私がこの相違点を取り上げる意図は、読者の注意を促し、認識を高め、考えを刺激して、もっと調べていただきたいということです。基本的な情報を得るには、IBMのWebサイト「Ease of Use」の 「Design」セクション (「参考文献」を参照) をご覧ください。この記事を読んでいる方々には、少なくとも、GUIの手法を盲目的かつ単純にWebアプリケーションに 取り入れるようなことは避けていただきたいと思います。GUIの中にはそのまま取り入れても差し支えないものもありますが、まったく不適切なものもあります。設計段階でユーザーの考えを常に取り入れるようにすれば、悲劇を防ぐことができます。あなたのサイトのユーザーはどんな人たちかをよく把握し、紙に鉛筆でスケッチを描く程度でもいいですから、ユーザーにも設計に加わってもらうことが大切です。設計の初期段階でユーザーに参加してもらうさまざまな方法が、すでに実証されています (「参考文献」を参照)。

GUIとWebのスタイルの相違点の中には、非常に明確で、設計上のガイドラインを定めるのが適切なものもあります。今後の記事では、フォームにおけるUIの制御、Webページ・ナビゲーションの問題と手法、(ウィンドウ、ダイアログ、メッセージなどの) 表示要素の使用方法、ユーザー支援の手法、ビジュアル・スタイルといった、使い勝手の良いWebベースのアプリケーションを設計するうえで かぎとなる設計上の指針を紹介する予定です。

ここで言うGUI とは、デスクトップ・メタフォー、つまり従来のウィンドウ、アイコン、メニュー、ポインターからなるインターフェース要素 (WIMP) を指します。Webスタイルの方は、情報中心のサイトからe-commerceおよびe-businessのサイトへ の変化を反映しています。GUIアプリケーション設計とこれまでの 情報中心型Webサイトとの違いはすでに認識されています。今後、e-businessアプリケーションの枠組みへの移行がますます進むにつれて、GUI-Web間のさまざまなギャップを埋める必要性が高まってくるでしょう。この記事では、GUIとWebのスタイルの違いを生み出した原因を明らかにし、ユーザーが操作をするうえでこの違いがどんな影響を及ぼすかについて指摘し、すでにWebの世界で始まりつつあるアプリケーション中心の流れに 注意を払うよう読者の考えを刺激します。可能な限りベストなユーザー・エクスペリエンスを 創り出そうとしている私たちデベロッパーが利用できる、オプションや方法をより良く理解していただきたいと考えています。

分析の枠組み

この分析の枠組みとして、GUIとWebスタイル・インターフェースの両方に共通する、人間とコンピューターとのインターフェースを構成する主な要素を以下に挙げます。

• インストールとセットアップ
• 主なユーザー概念
• ユーザー・スペース
• 表示要素
• ナビゲーション
• 対話
• ビジュアル・スタイル
• ユーザー支援
• 機能性と効率
• 統合と整合性
• セキュリティーと可用性
• アンインストールとクリーンアップ

GUIの使用形態はWebの使用形態と多くの点で似ていますが、大きく異なる面もあります。Webサーフィンは、ワープロ・ソフトの操作などよりもずっと簡単だと多くの人は感じています。確かに、サーフィンはそれほど複雑な操作ではありません。ブラウザーのメカニズム (ブックマークやブラウザー・オプション) を除けば、ユーザー・モデル、つまりユーザーが理解しなければならない一連の概念はいたって簡単です。しかし、サーフィンの途中に、ユーザーは自分が今どこにいるのかわからなくなり、混乱することがあります。これは、場所 (ロケーション) の感覚が ユーザーにうまく伝わっていないことを意味します。このように、ユーザー・モデルの概念的な面の重要さが、簡単なWebブラウズの場合にも当てはまるのです。

最近のWebは進歩して、従業員給与管理、発注管理、在庫管理などの企業間 (B2B) アプリケーションを サポートするようになりましたが、このことを考慮に入れると、かかわりのより深い、より重要な問題が浮かび上がってきます。それぞれのアプリケーションは、やがて、さまざまな概念からなるユーザー・モデルを提供することになるでしょう。これは現在のGUIアプリケーションや そのグリーン・スクリーン版とはまったく異なります。上に挙げた一連の要素は、そのようなアプリケーションがユーザー・エクスペリエンスを創出するうえで、かぎとなります。ただし、上のリストは時間の流れの一瞬を捕らえたスナップショットに過ぎません。今後、ますます多くの企業がB2Bのパラダイム (枠組み) を採用するにつれて、これ以外の相違点が明らかになり、新たな手法も追加されていくでしょう。

上に戻る

インストールとセットアップ

GUIユーザーは、プログラム のインストール、構成、個別設定、アップグレードを行います。

Webユーザーはページへのリンクをたどり、ページを表示して読み、フォームに入力し、各種のサービスに登録します。また、オンライン・データをダウンロードして保存したり、プラグインのインストールを行うこともあります (もっとも、プラグインのインストールを明示的に実行することは少なくなりましたが)。

ブラウザー自体を除けば、Webユーザーにはプログラム の概念がありません。インターネット準拠デバイスが使用されていれば、ブラウザーそのものが環境になります。Webユーザーは、コンピューターのしくみをそれほど意識しません。ただし、Web環境をセットアップするには、ほとんどの場合、ダイヤルアップその他の接続パラメーターを設定しなければなりません。これは経験豊富なユーザーにとっても面倒な作業です。

一般的に言って、どちらの環境のユーザーも、インストールやセットアップ作業を好んで行うわけではありません。単に、さまざまな機能を利用できるようにしたいだけです。したがってインストール作業とセットアップ作業が より自動化され非明示的になればなるほど、ユーザーにとっては快適です。

上に戻る

主なユーザー概念

GUIの世界では、ユーザーが作業を行うために利用するツールなどのプログラムを、オペレーティング・システム (OS) が実行します。最近のOSはオブジェクト指向が進んで、ユーザーは作業対象のデータだけに注意を集中しやすくなっていますが、それでもユーザーからはプログラムというものがはっきり見えます。ユーザーはプログラムを開始 して、データ・ファイルを開き ます。

一方、Webの世界では、ブラウザーを使ってさまざまなWebサイトのページを表示します。通常、Webサイトは企業、団体、またはそれらのサブディビジョン (組織の一部) を表す顔となっています。ユーザーは特定のサイトをナビゲートして、ページを表示させます。一部のユーザーは、e-commerceやe-businessのトランザクションに参加します。また、何かをダウンロードすることもあります。

Webの世界では、場所 の概念をもっとしっかりさせなければなりません。ユーザーは安心感と安定感を必要としています。自分が今どこにいるのか、ここからどこに行けるのか、現在の場所を出て、さらに別の 場所に行くにはどのリンクをたどればよいか、こうしたことをユーザーは知る必要があります。Webページ設計において、サイト内のすべてのページでビジュアル的に一貫した要素を採用すると、場所の感覚をはっきりさせるのに役立ちます。同じように、ビジュアル表示方法やリンクのレイアウトに関する何らかの規則を定めれば、リンクをたどった結果がどうなるか (たとえば、このサイト内の別の場所に行くのか、それともこのサイトの外に出るのか) を伝えることができます。

上に戻る

ユーザーの概念上のスペース

GUI環境は、ユーザーによるデータ・アクセスを制御し、ユーザーが自分のデータを保管したり管理することが 可能なスペースを制御します。即時アクセスの可能なデータは、通常、ユーザーまたはユーザーの関係者が所有し管理する ローカル・ディスク・ドライブやLANに格納されます。データは、通常、認知および信頼されたソースによって作成され、利用されます。私用データと共用データの概念があり、ユーザー・スペースのサイズは有限で、その特性や機能一般は、どんなファイル・システムが使われているかに依存します。

Web (あるいは、少なくとも、イントラネットに含まれないインターネットの部分) には、出所を確認できないコンテンツがたくさん存在し、実にさまざまな団体が混在して、個人データを提供したり編成したりする余地がほとんどありません。ブラウザーのブックマーク機能を使えば情報へのリンクを 編成することが少しは可能であり、個別ポータルによっても付加的な編成が可能でしょうが、管理対象のデータはユーザー提供データではなく、他人が提供するものです。大多数のユーザーは、Webに情報を発信 しません。自分のホーム・ページを公表することができるユーザーもいますが、あくまで少数派です。私用データの保管という概念は強くありません。スペースの大きさは膨大で、ほとんどのユーザーから見て、事実上の無限スペースです。

Webユーザーが繰り返し利用する情報を編成して すばやくアクセスできるようにするための機能が必要です。多くのブラウザーに実装されている現在の機能は未発達で、問題が残っています。Webポータルについて言うと、きわめて限られた情報しか編成できない場合がほとんどです。Webのどんな場所にある情報をも見付け出し、個別の表示方法を編成して、簡単にアクセスできるようにする機能が必要とされています。

上に戻る

表示要素

GUIアプリケーションの主な表示要素には、データ表示用のクライアント域を含む1次ウィンドウ (メイン画面)、ダイアログやメッセージを表示する2次ウィンドウ、メニュー・バー、ツールバー、ポップアップ・メニューなどがあります。独自の環境を継承または確立する一部のエンターテイメント、マルチメディア、3Dアプリケーションを除いて、すべてのアプリケーションは、プラットフォームのツールキットが提供する 実質的に同じ基本的表示要素を使います。また、GUIのほとんどの表示要素はきわめて一時的で、ポップアップ・ウィンドウ、ダイアログ、メニュー、メッセージなどは現れたかと思えばすぐに消えます。

ほとんどのWebユーザーは、2つの世界を体験しています。通常、ブラウザーはGUIアプリケーションであり、ユーザーは従来のGUI表示要素をたくさん見かけます。しかしブラウザーのクライアント域ではWebページが表示され、そこにはテキスト、イメージ、アニメーション、オーディオ、ビデオなどが混在します。Webページ作成ツールを利用すれば、いろいろなものを混ぜた設計を容易に生成することができます。時折、Webページ設計者たちはこうした柔軟な機能に夢中になるあまり、ユーザーを混乱させるものを作ってしまいます。Webに関する標準はGUIの世界よりも少ないですが、共通のツールキットや標準がいくつか提案され、採択されてきています。

Webにしか見られない特徴 (たとえば待ち時間の存在、スクリプトその他のページ埋め込み技法を歓迎しないユーザーの存在) は、ページ表示方法に関する設計上のオプションを大きく左右します。

上に戻る

ナビゲーション・メカニズム

GUIユーザーはメニュー、ツリー、リスト、ダイアログ、ウィザードなどを使用して、ほとんどゼロに近い応答時間を経験します。ナビゲーション・メカニズムは、UIツールキットおよび スタイル・ガイドによって標準化されています。これらのナビゲーション・メカニズムは、クライアント域の情報を補足 します。GUIアプリケーションでは、ナビゲーションの概念ははっきり確立されていません。機能やアクションが主流を占め、ナビゲーションは副次的作用です。ナビゲーションを行うプッシュボタンもあれば、行わないプッシュボタンもあります。たとえば、「OK」、「キャンセル」、「ヘルプ」などのボタンがユーザーの注意を 他のウィンドウに向けさせるのに対して、「適用」ボタンはそうではありません。「名前を付けて保存」などの、ルーティング・メニュー選択項目の省略符号は、明確なナビゲーション感覚を提供します。ウィザードもまた、一直線状に並んだ複数のダイアログに基づき、次に進んだり戻ったりするナビゲーション感覚を提供します。

Webユーザーにとって、ナビゲーションは重要ではっきりと目に見える概念です。Webユーザーはリンクやブックマークを利用したり、URLを入力します。待ち時間は大きな意味を持ちます。よく普及している標準は、「戻る」ボタンなどを含めてごくわずかです。ナビゲーション・メカニズムは、通常、ページの設計方法から継承されるため、多種多様なメカニズムが存在して、一貫性に欠けます。これは、ユーザーを最も混乱させている点の1つです。

場所 の概念 (つまり、今どこにいるか、どこに行けるかをユーザーに理解してもらうためのコンテキストの確立) は、Webの世界ではきわめて重要です。設計者は、「go to (...へ進む)」および「bring to me (ここに呼び出す)」という2つの基本的な 枠組みを採用できます。「go to」の枠組みでは、ユーザーは意識して移動を選択します。リンクを選択した時点で、ユーザーは移動していることに気付きます。コンテキストは大きく変化しますが、ユーザーはそれを知っているので驚きません。「bring to me」の枠組みでは、現在のページのコンテキストの中で、情報を「どこそこに届ける」ようユーザーが要求します。この枠組みはコンテキストを保持し、安定感と場所の感覚を提供します。それぞれの枠組みは、特定の状況にふさわしい方法です。この点については、別の記事で触れます。

上に戻る

対話

GUI設計における標準的な対話の技法には、ダブルクリック、ドラッグ・アンド・ドロップ、切り取り / コピー / 貼り付け、メニュー選択項目をクリックする、「OK」「キャンセル」などのボタンを押す、ツリーを拡張または省略表示する、リストから選択項目を選ぶ、などがあります。これらの対話は、通常、現行のアクティブ・プログラムを表すウィンドウの、クライアント域で確立されたコンテキストの中で適用されます。

Webページの基本的な対話は、リンクの上をシングルクリックすることです。しかし、この単純なクリックによってコンテキストは大きく変化します (たとえば、別のWebサイトに移る、情報のコンテンツとナビゲーション・フレームを変えて 他のページへのリンクを提供する、など)。こうしたコンテキストの変化はユーザーにとってわかりにくく、見落とされる場合が多いのです。さらに、ブラウザーの方でもこれと並行する メカニズム (「戻る」ボタンや「履歴」リストなど) を提供していますが、これが混乱の原因となる場合もあります。アクションとリンク (つまりナビゲーション) とは、簡単に区別がつきません。たとえば、e-commerceのWebサイトの中には、チェックアウトをプッシュボタンとして実装しているところもあれば、単にHTMLリンクとして実装しているところもあります。

上に戻る

ビジュアル・スタイル

エンターテイメントとマルチメディアのアプリケーションを除いて、GUI環境のビジュアル面の設計は、プラットフォーム・ツールキットによって定められ、制約されることがほとんどです。クライアント域でビジュアル的な創造性を発揮することは可能ですが、それほど簡単ではありません。グラフィックス・デザイナーとしての技術と グラフィックス・プログラマーとしての技術の両方が必要とされるからです。ユーザー・オプションやスタイル上の 選択肢が多少は提供されているものの、意味のあるユーザー選択やパーソナライズを行える余地は ほとんどありません。

Webの場合、ビジュアル面の設計はまさにWebそのものです。Webはより芸術的、個性的、自由奔放なスタイルを大切にします。帯域幅のような問題によって制約を受けることも時折ありますが、ビジュアル・デザイナーたちは、ビジュアル・メタフォーを自由に使いこなすことができます。ビジュアル面の設計を複雑にしている別の要因は、ウィンドウ・サイズや縦横比の変化に合わせて最適な表示方法を 調整しなければならないこと、および、最小公倍数的な (どんなユーザーにも利用できる 最低レベルの) ブラウザーや表示機能に合わせる必要があることです。それでもなお、ユーザーのオプションは限られていて、ブラウザーのオプションやサイト固有の選択肢が提供されるだけです。多数の企業および団体にとって、Webサイトは自らのアイデンティティーとイメージを反映します。彼らはWebサイトの外観にこだわり、他人がそれに手を加えることをひどく嫌います。

Webより前から存在するB2B (企業間) アプリケーション をWebで採用すると、より以前のGUI設計に逆行するかもしれません。しかし、Webから得られるビジュアル・アピール度も捨て難いものです。したがって、より高度な混成型インターフェースになると思われます。

上に戻る

ユーザー支援

GUI環境で最も普及している要素は、おそらくヘルプ・システムでしょう。GUI環境では、ヘルプはシステムおよびアプリケーションの付属物 です。ヘルプにアクセスするには、F1キーや「ヘルプ」メニューといった標準的メカニズムに従います。プラットフォームの提供するヘルプ・システムはオーサリングをサポートし、ハイパーテキストにリンクされたヘルプ情報をサポートします。すばやく役立つユーザー支援は、通常、情報領域と状況域、ポインターを使った吹き出しヘルプ、それにヒントなどからなります。オンライン・ユーザー・マニュアル、チュートリアル、READMEファイル、テクニカル・サポート連絡先情報もまた、広く使われています。

Webページの場合は、このようにあらかじめ準備されたヘルプ・システムはありません。支援情報はページそのものに組み込まれていることが多く、吹き出しヘルプはリンク先の情報をプレビューで示すだけです。ユーザー・マニュアルなどは存在しません (少なくとも、そのサイトの他のページから見分けることができません)。ほとんどの支援情報は組み込み型 です。何らかのカスタマー・サービスやテクニカル・サポートを 提供しているWebサイトは多いですが、ほとんどの場合、それらはサイトが提供する商品やサービスに関連したものであり、サイトそのものの利用法を教える支援情報ではありません。サイト向け支援情報が得られる唯一の機能は、WebマスターにE-mailを送ることだけという場合がほとんどです。ブラウザーは通常GUIアプリケーションですから、ブラウザーの使用方法に関する支援情報は プラットフォームのヘルプ・システムを使って得ることができます。このように、ユーザーは互いに分かれた2つの異なる支援方法を 体験しているわけです。

どちらの環境の場合も、従来の意味での「ヘルプ」をほとんど、またはまったく必要としないアプリケーションが、これから成功していくでしょう。一般的に言って、使いやすいインターフェースには、ユーザーが必要とするであろうあらゆる情報が保管されています。たとえば、ほとんどの場合、入力フィールドを提供するよりも、選択項目をリストする方が優れた方法であることはよく知られています。ここ何年かの間に、後者の支援メカニズムがあまりにも普及したため、私たちはそれが当たり前だと思っています。これは良い傾向です。それに付け加えるユーザー支援機能をとても役立つものにするには、ユーザーの次のような質問に答える必要があります。

• これは何か
• これは何をするか
• その機能をどのようにして実行できるか
• スキーム全体の中で、これはどんな役割を果たしているか

設計戦略とインターフェース設計技法の観点から見た これらの質問に対する答えは、ユーザー支援に焦点を絞った今後の記事で紹介します。

上に戻る

機能性と効率

「プログラミングで何でもできる」とよく言われますが、プログラミングにはGUIの世界と同程度の制限があります。機能性は、スピード、メモリー・サイズ、ハードウェア・プラットフォームの構成、およびソフトウェアの完成度に比例して大きくなります。

一方、Webの世界にはもう少し大きな制約があります。ハードウェア・プラットフォームによって課される制約に加えて、Webの世界はブラウザー、(D)HTML、Javaテクノロジー、JavaScriptなどの機能によって制約されるほか、クライアント側が、待ち時間、セキュリティー、プライバシーを考慮して そのような機能を使用可能にするかどうかの意思決定に左右されます。

機能性と同じように、GUI環境でタスクを実行する際の効率は、タスク実行に使われるプログラミングの量に大きく左右されます。いずれにしても、プログラミングは特定タスクを想定し、特定ユーザーを対象とする場合がほとんどです。

Webの場合は、ブラウザーの設計、ネットワーク能力の高さなどの効率の影響をある程度受けます。不特定多数の人を対象にするタスクが多く、どんなユーザーが実際に利用するかわからない場合がほとんどです。B2Bアプリケーションでは、これを変えなければならないことは明らかです。いつでも、どこからでもアクセスできるインターネットではGUIの世界の 制約の多くが取り除かれることを考えると、その必要性はいっそう明らかです。

クライアント / サーバー型の多層ネットワークにおいて、機能を分割する最適の方法はどんなものかを決めるために、多くの労力が注がれてきました。実にさまざまな要素が関係していますが、ここで議論するのはふさわしくありません。いずれにせよ、ユーザー・エクスペリエンス を常に念頭に置くべきです。設計上の戦略やネットワーク構成がどうであれ、ユーザーの視点から設計全般を評価することが大切です。遅延する対話の数、遅延の長さ、セキュリティーおよびプライバシーが破られる可能性といった 要素を考慮する必要があります。

上に戻る

統合と整合性

GUI環境において、整合性は重要な命題です。各プラットフォームのUIツールキットは、アプリケーションを超えた整合性の実現を1つの大きな目標としています。プラットフォーム内部で自己整合性が達成されれば、ユーザーは1つのアプリケーションを利用して身に着けた知識を 別のアプリケーションで利用できます。たとえアプリケーションの内容に関してはこれが当てはまらないとしても、少なくとも、インターフェースそのもののしくみに関する 知識を活かすことができます。

Webでは、各サイトが独自のアイデンティティーを持つ傾向があります。(D)HTMLやJavaテクノロジーなどの一般的な機能が使用でき、グローバルに課される制約がほとんどないため、設計の整合性をどの範囲まで広げるかは 各サイトの決定にかかっています。多くの団体が、自らのサイト全体にわたって 何らかの標準を採用しています (対象ユーザー、地理的場所、トピック、サブディビジョン (組織の一部) などによって定義される)。ユーザーの知識 (今どこにいるか、関連情報や必要情報はどこにあるか、どのようにしてそこにアクセスするか) を別の場所で活かせるようにするためにも、ある程度のレベルの自己整合性をやはり実現すべきです。

GUIアプリケーションの2番目に重要な命題は、統合および相互運用性です。すべてのアプリケーションは、プラットフォームにスムーズに統合されることが期待されています (たとえば、クリップボードへの切り取り / コピー / 貼り付けのサポートなど)。さらに、主なアプリケーションのほとんどは、相互運用性を高めるためのインポート / エクスポート機能を実装しています。プログラム・デベロッパーがこれらの機能を簡単にサポートできるかどうかは、主にGUIツールキットやコンポーネントにかかっています。

ほとんどのWebサイトでは、ナビゲーション、印刷などの機能に関して、サイト内部で 基本的なレベルの統合が実現されていることは明らかです。しかし、これは統合というよりは、むしろ自己整合性です。Webサイトには、自分が他とは違っていたいという傾向があります。さまざまなサイト間の相互運用性ではなく、プラットフォーム非依存性およびアイデンティティーが目標です。この傾向は、企業間環境への移行を伴う発展とともに変わってくるでしょう。

整合性とは、常に相対的なものです。つまり、ある物には、別の何かとの間に整合性があります。よく見過ごされがちな点ですが、最も重要な要件、つまりユーザー・エクスペリエンス との間に 整合性があるかどうかは、大きな意味を持ちます。自己整合性の起源は、おそらく、プラットフォーム、アプリケーション、サイトといった要件よりもむしろ、ユーザー側の要件ではないでしょうか。ユーザーがさまざまなアプリケーションやコンテンツにアクセスできたら、ユーザー自身の必要性や経験に合ったインターフェース・メカニズムを 使用できるとしたら、何とすばらしいことでしょう。

上に戻る

セキュリティーと信頼性

GUI環境では、セキュリティーと信頼性のどちらも、投資意欲に応じて厳格に制御することができます。ほとんどのソースやユーザーはすでに信頼されているものの、データ・アクセスを明細に制御することができます。データ共用およびパスワード・プロトコルが普及しています。かつて、一般家庭のPCユーザーはセキュリティーの心配をする 必要などありませんでした。せいぜい、物理レベルでのアクセス制御が必要な程度でした。信頼性とは、通常、クライアント・コンピューターに関する陳述であり、ローカル・エリア・ネットワークを対象とすることもあります。このどちらも、ユーザーまたはユーザーの組織による制御の下に置かれます。

Webは機密漏れの点で批判されていますが、一部の企業や消費者がいまだにWeb利用をためらっている主な理由は この点です。ブラウザーの提供するセキュリティー・オプションは 平均的ユーザーにとってわかりにくく、仮にオプションを選択した場合、(たとえばcookiesが使用不可になるなど) 機能が 制限されるという副作用が発生します。より単純で、より信頼できるように見せるために、セキュリティー・レベルを採用する試みがなされています。また、必要なパスワードの数が増大し、ウォレットのようなパスワード・メカニズムに問題が残されているとはいえ、パスワードの使用も普及しつつあります。Webでは、信頼性の公表がインターネットを通して、また、さまざまな提供者を通じて広がります。ローカルにユーザー制御が行われる要素に加えて、ユーザーは、電話回線やケーブル回線のプロバイダー、インターネット・サービス・プロバイダー、ホスティング・サーバー、リモート・アクセス先のサイト およびアプリケーションなどによる中断の影響を受けます。

Webの場合、アクセス制御の問題は、ユーザーが絶えず接続している場合には特に大きな問題になります。この問題は、毎日の利用にかかわる問題に発展しかねません。ユーザーは環境の安全性を保障することを要求し、ユーザー自身がほとんど、またはまったく努力しなくても、自動的に安全が得られることを期待するようになるでしょう。また、インターネット・サービスやアプリケーションへの信頼できる 接続およびアクセスを期待するようになるでしょう。設計戦略の側では、100 %使用可能というイメージを抱かせるために、バックアップや代替経路を提供する必要があります。結局のところ、完全に信頼できる状態でなければ、いつでもどこでもアクセスできるメリットはありません。ユーザーの期待するレベルは急激に高くなっています。

上に戻る

アンインストールとクリーンアップ

これらはGUIの世界で一応サポートされているものの、それほど頻繁に実行されるわれではありません。しかし、実行すると問題の発生する場合が多く、残骸を残してしまいます。もっと悪いことに、他のプログラムが必要とするファイルや、一時ファイルの入ったディレクトリーを削除してしまうことさえあります。

(一般ユーザーに理解できない) ブラウザーのプラグインの場合を除いて、アンインストールは今のところWebとは無縁な概念です。ブックマーク、キャッシュ、その他の古くなった情報のクリーンアップという作業がありますが、ユーザーはこの作業を実行したいとは思わないか、または作業の必要性に気付いていません。ユーザーは、こうした保守が自動的かつ非明示的に実行されることを期待しています。

設計戦略においては、ユーザー環境を理想状態に保つ自動的な 保守およびチューニングを目指すべきでしょう。ユーザーがシステムから機能を除去できるようなアクションを提供する場合、ユーザー・ニーズをよく理解したうえで、障害の危険がない形で提供する必要があります。

上に戻る

まとめ

Web設計と、従来のGUIアプリケーション設計との違いをよく考慮してください。設計上の具体的なガイドラインが存在するケースもあります。あるいは、設計時にこれら2つの環境がどのように互いに異なるかを考え、少なくとも、GUI設計を盲目的にWebアプリケーションにコピーことは避けてください。全体的に言って、最も良い設計とは、あらゆる局面でユーザーのことを考えるような方法です。ユーザーの目標、戦略、作業、動機など、ユーザーのことがわかって初めて、私たち設計者はさまざまな設計環境への適切なマッピングを提供できるのです。

参考文献

• Dick Berry氏によるこの連載の最初の記事は、効率的なアプリケーション設計にとって、ルック・アンド・フィールが氷山の一角に過ぎない理由を説明しています。
  
  
• 最先端の設計ガイドラインについてお知りになりたい場合は、IBM Ease of Use サイトにアクセスしてください。Webの設計から独創的なエクスペリエンスまで扱われています。また、使いやすさに関するIBMの世界的な年次会議である "make it easy 2001" に参加する方法についても説明されています。
  
  
• Usability Professionals' Association Webサイトには、設計の初期段階でユーザーに参加してもらうさまざまな方法が提供されています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 分析の枠組み
• インストールとセットアップ
• 主なユーザー概念
• ユーザーの概念上のスペース
• 表示要素
• ナビゲーション・メカニズム
• 対話
• ビジュアル・スタイル
• ユーザー支援
• 機能性と効率
• 統合と整合性
• セキュリティーと信頼性
• アンインストールとクリーンアップ
• まとめ
• 参考文献
• 著者について
• コメント