コマンドリンク

今よりも物事がシンプルだった時代には、ウェブサイト向けガイドラインの数々が存在し、その一方でアプリケーション向けガイドラインの数々が存在していた。そして両者は明らかに別物だった。たとえば、ユーザーの選択肢を表現するためには、以下のような別々のルールが示されていたのだ：

• ウェブサイトでは、リンク（アンダーラインを引いた色つきテキスト）を用いてナビゲーションを提供すること。
• アプリケーションでは、メニューやボタンを用いて機能を提供すること。

ウェブサイト向けとアプリケーション向けのガイドラインが別物だった理由（そして依然として別物である理由）は、「よいデザインとは、まずユーザー自身に基づいており、さらにユーザーのタスクに基づいている」という、ユーザビリティの金科玉条の一つによるものだ。ウェブサイトとアプリケーションでは、その後半部分に関して根本的な違いがある：

• ウェブサイトの場合： ユーザーのおもなタスクは、情報空間を動き回り、その内容を読み取ることである。
• アプリケーションの場合： ユーザーのおもなタスクは、コマンド（命令）を実行して、一連のデータの状態を変化させることである。

実は、まさにアプリケーションの定義こそが、その機能が外部の対象に作用してそれ自体のユーザーインタフェースに変化をもたらすもの、と言えるのだ。アプリケーションを利用すると何かを変化させることになるが、それはユーザーがその変化を要求するからである。それに対して、ウェブサイトはただ利用されているだけで、それ自体が変化するわけではない。ウェブページは、いつでも同じなのだ。（中身の情報は変化するかもしれないが、ウェブページとは、概念上は静的なものだ。たとえば、明日の天気予報のページが、仮に雨の日用と晴れの日用で違うアイコンを表示するとしても、常にこの“明日の天気予報”という情報を保持しているように。）

アプリケーションとウェブサイトの境界線があいまいに

ここ10年ほどを経て、ウェブサイトとアプリケーションの間には、はっきりとした区別がなくなりつつある。

まず第一に意味的レベルで見れば、ウェブサイトがますます多くの機能を提供するようになっている。真っ先に普及したのは「ショッピングカートに追加」機能であったが、ウェブサイトで表示する場合さえもこの機能がボタンで示されるのは、eコマースユーザビリティのガイドラインが常に付きまとうからだ。

そのため、アプリケーション的なウェブサイトの構成要素 ―― 普通の情報というよりは、機能やコマンドを表すもの ―― については、アプリケーションユーザビリティのガイドラインに従うべきだろう。（「ショッピングカートに追加」機能の場合と同様だ。）

第二の問題はさらに厄介である：構文的レベルで見ても、ボタンとリンクの区別があいまいになってきている。コマンドの中には、リンクとして示されているものもあるからだ。

幸い、われわれには少なくとも一つの明快なルールがある：ナビゲーション用にはボタンを使うべからず。ユーザーは別の情報ページに移動する場合、プレーンなリンクをクリックするはずなのだ。

ただし、このルールにさえ例外はある：「買い物を続ける」「レジへ進む」など、ショッピングカートの中での選択肢は、たとえ純粋なナビゲーション要素であったとしても、昔からボタンで示されてきた。ユーザーがこれら2つの選択肢のいずれかをクリックしても、何も変化は生じない ―― 次に実行すべきコマンドが用意されている別のページに、ただ移動するだけである。しかし、レジでの会計は作業プロセスの一部なので、ナビゲーションはプレーンなリンクで行うべき、という原則を放棄しても許されるのだ。

そうは言ってもほとんどの場合、ユーザーがページ間を移動するためにはリンクを用いるのが原則である。プレーンなリンクの使用には多くの利点があるが、ユーザーが自分の好みに応じて新規タブや新規ウィンドウでリンク先ページを開けることや、リンク先ページを訪問済みかどうかによってリンクテキストの色を変えられることは、とりわけ大きなメリットだ。

コマンドリンクをデザインするためのガイドライン

Windows Vistaは、コマンドを表現するための新しいGUIウィジェットを採用した。それが、コマンドリンク（command link）である。多くの人々が日常的に利用するシステムに何かが入り込むと、それはデファクトスタンダード（事実上の標準）になってしまうもの。Vistaユーザーはたびたびそれに出くわすことになるから、いずれコマンドリンクを理解し、それが現れると期待するようになるだろう。

多くのウェブサイトでも、すでにコマンド用にリンクを使っている。ただし、リンクをクリックすればコマンドを実行できると気づくユーザーが増えてはいるものの、混乱を招くおそれはまだ残っている。大部分のリンクは、ナビゲーション用のものだからだ。

混乱を少なくするには、リンクテキストの中で、そのリンクがただ新規ページに移動するだけではなく結果的に何らかのアクションにつながることを明示すべきだ。リンク周辺のテキストでこの情報を伝えるだけでは、不十分である：ユーザーは、何か操作できそうな部分を探してウェブページを斜め読みすることが多いからだ。つまり、ほとんどのユーザーはリンクテキストしか読まないだろうと想定しておいたほうがよい。実際、ユーザーがリンクテキストの先頭の数ワードしか読まないことさえ珍しくないので、リンクテキストを適切な単語から始めること（動詞から始めるのが一般的だ）、その単語がリンクをクリックした結果として起こるアクションを示していることが、非常に重要である。

大文字と小文字の使い分け（capitalization）のルールについては、各企業のスタイルガイドにおける、通常のリンク用のガイドラインを参照してほしい。スタイルガイドがない場合は、文単位の使い分けルールに従おう（コマンド名の先頭の単語の頭1文字のみを大文字にする方法のことだ）。例外として考えるべきなのは、リンク周辺のテキストに文中リンクが入っている場合である。ただし一般的には、本文テキストの中にコマンドを入れるのは避けるに越したことはない。文中リンクの使用は、ナビゲーション目的の場合に限るべきである。

コマンドリンクの使用は、以下を表現する場合に限定しよう：

• 比較的影響が小さいアクション。ユーザーは、リンクに見える要素をクリックする際、ただ新規ページが開くだけだと予測しているかもしれないからだ。たとえば証券取引用のアプリケーションの場合、「この株式を買う」というコマンドには、引き続きボタンを用いよう。
• 二次的なコマンド。ユーザーは、“重大な”または一番必要なコマンドを探している際には、画面上でボタンを探し回るものだからだ。したがって、（ユーザーの観点とデザイナーの観点のいずれかから見て）もっとも重要なコマンドは、ボタンとして表示すべきである。たとえば「買い物かごに追加する」ボタンは、今後もボタンのままとしよう。

コマンドリンクには以上のような制約があるにも関わらず、一方では新たな利点をもたらしたことで、受け入れられつつもある。もっともよく知られる利点は、ボタン上のラベルは短く（4単語以下に）しないとボタンが不恰好になってしまうのに対し、リンクを用いればより長いコマンド名を付けられるので、一段と意味が分かりやすくなるという点である。もちろん、ユーザーは文字を読むのを好みはしないので、コマンドの説明はできるだけ短くしておくべきだが。

Vistaでは、コマンドリンクの利点がもう一つお披露目されている：リンクテキスト本体の下に、説明テキストの追加ができることだ。この説明テキストは、それが二次的な情報であることを強調するために、一回り小さなフォントで表示できる（そのため、上級ユーザーならそれを読み飛ばして時間を節約することが可能だ）。ボタンは線で囲まれている性質上、周囲から孤立しがちなので、コマンドボタンの周辺にうまく説明テキストを添えるのはコマンドリンクの場合よりは難しい。そして、もしそれができたとしても、ユーザーはその説明テキストを見過ごしがちなのである。

そろそろ、コマンドによってはリンクとして表示すべき時がやって来たのだ。ただし、やり過ぎにはご注意を。