ライブラリ

前回「次世代Web 7つのポイント」という記事で述べましたが、いくら「IE6の葬式」が行われたとはいえ、(現段階では)最低限の見栄えは確保する必要があります。HTML5の実装を進めているというIE9の実態は謎に包まれており、IE6～IE8は言わずもがな対応していません。このような状況化で、最低限の見栄えを確保するということはHTML5で追加されたセマンティックな要素が使用できず、結局のところ現実的な妥協案にせざる終えなくなります。そこで私が目をつけたのが改訂版JISで明示された『依存しているウェブコンテンツ技術』という章です。簡単に言えば、利用者が(JSやFLASHなど)特定の技術を有効にしていることを前提にして制作をしてもよいというものです。ただし「依存している」とするには『アクセシビリティ・サポーテッド』を満たしている必要があります。

アクセシビリティ・サポーテッドとは、作成したコンテンツが標準仕様に沿っていて、利用するユーザーがアクセシブルに利用できるかということを指します。これは単にJISに適合していれば良いという話ではなく、コンテンツ側の実装技術とユーザーエージェント/支援技術側の折り合いをつけるという部分が強調されています。

技術をアクセシビリティ・サポーテッドな方法で用いるというのは、支援技術（AT）および OS、ブラウザ、その他のユーザエージェントのアクセシビリティ機能と連携するということを意味する。技術は、アクセシビリティ・サポーテッドな方法で用いられている場合のみ、WCAG 2.0 の達成基準を満たすために依存することが可能である。ただし、何らかの達成基準を満たすために用いられていない（つまり、同じ情報あるいは機能が、アクセシビリティ・サポーテッドな他の方法でも利用可能である）かぎり、その技術をアクセシビリティ・サポーテッドではない（支援技術などと連携しない）方法で用いることができる。

ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0

現状では、ブラウザによって対応状況が異なるため、全ての環境で新機能を活用することは難しい状況です。article要素やheader要素などを使用してもIE6ではレンダリングされないためスタイルを適用することができません。そうしたHTML5の新しい要素やJSなどの"コンテンツ側の実装技術"と、ブラウザなどの"ユーザーエージェント"、音声ブラウザなどの"支援技術"とを鑑みて、依存するかしないかを検討する必要があります。コンテンツを重視するのであれば「依存する」として、JSを有効にしていることを前提に『HTML5.js』を使用し、下位のブラウザの見栄えを保持することができます。逆に下位のブラウザの対応が必須なら「依存しない」として今まで通りの対応をするということになります。

以前「Webという世界ではコンテンツというレベルでの情報提供が必須である」と述べましたが、HTML5で追加されたセマンティクスな要素を使用すれば、情報をより意味のあるものとして定義することができます。それらを導入することで、すぐに変革がもたらされるわけではありませんが、将来的にWebという媒体が最大限に力を発揮するためのいわば投資のようなものです。それに比べてユーザーエージェントや支援技術において問題とされているのは「古いブラウザがあるから導入できない」「新しい要素はまだ対応していない」ということばかりが注目されています。「依存」という考え方が生まれたのも、コンテンツの重要性が認められ、将来的なWebの姿が明確になってきたからだと思いますし、個人的には一歩踏み出していこうよ！という心境です。

やっと本題ですが、IE6～IE8向けの対応として『HTML5.js』を使用しているサイトがほとんどでした。IE9では対応しているものとして扱い、以下のように「IE8以下に適用」という指定をすれば良いと思います。

<!--[if lte IE 8]>	
<script src="./js/html5.js" type="text/javascript"></script>
<![endif]-->

またCSS3の擬似セレクタに対応するスクリプト『ie-css3.js』を使用しているサイトもありました。これも『DOMAssistant』というスクリプトと併用し、先ほどのコメント内に追記するだけです。

<!--[if lte IE 8]>	
<script src="./js/html5.js" type="text/javascript"></script>
<script src="./js/DOMAssistantCompressed.js" type="text/javascript"></script>
<script src="./js/ie-css3.js" type="text/javascript"></script>
<![endif]-->

メッセージ

YouTubeがIE6を代表する下位ブラウザのサポートを終了したのは記憶に新しいですが、最近ではGoogleまでもが段階的に終了することを明らかにしています。さらにTwitter上では「IE6 Must Die」というIE6の撲滅運動が展開されています。サポートを終了することには何の異存もありませんが、使用するユーザーがいる限り、何かしらの対処を施す必要はあると思います。実際に「HTML5 Gallery」で見たサイトのほとんどが下位ブラウザ向けにメッセージを添えています。

<!--[if lte IE 6]>	
<h2>What the…</h2>
<p>Woah—it looks like you’re using Internet Explorer 6 or below. While I salute you for being so staunchly old school, you gotta know that IE6 just can’t display modern sites like this properly. You’re still most welcome here—just be aware that this isn’t how it’s <em>meant</em> to look.</p>
<![endif]-->

日本語では以下のように設定すれば良いと思います。ブラウザのロゴなどを使用して、各ベンダへの直リンクを貼ってあげるとより親切です。

<!--[if lte IE 6]>	
<p id="caution"><strong>あなたは旧式ブラウザをご利用中です</strong>このウェブサイトを快適に閲覧するにはブラウザをアップグレードしてください。</p>
<![endif]-->

サポートしないということ

@import命令を使用して、NN 4.xやIE5.xにCSSを適用しないといった手法はよく知られていますが、これらの対処は表示崩れを回避するために施されているわけですから、サポートしているといえます。つまり、コンテンツ側の技術が有効で、問題なく機能することが前提で作られているので、機能しない下位ブラウザはもう知りません、特別な対処は施しませんというのがサポートしないということになります。「HTML5 Gallery」では以下のようにIE6向けのスタイルを適用しているサイトもありましたが、おそらくこうした対処もされなくなっていくのでしょう。

<!--[if IE 6]>	
<link rel="stylesheet" href="/css/ie6.css" type="text/css" media="screen" />
<![endif]-->

新しい技術への姿勢

Developers Summit 2010「次世代web標準 html5 最新動向」では、HTML5に関する初歩的な内容から実践的な内容まで、広く深く学べる貴重な時間を過ごせました。とくに矢倉氏が話されていた「勧告が先だからといって諦めるのではなく、実装されている機能を活用していこう」というお話はとても共感できました。私も以前「私たちがWeb世界を作っているということ。」という記事で「ただ普及するのを待っているだけではなく、新しい技術や考え方があるのなら、どんどん取り入れていこう」と述べましたが、やはり今のWebにはそうしたアクティブな姿勢が求められているのだと思います。

整ってきている条件

これは単なる理想論なんかではなくて、実際にSafari(モバイル含む)のWebKitエンジンでは、HTML5、CSS3の新機能がほぼ完全に実装されています。つまり、モバイル版Safariしか選択肢がないiPhoneにおいては、事実上HTML5とCSS3が標準プラットフォームになっているということになります。それを踏まえると、iPhoneを代表するスマートフォンの普及、iPadという新基準デバイスの出現、これだけでもかなりのインパクトがあります。

また、「When can I use...」というサイトで「HTML5の実装状況」や「CSS3の実装状況」を見て分かる通り、Internet Explorer(以下IE)を覗くモダンブラウザではほとんどの新機能が実装されていることが分かります。Microsoftの次期ブラウザである『IE9』が標準技術に積極的な意向を示していること、IE6のシェアが下がる一方であることを加味すると、新機能を実装するための"条件"が整いつつあることが分かります。

IE6への対応

しかし、現実問題としてIE6などの古いブラウザを無視できないというのも事実です。以前「CSSのあり方について考えてみた。」という記事で「ターゲット外のブラウザでも最低限の見栄えを確保する配慮は必要になるでしょう。」と述べましたが、この時はまだ「Gemination」のように最低限の見栄えは確保し(このサイトの場合は全く異なるデザインを適用していますが)、高水準のブラウザ向けに一部のスタイルを上書きするようなイメージを抱いていました。IE6などの古いブラウザを対象に含める以上、新機能を余すところなく活用するというのは困難と思われるからです。

しかし、先日の「CSS Nite vol.44」で、植木 真氏による「アクセシビリティ」の講演を聴き、もしかしたらすぐにでも動き出せるんじゃないかという可能性を感じました。

依存する技術、しない技術

「2004年版 vs 2010年改定版」というテーマで、10つの要点を話されていましたが、JISがどう変わったのかということは基より、全体の構成がどうなっているのかということまで把握することができ、原案と睨めっこしていた私にとしてはとても身になる講演でした。『WCAG 2.0』を踏襲していること、あえて抽象的な達成基準にしていること、達成等級が取り入れられていることなど、JIS改定の詳細については公開されているスライドを音声を合わせてご覧下さい。

• スライド（PDF、100ページ、1.9MB）
• 音声（MP3、57:01、54.9MB）

「JIS X 8341-3 改正原案（2009年1月公開レビュー版）」も併せてどうぞ。

お話の中で特に印象的だったのは『依存しているウェブコンテンツ技術』という章です。今まではJSやFLASHなどが無効にされている場合の配慮として、代替コンテンツを用意する必要がありました。それは最低限のアクセシビリティ対応として当然のことですが、ここで言いたいのは、特定の技術に依存したコンテンツがNGとされているということです。例えば、JSを使用するのであれば「JSが無効の場合の対応」が必須でした。

しかし改定版JISでは、利用者がJSやFLASHを有効にしていることを前提にしても良いという内容が追加されたのです。特定の技術が利用できる前提とすることを「依存している」といい、前提としないことを「依存しない」といいます。つまり「依存している」とする場合は、JSなどが有効になっていることを前提にコンテンツを作成してもよいということになります。

JavaScriptの活用

現在、先行実装は進んでいるとはいえ、ブラウザによって対応状況がことなるため、全ての環境で新機能を活用するというのは難しい状況にあります。articleやheaderなど、新たに追加された要素を使用しても、IE6で悲惨な表示崩れが起こることは目に見えています。しかし、もし「依存している」としてJSの利用を前提にするのであれば、DOM ScriptingによってIE6,7でもHTML5の新要素を扱えるようにすることが可能になります。有名なのはRemy Sharp氏が公開した「html5.js」というライブラリです。

以下のようにIE向けに適用するだけで済みます。

<!--[if IE]>
<script src="html5.js" type="text/javascript"></script>
<![endif]-->

つい最近までは、このような後方互換のための対応をしても「JSが無効にされていたら元も子もないだろう」という話になってしまい、結局現実的な妥協案にせざる終えない状況にありました。しかし、改定版JISで新たに追加された「依存」という規定によって、新たな展開が期待できるのではないかと思っています。ただし、それには『アクセシビリティサポーテッド』を満たしていることが大前提となります。

アクセシビリティサポーテッド

アクセシビリティサポーテッドとは何ぞやということになりますが、簡単に言えば作成したコンテンツが標準仕様に沿っていて、利用するユーザーがアクセシブルにコンテンツを利用できるのかどうかということです。それには、ブラウザなどのユーザーエージェント、スクリーンリーダーや音声ブラウザなどの支援技術に対して適切なサポートがなされているかということまで含まれます。これについて「アクセシビリティ・サポーテッドという考え方｜ウェブユーザビリティ向上を支援するWebsite Usability Info」で非常に分かりやすい説明がされているので引用します。

1. Webコンテンツ自体が、標準仕様（WCAG 2.0 や JIS X8341-3）で定められたアクセシビリティに優れた方法で制作されていて、
2. ユーザーエージェント（Webブラウザなど）や支援技術（スクリーンリーダーや音声ブラウザなど）がそのアクセシブルな制作物（コンテンツ）を適切に理解、解釈、出力できて、
3. ユーザーがWebコンテンツをアクセシブルに利用することができる。

つまり、コンテンツ側の実装技術と、ユーザーエージェント/支援技術側の対応状況の折り合いがついて、初めてアクセシビリティが実現する、という考え方です。

植木氏も話しておられましたが、JISというのはあくまでガイドラインであって、それに適合していることがアクセシブルであるということではありません。標準仕様に適合しても、ユーザーエジェントや支援技術によって差異が生まれてしまうからです。JSなどの実装技術に依存することなく、またIE6などのエージェントなどに縛られることなく、サイトの要件によって、何が必要で、何が不要なのかを臨機応変に対処していくことがこれから求められていくのではないでしょうか。ガイドラインは、あくまで迷った時に立ち返るところとして、また世界共通のルールとして認識することが大切だと思います。そしてその考え方というのは『プログレッシブ・エンハンスメント』に通じるところがあります。

これからはプログレッシブ・エンハンスメント

以前「Progressive Enhancementという考え方」という記事を書きましたが、この考え方がこれからのWebを象徴していると改めて思います。"Progressive"という言葉には「前進する、進展する」という意味があります。前進する為には、まず目的地を決める必要があります。次世代Webの理想像を思い描いてください。そうしたら、そこにたどり着くにはどうしたらいいのかを考えます。今、何をすべきか。私自身はこういうふうに考えて自分の行動に納得しながら日々を過ごしています。このブログだってそうです。なぜなら、目的地が分かってなければ当然たどり着くことはできませんし、適当に決めて効率よく進んだところで、それは間違った目的地に進んでいることになります。

今こそ、次世代のWebへ向かって歩を進める時ではないでしょうか。

グローバルナビゲーションをJSで制御しているサイトもあれば、CSSの背景で制御しているサイトもあるけど、結局どれがベストなの？

まず、テキストは元より、画像であっても代替テキストを指定すれば『コンテンツ』というレベルで情報は確保できるので、テキストが良いか、画像が良いかということについては個人的にどちらでも良いと思っています。マークアップの観点では、グラフや地図、写真イメージなど、テキストでは補えない性質の情報を提供する場合はimg要素でマークアップするべきだと思いますが、ナビゲーションはあくまでサイト内を遷移するための"機能"であるため、その役割を果たすことが最も重要なのではないかと思います。

また、ナビゲーションにはサイト内を遷移するという役割のほかに、現在位置を把握するという役割も担っているので、ロールオーバーやカレント表示などの機能も備わっていなければなりません。どの手法がベストなのかを検討するには、画像を非表示にするユーザやCSSを無効にするユーザへの配慮がなされているかといった『見栄え』による部分と、JSを無効にしているユーザへの配慮がなされているかといった『ふるまい』の部分を把握した上で考慮する必要があります。では、実際にいくつかの手法を再現しながら検証していきましょう。

CSSで画像置換を行う

テキストをtext-indent:-9999pxで飛ばして背景画像を表示させる手法で、しばらくの間主流になっていました。しかし、画像を非表示にした環境下でテキストが表示されなくなるという問題は、モバイルでの閲覧や回線状況、テキストブラウザや音声ブラウザなどの閲覧環境においてアクセシビリティ上、致命的な問題を生じる可能性があります。また、テキストを飛ばす、或いは消して画像に置き換えるという手法上、SEOスパムと判別される可能性があります。画像置換にはメリットも色々とあるのですが、それを上回るデメリットがあるため、現在では使用が控えられている傾向にあるようです。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

テキストが表示されず、環境によってはナビゲーションとして機能しない

CSSをオフにした場合

適切にマークアップされていれば最低限のアクセシビリティは確保されるので問題なし

画像をJSで入れ替える

img要素で定義されているため、画像を非表示にした環境でも代替テキストが表示されます。これで、画像置換で起こる「テキストが表示されなくなる」という問題は解消されますが、JSを無効にすると今度はロールオーバーが機能しなくなります。よくJSでロールオーバーさせるメリットとして「CSSが無効の環境でも画像が保持される」ということが挙げられているのですが、おそらくCSSを必要としない環境下では画像そのものよりも適切な代替テキストが指定されているかの方が重要なのではないかと思います。その考え方に基づくと、CSSを無効にした環境下でJSによる挙動が本当に必要なのかという疑問も生じます。ロールオーバーが機能しないことは、差したる問題ではないとは思いますが、先に挙げたような"副作用"と天秤にかけて使用を検討する必要があるかもしれません。

JSをオフにした場合

JSで制御しているため、ロールオーバーが機能しない

画像をオフにした場合

代替えテキストが表示されるので、適切なAltが指定されていれば問題なく機能する

CSSをオフにした場合

適切なAltが指定されていれば最低限のアクセシビリティは確保されるので問題なし

画像をCSSで入れ替える

こちらもimg要素で定義を行うのですが、JSは使用せずにCSSだけでロールオーバーを実現しています。概要としては、img要素を囲うブロックにロールオーバー時の背景画像を適用させ、マウスオーバー時に画像を非表示にするというものです。JSを無効にした状態でもロールオーバーが機能し、かつ画像を非表示にした状態でも代替テキストが表示されるので、決定版はこれだ！と言いたいところなのですが、ロールオーバー時に背景画像を指定しているため、画像を非表示にした状態でマウスオーバーすると何も表示されなくなってしまいます。代替テキストが表示されるためサイト内での遷移は問題なく行えると思いますが、マウスオーバー時やカレント時に色が変わるなどといったユーザビリティが確保できないため、ユーザーに無駄なフラストレーションを与えてしまう可能性があります。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

代替えテキストが表示されるが、ロールオーバーやカレント表示の際にテキストが表示されなくなる

CSSをオフにした場合

適切なAltが指定されていれば最低限のアクセシビリティは確保されるので問題なし

新・画像置換

上記では、画像置換にはメリットを上回るデメリットがあるため、使用を控えるという話でした。しかし、もしそのデメリットが解消されたらどうでしょうか。『DKIR』という手法を使えば、画像が非表示の状態でもテキストが表示され、かつCSSで制御しているため、JSを無効にした状態でもロールオーバーが機能します。デザイン変更などがあった場合、マークアップに手を加えることなく画像の差し替えが行える、『CSS Sprite』を利用してhttpリクエストを減らせるなどといった、画像置換の恩恵のみを受けられることになります。SEOスパムについては、その定義の曖昧さや判断基準が明確でない以上、結論が出せないのでここでは棚上げにします。少なくともDKIRという手法はテキストを飛ばすわけでも、消すわけでもなく、背景画像の背面に隠すという手法であるため、画像置換におけるアクセシビリティの問題は解消できるはずです。しかし、そんなDKIRも万能というわけではなく、要素を重ねるという手法上、背景画像に透過PNGが使用できないという制約があります。

詳しくは「これで決まり？な画像置換 - DKIR | CSS-EBLOG」をご覧下さい。

JSをオフにした場合

CSSで制御しているため、問題なく機能する

画像をオフにした場合

代替えテキストが表示されるので問題なく機能する

CSSをオフにした場合

適切にマークアップされていれば最低限のアクセシビリティは確保されるので問題なし

4つの手法を紹介しましたが、どれがベストであるということはあえて明言しません。なぜなら、どれがベストであるかは時と場合によって異なるからです。JSを無効にした場合、画像を非表示にした場合、CSSを無効にした場合について検証したのは、それぞれの手法の長所と短所を明確にするためであって、優劣を決めるためではありません。一つの手法しか知らなければ何を疑うでもなくそれだけを使用し続けることになりますが、他の手法を知っていればそれだけ引き出しが増えることになり、時と場合によって相応しい選択が行えるようになります。

1つだけ個人的な意見を述べるとしたら、ナビゲーションというのは"機能"としての役割を全うしてくれればそれで良いと思います。例えば、一つタグなどを挟まないとその機能が実現できない、というならば躊躇せずに挟むべきだと思います。「spanタグが入ると気持ち悪い」というのはとても分かりますが、そのTPOにおいて何が必要で、何が不要なのかを判断するには、やはり相応の知識が必要になります。これは何にでも言えることだとは思いますが、あらゆる手法や考え方を"身に付ける"まではいかなくとも、"知っている"だけで全然違います。一つの手法や考え方に固執するのではなく、広い視野を持って取り組みましょう。

クロスプラットフォームにおいては、HTML5が独占しているわけではないので、"競争"という捉え方もできます。しかし、すでに次世代プラットフォームとして注目されている『WebKit』は言わずもがなHTML5が基盤になっていますし、『Google Chrome OS』はもちろん、Adobe『AIR』、Microsoft『Silverlight』もHTML5に対応する見通です。つまり、HTMLはFLASHを代表するリッチな技術の対抗勢力になるのではなく、アプリケーションを開発する上での標準技術になるというが正しい認識なのではないかと思います。

FLASHも『Flash for iPhone』というプロジェクトを発表していますが、それは「基盤」と「手段」という意味で全く異なる次元の問題です。それはFLSAHが優れていないと言いたいわけではなく、そもそも白黒つけようとすることが誤りなのではないかと思うのです。ここでWebサイトを作る目的について考えてみてください。「私たちがWeb世界を作っているということ。」で述べましたが、誰もがインターネットを持ち歩く時代、もう一つの"世界"といっても過言ではないWeb世界を、私たちが政治家として執政にあたっています。私たちの役割は、率先して市民の声に耳を傾け、ニーズを汲み取り、執行機関の施策に反映していくことです。

つまり「どのような施策を反映させ、国民を満足させるのか」ということが重要であって、FLASHやHTMLというのは、それに応える為の手段でしかありません。先に述べた通り、HTMLはリアル世界でいう国民保険のようなもの(意思に関わらず、住所を有する者であれば必ず加入しなければならない)になりつつありますが、現時点ではFLASHと同様、一つの手段として然るべき役割を担っているといえるでしょう。どちらかがという狭い視野で捉えるのではなく、それぞれの特性を理解して、また共有し合って『ユーザーエクスペリエンス(以下UX)』を創り出すことが本来の目的ではないでしょうか。

ユーザーエクスペリエンス

User Experienceの"Experience"という単語は「経験、体験」という意味合いがあり、直訳するとユーザー体験になります。つまり、ユーザーが製品やサービスなどを利用する際に得られる体験のことをいいます。Donald A. Normanによって提唱されたということもあり『ユーザー中心設計』が基盤になっているUXは、ヒューマンインタフェースやユーザビリティなどよりも広い概念を示すための造語として提唱されました。

どのような違いがあるのかというと、インタフェースにおけるレイアウト設計、色彩計画というのはあくまで"一つの構成要素"であって、それ自体が「体験」を提供しているわけではありません。例えば、ある製品に対してユーザーが形が格好いい、操作が分かりやすいと思っても、それが購買に結び付くかどうかは別の話です。ユーザインタフェースがそうした機能的なものに対してUXは、そもそもその機能がユーザーにとって必要なものであるのかという観点なのです。

大型ショッピングセンターには、カレーを作る為にカレールーや野菜を買いに来る人もいれば、電化製品を買いにくる人など、様々な目的を持ったユーザーが訪れます。カレーの材料を買いに来たユーザーが電化製品を買うということはまず考えられません。仮に電化製品売り場を通りかかる機会があって、いつか欲しいなとは思っても「カレーのついでに買っちゃおう」という人はそうはいないでしょう。かなり無理がある話ですが、もしカレーの材料を買いに来たユーザーに電化製品を買わせたいという目的があるのなら、その場合においてどのような「体験」を与えればユーザーの購買意欲を発起できるのかということを検討する必要があります。

さて、ではカレーの材料を買いにきたユーザーに対して、どのようなインタラクションを提供すれば良いのでしょう。頻繁に訪れている顕在ユーザーであれば迷うことなく目的の商品を見つけることができると思いますが、初めて訪れるユーザーには、何かしらのインタラクションを提供しなければなりません。例えば、普通のスーパーでは商品ごとにカテゴライズがなされており、指標となる目印が設けてあります。その他にもユーザーの購買意欲を発起する為の「体験」として、試食・試飲、医薬品や美容化粧品などのサンプルの提供などが挙げられます。また、ユーザーの性質に関わらず、レジの前に必ずと言ってよいほど置いてあるお菓子や日用品は、誰もが日常的に必要するものばかりが並べられています。

この例でのユーザーインタフェースが、ユーザーを誘導する為の目印や、購買意欲を高める為のサンプル品のことで、UXはユーザーが訪れてから目的を達成するまでの「体験」そのもののことをいいます。どのようなユーザーがいるのか、どのようなニーズがあるのか、何を伝えたいのかなどを把握した上で、どのようなインタラクションを提供すれば満足してもらえるのかという一連のシナリオを組み立てること、上の例でいえばカレーの試食をさせて購買意欲を発起しようなど、「ユーザーが認知する体験のこと」をUXといい、その設計を『ユーザエクスペリエンスデザイン(以下UXD)』といいます。

ユーザーエクスペリエンスの構成要素

先ほど冒頭で「HTMLもFLASHもUXを創りだす一つの手段に過ぎない」と述べましたが、UXを構成する要素について解説したいと思います。以下のモデルは「IA100 ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計」で採用されているものを使用しています。Webサイトは「テクノロジー」「ビジュアルコミュニケーション」「情報アーキテクチャ」という3つの組み合わせでコンテンツが企画され、UXDで一連のユーザー体験を組み立てます。

ユーザーエクスペリエンスの構成要素

【テクノロジー】

テクノロジーは、PCやモバイルといったデバイスを含む「プラットフォーム」、データベースや会員システムなどの技術を含む「サーバーサイド」、そして文書構造を司るHTMLや見栄えを司るCSS、インタラクションを司るFLASHやJavaScriptといった表現技術を含む「フロントエンド」に分けられます。今までも考察してきた通り、今日のテクノロジーにおける進展には目を見張るものがあり、ユーザーに与える体験をより快適なものにしてくれるでしょう。

【ビジュアルコミュニケーション】

ビジュアルコミュニケーションは、サイトの印象や感覚的な表現を司る「アートディレクション」とレイアウト設計や色彩計画などのグラフィカルな表現を司る「グラフィックデザイン」に分けられます。企業ブランドやコンテンツなどを、どのようなモチーフやトーンで伝えるのか、またそれをどのように表現するのかというWebサイトに限らず全ての媒体に必要不可欠な要素です。

【情報アーキテクチャ】

ユーザーが情報探索を行う上で、どのように情報を整理すれば、理解しやすく、利用しやすいものになるのだろうか？という複雑な情報を分かりやすく伝えるための技術です。具体的にはサイトストラクチャ、ラベリング、ナビゲーションの設計によって「情報の組織化/構造化」を行います。Webサイトを作るということは、言い換えれば情報をデザインするということであり、いわゆる『IA』と呼ばれる専門家だけが考えれば良いことではなく、Webに携わる全ての人に必要な要素です。

見つけやすさの重要性

以下の図はPeter Morville氏が提示した「ユーザーエクスペリエンス・ハニカム」です。UXを性質という観点から見た構成要素で、いくつかの性質を同時に満たすことでユーザーの琴線に触れることできると言われています。どの性質を優先するのか、或はさせないのかということを、ビジネスゴールとコンテクスト、ユーザーニーズと行動、コンテンツの有用な混合という観点から鑑みて、バランスの良いコンテンツ作りを目指します。例えば、高齢者のアクセスが想定されるWebサイトでは「好ましさ」よりも「アクセスしやすい」を優先しようなど、避けられない妥協は無意識にではなく意識的にさせなければなりません。

ユーザーエクスペリエンス・ハニカム

役に立つ

図的になされなければならないその商品やサービスが本当に役に立つのか、商品知識や専門的知識を深め多くのユーザーに訴えかける

好ましい

イメージ、アイデンティティー、ブランドが持つ力と価値はバランスを保つことでユーザーの関心を引く

アクセスしやすい

障害を持つユーザーであってもアクセスできることで、より多くのユーザーにリーチする

価値がある

利益を上げ、顧客満足を満たす。利害関係者すべてに価値をもたらす

信頼できる

多くのユーザーに信頼感を与えるデザインである

見つけやすい

ユーザーが欲する情報を迷う事なく即座に見つけられる構造である信頼できる

使いやすい

Man-Machine Interfaceの観点からユーザビリティを考慮する

この性質の中でも、数十億の項目が様々な形で分散して集積しているWebにおいて、「ファインダビリティ(見つけやすさ)」は非常に重要です。どのようにしてユーザーの興味を発起するかというインタラクションや、快適な操作性を提供するユーザビリティの重要性は広く認識されていると思いますが、ファインダビリティはあまり注目されていない節があります。これからさらに情報過多が進み、あらゆるデバイスでインターネットが利用され、Web世界が膨張し続けるということを考えれば、ユーザーのニーズとサイト固有の戦略とを結びつけ、双方のバランスを取り、最適なファインダビリティを提供することがどれほど重要なのかが分かると思います。何故なら、分かりやすさも、使いやすさも、好ましさも、全て見つけられなければ意味をなさないのです。

そういう意味においてサイトのファインダビリティを高めるということは、『SEO(検索エンジンの最適化)』という分野にまで及びます。一部のSEO業者では姑息な手段を使って検索エンジンを騙す手法を適用していますが、検索エンジンが進化し続ける生き物であるということを忘れているのではないでしょうか。一時的に効果があっても、後で取り返しのつかないことになる可能性があります。本質的にSEOを向上させるにはどうすれば良いのかを考え、今ある資源の中から有益なものを活用するしていくという方が、合理的であるといえます。

ノリシロを持つということ

ここまでUXについて述べてきましたが、FLASHやHTMLがUXを創りだす一つの要素でしかないということがご理解いただけたかと思います。私たちがWeb世界を執政するにあたり、一つの概念や手法に捕われてしまっては、物事の本質を見失ってしまいます。何が必要で、何が不要なのかを判断をするには現状を汲まなく把握し、そして把握する為にノリシロを持つ必要があります。「ユーザーエクスペリエンス」で述べた3つの要素では、それぞれのスペシャリストがいるはずです。「テクノロジー」であればマークアップエンジニア、フロントエンドテクノロジスト、フラッシャー、システムエンジニアなど、「ビジュアルコミュニケーション」であればグラフィックデザイナー、アートディレクターなど、「情報アーキテクチャ」ではインフォメーションアーキテクトなどが挙げられます。

もう一度「ユーザーエクスペリエンスの構成要素」の図を見ていただければ分かると思いますが、それぞれの要素は独立して成り立っているわけではなく、それぞれに依存し、また相関があります。つまり、理想的なUXを提供する為には、それぞれのスペシャリストが全体を俯瞰しながらUXDを行う必要があります。例えば、グラフィックデザイナーがパーツを作成する際に、マークアップの知識があればビジュアルと論理構造の相違はなくなるはずです。もう少し噛み砕くと、「資料請求」というボタンを作成するにあたり、論理的意味合いでは重要な意味付けを行っているのにも関わらず、デザイン的な見た目はまるで目立たせていないといった問題は避けられるはずです。また、プロジェクトで進めている場合、スペシャリスト同士のコミュニケーションは不可欠なものであり、それを円滑にさせるにはお互い価値観や考え方、技術に関することまで、認識のずれを出来る限り解消できるに越したことはありません。

構成要素のうちどれか1つを無くしてもUXは成り立ちません。プロジェクトとして1つのサイトを作り上げるのに、全員でUXを創っているという意識があれば、そしてよりユーザーの満足を得られるサイトを作るという意思があれば、自ずとお互いを理解し合える素晴らしい環境が築けると思います。そして、例外なくそうしたプロジェクトは成功しているのではないでしょうか。フラッシャーの人はHTMLの役割を理解し、マークアップエンジニアはFLASHの役割を理解することで、何が必要で、何が不要なのかをお互いの内で共有することができるはずです。繰り返し述べているように、UXは「どのような体験を与え、ユーザーを満足させるのか」という云わばWebサイトの「提供価値」を考えるコンセプトです。FLASHが、HTML5が、という狭い視野ではなく、広い視野を持って取り組みましょう。

クリエイティビティの可能性

Webサイト制作におけるJavaSciptというのは、いわゆる「DOM」と呼ばれるAPIを利用して簡単なギミックを実装する程度のもので、リッチなインタラクションを提供するというのにはほど遠いものでした。しかし、JavaScriptエンジンの高速化が進み、表現力の向上が進展すれば、より"ふるまい"としてのクリエイティビティは格段に進化することになるでしょう。「これからのWebのあり方について考えてみた。」で述べた通り、JavaScriptでネイティブアプリケーションと同等のクオリティを発揮するということは、それだけの「体験」を提供できるということを意味します。Flashを代表するリッチコンテンツ専用の規格と大きく異なる点は、Web標準に準拠した上でリッチなインタラクションと表現力を発揮するということです。

【JavaScriptエンジンの高速化】

JavaScriptは2000年頃に、ECMAScriptの標準化作業に伴ってバージョンアップをするという動きがあり、去年の12月に「JavaScipt 2.0」の仕様策定が完了しました。GoogleやAppleを初めとする代表的なベンダがプロトタイプとして実装を行い、仕様の最終確認、相互の互換性、旧バージョンとの互換性などの検証を経ているので、ブラウザ間の非互換性が大きく改善されると思われます。その他にも「JSON」のサポートが強化され、セキュリティの強化が行われているそうです。

そして最も注目すべきなのは、JavaSciptエンジンの高速化による表現力の向上でしょう。先に述べた通り、Microsoft、Yahoo!、Adobe、Mozilla、Opera、Googleは標準化プロジェクトに取り組みつつも、JavaScriptエンジンの高速化にも余念がなく、事実上の「JavaScript高速化競争」が起きています。AppleはSafari 4で「Nitoro」というエンジンを実装し、Operaは「Carakan」というエンジンを実装中、Firefoxは「TraceMonkey」というエンジンを実装中、そしてGoogle Chromeは「V8」と呼ばれる独自のエンジンを搭載し、その性能の高さは実証されています。

【新しいプラットフォーム】

次世代プラットフォームとして最近注目を集めているのは「WebKit」です。WebKitはすでにHTML5の機能を取り込んでいて、WebブラウザのGoogle CromeやSafari、iPhoneでも採用されているし、Symbian陣営もWebKit搭載に動いているそうです。これが何を意味するかというと、これからはPCがWeb標準を背負ってきた時代は終わり、他のプラットフォームが主流になる可能性すらあるということを示唆しています。

表現力やWebアプリケーション開発フレームワークが貧弱であるHTMLの代わりに、「Adobe AIR」や「Silverlight」、「Flash」などが活躍しているわけですが、オーディオやビデオといったマルチメディア関連機能、Webアプリケーション向け機能が充実しているHTML5がWebKitによって普及すれば、それらの技術は不要になるかもしれません。単純に"ふるまい"という意味でも、「CSS 3」の表現力向上やJavaSciptエンジンの高速化などの発展が進めば、セマンティックでありながらクリエイティビティ溢れるコンテンツを作ることも夢ではありません。

コンテンツと表現の相互作用

では、Web標準に準拠しているということにはどのような意味があるのでしょうか。HTMLが骨格、CSSが外装であるなら、JavaScriptは「体験」を提供します。過去、ブラウザベンダの独自拡張が相次ぎ、意味のないアニメーションやUIを実装したサイトが乱立した関係で、JavaScriptによるインタラクションを苦手とするユーザーは少なくありません。今でもそのようなWebサイトはありますが、それは体験を与えているのではなく、制作者側のエゴをユーザーに押し付けているに過ぎないのです。

体験というのは、ユーザーのニーズや利用状況を把握し、心理状態を理解するという「人間中心設計」と呼ばれるアプローチを行い、その上でどのような体験を与えれば響くのかということを考えて導きだされるものです。これはWebサイト全体を設計する際に必要になる行程ですが、狭義な意味での体験として、いわゆる「ユーザインタフェース(以下、UI)」にも同じことがいえると思います。例えば大型マーケットなどにあるエスカレーターは、ユーザーのニーズや利用状況を把握した上で設置されています。もしもエスカレーターが「動く階段」として飾られているだけなら誰にとっても意味のあるものに成り得るでしょう。これはあまりに極端ですが、そのようなUIが数年前のWeb世界では当たり前のように存在していたのです。

そして、エスカレーターの素晴らしいところは仮に動かなくなっても「人を移動させる」という目的をしっかりと果たすということです。そうしたコンテンツと表現を相互に作用させる操作能力を提供するのがJavaScriptのもう一つの役割であり、Web標準に準拠するということの本質的な意味です。Progressive Enhancementという考え方に基づいて言い換えれば、JavaScriptが機能しなくてもユーザーがWebサイトを利用できるような配慮をしつつも、より快適なUIを提供するということになります。

JavaScriptの実際

CSS以上に利用環境に依存してしまうJavaScriptですが、実はずいぶん前から「unobtrusive JavaScript(出しゃばらないJavaScript)」という考え方がありました。HTMLの要素などに直接JavaSciptを記述せず、外部JSからHTMLソース上の要素に結びつけるという手法です。これによってHTMLの保守性が高まる、JavaSciptがオフのブラウザでも動作する、再利用が容易になるというメリットがあり、ブラウザ対応の振り分けも容易になります。つまり、JSをオフにしているユーザーには最低限のインタラクションを提供し、高水準のブラウザを利用しているユーザーや高機能デバイスを利用するユーザーには、よりリッチなインタラクションを提供するということが可能になるのです。

「Graceful DegradationとProgressive Enhancementの実践 | Web標準Blog」で、オンラインショッピングの決済画面などによくある「印刷するボタン」をProgressive Enhancementなアプローチで実装するという事例があるので、引用します(この辺りは他力本願で申し訳ありません；)。

Progressive Enhancementは、最低限提供したい機能や目的を「ベースライン」として設定します。印刷リンクは「ページを印刷したいというユーザーのニーズに答える」ことが目的ですから、まず「ページの印刷について言及する」ことをベースラインとしましょう。

まずは、最低限提供するべき内容を定めています。ここでは以下のような形で「印刷して保管できます」ということを文章で伝えています。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>

では、次に実現したいことをどのように実装するのでしょうか。以下のようなスクリプトで、ブラウザが必要な機能を満たすときのみ、印刷ボタンが表示されるようにしています。

<p id="printthis">Thank you for your order.
 Please print this page for your records.</p>
<script type="text/javascript">
(function(){
  if(document.getElementById){
    var pt = document.getElementById('printthis');
    if(pt && typeof window.print === 'function'){
      var but = document.createElement('input');
      but.setAttribute('type','button');
      but.setAttribute('value','Print this now');
      but.onclick = function(){
        window.print();
      };
      pt.appendChild(but);
    }
  }
})();

</script>

この手法は、印刷リンク(ボタン)だけではなく、文字の拡大縮小インターフェースなどにも利用することができるでしょう。まずブラウザーの文字サイズ変更機能について言及し、インターフェースをあとからJavaScriptで組みこむのです。

矢倉さんが述べている通り、まずはその機能が本当に必要なのか？を言及する必要があります。「コンテンツと表現の相互作用」で述べた通り、「体験」とは必要なことだけを考えていれば良いということではなく、提供しなくて良いことも明確にした上で、どのような体験を与えれば響くのかを考えることに意味があります。つまり、制作者側がやりたいだけのエゴを押しつけるのではなく、ユーザーを理解した上で必要な機能を提供するということが大切なのです。ユーザーが理解出来ているのなら、「何が必要か」だけではなく「何が不要であるか」も明確になるはずだからです。

最後に

3回に渡って「○○のあり方について考えてみた。」について自分なりに考察してきましたが、ただインプットを行うのと、アウトプットをするためにインプットするのとでは、全く意味が異なるということが分かりました。前者はインプットすることが目的なので、一時的に満足はするもののすぐに忘れてしまいます。後者はアウトプットをするためにインプットを行うので、一度頭の中で情報を整理し、まとめるという作業が必要になります。色々な記事を参考にしながら書かせていただきましたが、自分の血肉となった感じがしています。今後も定期的に更新をしていこうと思いますので、よろしくお願いいたします。

Web標準とは

Web標準とは、W3Cによって規格化されている標準技術のことを指します。構造的かつセマンティックなマークアップ、見栄えをCSSで制御する手法で実装を行うことで「CSSのあり方について考えてみた。」で述べたような技術的なメリットが得られるだけでなく、ブラウザサポートの改善、ノウハウの普及、学習コストの低下などにも繋がります。

また、Webの利用者に占める高齢者やハンディを持つ方々の割合が高まり、Webアクセシビリティの重要性が広く認知されてきています。2008年12月に、草案の段階から多くのフィードバックが寄せられていた『WCAG 2.0』が勧告され、Webアクセシビリティのガイドラインとして広く利用されています。JIS規格もWCAG 2.0と調和するよう改訂が進められているそうです。

広義なWeb標準

このように、XHTML、HTML、CSSなどの標準技術をWeb標準とすることが一般的です。その通りなのですが、個人的にはもう少し俯瞰した捉え方もあるのかなと思っています。些か極論ではありますが、広義な意味でのWeb標準とは、Web世界で暮らす為のルールであるということがいえるのではないでしょうか。私たちが暮らすリアル世界では、信号が赤になったら止まる、青になったら進むというルールがあります。私たちは産まれたその時から、そうした「常識」の中で成長するため、当たり前のようにそれらを身につけていきますが、Web世界はまだ十数年しか存在していないため、ルールがなければ誰もが好き勝手に道路を渡り、事故が多発するような世界になってしまいます。

このまま、この例え話に興じるなら、Web世界の政情を司っているのがW3Cという国家組織で、学校で使われる教材が文部科学省の検定を受けているのと同じように、W3Cという組織では、仕様の策定が行われています。その中にはTim Berners-Leetという総理大臣がおり、Apple, Google, Microsoft, Mozilla, Operaといったブラウザベンダーを始め、幅広い分野の企業が閣僚として参画しています。そして、その国の執政にあたるのが国会議員であり、実際にWeb世界において権力を持っている方々はそれに当たります。彼らは率先して市民の声に耳を傾け、ニーズを汲み取り、執行機関の施策に反映していかなければなりません。

そうした地位にいる人はほんの一握りで、私を含め殆どの人は毎日のように政治家活動を行っている立場です。中にはいわゆる政治活動家として暗躍されている方もいるかもしれませんが、政治活動を行っていることに変わりはありません（語弊があると難なのですが、あくまで例え話です）。重要のは私たちがWebを生業としている限り、Web世界における政治家としての責任があるということです。以下、Wikipediaから「政治家に求められる資質」を引用します。

マックス・ヴェーバーは、「政治家の本領は『党派性』と『闘争』である」と指摘している。そのうえで、政治家に求められる資質として以下の3つを挙げている。

• 未来を構想しながら、現実を変革していこうとする情熱
• 現状をいまそこにあるままに、しかも一定の距離感覚をもって理解できる洞察力
• 政治がときには暴力を手段として選ばざるを得ないことを踏まえた結果責任への自覚

リアル世界でも政党があるように、Web世界でも様々な主張があります。HTML5に関する主張をする人もいれば、方やRIAに関する主張をする人がいます。個人で活動するタフな人もいるかもしれませんが、大体は同じ主張を持つ者同士が組織を作り、目標の実現に向けて切磋琢磨するはずです。私個人の話で言えば、Web制作者である以上、今ある現状を受け入れ、どうすればより良くなるのだろうか？と試行錯誤し、自分の判断が時には悪影響を及ぼす可能性があるという責任感を持って取り組み、未来を構想しながら現実を変えようとする姿勢を保ち続けたいと思っています。

とまあ、例えが分かりづらい上にかなりの極論になってしまいましたが、要するにWeb標準というのは、私たち次第でどうにでも変えられるということです。当時は理想論だと言われていた標準技術も、今ではWeb制作におけるデファクトスタンダードになっています。CSS 2.1においては、未だ勧告もされていないのにも関わらず、ブラウザで実装されているモジュールは積極的に利用され、IE6などの旧ブラウザのために、解釈の違いを逆手に取った『CSSハック』と呼ばれるテクニックなども生み出されていきました。CSSハックは標準技術ではありませんが、特定のブラウザのレンダリング処理を補うためには必要なものであり、Web標準が普及する上で暗躍してきました。

CSSハックや、こうしたクロスブラウザありきの考え方の善し悪しは置いておいて、ただ普及するのを待っているだけではなく、新しい技術や考え方があるのなら、どんどん取り入れていこうという姿勢が大事だと思うのです。Web標準はあくまで"標準"なので、決められたことは是が非でも守らなければならないというような厳格なルールではなく、ガイドラインとしての大まかな指針という認識で良いと思います。いわゆる「勧告」というのはISOやJISのような標準規格とは異なり、デファクトスタンダード(事実上の標準)という形式とっているため、勧告された時点で利用可能、もしくは既に普及しているということになります。そういった性質上、多くのエディターが議論を重ねながら段階を経て策定され、一般ユーザーからの意見を反映して改訂も行われるため、勧告されてから論争が起こるということはまずないでしょう。

Web標準に対する姿勢について偉そうに述べきましたが、伝えたいことは、私たちがWebという世界を作っているということです。そう思うとちょっと自信が沸いてきませんか？リアル世界と同じように政治を変えるにはそれ相応の主張が必要であるし、世界を動かす権力を持つには、それ相応の地位が必要になります。何にしても「政治家に求められる資質三ヶ条」は忘れずに可能な限り実行していきたいものですね。

見栄えを表現する手段としてCSSという技術が考案され、構造と見栄えを分離することで、メンテナンス性の向上、アクセシビリティの向上、ファイルの軽量化など大きなメリットが得られます。しかし、1998年頃に『CSS 2.0』が勧告された頃は、ブラウザ戦争の真っ只中ということもあり『Web標準』に懐疑的なブラウザベンダーは積極的に実装を進めてはいませんでした。実際に「懐疑的で積極的でなかった」のは私たち制作者側であって、ブラウザベンダーは凌ぎを削り合いながらも積極的に取り組んでいました。不適切な表現をしてしまい申し訳ありません。

私はというと、その頃は「Webっておいしいの？」程度の知識レベルだったのでリアルタイムな世代ではなかったのですが、先人の方々に伺ってみると「Web標準など理想論に過ぎない」と思っていた人が多かったのだとか。当時の状況を考えてみれば無理もないと思いますが、結果的に『CSS 2.1』は、仕様の改訂、フィードバックの反映を繰り返し、今日のWeb業界ではスタンダードな技術として広く普及しています。そのような時代背景から学べることは2つほどあります。

積極的にチャレンジする姿勢

当時は理想論だと言われていた標準技術も、今ではWeb制作におけるスタンダードになりつつあります。CSS 2.1においては、未だに最終勧告がされていないのにも関わらず、先行実装されている機能から積極的に利用されていき、IE6などの旧ブラウザに対応するために解釈の違いを逆手に取った『CSSハック』などのテクニックが生み出されました。つまり、W3Cの勧告や技術の普及を待つだけの受動的な姿勢ではなく、積極的にチャレンジしていく姿勢が大切なのではないかと思うのです。

今話題の『CSS 3.0』は草案段階でありながら、先行実装が始まっているモジュールもあれば、すでに実装がほぼ完了し、十分なフィードバックが得られるモジュールも存在します。以下「CSS3の実装状況│When can I use...」で列挙されているものを一部紹介します。見て分かる通り、IE9での実装も進んでいるようなので、これらの機能を惜しみなく使える日はそう遠くないかもしれません。

Box-sizing

widthやheightで指定した横幅や高さに、パディングやボーダーの大きさを含むかどうかを指定する

Web Font

サーバーから指定されたフォントがダウンロードされ、ユーザー環境に左右されない表示が可能になる

Text-shadow

ドロップシャドウやアウトラインの効果を表現できる

Media Queries

小型携帯端末向け、PC向けなどのデバイスに合わせてCSSを分岐できる

Border images

ボーダーでグラデーションや背景画像、エフェクトなどを表現できる

Multiple Column Layout

ユーザー環境によって2段組、3段組のレイアウトを表現できる

Flexible Box Layout Module

ボックスモデルを拡張し、より柔軟なレイアウトを行える

Multiple backgrounds

1つの要素に複数の背景画像を指定できる

Transforms

要素に対して拡大、回転、歪み、移動などの変形を行える

Transitions&Animations

要素に対してアニメーション処理を行える

パラダイムの転換

いわゆるブラウザ戦争というのは、1990年代に起きたInternet Explorer(以下IE)とNetscape Navigatorの『第一次ブラウザ戦争』、2004年以降Mozilla FirefoxやOperaがシェアを拡大し、IEに脅威を与え始めた『第二次ブラウザ戦争』が主なものとして挙げられます。これらのシェア争奪戦で共通しているのは、マーケットでシェアを独占していたIEに対して、ほかのブラウザが下克上を申し立てるという点です。そのような状況なので、IEへの対応は必須になり、クロスブラウザありきの『Graceful Degradation』という考え方が主流になっていきました。

しかし、2006年から水面下で続いている『ポスト第二次ブラウザ戦争』では、FireFox3.x、Opera9.x、Safari for Windows、そしてGoogle Chromeといった次世代ブラウザのリリースが相次ぎ、モダンブラウザがシェアを伸ばす一方、IEがシェアを減らしていくという傾向が続いています。Web標準に積極的でなかったIEも、さすがに準拠せざる終えないと判断したのか、IE7,IE8では積極的に仕様が取り入れられています。Net ApplicationsのBrowser market shareを測定結果では、IEのシェアは63％と表記されていますが、その内訳は以下「12月のブラウザシェア - ChromeがSafari抜く、Firefox 3.5は3位 | エンタープライズ | マイコミジャーナル」から引用します。

これを見て分かる通り、FireFoxをはじめとする次世代ブラウザが上位に食い込み始めています。IE8は、シェアが下がり続けるIE6と拮抗状態にあり、IE8、IE9がメインブラウザになるのは時間の問題でしょう。そうなれば、今までIE6を理由に採用されなかった実装手法も利用されるようになり、CSSハックと呼ばれるテクニックは利用する必要がなくなります。そして、CSS3.0が主流になれば、文書にとって不要な要素やid/class属性を減らすことができ、よりスマートなマークアップが可能になる上に、意図した通りの視覚表現が多くの環境で統一されるので、品質保証にかかる工数も減らすことができます。

だからといってIE6は放置しても良いということではなく、ターゲット外のブラウザでも最低限の見栄えを確保する配慮は必要になるでしょう。その上で新しい技術への積極的な取り組みを行い、そうした試行錯誤が技術の進歩を促し、新しい手法や考え方が生み出されていくのです。こうした状況を踏まえると、クロスブラウザありきの考え方から新たな考え方へパラダイムシフトしているという実感が湧いてきます。今は未だ灯火ですが、自ずと『Progressive Enhancement』という考え方へのパラダイムシフトが、緩やかに、そして確実に起こっていくことでしょう。

CSS3.0の実際

CSS3に関する実例としては以下のようなものが挙げられます。この手の記事では必ずといって良いほど取り上げられているサイトですが、イギリスのデザイナーAndy Clarkeの個人サイト「Stuff and Nonsense」です。モダンブラウザで見るとフルカラーで表示されるのですが、IE6で見るとモノクロで表示されます。IEのCSSサポート状況を皮肉っているようにも思えますが、Progressive Enhancementの考え方を理解するには分かりやすい事例だと思います。

IE6での表示

モダンブラウザでの表示

もう一つの事例は、CSS Zen Gardenに投稿された「Gemination」です。モダンブラウザとIE6とで表示を分けているという点は同じですが、実装手法が異なるようです。前者は条件付きコメントを使用してブラウザ判定を行っているのに対し、後者は属性セレクタを使用してスタイルを上書きしています。CSSソースを覗いてみると以下のように全てのブラウザに対してスタイルが適用されるようにし、モダンブラウザには属性セレクタを使用して新たなスタイルを上書きしています。これは最低限伝えるべき機能を実装し、その上で高水準の環境下でよりリッチな体験を提供するというProgressive Enhancementの考え方に基づいた手法といえるでしょう。

IE6での表示

#container{
position:relative;
margin:0 auto;
border-right:3px solid #fff;
border-left:3px solid #fff;
padding:0 20px;
width:706px;
background:url(contentback.gif);
voice-family:"\"}\"";
voice-family:inherit;
width:666px;
}

モダンブラウザでの表示

body[id=css-zen-garden] #container{
position:relative;
margin:0;
border-top: 5px solid #fff;
border-right:0;
border-bottom: 5px solid #fff;
border-left:0;
padding:0;
width:100%;
height:350px;
background:url(longgarden.gif) repeat-x center right;
}

Progressive Enhancementの考え方に基づいたCSSのあり方、如何でしたでしょうか。コンテンツはもちろんですが、ユーザーエクスペリエンスにおいて見栄えというレベルでの情報提供は大変重要です。ただそれが、コンテンツありきであるということは忘れないようにしてください（くどい）。IE6のシェアが減っているとはいえ、しばらくはターゲットブラウザには含まれるとは思いますが、使えるものは使わな損々。トライ&エラーを繰り返しながらも積極的に活用していきたいですね。

HTMLの軌跡

Tim Berners-Leeが提唱した「広くあまねくアクセシブルなWeb」がどのようなものなのかを知るには、HTMLについて理解する必要があります。1989年にWWWが開発され、文書に相互的な機能を持たせる『ハイパーテキスト』という概念が生まれました。以下、Tim Berners-Lee氏が「The「World Wide Web: Past, Present and Future」で述べた内容を和訳したものの一部です。

ウェブの到達目標は、人間とハイパーテキストの相互のやりとりが十分直感的に分かりやすいものとなって、コンピュータで読みとれる形の情報の空間が、人々の思考、やり取り、仕事のパターンの状態を適切に反映できること。

「コンピュータでも読み取れる形の情報」というのは、コンピュータが人間に代わって文書を適切に分析できるワークフレーム、つまりHTMLのことです。『HTML』とはその名の通り、文書を論理的にマークアップするための言語で、文書構造をコンピュータにも理解しやすいように論理的な意味付けを行い、それらを有益な情報として分析できるようにする役割を持っています。

そして、コンピュータに保存されている文書の『ハイパーリンク』を収集し、その構造を分析することによって、サーチエンジンによる検索データベースが実現しています。これが世界中のネットワークを司る仕組み、『WWW』なのです。

Semantic Web

ティムの思惑とは裏腹に、1993年にHTML1.0が公開されてからブラウザベンダーによる拡張が度重なり、見栄えを表現する要素や属性が追加され、本来の目的とはそぐわないWebサイトが乱立することになりました。そうした状況を踏まえ、『W3C』は標準化を本格的に推進し、HTML4.0では文書を論理的にマークアップする言語として本来の目的を果たすように改められ、見栄えを表現する手段として『CSS』が考案されます。

そして、拡張性、柔軟性に欠けるHTMLの弱点を克服するため、XMLにより独自の意味や構造を持ったマークアップを可能にする言語『XHTML』が開発され、『Semantic Web(セマンティック・ウェブ)』という分野が注目されるようになります。以下、「メタ情報とセマンティック・ウェブ」より引用します。

ウェブは人間が読むための「文書のウェブ」から、様々なデータを自在に発見して利用できる「データのウェブ」へと向かいます。メタデータを適切に与えることで、文書情報をこの「データのウェブ」に組み込むことが可能になります。

「文書のウェブ」は、情報の検索や活用が原始的で単純レベルに留まっているWebページを指し、「データのウェブ」は、その情報が持つ意味を表す『メタデータ』を付加することでコンピュータがより精度の高い分析を行えるようになるWebページを指します。いわゆるセマンティックなマークアップというのは、『XML(HTMLをXML標準に対応させたXHTMLを含む)』によって記述され、その中にメタデータの記述言語を用いて情報の意味付けを行ったものをいいます。

実際は、技術の標準化などに時間がかかることから、利用できるのは先になるだろうと多くの方が予想していたようですが、Webの発展に合わせてそのニーズが高まり『microformats(マイクロフォーマット)』と総称されるマークアップ方式が多くのサイトで採用されてきています。

そのように、W3CはSemantic Webを実現するために技術の標準化を順調に進めていましたが、期待していたほどは普及しませんでした。なぜなら『Ajax』に代表されるようなWebアプリケーションのニーズが、XHTMLによるマシンリーダブルなWebページよりもニーズが高まっているからです。こうした背景の基、新たにHTMLを進化させる仕様として策定されているのが『HTML5』です。

Webアプリケーション

HTML5ではこれまでの後方互換性を保ちながら、進化の土台となる重要な機能を加え、大きなバージョンアップが行われました。以下、主な新機能を列挙します。

Canvas

FlashやJavaのようにプラグインを使わずに、JavaScriptベースでグラフィックを描くことができます。「Chrome Experiments」でデモが公開されています。

Audio/Video

ブラウザで音声や動画の再生を可能にします。プラグインは必要としません。

Web Storage

データをブラウザ側に蓄積する仕組みです。クッキーとは異なり、より大きなデータを蓄積できるため、ユーザーエクスペリエスの向上、サーバー負荷の低減に役立てます。

Offline Web Applications

オフライン時でもWebアプリケーションが動作する仕組みです。ネイティブアプリケーションと同等の機能を提供します。

Webのストリーム化、コミュニケーションのリアルタイム化がトレンドになりつつある現状を考えると、このような進化は自然な流れであるといえます。すでに、グラフィック表現を可能にする『Canvas』は多くのブラウザで実装されていますし、リッチでインタラクティブな3Dアプリケーションを作成するAPI『O3D』という強力な機能も実装される予定です。

メーラーを代表とするネイティブアプリケーションと同等の機能を提供するには、インタラクションを司る『JavaScipt』の進化も必須になりますが、ほとんどのブラウザでJavaSciptエンジンの高速化が進められており、実現する日もそう遠くはないでしょう。

クロスプラットフォーム

Webアプリケーションがネイティブと同等になるのであれば、各々のデバイスに対応するよりも、標準技術を基に汎用性のあるアプリケーションの方が効率的です。今までもWindowsを代表とする様々なテクノロジーがクロスプラットフォームを実現しようとしてきましたが、ついにHTML5によって最大級のクロスプラットフォームが実現するかもしれません。

アプリケーションがハードウェアやOS、モバイルから電子機器などのあらゆるデバイスでサポートされるということは、それだけ開発がシームレスになるということであり、開発コストの低減、素早いサービス展開など、開発者だけでなくユーザーにとっても有益な結果をもたらします。

クロスプラットフォームは、HTML5だけが独占している話題ではなく、AdobeではFlashアプリケーションをiPhoneアプリケーションに変換する「Flash for iPhone」など、Flashをあらゆるデバイスに移植するというプロジェクトを発表しています。また、MicrosoftではPCとモバイル、テレビといったスクリーンをソーシャルサービスと繋ぎ、統一されたインタフェースを実現する「Three Screens and a Cloud」というプロジェクトが注目されています。

このように、ベンダーの戦略に共通するものがあり、改めて時代の変化を感じさせると共に、今後さらに加速化するであろうプラットフォーム競争の覇者となるのはどのベンダーなのか。しばらく目が離せそうにありません。

仕様による標準化

これまでの競争と違うのは、標準技術の仕様に準拠することが前提になっていることです。Windowsが普及した頃は、Windows仕様のアプリケーションを開発するのがスタンダードでしたが、HTML5やJavaScriptという標準技術に基づいて開発されたアプリケーションはプラットフォームに依存しないため、あらゆるデバイスで拡張性の高い開発が可能になります。

標準技術をベースにアプリケーションが開発され、OSやモバイルなど、デバイスに依存しないプラットフォームが普及すれば、市場競争が活発化することで実装の多様化が進み、目覚しいほどの進化が期待できます。

そのようなことから、今後はAdobe 『AIR』、Microsoft 『Silverlight』、そして『Google Chrome OS』上で動作するブラウザをターゲットに開発されていくと思われます。「AIR vs Silverlight vs HTML5」という構図が思い浮かびますが、調べてみたところAIR、Silverlightは共にHTML5に対応する見通しのようです。Google Chromeは当然対応しているので、HTML5はアプリケーションの標準技術として欠かせないものになっていくのではないでしょうか。

アクセシブルなWebへ

新時代のブラウザの登場、モバイルデバイスの普及などによって、Webのストリーム化、コミュニケーションのリアルタイム化が行われ、Webのあり方に大きな変化がもたらされています。そのような時代のニーズに合わせてHTML5という標準技術が公開され、Webアプリケーションの進化、クロスプラットフォーム、仕様の標準化が推進され、着々とTim Berners-Leeが意図したWeb本来の姿に変貌を遂げようとしています。この方向性はW3Cの多大なる努力の結果という見方もできますが、Webが進化する上ではごく自然な成り行きだったようにも思います。

ここまでくればTim Berners-Leeが提唱した「広くあまねくアクセシブルなWeb」の意味が掴めてくるのではないでしょうか。前回の記事で「全方位的なアクセシビリティ」と「コンテンツの供給力」が重要だと述べましたが、これまでのことを踏まえてそれぞれ解説してみます。

【全方位的なアクセシビリティ】

基本方針として高齢者や障害者への配慮、多様な機器やディスプレイ、ブラウザで利用できること、これらを企画から運用に至るプロセス全体で常に考慮すること

簡潔にまとめると「あらゆる環境に配慮し、誰にとっても使いやすい方法で情報を提供すること」です。まず、ハンディのある方々への配慮というように、バリアフリーという観点では認知されてきていると思います。

ただし、高齢者や障がい者など身体に障害や不自由がある方々のための対応というよりは、最低限の使いやすさを確保するために必要な指標という方がしっくりきます。例えば、駅に設置されているエレベーターは、高齢者や車椅子を利用されている方々はもちろん、健常者にとっても便利なものです。それをWebの世界に還元すると、アクセスした誰もが容易に情報を共有できるようにするということになります。

多様化が進むWebの世界でそのような取り組みがより求められていることは既知の事実であり、その中心にいるのがW3Cです。W3Cの取り組みによって、あらゆるデバイスで共通化を行うクロスプラットフォーム、環境に依存しない技術の標準化が進み、全方位的なアクセシビリティが現実的なものになってきているのです。

【コンテンツの供給力】

前回の記事で「『Progressive Enhancement』は、コンテンツそのものに重きを置き、Webの本来の能力を最大限に生かそうという試みなのです。」と述べましたが、コンテンツとは何を意味するのでしょう。以下、「Webアクセシビリティについて」より引用します。

基本的要件として、視覚、聴覚、身体のハンディにかかわらずコンテンツを操作・利用できること

この引用分では、ハンディがある方への対応という捉え方をしてしまうかもしれませんが、上記と同様、誰か或いは何かのデバイスに特別な対応をするということではありません。「広くあまねくアクセシブルなWeb」とは、クロスプラットフォームや標準化によって、あらゆる環境下でWebを閲覧できるということも一つありますが、最も本質的な部分は『コンテンツ』にあります。

ここで以下のような階層で囲まれた円を想像して欲しいのですが、最も内側にある階層がコンテンツであり、それはセマンティックなHTMLでマークアップされたものだと思ってください。コンテンツを包み込んでいる真ん中の階層は、CSSによって"見栄え"を整え、さらに全体を包み込んでいる外側の階層はJavaScriptによって"ふるまい"を与えます。

Webアプリケーション及びWebサイトの土台として、基本的にこの3つ要素が関わっており、最も深く、中心にあるのがコンテンツです。Webの世界はグーグルボットに代表されるクローラーというプログラムによって成り立っています。Web上にある文書や画像などの情報を周期的に取得し、データベース化、インデックス化を行います。要するに彼らはコンテンツだけを求めています。

また、高齢者や弱視の視覚障害を持つ方、特に全盲の方は、当然視覚が確保できないので音声読み上げソフトを利用してWebサイトの情報を取得します。それでも画像や動画などの情報は読み上げることができないので、alt属性などに情報を付加したりするなどの配慮が必要になります。繰り返しになりますが、多様な環境で利用されるWebの世界では、コンテンツが全てです。Webサイト上で、情報を発信、普及、収集、要求したりするのには、コンテンツというレベルでの情報提供は必須なのです。

今後、技術の進展により様々な実装の登場とそれらの競争が予想されますが、コンテンツの供給においては、技術云々の問題ではなく私たち制作者側の意識によって良くも悪くもなります。より良い情報伝達を行うためには、Webアクセシビリティ確保の必要性を認識し、利用者側の立場に立つことが大切だと思います。それこそターゲット層云々の問題でもなく、私たちが例外なく空気を必要とするように、Webという世界で過ごすために必要なものは何なのか、もう一度振り返って考えてみる必要があるのではないでしょうか。

HTML5の実際

Webアクセシビリティの重要性が高まっていく世の中で、情報伝達すらも儘ならないようなWebサイトは、収益機会を逃すだけでなく、自社の信用を落とすことにも繋がります。では、コンテンツを供給するために必要な「セマンティックなマークアップ」とはどのようなものをいうのでしょうか。Webアプリケーションの項目で「Webアプリケーションのニーズが、XHTMLによるマシンリーダブルなWebページよりもニーズが高まっているからです。」と述べましたが、だからといってSemantic Webが切り捨てられるという訳ではありません。

HTML5では、section、nav、aside、header、footerなど、セマンティックなタグが追加され、より論理的なマークアップが可能になります。これらのタグを利用することで、単純に構造が分かりやすくなるなどといった表面的なメリットだけではなく、クローラーが文書の内容をより正確に収集できるようになり、検索の精度が格段に向上するという恩恵を受けられます。コンピュータにやさしいマークアップは最終的に人間にとってもやさしいものになるのです。

HTML5は2022年以降にW3C勧告に至ると言われていますが、「Browser support for CSS3 and HTML5 CSS3 and HTML5 feature support」というサイトでHTML5の対応状況を見る限り、それまで全く使えないということはなさそうです。新世代プラットフォームである『Google Wave』や『Web Kit』などがHTML5を駆使した仕様になっているということもあり、Firefox、Safari、Opera、Google ChromeなどのモダンブラウザでHTML5の実装が進んでいますし、Microsoftの次期ブラウザである『IE9』も標準技術に準拠するという意向を示しています。

また、JSライブラリを使用すれば、今すぐにでも以下のような機能を利用することができます。現状では、JavaSciptエンジンに依存していますが、プラグインが必要なくなるのも時間の問題だということです。

typeface.js

テキストをSVGに自動置換してフォントを表現するライブラリ

Bluff

Canvasを用いてグラフを描画するライブラリ

raphael

SVGでチャートグラフ、円グラフなどの曲線をベクターとして扱うことが可能になるライブラリ

280 Slides

280 Slides
PowerPointをWEBアプリケーションとして実現するライブラリ

Processing.js

Processing言語をJavaScriptに流用したライブラリ

cpick.js

色を選択するためのカラーパレットを表示するライトウェイトなライブラリ

progress.js

プログレスバーを表示するライトウェイトなライブラリ

border-radius.js

class属性に値を追加するだけで、ブロックボックス要素の角を丸くするライトウェイトなライブラリ

table.js

class属性に値を追加するだけで、テーブルの通常行の背景色をストライプ状にし、各行をクリッカブルにするライトウェイトなライブラリ

radar.js

canvas要素でレーダーチャートを描画するライブラリ

他のライブラリはJavaScipt ライブラリー - HTML5.JPからどうぞ。

最後に

Webが時代を終わらせ、Webが時代を作り始めている今日、あらゆる業界に多大な影響を与えていることと思います。時代の変化に合わせて新しい技術が生み出され、誰もがインターネットを持ち歩く世の中になりました。そうした時代の覇者になるべく、大手ベンダーは自社の技術を駆使し、凌ぎを削り合っています。そして、私たちWeb制作者はそうした変化に合わせて、パラダイムの転換を行わなければなりません。

ここにきてやっと、Tim Berners-Leeが望んだWebのあり方に時代が追いついたという感じがしてなりません。「Webのあり方」という地図があったとして、私たちはしばらく間違った道を半ば開き直りながら進んでいたのではないでしょうか。誤った道をどんなに効率的に進んでも、行き着くところは誤った目的地です。ティムの手元には何年も前から正確な地図があり、長い年月をかけて私たちを正しい道に戻してくれたのです。

しかし、進むべき道がが明確になったとはいえ、順風満帆にことが進むとは限りません。多くの誘惑が出てきて、道を塞ぐこともあるかもしれません。そうした中で心がけることは、正確な地図をなくさないということです。どんなに遅くても、寄り道しても、正確な地図さえあればいずれ目的地に到着することができるのです。『Progressive Enhancement』という考え方が広まっていることも、一つの道標です。迷子にならないようにしましょう。

頭の整理をしようとして、アウトプットをしていたらこんなに長文になってしまいました。何だか宗教の信者ｗのようになってしまいましたが、少しでもお役に立てれば幸いです。

HTML5やJavaScriptなどの標準化が進み、Google ChromeやFirefoxを始めとするWebブラウザが我先にとテクノロジーの進展に努めています。このまま表現力の向上、高速化が進めば、スタティックな文書を閲覧するだけではなく、ダイナミックなWebアプリケーションとして新たなプラットフォームを築く日もそう遠くはないでしょう。Webアプリケーションといえば、2004年頃に公開されたGMailを筆頭に、カレンダーやワードプロセッサなど、様々なアプリケーションがWebブラウザ上で活躍してきましたが、今やネイティブアプリケーションとほぼ同等というところまで技術が進化しているということなので驚きです。

それはつまり、標準技術を基に汎用性のあるアプリケーションをシームレスに開発できる環境が整うことを意味しており、PC、モバイル、家庭用電子機器など、あらゆるデバイスが共通のプラットフォームを持つということになります。そんな中、『Progressive Enhancement』という考え方が注目されてきています。

Progressive Enhancementとは

では『Progressive Enhancement』とはどのような考え方なのでしょうか。

以下、Graceful DegradationとProgressive Enhancement | Web標準Blogより引用です。

ターゲットとするすべてのブラウザーに対し、最低限伝えるべき機能を実装します。その上で、より高水準の環境（ブラウザー）では、高い機能を体験できるように機能強化をおこないます。

つまり情報やサービスへのアクセシビリティを確保し、高水準のブラウザ、デバイスにそれ相応のデザインやインタフェース、技術を実装しようという考え方です。それに対して今まで主流であったのは『Graceful degradation』という考え方です。

Webサイトで表現したい機能を、特定の水準にあるモダンブラウザーに対して提供します。しかし、低水準の古いブラウザーに対しても、同等ではないもののそつのない、または理にかなったかたちで機能を提供します。

クロスブラウザ＝どのブラウザでも同じようにするという考え方は、制作コンセプトとして当たり前のものになっています。高水準のブラウザで表示確認を行い、下位ブラウザやデバイスの対応を行うというフローが一般的なのではないでしょうか。

別段、それが悪いということではなく、どちらの考え方もWeb体験をより良く提供しようという前向きなアプローチが取られています。両者の違いは、制作コンセプトにおける観点にあります。前者は、コンテンツありきの考え方で、後者はクロスブラウザありきの考え方です。

また、あらゆるデバイスの基盤技術がWeb標準に統一化されていく中で(もちろんデバイスごとにカスタマイズする必要はありますが)、見栄えやふるまいに重きを置くのはスマートなやり方とは言えません。『Progressive Enhancement』は、コンテンツそのものに重きを置き、Webの本来の能力を最大限に生かそうという試みなのです。Tim Berners-Leeが掲げた「広くあまねくアクセシブルなWeb」がようやく実現に向けて走り出したということでしょうか。

次回から『Progressive Enhancement』の考え方に基づいて、技術的な観点からWebのあるべき姿について考えていこうと思います。

今まで、我流でサイト分析を行っていましたが『デザインイング・ウェブナビゲーション 』や『IA100 _ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計』など、情報アーキテクチャに関する参考書も豊富になってきたところで心機一転、それらをバイブルに実践を通して体系的に学んでいこうと思います。

ファッションレッグウェアブランド「Relish」の2009年秋冬コレクションサイトです。個人的に好きなブランド(ストッキングを身につけるわけではありませんが...)ということもあり、以前からチェックしていたのですが、久しぶりに見てみたらFLASHベースのプロモーションサイトから、柔軟性のあるHTMLベースの静的なブランドサイトにリニューアルされていました。

ビジネスゴール

レッグウェア事業、インナーウェア事業、介護用品事業など主とする『アツギ』がプロデュースする人気ブランドの一つが「Relish」であることからみて、ブランドイメージを高め基本的な主張を広めるという目的があると思います。また、今回のリニューアルから予想できることは、顧客ロイヤリティを向上させるという狙いがあるのではないかということです。HTMLベースの静的なブランドサイトにする利点は、来訪したユーザーがウェブサイト上で獲得できる最終的な成果である「コンバージョン」を意識した動線設計が行えることです。事業活動を支援するマーケティングツールとしてWebサイトを活用するのであれば、具体的な数値的目標、すなわち「コンバージョン率」をモニターし、実際にビジネスゴールに貢献するだけのコンバージョンが達成されているかどうかを明示する必要があります。「Relish」のようにある程度のブランドイメージが認知されている場合、次のステップとしてすでに抱えている顕在ユーザーの顧客ロイヤリティを向上させるというマーケティングは理にかなっていると思いますし、ログ解析によって費用対効果が明確になるという意味でも、ユーザーに与える価値の成長が見込める良いサイト事例だと思います。

サイトストラクチャ

図を見て分かる通り、コンテンツが少なく階層レベルが浅い構造になっています。「Relish」にサイトマップがないのは"必要ないから"ということなのでしょう。階層構造のバランスには、明白なトレードオフがあり、表示する項目を減らせば階層は深くなり、項目を増やせば浅くなります。一般的に後者の方が効果的に機能しますが、選択肢や項目をグループ化して焦点を絞り、ユーザーがより効率の良い経路で目的に到達できるようにするという意味では当たり前のことです。ただし、むやみに項目を増やせば良いということではなく、あくまで必要最低限の探索で済むように、選択肢を"最適化"するという視点を持つべきです。

ナビゲーション

「Relish」で特徴的なのは、主導線である『秋冬コレクション』や『キャンペーン』がそれぞれのカテゴリで副導線としても機能しているということです。複数のアクセスポイントを持つことにより、よりスムーズな情報探索が可能になるだけでなく、関連リンクとしてショートカットの役目も果たします。そうしたナビゲーション設計から、情報の優先順位、つまりユーザーをどのように導きたいのかを伺い知ることができます。メインコンテンツとなるのは、やはりシーズンごとに更新される「コレクション」なので、メインナビゲーションでは一番左、ローカルナビゲーションでは一番上に位置しています。Webの文書構造が、上から下に読まれる構造であること、左上から順に読まれるというヒューマンインタフェースの特性から、優先順位の高い項目を左から順に配置するのは、ナビゲーションシステムにおけるデファクトスタンダードとなっています。ビジネスゴールが顧客ロイヤリティの向上と記しましたが『ダウンロード』やキャンペーンはまさにそれを裏付ける主要なコンテンツではないかと思います。キャンペーンでは「季節スタイリングを見て、好きなスタイリングを選んでください。」とあり、『季節スタイリング』への導線を確保しています。Relishの商品はオンラインストアでも購入できるようなので、そこから購買に繋げるという狙いがあるのかもしれません(ただし、商品詳細ページでは品番しか明記されていないので、カタログを持ってるコアユーザー向けのコンテンツである可能性もあります)。ダウンロードでは、クオリティの高い壁紙やスクリーンセーバーを無償でダウンロードすることができます。おそらく壁紙もシーズンごとに更新され、ユーザーに「また見たい」という動機を抱かせる伏線になるのだと思います。

分析しながら、誰に対して、どのような情報を、どのように伝えるかという「ユーザーへ与えたい価値」が明確なサイトだなぁと思いました。不要な要素がそぎ落とされ、必要なものだけが残ったような、シンプルイズビューティフルの本質的な素晴らしさに触れられたような感じです。ところで「こころまでも、あたたかく写真集」がもらえるキャンペーンはもう終わってしまったのでしょうか。。「Relish」の商品も好きですが、毎回写真が素敵すぎるんです。

web2.0に対応した新しい情報サービスアプリケーション・ webコンテンツの可能性への共同トライアルとして、広く世の中の叡智を募るために設けられた「MASHUP AWARDS」で審査員特別賞、優秀賞を受賞した作品「100kw & sgss » CastOven」の公式サイトです。本来マッシュアップという用語は、音楽用語で「複数の音源を組み合わせる」意味を持ち、それをテクノロジーの世界に置き換え、「複数のWebサービスを組み合わせる」という意味の造語として広まったそうです。例えば、よく事例として挙げられるGoogleマップのAPIは、天気予報のAPIを組み合わせた「Weather Bonk」や不動産のあAPIと組み合わせた「HousingMaps.com」などがあります。Web サービスのAPIを組み合わせて新しいサービスを生み出すマッシュアップですが、100kw & sgss » CastOvenを見て思ったのは、単なるWebサービス同士のフュージョン(ドラゴンボールのアレです。個人的にしっくりきたので使わせてくださいｗ)ではなく、もっと広義な意味で使われるようになっているのかな、ということです。それというのも、iPhoneやミニノートなどのインターネットデバイスが浸透し、今では誰もがインターネットを持ち歩いています。日常の中にインターネットがあるのが当たり前の世の中になってゆくにつれ、マッシュアップという言葉の概念も、Webサービス同士のフュージョンという狭義な意味から、Web世界とリアル世界のフュージョンという、もっと広義な意味に変わってきているのかなと思います(極端な話ですが‥)。100kw & sgss » CastOvenを例にとると、youtubeというWeb世界のサービスとリアル世界の電子レンジという調理機器がフュージョンを成功させ、まさに新しい価値を提供しています。これは疑う余地もなくマッシュアップだと思いますし、大規模なアワードで優秀賞を受賞しているという事実からも、そうした認知がされてきているということが示唆しています。この分だと100年後には人間自身にgoogleが備わっているかもしれないですね(笑)。

女性のための興奮剤ｗ「K-Y Brand Intense」のプロモーションサイトです。"REACTION ROOM"や"AROUSAL LAB"に入室し、パソコンなどの物体に「K-Y Brand Intense」を垂らすと、それぞれユニークなリアクションを楽しむことができます。その製品によってもたらされる効能を面白おかしく表現するという発想は、インテルやフリスクのCMと似ていますね。こうした何が起こるか分からないワクワク感を盛り込んだ作品は映像であれWEBであれ好奇心が煽られます。 ユーザーエクスペリエンスを唱えた認知心理学者、ドナルド ノーマン（Donald A. Norman）氏は、作中で「デザインは情動的(エモーショナル)であれ」と唱えています。そうした感動を与える、インパクトを与える、所有欲をそそるなどといったエモーショナルなユーザーエクスペリエンスは、双方向的なコミュニケーションを可能にするFLASHコンテンツならではの演出だと思います。前回FLASHの利点を生かした「TOYOTA SAIスペシャルサイト」では主に音声や映像を駆使した技術的な面での利点を述べましたが、「K-Y Brand Intense」ではインタラクションとしてのFALSHの魅力が十分に伝わってくる良い事例でした。

フリスク CM

インテル CM

トヨタの新型車「SAI」のスペシャルサイトです。音声、映像を駆使して、FLASH特有の価値を提供し、リッチコンテンツが得意とする情動的(エモーショナル)な演出が成されています。ビジネスニーズにブランド価値の向上は含まれていると思いますが、サイトゴールは"INFORMATION"から関連リンクやSAI展示情報へ誘導することではないかと思います。そこからお問い合わせに繋げる、資料請求につなげる、展示場に足を運んでもらうなどの導線が確保してあるのかもしれませんが、重要なのはFLASHを活用するのはあくまでも「手段」であって「目的」ではないということです。最終的にユーザーをどこに導き、コンバージョンを得るのかというサイトゴールは、ビジネスニーズ、ユーザーニーズを把握し、戦略的に導き出す必要があります。FLASHを活用すること、映像を活用すること、音声を活用することが目的になってしまい、コンバージョンがまるで意識されていない「アート作品」のようなサイトをよく見かけますが、そういうサイトはこれから淘汰されてくのではないかと考えています。WEB業界でインフォメーションアーキテクチャやエクスペリエンスデザインが注目されているのは溢れている情報の整理という以上に、"出来る限り無駄な費用は抑えたい"というクライアント側の意図も反映されているのではないかと思います。実際、今日のWEB制作会社では、新規案件、リニューアル案件が減っていき、サイト内の一部をリニューアルしたり更新したりする運用案件が増えているようです。それはプロモーションサイトに活用されるFLASHサイトも例外でなく、何のために立ち上げるのか、誰が使うのかを把握した上でインタラクションを考え、戦略的に設計する必要があるでしょう。

前置きが長くなりましたが「SAI」はFLASHの特性が活かし、静的なサイトでは伝わりにくい情報が体感的に伝わるサイトになっていると思います。体感的にというのは、音声によるアナウンスに沿って映像が展開されるユーザーエクスペリエンスを指し、環境性能、スタイリング、インテリアという3つの最適化された"売り"のどれかを選択するだけで、情報を探索する必要がない直観的なインタフェースとなっています。だからといって受動的なわけではなく、マウスポインタに早送り、巻き戻しボタンが配置されているので、能動的に操作が可能です。また、タブインデックスでの操作が可能、音声のみでなく字幕がある、ナビゲーションにマウスオンすると音声で知らせてくれる、アクセスした際に音声を調節できるなど、FLASHサイトにおけるユーザービリティ(ここでは操作上の使いやすさを指します)においても非常に参考になります。FLASHの利点を上手く活用した良い事例でした。

何の変哲もない一般的なブログかと思いきや、画面の下部にナビゲーションが固定されています。ブラウジングをしながら、ふとテレビのリモコンを操作している感覚と似ていることに気がつきました。ブログの普及によって、ある程度はお決まりのひな形というものが認知されているとは思いますが、内容はもちろん、デザインもインタフェースもブログごとに異なるため、必要な情報を探すタイムロスはどうしても出てきます。コーポレートサイトなどのデファクトスタンダードであるナビゲーションシステム、いわゆる「メインナビゲーション（或はグローバルナビゲーション）」もブログにはサイドコンテンツのカテゴリ一覧という位置づけで提供されているケースが多いので、ファインダビリティはやはり低くなります。Adii Rockstarでは、ナビゲーションを固定させているので、スクロールをする機会さえ与えれば、ナビゲーションをすぐに見つけることができます。「固定する」というテクニックは、割と簡単に実装できるし、アテンションとしてかなり有効なので覚えておきたいですね。そして、その後はテレビのリモコンを操作するように、見たいチャンネルを選ぶだけという手軽さが手に入り、一切のフラストレーションを感じずにブラウジングすることができます。情報がいくら分かりやすくても、見つけられないと意味がない、見つけやすさがあるからこその分かりやすさということが改めて確認できる良い事例です。

分かりやすさについてですが、Adii Rockstarのメインナビゲーションでは、文字情報だけでなく、色情報、アイコンなどを用いてより明解さを高め、アクセシビリティにも配慮された設計が成されています。それだけでなく、"Qyites"カテゴリの右隣にカテゴリ内を移動するための機能的なナビゲーションも用意されています。また、このメインナビゲーションに適用されているルールが、サイト全体でも反映されている点も素晴らしいです。例えば、各カテゴリの色情報は記事のアウトラインとして強調され、アイコンはアテンションとして上手く機能させています。そうした一貫性は、サイト全体の学習しやすさや効率を高め、ユーザーの情報探索経路を大幅に短縮させてくれるでしょう。

メイベリン ニューヨークがおくるマスカラWebマガジンVol.07が公開されました。ムラサキ×イエローというインパクトある配色だったので、思わずムラスポかと思ってしまいましたが、どうやら最近話題の西野カナとのコラボのようです。タイポグラフィやグラフィックが雑誌のように表現されているのが特徴的で、そのクオリティの高さに毎回圧倒されてしまいます。特集コンテンツもそれぞれにユニークなデザインが当てられ、まるで雑誌を捲っているような感覚を覚えます。こうした雑誌風のデザインを、Webデザインでどう表現するのかということにおいて、非常に参考になるサイトです。また、以下のURLからアクセスするとまずCMのようなFLASHが展開されるのですが、これもマスカラマガジンならではの大胆さですね。デザインコンセプトにブレがないのが分かります。