さて、たまにGoogleで探し物をしている時、昔読んでブックマークした記事に出会って読み返すことがあります。さっきはposition:fixed大嫌い：agendaを読み返していたんですが（内容については一度読んでください）、始め読んだときには、この理由というか補足説明にあるWorld Wide Webはハイパーテキストという概念を応用した「ハイパーテキストアプリケーション」で、ブラウザはハイパーテキストアプリケーションのビューワー。当然ウェブログもハイパーテキストアプリケーションという意味がいまいちつかめませんでした¹ （改めて読んでみたらしっくりきたんですが）。

末尾でも「ページ上部へ移動」とか「スタイルシート切り替え」とか「サイト内検索」とか、本質的にハイパーテキストインスタンスには必要のないものだから。それはブラウザの仕事だとして触れていますが、改めて「ハイパーテキストアプリケーションのビューワ」としてブラウザ側がやるべき領域と「ハイパーテキストアプリケーション」としてのウェブサイトがやるべき領域について考え直さないといけないと思わされました。

ブラウザの役割、ウェブサイトの役割

その各々の役割について考えていた時にInfoperience – ナビゲーションの落とし穴という記事を読みました。ここでは、ナビゲーションをウェブサイト側が担当すると、制作者によるナビゲーションエリアの設計ミスが起こりやすいとしつつ、最後には極論としつつもナビゲーションと内容物を分離するべきではないかと述べています。

ナビゲーションエリアは、ユーザにサイトの基本的な機能を提供するインターフェイスである。しかしそのエリアのデザインを間違えれば、ユーザの操作を不本意に制限してしまうという全く逆の役割を果たしてしまう。

極論から言えば、そもそもコンテンツとナビゲーションを一枚の HTML の中に記述するということ自体が間違っているようにも思えるのである。素のドキュメントとしての価値が下がり、せっかく論理的にマークアップされた文書が、加工・再利用されにくくなってしまう。

また、本来ユーザはサイトの情報構造などというものに興味はない。ユーザは必要な情報を早く見つけたいだけなのであって、すばらしく計算されたサイトの設計などはどうでもよい。ただ便宜上、サイトの構造を理解していれば自分の判断で必要な情報にたどり着けるので、仕方なく全体を把握しようとするだけである。

それと同時に、制作側がどのような順番で情報を見せたいかということもユーザには関係がない。とにかくシンプルな構造にしてさえくれれば、ユーザは好きなようにそれを利用できるのだ。そのためには、ドキュメントは様々なコンテクストや利用方法に耐えられるように、ナビゲーションと内容物を分離するべきである。そして、サイトによって異なる方法で情報構造を示すのではなく、そういった機能は「ブラウザが提供すべき」なのではないだろうか。

Infoperience – ナビゲーションの落とし穴

多様な機器

私はこの意見に賛成です。ブログの普及によってある程度のデファクト・スタンダードができたとはいえ、ナビゲーションの設計が個々人の設計能力に委ねられている以上、その設計ミスにより利用者を迷わせてしまうことは否めません。だとしたら、ウェブページからナビゲーションを分離し、ブラウザの一部として統合・標準化していったらよいのではないかと思います。

そして、その場合のロードマップをこんな感じで考えています。

1. ウェブサイトにおけるナビゲーションの記述方法を仕様として標準化する（HTML5・microformatなどの仕様を活用してなんとかならないか考える）
2. 標準的な仕様・技術が出来ることにより、機械的なナビゲーションの生成（ブログやウェブサイト作成ソフトなど）が行いやすくなる
3. 多くのウェブサイトがその標準に従うようになり、ナビゲーションに関する要素が文書中（埋め込みか参照かはさておき）に記述されるようになる。表示の可否も含め、その表示・動作方法はWebブラウザに委ねられる（後方互換性を考慮し、対応しないWebブラウザのウェブサイト内での表示方法も当面は必要になるでしょう）。

このようにコンテンツとナビゲーションを「分離」、つまり「ハイパーテキストアプリケーション」としてのWebを操作する部分を「ビューワ」であるブラウザ側に委ねていくことで、

• ナビゲーションの一貫性・信頼性が保証できるようになる（サイト毎の一貫性→Web全体での一貫性）
• ナビゲーションが不十分だったサイトにおいても利用者が操作に迷わなくてすむようになる
• “広大な”サイドバーナビゲーション領域が整理され、一画面の本文表示領域が増える
• アクセス環境（PC、携帯端末、プリンター、音声ブラウザ…）や利用者の要求に応じて表示・動作方法を変更（＝最適化）することが出来る

という効果があり、結果として

• ユーザビリティ・アクセシビリティの底上げが図れる
• 機器に依存しないウェブ² へより近づく

ということになります。

「分離」と書いているのは、「コンテンツ」も「ナビゲーション」いずれも一枚の文書中に記述するので分離という言い方はやや不正確かもしれないからと思ったからです。マークアップの観点からは「明確化」と言った方がいいのかもしれません。

ただ、全てのナビゲーションをウェブページから「分離」すればいいわけではなく、サイトイメージの重要な要素である（トップページへのリンクを含む）サイトロゴや、例えばECサイトにおける「買い物かごに入れる」など重要なナビゲーションは、あえてウェブページ中に常時表示させておくことが必要でしょう（特に重要な要素を他のナビゲーションと並列に表示すると、かえってナビゲーションの中に埋没してしまいかねないため）。

「ナビゲーション」とは

さて、「コンテンツ」と「ナビゲーション」と抽象的に書いてきましたが、その「ナビゲーション」は具体的にどういうものを指すのか。本などを参考にしながら、以下のように分類してみました。

モックアップを作る

言葉でいろいろ言っていても伝わらないと思うので、試しにモックアップを作ってみました。なお、このプロトタイプはあくまでも表示の一例であって、実際にはこれと異なった他の表示方法も考えられます（例えばページ分割リンクや関連文書をブラウザ側にではなくコンテンツ直下に表示するなど）のであしからず。

モックアップ例：Apple

今回はAppleのKeyNoteの紹介ページを土台に作ってみました。Appleは割とナビゲーションや構造がしっかり出来ているページですが…

サイト構造をファイラーのように表示してみた例。ページの目次も下部に表示。

サイト構造をデスクトップアプリケーションのメニューバーのような感じに表示してみました。ただ、両者は機能が全く違うので、これも単純に移植するわけにはいきませんが。

ノートPCのページを見たいということで、Appleサイト内を「ノート」で検索。

構造がわかるのであれば、パンくずリストとして表示することも出来るでしょう（現実的にはグローバルナビゲーションなどと両方表示する必要があるでしょう）

分離の恩恵を最も受けるのは、画面領域が限られるモバイル機器かもしれません。ただ、どのように表現するかは工夫が必要ですね。

グローバルナビゲーションは初期状態で展開されているべきと言うことであえて分離していません。ただ、初期状態では小さすぎて構造の把握や移動が難しいので、どうにかしたいは思っています。サイト内検索は検索バーに統合、ウェブ検索と適宜切り替えることができます。

下の目次ボタンか、二本指で左方向にスワイプ（右から左へ指を滑らせる）することで、ページの構造を見ることが出来ます（目次をポップアップさせても良いかも）

視覚化してみましたが、ちょっと微妙かな…

モックアップ例：Liner Note

おまけで当サイト中の記事をでも作ってみました。

記事の一覧は時系列、タグ別、あいうえお順、被ブックマーク数順、被コメント順でそれぞれ表示可能です。スペース的に記事を一覧するというより、前後リンク（コンテキストナビゲーション）の拡張という意味合いで設けました。

サイト内を「サイドバー デザイン」で検索した例

モックとしては作りませんでしたが、その他のUA…例えばプリンターなら印刷用CSSをわざわざ作らなくとも、本文領域だけを印刷することが出来るでしょうし、音声ブラウザはナビゲーションをより効果的に利用することが出来るなどといった効果があるでしょう。

まとめ

繰り返しになりますが、要するにブラウザにサイトナビゲーションを担わせることで、ウェブサイトはハイパーテキストアプリケーションとしての柔軟性・相互運用性を向上できるんじゃないかということが言いたかったのでした。分離まで受け入れられるかは別として（例えばHTML5のように）個々の情報をグローバルスタンダードな意味で明確化して、ブラウザがそれに応じてユーザに適切に提示するくらいの方向性はそろそろ見えてきてほしいと思うところです（上記のナビゲーションは部分的にrel/rev属性で表現可能なわけで、そこから何か始まらないかな）。

その他参考にした記事

• ウェブデザインとは何か（Jintrick Archives）
• サイトのナビゲーションとしてサイドバーを採用すべきでない理由 (agenda)
• 我的春秋: link 要素をナビゲーションに利用することの注意点（改訂）
• link要素覚書
• Webアクセシビリティの未来が見えない（関連記事）

1. Webはハイパーテキストのアプリケーション＝応用、実装例としてのWebという点をど忘れしていたのでしょう‥
2. このような考え方をDevice Independence（機器に依存しない）といいます（神崎さんによる参考情報）
3. この定義だと、ブログパーツやら広告やらはどちらにも属さないのだけど、とりあえずそれはここでは触れないでおく

デモサイト

ダウンロード

cieloテーマ(約1.2MB)

最終更新日

2011年9月13日 08時05分

動作環境

PHP5.2.0以上、WordPress 2.5以上

ライセンス

ライセンスが設定されているリソースはそのライセンスに従ってください。その他は修正BSDライセンスとします

使い方

1. ファイルをダウンロードしたら解凍してください
2. 中に入っている/module/config.phpファイルがテーマの設定ファイルですので、指示に従って設定してください
3. サーバの/wp-content/themes/フォルダに(2)をアップロードしてください
4. サーバの/wp-content/themes/cielo/cache/フォルダを書き込み可能な状態(パーミッションを0777<rwxrwxrwx>)にしてください
5. 必須プラグイン一式をダウンロードし、解凍します
6. サーバの/wp-content/plugins/フォルダに(4)をアップロードしてください
7. 管理画面からプラグインを有効化します
8. 管理画面からテーマを有効化します
9. 記事一覧ページなど特殊なページを作成します。投稿 → ページ から以下のページを作成してください。中身はテンプレートから自動的に読み込まれます
   • ポストスラグ名:webmemoのページを作成。タイトルはご自由に、中身は空でOK
   • ポストスラグ名:archivesのページを作成。タイトルはご自由に、中身は空でOK
   • ポストスラグ名:allのページを作成。タイトルはご自由に、中身は空でOK
   • ポストスラグ名:readmoreのページを作成。タイトルはご自由に、中身は空でOK

特徴

快適に読むための環境

ブログは読者あってこそ。できるだけ多くの人に快適にブログを見てもらえるよう、多すぎず、少なすぎず必要な機能を配置しました

1カラム

本文のレイアウトが崩れにくく、本文を一番読んでもらえる1カラムを採用しました

本文検索機能

並び替え機能、検索結果の自動継ぎ足しをサポート

次の記事へ

関連記事、人気の記事(自動取得&手動設定)で次の記事へ読者を案内します

各種ウェブサービスとの連携

ブログサイトを運営する上で欠かせないネット上のサービスも簡単に利用できます。

Google Analytics

Googleのアクセス解析サービスも設定画面から認証キーを入力すれば利用できます

はてなブックマーク

エントリーページにはてなブックマークへのリンクを自動的に表示します

コメント欄には、はてなブックマークのコメントがシームレスに表示されるよう組み込みました

ウェブメモ機能

twitter, tumblr, はてなブックマーク上での最新の更新をウェブメモコーナーとして表示できます。表示した各記事には、はてなスターをつけることができます(はてなスターのトークンの発行が必要です)

ウェブアプリケーションを簡単に使える内蔵機能

便利なウェブアプリケーションが記事中で簡単に呼び出せます

Googleマップを1行で

住所を指定するだけでその周辺の2D地図や風景を表示できます(Googleマップ APIの発行が必要です)

動画の貼り付けも1行で

動画共有サイト(Youtube, Googleビデオ)上の動画や自作動画をコードを考えることなく簡単に公開できます

モバイルにも対応

もちろん、携帯電話やiPhoneなどのモバイル機器にも対応します

携帯電話にもプラグイン使用で対応

餅は餅屋…ということで動きの速い携帯電話向けの最適化はKtai Styleを使うことで対応することにしました

iPhone / iPod touchに標準対応

ビジュアルデザインはiPhoneのSafariでも読みやすくなるよう最適化しています

呼び出した動画や地図は、iPhone / iPod touch内蔵アプリでも再生できるように工夫しています

その他にも

XHTML1.1 + CSSで書いています

Web標準に準拠した、できるだけシンプルな文書構造を心がけました。現在使われているほとんどのウェブブラウザに対応しています。

SEOにも配慮

metaタグの自動生成、XHTMLでの構造化、わかりやすいページタイトルとテーマ側で出来ることはやっておきました。

間違ってると思ったらすぐ編集

ログインしている間は記事画面からワンクリックで編集画面に移動できます。

エフェクトでおめかし

あれこれポップアップ(リンク先・引用元のタイトルなどをちょっとリッチにポップアップするスクリプト)やjQuery lightbox プラグイン(写真のポップアップをエフェクトを付けて表示するスクリプト)を標準で導入しています

ページ毎のCSSデザインも簡単に

Sandbox テーマは主要な要素に現在の状態を示すクラス名をつける機能がありますが、cieloはこの機能を取り込んでいます

ダウンロードは高速に

一部のファイルをGZIPという形式で圧縮しており、サーバとブラウザが対応していれば落とすファイルサイズが小さくなり、高速にページが表示できるようになります(方法)

続き物の記事はまとめよう

記事は独立したものだけではなく、何回かに分けて書いた続き物の記事もあるでしょう。cieloテーマではそうした記事を半自動的にまとめあげ、シリーズのRSSフィードを発行することも出来ます(方法)

サポートしないもの

このテーマは次の機能をサポートしません

• 可変1カラムデザイン以外の表示方法
• コメント欄でのアバターの表示
• UTF-8以外の文字コードでの運用

導入を推奨するプラグイン

依存しているプラグイン

推奨というより、このプラグインを入れていないと動かないので必ず入れておいてください

ダウンロード

必須プラグイン一式をダウンロード

ライセンス

GNU General Public License

runPHP

記事中でPHPコードを使うプラグインです。内蔵の動画共有サイトのコード呼び出し機能などを使ったり、記事一覧ページ中で記述しているPHPコードを実行するのに必要です。「ビジュアルリッチエディタ」「XHTML 構文の自動修正」とは同時使用できないようですが、同種のプラグインは多くあるようなのでそちらを使っていただいても構いません。

Similar Posts

関連記事を表示させるためのプラグイン

Post-Plugin Library

上記プラグインを利用するために必要なプラグイン。これを利用したプラグインとして、上記意外にも人気記事を表示するPopular Postsなどがあるので、余裕があれば試してみては。

入れたら便利なプラグイン

入れなくても良いけど、実害はあまりないし便利なので入れておくことをオススメするプラグインです。

WP-Footnotes

本文中に((脚注の内容))と書くだけで脚注を生成してくれるプラグインです、ちょっとした余談で話の腰を折らずにすみます

Table of Contents Generator

本文中に<!--TOC--%gt;と書くだけで見出しを拾って、目次を生成してくれるプラグインです、長めの記事を書くときは読者のことを考えてできるだけ使った方がよいでしょう

Amazon Linkage

本文中に<amazon>ASIN</amazon>と書くだけで(ワンパターンですいません)、ジャケット画像付きでAmazonへのリンクを貼れるプラグインです。

Ktai Style

携帯電話のアクセス時にコンテンツを読みやすいように最適化してくれるプラグインです。

スパム防止に役立つプラグイン

入れておくと、スパム対策にてきめんの効果を発揮するプラグインです

SOMY SpamBlock JP スパム対策プラグイン

コメントやトラックバックの内容にひらがなやカタカナが指定回数以上ない場合、該当のコメント等をスパム扱いするか、あるいは削除してくれるプラグインです。このプラグインを使って以来、半年に一回スパムが来るか来ないかという程度になりました。セキュリティ上の懸念が残るとご指摘を頂きました（今すぐに危険なわけではないようですが）。利用にあたっては、

Simple Trackback Validation

トラックバックが指定した条件に沿っていない場合、スパム扱いするか削除できるプラグインです。トラックバックポリシーにも書いてありますが、記事のURLを含まないトラックバックは拒否するようにしています。

仕様・技術情報

デモサイトにて技術情報を公開しています。

• cieloテーマで使えるHTMLコードの一覧
• cieloテーマ内蔵機能について
• cieloテーマのXHTML構造について
• cieloテーマのその他よくある質問

謝辞 & 著作権表記

このテーマは以下のリソースが無ければできていません。オープンなライセンスでいいものづくりをしてくれた皆さんに感謝。We’re standing on the shoulders of Giants!(お名前の敬称は略しています)

Javascriptライブラリ

jQuery by John Resig and the jQuery Team(GPL & MIT License)

jQuery lightbox plugin(クリエイティブコモンズ 2.5 ブラジル 表示・改変禁止)

WebFX by Erik Arvidsson & Emil A Eklund(Apache Software License 2.0)

あれこれポップアップ by ありみかさとみ(BSD License)

IE PNG Fix by Angus Turnbull(GNU LGPL)

Whatever:hover by Peter Nederiof(GNU LGPL)

アイコン

famfamfam.com: Silk Icons by Mark James(クリエイティブコモンズ 2.5 表示)

AeroVista for Mac by Mayosoft(クリエイティブコモンズ 3.0 表示・非営利・改変禁止)

Aqua Blend Icons by Laurent Baumann(クリエイティブコモンズ 3.0 表示・非営利・継承)

McDo DESIGN – Icons by Susumu Yoshida(クリエイティブコモンズ 2.5 日本 表示・改変禁止)

Flashプレイヤー

JW FLV Media Player by Jeroen Wijering(クリエイティブコモンズ 3.0 表示・非営利・継承)

WordPressテーマ

Sandbox by Scott Allan Wallick(GNU GPL)

ライセンスとかあまり関係ないけどこちらの方々にも感謝。

• 株式会社はてな(はてなブックマークAPIの提供元)
• WordPress開発者の皆さん

更新履歴

4839929548

CSS Variables と CSS の未来 : could

「CSSの未来」がどうあったらよいかと言って浮かぶのは、CSSそれ自体の進化ではなく、CSSをどう管理するかという部分の進化ですね。

ブラウザにおける CSS の解釈の違いを理解するのも CSS を学習する上で大変な部分ではありますが、CSS の基礎を学ぶのも今は何とも難しいなという気がします。先に紹介したセレクタもそうですし、属性も様々。もちろん、ひとつのプログラミング言語を覚えるのに比べたら簡単でしょうけど、初心者が中級者への道筋が険しいものになっているような気がします。

CSS Variables と CSS の未来 : could

表現力の向上やシンプルな記述の支援という観点から、CSS3セレクタやCSS Variablesなどの仕様自体の進化は確かに喜ばしいことですが、一方で上記のような危惧を考えると入門者でも（そして熟練者でも）楽に記述・管理ができていくようになるのが望ましいかと思います。そして、これは仕様それ自体ではなく、それを扱うツールが担う領域です。

例えば、以下のような機能は考えられないでしょうか。

• 実現したい表示方法を自然文で入力すると、それを実現するプロパティを支持してくれる機能
• HTMLのプレゼンテーション要素・属性を入力すると、同様の記述がどういったCSS記述で可能なのか教えてくれる機能
• ある書き方や要素の組み合わせがあった場合に特定のブラウザで意図に反した結果¹ になることを告知する機能
• CSSのコードを分類（フォルダ分け）できる機能（フレームワーク、一般、ヘッダ、本文、フッタなど）
• 現在使っているプロパティがどのブラウザで有効か示してくれる機能
• CSSテンプレートサイトからレイアウトや見出し・引用などの表示の仕方などテンプレートとなっているお決まりのCSSコードの組み合わせをダウンロードし、ソフトウェア上から1クリックで適用する機能
• 色彩の組み合わせなど、アクセシビリティの標準仕様と照合して、問題のある記述を告知する機能
• 同様の指定がある場合にCSS Variablesを使って自動整形する機能

もっとも、CSSの管理に長けたソフトウェアをあまり知らないので、「それ○○でできるよ」ということがあるなら教えていただければなと。MacRabbitのCSSEditというソフトウェアは便利そうですね。ここで挙げた機能も一部実装されているようです。

1. 有名どころではInternet Explorer 6 の 擬似要素名称の直後に空白類文字を置かないと擬似要素が認識されないバグ

1. 辞書サービスで知らない単語を調べる（問題：単語の意味が不明）
2. オンライン書店で気になっている本を買う（問題：本を読むために手に入れたい）
3. 鉄道会社のサイトで目的地まで鉄道やバスが通っているか路線図を見て調べる（問題：目的地まで電車・バスを使って移動したい）

などといったことだったりするでしょう。そして、サービス提供する者（ここではサイト運営者）としてここで一番大切なことは、そうしたユーザの要求に簡単にお手上げしてはいけないということです。なぜなら、それがユーザにとって自分のサイトが役立たずだったと宣言するようなことだからです。

ですから、ユーザ要求を自分達の持つリソースで解決できないのであれば、同業者へ橋渡ししてあげることも積極的に考慮すべきでしょう。先の例で言えば、

1. 「該当の単語は見つかりませんでした、キーワードを変えてください」と表示するかわりに、他の辞書サービスにディープリンクする
2. 「該当の本は現在品切れ中です、しばらくお待ちください」と表示するかわりに、他のオンライン書店や図書館蔵書検索ページへディープリンクする
3. 自分の鉄道だけでなく、他者の鉄道路線も併せて表示する

という配慮が必要だと思います。

利用者は何も、その辞書サービスを使いに来たわけでも、そのオンライン書店を使いに来たわけでも、○○バスに乗りたいわけでもなく、単にその問題を解決したかっただけです。あくまで「誰が」解決するべきではなく、「何を」解決するべきなのかを意識しないといけないのではないかなと。ですから、ただ第三者の便利なサービスを待つのではなく、まず自分たちがその要求、その期待に応えようとすることが大事だと思います。

もちろん、他者に橋渡しする以前として自分たちのリソースをフルに活用する、活用できるようなサービスを展開するということは前提です。例えばAmazonは、新品だけでなく中古商品（マーケットプレイス）も併記することで、万一の在庫切れの際もできるだけユーザの期待を裏切らないようなサービス展開をしています。で、それでも解決できないようであればということを言っているわけです。

さてさて、などと言うと「行為それ自体としての正しさとビジネス上の正しさは違う」、つまり他社へ水を送るような事をやっていては市場経済で生き残れないよと批判されるかもしれませんが、まず誰に利益が行くかということよりもユーザの期待に応えて満足度を高めることを考えるべきだと思います。

サービス運営者が持つ資源が有限である以上、それで解決できる要求が限られてしまうのは致し方ないことですから（繰り返して言いますが）その資源でできるだけ多くの要求に応えられるようにデザインした上で、それでも無理だった場合に他者に解決してもらうことも一緒に考えないといけないでしょう。つまり、誰に利益が行くかではなく、お客さんの問題解決という期待に応えられるかどうかの方が重要なわけです。

市場競争ではどうしても縄張り主義的に自分が出来ないことは知りませんよと言ってしまいがちですが、そこでお互いの渡り口を用意しておくことが各サービスの満足度、ひいてはその業界の満足度の向上につながるのではと思っています。

とはいえ、業界内で圧倒的なスケールメリットを持つ先行者がいて、かつ自分たちが何かに特化しているわけでもなく、その先行者と違っている特長があるわけでもない場合¹ は、最終的にそちらに依存している状況でしかないわけですから、そもそもそのままではサービスが長続きしないんじゃないかという意味から、この戦略を執るのは難しいと思います。その時はどうスケールを拡大すべきかとか、どう差別化すべきかとかをまず考えた方が良いでしょう。

さて、長い前振りみたいですが、これをふまえて試しにこのサイト内検索に結果が得られない場合に、同検索語でGoogle検索した結果を併記してみることにしました。これで解決できないこともあるでしょうけど、やらないよりかはだいぶマシかなと。もちろん、サイト内検索自体の精度も何とかしないといけませんけどね。

ところで前に提案した図書館と他書店・図書館・ウェブサービスとの連携案なんかもこの文脈で言っていたことですね。ちなみにこちらのプロジェクトは今も継続中です。

1. 例えばビッダーズが検索結果にマッチする出品がない時にヤフーオークションの検索結果を表示したらそう思ってしまいます

例えば、引用文を引用文ぽくスタイリングしたいとする、こんな感じに。

で、とりあえずGoogle先生で調べてから頭を回してみるわけですが、

• Natalie Downe » Blog Archive » Inline image quotes
• CSSで引用をデザインする。 – DesignWalker
• 第12回：引用（blockquote）をCSSと画像でそれらしく見せる方法 ::: creazy photograph
• イメージ無しのblockquoteで引用を表示するCSSサンプル – WEBデザイン BLOG

たいていは、幅固定だったり、blockquoteタグの中で使えるタグの種類や数が限られていたり、不自然な空要素があったりするわけです。要するにIE6などの後方互換性対策ですよね。こういうのは引用だけではなく、いろんなCSSスタイリングの方法論で見られます。

で、これはストリクタの戯言と言うのではなくて、なんだかスタイリングのために変な制限をかけたり、不自然なマークアップをしたりするのが、どうも機械の都合に併せて人間が動いているように思えて釈然としない気持ちになるのですね。

ちなみに私ならこう書きます。

CSSソースコード

blockquote{
  width: 70%;
  background: white url("blockquote_mark_end.png") right bottom no-repeat;
  padding: 15px;
  margin: 15px;
}
 
blockquote > *:first-child{
  background: transparent url("blockquote_mark_start.png") left top no-repeat;
}
 
blockquote p.citation{
  text-align: right;
}

これで以下のすっきりとしたコードでも、きちんとスタイリングできます（引用符のサイズが大きいため、今回は p.citation に背景画像はつけませんでした）

HTMLソースコード

<blockquote>
<dl>
<dt>引用タイトル</dt>
<dd><p>あのイーハトーヴォのすきとおった風、<br />
夏でも底に冷たさをもつ青いそら、<br />
うつくしい森で飾られたモリーオ市、<br />
郊外のぎらぎらひかる草の波。 </p></dd>
</dl>
<p class="citation"><cite>宮沢賢治氏の小説より</cite></p>
</blockquote>

引用タイトル

あのイーハトーヴォのすきとおった風、
夏でも底に冷たさをもつ青いそら、
うつくしい森で飾られたモリーオ市、
郊外のぎらぎらひかる草の波。

宮沢賢治氏の小説より

しかし、WinIE6はfirst-child擬似要素に対応していませんので、以下のように補正CSSを追加します。これでWinIE6は点線で囲まれた感じで引用を表現することになります。

CSSソースコード

blockquote{
  background: white none;
  border: 1px dotted gray;
}

このように必ずしも全てのブラウザに同じスタイリングを提供する必要はないだろうし、むしろCSSの実装レベルに応じて（実装レベルが低いものはそれなりに、高いものはそれを活かして）積極的に見せ方を変えていってもよいのではないでしょうか。

既にこのサイトはWinIE6の実装レベルやバグも考慮して（文章の読解に影響を与えない程度で）、スタイリングをWinIE6とそれ以外で区別するようにしてきました。

空要素を意識して作ったり、妙な制限に縛られたりするよりも、実装レベルに応じたスタイリングをする方が後方互換性に必要以上に引きづられることもないですし、何より楽だと思うのですがどうですかね。

You can write a document as simple as you like.
In many ways, the simpler the better.

Tim Berners-Lee

はてなブックマークでの反応に対するお答え

ブラウザに応じてとか基本的に邪魔にしか思えないからなあ。ま、どっちみち一部の受け手は発信側のページのソースをザクザクに切り刻んでスクラップにしてブラウジングするけどね。

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

邪魔にしか思えないというのはどうしてですかね。やはり違うブラウザで見たときに違う見た目になって、そのたびに考えないといけないからでしょうか。であるならば、ちょくちょくブラウザを変えて同じサイトをみることってほとんど無いですし、大きく操作に影響するほどでなければよいと思っているのですが、どうでしょう。

blockquoteの中にタイトルとか.citationとか、メタ情報を入れるのはinvalidな気がするんだ。dlで整形してるのもアウトだと思う。

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

本筋とは別の話ではあるんですがコメント、議論参照先はこのへん。

• 『blockquote要素の中に出典を示すcite要素を包含すべきか』に関する議論リンク集 @ CD
  • ねこめしにっき（2001年4月下旬）
  • 強調,引用,グループ化,画像などの要素 — ごく簡単なHTMLの説明
• 引用元の表示と表記の改変に関する議論 – 徒委記

blockquote内は引用内容のみ入れるべきで、メタ情報は入れるべきではないと言うことですかね。私はこれについては議論はあって賛否両論あるけれども、少なくともXHTML仕様的にはinvalidではないと思っていたんですが。どっちかというと言語文法的にinvalidということですかね。それならわかります（引用タイトルを混ぜたのは確かにまずかったと思います）

UAが対応してくれるのなら、できればblockquote要素のcite属性およびtitle属性のみですませるのが一番良いのですが、それは現状できませんので（かといって、javascriptを動員するのは大げさな気がしますし）。

リテラシの低いお客さんはそれだと納得してくれません。/ 分からない人はどんな説明しても分からないからなぁ / ブラウザによって見た目変えるのはいいけど、個人的にはその辺どうすんの？とか思った。

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

仕事だったら、jQueryとかのjavascriptライブラリを使ってでも、無理矢理同じ見た目にすると思います。ただ、仕事以外ならあんまり取りたくない面倒くさい手なので、今回は修正CSS使って対処しとこうよという風に書いたのです。

プロの人はたいへんだ。

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

いちいち修正CSS書いたりするんだったら、ちょっとぐらい変なマークアップするよ的な意見（だと読み取ったんですが）も想定してました。僕はちょっと修正CSSを書いた方が変なマークアップ繰り返すより楽かなと思ったんですよね。まぁ、提案であって押しつける気はないんでまた機会があったら考えてみてください。

言及されました、クロスブラウザ対応は運営者が楽な方法で、なるべく多くの環境に適応できるといいですね ::: creazy photographという記事もあわせてどうぞ。

レイアウト名	固定レイアウト (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. 横幅に応じて自動的に段組をくむようにして、閲覧者のブラウザスペースを有効活用するようにした（現在は中止しています）
3. ユーザが表示部分を微調整できるように、スライダーで動的に1行の文字数と文字サイズを変更できるようにした

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

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

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

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

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

考え中の私案

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

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

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

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

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

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

特に自動調整無し

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

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

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

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

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

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

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

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

• COULD：固定か可変かそれが問題だ
• ウノウラボ Unoh Labs: エラスティック・レイアウトのご紹介

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

1. サイドバーの役割ってなんだ？
2. 具体的に何を載せるのか
   1. 注釈や附記など本文の補足となる文章
   2. イメージ画像など本文を読解するための助けになるもの
   3. 参考となるページへのミニリンク集
   4. 参考文献へのリンク
   5. 本文全体の目次など全体を俯瞰できるツール

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

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

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

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

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

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

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

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

具体的に何を載せるのか

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

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

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

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

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

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

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

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

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

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

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

参考文献へのリンク

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

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

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

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

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

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

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

感性満足を開発する「ユーザビリティ・エンジニア」 / Tech総研

ユーザビリティ・エンジニアが注目職種として取り上げられています。

野村総合研究所：Webシステムにおけるユーザ中心設計手法への取り組み（PDF注意）

NRI 上級コンサルタントによるレポート。内容はやや硬いですが、系統的にとりあえず一通りを知りたいという人はまず読んでみるといいかと思います。

実践！Webユーザビリティ研究室

Webユーザビリティを丁寧かつ懇切に解説してくれている連載記事です。ユーザテストの方法論などを手軽に知ることが出来ます。

北海道教育大学 卒業論文：Web ユーザビリティ その解釈の歴史と評価方法（PDF注意）

実質4ページしかないので、ちょっと概観するにしても軽すぎるかもしれませんが、多すぎて読めない！という人はこちらで。

ユーザビリティ – Wikipedia

そもそもユーザビリティって何だ？って思っていて、ちょっと詳しく知っておきたいと思っている人へ。ニールセン博士の考えておられるユーザビリティ、あるいはISO 9241-11やISO 13407で捉えているユーザビリティ概念の違いがよくわかります。日立にある黒須教授のコラムも併読するといいんじゃないでしょうか。

実践！Webマーケティング：Blog | メソッド | ミツエーリンクス

ウェブユーザビリティを追求することは、ユーザを知ることなくしては成立しませんから、ウェブマーケティングはユーザビリティの追求に不可欠です。このサイトの特集ではマーケティングを含めた幅広いカテゴリの記事を掲載しています。

DESIGN IT! w/LOVEさんのエントリ

参考になるエントリーはいろいろありますが、ここではユーザ中心設計手法の考え方とその具体的手法を示した実践的なエントリーをピックアップしておきます。

• 人間中心のデザイン（Human Centered Design）：人間の性質にあわせるデザインのアプローチ
• ISO13407：人間中心設計
• 人間中心設計（Human Centered Design＝HCD）で使う主な手法
  1. コンテキスト調査
     • コンテキスチュアル・インクワイアリー（文脈的質問）がむずかしい対象
     • ユーザビリティ・エンジニアリングにおける師匠と弟子
  2. ペルソナ/シナリオ法
     • ペルソナ：誰のために何をデザインするかを明示する手法
     • ペルソナ／シナリオ法をいかにデザインに活用するか
     • 物語風のシナリオを描くことでユーザーの利用状況を明確にする
  3. プロトタイピング
     • プロトタイピングとしてのワークショップ
  4. デザイン・ルールを用いる際の注意
  5. ユーザテスト
     • ユーザーテストはこうやります
     • ユーザーテストをやることがユーザビリティだと思ったら大間違い

慶應義塾SFC GC：人間環境整合論 第4回 人間と調和した環境設計の方法

慶應SFCが無料で公開している講義の一篇です。講義担当者はエルゴノミクス（人間工学）について研究されている方のようです。

アップル ヒューマンインタフェースガイドライン

アップル社が自社のOS上で動作するソフトウェアをデザインするにあたって守って欲しいことを記した開発者向けガイドライン。Mac OS Xオンリーな部分もありますが、大部分はウェブデザインの話などとも読み替えられる点が多いです。ちなみに上記リンクは有志による日本語訳で原文はアップル社のサイトからダウンロードできます（ちなみにOS 10.4 Tiger発売後に章の追加や内容のアップデートが加えられています）

Jakob Nielsen博士のAlertbox

ユーザビリティ業界の重鎮、ニールセン博士のコラム。ちなみに、本になってます。

黒須教授のUser Engineering Lecture

こちらも日本では重鎮の黒須博士のコラム。黒須先生はユーザビリティ関連の多くの著書を書かれています。

Web担当者Forum：ユーザビリティ関連の記事

複数の会社のWeb担当者が書いておられるので、SEO・ペルソナ・ウェブマーケティングなど様々な話題を拾うのに便利だと思います。

先のエントリで挙げたビービットもいろいろ情報を出しているようですので、まとめて載せておきます。

ユーザビリティコラム：ビービット

ユーザビリティを考えるにあたって参考になる考え方を様々な視点から考察しています。分量もコンパクトで読みやすいです。

ユーザビリティ実践メモ：ビービット

こちらは上記に比べ個別具体的な話で、より実践にフォーカスをおいています。

プレジデントビジョン インタビュー：株式会社ビービット 代表取締役　遠藤直紀氏『 確実に社会に大きな変化がきている 』

先ほどのエントリで挙げたビービット社の社長のインタビュー、なぜユーザビリティが必要とされているのか、どのようにして確保してけばいいのかみたいなことをとりあえず知りたい人は読むといいでしょう。まぁ、インタビューですから個人的な話も入ってきますけど面白いですしいいでしょう。

UNIVERSAL INTERVIEW～フューチャリスティックなITパーソン～

上記会社の人のインタビュー on PodCast。長さは上下合わせて43分ほどなんで、通勤・通学の往復で聴ける量です。若干、インタビュアーの無茶振りが入ってる感じも。

とりあえず以上です。これも載せておくといいよってのがあったら、こちらのWikiに追加してみてください。

周りが落ち着いたら、この辺で書いてあることをまとめて書いておこうと思います¹ 。

ちなみに、私も内容を完璧に理解できているわけではありませんので誤解しているところがあるかもしれません。フィードバックは歓迎しますので、間違いがあればレスポンス頂けるとうれしいです。

ユーザビリティエンジニアリング

978-4274201448

一冊目はこちら。ユーザビリティについて基礎から学びたいという人には、この本が一番オススメです。ウェブユーザビリティに関する概説書といっていいでしょう。

そもそも「ユーザビリティとは何なのか」から始まり、そのユーザビリティを確保するための「ユーザ中心設計手法」の紹介へと向かい、そしてその方法について「調査・評価および実践」までを200ページ弱でコンパクトに、しかしきっちりと解説してくれています。ユーザビリティに関するありがちな誤解もこれを読めば解消できるでしょう。

内容も平易でとっつきやすく、ゆっくり読んでも3日ほどで読めるんじゃないでしょうか。まず、ユーザビリティについて一遍の知識を手に入れたいのでしたら、これから読むといいでしょう。

著者のサイトでは、この本の5章のうちの1章がお試しとして無料配布されていて、なんとも良心的です。

ユーザ中心ウェブサイト戦略

978-4797333527

ウェブユーザビリティに関してのコンサルティングおよび制作業務を行っているビービット社の中の人が書いた本。

一言で言うと緻密。日本でもユーザビリティを軸にコンサルティングを行っている会社は数少ないですが、それだけあってさすがに中身が濃く、タイトルの示すとおり戦略にまで昇華されているという印象です。

最初の本を読んで、もっと○○について詳しく知りたいとか、どのようにして業務に取り入れていけばいいのかということを知りたい人にお勧めです（逆に手間暇かけずユーザビリティを「改良」できないかなという程度であれば、本書はちょっと詳しすぎるので他の本の方がよいかもしれません）

ちなみに本書は理論編と実践編の2部構成になっていますが、もしある程度の知識があおりでしたら実践編から読んでいってもいいと思います。

発想する会社!

978-4152084262

アメリカでプロダクト・デザインを手がけているIDEOという会社が、どのようにイノベーティブな製品を生み出すのかまとめた本。

上記2冊は「どうデザインしていくか」という方法論や考え方が主に書かれていますが、こちらは「どのようにしてすばらしいデザインができる環境を作っているのか」という環境つまり組織・集団のマネージメントの話をメインにして書かれています。

ですので、ウェブユーザビリティそのものとは少しずれてしまうかもしれませんが、デザインという作業を含めたプロセス全体を考える際には読んでおいて損はないです。それに、3章の「イノベーションは見ることから始まる」で触れられているヒューマン・ファクターという手法はユーザ中心設計手法とかなり重なってくるものです。

「法則」本 2冊

978-4844324232

978-4798112565

挙げておいてなんですが、上記3冊は考え方としては確かに非常に参考になるのだけど、中小規模のウェブページを趣味で作っている方からすると「ハードルが高いな」と思われるかもしれません。

ユーザビリティテストは協力者がいないとできませんし、ユーザの行動シナリオを作るというのも考え方としては役に立っても、実際やってみるのはノウハウや経験が必要で難しいです（だからこそ上記のような本や会社があるわけですが）

ですから、とりあえずここはおさえておこうよという点をピックアップした上記の法則シリーズ(?)² 2冊をオススメしておきます。

絵も多彩に用いられていて読みやすいですし、法則単位で短く分かれていてサラッと読ませる感じになっているので、そこまでリソースは割けないけどという方はこれらを読んでみるといいでしょう。

ところで、ユニバーサルデザインの概念はユーザビリティとは異なるもの（どちらかというとアクセシビリティに近い）なのですが、この分野に興味をもつきっかけとしてはよいかなと思って挙げてみました。

あとがき

ペーパープロトタイピング本やペルソナ本も結構オススメなんですが、ちょっと各論に入ってるかなという感じもあるし、初～中級者向けなら上記がいいかなと思って、今回は外しました。

ところで、日本では世にあふれている「ユーザビリティ本」はいわゆるヒューリスティック、つまりプロによる一般論をまとめたものが多いという印象があります。

しかし、高齢化・ユーザインタフェースの進化などの環境の変化（とその速度）を考慮すると、そうした本はお手軽ではあるけれど、陳腐化しやすい点も多いのではないかと思います（そうした本が全て陳腐であると極論を言っているわけではありません）

こうしたユーザ中心設計手法やその考え方を身につけていくことで、みなさんが自分自身でウェブユーザビリティを考える一助になればなと思います（ちょっと偉そう）

1. もちろん、それをしてくれている先達はいらっしゃるのですが
2. といっても出版社は違うので、法則つながりは偶然なのですが

スクレイピング結果の表示はHTMLとXMLとRSS 2.0に対応しています。動作させるにはPEAR::HTTP Clientが必要です。

表示サンプル

PHPをGoogleで検索した結果（HTML）

PHPをGoogleで検索した結果（XML）

PHPをGoogleで検索した結果（RSS 2.0）

サンプルではGoogleの検索結果のタイトルと説明を拾って表示する処理をしています。コントローラー部分はこんな感じ。

PHPソースコード

<?php
require_once "HTTP/Client.php";
require_once "scraper.Class.php";
 
// インスタンスを生成
$scraper = new WebScraper("http://www.google.co.jp/search?q=", "UTF-8");
 
// キーワードが入力されている場合はゲット
if (!empty($_GET["q"])){
  
  // XMLに変換して格納
  $scraper->retrieve();
  // 要素を抽出して、変数に代入
  $titles = $scraper->pickUpElement('//a[@class="l"]');
  $links  = $scraper->pickUpElement('//a[@class="l"]/@href');
  $descs  = $scraper->pickUpElement('//div[@class="std"]');
  $count  = count($titles);
  // キーワードをUTF-8に戻す
  $scraper->keyword = $scraper->convertKeyword();
  
}
 
switch ($_GET["type"]){
  case "html": require("template.html.php"); break;
  case "xml" : require("template.xml.php");  break;
  case "rss" : require("template.rss.php");  break;
  default    : require("template.html.php"); break;
}
 
?>

スクレイピングするURLは動的なもの（検索語などクエリが混ざっているもの）と静的なものに分かれると思います。このライブラリでは、動的なURLの場合にフォームから検索できるようにするため、これらを別々に処理しています。

// インスタンスを生成
$scraper = new WebScraper("http://www.google.co.jp/search?q=", "UTF-8");

今回はGoogleに検索語を投げる処理なので、動的なURLにあたります。もし、静的なURLであれば、インスタンスを生成する際の3番目の引数にtrueを指定してください。

インスタンスを生成する際に、検索語を投げるURL（もしくは静的なURL）とその文字エンコーディングを指定します。

// XMLに変換して格納（その際に不必要なタグを除去）
$scraper->retrieve("<\/?b>");

指定されたURLをゲットしてSimpleXML Objectに変換します。

以下の手順は、バージョンアップにより不要になりました。

その際、タグがネストしているとうまくいかない場合があるので、不必要な要素を消去します。

たとえば、<a href="http://example.com">あれこれ<em>に加えて</em>どれこれ</a>というコードだとa要素の中身を指定しても、あれこれどれこれという風に、em要素の中身がすっ飛んでしまうため、em要素を消しておく必要があります。

よって、ここでHTMLから消去する要素を正規表現で指定しておきます。

// 要素を抽出して、変数に代入
$titles = $scraper->pickUpElement('//a[@class="l"]');
$links  = $scraper->pickUpElement('//a[@class="l"]/@href');
$descs  = $scraper->pickUpElement('//div[@class="std"]');
$count  = count($titles);

さきほど、ゲットしたXMLからゲットしたい部分を抽出して変数に格納します。抽出する部分はXPath式で指定してください。ゲットに成功していれば、文字列が配列で格納されます（CSSはわかるけど、XPathシラネって人はLatest topics > CSS3セレクタとXPathでの表現の対応表 – outsider reflexを参照してみてください）。

格納された文字列は、ビュー部分でたとえば以下のように出力します（例はHTML）

PHPソースコード

<?php
  
  // 設定に失敗していたら離脱
  if ($scraper->isError() != false){
    
    $scraper->isError();
    
  } else{
    
    for ($i=0; $i<$count; $i++){
      $msg .= "<dt>".$titles[$i]."</dt>";
      $msg .= "<dd>".$descs[$i]."</dd>";
    }
    
    echo "<dl>". $msg ."</dl>";
    
  }
?>

PHPフレームワーク（rhacoとか）にはスクレイピングライブラリがくっついているし、マイナーだけどSNOOPYというスクレイピングライブラリもありますから、車輪の再発明には違いないんですけどね。perlやrubyみたいにもうちょっとこの手のライブラリが充実していってほしいもんです。

ダウンロード

ダウンロード

汎用スクレイピングライブラリ

ライセンス

修正BSDライセンス

HTMLParser.Class.php, xhtml1-transitional_dtd.inc.php, XMLフォルダ以下のファイルについてはGNU LGPLライセンス

更新履歴

既知の問題点

POSTで取得するリソースを取得できない

実装自体は簡単ですが、どう実装するかという話です。あんまりオプションを増やしたくないので

認証がかかったりソースを取得できない

これも上記に同じ。このニーズも大きいと思います。

参考にしたURL

• PHP5、未整形HTMLをSimpleXMLへ変換 – goungoun技術系雑記帳

Phizeさんがこのスクリプトも含めてPHPのスクレイピングに役立つライブラリをまとめてくださっています。このスクリプトでできないこともありますので、参考にしてください。