「情報の中身」を重視したWWW設計方針

 WWW(World Wide Web:俗にいう「ホームページ」)による情報発信が1990年代中ごろのインターネットブームで世の中に定着したことは、改めて論ずるまでも無いことであろう。 しかし、その過程で、WWWとは「美術的な美しさを求めるもの」「最新情報を広めるもの」という誤った固定観念が一般化してしまったように思える。

 WWWの本質は、多種多様な情報源からの情報を縦横無尽に使いこなすための、データベースシステムであると言うべきであろう。 その情報とは、最新情報には限らない。 もちろん、最新情報を迅速に提供できることはWWWの大きな特長であるが、あくまでそういう情報を「提供できる」のであって、そういう情報「しか提供してはならない」わけではない。

 筆者は、琵琶湖博物館の学芸員という立場で、そのインターネット情報発信の業務にずっと関わってきた。 博物館という組織は、学術情報の集散センターだとも言える。 他の研究機関と違って、学術資料の収集そのものが本来業務の1つである。 また、伝統的に「普及活動」と呼ばれている、一般を対象とする情報発信を常に意識している。 従って、WWWに期待することも「情報の“中身”を如何に効果的に発信するか」ということであり、その情報も、それがそのまま図鑑として成立するような寿命の長い情報が多い。

 これは別に博物館情報に限った話ではない。 何か「調べごと」が生じた場合に「WWWを検索してみる」というのは、インターネットブーム以降であれば、ごく常識的な行動であろう。 その際に求められているのは「情報の中身」であって、決して「美術的な美しさ」ではない。 そして、最新情報だけに限らない、寿命の長い情報や歴史的な情報が検索対象として「普通」であることは、言うまでも無いであろう。

 この文章では、「情報の中身」を重視してWWWページを整備する場合に留意せねばならないことについて論ずる。 その論は、あくまで筆者の個人的な見解であり、琵琶湖博物館の公式見解ではない。 しかし、琵琶湖博物館の実際の情報整備が、この論に近いところで進められていることは指摘しておきたい。

歴史的起源からみたWWWの機能

 歴史的には、WWWは学術論文を早く広く公表する目的で開発されたものである。 あくまで文章が本旨であり、画像貼付や作表などのレイアウトは文章の主張内容に説得力を加えるための補助手段に過ぎない。 このことは、WWWの記述言語であるHTMLの仕様からも解る。 HTMLは、文章を各端末の環境に合わせて、その論理構造が狂わないようにレイアウトするように設計されている。 端末の環境、例えば画面サイズが違えば、異なるレイアウトになるのは当然という発想なのである。 それどころか、文字のサイズやフォントなども、端末環境に合わせて読み手側が最適なものを選択するのが本筋であり、送り手側がフォントを指定するなど、全くの邪道である。

 とはいえ、普及して世の中の標準になったものは、その本来の趣旨を逸脱した無茶な用途を余儀なくされるというのが、コンピュータソフトウェアの常である。 かつてのパソコンBasicがそうであったし、最近ではスプレッドシート(表計算ソフト)であるハズのExcelの無茶な機能拡張が典型的であろう。 WWWもその例に漏れない。

 しかしながら、その本来の趣旨から逸脱した「美術的レイアウト」がWWWの本旨であるかのように誤解されている現状はどうかと思う。 「WWWを検索してみる」という、「ごく普通の」「WWWを使いこなす」行動パターンは、やはりWWWの歴史的起源に沿った行動なのである。 そこでの本質は「情報の中身」である。 「美術的レイアウト」は、利用者を情報の中身へ誘導するための呼び水に過ぎない。

トップページの在り方

 トップページで動画などを使って「見て面白い」プレゼンテーションを展開している例をよく見掛ける。 担当者が軽快なトップページを作ろうとしたのに、上司である管理職が凝ったページにするよう強制するという事例も耳にする。 どうも世の中、「WWWのトップページ」と「書籍の表紙」との本質的な違いが解っていない人が多過ぎるようである。

 書籍の表紙は、書籍そのものを選択する際の手がかりになるものである。 そして、表紙を一瞥した際の全体的な印象が、手がかりとして重要である。 このような特徴は、WWWのトップページには当てはまらない。

 WWWの利用者はトップページの表示結果を見較べてWWWサイトを選択するわけではない。 検索エンジンやリンク集などの二次情報を手がかりにするのである。 トップページを見るときには、利用者は既に第一段階の選択を終えており、そのサイトでどんな情報が得られるのかという詳細を知ろうとしている。 その段階で「誘い」をかけても無駄であるばかりでなく、有害である。 利用者は、目次が早く見たいのである。余計なものを強制的に見せたのでは、イラついた利用者は、そのサイトを見捨てて去ってしまう。

 トップページは、軽快に手早く表示できて、かつ当該サイトの全貌が迅速に理解できるものであるべきである。 美術的デザインは、この「全貌の迅速な理解」を容易にかつ楽しく行うために設計されるべきである。 これらの条件を的確に充足するのは、なかなか困難なのであるが、少なくとも「凝ったプレゼンテーション」が、この条件から最も遠いところに存在することは間違いが無い。

WWWの利用者は表紙からは入ってこない

 利用者がトップページから順に辿って入ってくるなどとは考えてはならない。 琵琶湖博物館が業務として行っているアクセス解析の結果を見ても、表紙ページに最初にアクセスする利用者は全体の4分の1以下であり、全体の3分の2は表紙ページを見もせずに去ってしまう。 大多数の利用者はgoogleやgooなどの検索エンジンで情報を探しあてて入ってくるのである。

 世の中には、技術的手段によって下位ページへ直接入ってきた利用者を強制的にトップページへ移動させるサイトもあるようだが、これはサイトの価値を落としめる行為でしかない。 役に立つ情報を折角捜し当てたのに、それを見せずに隠して、何処にあるのか判らなくしたのでは、結局そのサイト自体が役立たずになってしまう。

 むしろ重要なことは、下位ページへ直接入ってきた利用者に対して、自らの操作でトップページへ向かわせるよう、適切に誘導することであろう。 偶々捜し当てたページを見た利用者が、トップページに誘い込まれて、「こんな面白いサイトがあったのか」と思ってくれれば儲けものである。

フレームを使う上で注意するべきこと

 多種多様な内容を提供するサイトで、フレーム機能を使ったナビゲーションを提供するのは有益である。 しかし、全ての利用者が情報ページを必ずフレーム内に展開して表示すると仮定して設計するのは、誤った行動であると言うべきだろう。 多くの利用者が、検索エンジンで情報ページを捜し当てて直接入ってくるし、その情報ページ自体をブックマーク登録したりリンク登録したり、URLを記録して文章の中で参照したりしようとするし、情報を見較べるためにを別ウィンドウに独立展開したりもする。 そういう場合に不自然な動作を引き起こしたり、使いにくくなったりするような記述は、禁じ手と考えるべきである。

禁じ手1:「戻る」の無い情報ページ

 ナビゲーションフレームなどを除く「情報ページ」には、上位ページに戻るリンクアンカー(いわゆる「戻るボタン」)を必ず設置するべきであり、ナビゲーションフレームによる操作に頼ってはならない。 検索エンジンやブックマーク登録ないしリンク登録に従って、あるいはURLを直接入力してページに到達した場合、あるいは端末側操作で別ウィンドウに展開した場合、その情報ページを操作するナビゲーションフレームは存在しない。

禁じ手2:自分自身を指すtarget指定

 ナビゲーションフレームに記述されるリンクアンカーには、当然ながらtarget指定がある。 ところが、情報ページの記述の中で、自分自身を消して置換える形で展開するべきページを指定するリンクアンカーにまでtarget指定している例を見掛ける。 この場合のtargetには、トップページから素直に辿って表示した場合に当該ページが展開されているべきフレームの名前が指定されていることになる。 検索エンジンやブックマーク登録ないしリンク登録に従ったりURLを直接入力したりしてページに到達した場合、あるいは、端末側操作によって別ウィンドウを開いて表示させた場合、この名前のフレームは自分自身では無い。

 従って、そういうリンクアンカーをクリックした場合、該当する名前のフレームが存在しない場合には、意に反して新しいウィンドウが作られてしまう。 当該フレームが既存である場合にはもっと悲惨で、全く予想外のフレームが変化を受けてしまう。 最悪、そのフレームが背後に隠れたウィンドウにあったりしたら、一見すると何の変化も起っていないように見えて、「おかしいな、おかしいな」ということになりかねない。

 結局、自分自身を変化させるリンクアンカーにtarget指定をしてはならない。 原理的には「target="_self"」という指定も可能であるが、何も指定しない方が「ブラウザを選ばない」という利点がある。 target指定まわりにバグがあるブラウザは決して少なくないのである。

禁じ手3:中途半端なNOFRAMES記述

 フレームを定義するHTMLソースには、NOFRAMES記述を行うことが推奨されている。 ところが、その記述内容が「フレーム機能のあるブラウザでご覧下さい」という、フレーム非対応ブラウザを排除するメッセージになっている例が多いようである。

 フレームを単にナビゲーションに使っているのであれば、個々の情報ページの閲覧にフレーム機能は必須ではない。 このような場合、NOFRAMES記述の内容は、是非ともサイトマップへの誘導とするべきである。 サイトマップを利用して直接個々の情報ページへ飛ぶという利用法であれば、フレーム機能は不必要だからである。

無節操なURL変更をしないこと

 WWWが「最新の情報を提供するもの」と考える誤解が最も典型的に現れているのは、無節操なURL変更が世の中で後を絶たないという事象であろう。

 「速報性」はWWWの数多い側面の中の1つに過ぎないことを改めて確認しておきたい。 速報性以上に記録性と検索性も重要な側面である。 例えば、イベント情報等の発信は、もちろん速報性という側面を大いに期待して行っているものである。 しかし、それは速報的価値が失われた過去の情報が無価値になるということを意味しない。 むしろそれは「活動記録」として貴重な存在であり、情報発信活動の一環として欠かしてはならないものである。

 そして、WWWの特性として「リンクされて“なんぼ”」であることを意識しよう。 そのためには、リンクしてもらえるような内容を備えることも重要であるが、それ以上に、折角設定してもらったリンクを自ら壊す(つまり、「リンク切れ」を自ら引き起こす)のは 最高の愚行であるということを意識しておく必要がある。

 以上のことから、以下の行動原理が導き出される。

(1)一度掲載した情報は、消去しない。
(2)一度掲載した情報の掲載位置は、変更しない。
もちろん、これは教条的に守るべき絶対原理ではない。 例えば行動原理(1)を否定するような、情報を消去するべき「積極的な理由」が何か発生するかもしれない。 また、2次情報を何が何でも残す必要は無いだろう。 情報内容も「過去」であることが解るよう、誤解が起こらないように適宜修正する必要があるだろう。

 一方の行動原理(2)は、実は行動原理(1)よりも遥かに重要である。 しかし、別稿でも論じたように、世間ではこの重要性があまり理解されておらず、非常に安易に情報の掲載位置が変更されている。 掲載位置の変更というのが、如何に情報発信者の利益を深刻に損ねることなのかが、これらのサイトの管理者には全く理解されていないのである。

 例えば、googleのような検索ロボットは、掲載位置を変更しても、そのうち新しい位置を見つけてくれる。 しかし、それには概ね1ヶ月を要する。 ましてや、一般の静的なリンク集や個人のブックマーク集が 変更に対応してくれるのは少数である。 これらがきちんと変更されなければ、本来なら利用されたであろう情報が利用されなくなってしまう。 利用されない情報には価値が無い。

 つまり、位置変更はサイトの価値を約1ヶ月間は大幅に低下させ、その後もその低下が完全に回復することは無い。 それだけの深刻なリスクを伴うことを知っておくべきである。

ブラウザの種類を選ばない記述

 「情報の中身」を重視する以上は、多種多様なユーザに遍く利用できることが必要である。 即ち、ブラウザの種類や画面サイズを限定したり、回線が遅いと実用的に使えないような作り方は、可能な限り避けるべきである。 唯一の例外は、発信に不可欠な情報内容を実現するために、どうしても大画像や特殊機能などが必要な場合である。 例えば、琵琶湖博物館の情報発信では、写真関連のプレゼンテーションや気象情報提供などで、そのような例外的な状況が発生している。

 「ブラウザの種類を限定しない」という原則を貫徹するための目安として、筆者としては「古いブラウザで動く」という判断基準を推奨したい。 最近になって追加された仕様を安易に使わないのが安全である。

 そして、ブラウザの種類や画面サイズを選ばないようにする原則が半自動的に満たされる状況を確保するために、 「HTMLソースが見える」環境で編集することを強く推奨する。 「HTMLソースが見えない」状況で編集する所謂「ホームページ作成ソフト」は、確かに手軽ではあるが、ブラウザの種類や画面サイズなどの環境が変わったときに何がどうなるか想像しにくいという原理的な欠陥がある。

 また、この手のソフトウェアは、有害無益な書式指定情報を大量に付加することが少なくない。 特にワードプロセッサ(特にMicrosoft Word)を「ホームページ作成ソフト」の代わりに用いて、「HTMLファイルを出力」する機能でソースを作成することは、絶対忌避するべきである。 基本的に、ワードプロセッサというのは、印刷サイズなどの環境条件を特定して、その条件の下で文章のレイアウトを最適化する道具である。 従って、様々な環境の各々に合わせて相手に最適化させるというHTMLの本来の機能には原理的に馴染まないのである。

 それでも、その限界を心得た無理の無いHTMLソースを出力するのであれば、まだ許容できる余地があるであろう。 Microsoft Wordも、HTML出力ができるようになった当初はそうだったのだが、その後、「特定された環境条件におけるレイアウト」の結果をHTMLソースで忠実に再現しようという、無謀な野心を抱くようになってしまった。 当然ながら、そのソースはHTMLとしては不自然な書式指定が満載になる。 (一般的には、有害無益な書式指定情報が、全体の7〜8割を占める。 マトモなHTMLソースを見慣れた人が、Microsoft Wordの出力を初めて見たら、卒倒するかもしれない^_^;) それでいて、ブラウザやOSの種類、画面サイズなどの表示環境条件がMicrosoft Wordが仮定した環境条件と親和性の高いものでなければ、結局のところレイアウトを適切に再現することができないという結果になる。

画面幅を限定しないこと

 冒頭でも歴史的起源に関連して述べたように、文章を「各端末の環境に合わせて」レイアウトするのが、HTMLの基本的な設計思想である。 従って、文章が段落内のどこで改行するかということも、 画面サイズとフォントサイズに合わせて各々の端末が決定するのであり、端末環境によって改行位置が変化するのが当然なのである。 表示ウィンドウの大きさを変えれば、改行位置はそれに連動して変化しなければならない。

 ところが、世の中には、TABLE環境のWIDTH指定などを悪用して、表示ウィンドウの大きさに合わせた改行位置調整をさせないように細工してあるページが少なくない。 ウィンドウ幅を小さくすると内容が右へハミ出してしまい、1行ごとに横スクロールしなければ読めないのである。

 画面上では単に「読みにくくって仕方が無い」程度の問題だが、印刷すると悲惨なことが起こる。 端末の環境にもよるが、多くの場合、右へハミ出した内容は何処にも印刷されない。 印刷したつもりの内容の一部が、失われてしまうのである。 最近では、ブラウザの方が諦めて、印刷に際してハミ出しが起こらないように自動的に縮小するのを標準動作とするようになってしまった。 已むを得ない選択だとも言えるが、本末転倒である。

 画面幅を固定しようとする動機として、そうすることによってレイアウトを細かく制御したいということがあるらしい。 しかし、そんなことをしても無駄である。 画面幅が同じでも、ブラウザの機種や設定が変われば、レイアウトは変わる。 中には、このことを理由として「閲覧ブラウザを限定」しようとする場合があるようだが、言語道断である。 ブラウザを限定しなければならないようなレイアウトを設計する方が悪い。

 画面表示よりも印刷出力を主たる目的とするページであれば、印刷サイズを限定し、それに応じてレイアウトする必要があるかもしれない。 しかし、この場合に使うべき手段はPDFである。 HTMLではない。

 所謂「ホームページ作成ソフト」の中に、画面幅を固定する記述を標準で出力するものがあるという噂を聞いた。 全く論外のソフトウェアである。

TABLEの画面幅も限定するべきではない

 地の文章に対して画面幅固定などという無節操なことをしない人の中にも、TABLE環境はオブジェクト幅を絶対値で指定するという人が居る。 そうしたくなる気持ちは解らなくも無い。 例えば、次のような表を考えてみよう。
項目名 短い説明文が入るとして…… ズラズラと長い文章が表の内容として入ってくる場合には、当然これが2行にも3行にも渡るようなレイアウトにならざるを得ない。
次項目 となると…… 何も考えずに書くと、左端の項目名が短い単位で改行されて、格好の悪いレイアウト結果になってしまうことがある。
特に こんなふうに…… 中途半端な長さの項目が入ってたりすると、そちらは1行に収まって左端の項目名が改行されてしまうなんていう不恰好なレイアウトになってしまうことも多い。
そこで、左端の「項目名」「次項目」「特に」の部分の表示幅を絶対値で指定することによって、途中で改行しないようにしようという動機である。

 しかし、上表の左端欄には表示幅指定をしていないが、おそらくどのブラウザでどんなウィンドウ幅にしても、改行されないと思う。 別に難しい細工ではない。 「NOWRAP」という指示を記述しただけである。 こういう便利な仕掛けがちゃんと用意されているのだ。 適切な手段を使うようにしよう。

本当にJavaScriptが必要か?

 JavaScriptはいろんなことができて便利である。 しかし、あまりにも安易に使われてはいないだろうか?

 「データベース検索」的な内容のプレゼンテーションでよく見掛けるのが、一覧表から選んだ情報ページを、 JavaScriptでポップアップウィンドウを出して示すというものである。 しかし、このポップアップウィンドウを、URL指定領域や各種機能のメニューが表示されない設定で出す例が多いように思える。

 確かに、美術的センスから言えば、ポップアップウィンドウの周囲に余計なものがチャラチャラついていない方が美しいかもしれない。 ブラウザの仕様として、何も指定しなかった場合の省略時標準値が「出さない」になっているということも、1つの理由かもしれない。 しかし、情報を使う立場からこれを考えてみよう。 URL領域が無いからURLを記録することもできないし、メニューが無いから、ブックマーク登録はもちろん、印刷さえできない。 ページのプロパティ(属性情報)を出すか、あるいは呼出し元のソースを読んで、改めて当該ページを普通のウィンドウに表示し直さなければ何もできない。 これ以上は無いという不便な代物だと言わざるを得ない。

 また、JavaScriptでしかリンクしていないページは、検索エンジンに無視されることも多いようである。 キーワード検索で引っ掛けるに適した内容を有する情報ページは、是非とも通常の方法でリンクしておくべきである。

 単にリンク先ページを別ウィンドウにポップアップすることだけが目的であれば、JavaScriptを使う必要は無い。 「target="_blank"」を指定して普通にリンクすれば良いのである。 ただ、別ウィンドウの位置や大きさを制御することができないだけである。 位置や大きさを制御するためにJavaScriptを使うとしても、URL指定領域や各種機能のメニューが表示されるように面倒でも逐一指定するべきである。

 JavaScriptはセキュリティホールになる例もあるし、ブラウザの種類やバージョンに依存する異常動作の原因にもなりやすい。 古いブラウザで新しい書式のJavaScriptを実行すると、ブラウザ自体が異常終了してしまうという例も多いのである。 JavaScriptは安易に使うべきものではない。


2003年10月24日WWW公開用初稿/2014年1月23日最終改訂・ホスト移転

戸田孝の雑学資料室へ戻る

Copyright © 2003,2004 by TODA, Takashi