レベル: 初級 David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
2007年 9月 11日 どのような CMS (Content Management System) や Web アプリケーション・フレームワークを使って Web サイトを開発する場合にも、必ず守らなければならない基本があります。高度なユーザー・インターフェースやリッチなコンテンツを持つことは素晴らしいことですが、そこに至る前に、当然見つかるものとユーザーが期待する、またそのサイトが何をするのかを人間に対しても機械に対しても伝える、基本ファイルを提供する必要があります。
はじめに
すべての Web サイトが本当に持つ必要がありながら、大部分のサイトが無視している標準ファイルがいくつかあります。これらのファイルの大部分は習慣的に用意されているもので、技術的な要件によるものではありませんが、そうしたファイルを提供しないサイトは不適切です。大胆な推測をして見つけたい情報を探すユーザーが URL を推測すれば、通常はこれらの標準ファイルを見つけることができるように工夫しましょう。このヒントでは、そうした標準ファイルのそれぞれを簡単に説明します。
あるリソースがどのように提供されるかは、使用される Web サーバーと、Web アプリケーションのレイヤーに依存します。Apache のように、ほとんど静的な「従来型の」サーバーの場合には、これらのリソースはサーバー上のリテラル・ファイルであることが多いものです。しかし、そうしたものとは異なる構成の場合には、そうしたリソースは、実際にはデータベースのエントリーや構成ファイルの何行か、そしてサーバー・プロセスのクラスなどかもしれません。このヒントでは、最終的にユーザーが見るものに焦点を当て、それを実現するために何をする必要があるかについては触れないことにします。
404.html
ユーザーが Web サイトを使用する際に、存在しないリソースをユーザーが探してしまうことはよくあるものです。これが起こる原因は何といっても URL の入力間違いが最も多いと思いますが、リンクの誤りやバックエンドの構成間違い、さまざまなポイントでの URL の混乱などが原因になることもあります。リソースがない場合には、何か有用なものにユーザーをナビゲートできる、何らかの代替ページを用意することが適切です。汎用の「not found」は、リソースがないことをユーザーに知らせるには十分ですが、「次に何をすべきか」をユーザーが考え付くためには何の役にも立ちません。
カスタムの 404.html (あるいはカスタムの「not found」メッセージを提供するために Web サーバーが使用する任意の仕組み) を作成する際の注意: 誤った構成で「あいまいな404」メッセージを提供している Web サイトが多すぎます。つまりそうしたページは、テキストのどこかで「利用できません」と言っているだけの、通常の「200 OK」ヘッダーを持つページを提供しているにすぎません (テキストのどこかで「404 Error」に触れているかもしれませんが、必ず触れているわけでもありません)。こんなことをしてはいけません。ユーザーや、そしてユーザーの Web ブラウザーや他のツールに対して、そんなものを提供するよりも一息入れてもらい、正確なステータス・ヘッダーを使用するようにしてください。
about.html
ところで、皆さんはなぜその Web サイトを作成したのでしょう。その質問に対して、フロント・ページが答えてくれるかもしれません。しかし大部分の場合はそんなことがなく、フロント・ページではユーザーにログインさせたり、そのサイトを売り込んだり、目立つものを表示したり、といったことをしています。ホーム・ページから「about」ページまでユーザーをナビゲートする方法があるはずです。ぜひその方法を使って、まさに http://mysite.example.com/about.html でそのサイトの目的に関する情報を得られるようにします。その情報を探す人は、そこを探すはずです。
適切な about.html ページは、そのサイトで行っていることに関する簡単な概要を提供しているものです。場合によっては、なぜそのサイトが作られたのか、なぜそのサイトがユーザーにとって重要なのか、そしてそのサイトの中核となる機能までナビゲートして戻るためのいくつかのリンクも提供しています。このページはあまり凝った作りにする必要はなく、また通常はそうすべきではありません。ユーザーが、そのサイトが提供するすべての素晴らしいものを利用しようという気になるように、事実のみを簡潔に記述すれば十分です。
contact.html
では、あなたは誰なのでしょう。about.html の場合と同じように、ユーザーがこの情報にたどり着くためには、既存のホーム・ページから別のページへと次々に何度もクリックを繰り返す必要があるかもしれません。ユーザーがこの情報を得るのに苦労をさせてはいけません。その情報は http://mysite.example.com/contact.html に置けばよいのです。また、同じページに対して contacts.html も使うようにします。さらに .htm 拡張子も使うようにします。名前に大きなコストがかかることはありません。もちろん、素晴らしいナビゲーション画面を何度かクリックした後でないと到達できない場所にこの情報を置くこともできます。リソースを見つけるために少し手間がかかるのは悪いことではありません。
copyright.html
そのサイトのコンテンツは誰に帰属するのでしょうか。おそらく、そのコンテンツはあなたに帰属するのでしょう。では再度、あなたは誰なのでしょう。個人なのでしょうか。会社でしょうか。一連の協力者でしょうか。政府組織でしょうか。そのコンテンツが公共のものであるか、あるいは何らかの無料のコンテンツ・ライセンスの下で提供されている場合には、それをユーザーに知らせることが一層重要です。最近では、作成されるすべてのものに個人的な著作権が伴います。もし皆さんのコンテンツが別のルールに従う場合には、それをユーザーに知らせる必要があります。この情報を提供する手間をかけている Web サイトは多くありませんが、皆さんのサイトにこの情報を加えてはどうでしょう。その情報を探している人もいるはずです。
当然のことですが、ページやリソースによって著作権情報は異なります。そうした著作権情報それぞれの違いを判断する方法について (それが重要であれば)、この一般的なページを使って何らかの情報をユーザーに提供しましょう。もし商標に関する問題があれば、それにも触れるようにします。
index.html (と index.htm)
すべての Web サーバーが、そのホーム・ページを実際の index.html ファイルを使って記述しているわけではありません。設定によっては、URL のリライトやパス名の動的生成などがあるかもしれません。しかしユーザーには、そんなことは無関係です。たとえ単純な HTML リダイレクトを使わざるを得ないとしても、単純に http://mysite.example.com/index.html がホーム・ページを指すようにします。
そしてついでに、古い、Windows の欠陥 .htm 拡張子でも同じように動作するようにしたほうが良いでしょう。また、もし皆さんが特別に心の広い人なら、index.cgi でも同じ場所にたどり着けるようにしましょう。
index.rss
Web コンテンツの多くは RSS を使って入手することができます。すべての Web サイトを RSS で利用可能にしてもあまり意味がありませんが、多くの Web サイトにとっては意味があります。RSS コンテンツが、そのユーザー固有の構成オプションやログイン方法、あるいは特定の情報に対する支払いに依存することは、極めて妥当なことです。しかし RSS が必ずしも万能というわけではありません。
それでもなお、RSS として一般的に提供できるものが何かある場合には、それを RSS として提供することです。index.rss として提供できるものが、RSS フィードを十分に活用する方法についての繰り返しの説明とティーザー・コンテンツのみという場合もあるかもしれません。あるいは、その Web サイトにとって RSS がなぜ重要ではないか理由を説明するのみであったとしても構わないのです。
privacy.html
ユーザーから情報を収集しようとする場合には、それがどのような情報であっても (たとえユーザー名またはトラフィックのログのみでも)、その情報を使って何をしようとしているのかをユーザーに知らせてください。Web サイトの作成者やユーザーの、権利と義務に関する法的な問題は複雑です。しかも私は弁護士ではなく、ましてや皆さんの弁護士でもありません。しかし、皆さんがユーザーのプライバシーを考慮していることを知れば、ユーザーは好感を持つはずです。そして、ユーザー・データを使って行おうとしている、まさにその内容について皆さんの弁護士と相談するタイミングは、この時が適切なのかもしれません。
robots.txt
Web サイトにあるすべてのリソースを自動ツールで索引付けして欲しくない場合には、それを robots.txt の中で説明する必要があります。また、すべてを索引付けして欲しい場合にも、やはりそのことを説明する必要があります。Robots Exclusion Standard のディレクティブは、ユーザーに対して強制的なものではありません。何かが見えてしまうことを本当に避けたい場合には、それをそもそも Web サイトに置かないことにするか、あるいはそれを必ず、適切なアクセス権による保護の下に置くことです。しかし主要な、そして合法的な Web クローリング・エンジンは、すべて robots.txt に書かれた要求に従います。皆さんの意図を明確にする必要があります。
security.html
security.html リソースの使い方は統一されていません。しかし、そのサイトにセキュリティーの懸念がある場合 (例えば、ユーザーから何らかの機密情報を収集する場合) には、セキュリティーに関する手続きを (少なくとも大まかな概要として) 文書化しておくことが適切です。ユーザーが質問したい場合、あるいはユーザーが有用な改善を提言したい場合に備えて、このページに何らかの連絡先情報を載せておきます。この情報の見つけ方は、そのサイトのナビゲーション・オプション全体の構成に従う必要があります。ついでに、その情報もこの URL に置いておくとよいでしょう。
サイトマップ
Web サイト全体のマップをどのように表示するかは、正確にはきちんと標準化されていません。これに関する何らかの方針を提供しておくと必ず役に立ちますが、正確にどのような詳細レベルでマップが得られるかは、そのサイトがどの程度 (そしてどのような方法で) 動的に作られているかに依存します。さらに、ユーザーに対して何を表示するかは、そのサイトの目的に依存します。例えば、リソース X を使う許可を得ているのがユーザー全員ではない場合には、リソース X が存在すること自体をユーザー全員が知ることは適切ではないかもしれません。適切な判断が必要ですが、何らかのサイトマップを提供することを考えてください。
多くのサイトでは、サイトマップは単純に検索エンジンなどのロボットにとって扱いやすくするための手段にすぎません。Google は robots.txt の規則と抱き合わせる規則を公開しています。簡単に言えば、そのサイトで提供されるすべてのリソースを記述した XML ファイルを作成するのです。このファイルは robots.txt の「排除リスト」を補完する「包含リスト」の役割を果たします。
E メール・アドレス
すべてのことが Web 上で起こるわけではありません。実際、Web サイトのナビゲーション・ツールが期待どおりの役割を果たせなかった場合に備えて (あるいはユーザーが皆さんの優れた設計を認識できない場合に備えて)、ユーザーが E メールでも連絡できるようにしておくことが適切です。
ぜひ、contact.html や Web サイトの他の場所でも、連絡先情報を目立つ場所に公開してください。しかし念のため、いくつかの一般的な E メール・アドレスに送信されたメールが、適切な人に送信されるようにします。そういった一般的な E メール・アドレスには、少なくとも postmaster@mysite.example.com と webmaster@mysite.example.com、そして security@mysite.example.com を含める必要があります。本当に古くから携わっている人であれば、どこか意味のある場所に root@mysite.example.com も置きたくなるかもしれません (しかしセキュリティー上の理由から、おそらく「ルート」には置かない方がよいでしょう)。ついでに、それ以外の、そのサイトの目的から明白と思える、たくさんの説明文にも E メール・アドレスを追加して転送されるようにしておきます。E メール・アドレスは、Web サーバーのディレクトリーのシンボリック・リンクと同じくらいコストがかかりません。
参考文献
著者について  | 
| | David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。 |
記事の評価
| 
