Liner Note » 検索結果: » ブログのIA研究

Webアクセシビリティの未来が見えない

leva — Mon, 16 Jun 2008 13:58:23 +0000

今月12日のヤスヒサさんのPodcastではWebアクセシビリティをテーマにして、インフォアクシアの植木さんと対談されていました。

Webアクセシビリティとは

まず、Webアクセシビリティとは何かというのを、普段の知識やインフォアクシ内のページ、あるいはこのPodcastを聴いて感じたところをまとめてみますと、まず下図のように新聞・雑誌などの紙媒体のコンテンツは制作者が作ったようにしか見ることは出来ないのだけれど、ウェブ媒体のコンテンツは文字サイズを変えたり、反転させたり、色を変えたりと、利用者が読みやすいように利用方法・形態を変えて利用することが出来ます。また、ウェブは必ずしもPCから見られるわけではありません。紙に印刷してみられることもあれば、携帯電話で見ることもあります。WiiなどTVで利用することもあるし、機械に読み上げさせている人もいるでしょう。

Webコンテンツの特性／基礎知識－ Webアクセシビリティポータルサイト『infoaxia(インフォアクシア)』

そのように多様なアクセス方法・表示方法が可能になるのがウェブという媒体の特性で、そうしやすいようにコンテンツ制作者側がきちんと作ったり、ブラウザ（広く言えばユーザエージェント）が機能面でサポートしましょうと。そうした多様なアクセスを考えるときのコンセプトがアクセシビリティ（accessiblity）であると、そういう風に理解しました。

Webアクセシビリティの末にあるもの

ただ、Podcastを聴いていて思ったのは、なんとなくビジョンが見えないなと。

アクセシビリティにはWCAG2.0を始め、いろんなガイドラインがあったりするわけですけど、例えばそれに準拠することで…

情報がより伝わるようになります
- 高齢者が（適宜文字サイズを変えるなどして）コンテンツが読みやすくなります
- 一般の読者にもより内容が伝わりやすくなります
- 検索エンジンに内容を拾ってもらいやすくなります（SEO）
デバイスのアクセス性が向上します
- PC以外のブラウザ（携帯電話・スマートフォンやTVゲーム機のブラウザなど）でも読めるようになります
- 弱視者、全盲者の方が（非視覚系UA¹ を用いて）情報を得られるようになります

といったように多様な環境から利用できるようになると言うメリットがあると。しかし、逆に言うとそれだけ？とも思ってしまうわけです。このサイトでは十分ではありませんが、ある程度適切なマークアップに努めているつもりですから、内容もそれなりにアクセシブルになっているでしょうし、携帯電話やiPhoneなどの機器にはその環境に応じた最適化を行い、読みやすい環境で提供しているつもりです。つまり、全てとはとても言えませんが² 、ある程度の水準まではできていると思っています。つまりWebアクセシビリティはすでに前提となったルールであって、これから何を考えていけばよいのかなと思うわけです。

Web標準が当たり前な世の中になった時の戦略 | Web標準Blog | ミツエーリンクス

この話に近いなと思いました。つまり、Podcastで言われていたようにWebアクセシビリティという言葉が無くなった時には、どのような部分にエネルギーを向けるようになっているのかということです。

例えば、ユーザビリティには3つの水準があることがいわれています（図にされたものを引いておくと以下のようになります）

ユーザービリティとユーザー中心設計の発表資料 – ウェブユーザビリティ.JP

この図で言うと、アクセシビリティはこの第一水準をやっとクリアして、第二水準について議論されているように感じて、まだ第三水準のことが話されていない…ビジョンというか未来が見えないというのはこういうことを言うのかなと感じています。

Webアクセシビリティのビジョン小考

では、具体的にどのようなビジョンがありうるのかということを、UA側がどういう機能を持つとよりアクセシブルになるかということを意識しながら少し考えてみました。

普遍的に利用できるサイトナビゲーションバーの実用化

嬉しいこと: サイトをより簡単に移動できるようになり、個々のサイト構造設計の善し悪しに関わらず目的のコンテンツにたどり着きやすくなる

Netscape7 や Opera7beta 以降では、コンテンツ制作者がlink要素を適切に記述しておけば、それに従って
サイトの主要な場所にリンクが貼られたナビゲーションバーがブラウザ側で利用できるようになります。

現状、対応ブラウザが少ないため、制作者側も積極的にlink要素を配置しようというインセンティブもあまりない状況なのですが、対応ブラウザの広がりによってブログツールの対応など実装例も増えていくのではないかと思います。検索ページが明示されれば、ブラウザ側から直接サイト内検索を行うこともできるようになるでしょう。

また、この発展形としてパンくずリストなどの現在の位置を示すナビゲーションもブラウザ側に組み込んでいけばいいのではないかと考えています。

Podcastでも、文字サイズ変更機能はサイト側ではなくUA側で対応する機能と言っていましたが、それと同じ意味で今あるナビゲーションも、サイト独自で行うよりもブラウザ側で普遍的に扱えるようにすることで、よりサイト内での迷子が減らせるようになるかと思います。

利用者自身がウェブサイトを簡単に再設計できるように

嬉しいこと: サイト構造が明確になることで、情報にアクセスしやすくなる

単に反転するとか、文字サイズを変えるという単純な調整ではなく、例えばサイドバーや本文、フッタなどをモジュール化して、それを利用者が好みのレイアウトで閲覧できるように設定できるというものです。

HTML5（現在は草案段階）ではmenu要素やheader要素/footer要素、nav要素などコンテンツをより明確に構造化するための専用の要素が設けられていますが、これを利用して利用者がどのサイトも同じデザインで閲覧できるようにもできるでしょう。

また、通常の縦スクロールに加えて横スクロール読みや、縦書き読みなどが利用者側で選択できるようになれば、個に応じたウェブの読まれ方が広がるかもしれません。

コンテンツのきめ細かい調整

ただ、そうした大きい意味での調整だけではなく、細かな調整（文字サイズ調整など）にも気を払う必要があると思います。

ところで、このサイトにはレイアウト調整機能を設置していて、文字サイズや行間を変えられるようになっているのですが、その対象範囲は基本的に本文＋コメントだけにしています。

それはタイトルやナビゲーションを拡大してしまうと、全体のレイアウトが崩れてしまって、リンクなどにアクセスできなくなることを考慮してのことです。

先のHTML5の話に関連していえば、本文部分がきちんと構造化されていますから、例えば文字サイズを調整する際は本文の文字サイズだけ拡大、全体を拡大（ズーム機能）などが選べるようになるわけです。よって、大きいサイズで見た結果レイアウトが崩れて情報に気づかない・アクセスできなくなるという事態をある程度回避できるようになるではないかと思います。

まとめ

Webデザインというのは制作者の技量によってバラツキが多いところで、Webアクセシビリティもそれに大きく影響されてきたと思います。構造整理が不完全なナビゲーションなど目的の情報にアクセスするまでに頭を抱えてしまうようなサイトもあるでしょう。優れてアクセシブルな所もあれば、そうでないところも多い。

ナビゲーションやレイアウトをユーザエージェント側から普遍的にアクセスできるような環境を整備することで、Webアクセシビリティのバラツキが無くなるでしょうし、何よりもこれによってユーザ自身がウェブの見方をコントロールできるという考え方が定着すれば、ウェブデザインへの考え方も大きく変わるでしょう。

多様な人・機械が多様な環境から多様な見方が出来るようになる。細かな違いはあれど、Webアクセシビリティのビジョンはこの語の定義を徹底したものになるのだろうと思います。

参考にしたサイト

ブックマークコメントへの応答

その前提がまだ低くね？とは思う。その品質はもっと高められるはず。加えて俺らは本当に障害者のニーズを取り入れているのかっていうのもギモン。デベロッパーの虚像とかになってないかな。

id:aratako0さんのブックマーク

前段、突き詰めれば一例として画像の代替テキストをより詳しく記述したり、動画に音声キャプションを付ける必要があるでしょう。しかし、これは、画像置換問題の時にも結論したように、完璧を求めるのではなく、ある程度どこかに一線を設けないといけない話だと思っています（それで飯を食っているわけでもない限りは）。いくらコンテンツがアクセシブルであっても、コンテンツ自身がつまらなければアクセスする価値はありませんよね³ 。

そうではなくて、まだまだ手近な範囲でやってないことがこんなにあるじゃないかということであれば、その旨お知らせいただければ助かります。

後段、確かに障害者がウェブをどのように見ているかというのも総務省の「みんなの公共サイト運用モデル」というコンテンツを見て始めて具体的に知りましたし、直に障碍者の方がウェブを利用していることを観察したことがありません。

そういう意味では仰るとおり、デベロッパーの虚像を基にデザインしてアクセシブルだと言っている可能性は大いにあります（こんなハッキリしない言い方をしているのがその印ですね）。

音声ブラウザ、スクリーンリーダー、点字ピンディスプレイなど
alt属性値なんか時々不十分だなーと思いつつ、面倒くさいので少し手を抜いた記述をしたりしますし。今回の記事でも不十分な所もあるでしょう。
別に、俺って面白いコンテンツ書いてるよねという意味ではなくて

幅固定か可変かではなく、読者環境に合わせて見やすいデザインを提供しよう

leva — Fri, 18 Apr 2008 18:41:39 +0000

ウェブデザインにおけるページのレイアウトで、コンテンツ部分の幅をピクセル単位で固定するかあるいは相対値（%等）で可変にするかで議論があるようです。最近は、閲覧者のフォントサイズも考慮に入れて、文字数（em等）で可変にするというエラスティック・レイアウトというのがあるようです。まとめてみると、以下のように整理できそうです。

レイアウト名	固定レイアウト (Fixed Layout)	可変レイアウト (Liquid/Fluid/Flexible Layout)	弾力的レイアウト (Elastic Layout)
定義	コンテンツの横幅がピクセル値で固定されたレイアウト	コンテンツの横幅が%値で決められ、読者のブラウザ幅によってコンテンツ幅が変化するレイアウト	コンテンツの横幅が文字サイズ（em）で決められ、読者の文字サイズ設定によってコンテンツ幅が変化するレイアウト
サンプル画像
サンプルCSSコード	#container{ width: 800px; }	#container{ width: 80%; }	#container{ width: 50em; min-width: 45em; max-width: 60em; }
メリット	横幅が閲覧者のブラウザ幅に依存しないので、大幅にデザインが崩れることがない	横幅が閲覧者のブラウザ幅に柔軟に変化するので、固定レイアウトに比べるとより多くの環境で読みやすくなる	固定・可変レイアウトでの文字サイズで問題を解消横幅が閲覧者の文字サイズに従って全体のレイアウトが変化するため、全体としての統一感が増す
デメリット	閲覧者のブラウザ幅が想定したものより狭い/広いと読みやすさを損なう閲覧者のフォントサイズ環境が想定したものより小さい/大きいと1行の文字数が多すぎ/少なすぎる結果となり読みやすさを損なう	閲覧者のブラウザ幅が広いと1行の文字数が多くなりすぎてしまい、圧迫感が生まれて読みづらくなる閲覧者のフォントサイズ環境が想定したものより小さい/大きいと1行の文字数が多すぎ/少なすぎる結果となり読みやすさを損なう	閲覧者の文字サイズが大きいと、コンテンツ幅がブラウザ幅を超えてしまい、水平スクロールバーが出るので、極端に読みづらいレイアウトになってしまう画像サイズが固定値なので、全体のサイズに対して画像が小さすぎたり、大きすぎたりする

要するに、どれも一長一短なわけです。ちなみにエラスティックレイアウトの前者の問題についてはElastic layout – wrong term? > AlastairCで解決法が示されていますし、2xupさんは可変レイアウトにエラスティックレイアウトの手法を織り交ぜて、両者のいいとこ取りをしているようです。

過去の私案

で、私はどうしたか。基本は可変レイアウトベースですが、以下のような工夫を加えています。

最小・最大文字数を設定することで閲覧者のブラウザ幅や文字サイズによって極端に読みづらくなるケースを回避した
横幅に応じて自動的に段組をくむようにして、閲覧者のブラウザスペースを有効活用するようにした（現在は中止しています）
ユーザが表示部分を微調整できるように、スライダーで動的に1行の文字数と文字サイズを変更できるようにした

これが当時の解決策でした。でも、本当にこれでいいのかなとは思っていたのですよね。

先日、読者の方とチャットした時に指摘してもらったんですが、まず2点目については幅に応じて段組するというのは読みやすいとは限らないということです。例えばブラウザ幅が広いと2段組、3段組になったりするわけですが、これは現在のウェブページが上から下への一方的な視線移動をするように設計されている中で、上下移動を何回も繰り返すことととなってしまい、手間が増えるのではないかと言うことです。

一方で、段組をせずに最大文字数を設定しておくと、ブラウザ幅が広い場合に余白が大きく出てしまって、画面に大きく無駄な領域が出来てしまいます。もちろん空の領域がないほどいいわけではありませんが、なにか有効活用できないかなとは思いますよね。

そして3点目については、まず私が懸念していたこととして「初めてこれを見た人はこれが何か理解できるだろうか」ということと「果たしてユーザはこれを使っているのか」ということがありました。この辺はユーザテストもしていないので、かなり不安を持っていたところです（ウェブデザインの基本はPDCAサイクルによる改善ですから）。加えて、読者さんには「カスタマイズパネルが邪魔である」という指摘もいただきました。

しかし、これら以前のそもそもの問題として「ユーザによる微調整が必要なのか」という問題もあるのです。つまり、そもそもこういった作業は、ブラウザ側がやるべきことであって、サイト側がやることではないと。なので、私は将来的にはこうした微調整バーは撤廃しようと考えています。

考え中の私案

読者さんとのやりとりの中で考えた結果、現在よりもよりよいデザインをということで考えているのは、閲覧者のブラウザ環境（横幅や文字サイズ）を取得して、自動的にその環境に沿って全ての人にベストとはいかないけど¹ なるべく多くの人にベストである環境を提供するレイアウトです。一言で言うと最適化レイアウト（Optimized Layout）でしょうか。

幸いなことに、Javascriptを使用すれば横幅も、文字サイズも取得できるようです² 。

具体的には可変レイアウトをベースにし、最小・最大文字数を設定することで一定の環境に対応しつつ、そのような技術で閲覧者環境を取得して、自動調整を進めていくことでデザインの柔軟性を高めていこうと思っています。もっとケースに分解すると以下のような感じです。

閲覧者のブラウザ幅が狭い場合（600px程度）

文字サイズをやや小さめに設定することで、1行の読みやすい文字数を確保する（もちろん、閲覧者のブラウザで文字サイズが切り替えられるようにしておく）

閲覧者のブラウザ幅が通常程度の場合（900px程度）

特に自動調整無し

閲覧者のブラウザ幅が広い場合（1200px程度）

文字サイズを大きめに設定することで、1行の読みやすい文字数を確保する
サイドバーの領域をやや広めに取る

閲覧者のブラウザ幅が広すぎる場合（2000px程度）

文字サイズを大きめに設定することで、1行の読みやすい文字数を確保する。
サイドバーの領域をやや広めに取る
視線の上下移動を伴わない範囲で段組を組む

最初に手間をかけるのは少し大変かもしれませんが、一度WordPressのテーマなどのようにテンプレートにしてしまえば、そのテーマの利用者は手間をかけることなく利用者に読みやすい環境を提供できるので、問題無いと思います。

ちなみにFirefox 3ではwidthプロパティが追加されるようで、より柔軟なレイアウトが可能になりそうです。

これからは今の最適幅は何ピクセルかなどという話ではなく、どんな解像度でも快適にご覧頂けますといったような解像度非依存デザインの考え方を基本・前提としてウェブデザインを進めていきたいと思います。

調査の時に見つけたページ

弱視の方などアクセシビリティ上、配慮すべき方もいらっしゃると思うので
必然的にJavascriptに依存することになりますが、当然ながらJavascriptを利用しなくても一定の環境をサポートできるようにしておかないといけませんね

サイドバーにはどんな情報を載せるべきか：ウェブログのIA研究(7)

leva — Fri, 18 Apr 2008 15:06:36 +0000

サイドバーいらない論に始まって、リキッドカラムデザイン¹ なんかを話してお休みしていたブログデザインの話ですが、ヤスヒサさんのサイドバーの行方という記事をみて、また少しずつ考えていました。

えーと、本筋を話す前にちょっとおさらいしておきましょう。まず、サイドバーいらない論では、サイドバーは一般的に過去ログや他のカテゴリなどのリンクをたどることによって、その人の考えを知るきっかけができたり、コメントを追うことができる風に使われているんじゃないかと指摘しました。しかし、その役割は必ずしもサイドバーに担わせるべき類のものではなく、そうすることによって却って読者の本文に対する注意力を削いでしまっているのじゃないかとも言いました。その上でマルチカラム（段組）ではなく、1カラムもメリットあるよという話をしました。

しかし、よくよく考えてみるとこの展開も1カラムのメリットだけを挙げて、マルチカラムのメリットを話せていない点で考察が甘いよなという感じもしていました。実際、サイドバーも役立つ局面は十分あるはずです。その点、サイドバーに載せるべき・載せたい情報を吟味しているヤスヒサさんの記事は面白いなと思ったのです。

サイドバーの役割ってなんだ？

さて、サイドバーにおける最も効果的な情報の配置が上記のように現在一般的に使われている用途でないのならば、いったいどういった情報をどこに配置したらよいのでしょうか。

そのためには、そもそもサイドバーの役割とはいったい何なのかを考える必要があるでしょう。人によって諸処あると思うんですが、今のところ私は、その役割はユーザに本文をよりよく理解してもらうための助けになることだと考えています。なぜかというと本文の印象を強くするためには、本文とは別の位置＝サイドバーに本文の理解を助けるコンテンツを並べる必要があるからです。

もうちょっと詳しく書いておきましょう。

まず理由の前提として、1カラムだとどうしても全体的にメリハリのない単調なデザインになりがちというのがあります。また、ウェブ上の文章は基本的に斜め読みされるものです。ですから、本文と注釈・補足あるいは参考リンクを一緒に載せても、どうしても本文の要旨的な部分以外は印象が薄くなってしまうのではないでしょうか。ですから、そうした情報をサイドバー部分に配置し、意図的に本文とは異なるようにメリハリをつけていくことで、ページのメインコンテンツである本文の読解の助けになることができるのです。

具体的に何を載せるのか

えーと、文章でいろいろ書いてばかりいても始まりません。少し具体的な話をしましょう。

まず1点目、本文の読解を助けるものですが、例えば以下のようなものをサイドバーに添えてみると良いんじゃないでしょうか。

注釈や附記など本文の補足となる文章

本文の補足や附記など本文の補足となるものです。余談や雑談なども本文と一緒にするとメリハリが無くなりますので、適宜分離した方がよいと思います。

この手のコンテンツを文末脚注でまとめるとページ内移動が発生し、視点移動の関係上本文を見失ってしまう可能性がありますが、サイドバーはその点本文と並列関係にあるので、その問題は解消されるのではないでしょうか。SWAのWebページさんなんかは本文と附記がきれいに分離されていて、読み物として非常に良質なデザインになっています。

イメージ画像など本文を読解するための助けになるもの

短文なら良いですが長文でテキストのみとなると、全体として文字の羅列といった印象が出てしまい、テキスト字体の上手下手とは関係ないところで、ユーザを取り逃してしまう可能性があります。ですので、例えばデジモノに埋もれる日々さんのコラムのように見出しを敢えて画像化して要点を強調してみたり、あるいは文章に関連する画像を掲載してみると読者が読む支えになると思います。

ただ、本文と密接な関係のある画像（本文の根拠となる資料図・概念図など）はあくまで本文に位置づけられるものなので、アクセントとして使うのか、それとも本文の一要素として使うのかを考えて、明確に区別すべきだと思います。

参考となるページへのミニリンク集

例えばAの話をしたいけど、そのためにはBを前提として理解していないといけないというケースを考えましょう。ここで、Bの話をしてしまうと、構成上AとBどちらの話がしたかったのかわかりづらくなる場合があります。なので、とりあえずわからない人はリンク先で勉強してねというリンクを張っておくというケースがあるかと思います。

これをサイドバーに持ってくることで、読者はそれが前提となっていること、（理解できていない場合）それらを読めばいいことを一目で判断できるようになります。これは上記の「注釈や附記など本文の補足となる文章」を広義に考えたものに含めて良いかもしれません。

参考文献へのリンク

例えば、書籍からの引用や書籍の要約がある場合、書影付きのオンライン書店へのリンクがあれば、視覚的に他者の意見の援用をしているのだと判断しやすいでしょう。

本文全体の目次など全体を俯瞰できるツール

長文になると、全体の構成が複雑なものになり、読者としては「今何を読んでいて、この人は何を言おうとしているのか」が曖昧になりがちです。

そうした所に陥らないために、目次をサイドバーに貼り付ける形で提供する² ことで、全体の見通しが良くなりますし、リンクを張っておけば各見出しにスクロールを何度もすることなくたどり着くことが出来ます。

Kanzaki.comさんでは、各中見出しに目次表示ボタンをつけていますが、サイドバーでの表示も向いているかと思います。

あとはサイドバーでコメントとか、あるいはサイドバーを丸々Wikiにしてみるとかも実験としては面白いかなとは思うんですが（＝コメント欄で吸収できない読者のフィードバックを掲載する）

閲覧者のブラウザ幅に応じて自動的、あるいは閲覧者自身の手動操作によって最適な段組数に変形するデザインのことだと自分は定義してます
CSSでいうとposition: fixed

続・リキッドカラムデザイン：ウェブログのIA研究(6)

leva — Wed, 29 Aug 2007 16:20:34 +0000

昨日書いたリキッドカラムデザインの実験は、リンク先のテキストを解釈しきれていなかったのもあるけれど、実装をどうするかばかりを考えてしまった結果、ちょっと変な実装結果になっていたと思う。

つまり、昨日の実験では幅をおよそ半分以下に設定したときに段組になるように設定したけども、それだと高解像度環境では一行の長さ（＝最大文字数）が長くなってしまって、読みづらくなってしまうケースが生じる。そうではなくて、一行の長さを固定的に¹ 決めた上で、ユーザーのブラウザが、それを超える幅を持つ場合に段組をするようにするのが適切なやり方なんじゃないかと。一言で言うと幅に応じた動的な段組ですね、昨日の記事ではリキッドカラムデザイン（レイアウト）と言っていたことですが。図にするとこんなのです。

jintrick氏の補足では、Mozilla Firefox 1.5以上で実装されているCSS3 段組モジュールの先行実装プロパティを利用して、そうした動的な段組を実現しています（このプロパティについては中身まできっちり調べていなかったので勉強になりました）

CSS 3のマルチカラムレイアウト – Go my wayという記事でもこのプロパティを用いた簡単なサンプルが紹介されています。

で、これを利用して実践に移そうということで、このサイトに適用しています。

Firefox系はこの先行実装を用います。つまり、-moz-column-widthにスライダで設定された値を設定することで、スライダを移動して、好きな段組レイアウトで本文を読むことができます。前のスクリプトのようにスムーズに最大文字数が増減するわけではなく、1カラム→2カラム→‥がガタンガタンと段階的に切り替わるような動きですが、そこまでゲンミツさを求めている人はいないと思うのでよしとしておきましょうか。

それ以外のブラウザ（IE6除く）では、昨日のように本文をdiv要素で真っ二つにして、両方の要素にfloat: leftをかけます。Firefoxのように幅に応じて組段数を柔軟に変更することはできないですし、1カラムか2カラムかを幅に応じて切り替えるのみですが、妥協策としてはまぁそんなに悪かないかなと。

このサイトでは現在、XHTMLコードが妥当でなくなる可能性があるため、Firefox以外のブラウザにこの手法が用いていません。原因は他のブロック要素が始まったときに、divタグを閉じてしまうからです。PHPのDOM関数を使えば安全にできるかもしれませんが、いったん様子見と言うことで。

で、あと残った問題はどう縦スクロールを減らすかですね。読みやすくなっても、上下に行ったり来たりでは面倒くさいですからね。

その他の反応

縦スクロールせずに読めるようにならないと、不便。

カラムの高さをウィンドウサイズ内に制限。

オーバーフローしたら、新カラムへ。

下の段の（或いは新しい）カラムへの移動は、ページをめくるような感じでないと。

カナかな団首領の自転車置き場 – リキッド・マルチカラム考察

これは素敵ですね。イメージにしてみるとこんな感じかな。

コレの良いところは、情報量がどれだけあっても（そこそこ十分な幅と高さがあれば）縦スクロールが一切不要にできることだと思います。コメント云々は下からポップアップ（jigelog）させればいいでしょうし。

技術的には、どうするんだろう‥。1ページ毎の表示（jintrick氏の言うスライドショーのような方法）ならば、javascriptブラウザの高さを算出して、その高さに合わせた内容量を各々ID付きのdiv要素で括って、target疑似クラスで切り替えるとかでいけそうかな、でもちーともスマートではないですし。

そんなことするくらいなら、同じく内容量を算出してDOM Rangeで選択し、displayプロパティを切り替える方がまだマシかな。いずれにしても、まだ私の技術水準ではできなさそうな感じ。

コード

昨日のコードと多少違います。まずは記事呼出部分。

PHPソースコード （single.php）


$content = apply_filters('the_content', get_the_content(__('(Read More)', 'sandbox')));
if (
    ereg("gecko\/", $_SERVER['HTTP_USER_AGENT']) ||
    ereg("MSIE 5.0", $_SERVER['HTTP_USER_AGENT']) ||
    ereg("MSIE 6.0", $_SERVER['HTTP_USER_AGENT'])
){
    echo $content;
} else{
    $content = split("", $content);
    $t = floor(count($content) / 2);
    echo ''."\n";
    for ($i=0; $i<count($content); $i++){
        if (ereg("^<", $content[$i]) || (!$content[$i])){
            echo $content[$i];
        } else{
            echo "".$content[$i];
        }
        if ($t == $i){
            echo "\n";
            echo ''."\n";
        }
    }
    echo "\n";
}
?>

スライダー呼出部分。

PHPソースコード （make_slider.js.php）

そして、最後にCSSをセット。

CSSソースコード （テーマのCSS）

div#former-part,
div#latter-part{
    float:                left;
    overflow:            hidden;
}
 
div#former-part{
    padding-right:        25px;
    margin-right:        25px;
}

いいアイデアだと思うけど、このサイトが横スクロール必須のデザインなところが頭痛い。

livedoor クリップ – Liner Note – 続・リキッドカラムデザイン :実践1カラムテクニックス(4)

Windows IE5, 6でスクロールバーが出るようになっていたのを修正しました。

もちろん、実際には長さはユーザーが変更可能なのだが

リキッドカラムデザインの実験：ウェブログのIA研究(5)

leva — Tue, 28 Aug 2007 14:21:57 +0000

上述するとおり、実際導入してみて失敗したのでこのサイトには導入していないのですが、コードと実装について一応書いておきます。きっかけは、前回と同じサイトの以下のテキスト。

閲覧者のウィンドウ幅が充分広くなると、当然左右、あるいは左右どちらかにスペースができる。そのスペースがある一定以上の幅になったとき、そのスペースに、それまで本文の下部にあった（あるいは異なるURIをもつ外部にあった）補足情報などがサイドバーとして登場する。つまり、ウィンドウをたくさん並べて並行閲覧していても、あるいは低解像度のモニタで閲覧しても、本文がキチンと表示されて利用しやすいリソースとなり、一方、高解像度のモニタでウィンドウを大きくしてみる閲覧者には、その投資に見合ったそれ相応の利益がある。

Hatena::agenda – 本物のリキッドレイアウト

スライダーで動的に1行の文字数と文字サイズを変更・保存するスクリプトでは、内容幅を狭くしたときに、右部分に空きができるのが「もったいないなぁ」とは思っていて、それがこのスクリプトの不満でした。

今回はjintrick氏の提案に着想を得て、その不満を解決できる様な改良を施してみることにした。まずあらかじめ本文を2等分し、本文幅が半分以下に設定された場合、後半のテキストを前半のテキストの右側に回り込ませることにしました（これをリキッドカラムと呼ぶことにしました、本文を6分割すれば6/3/2カラムに柔軟に切り替えることもできるでしょう）

と、言葉で言っても伝わりにくいので、できたものをば。

ビフォー（幅を狭める前）

アフター（幅を半分以下に設定）

前半の下段には、後半上部に飛ぶリンクも用意しています

実装について

で、これで作ってみて、Firefox ではうまく動作するんですが、Operaでは上手いこと動作しませんでした。あとSafariの動作もちょっと怪しい‥。

これ以上、動作確認できるブラウザを減らしたくないので、今回は導入見送りすることにしました。とりあえず、以下にコードを示しておきますので、利用したい人などは自由に使ってください。

動作としては PHP（サーバサイド）で、本文中の p 要素の数を数えて、本文最初から p 要素が全体の半分の位置に来たところまでを前半の div 要素で、全体の半分の位置から最後までを後半の div 要素で囲います。この辺はDOM Rangeで本文要素を書き換えてもいいかもしれませんが、スライダー側の処理とタイミングうまくいかないのが原因なのか、上手く動かなかったためサーバーサイドで処理してます。

一方 javascript（クライアントサイド）では、本文要素の幅を監視して、47%以下の場合は回り込みとクラス名の変更、それより大きい場合はその解除を行っています。

なお、記事単体ページとそれ以外のページを分けて処理しているため、WordPressに依存したコードになっているところがあります。

「本物のリキッドレイアウト」について

今まで「どの解像度環境を最低基準にしてデザインを進めるか」ばかりが注目されてきて、「高解像度環境」ではそれに見合ったメリットが得られないどころか、逆に見づらくなるデザインも散見されてきたと思います。

いわば下を見てばかりで、上を見ずに「リキッドデザインはどの解像度環境でも云々」とか言ってきたようなものですから、そうした中で注目すべき提案だと思います。

私もサイドバーいらない論では、1カラム・2カラム..nカラムをユーザーが選べるように（CSS切り替えとかでありがちですが）なるのが理想的な答えだと思いますと言ったこともあり、同じような感想は持っています。

link要素のrel属性・rev属性で示されるナビゲーションなどは、有効に使うUAも少なく、半ばストリクタのおもちゃ的存在な感がありましたが、そうした使い方はなかなか実践的で有効な使い手だと思います（このサイトでは、必要な情報は下部に表示しているので、わざわざ表示しませんけど）

コード

記事単体を呼び出しているところに、本文要素数の計算と要素の追加をしています。一般的には、を以下のようなコードに書き換えてください。

PHPソースコード （single.php）


$content = apply_filters('the_content', get_the_content(__('(Read More)', 'sandbox')));
$content = split("", $content);
$t = floor(count($content) / 2);
 
echo ''."\n";
for ($i=0; $i<count($content); $i++){
    if (ereg("^<", $content[$i]) || (!$content[$i])){
        echo $content[$i];
    } else{
        echo "".$content[$i];
    }
    if ($t == $i){
        echo '次の段へ移動'."\n";
        echo "\n";
        echo ''."\n";
    }
    echo "\n";
}
?>

スライダーを呼び出しているところもいじります。

PHPソースコード （make_slider.js.php）

最後にCSSをセット。

CSSソースコード （テーマのCSS）

div#former-part.active-part{
    padding-right:        25px;
    margin-right:        25px;
    border-right:        1px solid #ccc;
}
 
div.active-part{
    float:                left;
    overflow:            hidden;
}
 
/* 後続の要素をclear */
dl.show_uri{
    clear:                both;
}

1カラムの情報補完形プラグイン：ウェブログのIA研究(4)

leva — Wed, 15 Aug 2007 20:10:26 +0000

前回に引き続き第2回。さて、サイドバーいらない論で、私はこんな事をいっていました。

（註：サイドバーがそのエントリを書いた人の他の記事が見られて便利だという主張に対して）その人の考えを知りたいのであれば、個別エントリに関連エントリ（同じカテゴリの人気エントリ）をコメント欄直前あたりに貼ればよいでしょうし、コメントを追いたいのであればコメントのRSS（WordPressでは標準装備）を購読すればいいわけです。

Liner Note – サイドバーいらない論

ということで、実践編です。今回は、1カラムで役立つ情報補完系のプラグインをまとめてみようと思います。

てことで、早速それにならって、コメント欄の直後に

記事と関連がある別記事リンク
人気がある別記事リンク
最近コメントが付いた別記事リンク

をつけました。あんまり多くても困るでしょうから1ブロックにつき5記事のリンクを付けています。

ちなみに、カテゴリ一覧とかタグ一覧とか月別アーカイブとかは別に専用ページがあればいいわけだから、ここでは載せていません。

最近コメントがあった記事の表示

ここで言うコメントはトラックバックなども含んだコメントです、WordPressはその辺ごっちゃになっていて若干わかりにくい‥。

Customizable Post Listings（使用中）

件数や表示方法等々がカスタマイズ可能です。

ちなみにこのプラグインは、他にも「最近投稿された記事」、「最近更新された記事」、「記事をランダムに表示」といろいろな表示ができますので、スキンのいろんな場所で活躍できるお勧めのプラグインです。

Brian’s Latest Comments

記事あたりのコメント表示数などが設定可能で、新着コメントと古いコメントの表示色を変えることができます。上記プラグインに不満が残るなら試してみるといいでしょう。

Commented entry list

このプラグインはコメントとトラックバックの表示が別みたいですね。分けて表示したいのならコレかな。

雑感

つことで、駆け足でプラグインを紹介してみましたけど、いかがなもんでしょうか。このサイトでは、単体記事以外にも404エラーのページでもこのプラグイン群を使っています。

あと、もしこういう情報があるといいと思った方は教えてくださいませ。

（参考）スキンへの記述例

目次作成プラグインが反応するため、h3/h4タグをそれぞれw3/w4タグと書いています。

PHPソースコード


 
 _e("See also these articles..", "sandbox"); ?>
 

 _e("Related posts", "sandbox"); ?>

 if (cattag_related_posts()){
        echo "\n";
        echo cattag_related_posts();
        echo "\n";
    } else{
        echo "". __("Related post is not found", "sandbox"). "";
    } ?>


 

 _e("Popular posts", "sandbox"); ?>

 akpc_most_popular($limit = 5, $before = "", $after = "\n"); ?>


 

 _e("Recently commented posts", "sandbox"); ?>

 c2c_get_recently_commented($num_posts = 5, $format = "%comments_URL% (%comments_count%)");?>

はてなキーワードやYahoo!の形態素解析を使えばできそうな気もするが

スライダーで動的に本文とサイドバーの比率を変更・保存するスクリプト（2カラム版）：ウェブログのIA研究(3)

leva — Sat, 11 Aug 2007 12:28:03 +0000

昨日言いました通り、2カラム版です。

といっても、max-widthプロパチをwidthに変えて、少し値を変えるくらいです。widthプロパチを使うと言うことは、副作用としてIE6に対応することになりました、IE6 + 現在確認できるモダンブラウザでは動作を確認しています。

では、なんだかんだ言うより、とりあえずデモとスクリプトをどうぞ。

デモ: 2カラムレイアウトサイトのサンプル
ダウンロード: スライダーで動的に本文とサイドバーの比率を変更・保存するスクリプト
ライセンス: このサイトと同じくCreative Commonsライセンス

で、これは前置きで本当はもうちょい直感的にいじれるコントローラを考えてたんですよ。図にするとこういうのです。

つまり、本文ボックスとサイドバーボックスの間にボタンを設けて、ボーダーとボタンが連動する形で移動する感じです。

ただ、実際やってみるとこれが案外調整が難しくて、デメリットも大きいです。というのは、まず、リキッドレイアウトができません。

なぜかというと、まず、スライダーの長さは一定にしないといけませんから（ブラウザの幅に依存するとスライダーの長さが変わってしまう）スライダーの長さの単位は % ではなく、pxにしないといけません。

そして、この場合スライダ部分もjavascriptでスタイルをいじりつつ動的に動かすことになりますが、スライダーをボタンが動くと、移動した分だけ「ズレ」がでるんですね。このズレはスライダーの長さに関係するため、px単位でのズレになります。

となると、単位をpxに統一しながら微調整をしないといけませんから¹ 、スライダ部分の移動はpx単位で行うことになります。そうすると、それに併せて、本文ボックス・サイドバーボックスもpxで組むことになります。ゆえにリキッドレイアウトができないと。

てわけで、最初の点で妥協したわけですが、これでも十分ですかね。ただ、それよりもこれを他の点で改良することを考えた方がいいかもしれません。

例えば、本文ボックスの幅が広いときは1カラム、そこそこの広さのときは2カラム、かなり狭い場合は3カラムにすると言った具合です。私は1カラム賛成派の人ですが、以前にも言いましたとおり、理想的には最終的な選択はユーザーにゆだねるべきだと思います。

ただ、それは、1カラムなら1カラムなりのメリット、2カラムなら2カラムなりのメリットをきちんと考慮した上で、設置するサイトに各カラムデザインを提供するだけのメリットがあったときの話であって、その必要がないのならば、積極的に1カラムあるいは2カラム、nカラムと絞り込んでいくことも必要だと思いますね。

60%+50pxとかできないので

スライダーで動的に1行の文字数と文字サイズを変更・保存するスクリプト：ウェブログのIA研究(2)

leva — Fri, 10 Aug 2007 07:49:12 +0000

1カラムデザインをもっと柔軟に

サイドバーいらない論では、1カラムのメリットを強調しましたが、その中のはてブコメントで、一段の文字数が短い方が読みやすいから（マルチカラムの方がよい）という意見がありました。

これに対して、私はCSSで最大幅を指定すればいいじゃないと言いましたが、どこか腑に落ちていない点もありました。というのは私が逆に文字数が断然多い方がいいタイプなんですね。

だからmax-widthで最大幅を指定されると、逆に幅が限定されて困るケースがあるんですよ。それにmax-widthで指定された「最適な」最大幅は、あくまで運営者が思っていることで、実際ユーザが最適だと思っているとは限らないんですね。

で、あるならばユーザがCSSを切り替えるように、自分の最適な1行の文字数を決められるのが最適解なんじゃないか、そう思ったんです。

ということで、既にサイト右下の方に実装した通り、1行の文字数と文字サイズをユーザーがスライダーで動的に変更できる仕組みを導入しています。なお、設定された値はCookieに保存していますので、一度設定すれば常時設定した文字数と文字サイズでサイトが表示されるようになります。つまり、サイトのカスタマイズができると言うことです。

やり口としては以下のエントリをかなり参考にしました。というか以下のエントリがなければできていなかったと思います。スクリプト WebFXの作者さんと紹介していたyujiroさん、どうもありがとうございました。

ちなみに今回のスクリプトはこれに以下の機能を追加した物です。

値をCookieに保存する
Cookieが設定されていれば、それをデフォルト値に設定し、幅・サイズ変更を実行する
max-width / font-size プロパティの最小値・最大値の振れ幅を設定する機能
max-width / font-size プロパティを変更する単位を設定する機能

なお、このスクリプトは現状ではIE6以下に対応していません（IE7には対応しています）。理由としては

max-widthプロパティに対応していない
position: fixedに対応していない
幅・サイズ拡大時にボックス幅が内容領域を超えてしまうことがある

ためです。ただ、前2つはjavascriptで同様の機能を実現するfixed.jsやminmax.jsを使えば解決できそうです。

問題なのは1番最後の物で、おそらくIEのバグではないかなと思っているのですが、解決できる方法を探しています。もし、解決法をおわかりの方がいましたら、コメントをお寄せいただければ嬉しいです。

というわけで、現状は以下のブラウザに対応しています。配布物にもIE5,6には出力しないように設定しています。

Windows Internet Explorer（バージョン7.0以上）
Mozilla Firefox
Opera
Safari for Windows

技術的な話

技術的にはスライダーの変更時にjavascriptで動的に本文¹のスタイルを変える方法をとっています。なので、やろうとすれば文字幅・文字サイズだけではなく、行間や背景色なども変えられるでしょう。

当然ですが、このサイトのマークアップに最適化されていますので、導入される際はCSSのID名などは自分のサイトの物に書き換えてください。

なお、当サイトでのマークアップ図をページ末尾に書いてありますので、よければ参考にしてください。

導入について

では、WordPressへの導入方法について。まず、以下のファイルをダウンロードしてください。

ダウンロード: スライダ設定スクリプトセット (v0.1 20070810); スライダー表示PHPスクリプト (v0.1 20070811)
ライセンス: サイト全体と同じくCreative Commonsライセンス、ただしWebFXスクリプトはApache Software Licese 2.0を引き続き適用

更新履歴は先の記事をご覧下さい

ダウンロード後にファイルを解凍したら、「スライダ設定スクリプトセット」をそのままWordPressのトップフォルダにコピーしてください。その後、お使いのテーマに以下の記述を加えてください。

PHPソースコード （wp-content/themes/お使いのテーマ/header.php）

 bloginfo('url'); ?>/wp-includes/images/slider/style.css" />

次にスライダーを動作させるjavascriptを読み込む部分を記述します。まず「スライダー表示PHPスクリプト」をお使いのテーマのフォルダにコピーした後、テーマのの直前に以下の記述を加えてください。

PHPソースコード （wp-content/themes/お使いのテーマ/footer.php）

 include ("module/make_slider.js.php");?>

そして、そのスライダーを表示する部分を記述します。絶対配置しているので、場所はどこでもいいのですが、body開始タグの直後あたりに以下を記述してください。

PHPソースコード （wp-content/themes/お使いのテーマ/header.php）

 include_once ("module/show_slider.inc.php"); ?>

最後にテーマのCSSに以下を記述します。

CSSソースコード （wp-content/themes/お使いのテーマ/layouts/???.css）

/* Slider */
 
.slider{
    opacity:                0.6;
}
 
.slider:hover{
    opacity:                1.0;
}
 
div#slider-1{
    position:            fixed;
    right:                10px;
    bottom:                40px;
}
 
div#slider-2{
    position:            fixed;
    right:                10px;
    bottom:                10px;
}
 
#slider-icon{
    position:            fixed;
    right:                160px;
    bottom:                10px;
}
 
#slider-icon img{
    display:                block;
}

設定は以下のファイルで行います。ここでは最大幅とフォントサイズの単位・振れ幅を設定できます。なお、単位が%以外の際は（つまり基準が100%ではない場合）、基準を設定する必要があるので、必ず入力してください。

PHPソースコード （wp-content/themes/お使いのテーマ/module/make_slider.js/php）

// max-width や font-size の単位
define("unit_width", "em");
define("unit_fontsize", "%");
// unit_xxx が "%"以外の場合は基準となる値を設定
define("default_width", "55");
define("default_fontsize", "");
// max-width や font-size の振れ幅
// ex: [最小] 40% <== $range_fontsize(%) ==> 100% <== $range_fontsize(%) ==> 160% [最大]
// （この場合の range_fontsize は 60）
define("range_width", "25");
define("range_fontsize", "60");

なお、最大幅やフォントサイズの変更に影響されたくない要素（長くなる傾向にあるソースコードやテーブルなど）があれば、スタイルシートで!important命令付きで個別的に指定してください。

導入方法は以上です。

結びに

というソリューションを提案してみたわけですが、いかがでしょうか > 行間が狭い方が読みやすい派の方

ちなみに、マルチカラムでの導入方法はこの次の記事で書きます。このサイトでは、これからも1カラムの理想的なデザインを模索していくつもりです。

スライダーで動的に本文とサイドバーの比率を変更・保存するスクリプト（2カラム版）にて2カラム版を書きました。

なお、この手のスクリプトにありがちですが、空divなどを2つほど生成しています。strict派な人には気になるかもしれませんが、私はアクセシビリティ確保のためには、現状はある程度このようなイレギュラーなマークアップをすることもやむなしと考えています。むろん、このようなマークアップをすることナシにブラウザ側がユニバーサルにコントロールできることが理想的ではありますが。

当スクリプトではdiv#contentの内容。なお、変更時に背景が見えないように親要素に白の背景色を設定しています

サイドバーいらない論：ウェブログのIA研究(1)

leva — Mon, 06 Aug 2007 19:40:18 +0000

タイトル通り、私もいらない論に賛成です。

全幅の20%かそこらの範囲内でやりくりするならまだ許容範囲内で役に立つケースもあるんですが、2カラム・3カラムで40-50%まで領域に取るようなコンテンツが増えてきて、本来のコンテンツである本文が読みにくくなる本末転倒ぽいケースが一般化してると思います。私も最近、そんなこんなでRSSリーダーから外へ出られません。

とりあえずそもそも論って事でサイドバーの存在意義から追ってみましょう。サイドバーが必要な人からすると、サイドバーのメリットはおおむね34点くらいにまとめられそうです。

つまり、過去ログや他のカテゴリなどのリンクをたどることによって、その人の考えを知るきっかけができたり、コメントを追うことができるじゃないかと。

しかし、それはわかるのですが「だからサイドバーなのだ」とはいかないかなと。

その人の考えを知りたいのであれば、個別エントリに関連エントリ（同じカテゴリの人気エントリ）をコメント欄直前あたりに貼ればよいでしょうし、コメントを追いたいのであればコメントのRSS（WordPressでは標準装備）を購読すればいいわけです。

個別エントリが個別的・具体的なものであるなら、サイドバーは全体的・抽象的なものだといえます。個別的な記事だけでなく、サイト全体のも見てもらいたい（運営者の）思いとかもあると思います。しかし、それなら最近人気の記事とかコメントが多く付いた記事とかを専用のページに設ければいいわけで、jintrickさんが言うとおり小さくて見にくいですから、サイドバー・記事双方見にくくなってしまいます。

そういう点からすると、私は個別記事ページでは記事と関連性のあるページを自動リンクするくらいにとどめるべきだと思うし、全体的なところを見せたいのであればそれ専用のページを設ければいい。どちらもいいとこ取りしようと両者を1ページ内に無理に混合しようとすると、かえって閲覧者の肝心のコンテンツに対する印象が薄まったりはしないのでしょうか。

じゃあ、にも関わらず、なぜサイドバーはここまで普及しているんでしょうか？私は2つあると思っていて、

単にそれが慣習的で簡単だから
2カラムの利点を1カラムに持ち込む技術的な策があまり一般的ではない

1はPCに最初から入っている青いeマークのブラウザを使ってますと同じ理由ですね。「問題ないし、みんなもそうしてるから」というもの。

で、2について。そうはいっても長年親しんだ2カラムのメリットは、思い立ったらすぐに全体リンクが一望できて（上に上げた可視化とも似てますが）辿れる部分とかで、これは簡単に捨てきれません。これについてjintrickさんはナビゲーション専用のページにリンクしてリンク先を得意のAjaxとやらで上手に扱えばいいじゃないのと指摘しているんですが、これは確かにその通りで利点を取り込む方法はあるんです。けど、果たしてそこまで技術に習熟しているユーザーがどこまでいるものでしょうか？

2カラムの利点を1カラムに持ち込む事は可能です。サイドバーの情報量は多いでしょうが、selectボックスを使ってページの隅に絶対配置するなり、jigelogさんの下の飛び出るメニューを使うなり、いろいろ方法はあると思います。

ただ、それがあまり一般的ではないために、1カラムは結局「～が足りない」と言われてしまってるんじゃないかなと推測しています。

また、2カラムの利点を持ち込めるだけでなく、1カラム独自のメリットもあると思います。ちょっと箇条書きにしてみましょうか。

図や表、ソースコードが書きやすい: 2カラムだと横長のテーブルや多めのソースコードは書けないケースが増えますから（書けても内容枠をはみ出たりする）、ケースに即した表現の幅が狭まってしまいます。2カラムで如何に大きな表を書くかを考えていたこともありましたが（テーブルを分割するとか）なかなか上手い手段はないんじゃないでしょうか、ありましたら教えていただけると嬉しいです。
モバイル環境にも適している: W-ZERO3やPCサイトビューアなどscreenメディア向けCSSをガンガン読むブラウザが盛んですが、そうしたブラウザにも1カラムは個別コンテンツの可視性がよくモバイルでの利用に比較的適しているんじゃないかなと
回り込みなどで面倒なCSSの処理に煩わされることがない: 過渡期故の悩みですが。ここを○%にするとブラウザの幅を狭めたときにサイドバーがずり落ちてー、とかいちいち考えなくていいので楽ちんです
必要な量のみダウンロードされるのでサーバに優しい: たまに本文の何百倍もの情報量のサイドバーをみかけて苦笑することがありますが、そうした点からするとやりとりされるデータ量を最大限小さくすることができ、サーバの負荷を低くすることができます。
文字を大きめに設定しやすい（普通サイズの文字でもデザインしやすい）: 横方向の領域が狭いと、必然的にその狭い領域に情報を押し込めざるを得ないわけで、どーしても文字を小さくする方向に行っちゃ足りします。ありみかさんと同様、私も本文サイズはそのままがいいよね派なんですが、1カラムだとその辺文字サイズ100%でも無理なくデザインできるんじゃないかと思います。

つーわけで、私が1カラム賛成な理由を書き出してみました。ただ、このネタが「そんなの好き嫌いじゃん」と身も蓋もない結論に陥りがちなのは、やっぱり「最終的にどうするかはユーザーが選択できるべきだよね」という考え方があるからだと思っています。

なので、個人的には1カラム・2カラム..nカラムをユーザーが選べるように（CSS切り替えとかでありがちですが）なるのが理想的な答えだと思います、ただデザイナーの労力はその多様性に比例するんで、なかなかこうした選択の自由が与えられるってのはあんまりないんでしょうね。

これについてはjintrickさんの反論にも書いてありますが、表示幅の最大値を設定すれば解決しますよね。