フレームが（おおむね）ダメな理由
私の手元に寄せられた電子メールから判断して、これまでにもっとも物議をかもしたAlertboxコラムは、「フレームの使用」を間違いのひとつに数えたウェブデザインの間違いトップ10だろう。
この世界に入って日の浅いウェブデザイナー相手なら、私はこれまで通り主張を変える気はない。フレームはノーだ。
高度なスキルを備えたウェブデザイナーがフレームを利用する分には、私も少し意見を変えた。自分のやっていることが本当にわかっている人間なら、フレームを使っていい効果を出せることもある。だが、ベテランのデザイナーであっても、フレームはできるだけ避けるようお薦めしたい。
フレームの基本的な問題
ウェブの設計にあたって発揮されたTim Berners-Leeの天才の一端は、いくつかのコンセプトをひとつのアイデアに統合した点に見られる。それはページである。
- ユーザから見た画面上の情報の表示形態
- ナビゲーションの単位（リンクをクリックしたり、ブックマークなどのナビゲーション行動をとった時に得られるもの）
- ネット経由で情報を入手する際に用いられる文字アドレス（URL）
- サーバ上での情報の保管、および作者の編集にあたってのユニット（画像ファイルなどの埋め込みオブジェクトを利用した場合を除く。この場合、著者は、ひとつのページのために複数のファイルを管理しなくてはならない）
ウェブの基本デザインは、ページを原子ユニットとして築かれており、この概念がウェブの隅々まで浸透している。ウェブ本来のシンプルさが、その使いやすさと急速な普及につながっているのだ。
フレームは、このウェブの統一モデルを打ち破る新しいデータの見方を導入するものだが、これがウェブのその他の側面とうまく統合されていない。
ナビゲーションはフレームとなじまない。ナビゲーションの単位が、表示ユニットと違っているからである。ユーザがブラウザでブックマークして後でそのブックマークを使っても、同じ表示には戻れない。ブックマークでは、フレーム内のページの状態までは保存できないからだ。
なお悪いことに、URLが機能しなくなる。ブラウザ上部に表示されたアドレス情報では、ウィンドウ内に表示された情報を完全には特定できなくなるのだ。自分のページ内に、ハイパーテキストアンカーとして取り入れるつもりでURLをコピーしても、このアンカーからは希望する表示画面には行けず、フレーム設定の初期状態にしか行けない。同様に、ユーザがお薦めのページを電子メールで友人に送ろうとしてURLをブラウザからコピーしても、フレームが使われているとうまくいかない。URLは、（友人に教えたい情報が載っている）現在の画面表示ではなく、フレーム設定時の状態を指し示しているからである。インターネットでは、社会的なフィルタリングがもっとも有力な情報発見の仕組みになっていることを考えると、アドレス情報としてURLが機能しなくなるということは、まったく災厄と言うほかはない。
フレーム実装時の問題
上で論じた基本的な問題に加えて、現在のフレームの実装に関して、いくつかマイナーな問題もある。これらの問題は数年のうちに解消されるだろう。だが、1997年（ことによると1998年まで）のデザインでは、フレームは最小限に押さえるべきだというのは、こういった理由があるのだ。
フレーム未対応ブラウザのユーザ
Interseが1996年11月に発表した統計によれば、ブラウザ利用状況の分布は以下のようになっている。
- Netscape 2: ユーザの13％
- Netscape 3: ユーザの47％
- Internet Explorer 3: ユーザの28％
- その他のブラウザ、あるいは上記以前のバージョン: ユーザの13％
パーセンテージの合計が101％になるのは、丸め誤差である。これによると、フレーム利用のサイトを見ることさえできないユーザが13％もいる。もちろん、原理的には、<NOFRAMES>機能を使えば、こういったユーザに代替コンテンツを提供できる。だが、ほとんどのデザイナーはわざわざ同じページを2バージョンも作ったりしないし、<NOFRAMES>を使うとしても、フレーム対応ブラウザのダウンロードサイトへの「便利な」リンクを置いておくくらいの使い方しかしないだろう。
Netscape 2を利用しているユーザが、まだ13％もいる。これは、ウェブ上では、これまでで最悪のユーザビリティ問題を抱えたバージョンだ。ブラウザのBACKボタンを押しても、フレームサイトでは効き目がないのだ。BACK機能は絶対不可欠な安全装置であり、このおかげで、ユーザは不安を感じることなく自由にナビゲートできる。いつ何時でも、おなじみの場所に戻れることがわかっているからだ。以前に行ったいくつかのユーザのナビゲーション行動についての調査から、BACK機能は、ウェブブラウザのナビゲーション機能としては2番目に（1番は「リンクをクリックして移動する」というシンプルな行動）よく使われるものだということがわかっている。よって、BACKボタンを機能不全にするということは、とりもなおさずユーザビリティの致命傷になる。
これら2つの統計を組み合わせると、こういう結論に達する。1/4以上のユーザがフレームを見ることさえできないか、できるとしてもかなり深刻なユーザビリティ問題に悩まされることになる。こういったユーザも、ほとんどが来年中にアップグレードするだろうが、それでも1997年末の時点で約10％が取り残される。忘れないでいただきたい。ウェブ閲覧を中心にして人生が回っていると言う人は、まだほとんどいない。それゆえ、ツールの変遷に一生懸命ついていこうとする人もまれにしかいないのだ。
よって、フレームでデザインが向上するとしても、その恩恵にあずかれるのはユーザの3/4にしかならない。となると、フレームの使用は、余分の労力と、フレーム未対応の1/4のユーザを怒らせてしまうリスクを支払う価値が本当にある場合に限定すべきである。
印刷の問題
フレーム分割されたページをきれいに印刷できるブラウザが、ほとんどない。もちろん、ほとんどのブラウザは、どんなページだってまともに印刷できないのだが、少なくとも、通常のページを普通に全面印刷はできる。全面印刷は、スクロール可能なフレームがあると難しくなる。フレームの見えている部分だけを印刷すべきだろうか、それとも、コンテンツを拡大して、画面よりもずっと広いエリアをとるべきだろうか？
制作上の問題
HTML本来の姿はかなりシンプルなもので、ほとんどの人が大した苦もなく学べる程度のものである。だが、フレームとなると話は違ってくる。comp.infosystems.www.authoring.htmlといったニュースグループは、フレームが思い通りに動作しないという悩みを抱えたウェブ制作者からの質問であふれている。フレームは、現状では学習が難しく、制作者の多くがバグだらけのコードを書く羽目になっている。
検索の問題
検索エンジンもフレームで問題を起こす。フレームの構成要素のうち、どれをナビゲーションユニットとしてインデックスすればいいかわからないからである。
ユーザの嗜好
通常バージョンと「フレームあり」バージョンを選択できるようにしているウェブサイトでは、ほとんどのユーザがフレームなしのデザインを選んでいる場合が多い。
フレームを使ってもいい場合
フレームを利用する上での一番の注意点は、URLがきちん動作することを確認することである。このためには、あらゆるハイパーテキストのアンカータグにTARGET="_top"属性をつけること（すなわち<A HREF=foo.html TARGET="_top">となる）。_topをつけておけば、ブラウザはすべてのフレームをクリアし、ウィンドウ全体を使って新しいフレーム設定を行う。目的のフレーム設定には元のフレーム設定と同じたくさんのフレームが入っていて、それはすでにブラウザのキャッシュに入っているかもしれないが、原則として強制的に完全な再読み込みを行うことで、ブラウザは目的地の新しいURLを表示するようになる。これによって、ナビゲーション行動（例えばブックマーク）は再び正常に動作するようになり、URLは、他の人がリンクできる形になる。
TARGET="_top"属性を使わなくていい唯一の例外は、単一ページのスクロールをショートカットするためにフレームを使っている場合だ。例えば、非常に長い住所録やその他のアルファベット順のリストの上部にフレームを設け、アルファベットの各文字を並べておくのだ。この文字をどれかクリックすると、他方のフレームに置かれたリストがスクロールするが、それでもユーザは同一ページを離れることはないし、ナビゲーションが破壊されることもない。
フレームは、別のページに対するコメントを掲載する「メタページ」にも向いている。例えば、ウェブデザインのスタイルガイドでは、デザイン原則についての議論と、そのルールに従った（あるいは違反した）全ページ大の実例が組み合わされる。こういったケースでは、埋め込まれたページは（独立したページとして制作されてはいるものの）埋め込み画像と同じ扱いにするべきだ。ユーザがブックマークしたくなる「メイン」の情報は、コメントをつけるフレームの内容にしておくべきだ。
最後に、HTML 4.0で導入されたインラインフレームであるが、これは概ね、無害であるといっていいように思われる。インラインになるフレームはメインページに従属するものであり、ユーザは問題なくメインページにブックマークし、通常どおりナビゲートできるからである。主流のブラウザはまだHTML 4.0を実装していないから、インラインフレームに固有の問題が、実装時に発生しないとも限らない。特に、スクロールするインラインフレームを含んだページの印刷に関しては、名案が生まれるかどうか疑わしい（私の予想では、メインページのレイアウトを崩さないためには、今見えているところだけを印刷するというのが一番のように思われるが、ユーザの中には全コンテンツの印刷を望む者もいるだろう。よって、かなり込み入った設定が必要になるかもしれない）。
より豊かなノードモデルに向けて
長期的には、ウェブには、フレームよりも豊かなハイパーテキストノードが必要になるだろう。例えば、合成ノードや、タイプ別ノード、ノードの階層的ネスティング、様々な表示形態を持つノード、それに他のノードに影響を与えるようなアクションをともなうノードといったものだ。これらはすべてハイパーテキスト研究の中で模索されてきたものだ。ウェブの優れた面を維持しながら、こうした豊かな情報構造に向かって前進することが重要である。
1996年12月
