今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、どんな講演内容だったのか教えてください

「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」

「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」

「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」

「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」

「どのような実例でご説明されたのでしょうか？」

「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。

よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」

「先に知っておけば、そういう落とし穴には落ちないということですね」

「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」

「そうなってしまうのは、楽だからなんでしょうか」

「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」

「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」

「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。

アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」

「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」

「そのピンク本、ありがたいことに私の著書なんです(笑)」

「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」

「ディレクターさんにもすごくいい本ですよ」

「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」

「なるほど！読みます！」

「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」

「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」

「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」

「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」

「そうですね。それを解消するためにも、ぜひ！」

「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」

モダンなウェブとアクセシビリティは両立できますか？

「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」

「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」

「自然と優先度が下がっちゃう、というかんじですね」

「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」

「そういうことですか！」

「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」

「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」

「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」

ところで、普段はどんなお仕事しているんですか？

「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」

「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」

「企業の公式Webサイトですね」

「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」

「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」

「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」

「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」

「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」

「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」

「原さんは、どんなお仕事をされているのですか？」

「私は完全に開発者で、2004年からずっとアメーバブログを作っています」

「長いですね！」

「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」

「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」

「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」

「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」

「かなり」

「そうですね」

お二人の情報収集や勉強方法を聞かせてください

「お二人はどのように情報収集や勉強されているんですか？」

「今まさに勉強しているつもりです」

「そうそう。かなり勉強してます(笑)」

「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」

「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」

「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」

「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」

「もちろん、全部を読むわけではないですよ」

「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」

「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」

「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」

「なるほど！」

「簡単に希望したところに行けるかはわからないですけど」

「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」

「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」

「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」

「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」

「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」

アクセシブルなサイト設計・制作について教えてください

「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」

「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」

「はい。で、書きながら実行してるんですよ」

「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」

「完全に素のやつですよね」

「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」

「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」

「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。

それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」

「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」

「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」

「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」

サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？

「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」

「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」

「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」

「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」

「構造も何もあったもんじゃない(笑)」

「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」

「ある意味うらやましいですね(笑)」

「昔はありだったんでしょうか」

「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」

「あれはフロートがなかったからとかそういうことだったんでしょうか」

「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」

「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」

「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」

「モバイルが出てきてWebkitベースで確認できるようになって…」

「それ以前はもうぐっちゃぐちゃですよね」

「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」

「ピクセルパーフェクトってやつですね！」

「聞いたことあります」

「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」

「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」

「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」

「ぜひ、勉強します！」

「CSSが一番難しいですよね」

「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」

「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」

「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」

「CSSについても書いてありますか？」

「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」

「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」

「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」

「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」

UIを考える時に一番気をつけるべきことは何ですか？

「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」

「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」

「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」

「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」

「ありがとうございました！」

2014年3月22日、リクルートメディアテクノロジーラボ (MTL) にて、デザイナーとエンジニアでつくるWebプロトタイプとユーザーテストを行うイベント「デザイニアン002」が開催されました。

プロトタイピング作成の意味と利点とは

プロトタイプ作成で得られる利点は、早い段階で設計を多様な角度から検証し、企画や機能を実際に体験することでユーザーからフィードバックを得て問題解決に役立てられることです。

可能な限り早期に問題を見い出して、制作の工程を最終的には早くて手戻りのないものにする。そして、検証結果から多くの問題を修正することで、ユーザー体験をより理想の形に近づけることが可能となります。

はじめに部長の秋葉さんより、イベントの趣旨／本日の流れ等の全体の説明が行われました。

以前ご紹介した「html5jデザイン部が目指す、ユーザー体験も含んだデザインを実体験で学べるイベントとは」と同様、「JRの新幹線予約サイト『えきねっと』を、目的の新幹線チケット購入までたどり着きやすくする」を課題にし、

1. 課題のサイトの問題の洗い出し
2. 情報整理と仮説
3. プロトタイプ作成
4. ユーザーテスト
5. ヒアリング　

の流れで行いました。

エンジニアの方には、デザイン部エンジニアが少ない時間の中で、できるだけ早く進められるようイベント用に用意したテンプレートを渡し、作業してもらいます。

説明の後に、デザイナーとエンジニア2～3名ずつのチームを作り課題に入りました。

前半はそれぞれのチームでディスカッション。

後半は、デザイナーとエンジニアが各々の担当分を制作していきます。

18時には、テストユーザーの皆さんが到着。各チームに1人テストユーザーが着席し、課題で作成したプロトタイプを操作していきました。

一通りテストが終わったところで、各チームごとに何に問題を感じ、どのようなコンセプトでつくったのかをプレゼンテーション。テストユーザーの方には、操作した感想を発表していただきました。

チーム1）　不必要な機能を削除し、画面をわかりやすく

どんなふうに到達するのが違和感ないのかを考え、不必要な機能を消し必要な機能のみで作ることにした。制作者側として画面の流れはわかりやすくなったかと思いましたが、デザインを適用する時間が足りなかった。乗車する日にち選択で、テストユーザーの方の「iPhoneの”ドラムロールUI（※1）”はわかりづらい」という意見が参考になった。

※:iPhoneの”ドラムロールUI
　正しくはDate Pickersと呼ばれているUI。HTMLのselect要素を使ったときに出てくるUIを本記事では「ドラムロールUI」と呼称しています。

[テストユーザーの感想]
ビジュアルとしてはっきりしておらず、薄い線などで見にくいと操作がしづらい。iPhoneのドラムロールUI式カレンダーは使いにくい。ネットに慣れていない人間は緑の窓口で購入する機会が多く、自分の記憶の中から勝手に窓口でのイメージを求めてしまうため、券売機に近いデザインの方がエンドユーザーには使用しやすい。

チーム2）　無駄なスペースを削り、スクロールを減らす

入力フォームの項目に関しては縦並びにせずに、画面の横につめられる内容のものはつめて、少ないスクロールで必要な情報を見られるようにした。検索結果のボタンの色が変えて、わかりやすくと考えた（時間不足で未実装）。

[テストユーザーの感想]
チケットの有無を「○」「△」「×」で表示する方がわかりやすい。
検索結果に時間が何時から何時と出ているのがわかりやすかった。料金の比較もあるとわかりやすい。
自分が医療関係者なのでその視点で考えると、障碍者は対人コミュニケーションを避ける傾向があり、窓口での購買よりもスマホ使うことが多いと思う。白内障や色盲の人には白と黄色の組み合わせが判別しにくいので、スマホサイトに背景が黄色で文字が白、といった組み合わせは避ける方が好ましい。

チーム3）日付と時間をわかりやすく設計

ユーザーが何をしたいのかを重要視した。日付と時間がわかりやすいことが重要と考えて、画面一番上にした。クリックしたら表示されるようにしたが、反映しきれなかったので迷わせてしまった。
流れを直感的に予約できるようにし、必要な情報をしぼることを心がけた。時間がなくデザインが当て込めなかったが、ユーザーは意外にわかってくれるということもわかった。

[テストユーザーの感想]
最初つまづいたが、使っているうちにわかった。時間不足で機能していないボタンがあったので、どうとればいいかわからなかった。

チーム4）操作しにくいラジオボタンから、押しやすいボタンに

検索画面のわかりやすさを考えて操作順にタブ式に選択できるようにした。スマートフォンではラジオボタンでの操作はしにくいという判断をして、ボタンとして押しやすいように制作した。
往路を購入する場合は一度に往復を購入するのではなく、まず往路を購入し、片道を購入してから復路を買うボタンと完了ボタンを作り、ユーザーが動線を迷わないようにした。

[テストユーザーの感想]
やっぱりiOSのドラムロールUIの操作がわかりづらい。Androidの方が日にちを選びやすい。

チーム5）　ぱっと見た瞬間に空席が表示される

UIの要素を極力減らしてシンプルにする方向にし、不要な要素は削除した。ぱっと見た瞬間に必要な情報がある程度出るように考え、席がどの程度空きがあるかを表示するようにした。階層的に選べるようにした。

[テストユーザーの感想]
空席を探した時に「○」「△」「×」が表示され残席数がおおよそわかる点が良かった。指定席の空席がないとわかった時点で、そこから再検索できれば使いやすいと思う。
ボタンが小さくて狙ったところを押せないとストレスになるので、大きめのボタンの方がよかった。ロード中にロードしていることがわかるようになっていると良いと思いました。

チーム6）カレンダー表示やボタンサイズの拡大

日付の予約は、カレンダーで表示させた。縦横表示できるようにした。席選択のボタンを色分けし、見てすぐ判別できるようこだわり、スマホで選択しやすいようボタンサイズを大きくした。
配布テンプレートに戻るボタンを追加し、動線をわかりやすくした。機能の取捨選択をすることが大事だと思った。こういった場があったことを感謝しています。

[テストユーザーの感想]
乗車駅と降車駅がドラムでの選択でなく、キーボードで1文字入れると予測結果が表示される方が、個人的に使いやすい。
ラジオボタンは小さすぎて親指で隠れ押しにくいので、大きい方が良い。人数をテンキーで入力する仕様でつくられていたが、使いやすくて良い。
検索結果がたくさん表示されるより、精度のよいデーターが絞り込まれて出るほうがいい。選択項目を色分けしているのがわかりやすくて良かった。

イベントを終えて

テストユーザーの方には、iOS 7とiOS 6両方で比較してもらいました。iOS 7ではシンプルに線が細くなっていますが、iOS 6のドラムの方が線も文字もはっきりし、選択するとチェックが出るのでわかりやすい、という意見も出ました。

短い時間の中で、各チームのデザイナーとプログラマが課題に対して問題解決を図るアイデアを出し合う。多様なアプローチで試行錯誤することで、さらなる問題解決の可能性を見い出せた印象を抱きました。

イベントを運営した我々デザイン部一同、参加者の皆さんやテストユーザーの皆さんから学ばせて頂く機会となったことに感謝するとともに、 デザイン部では今後も積極的に取り組んでいきたいと思います。

2014年2月17日、日本マイクロソフトの品川本社オフィスにて、第45回HTML5とか勉強会を開催しました。今回は「ユーザーエクスペリエンスとペーパープロトタイピング」というテーマで、安藤幸央さんのご講演およびワークショップといういつもとは違った試みを行っています。

参加枠も100人の定員がすぐに埋まり、140人もの応募がありました。普段のHTML5とか勉強会に比べると、デザイナーの方の参加率が高いことが印象的ですが、エンジニアの方も興味を持って参加されていて、職種を問わず多くの方が興味を持っているテーマだということを感じました。

前半はスライドを見ながら　「ユーザーエクスペリエンス」に関してご講演頂きました。
まずは有名なサイトのプロトタイプを見て、どのサービスのプロトタイピングかを考えるということから始めました。

プロトタイプ制作でのポイント

今回は紙を使用してプロトタイプを作成します。
なぜ紙で作るのでしょうか？紙で作成すると以下のようなメリットがあります。

紙とペンでの試作のメリット

• 素早くできる
• コストが少なくてすむ
• やり直しが簡単
• 失敗してもリスクが少ない
• でき上がった感じがしない （ Photoshopだとでき上がったと勘違いされやすい）
• 余計なことを作り込めないので重要な所に集中できる
• 目と指で感じる感覚を得られる
• 紙とペンは潤沢に使えるツール

逆に欠点としては、

• また完成していないので、想像しながら試す必要がある
• アニメーションは確認できない
• 理解するのには空想力が必要かもしれない

等の欠点があるそうです。

プロトタイプの法則

それでは実際にプロトタイプを作成する場合の法則には、どのようなものがあるでしょうか。

1 画面を見直すと気づきがある

画面を見直すといろいろなことに気づきます、普段アプリなどを使っていて使いづらい、使いやすいシーンがあったら、なぜ使いやすいのか・使いづらいのかを分析してくことで気づきが生まれてきます。

2 道具にこだわろう

例えばクロッキー帳やポストイット、インターネットで入手できるUIテンプレート、ペンなどの道具や、ペンの太さを2種類に変えて、押せる部分と押せない部分をわかりやすく表現するなどTIPSなど。実際に安藤さんが使用されている用紙が文具を見本にわかりやすい作り方のポイントも解説されました。

3 アウトプットの質はインプットの質と量に比例する

良いものを作りたいのなら、いいものをたくさん見るーつまりアプリの場合はたくさんのアプリをみて使ってみることが大事です。

例えば「モバイルウェブの見本を集めているサイトなどを見て、自分の気に入るテイストや案件に合うサイトを調べてみる」、「アプリストアのランキングなどをチェックしなぜ人気なのかを考える」こともおすすめだそうです。

安藤さんの情報収集方法として、実際に参考となるサイトをスマホでキャプチャしたあとに、インターネットの書籍作成サービスで自分のミニ本を作成されているのだとか。クライアントの打ち合わせ時に手軽に見せて打ち合わせをしたり、手軽にまとめてみられるのが便利なのだそうです！

安藤さんのMinibook

アンテナを研ぎすませて新しいことを常にキャッチする姿勢とともに、自分の仕事やスタイルに合わせて、情報のまとめ方や生かし方を工夫することも、質を高めるために必要なことだと感じました。

4 素早く試して、素早く失敗しよう

5 本当に大切な2.3の機能を作ろう

すべての機能をたくさん試すよりも、まずそのアプリの中で重要な2つ3つの機能から考えてみることが大切です。

6 凝りすぎない。作り込みすぎない

紙で書くだけで大雑把で、ここに時間をかけすぎて開発時間が減るのは本末転倒です。素早く試しましょう！

7 完璧を目指さない、失敗を受け入れる

どんな人でも失敗するのは当たり前。早く失敗して良かったと考えましょう。

8　実際の環境で検討するのが重要

実際にスマートフォンで画面表示を試すにしても、会社のデスクで試すのではなく、会社の中を歩き回りながら使うだけでも違います。

例えば　車関係のアプリであれば実際車の動いている時や乗り降りに使うので、その環境に近い状況で試してみることが重要です。

9　客観的に見る、時間をおいて見る

使うであろうユーザーの立場に立って切り替えてみてみることが大切です。また、ずっと開発やデザインをしているとゲシュタルト崩壊というのか、良いのか悪いのか判断がつかなくなることがあります。その場合は時間をおいて確認しましょう。

10　素晴らしい試作も、本物ではない

リソースをかけすぎない。試作は試作と割り切って、ある段階になったら次の段階に進めるように考えると良いと思います。

手を動かしてわかる、プロトタイピングの効果

後半では2～3人でチームを作成し、自己紹介タイムの後にプロトタイプ作成に入りました。 テーマサイトは「Esty.com」通販サイトです。

PC用のサイトを見ながら要素を10個以上書き出しました。その中からスマートフォン用に表示させる内容を選んで行きました。まず各々がPICK UP！　そのあとチームで話し合って意見交換。

最後にチームの中から一人代表を選んでコンセプトと合わせて発表します。
それぞれのチームごとにさまざまな解があり、そのコンセプトを聞くことで自分の考えに凝り固まらずに、気づかなかった視点を認識します。

各チームのプロトタイプを見た後に、Esty.comの実際のスマホサイトが実際にどのようになっているかを確認。各々のプロトタイプとの違いを確認し合い、イベントを終了しました。短い時間でしたが、プロトタイプ作成でのポイントから考え方、制作まで体験することができ、続きもぜひ作りたいという声も聞かれ、有意義な時間となりました。

イベントの動画はこちら

イベント資料はこちら

デザイニアンプレイベントのご報告とVOL2のお知らせ！

最後に今回のHTML5とか勉強会・チューターの秋葉秀樹さんより、1月に行われたデザイニアンプレイベントを動画を交えながら報告、そして次回のイベント開催の告知が行われました。（プレイベントのレポート記事はこちら）

このイベントでは実際のサイトをテーマにHTMLのテンプレートを使用しエンジニアとデザイナーがチームを作りプロトタイプを作成します。3/22（土）に開催です、ぜひご参加ください！

＜デザイニアン 002＞

• 開催日:3/22（土）
• 開催時間:12:00会場 12:30より開催予定
• 定員:デザイナー15名 コーダー／プログラマー（ノートPC持参）15名　計30名
• 会場:メディアテクノロジーラボ（日比谷、銀座）
  　　　 東京都中央区銀座7-2-6 リクルートアネックス1ビル B1F　MAP
• イベントの詳細はこちらで紹介しています

2014年1月12日、株式会社ツクロアの事務所にhtml5jデザイン部スタッフが集まり、3月開催予定のイベントの打ち合わせを兼ねたプレイベントを行いました。どのようなチームで、どのように課題サイトの設定やテストを行ったのか。イベントの予告を兼ねたレポートをさせていただきます。

「デザイニアン Vol.2」で目指すもの

デザインという言葉から想像するものはどんなものでしょうか？

一般的には多くの方がPhotoshopやFireworksで作成したデザイン画像を想像されるかもしれません。しかしデザインとは「画面の意匠」という意味だけではなく、ユーザーが抱えている課題を解決するために思考や概念を組み立て、展開する媒体に応じた表現をし、さらなる問題解決を図ることです。

WEBやスマートフォンのアプリの場合、ユーザーが操作することで目的に到達します。つまりサービスから得られる体験を設計する事もデザインに含まれています。

Webデザイナーの通常業務の中で納期や予算の関係などから、プロトタイピングを制作し検証する機会がない方も多いのではないでしょうか。このイベントではサンプルとなるサイトを課題にして現状の問題点を分析し、プロトタイピングを作成し「ユーザー体験」まで含めた設計を行う、これが今回のイベントが目指すところです。

プレイベントの流れ

課題のサイトは、一般の利用経験者が比較的多いと考えられるJRの新幹線予約サイト「えきねっと」に設定しました。新幹線の予約を課題にいかにスムーズに情報を伝え、目的となるチケット購入までたどり着けるかをテーマに、

1. 課題のサイトの問題の洗い出し
2. 情報整理と仮説
3. プロトタイプ作成
4. ユーザーテスト
5. ヒアリング　

の流れで進めます。

1. 課題のサイトの問題の洗い出し

課題のサイトは、一般の利用経験者が比較的多いと考えられるJR東日本の新幹線予約サイト「えきねっと」に設定しました。

新幹線の予約を課題にいかにスムーズに情報を伝え、目的となるチケット購入までたどり着けるかをテーマにします。

まずは、デザイン部スタッフ一同で課題サイトの問題点を洗い出します。

• 目的の切符を買いづらい、
• 空席情報がわかりづらい、
• 往復チケットが買えない、
• 動線がわかりづらい、
• 押す場所がわからない、

など、さまざまな課題が見つかりました。

デザイン部スタッフが課題をテストしながら、同時にイベントの進行や時間配分、参加者の方にやっていただける内容・段取りも検討していきました。

2. 情報整理と仮説

次に課題サイトの情報を付箋に書き出して細分化し整理分類します。

その中から必要な機能や不要なものを取捨選択しカテゴライズしながら、目的への流れの中で発生するユーザーの動きを考えていきます。

3. プロトタイプ作成

フロントエンジニアとデザイナーが担当ごとに分かれて、プロタイプを作成していいきます。プロトタイプを作ることで トライ＆エラーを素早く繰り返すことができ、”自分たちの分析した内容が正しいのか？”をより早く検証することができます。

4. ユーザーテスト

サービスを作る時、誰のためのサービスを考えて、使用する人の目線で問題解決することが必要になります。しかし、制作に携わる側は開発しているサービスに慣れてしまい、ユーザーの目線でとらえられなくなります。

設定ターゲットに近い2名の方に来ていただいてプロトタイプの検証を行います。

• Aさん（女性　ITリテラシーは低め　新幹線には乗るが、予約サイトでのチケット購入経験はなし）
• Bさん（20代男性 普段はiPhoneを使用する程度の利用。Webサイトでの購入経験はなし）

課題の「えきねっと」と合わせて、JR西日本の新幹線予約サイト「JRおでかけネット」も比較対象として検証します。さらに新幹線の乗車券と特急券を、提示した2パターンで予約を取ってもらい、その手元の動きを動画で撮影します。

5. ヒアリング

サイト検証の終了後は、録画した動画を見ながらレビューを行います。どの段階で操作が詰まったか、何がわかりにくかったのか、コントリビューターのお二人に細かく説明していただきました。

操作中の声も記録されているので、言葉からも何を迷っているか把握できました。

• ボタンかと思っておしたらアイコンで、操作に迷った。
• 一見しただけでは指定席を取っているかがわからなかった。
• ボタンの色が赤だったので警告なのかとおもったら違っていた。
• ボタンのテキストを「確認する」など次の動作がわかる言葉に変えた方が押しやすい。

etc — たくさんの問題点が浮き彫りになります。私たち制作に携わる側が当然だと思い込み、気がつかなかった点や問題点、予想していなかったユーザーの行動など知ることができました。

“求める解に近づく力を体験から培う”イベントに参加しませんか？

この日のプレイベントはこちらで終了しましたが、スタッフは引き続きイベントに向けて準備を続けています。

3月開催予定のデザイン部イベント「デザイニアン Vol.2」では、エンジニアとデザイナーがチームを作り、スタッフの行ったプレイベントと同じ流れで課題サイトのプロトタイプを作成し、ユーザーテストを行います。仮説を立て試行錯誤しながら一緒に考えるイベントです。

みなさんも一緒に学びませんか？

イベントの詳細は以下です。募集に関してはhtml5jのメーリングリスト（ML)にてお知らせします。 ご興味のある方はぜひご参加ください！！！

• イベント名：　デザイニアン002
• 開催日：　3/22（土）
• 開催時間：　昼12時会場 12:30より開催予定
• 定員：　デザイナー15名　・　コーダー／プログラマー15名　計30名
• 会場：　メディアテクノロジーラボ
• 会場住所：　東京都中央区銀座7-2-6 リクルートアネックス1ビル B1F　http://mtl.recruit.co.jp/access/
• 参加資格：　スキルは問いませんがワークショップがあります
• イベントの募集について：　html5jメーリングリストでお知らせします

タイムテーブル：

• ◎チーム編成　…　13:00〜13:30
• ◎ワークショップ　…　13:30〜18:00
• ◎ユーザー評価　…　18:30〜20:30
• 終了後、任意参加で打ち上げ

斉藤祐也の海外WEBテク定点観測＜Issue.10: 2014/01/01-2014/01/31＞

今月の定点観測は、CSS Regionsに対する問題提起、新picture要素仕様、Webスタンダードの新フェーズなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

CSS Regionsへの問題提起 – An A List Apart Blog Post

原題: CSS Regions Considered Harmful

タイトルからしてすでに議論を呼び込むようなタイトルとなっている、CSSの父であるHåkon Wium Lie氏によるCSS Regionsの仕様に対する問題提起。
時を同じくして、GoogleのBlinkチームがCSS Regionsを実装しないという議論も始まり、大きな議論に発展しています(関連リンクを参照してください)。
この記事でHåkon Wium Lie氏はRegionsはダミーのdivを使う必要がある、レスポンシブではない、テキストフローが分かりづらい、33行にもおよぶほどのコードで実現するしかない、コードの再利用性が低いという5つのポイントを問題点として挙げています。

関連リンク:

• CSS Regions in Blink: status, future work / CSS Regionの実装についての議論
• CSS Regions Matter – Flippin’ Awesome / CSS Regionsを実利的に利用した例を豊富に紹介

The picture Element

レスポンシブ画像に対する飽くなき議論の末、議論の始まりとなったpicture要素の新仕様が発表されました。これまでの議論をうまく集約した提案となっています。フォールバック要素としてのimgではなく、picture要素内に必須となる要素としてimgを利用している点が、以前のpicture要素との違いとなるポイントとなっています。

関連リンク: picturefill – Shawn Jansepar / 新仕様に合わせたPolyfill

2014年、Webデザインは死んだのか? – Jeffrey Zeldman Presents The Daily Report

原題: It’s 2014. Is Web Design Dead?

Jeff Croft氏による「Web Standards Killed the HTML Star」という記事を見かけた方も多いかも知れません。その記事へのJeffrey Zeldman氏からの反論がこの記事です。Zeldman氏は確かにChroft氏が言う通りの部分があることは認めつつ、Webスタンダードには2つのフェーズがあり、現時点ではその内の1つ目がようやくまともになってきたタイミングだとしています。
Zeldman氏はWebスタンダードは当たり前の存在であるべきとしつつ、さらにウェブサイトを構築することを簡易にし、その上でデザイン、コンテント、そして体験を生み出すことにフォーカスしやすくするのが次のフェーズであると主張しています。

関連リンク: Web Standards Killed the HTML Star – JeffCroft.com

フロントエンド開発における問題解決へのプロセス – CSS-Tricks

原題: Thought Process of a Front End Problem

海外の第一線で活躍するフロントエンド開発者であるChris Coyier氏が自身が実際に解決しようとした「Opera mobileでフォントのレンダリングがおかしい」という問題へのアプローチについて詳細を語っています。
共感できる点が多く、やはり第一線にいるCoyier氏でも環境が大きく異なるブラウザの世界では同じように苦労しているのだなというのが分かります。
彼自身がどのように問題に対峙したのかの記録は似た問題を解決する際の参考になるのはもちろん、フロントエンド開発における問題の多くの解決に参考になります。

アルゴリズムはフロントエンド開発者にも必要な知識か? – Aerotwist

原題: Algowhatnow?

フロントエンド開発者の面接に、アルゴリズムに関する問題を出す意味はあるのでしょうか？
フロントエンドに関わる多くの開発者コンピュータサイエンス関連の大学を卒業していないケースもあり、アルゴリズムそのものよりもクロスブラウザに対するアプローチや知見などのほうが優先度が高いという議論もありますが、コンピュータとの対話を行うためにやはりアルゴリズムは欠かすことができないのかもしれません。
ロジカルシンキングの指標としても利用できるアルゴリズムへの知見は持っていて損はしないという主張。

海外トレンドコラム

ボタン要素はいつ使うべきなのか? – CSS-Tricks

原題: When To Use The Button Element

a要素とbutton要素はどのように使い分けて行くべきでしょうか？ CSSを利用して、どんな要素でも自在にスタイリングできるようになったからこそ知っておきたいことです。

EMEの利点と欠点

原題: EME pro and con

W3Cが仕様を策定しようとしていることで話題になっているEME(Encrypted Media Extensions)について利点と欠点をコンパクトにまとめたGoogle Docs。
これまでに多くの議論が行われてきているので、今からその議論に追いつきたい場合に非常に役に立つ文書です。

アクセシブルなアイコンフォントの使い方 – Filament Group, Inc., Boston, MA

原題: Bulletproof Accessible Icon Fonts

アイコンフォントを利用するケースが徐々に増えてきています。しかし、アイコンフォントの利用に際して忘れられがちなのがアクセシビリティ。音声ブラウザがアイコンフォントに使っている文字を発してしまったりするのは避けるべきです。この記事では、アクセシビリティを考慮したアイコンフォントの利用について、詳細に紹介しています。

CSS Will Change Module Level 1

レンダリングのパフォーマンスを向上させるために、利用せざるを得ないtranslateZなどを活用したハック。有効でありかつ手軽である反面、ハックである事実は変わりませんし、それなりのコストもかかります。
このCSS Will Change Moduleはそのハックを必要とせずに済むように提案されている仕様です。

関連リンク: Bye Bye Layer Hacks – Aerotwist

Promisesガイド – w3ctag

原題: Promises Guide

Promisesの仕様を作成しているチームにより、どのようにPromisesは利用するのかについてのガイドラインが公開されました。ライブラリなどを作成する際に参考になるだけではなく、少々とっつきづらい文章ながら、既存のPromisesライブラリを利用する際にも参考になるはずです。

jQueryはもう必要ない?

原題: You Might Not Need jQuery

数年前までは、jQueryなしでのクライアントサイドの開発は想像できませんでした。しかし、レガシーブラウザへの対応の必要性が少しずつ減ってきた今、jQueryは本当に必要でしょうか？
このサイトでは、ネイティブJavaScriptでjQueryが提供しているAPIを代替するスニペットを紹介しています。

関連リンク:

• Why You Still Need jQuery / いわゆるモダンブラウザでもクロスブラウザの問題を解決するのにjQueryが行っているワークアラウンドを示しています。
• Twitter / jeresig: I keep writing and deleting … / jQueryのオリジナルの作者であるJohn Resig氏のコメントにも注目してください。

head要素内にCSSを入れるのは何故なのか? – Aqeel

原題: What’s with putting the CSS in the head?

これまで知られているベストプラクティスでは、CSSは外部CSSファイルから呼び出す。となっています。本質的には現時点でも間違いではありません。しかし、近年CSSをstyleタグ内に記述する例も増えています。なぜそうすることがパフォーマンス観点でプラスに働くかについて、ブラウザのレンダリングの仕組みなどを踏まえて詳細に解説しています。

Promise nuggets – Gorgi Kosev

なかなか理解するのに苦労するPromisesについて、コールバックとの違いを実例を通して解説してくれているのがこのサイト。コールバックを使ったアプローチとの比較のおかげで、Promisesの利点や実装イメージがわきやすくなるはずです。

HTML、CSS、JavaScriptを合わせたモジュールデザイン開発へのアプローチ – Techwraith

原題: Atomic Product Development

モジュールデザインというアプローチは、今ではウェブ開発において欠かすことができないものとなっています。近年はJavaScriptにおけるモジュールデザインが盛んに議題に上がっていますが、CSSについてはあまり言及がありません。この記事では、HTML、CSS、JavaScriptが持つ依存関係の低減に必要なアプローチについて、詳しく解説しています。

CSSOMを使ったCSSの機能テストについて – Ryan Morr

原題: Feature Testing CSS At-Rules

ブラウザでどのCSSのAPIが実装されているかを調べる手法の紹介。この記事では「@」を利用する機能のテストについて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

Promises/A+ 実装を通じて仕様について学ぼう v.1.1対応版 – Modern JavaScript

原題: Promises/A+ Understanding the spec through implementation v1.1

ネイティブでJavaScriptに実装される予定であるPromises。その元々の仕様であるPromises/A+と呼ばれる仕様が、昨年の8月にバージョン1.1に変更されました。その変更を踏まえて、実装と仕様を合わせて解説しているのがこのスライド。細かい部分についても分かりやすく解説してくれているのでおすすめです。

JavaScriptにおけるSOLID – Derick Bailey

原題: SOLID JavaScript In A Wobbly (World Wide Web)

オブジェクト指向における有名な5つの設計原則をまとめたSOLIDを、JavaScriptで実践する際に気をつけておくべきポイントについて、詳しく解説している動画です。スピーカのDerick Bailey氏はBackbone.jsのプラグインMarionette.jsの作者でもあります。

CSSの3D、アニメーションについてインタラクティブに学ぶ – Chris Ruppel

原題: Unfolding the Box Model

CSSの3D Transformsについて、インタラクティブに学ぶことができるサイトです。アニメーションはもちろん、3Dのコンセプトは実際に動いているものを見ることが一番わかりやすいので、初心者、中級者の方はぜひ。

JS: The Right Way

JavaScriptに関する優れた様々な情報を集めて紹介しているサイトです。Superhero.jsと同じようなコンセプトではありますが、記事だけではなくライブラリなどもコレクションしています。

Remote.js – Hage Yaapa

WiFiもBluetoothも使わずに、音を使ってスマートフォンからデスクトップブラウザを操作するためのライブラリ。
実際に動作する(試してみたところ、少々怪しげながら動作します)デモもあり、非常に興味深いツールです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年3月3日にお届け予定です。★

それでは実際、レスポンシブ・ウェブとは何についての対応（レスポンシブ）なのでしょうか。

現在のところ、私たちがいうレスポンシブ・ウェブデザインとは、どんなスクリーンの幅や表示領域、デバイスの画面解像度や画面の縦横の向きにも対応したウェブデザイン、というのが事実上の定義となっているようです。

そこで今回、私はその定義を超えたレスポンシブ・ウェブのユースケースについて考えてみました。

太陽光下でのスクリーン・リーダビリティ

私は普段の仕事ではNokia Lumiaというスマートフォンを使っているのですが、これがなかなかの優れもの。環境光センサーでスクリーンの輝度値を自動調整してくれるので、晴天の空の下でもスクリーンのコンテンツがはっきり読めるのです。ところが私の個人用で使ってる別機種の場合、そうもいきません。例えば読みたいウェブがたとえ「レスポンシブ」であれ「モバイル・ファースト」であれ、まぶしいカリフォルニアの空の下では、全くコンテンツが見えないので使い物にならないのです。

一方、W3CのCSSメーリングリストでは、次世代のCSS Media Queries 4のひとつである

luminosity

しかしこれが実現するのは一体いつの日になることやら…

Ambient Light Events API

というわけで、今現在のブラウザでは、CSSを使って環境光の度合いに合わせてウェブのUIを調整するのは不可能。

しかし私たちには、HTML5を使ってブラウザから各種センサーやカメラなどのハードウェアが持つ機能にアクセスするための仕様、デバイス APIのひとつであるAmbient Light Eventsがあるでないですか！
これならJavaScriptを使って環境光センサーから照度を知ることができるはず。これを使えば、次世代メディアクエリをまねて、太陽や照明にレスポンシブなウェブが作れるかもしれない！
そう思って私は、実験的に簡単なデモを書いてみました。

Devicelight events

デバイスのセンサーが照度の変化に反応すると、ブラウザ側では

DeviceLightEvent

devicelight

そこで得られるプロパティの値、

value

実際、大変簡単にこう書くことができます。

window.addEventListener('devicelight', function(event) {
  console.log(event.value + 'lux');
});

照度にレスポンシブなウェブを作ってみる

これを使って、環境光が変わってもウェブの内容を読みやすくするためのUIを考えてみました。

デフォルトではライトグレーの背景に黒の文字、明るい照度の時には白地に黒の文字、そして暗い時には暗めな背景に白の文字、というUIにしてみましょう。

例のAPIを使って、照度によってコンテンツのコンテイナー（このデモではわかりやすいように

document.body

window.addEventListener('devicelight', function(e) {
  var lux = e.value;

  if(lux < 50) {
    document.body.className = 'dim';
  }
  if(lux >= 50 && lux <= 1000) {
    document.body.className = 'normal';
  }
  if(lux > 1000)  {
    document.body.className = 'bright';
  } 
});

body,
body.normal {
  background-color: #ddd;
  color: #111;
}
body.dim {
  background-color: #444;
  color: #fff;
}
body.bright {
  background-color: #fff;
  color: #333;
}

実際に、このデモが動いている様子がわかる動画を作ってみました。

ブラウザサポートとデバイス

このデモで使われた実際のソースコードは、CodePenを見てください。

ほとんどの方の観覧しているブラウザ上では “AmbientLightEvent is not supported.” というメッセージが出ていて何も起こらないのではないでしょうか。というのも、残念ながら今のところ、このAPIをサポートしているのはFirefox 22+ だけ、しかもデバイス側にも環境光センサーが必要。
ですので、デスクトップから見ている皆さんには、どのブラウザを使っていてもこのデモは作動していないでしょう。私のデモで実際に使ったデバイスはNexus 7ですので、AndroidやFirefoxOSのデバイス持っている方は、ぜひFirefoxで試してみてください。

イベントが返す値も、デバイスによってばらつきがあるようです。私が実験した機種2機ではずいぶん違う結果が出ました。たぶんセンサーの精度にブレがあるのでしょう。

この写真にあるデバイスは、Moto G(Android)と、Keon(FirefoxOS)です。暗めの部屋での照度が、一方が6lux、もう一方が61luxとなっています。

CSS Media Queries Level 4 Luminosity

さて、話題をメディアクエリに戻します。
今現在の仕様では、メディアクエリ・レベル4はまだeditor’s draftの段階なので、ブラウザに実装されるまでにはまだまだ時間がかかりそうです。

将来的に実装された際には、このデモで書かれたコードはCSSのみでこのように書き直すことができるようになります。

@media screen and (luminosity: normal) {
  body {background-color: #ddd; color: #111;}
}
@media screen and (luminosity: dim) {
  body {background-color: #444; color: #fff;}
}
@media screen and (luminosity: washed) {
  body {background-color: #fff; color: #333;}
}

このように、

luminosity

おわりに

近い将来、レスポンシブ・ウェブの定義も、デバイスなどの多様性に合わせて変わってくるのではないでしょうか。このユースケースも実際果たして本当に役に立つのかどうかもまだわかりませんが、発想の転換とブラウザの新しい可能性、という面でこの記事を楽しんでいただけたかと思います。

この記事は元々は私個人のブログ（原文は英語）に掲載したのですが、TwitterやReddit、Hacker Newsで思いのほか話題になりました。やはりディベロッパ、デザイナは国境を問わず、みな新しい可能性に興味津々なのでしょう。

では。

Web制作においてHTMLのマークアップには絶対の正解というものがありません。ページを制作しているとき、特にセマンティクスを意識したとき「このマークアップで正しいのだろうか」と悩むことがあると思います。

そんなマークアップについて考えるイベント「MarkupCafe」がhtml5jマークアップ部の主催のもと開催されました。「MarkupCafe」では参加者同士がチームに分かれ、お題となるデザインに対して議論し、自分たちならこうマークアップするといった考えを発表し合いました。

本記事では「MarkupCafe」で出された”フッター”、”パンくずリスト”、”求人情報”の3つのお題をもとに、Web制作におけるマークアップの捉え方、誤った使い方をしがちな要素などについて考え、マークアップの最適解を探ります。

※html5jは、HTML5などのWebプラットフォーム技術を使った「ものづくり」に関わる、すべての人々を応援する非営利・中立のコミュニティです。

1.フッターの要素が持つそれぞれの意味は？

最初のお題として出されたのはページ最下部によくある、フッター部分のデザインからのマークアップです。お題で使われた画像には、筆者が印象から決めたパーツの構成がわかるようにキャプションをつけています。筆者はAからFの6つのパーツに分解してマークアップを考えました。パーツをいくつかピックアップして、参加者のマークアップを見ていきます。

パンくずリスト？ナビゲーション？

意見が分かれるところだと思いますが、Aのパーツはパンくずリストにもナビゲーションにもとれるパーツです。実際に各チームのマークアップは、大きく分類してリストを使うか、使わないかに二分されました。

<nav><!-- nav要素で囲むチームもいれば -->
    <ul>
        <li>
            <a href="">HOME ＞</a><!-- リンクにしないチームも -->
        </li>
    </ul>
</nav>

リストにしたチームの中でもnav要素で囲んでいたり、li要素の中をリンクにしたりといった差異がありました。リストにしなかったチームのマークアップはp要素一つというもので、「意味をもたせるほど重要な情報ではない」と判断してのもの。捉え方の違いでマークアップは大きく変わる、ということ象徴していると思います。

水平線に潜む罠？

Bのパーツの水平線は、一見hr要素を使って線が引けそうですが、どのチームもhr要素は使っていません。hr要素は話題の区切りなどを表す際に使う要素なので、この場合のマークアップには適さないという判断でした。見た目的な水平線を引きたい場合は、スタイルシートで行うべきだとされています。

address要素から考える”良いマークアップ”とは？

このお題の中で、どのチームも一番時間をかけたのがDとEのパーツです。電話番号やメールアドレス、住所といった情報に意味をもたせようと思ったとき、一番に浮かぶのはaddress要素です。どのチームもaddress要素を使用しましたが、その使い方はバラバラでした。

<address>
    <p>
        <span><a>お問い合わせ：0120-0000-0000</a>, <a>infomation[at]bathtimeshoji.com</a></span>
    </p>
</address>
<dl>
    <dt>神戸本社：</dt>
    <dd>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</dd>
    <dt>東京本社：</dt>
    <dd>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</dd>
</dl>

<p>
    <span>お問い合わせ：</span>
    <address itemprop="telephone">0120-0000-0000</address>
    <address itemprop="email">infomation[at]bathtimeshoji.com</address>
</p>
<dl>
    <dt>神戸本社：</dt>
    <dd>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</dd>
    <dt>東京本社：</dt>
    <dd>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</dd>
</dl>

<address>
    <p>お問い合わせ：<span>0120-0000-0000</span> <span>infomation［at］bathtimeshoji.com</span></p>
    <p>神戸本社：<span>兵庫県神戸市◯◯◯◯◯ 11-11-11 ◯◯ビル 11</span></p>
    <p>東京本社：<span>東京都渋谷区◯◯◯◯◯ 22-22-22 ◯◯ビル 22</span></p>
</address>

お問い合せの部分だけをaddress要素にするチームもあれば、Microdataを使った上で電話番号とメールアドレスを分けてaddress要素を使う、住所も含めてaddress要素にする、といったようにaddress要素の使い方はバラバラになりました。

address要素は特に誤った使われ方をされる要素の一つですが、仕様をざっくりと意訳すると”そのドキュメントの問い合わせを受ける人に関する情報に用いる”とされています。このお題の場合、ドキュメントの問い合わせ先として適していそうなのは電話番号とメールアドレスの2種類だと捉え、所在地の情報は適していないと考えることができます。 要素の名前がもっていそうな意味からマークアップするのではなく、仕様に基づいて正しい使い方をすることが良いマークアップのためには必要です。

2.パンくずリストに正解はあるのか

次のお題に出されたのはパンくずリストです。先のお題の中にもパンくずリストとして扱える要素がありましたが、このお題では明確にパンくずリストとしてマークアップします。

ほとんどのチームが要素にメタデータを付与して、細かく意味付けをしていました。パンくずリストというシンプルなお題なだけに、同じようなマークアップになるのではと思いましたが、それぞれのマークアップからは様々な部分に思考を巡らせたのが見えてきます。

メタデータはだれのため？

このマークアップでは、Microdataで各要素にメタデータで意味付けをしています。

<nav>
    <ol itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
        <li itemprop="child">
            <a itemprop="url" href="">
                <span itemprop="title">Markup Cafe トップページ</span>
            </a>
        </li>
        <li itemprop="child">
            <a itemprop="url" href="">
                <span itemprop="title">店舗情報</span>
            </a>
        </li>
        <li>ドリンク・フード</li>
    </ol>
</nav>

Microdataを使った理由としては、Googleなどの検索エンジンに対して優位なマークアップにしたいといった意図からです。

ここではol要素を使っていますが、パンくずリストを順序ありリストとするか順序なしリストとするか、この点だけを取っても意見が分かれると思います。

これからはRDFaがくるかも

このマークアップではMicrodataではなくRDFa Liteで意味付けをしています。

<nav vocab="http://rdf.data-vocabulary.org/" typeof="Breadcrumb">
  <h1>ページ階層</h1>
    <ul>
        <li>
            <a property="url" href="">
                <span property="title">Markup Cafe トップページ</span>
            </a>
        </li>
        <li>
            <a property="url" href="">
                <span property="title">店舗情報</span>
            </a>
        </li>
        <li>
            <a property="url" href="">
                <span property="title">ドリンク・フード</span>
            </a>
        </li>
    </ul>
</nav>

先日W3Cより勧告されたRDFa 1.1では、HTML5への対応やRDFa Liteで簡潔なマークアップが可能になったこともあり、RDFaの利用が増えていくかもしれません。

先のマークアップとの他の違いとして、h1要素を使ってる箇所があります。nav要素はセクショニング・コンテンツなので、見出し要素を使うことでアウトラインを意識したマークアップにできる、と考えることもできます。

リストってなんだろう

このマークアップはMicrodataを使っていますが、リスト要素を使っていません。

<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">Markup Cafe トップページ</span>
    </a>
</div>
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">店舗情報</span>
    </a>
</div>
<div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
    <a itemprop="url" href="">
        <span itemprop="title">ドリンク・フード</span>
    </a>
</div>

これは「パンくずリストはリストではない」という解釈からでした。階層構造を表すためにリスト要素を使うのが本当に正しいのかどうか、非常に考えさせられるマークアップです。

意味付けだけに囚われることなかれ

このマークアップは、メタデータを使わず非常に簡素なマークアップです。

<ul>
    <li>
        <a href="">Markup Cafe トップページ</a>
    </li>
    <li>
        <a href="">店舗情報</a>
    </li>
    <li>
        <a href="">ドリンク・フード</a>
    </li>
</ul>

同じようにリスト要素を使っている他のチームと比べるとnav要素を使っていません。これはnav要素の”重要なナビゲーションブロックからなるセクションだけがnav要素に適している”という仕様を意識し、パンくずリストはそこまで重要ではないと判断してのものでした。

また、nav要素を使わなかったもう一つの理由として「スクリーンリーダなどでアクセスしたときに重要なリンクを見失わないように」という意図も込められています。セマンティクスを与えてマシンが意味を理解できるようにすることも大事ですが、その先を考える必要もあるのかもしれません。

Microdata VS RDFa、決着か？

MicrodataとRDFaはどちらもメタデータを付与して意味づけを行うための仕様ですが、Microdataが7月にW3C HTML WGによってHTML5.0の勧告候補から削除されてしまいました。(詳しい理由と顛末は白石編集長の記事でふれていますのでそちらをご覧ください) Microdataがこの先どう落ち着くのか、先にふれたRDFa 1.1が勧告されたという点からもこれからの動向に要注目です。

3.求人情報は独立した記事か

最後のお題は、よくある求人情報のデザインからのマークアップです。このお題では4つのパーツに分解して考えました。中でもAの”求人情報全体”については特に意見が分かれ、多くの議論が交わされました。

tableの出番？いやいやdlでしょ

Dの求人内容の部分は、table要素とdl要素とでマークアップが分かれました。

<dl>
    <dt>給与</dt><dd>時給1500円</dd>
    <dd>月額20.3万円〜22.3万円＋残業代</dd>
    <!-- 略 -->
</dl>

給与や勤務時間といった情報を定義と解釈するか、表の項目の一つとして解釈するかで使用する要素も変わってきます。どちらを使うのが正しいのか決められることではないですが、その情報が何を表したいのか考えることは良いマークアップへと繋がります。

文章構造は視覚的に決まる？

Cの”その他の情報”部分のマークアップですが、チームごとにバラバラになっていたのがとても興味深いです。

<p><img src="" alt=""></p>
<p>未経験！派遣初めてさん！大歓迎！<br>
★履歴書不要！らくらく登録！<br>
★正社員のような待遇！嬉しい「月給制＋交通費支給 」<br>
★IT・美容・マスコミ・金融など業界も様々<br>
★正社員を目指す！紹介予定派遣のお仕事多数
</p>

<p><img src="" alt="">未経験！派遣初めてさん！大歓迎！</p>
<p>★履歴書不要！らくらく登録！</p>
<p>★正社員のような待遇！嬉しい「月給制＋交通費支給 」</p>
<p>★IT・美容・マスコミ・金融など業界も様々</p>
<p>★正社員を目指す！紹介予定派遣のお仕事多数</p>

<img src="" alt="">
<p>未経験！派遣初めてさん！大歓迎！</p>
<ul>
    <li>★履歴書不要！らくらく登録！</li>
    <li>★正社員のような待遇！嬉しい「月給制＋交通費支給 」</li>
    <li>★IT・美容・マスコミ・金融など業界も様々</li>
    <li>★正社員を目指す！紹介予定派遣のお仕事多数</li>
</ul>

p要素の中でbr要素で改行してるものもあれば、全てp要素にしたり、リストを使ってるマークアップもあります。一行目に星マークがついていないテキストがあるから箇条書き、という解釈もできますし、一行目以外は星マークがついているからリスト、という解釈もできます。

では、もしこの一行目のテキストにも星マークがついていたらどうでしょうか。それぞれ似たようなマークアップになっていたかもしれません。これらのマークアップから「構造が曖昧な文章への意味付けは、整った文章への意味付けよりも解釈の仕方が多様になる」と筆者は考えます。

articleという名の迷宮

HTML5で定義された要素の中でも、特にarticle要素の使いどころについてはさまざまな意見があると思います。article要素を使ったチーム、article要素ではなくsection要素を使ったチーム、2つのマークアップを比較します。

<article>
    <h1><!-- 見出し --></h1>
    <div><!-- その他の情報+求人内容 --></div>
    <aside><!-- 関連する求人 --></aside>
</article>

<section>
    <h1><!-- 見出し --></h1>
    <div><!-- その他の情報+求人内容 --></div>
    <div><!-- 関連する求人 --></div>
</section>

この2つのマークアップはaside要素を使っているという違いこそあるものの、文書構造的にはとても似ています。article要素をどこで使えばいいか悩んだときは、「RSSとして配信されたときに単独の記事として成り立つかどうかを意識すると良い」と言われていますが、それも見る人や状況によって違ってきます。article要素とsection要素のどちらを使うかは、前後の文章構造によっても変わりますが、主観による部分が大きいのではないでしょうか。構造の解釈は一緒なのに意味の解釈は違うものになる、マークアップの奥深さが垣間見えます。

MarkupCafeから見えたもの

今回筆者が参加したMarkupCafeでは一つのマークアップについて、30分間考える時間がありました。自分自身でマークアップに向き合えたのもよい体験でしたが、同じデザインから自分と違うマークアップをした理由を直接聞ける機会はなかなかないと思います。解釈の仕方でマークアップが変わる、というのを実感できたイベントでした。

この記事で紹介したマークアップや要素の使い方も、すべて考え方の一つでしかありません。答えを決めることはできないかもしれませんが、良いマークアップを作っていくことはできるはずです。

最後に「MarkupCafe」主催の村岡正和氏の言葉を引用して、記事を締めくくりたいと思います。

「HTMLのマークアップには決まった答えがありません。 どんなウェブページを作りたいか。アクセスした人になにを伝えたいか。どういう気持で伝えたいか。 それがページごとに違うから、それぞれのページにそれぞれのマークアップがあるのです」

＜MarkupCafe Tokyo Vol.2 開催のお知らせ＞ 10月19日（土）13:00～17:00に「MarkupCafe Tokyo Vol.2」を開催します。 プロのWebデザイナーから初心者まで、みんなで気軽に会話しながらイマドキのHTMLマークアップの知識を深めましょう！ 詳細はこちらから。

フラットデザイン採用、フルレスポンシブ！

Bootstrap2からの変更点のリストは、公式のリリース文を参照してください。特に大きな変更点は以下のとおりです。

フラットデザインの採用

現在流行のフラットデザインを採用しました。ただこれは「流行りに乗った」のではなく、テーマの一つとして提供されているという位置付けのようです。

例えば以下は、Bootstrap3のボタングループです。

Bootstrap3でのボタングループ

Bootstrap2のボタングループと比較すると、確かにフラットデザインを採用していることがわかりますね。

Bootstrap2でのボタングループ

レスポンシブWebデザインの全面採用

以前までのBootstrapは、レスポンシブWebデザインへの対応はオプショナルな扱いでした。ですが、Bootstrap3はレスポンシブがデフォルトになり、グリッドシステムや入力フォーム、モーダルダイアログなどの各種コンポーネントが、全てスクリーン幅に応じて最適な見た目に調整されます。

また、モバイルファーストの流儀に従ってCSSが記述されています。すなわち、幅768px以下の小さなスクリーン向けのCSSがデフォルトで、それ以上のスクリーンサイズについてメディアクエリが定義されています。

IE7とFirefox3.6のサポートが打ち切られた

Bootstrap3からは、IE7以前とFirefox3.6のサポートが打ち切られました。またIE8では、Respond.jsを用いてメディアクエリを有効にしない限り、デスクトップ向けのスタイルが正しく動作しません。

Bootstrap3のインストール

では実際に、Bootstrap3を試してみましょう。

Bootstrapを利用するには、まずGitHubリポジトリから、zipファイルをダウンロードします。

zipファイルを展開すると以下の様なファイル構造になっています。この中のCSSとJSを参照するよう、HTMLファイルを記述するだけで、Bootstrapのインストールは完了です。

bootstrap/
├── css/
│   ├── bootstrap.css
│   ├── bootstrap.min.css
│   ├── bootstrap-theme.css
│   ├── bootstrap-theme.min.css
├── js/
│   ├── bootstrap.js
│   ├── bootstrap.min.js
└── fonts/
    ├── glyphicons-halflings-regular.eot
    ├── glyphicons-halflings-regular.svg
    ├── glyphicons-halflings-regular.ttf
    └── glyphicons-halflings-regular.woff

例えば、以下の様なHTMLテンプレートから始めると良いでしょう（公式ドキュメント内のテンプレートを多少改変）。このテンプレートでは、IE8以前でもHTML5要素とメディアクエリをサポートするために、HTML5 ShimとRespond.jsを使用しています。

:html:
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Bootstrap3テンプレート</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link href="css/bootstrap.min.css" rel="stylesheet" media="screen">

    <!-- IE8以前でもHTML5要素とメディアクエリをサポートするために、HTML5 shimとRespond.jsを読み込む -->
    <!--[if lt IE 9]>
      <script src="js/html5shiv.js"></script>
      <script src="js/respond.min.js"></script>
    <![endif]-->
  </head>
  <body>
    <h1>Hello, world</h1>

    <!-- jQuery (BootstrapのJavaScriptプラグインのために必要) -->
    <script src="//code.jquery.com/jquery.js"></script>
    <script src="js/bootstrap.min.js"></script>
  </body>
</html>

新しいグリッドシステムを理解しよう

Bootstrap3を軽く試してみたところ、以前のバージョンから最も変化していて、少しわかりにくかったのがグリッドシステムでした。ということで本稿の残りの部分では、そのグリッドシステムにフォーカスを当てて説明していきたいと思います。

まず基本的なこととして、グリッドレイアウトとは、画面を論理的にグリッド状（格子状）に分割してレイアウトする手法です。

Bootstrap3の場合、グリッドの列数は12に固定されています。そして、col-xs-1, col-xs-2のように「横に占める列数」を名前に含むクラスがBootstrapによって提供されています。これらのクラスをブロック要素に付与していき、要素が占める列数の合計がちょうど12になるようにレイアウトしていきます（12以上になると、次の行に折り返されます）。

文章だけではわかりにくいと思いますので、簡単な例で説明します。グリッドの行を表すrowというクラスを持つブロック要素をまず配置し、その中に、列数の合計が12になるようにブロックを配置していきます（列数はクラス名で判別します）。

:html:
<div class="container">
  <!-- グリッドの一行。列数は合計12 -->
  <div class="row">
    <!-- この要素が占める列数は8 -->
    <div class="col-md-8">.col-md-8</div>
    <!-- この要素が占める列数は4 -->
    <div class="col-md-4">.col-md-4</div>
  </div>
</div>

上記のマークアップをブラウザ上でレンダリングすると、以下の様な表示になります（それぞれのブロックが占める範囲がわかりやすいように枠線を表示しています）。col-md-8が画面の3分の2を、col-md-4が画面の3分の1を占めているのがおわかりでしょう。

Bootstrap3のグリッドを使用した結果

そして、Bootstrap3のグリッドシステムの面白い点は、スクリーンの幅に応じてこのグリッドが自動的に縦方向にスタックされるという点です。上のマークアップを、幅992pxより小さいブラウザウィンドウで見ると、以下のように見えます。

Bootstrap3のグリッドを使用した結果（スクリーン幅が768px以下）

このように、スクリーンの幅に応じて自動的にレイアウトが変化するのが、Bootstrap3のグリッドシステムにおける強力な特徴です。

Bootstrap3のグリッドシステムを理解する上で重要なのは、以下の表です。（ドキュメント内の表から引用、改変）

この表を見ておわかりの通り、スクリーンの幅に応じて、異なる接頭辞を持つクラスが用意されています。例えばcol-sm-という接頭辞を持つクラスは、幅768px未満では縦積み、それ以上の場合は横方向に配置されます。上のサンプルではcol-md-というクラスを使用していたため、幅992px前後でレイアウトが変わったというわけです。

そしてこれらのクラスは、複数同時に使うこともできるというのもポイントです。 例えば、「モバイルでは2列ずつ縦積み、タブレットでは3列ずつ縦積み、デスクトップでは横並び」というレイアウトを実現するには、以下の様なマークアップを行います。

:html:
<div class="row">
  <div class="col-xs-6 col-sm-4 col-md-2">あ</div>
  <div class="col-xs-6 col-sm-4 col-md-2">い</div>
  <div class="col-xs-6 col-sm-4 col-md-2">う</div>
  <div class="col-xs-6 col-sm-4 col-md-2">え</div>
  <div class="col-xs-6 col-sm-4 col-md-2">お</div>
  <div class="col-xs-6 col-sm-4 col-md-2">か</div>
</div>

スクリーン幅に応じて列数が変わるサンプル。モバイルでは2列。

スクリーン幅に応じて列数が変わるサンプル。タブレットでは3列。

スクリーン幅に応じて列数が変わるサンプル。デスクトップでは6列。

このように、Bootstrap3のグリッドシステムにより、スクリーン幅に応じて動的に変化する柔軟なレイアウトを、とても手軽に実現することができます。

以上が、Bootstrap3のグリッドシステムの基本です。他にもいくつか機能がありますので、詳しく知りたい方は公式ドキュメントを参照してください。

まとめ

レスポンシブWebデザインを前提として生まれ変わったBootstrap3は、洗練されたデザインのWebサイトを手軽に実現できるというだけではなく、その強力なレイアウト機能や利便性の高いコンポーネント、そしてテーマ機能のおかげで、「汎用的で強力な、Webサイト構築フレームワーク」になったという印象を受けました。

完全にレスポンシブなWebサイトを構築するつもりがなくとも、また、Bootstrapのデザインを最終的に採用する予定がなくとも、まずはサイト構築の基盤としてBootstrapを使う…というのも、開発のやり方としてアリなのではないでしょうか。

二週に一度、月曜日にお届けする海外のWeb開発に関する最新ニュースを厳選。今回は、開発リーダーであるPamela FoxによるBackbone.jsを使ったアプリケーションガイド記事をはじめ、21本のニュースを紹介。HTML5 Experts.jpのエキスパートの皆さんの協力を得て、キュレータは私、斉藤祐也がお届けします！

注目ニュースピックアップ

実践! Backboje.jsを使ったアプリケーションガイド – pamela fox’s blog

原題: A Guide to Writing Backbone Apps at Coursera

オンライン学習サービスを提供しているCourseraでBackbone.jsを使ったアプリケーションをどのように構築したのか、開発リーダーであるPamela Foxによる紹介。
Backbone.jsのモデルやコレクション、ビューなどの設計はもちろんアーキテクチャ、APIについても細かく紹介されている。ハウツー記事は多くあるが、実際の設計、実装について紹介されることは稀なので参考になる点が多い。 さらに記事中からもリンクがあるが、Courseraで利用しているJSのライブラリ/ツール集まで公開しているのであわせてぜひ。

CSSプリプロセッサ、Sassの次期バージョンの変更ポイント – The David Walsh Blog

原題: Looking Into the Future of Sass

CSSプリプロセッサの中でも人気のあるSass、そのSassの次バージョン、あるいはそれ以降で実装される予定の機能について紹介。
リファレンスセレクタである&が大幅に改良されていたり、if()、リストのオペレーション、@forループの改良など、細かい部分までしっかりと改善がされていく印象だ。 どの機能もあくまでも実装予定という段階ではあるので、実際のところが気になる方はぜひSassのオフィシャルレポジトリをのぞいてみるといいでしょう。

新しくなったPageSpeed Insights – Google Developlers

原題: PageSpeed Insights

ウェブサイトのパフォーマンス計測においての総合チェックツールとして長らく我々デベロッパから利用されているGoogle PageSpeed Insightがリニューアル。
モバイルとデスクトップ両方でチェッカーを使えるようになっていたり、改良ポイントが非常に見やすくなっていたり、チェックポイントも増えていたりしている。
ドキュメントもアップデートされているので、再度一読してほしい。

JavaScriptのスタイルガイドを詳しくガイド – ②ality

原題: A meta style guide for JavaScript

現在、JavaScriptのスタイルガイドは多く公開されているが、この記事ではそれらのスタイルガイドに含まれるガイドライン達の裏側にある理由についてまで紹介している。
どのスタイルガイドがいいか、という話ではなくどういう理由でガイドラインが存在するのかを知ることで自分やチームにとってよい選択ができるようになる。このレベルの詳細さでガイドラインについて紹介されている記事は稀なので、リファレンスとしていつでも参照できるようにしておくといいだろう。

海外トレンドコラム

オブジェクト指向プログラミングがすべての問題を解決できない理由 – HTML5 Hub

原題: OOP is Not Your Hammer

JavaScriptにおいても大切なコンセプトであるオブジェクト指向のプログラミングアプローチはもちろん、すべての問題を解決できるわけではない。記事ではシンプルな例を元にオブジェクト指向が苦手な問題を提示し、解決策としてイベント駆動のアプローチ、そしてアスペクト指向プログラミングのアプローチを紹介している。

Handlebars.jsの裏側を知ろう – Nettuts+

原題: Handlebars.js – a Behind the Scenes Look

JavaScriptのテンプレートとして、シンプルでありながらも強力であり、高速なツールとして知られるHandlebars.jsについて、裏側で実際にどんな処理を行っているかについてを詳しく解説。

モバイルブラウザではDataURIは画像を読み込むよりも6倍時間がかかる – Mobify

原題: On Mobile, Data URIs are 6x Slower than Source Linking (New Research)

HTTPリクエストを減らすためのテクニックとして利用されるDataURIがモバイルブラウザにおいて、イメージデータを表示するよりもData URIを表示するほうが6倍ほど遅くなるそう。 記事では最終的にはきちんとキャッシュする前提でCSSスプライトを利用する方がパフォーマンスにプラスになると結んでいる。

CSSアニメーションで60FPSを実現するテクニック – Jeremy Kahn’s Dev Blog

原題: 60 FPS or Bust: Dynamically Prerendering CSS Animations

CSSのアニメーションのパフォーマンスについて、長きに渡り研究を重ねて来たJeremy Kahnがたどり着いた一つの解答。CSSプリレンダリングと名付けた手法について詳しく解説。

Backbone.jsアプリをセキュアにするための実装例 – Danial Khosravi’s Blog

原題: Advanced Security In Backbone Application

Backbone.jsを使ったシングルページアプリケーションにおけるセキュリティについて。クライアントサイドでアプリケーションのほとんどをやってしまう場合に知っておきたい大事なこと。

いまさら聞けない!? HTTPSがどうやって安全を確保しているのか

原題: How HTTPS Secures Connections: What Every Web Dev Should Know

HTTPSを使ったコネクションが一体どのようにして安全を確保しているのか。内容が内容だけに少々難しいが、非常によくまとめられている。完璧に知ってなければならない、ということはないが知っておいて損はないのでぜひ。

UXアンチパターン – 90 Percent Of Everything

原題: The slippery slope

UXの中でも特にメールでの通知やサインアップなどについてのアンチパターンについてのプレゼンテーションのまとめ。アンチパターンは見た目上の成長につながるかもしれないが、ブランドを生み出すことを阻害する。

クローズアップ“ビデオ/スライド”

60分Angular.js基礎講習 – Dan Wahlin

原題: AngularJS Fundamentals In 60-ish Minutes

フロントエンドのMV*ライブラリとして今では多くの実装例があるAngular.jsの基礎を60分で紹介していく動画。
これからAngular.jsを学ぼうという場合にはぜひ。
スライドはこちらから(PDF)。

Ember.jsを無料で学べるコース – Tuts+

原題: Let’s Learn Ember

Angular.jsを紹介したら、Ember.jsについても言及しておかないと。ということで、Tuts+からEmber.jsについて学べるコースがこちら。
動画自体は14本あるが、それぞれがきちんとカリキュラムに沿って分割されているだけで、合計すれば60分ほど。

詳解: Adobe発UIライブラリ、TopCoat – Adobe TV

原題: Getting Shellacked with TopCoat

Adobe発のオープンソースUIライブラリであるTopCoatについての紹介動画。TopCoatの使い方や、実例やそもそもプロジェクトがどんな問題を解決しようしているのかについて紹介。

オブジェクト指向JavaScriptガイド – Object Playground

原題: Object Playground: The Definitive Guide to Object-Oriented JavaScript

JavaScriptに限らないがオブジェクト指向プログラミングはなかなかコンセプトが理解しづらいものだが、この30分ほどの動画ではオブジェクトを車に例えることなく、継承の概念やプロトタイプなどについて分かりやすく解説。ページ下にあるオブジェクトグラフ生成ツールも非常によくできているのでぜひ、試してみてほしい。

一歩先行く“コード”

JointJS – JavaScript diagramming library.

JavaScriptを使ってダイアグラムを生成するという非常に意欲的なツール。
マウスオーバーで情報を表示したり、ダイアグラムをドラッグできたりもできるのでこちらのサンプルから試してみてほしい。

eslint – Nicolas Zakas

JSLintとJSHintと同じ種類のツールであるESLintはCSSLintの開発メンバーの1人でもあるNicolas Zakasの新しいプロジェクト。開始されたばかりなので、不安定な状態ではあるが、開発スピードはものすごく早いので近くアルファ版あるいはベータ版もリリースされるだろう。

VerbalExpressions – jehna

サーバでもクライアントでも利用できるJavaScript(現在は他言語にもポートされている)の正規表現ツール。
jQueryのようなFluent風のAPIで普通の言葉のように正規表現を利用できるようにしている。

leapjs – leapmotion

白石編集長主催のWeb先端技術味見部でもさっそく取り扱われたLeapMotionをJavaScriptでプログラムできるフレームワーク。例も多く含まれているので、LeapMotionが届いた方はぜひ試してみてほしい。

jspm.io

クライアントサイドのJavaScriptが複雑化、巨大化傾向にある中、パッケージマネジメントをどうするのかが求められている昨今で、ES6から利用できるようになるかもしれないシンタックスを使ってモジュールを利用できるようにする解決がこちら。

海外で話題の“ツール”

less2stylus – Andrey Popp

CSSプリプロセッサであるLESSをStylusに転換するコマンドラインツール。
Twitter BootstrapなどのようなLESSを利用したツールなどもStylusに変換できる。

Native HTML Widgets/Forms – Cody Lindley

ツールと呼ぶにはややシンプルすぎるきらいがあるが、HTML5にて定義されている追加されたフォーム属性を一覧化し、各ブラウザでどのようなUIになるのかを簡単にチェックできるページ。

★次回の「斉藤祐也の海外WEBテク定点観測」は、8月19日にお届け予定です。★

HTML5 Canvasを利用した冷気の演出が話題となった「RAIZIN JAPAN」のデモサイト。エキスパートが手がけたプロダクトを題材に技術的な解説を行っていくシリーズ第二弾は、RAIZIN Coolの実装を徹底解説します。

HTML5 Canvasを利用した簡易的な冷気の演出

最近の仕事で実装したものが海外の、しかも米シリコンバレーで話題になりました。
社内でもそうした簡単にできる（けど簡単そうに見えない）簡易的な実装に注目が集まり、ちょっとした話題になったので解説しつつ紹介したいと思います。

※今回の解説用に、jsdo.itに実際に動くサンプルをアップしました。
さらに今回の解説用に特別に動作が分かりやすくなるオプションも追加しています。↓ (invalid jsdo.it code)

今回紹介するのはRAIZINというエナジードリンクの新バージョン「Cool」のLPです。
当初はとても時間がタイトで限られた予算での実施ということもあり、まったく動きのないペライチにしようという話になっていました。

しかしそれだとどうしてもインパクトが出ない。
「時間と予算が限られた中で、それでも少しでもインパクトのあるものが作りたい」
とエンジニアとデザイナーで話し合いました。

あ、ちなみにこの記事を書いているのは私ですが、方向性、実装方法などおおまかに話したあとは実装は社内の別のエンジニアが行なっています。

どこに人はリアリティを感じるか

話し合いは、まずはどうしたらリアリティが出るか、という話をメインに行いました。
話し合い時点である程度デザインはでき上がっていたので、それを元にどうしたらリアリティが出るか、どういう演出が考えられるかを話し合いました。

最初に着目したのは冷気。まぁここは当然ですね。なにはなくとも冷気がなければ冷えている感、Cool感は出ません。問題はこれをどう動かすか、でした。
当然、高度な物理演算を用いて冷気をリアルに動かす、ということも考えましたが、当然時間が足りない。（それこそ、1～2日くらいしか時間が残されていなかった）

みんなであれこれ話していて、冷気の動きは実は3種類くらいしかないのでは、とひらめきました。

• 缶から出て下に落ちる縦の動き
• それが地面に到達してわだかまり、渦を巻いている状態
• たまった冷気が缶から離れていく横の動き

おおまかに動きを分解すると、この3つの動きだけで実装できそうだと気づきました。
閃いてからは話は早く、あとはそれをどう実装するか、という話になります。

Canvas要素を使って冷気表現

今回選択したのはHTML5から定義されたCanvas要素。
冷気の動きには回転を含んでいたのと、冷気同士の色みを合成することを考えて選択しました。

実際に実装を始めてみるといくつか問題がありました。

• 冷気の画像は左右で対象なので同じタイミングで出すとバレる
  違う画像をデザイナーに頼もうかと思いましたが、時間も素材を用意できるか微妙だったので、左右で煙の出るタイミングをずらしたらほとんど目立たなくなりました。
• 回転する冷気は縦横に比べて速度を落とす
  回転する冷気は、縦と横で動いている冷気よりも目立ってしまったので、回転速度をだいぶ遅くしたら違和感がなくなりました。
• 冷気の最初はグラデーションマスク
  縦に動く画像の出始めの部分は、缶から冷気が出ているというより空中から出ているようになるので、上からグラデーションで透明にしたマスクを置きました。

最終的には冷気の出現の仕方・速度を調整することでだいぶリアリティのあるものができました。
やはり、予算や時間がタイトな案件は多くあるもの。その中でどうしたら表現したいものに最大限近づけることができるか。
本当に計算をして表現する以外に方法がないか模索してみるといいと思います。

構造を分解

今回作成したものは上記で書いた通り比較的簡易な表現になっています。
そのため、レイヤー構造もとてもシンプル。
おおまかに構造を分解したものが以下の画像です。

全体は3つのレイヤーのみ

見てもらうと分かる通り、メインとなる缶の画像を含めても3つのレイヤーしかありません。
構造は

• メインの缶画像レイヤー
• 冷気を表現するCanvasレイヤー
• マスクレイヤー

の3つです。

DOM要素的にはもっとありますが、レイヤーとしては3つです。

Canvas内のレイヤーも3つ

さらに演出のメインとなるのはCanvas要素のみです。
そのCanvas要素内で動いているものも3つのレイヤーからなっています。

冒頭に書いた「気付き」を元に構成したものです。つまり、「縦・横・回転」の3レイヤーです。　　 これをそれぞれ個別にアニメーションさせながら今回の演出を表現しています。

アニメーション自体は実にシンプルで、縦・横ともにひとつのPNG画像をうまくループするように配置しアニメーションさせるだけです。
回転に関してはさらにシンプルで、移動はせず、単純に配置された場所でゆっくりと回転させるだけです。Canvasアニメーションを実装したことがある人ならそれこそものの数分で作れる演出です。

それぞれのアニメーションで使用した画像は以下の3つだけです。

縦にループさせている画像

横にループさせている画像

回転させている画像

jsdo.itのサンプルを動かして理解しよう

冒頭でも書きましたが、今回制作したものがどういう仕組で動いているのか確認できるものをjsdo.itにアップしました。
各項目をOn/Offすることで動作がどういうものか理解できるかと思います。参考にしてみてください。

ちなみに3Dをオンにしたあとはさらにドラッグで回転することができます。
どういう構造になっているのかを理解するのに役立つと思うのでそちらも参考にしてみてください。
※jsdo.it上にアップしたサンプルは、実際のサイトに公開されているものとは別物です。
動作確認がしやすいように、処理を最適化しています。

(invalid jsdo.it code)

話題にされた記事

• 「RAIZIN JAPAN」HTML5 CANVASを使用した冷気の表現が話題に 【@maskin】
• HTML5で冷気を表現したサイトがすごいな
• 「HTML5で冷気を表現したサイトがすごいな」を分解してみた！