Webページ以外のドキュメントは新しいウィンドウで開こう

PDFやスプレッドシートのような、本来、ブラウザ以外のPCソフト上で使うことを想定して作られているファイルフォーマットを目にしたユーザーは、PCソフトとやり取りをしていると感じるものだ。もはや、ウェブサイトをブラウジングしているわけではないのだから、ブラウザのUIが提供されるべきではない。

ユーザーは、ウェブサイトからのリンクでウェブページではないドキュメントに辿り着くと、ウェブページのブラウジングとは全く異なるユーザエクスペリエンスを余儀なくされ、いとも簡単に混乱してしまう。

ユーザーテストでは、以下のようなユーザーの行為をしばしば目にする。PDFファイル、Wordメモ、PowerPointのスライドやExcelのスプレッドシートなどに代表されるドキュメントを見終わると、ユーザーは戻るボタンをクリックする代わりに、ウィンドウの閉じるボタンをクリックしてしまうのだ。そうすれば、確かにそのドキュメントから抜けることができる。しかし、もとのウェブページへ戻ることはできない。

ブラウザのウィンドウを思わず閉じてしまうのは、イントラネットでは特に都合が悪い。ドキュメントのデータベースへアクセスするには、ログインが必要だったり、どこかを経由しなければならなかったりする場合が多いからだ。

ユーザーが、ドキュメントの表示されたウィンドウを閉じてしまうことが頻繁にあるということから、ウェブページ以外のドキュメントにリンクを張るときのガイドラインは、以下のようであることが望ましいと考えられる:

  1. ウェブページ以外のドキュメントは、新しいウィンドウで開くようにする
  2. 新しいウィンドウで開かれることを、前もってユーザーに知らせる
  3. 新しいウィンドウには、ブラウザのツールバー(戻るボタンなど)を表示しない
  4. 何より、ウェブページ以外のドキュメントをそもそもブラウザに開かせないのが良い。代わって、そのファイルをハードディスクに保存するか、あるいは、本来使用されるべきアプリケーション(PDFならAdobe Reader、スライドにはPowerPoint、といった具合)でファイルを開くか、どちらかをユーザーが選択できるようにしてあげるのだ。残念ながら、そのためには少々の技が必要になる。その厄介なファイルを送るために、追加のHTTPヘッダーを書かなければならないのだ。追加されることになるヘッダーは、“Content-disposition: Attachment” である。可能ならば、“; filename=somefile.pdf” を行の最後にさらに追加しておこう。そうすれば、ユーザーがファイルを保存することを選んだときに、ファイル名をしっかりとブラウザに知らせてやることができる。(上記コードを提供くださったSybren Stuvelに感謝します。)

これらのガイドラインはいずれも、ある一つの事実に起因する。ウェブページ以外のドキュメントは、本来、ブラウザ以外のPCソフト上で使われることを想定したフォーマットなのだ。これらのフォーマットは、それぞれ、特定のアプリケーションで使われるものであり、ウェブサイトをブラウジングするのとはまったく異なるコマンドやナビゲーションを、各種各様に提供する。

たとえば、PowerPointのスライドショーを見ているとしよう。PowerPointのスライドを操作する機能に注意が向いているはずだ。ユーザーエクスペリエンスは、自分のパソコンに保存されているスライドを見るときのそれと非常に似ている。そのため、ウェブサイトからこれらのスライドをダウンロードしたという事実に意識が向かなくなるのは容易いことだ。スライドを見終わると、いつもPowerPointを使い終えるときにするようにしてしまう。つまり、閉じるボタンをクリックするのだ。

ブラウザ以外のPCソフトがブラウザウィンドウの中で立ち上がると、次の — 同じくらい嘆かわしい — 現象が起こる。ユーザーは、ブラウザのコマンドやボタンを目にできてしまうため、ドキュメントを操作するのに、ブラウザの機能を使えるものだと考えてしまうのだ。残念ながら、“文字サイズを大きくする”、“印刷する”、“ページ内検索”などといった機能は、PCソフトが立ち上がっていて、ドキュメントが見えている間は使えない。ユーザーが慣れ親しんでいる(そして、機能することのない)ブラウザのボタンは、ウェブページ以外のドキュメントを扱っている間は見えないようにしてあげるのが良いだろう。

ユーザビリティガイドラインとの対立

1999年以来、新しいウィンドウでページを開くことを控えるようにと促すウェブユーザビリティのガイドラインが、以下にあげるような理由で言われ続けてきた。

  • ユーザーが頼みもしないのに新しいウィンドウを開くのは、混乱や困惑を招く
  • 新しく開かれたウィンドウが、リンク元のページをすっかり覆い隠してしまうと、多くのユーザーは、新しいウィンドウが開かれたことに気付きさえしない
  • 技術を伴わないユーザーは、複数のウィンドウをさばききれない
  • 新しいウィンドウは、視力のないユーザー、視覚障碍を有するユーザーを困らせることになる。たとえば、視覚障碍を持つユーザーが画面を拡大して見ているような場合、新しいウィンドウは、目にしている領域の外に表示されてしまうことがある

リンク先を新しいウィンドウで表示する論拠としてデザイナーは、そうすれば“ユーザーを自分のサイトに留まらせる”ことができる、とよく口にする。しかし、これは正しくない。他へ行きたいと思ったユーザーは、他へ行く。他のサイトも少し見てみたいという程度だったなら、きっと、戻るボタン — ウェブ上で2番目によく使われる機能(トップはハイパーテキストリンク) — をクリックして戻ってくる。実際、リンク先を新しいウィンドウで表示することで生じるユーザビリティ上の問題の一つは、前のページへ戻ろうとするときに、ユーザーが当たり前にとる戻るボタンをクリックするという行為を無効にしてしまうことにある。

ユーザーがウェブをブラウジングしているならば、リンク先を新しいウィンドウで開くべきではないとする従来の指針を、私は支持する。PDFをはじめとするドキュメントを新しいウィンドウで開くべきとする新しいガイドラインと、さて、どうやって調整をはかれば良いだろうか?

ユーザーエクスペリエンス vs. 実装

明らかに対立するこの問いへの答えは、ここでの議論の焦点が、ユーザーエクスペリエンスのガイドラインであり、実装上のテクノロジーに関する話ではないという事実にある。そう、どちらの場合も、実装という観点では似ている。インターネットを通じて、ハイパーリンクで指定されたアドレスからダウンロードされたものを、ウェブブラウザで見られるようにする点は同じだ。ところが、ユーザーエクスペリエンスは非常に異なる。従って、デザインガイドラインもまた、違うものにならなければならないのだ。

ユーザーは、ウェブサイトを見ているのと全く同じ環境でPDFファイルを見ているわけではない。ナビゲーションバーもウェブサイトの機能も使うことができず、ドキュメントを扱うときの仕組みは、ウェブサイトを扱うときのそれとは非常に異なる。この相違が、ブラウジングをしているのではなく、アプリケーションを使っているかのような錯覚にユーザーを陥らせ、終了しようとするときには閉じるボタンをクリックさせてしまうことになるのだ。

言うまでもなく、ユーザーエクスペリエンスが通常とは違うという事実こそが、ブラウジングエクスペリエンスをデザインしているときには、そもそもPDFファイルのような忌まわしいドキュメントを使うことを避けるようにする主な理由の一つである。PDFは、印刷をするときには良いが、ディスプレイ上で読むのには適していない。しかし、どうしてもPDFをはじめとするドキュメントを使わなければならないならば、少なくとも、その違いを認識し、相応に取り扱わねばなるまい。

イントラネットのデザイン vs. ウェブサイトのデザイン

新しいウィンドウでドキュメントを開くことを支持する新しいガイドラインは、イントラネットのユーザーテストを通じて強く動機付けられてきた。イントラネットでは、そういったドキュメントが使われるケースが特に多いからだ。興味深いことに、一見、対立するかのように思われるガイドラインがもう一組、イントラネットのリサーチを通じて明らかになった。検索ボックスは一つにまとめることが通常は推奨されるが、従業員向けのディレクトリサーチに関しては検索ボックスを分けた方が良いとするユーザビリティガイドラインが出来てきた。

イントラネットガイドラインの多くは、ウェブサイトガイドラインと同じである。たとえば、新しいウィンドウでドキュメントを開くことを推奨するガイドラインは、どちらの場合にも該当する。イントラネットの場合の方が特に重要との見方があるにしても。いつものように、ユーザビリティは2つの問いに立ち返ることが重要だ。ユーザーは誰で、そのユーザーは何をしようとしているのか。この2つの問いに対する答えは、ウェブサイトの場合と、イントラネットの場合で異なる。従って、ガイドラインも同様に、時には異なることがあるのだ。

2005 年 8 月 29 日