あらゆるデバイスに対応できるWebデザインの考え方

あらゆるデバイスに対応できるWebデザインの考え方

続いてのスピーカーはDan Cederholm（ダン・セダーホルム)氏。あらゆるデバイスに対応するWebデザインとして、同氏が用意したテストサイトを例にソースコードを引用した説明が行われた。

Dan Cederholm（ダン・セダーホルム）氏

テーマは「CRAFTMANSHIP」。職人が織り成すワザと同じように、Webを家具にたとえ、実際に使ってみないとその良さはわからないと語る。彼は今回の講演のために用意したサイト「ICED or HOT」を例に挙げて説明を始めた。

Dan氏のプレゼンは一風変わったもので、トピックとなるセンテンスの頭文字をA-Zに並べて順に説明していった。”B”は「border-radius」プロパティ、日本語でいうと「丸角」を指す。CSS3での標準のプロパティとして取り入れられることが検討されているものだ。すでに一部のブラウザにはその機能が選考で実装されている。続く”C”ではColorの透過性に関する「RGBa」プロパティの設定手法などを紹介していった。

しかし、各種のブラウザが標準化を目指してはいるものの、古いブラウザを使用している場合は、上記のようなリッチな表現には対応していない。だからといって表示を損ねることは許されず、どんなブラウザでも一定の表示を保ったうえで、より先進的なブラウザに対しは積極的にこういった取り組みを推し進めたいとした。「Progressive Enhancement」と呼ばれる考え方である。

また、これらの取り組みは、いつどの段階で行うのが適切だろうかと客席に問いかけ、それにはサイトのアクセス解析の結果をみるようにと示唆した。自社サイトへのアクセスの内、IE6の比率が半数以上を占めているようならば、今まで説明してきた最新の機能のほとんどが動作しない。では、反対にFireFoxやSafariのシェアが高かったらどうだろうか？……ブラウザのシェアをみて、注意深く判断する必要があるだろう。

Ajaxありきの設計はユーザーの混乱を招く恐れもある

午前最後のセッションはJeremy Keith（ジェレミー・キース）氏による、Ajaxの設計に関する講演。Ajaxの導入が進む中、まずはAjaxを利用しない前提で作りはじめるのがベターだと説いた。

Jeremy Keith（ジェレミー・キース）氏

Ajaxの定義は、「サーバーとのトランザクション上でページをリフレッシュしない構造」つまり、XMLHttpRequestに対してダイレクトHTMLでページの一部だけを書き換えるものである。ページ内のデータ更新を一部にとどめることにより、ページの表示速度が向上する“イメージ”をもたせ、ユーザーのストレスを軽減する役割も持っている。

Ajaxは革新的な技術ではあるが、開発側は常にブラウザのJava Scriptが無効になっているかもしれないことを念頭に置かなければならない。Ajaxを用いていないWebサイトも用意する必要があるだろう。Ajaxを利用したサイトを作成するときは、はじめからAjaxありきで考えてはならない。サイトが仕上がったうえで本当にAjaxを適応するのがいい部分にだけ適応するのが望ましいとした。

たとえば、以下のような場面ではAjaxの活用は効果的といえる。

• ユーザー登録画面での既存アカウントの確認
  ユーザー名の入力中に「そのユーザー名はすでに使用されています」と表示
• 物販サイトでカートに商品を追加したとき
  追加した商品の金額がカートに即座に反映

では検索結果（※サジェスト機能ではなく検索結果を表示するページ）にAjaxを使用するのはどうだろうか。ジェレミー氏が言うにはあまりお勧めできないとのことだった。

Ajaxのような機能を実装すると、ユーザーに何でもできると思い込ませてしまう節もある。ユーザーはデスクトップ環境でできるものはすべてブラウザ上でもできることを期待するのだ。ブラウザ上でドラッグ＆ドロップをしてしまったことはないだろうか。また、Ajaxの弊害として、一つ前の肯定に戻ろうとするときに、ブラウザの「戻る」ボタンを押して、そのページ以前のページに戻ったり、うまくブックマークできなかったりする問題があることをあげた。サイト内のどの部分にAjaxを活用すべきかを決めあぐねているのなら一度ユーザーテストを導入することをお勧めするとしてセッションを終えた。

高効率・低コストで行うユーザビリティテストの仕組み

Jeremy Keith（ジェレミー・キース）氏の講演でも、重要視されていたユーザーテストであるが、Andy Budd（アンディ・バド）氏が効果的なユーザーテストのやり方に関するセッションを行っていた。

Andy Budd（アンディ・バド）氏

アンディ氏は、航空機のチケット発行機の操作画面が非常に使いにくかったために、飛行機に乗り遅れそうになったという自身のエピソードをあげて、コンピュータの処理能力の向上に伴い、インターフェースも考えなければならないと説く。使いにくい機械を責めるのではなく、ましてうまく操作できない自分自身を責めるのでもない。開発時点でのエラーを考え、ユーザーが間違えないような仕組みを作らなければならない。

ユーザーは一般的にはマニュアルは読まず、既存の考え方や使い方が潜在的に働くものである。Webでも同じことが言え、新しい技術が登場したときは、ユーザーは古いしきたりをあてはめてみるものだという。そして新しい技術を試してみることから新しい技術が習得されるのである。ただし、ユーザーがWebサイトをみているときに、ユーザーは何らかの外部要因にさらされていることを考えて開発を行うことが重要である。どこでフラストレーションになっているのかを判定しなければならないのだ。

そういったときに検証が必要となり、ユーザーテストが重要なのだ。

Microsoft社の大ヒットゲームとなった「Halo3」では、開発の際に大々的なユーザーテストが行われたという。600人の被験者に対し、のべ3000時間以上もの時間とその分のコストを費やしたが、それが結果的に3億ドルという売り上げにつながったとしている。

従来のユーザーテストは、たとえば司会者がグループインタビューを行いミラー越しの部屋でビデオを回して観察するというのが一般的であった。しかし、このやり方では、時間がかかりすぎて、なおかつ対象者を集めるのが大変である。多くの被験者の定量データのみで判断する必要があり、個別の問題点を調べられないといったデメリットがある。

一方、ユーザビリティテストは、従来のテストと比べると簡単で安く、短時間で検証が可能だ。そして、検証結果をまとめる必要がないのですぐに反映させることが可能となる。ただし、対象者の選出はネックであり、偏見がある可能性も考えられる。以下の注意点を参考に、テストの実施を検討して欲しい。

ユーザビリティテストを行う際の注意点

• ユーザーに状況を大きな声で発表してもらう
  →何を考えているのかオープンにしてもらう
• ユーザーの個人的な意見ではなく、利用方法を観察することによって、何を考えているのか、何を判断して操作しているのかを導き出す
  →ロゴやデザインに関する意見を集めているのではない
• ユーザーから何も得られないことが最も危険
  →なるべく早くその問題点を洗い出すことが重要
• テストは最低でも5～6人を対象に行い10人いれば十分だろう
• タスクを選ぶだけ（ECサイトでものを買うとき、SNSサイトで登録を行うときなど）
  →ストーリーを作り、ユーザーが自ら考える方向に進める。ルールだけ設定し指示は出してはいけない
• テストが終わった後は寝かせてはいけない
  →月・火でテストをして、その週のうちには修正するくらいのイメージ