Web の世界で最も古くからあるニュースサイトのひとつ、Wired News は、毎月 2,000 万から 2,500 万ページビューを記録しています。2002 年 10 月 11 日、Wired News は、文書構造に正当 (valid) な XHTML を、レイアウトにいくつかの CSS ファイルを利用した、まったく新しいサイトデザインを立ち上げました。この新デザインは、これまで何人かの専門家が主張してきた次のようなことを、はっきりと示しています。それは、標準に基づいたデザインが視覚的に人を引き付け、また、私たちが Web ページに期待するようになったインターフェイスの慣習を維持することができる、ということです。
この魅力的な新デザインの裏で、ブレーンとなり、いちばんの立役者となった人物は、Terra Lycos のネットワークデザインマネージャである Douglas Bowman 氏です。今回彼は快くインタビューに応じてくれました。その中で、標準に基づいたリデザインの取り組みについて、多くの光を当ててくれました。
Wired News のリデザインの概要
- XHTML 1.0 Transitional と CSS によるコーディング
- 何千というページのレイアウトやデザインの集中管理が可能に
- シンプルなマークアップによって、短時間でのテンプレート変更が可能に
- ページサイズを平均で約半分に削減
- シンプルな CSS ポジショニングで実現したページレイアウト
- 特別なコーディングやユーザエージェントの判別をすることなく、アクセシビリティが大幅に向上
標準に基づいた Wired News のリデザインを推進した理由は?
私は過去 2 年間、Lycos のネットワークデザインマネージャとして、自社ネットワークのサイトに関するデザイン基準を作成、文書化してきました。これには、ヘッダ、フッタ、ページ階層、タイトル、タイポグラフィ、イコノグラフィ (図像学)、ナビゲーション、その他あらゆるものに適用する規定やガイドラインが含まれています。そのため私は、標準と、それらを利用することによって得られるメリットについて、かなり詳しくなりました。Wired News をデザインする過程で、シナリオが逆転しました。私は、製品のデザインをしているうちに、一連の幅広い Web 標準に気付き始め、すぐにそれらを取り入れたときに考えられるメリットに揺り動かされたのです。
Wired News を XHTML と CSS への全面的な移行を実現するうってつけの候補として捉えることは、私たちにとっては非常に簡単なことでした。Wired News のコンテンツは、私たちの日常生活、特にビジネスや文化、政治の世界に、テクノロジーがどのような影響を与えているのかということを物語ってくれます。このストーリーを実現するために、技術標準を Web に利用しない手はないでしょう? Wired News の視覚デザインと Vignette のテンプレートは、どれもひどく、陳腐化した状態でしたが、私たちは 2 年以上もこれらに投資する目立った努力をしてきませんでした。この現実が、まったく新しいことに挑戦する私たちのチームの意欲を強力に後押ししたと思っています。実際、標準に基づいたデザインへ移行することについて、私たちの技術チームを納得させる必要はほとんどありませんでした。なぜなら彼らも、自分たちの仕事量とサイトのメンテナンスにもたらされるメリットを容易に想像できたからです。
HTML ベースの視覚表現をすべて取り除いた結果、サイトはどのようにスタイル付けされたのですか?
技術的には、常時合わせて 13 種類のスタイルシートが使われています。その内訳は次のようになります。
- 以下の 4 種類のファイルをインポートする、スクリーンメディア用マスターファイル (1)
- ベースファイル (書式設定の大部分)
- 金融関連のテーブル形式を指定するファイル
- カラーファイル (特定の配色を上書きする色と背景画像)
- 一時ファイル (一時的な特集や広告関連のページに関するスタイルに利用)
- 印刷メディア用ファイル (1)
- 音声メディア用ファイル (1)
- それぞれ 1 種類のファイルをインポートする、マスター代替スタイルシート (3)
- 代替フォントサイズ (小・大・最大) を設定する 3 種類のインポートファイル
Wired News の標準的なページのサイズは、どの程度削減されましたか?
HTML ファイルは 32 KB から 19 KB まで圧縮できましたが、画像のサイズは 8 KB から 13 KB に増えました。私たちは、一部のファイルサイズの比較が、必ずしも公正ではないことに気付きました。なぜなら、私たちは似たもの同士を比較しているわけではなく、HTML やテーブル、スペーサー GIF をいくつも使った古いデザインと、イメージやスタイルの点でずっとリッチな新しいデザインを比較しているのですから。
レイアウト構造にテーブルを使うのをやめたきっかけは何だったのでしょうか? 多くのデザイナーは、ひとつもテーブルを使わないでレイアウトを実現するのは不可能だと考えているようですが。
これまで 4、5 年の間、私は自分自身のデザインプロトタイプのためのサンプルコードを手書きで作成してきました。あらゆるインターフェイスデザインをピクセル単位まで完全に再現する方法を見つけては、それを誇りに思っていたものです。ある開発者は私に、中には不可能なこともあると忠告してくれましたが、そのたびに別の方法で実現可能なことを証明してみせることができました。他のデザイナーや HTML 専門家のように、私はテーブル操作と問題解決の達人となり、あらゆる思い通りのレイアウトや効果を実現するために、複雑な方法でそれらを入れ子にする術を身に付けました。
Lycos のあるプロジェクトで、10 階層もの深さを持った入れ子テーブルを作ったことを覚えています。実際に自分で数えたんですよ。意図したデザイン効果を再現するのに、すべての階層が絶対に必要というわけではありませんでした。しかし、それぞれのテーブルが、コンテンツの特定のモジュールや構成要素を見せたり消したりする場合に必要な柔軟性を確保してくれました。ここまで来ると、何かひとつのものを見つけるだけでも、調べなければならないマークアップの量は桁外れになります。今回のリデザインまで、Wired News は、テーブル内のコンテンツをスタイル付けするのにさえ CSS を使っていませんでした。どのセルの中にも重複して書かれていた <font> タグは、全部合わせると、おそらくファイルサイズを倍増させてしまうほどの数だったと思います。
Wired News デザインのためのマークアップと CSS に関する最初の試みは、大部分のテーブルを削除することでしたが、最後に各ページの主要列をコントロールするマスターテーブルがひとつだけ残ってしまいました。この方法では、すべての列のコンテンツを、ブラウザウィンドウ内に表示される前に読み込んで、計算させる必要がありました。しかしこれはまったく良い方法ではありませんでした。ちょうどその頃、私は glish.com や bluerobot.com といった素晴らしいサイトを見つけ始めていました。どちらのサイトも、テーブルを一切使わずに複数列のレイアウトを実現するための方法を公開し、文書化していました。それらの方法を試してみましたが、私たち独自のシナリオがあったために、最初の何回かは失敗しました。しかし、それらの中から Wired News のデザインに応用できる方法を見つけるまで、そう長くは掛かりませんでした。
レイアウトのために絶対的に使われていたテーブルを取り除いたことで、HTML のマークアップと無駄なタグを大幅に削減し、非常にメンテナンスしやすい構造を得られました。コンテンツが固有のテーブル構造に縛られなくなった結果、それらのコンテンツをとても柔軟に見せることが可能になりました。CSS にいくつかの変更を加えるだけで、何千というページの視覚表現を完全に変えることができるのです。また、大変歓迎すべき副次的なメリットとして、入れ子になってゴチャゴチャした、レイアウト目的のテーブルがなくなったことで、Wired News のアクセシビリティは大幅に向上すると思います。
各カラムは float を使って組み立てているのですか? それともポジショニングを用いているのでしょうか?
ページの列構造を配置するために使っていた最後のテーブルを取り除こうとするときに、float による div と、ポジショニングを使った div の両方をよく確認してみました。2 週間、どちらの方法を使うか迷った結果、Wired News の選択として、最終的にポジショニングを使った div に絞り込みました。
なぜ float ではなくポジショニングを選択したのですか?
私自身の見解では、float には不都合な点がいくつかあります。ひとつは、一般的なマークアップで必要とされるコンテンツの順番です。Wired News の場合、どのページでも必ず中央 (メイン) の列に最も重要なコンテンツが含まれていますが、スタイルシートを読み込まないブラウザでは、中央列のコンテンツを最初に表示させたかったのです。 float を使うと、必ず左右のどちらかの列を最初に持ってこなければなりません。左右どちらかの列を主要なナビゲーションに使っているサイトなら、この float を使った場合に求められるコンテンツの順番の条件は、目的とした都合の良い表示を実現できるはずです。
また、float を使った列では、縦方向の開始位置を揃えるのが大変であることにも気付きました。float を使った 2 列のレイアウトは簡単に見えます。しかし、3 列目を加えると、一部のブラウザでは全体の幅を動的に計算するために、各列の幅がかなりバラバラになってしまうのです。さらに、ブラウザウィンドウの大きさを変えると、ひとつの列が他の列の下に押し出されてしまうといったことが頻繁に起こりました。
左右の列に絶対配置を用いると、各列のマークアップをどんな順番に変えることもできます。私たちには、マークアップの順番にしても、広告をひとつとっても、ここでは説明しきれないぐらい、相当の社内規定があります。しかし、ポジショニングを使えば、中央列をマークアップの最初に持ってくることが可能でした。また、各列を確実に同じ縦位置で揃えられることが保証されました。
とは言っても、ポジショニングには不都合な点が 2 つあることに気が付きました。まず、ひとつあるいは複数の列を絶対配置にした場合、フッタを必ず一番長い列の下に配置する方法がありません。私たちは結局、フッタの幅を中央列の幅に合わせて、他のコンテンツと重ならないようにしました。もうひとつの欠点は、ブラウザウィンドウの大きさが小さいときに問題となります。float では、コンテンツがウィンドウの幅に合わない場合、自動的に再構成されますが、絶対配置した列は、ひとつの列のコンテンツが他の列に重なったとしても、常に同じ場所にレイアウトされてしまいます。しかし、これら両方を考え合わせてみても、float よりもポジショニングのメリットを思いとどまらせるほどには至りませんでした。
ページを印刷した場合、新しいデザインはどのように表現されますか?
ページ全体のコンテンツの大部分をカバーした、印刷メディア用の特別な CSS ファイルをひとつ用意しました。デフォルトでは、スクリーンメディア用の CSS ファイルへのリンクはすべて、「all」メディアの代わりに「screen」メディアとして明示的に宣言されます。これによって、どのスクリーン用スタイルも上書きすることなく、印刷用スタイルを白紙の状態で始められます。印刷用スタイルでは、ページのコンテンツを 2 列または 3 列に分けるのではなく、1 列で表示します。また、プリンタのインクを節約するため、背景色や背景画像のほとんどが取り除かれます。フォントサイズはポイント (pt) 単位で指定され、印刷した紙の上で読みやすさを向上させるためにセリフ体 (明朝体) が使われています。
私たちの記事は必然的に、サイト上で最も印刷されるページになります。技術的には、印刷メディア用の CSS ファイルを使うことによって、記事のために別の印刷用テンプレートを生成せずに済みました。しかし、一部の記事は 2、3 ページに分割されてしまうので、記事全文をひとつのページに入れる、印刷用に若干変更したテンプレートを作成しました。その別のテンプレートを機能させるため、リンクした印刷メディア用スタイルシートのメディア属性を「all」に変更し、通常のスクリーンメディア用ファイルへのリンクを削除しました。これによって、スクリーン上でも、そのページの印刷に利用するのと同じ形式を一時的に表示することが可能になりました。
今回のリデザインは、サイトの管理者であるあなたにどのようなメリットをもたらしてくれましたか?
要するに、デザイナーとして、わずか数種類のファイルで何千というニュースページの詳細なデザインをコントロールできるという事実の他に、という意味ですか? 例えば... 技術者が、ページのデザインに関してや、次のスペーサー GIF をどこに置くかということで頭を悩ませるよりも、サイトの実際の機能性を高める作業に集中できるようになりました。また、ある開発者が、ひとつのモジュールを組み直すのに 1、2 時間は掛かると思っていたところ、最近では 5 分で済むようになりました。それから、別の CSS ファイルを指定し、画像を差し替えてやるだけで、一週間、毎日サイト全体の配色を変えてしまおうというアイディアが生まれました。うーん、今すぐにすべてのメリットを思い付くのは難しいですね...
何か不都合な問題にぶつかったことはありますか?
正直なところ、ここに至るまでに、いくつものチャレンジと問題に突き当たりました。まず最初に、Wired News は大量のバナー広告によって支えられているサイトですから、広告単位がいくつかの重要な決定要素となりました。広告配信業者は基本的に、あらかじめ用意してあるリストから動的に広告を引き出すために、インラインフレーム (iframe) を使うよう求めてきます。このインラインフレームのために、XHTML の Strict 規則を守ることが可能だという考えを撤回し、XHTML Transitional の文書型定義 (DTD) を使うことで妥協しました。私たちは全面的に XHTML に移行したいと考えていましたが、これらの広告と、その他一部のサードパーティーのコンテンツを組み込む必要があったので、実現することはできませんでした。
技術者たちもまた、XHTML を念頭に置いて CMS に入力されていない、膨大なコンテンツのアーカイブに直面しました。確かに、Wired News の記事はデータベースに存在し、ページのテンプレートや周辺のフォーマットとは別に管理されています。しかし、ライターや編集者、プロデューサーは、ずっと前から段落タグを閉じずに (</p>) Vignette に記事を追加してきました。引用符の付いていない属性や、大文字の HTML タグですか? もちろんそれらも見つかると思っていましたが、実際、データベースに入っている、あらゆる過去の記事に含まれていました。幸いにも、私たちのチーフエンジニアが、データベースの中からこのようなマークアップに合っていないエラーを探し出して修正するスクリプトを書いてくれました。私たちは、過去のコンテンツについては一切クレームを付けませんが、たとえ数年前の記事であっても、できる限り正当なマークアップとなるよう、様々な取り組みをしてきました。
XHTML と CSS への移行によって、コードの操作に通常費やされる開発期間は間違いなく削減されましたが、完全に楽になったとか、コストがまったく掛からないということではありませんでした。実際に、技術者の Aaron Jones は、Vignette のテンプレートの大半をゼロから書き直すことになりました。私は、Web 標準そのものではなく、様々なブラウザの気まぐれなレンダリング動作と不整合を理解するという、急激な学習曲線にぶち当たりました。ライターや編集者は、いつもの記事を出版するにあたって、いくつかの新しい規則に慣れる必要がありました。経営陣もまた、一部の古いブラウザや小型のブラウザでは、スタイルが適用されていない状態のコンテンツが表示されるという事実を受け入れなければなりませんでした。私たちは、たいていの利用者はスタイルなしの記事を受け取る方を選ぶだろうと思っています。なぜなら、最終的には自分たちが使っているブラウザでコンテンツを問題なく読めるからです。しかし、一部の利用者は、私たちが下したひどいデザインの決定について、不平不満を申し立ててくるかもしれません。それらのフィードバックループには適切に対処する必要があるでしょう。
Wired News では、利用者像を理解するため、サイトのアクセスログを解析しました。データを見たところでは、利用者のうち約 14% が、スタイルの適用されていない状態のコンテンツを受け取っていると推測できます。これは、今まで、あらゆるブラウザで同じようにページを見られるのが当たり前だと考えていたことを思えば、驚異的な数字です。
他に移行の過程で得られた教訓はありますか?
コンテンツのデザインは、コンテンツそのものとは明確に区別されるべきだというメッセージを、これまで何度も聞いてきましたが、実際にそれらを切り離すプロセスをたどるまでは、そうすることのメリットを十分に実感できなかったと思います。今となっては、HTML のマークアップに一切触れることなく、細かいデザインの変更をサイト全体に即座に反映することが可能になりました。テンプレートに変更を加えたり、コンテンツを追加する必要がある場合でも、サイトのデータは、開発者が驚くほど簡単に変更できるような形で構造化されています。
また、Wired News のアクセシビリティは、そのための特別な取り組みはほとんどしていないにも関わらず、大幅に向上しました。もちろん、画像の代替テキスト (alt 属性) により気を配ったり、見出しタグを適切に使うような努力はしています。しかし、見た目のためのマークアップタグを大幅に削減したことも、大きな役割を果たしています。すべてのコンテンツが、スタイルシートなしでも完全にアクセシブルなので、私は、両方の世界を乗り越えたと考えています。それは、美しくデザインされ、高度に定型化され、ブランドの名に恥じない Web サイトは、異なるブラウズ環境にも適応できるということです。
シンプルなテーブル構造を使った、あるいは一切テーブルを使わない、標準に準拠したレイアウトへの移行を考えている、あなたと同じようなサイト開発者に対して言っておきたいことは?
XHTML/CSS への移行は、まずいくつかの事柄を考慮に入れることから始めるべきだと思います。マークアップの中にあふれている、余計なテーブルや、見た目を整えるためのタグによって引き起こされる、メンテナンスの苦労に悩まされていませんか? ファイルサイズとダウンロード時間の高速化によるメリットが分かりますか? 長期的に見れば時間と予算を削減できる大幅な変更に先行投資する資源がありますか? サイトのドキュメントについて、古いブラウザや特殊なブラウズ環境に対する下位互換性を確保することが重要ですか? では、将来のブラウザアプリケーションとの上位互換性について考えたことはありますか? サイトのドキュメントがあらゆるブラウザでまったく同じに見えないという考えを受け入れられますか?
これらの質問に対する答えがひとつ以上「Yes」なら、実現へのチャンスを見つけられる可能性は大いにあります。今私が指摘した最後のデメリットを肝に銘じてください。すべてのブラウザがテーブルレイアウトの代わりに使われる CSS をサポートしているわけではありません。そういった場合、ブラウザは多くのバグを含んだ状態でドキュメントを表示します。それを防ぐためには、CSS を十分にサポートできないブラウザから一部のスタイル情報を隠すことを、意図的に選択する必要があります。現在のサイト利用者が使っているブラウザの割合はどうなっていますか? ターゲットとしている (おそらく様々な) 利用者像はどうなっていますか? 利用者の大半は、新しい、標準に準拠したブラウザで、あなたのサイトを見ているのではないでしょうか。
初めて移行を実施に移す場合、組織形態やデータの複雑さによって、一部のサイトではより時間が掛かることがあります。データベースからコンテンツを取り出すページでは、雑多な構造を持った、何百という静的 HTML ファイルを調べるよりは、おそらく移行に必要な作業は少なくて済みます。しかし、どのような状況にあっても、その移行が価値ある取り組みだと思ったら、サイトのデータを正しく再構築する良い機会です。最後には、自分が求める柔軟性を実現できるのですから。
原文書の情報
- 著者: Eric A. Meyer
- 最終変更日: October 11th, 2002
- 著作権: 2001-2003 Netscape