NYTimesのArticle Skimmerに学ぶ
『全部の情報をいかにレイアウトするか』ではなく『見やすいレイアウトありきで、情報量をどこまであきらめるか』
NYTimes.com が 記事を一覧するシンプルなレイアウトの Article Skimmerというプロトタイプを試しています。
レイアウトとしては、左に記事カテゴリーリスト、そして記事を等分したブロックにして一覧表示しています。画面遷移の方法としてカテゴリ名をクリックすると上下スライドのモーションを見せながら該当カテゴリに移動します。
沢山の情報をアーカイブするインターフェイスとしてはシンプルさの追求による極めてユーザーに優しいレイアウトです。画面遷移も斬新な印象ですが、ここではきれいにグリッド状にしきられたレイアウトについて考察してみたいと思います。
CMSによるアーカイブページをレイアウトすることの難しさ
こういった「記事詳細ページ」以前のアーカイブページをどのようにするかというのは、ブログではもちろん、ECサイトや企業サイトでもよくある場面です。
決められた原稿での静的ページならデザイナーが決めたレイアウトで問題ないのですが、CMSの場合は文章量は固定されません。つまり、レイアウトは更新担当者の文章量に依存してしまいます。
（CMSで構築したものの、クライアントの自由気ままな更新によってどんどんレイアウトが崩れて行くのはよくある話）
そんな条件下で、ボックスをフロートさせてきれいなグリッド状にするだなんて、できれば避けたいレイアウト。この Article Skimmer ではどのような対処をしているのでしょうか。
でこぼこのブロックをグリッド状に並べるには
Article Skimmer ではブロックの横幅はリキッドで指定ですが、高さが固定されています。
つまりウィンドウ幅を縮めて文字が下に流れた場合、またフォントサイズを大きくした場合、はみ出した記事本文は見えなくなることになります。
「なんだそれだけか」という内容ですが、ここで書きたいのはコーディングテクニックの話ではありません。
『全部の情報をいかにレイアウトするか』ではなく『見やすいレイアウトありきで、情報量をどこまであきらめるか』という、あくまでアーカイブページとしての機能を優先した設計段階の話になると思います。
これまでの考え方だと、文字量が増えればレイアウトが柔軟に変化して表示を保つ、フォントサイズが大きくなればボックスが大きくなり表示を保つ、というものが「よいコーディング」とされていたような気がします。
しかし、記事詳細ページへの案内役としてのアーカイブ機能を考えた時、『とにかくレイアウトを維持して重要性が低い部分は非表示』にした方が、ユーザーにとっては見やすいということを Article Skimmer が明示していると感じます。
例えばApple のカレンダーアプリ iCal の場合、1日に沢山の予定を入れてカレンダーを小さくすると、個別の表示文字がどんどん減って行き最後は1文字だけになるまで省略されますが、存在自体が省略されることはありません。月一覧では個々の内容が犠牲になっても、せめてイベントの存在だけでも伝えるという機能目的が達成されています。
まとめ
ボックスの高さを固定してフロートすればグリッドになる、という事は誰でも知っていることです。
しかし、多くのHTMLコーダーがいままでWEBサイト上でこれをしなかった理由として「文字を大きくすると語尾が消えるんですけど…」というクライアントなりディレクターなりの物言いがあるからだと思います。
そのためハナからこんなレイアウトは避けたり、テーブルにしたり（テーブルは嫌だと言われ無理矢理動的なCSS指定を追加したり）という話になってしまう。
しかし、そもそもフロントエンドコードの問題ではなく、『どのページがどんな役割をするのか、どのページでどこまでの情報が必要なのか』という、サイト設計段階で解決するべき問題だと思います。
クライアントがWEBに対する理解が浅い場合「全部大事な文章なんだからとにかく全部表示させたい！」と主張する場合も多いと思いますが、ユーザーの視線は1つ、またページ遷移も一瞬であることを、よく考えた情報整理が必要です。
Posted on 2009/02/18DEVELOPMENT WebDesign