「HTML Conference 2013」で行われたセッションから、株式会社サイバーエージェント大谷剛氏と船ヶ山慶氏による「現場の実例から学ぶ、最新鋭のWebアプリケーション開発フローとアーキテクチャ」の模様をお伝えします。

「なぞってピグキッチン」とは

今回作ったWebアプリケーションは、「なぞってピグキッチン」に使っている基本的な技術は、HTML、CSS、JavaScript。これにCanvasなど、他のフレームワークを組み合わせていますが、基本は前者の3つです。これをスマートフォンのブラウザ上で動かし、ネイティブのアプリと近い状態を作り上げたサービスです。

基本的な流れは、例えば（画面上の）ボタンをタップすると、背景色や文字色が変化する。さらに、せっかくCSS3が使えるのだから、角丸やシャドウを付けてみる。さらにアニメを付けてみる。――さらには画面全体を動かして、ぱっと見、ネイティブアプリのようなものを頑張って作りましょう、という流れです。

これが、HTML、CSS、JavaScriptですべて作られている基本の画面です。

左下に自分のアバタがあり、中央にキッチンがある。キッチンをデコレーションし、レシピを並べ、友達に料理をふるまい、キッチンを核にやっていこうと。それを楽しむゲームです。下のボタンを押せばモジュールが開きますが、モジュールからモジュールへとたどっていくのが基本の動きです。基本のURLは一つで、ページのリロードはせず、hashの部分のみで見た目を切り替える仕組みです。

ゲームの流れとして、パズルをして料理に必要な素材を収穫し、それを使って料理をします。制作チームのメンバーは、プロデューサー、エンジニア、デザイナー、ディベロッパーの大きく4つの職種があり、各職種にリーダー的なの人がいます。

フレームワークについて

フレームワークは世の中にたくさんあるのですが、それぞれ特性があります。例えばjQueryなどは有名ですが、スマートフォンで使うには、通信帯域が狭い中でファイルサイズが大きく厳しい。このように、どれがサービスに合っているのか、適性を見極める必要があります。

今回、「なぞってピグキッチン」に使用したフレームワークは「beez」と呼ばれるもの。現在は社内でしか使えませんが、近く社外にも公開する予定なので、その際には試していただければと思います。「スマートフォン開発をスピーディに進めるための、中・大規模クライアントブラウザ向けのフレームワーク（開発ツールキット）」というのが、beezの基本的立ち位置です。

ここで「開発ツールキット」とあるのは、スマホに特化したライブラリ、相性のいいライブラリをまとめてラップしたというのが大きな特徴だからで、そのためbeezを使う場合はbeez専用の言語、書き方ではなく、既存のライブラリの組み合わせで効率よく書けるようになっています。

主に先ほどのライブラリの中から、クライアントが主に触ると思われるものが以下の7つです。

＜１＞ Backbone.js

＜２＞ Underscore.js

＜３＞ Zepto.js

＜４＞ RequireJS

＜５＞ Handlebars

＜６＞ Stylus

＜７＞ bucks.js

簡単にまとめると、Backboneがbeezの中では全体のフレームワークを担い、HandlebarsがHTML、StylusがCSS、ZeptoがDOM操作、Underscoreがユーティリティ、Requireがモジュールを担っています。beezは、これら既存のライブラリに追加する形で、Manager、Controllerという概念を持っています。

Managerは、viewに関しては、グローバルに必ず1つしか存在しない、viewを必ず監視している立ち位置にあります。しかもviewが必要なくなったタイミングで、それを全部破棄しメモリ上から消したり、また必要になった場合には再復帰させたりします。特にスマートフォンの場合はメモリ制限が厳しいので、こうしたマネージメントを行うのが、beezの中のManagerの概念です。

beezは、ツリー構造でviewを管理しています。これはBackboneとかではなく、beez独自のものです。

Controllerの概念は、まずRouterというもの――これはBackboneのものなのですが、hashのフラグメントを常に監視しています。これがモジュール単位で、「クエスト」といったhashに書き換わると、クエストのControllerが呼ばれて、複数のviewとmodelを一気に作成します。そのうえで、クエストが必要としているCSS、i18nのファイルをロードします。

アーキテクチャ

M（Model）とV（View）とR（Router）、これにプラスして、beezのM（Manager）、C（Controller）。この5つの構造で、アプリケーションは成り立っています。

全体の流れとしては、Routerが会社に例えれば社長のような立場にあり、hashを常に監視していて、hashが変わったタイミングで、Controllerという部長クラスに指示を出します。Controllerは、その指令に従って、各社員にあたるModelに指令を下ろす。Modelは更に下のViewに指示。こうしてアプリケーションの見た目に反映される。このようなトップダウンの仕組みで、ボトムアップは基本NGですが、ViewからModelへは、ユーザーがタップした際のアラーム的なものは出ます。

これをまとめると、一番最初にログインした段階で、hashが何であれ、強制的に#mypageに書き換えます。それをRouterが捉え、該当するController（MyPageController）を呼び出します。MyPageControllerはViewとModelを作成。それぞれをひもづけて、いわば社員の“人員配置”をします。ここでユーザーがタップ操作をすると、それがModelに伝わり、Modelが上に伝える。例えば「area」というボタンがタップされたとすると、「#area」というhashに変えてくれというリクエストが行く。#hashに変わってからの流れはまた同様です。

共通機能群

最後に共通機能の部分について。先ほどから何度も登場しているアバターはCanvasで描かれていて、好きなところに移動もできますし、好きな服を着せてやることもでき、動作のバリエーションを登録しておけば、好きな動きをさせることも可能です。

服情報は、アバターの動きに合わせて服の位置等も変わるので、それに合わせてシート化されたものが用意されています。下に一見、横線のように見えるものがありますが、これは画像のデータを持っていて、腕の回転中心の座標情報などがここにあります。

あとは下から開いて左右に移動するなどといった、いかにもスマートフォンアプリっぽい画面制御。これもカスタマイズすれば、一部を固定し部分だけガリガリ動くといったことも可能です。

ポップアップもよく使いますが、これも基本形を作っておいて、それを適宜カスタマイズ。また、リロードが発生したときにエラーデータをキャッチし、ポップアップを自動で表示させるといったことも可能です。

【講演資料・セッション映像】

楽天では、10月26日に「Rakuten Technology Conference 2013」を開催し、多くの方にご来場頂きました。ご参加者の皆様、ありがとうございました！

私が所属している「HTML5 Project Team」が担当したセッションでは、今回制作を担当したカンファレンスのサイトについて発表をしました。技術者の祭典ということもあり、HTML5やフロントエンドの技術をふんだんに盛り込み、皆さんご存知の賑やかな楽天市場とはひと味違ったクールなサイトに仕上げました。ご覧頂けましたでしょうか？

当日のセッションの内容と重複しますが、今回は、HTML5の活用事例として、このサイトがどのような技術で作られたのか、セッションでも使用したスライドを交えて紹介していきます。

「Rakuten Technology Conference 2013」サイトのコンセプトと要求仕様

このサイトでは、よくあるカンファレンスのサイトと同じく、講演者の紹介やタイムテーブルなどを公開しています。メインのターゲットユーザーはエンジニアで、日頃はPCをよく使い、最新のスマートフォンを持ち歩いていると想定しました。また、情報だけでなく技術面でもアピールする機会にしたかったこともあり、過剰なほどにあらゆる技術を盛り込んでいます。

サイトを構築する上で、いくつか要求仕様がありました。

• 情報の更新が頻繁に行われる
• SEOを考慮する
• サーバサイドスクリプトは使用しない

これらを満たすために、

• 都度、複数のHTMLを編集するのではなく、スタッフから受け取ったデータ（JSON）からHTMLを生成する。
• サーバサイドスクリプトが使えないので、ローカルで生成する。

という方針を定め、様々な技術を使って実現しました。

活用した技術

コンテンツ自体にもHTML5をはじめとした最新技術が使われていますが、制作面においても、最新のツールを駆使して効率化を図りました。

Canvasを使ったインタラクティブな背景

サイト全体にタイルをモチーフとした背景を採用していて、PCでご覧頂くと、マウスの動きに合わせてハイライトとされ、タイルが微妙に移動していることがわかるかと思います。この背景部分は、Canvas で描画しています。PC向けにはタイルは固定幅ですが、タブレット向けでは画面幅に合わせてタイル幅を調整しています。また、Canvasの処理部分にはCreateJSを使用しています。

CSSによるスムーズなインタラクション

トップページの「M」のタイルをクリックすると、実行委員長からのメッセージが表示されます。このとき、委員長の顔のタイルが拡張して、それに合わせて他のタイルが追いやられるようなアニメーションを行っています。この動きはCSSによって実現されていて、スマートフォンでも同様に動きます。これ以外にも、様々な場面でCSSによるアニメーションを使用しています。

スマートフォン最適化とレスポンシブWebデザイン

当日会場でスマートフォンからタイムテーブルを確認することを考慮し、スマートフォン対応をしました。タイムテーブルは縦横に長いコンテンツのため、スマートフォンとの相性は悪いのですが、時間帯ごとに横スクロールするようにして、閲覧性を確保しました。

各デバイスへの対応は、レスポンシブWebデザインで行いました。PCとスマートフォンでレイアウトが大きく異なるので、かなり苦戦しました。

また、それぞれの表示ごとにJavaScriptの処理も異なっているため、ウィンドウ幅を監視して、表示の切り替わり時にそれぞれ適切な処理を実行するような仕組みも取り入れました。

お気に入りのセッションをブックマークできるWeb Storage

タイムテーブルで、お気に入りのセッションをブックマークできる機能を追加しました。ブックマークするとブラウザのlocalStorageに保存され、いつでもお気に入りのセッションだけを表示できます。

また、ページ上部のSpeakersやUpdatesの部分に、赤枠の数字が表示されますが、これは、前回閲覧したときのデータをlocalStorageに保持し、今回読み込んだデータ数の差を表示して、何件更新されたかを示しています（表示すると消えます）。

PCで登録したブックマークをカンファレンス当日にスマートフォンで呼び出せるように、URLでその情報を引き継げるようにはしていたのですが、UIを提供できませんでした。来年はその辺りも提供できればと思っています。

PhantomJS + UnderscoreJSで更新負荷を下げる

PhantomJSは、コマンドラインから呼び出せるWebKitエンジンで、今回は、テンプレートとデータからHTMLを生成する処理で利用しました。テンプレートエンジンはUnderscore.jsを利用しました。

講演者の情報やセッションの時間などの情報は開催日まで頻繁に更新があり、その度にHTMLを修正しているとかなりの手間となります。そのため、それらの情報をまとめるカンファレンススタッフに、データをJSON形式で記述して納品してもらうようにしました。納品されたJSONファイルをUnderscore.jsでテンプレートに適用して、HTMLを出力しました。

データは構造化されているため、例えばタイムテーブルのデータを更新すると、タイムテーブルだけではなく、その講演者のページの情報も同時に変更されます。また、セッションの場所の名称が変更されたときも、１箇所修正するだけで、すべての名称が新しいものに置き換わります。

レスポンシブ対応がシンプルに記述できるSass / Compass

CSSの生成には、おなじみSassとCompassを使用しました。Sass内でif文を使って各デバイスの判定ができるようにして、レスポンシブ対応がシンプルに記述できました。

Gruntによる処理の自動化

PhantomJSでのHTMLの生成、Sass/Compassのコンパイル、ファイル操作などはGruntを使い自動化しました。PhantomJSの呼び出し部分は、いいモジュールを見つけられなかったため、シェルコマンドを呼び出すタスクを書きました。

このように、目的に合わせた最新技術に挑戦して、今回の「Rakuten Technology Conference 2013」のサイトを作り上げていて、私たちも様々な収穫がありました。まだ、パフォーマンスやユーザビリティなどで不十分な点もあるので、今後の課題として取り組みたいと思っています。

また、「サーバでスクリプト使えなくても、ローカルでRubyやPHPとか使えば楽じゃね？」という話もありますが（汗）、そこは我々「HTML5 Project Team」ということで、今回はフロントエンドの技術だけにこだわってみました。来年は、NodeベースのWebサーバに移行して、より簡単にサイトを更新できるようなことも考えています。

今後もこのような挑戦を続け、そこで得ていく知見を楽天のサービスに活かして行きたいと思っています。またこのような形で、いつもお世話になっているコミュニティにも還元できれば幸いです。今後ともよろしくお願いします。

このセッションのビデオはYouTubeにアップされており、使ったスライドもSlideShareで公開されています。もしよろしければそちらもご覧ください。

HTML5化によるSEO効果の影響はあるか

WebサイトをHTML5でマークアップをする際、特にHTML4などからHTML5にリニューアルする場合に、それによって検索エンジンによる評価が変化するのかどうかは非常に気になる問題です。

各検索エンジンでは、この疑問について公式に説明しています。GoogleはHTML5化することでプラスにもマイナスにもならないと度々公式に言及していますし、Bingは「List of things you really ought to know as an SEO today(今SEOとして本当に知っておきたいこと)」と題した記事の中で、HTML5について言及しています。こうした情報を併せて考えると、主要な検索エンジンは、HTML5化は問題ない、もしくは推奨しているとさえ言っても良いでしょう。

しかし、本当にHTML5化することでSEO上の問題は起きないものでしょうか。 私はSEOの専門家として、HTML5のWebサイトに多く関わってきました。お客様のWebサイトでのHTML4からHTML5への変更も何度か経験しましたが、実際HTML5化で検索流入が伸びたことも減ったこともありません。しかし過去に数度、HTML5化を含むリニューアルの結果、大幅に検索流入を落としたWebサイトの話を聞いたことがあります。

「問題ない形のHTML5化」であれば、検索エンジンはその評価を変えることはないと私は考えています。しかし、SEOの知識を一切持たずにHTML5化すると、犯しがちなミスもあります。 本稿では、SEO上の問題を起こさずにHTML5化するために注意すべきポイントを説明しましょう。

HTML5のマークアップをする際の注意点

FlashからHTML5へ。リッチな表現のSEO手法

ほんの1～2年前までWebでリッチな表現をするには主にFlashが使われていましたが、FlashコンテンツのSEOには明確なベストプラクティスがありました。それは、FlashコンテンツはJavaScriptを使って呼び出すようにし、JavaScriptを扱えない環境向けにテキスト情報を追加するという方法です。noscript要素やSWFObject等を使った代替要素としてのテキスト情報を加えることや、それに加えてページ分割やSWFAddressを併用することで、Flashであっても非常に高いレベルの検索エンジン対応が行うことが可能でした(この詳細は4年前の拙筆ですがこの記事に詳細を記してあります)。

FlashコンテンツのSEOは、このように代替要素を使用する方法が一般的でした。その手法を検索エンジンも公式に推奨する場合もありましたし、検索エンジンのアルゴリズムとしても、Flashを認識するようになっていきました。その結果、Flashを活用したリッチなコンテンツを検索できる状態にする方法が確立したのです。しかしそのようなFlashの登場から、そのSEOのベストプラクティスが確立するまでには、長い期間を必要としました。

さて現在ではFlashを使う機会は減り、同じニーズに対してHTML5を使うシーンが多くなりました。HTML5では様々な描画を行うcanvas要素や、動画を再生するvideo要素、音声を再生するaudio要素などが追加されています。それらの新要素を中心としたWebページを制作する場合、どのように検索エンジンに認識させるべきか、という議論はほぼ行われていません。

この方法として、いくつかの方法が考えられます。例えばcanvas要素は、要素内にフォールバック・コンテンツとして、テキスト情報を組込むことができます。2013年9月1日現在、このテキスト情報はGoogle、Bingの検索エンジンでは認識しています。しかし一部の検索エンジンでは、canvas要素のフォールバック・コンテンツを認識しませんし、サイト内検索等で使われるシステムでは認識しないことがありました。対応されている検索エンジンにおいても、検索エンジンが公式にサポートしているものではありません。今後扱いがどのように変わっていくかも不透明でしょう。フォールバック・コンテンツだけに頼ることは不安があります。

Flashコンテンツが一般化することで、検索エンジンに認識させる様々な方法が試されて検索エンジンも対応を始めたように、今後HTML5が一般化した後にリッチコンテンツを検索エンジンに認識させるためのベストプラクティスが出てくるものでしょう。しかしそれが確立していない現状では、いろいろと試す必要があるのです。

さて、実際に現段階ではどのようにするべきでしょうか。まず考えられるのは別ページを作ることです。Flashが一般化する前は、Flashを中心としたページとは別に同じ内容をテキスト中心で知らせるWebページが作られていたように、テキスト中心の別ページを作ることが確実でしょう。ただそれが困難な場合には、何らかの方法でテキストでの代替要素を配置するしかありません。FlashはJavaScriptで呼び出すことが多かったため、代替要素が配置しやすかったのですが、JavaScriptを使わないHTML5の新要素では別の方法を考える必要があります。

代替要素を作るためには、CSSを利用した切り替えを用意しておくことが、現段階では一番お勧めできる方法です。ユーザへの適切な情報提供を目的としてテキストを切り替える形で配置することは問題がないと、Googleは公式に説明していますので、Canvas等のリッチな表現を使いたくない人向けの情報も同ページで提供した上で、切り替えて使用できるようにするのが最も適切でしょう。

canvas要素の場合にはフォールバック・コンテンツとしてのテキスト情報追加も選択肢の一つです。先にも書きました通り、一部検索エンジンは対応していませんし、今後の扱いは不透明です。しかし日本で圧倒的なシェアを持つGoogleは現段階では対応していますし、今後についても、HTML5の公式仕様に基づいたマークアップを大きく不利にする可能性は低いものです。対応しなくてはならない検索エンジンがGoogleだけなのであれば、フォールバック・コンテンツは良い選択肢でしょう。

ここまで、リッチな表現のSEO手法について書いてきましたが、本来リッチな表現を検索させる上で、最も重要な事は技術的な要件ではありません。そもそもの話ですが、検索される必要がある情報をリッチコンテンツを中心として制作するのが誤りでしょう。そのWebページで伝える事を表現するのに適切な手法は何なのか、ということから考えてみることをお勧めします。

SEO効果があるh要素の使い方

HTML5とSEOを考える上で、よく言及されるのはhx要素をどうするかということです。

HTML5ではh1要素を複数設置できるようになりました。しかしh1要素の扱いはSEOの観点で極めて重要です。Googleが公式に配布しているSEO初級者向けの「検索エンジン最適化スターターガイド」でも「見出しタグを適切に使おう」として、1ページ丸々を費やしてユーザに説明をしています。実際、数年前のように、h1要素とするだけで順位アップといった単純な効果はありませんが、hx要素をうまく使って文書を整理することは、検索エンジンもその文書の構造を把握しやすくなり、様々な面でプラスとなります。

h要素のSEO要件が語られる際に必ず言われることとして、「h1要素はそのページのテーマを示す内容として、1ページに1つのみにする」があります。しかしHTML5では、h1要素を複数使用することは、仕様として推奨されています。では、HTML5の仕様どおりにh1要素を複数でマークアップすることは、SEOにとって不利になるものでしょうか？

これは不利になる場合もあるし、ならない場合もあるというのが私の考えです。実際にWebページによって、hx要素の番号がどうなっていても検索エンジンの評価に影響を与えないような場合もあれば、甚大な影響を与えるケースも確認しています。

有力な検索エンジンは。ページ内のどこが重要な情報かを識別しようとしています。サイドバーやフッターなどに記された情報は、あまり検索結果に表示されづらいですし、メインカラムの情報は表示されやすいということは、少し注意して検索エンジンを利用しているとわかることでしょう。これはサイドバーなどに共通の情報が記載されがちなことが原因である場合もありますが、例えそのページにしかない情報がサイドバーに記載されていても、検索結果には表示されづらいものです。

どこの部分が重要かという検索エンジンの判別は、一つの要因だけで行うものではありません。様々な要因を使って判定していると考えられますが、私はその要因の一つとしてhx要素の番号が使われていると考えています。hx要素の番号がその判別に重要な役割を果たしているようなWebページでは、hx要素を全てh1要素とすると流入の減少につながりますし、他の要因が重要なページでは大きな影響が出ないことでしょう。

そのため、必ずしも全サイトで必須とは言い切れませんが、SEOを考えるとやはりh1要素は1つで、h2要素以後もうまく使って文書構造を示しておくのが安全と考えられます。

先に述べたとおり、HTML5化したサイトではh1要素を複数使うことが一般的です。hx要素は全てh1要素にした上で、section要素の入れ子構造で文書構造を示すのはHTML5の仕様上正しいとされていますが、h1要素は1つとしてh2要素を中見出し、h3要素を小見出し……と使っていっても問題はないとされています。どちらでもよいのであれば、SEOには確実に問題がない後者の方法を使うべきでしょう。

とは言え、大規模サイトでページ内のパーツを様々なページで流用する場合に、hの番号の整合性が取りづらいため、全てh1要素にするWebサイトも多くあります。そのような場合もページのテーマとなる部分一箇所だけにh1要素を適用して、流用するパーツにはh1要素を使わずにh2要素から始めるようにしておくだけで大きなSEO上の問題は避けられるでしょう。流用する部分は全てh2要素から始めておくことは全ての使用ケースで問題がないわけではないかもしれません。しかし、全てh1要素にすることで発生するSEO上のリスクを考えると、どちらかというと問題は小さいと考えます。

HTML5の把握でレベルが高いGoogleの検索システムは、日本では圧倒的なシェアを持っています。しかし、100%ではありません。Google以外の検索エンジンでは、まだHTML5をうまく扱えないものがあります。その際に一番大きな問題となるのはこのhx要素です。実際、HTML5化した際にある検索エンジンでは、h1要素が複数あることで大きな問題となっている事象を確認しています。h1要素は検索エンジンスパムにもよく使われるため、非常に問題を起こしやすいものでもあるのです。

ご存知の通り、HTML5は普及したといえる段階ではありません。現状ではHTML5に対応していない環境のことを考える必要があります。そのためにもh1要素は1つにしておくべきでしょう。

HTML5で追加・削除・復活した要素

HTML5では、いくつかの要素が追加・削除・復活しました。

まず気になるのは、nav要素やfooter要素などの意味を持った要素でしょう。これらの要素は、現段階での私の観測の範囲では、検索エンジンからはこれまでのdiv要素と同じ扱いを受けているようです。しかし今後HTML5が普及した際には、様々な形で検索エンジンも活用し出すことが考えられます。

今後を考えれば、ページの情報を正しいHTML5でマークアップをしておくことが、唯一の対策となるでしょう。検索エンジンは正しいHTMLしか評価しないわけではありません。インターネット上で公開されているWebページのほとんどは、マークアップ上のミスを含んでいますので、主要検索エンジンはそのミスを織り込んでWebページを認識しようとしています。HTML5は、現段階では人によって使い方に大きなブレがあります。そのため必ずしも正しいHTML5しか評価できないように、アルゴリズムを組んでくるはずはないと考えられます。しかし今後どのような評価を行ってくるかはわかりませんし、全ての検索エンジンが、HTMLのミスを織り込めるほどの技術を持っているとは限りません。やはり最大限仕様上は、正しい形でのマークアップをお勧めします。

次に注意するべきポイントとして、これまでは推奨から外れていたものの復活した要素です。

特に注意するべきはiframe要素でしょう。XHTMLで非推奨とされていたiframe要素も、HTML5で復活したことで、使用するWebサイトも増えているようです。しかし、検索エンジンはiframe要素の扱いが得意ではありません。検索エンジンは、iframe要素を呼び出すURLへのa要素と同様に扱うのが通常ですが、iframe要素で呼び出すコンテンツをそのページのコンテンツとして認識している例もあります。

iframe要素に関わるアルゴリズムも進化を続けていますが、現段階では「iframe要素内のコンテンツは、ページ内のコンテンツとして認識されることもあれば、されないこともある」という非常に微妙な状態です。そのためiframe要素で呼び出されるコンテンツは「検索対象になるかもしれないしならないかもしれない」ものとして扱う必要があります。検索されるコンテンツを作る上では非常に使いづらいものですので、HTML5で復活したといっても、SEOを考える必要があるWebページでは使用しないことをお勧めします。

b要素やi要素など、スタイルを使いながら目立たせるために使われることが多いものの、セマンティクス上、重要という意味を持たない要素があります。それとは違い、strong要素については「他の部分に比べて重要」という意味を持ちます。SEOの知識としてstrong要素は「他に比べて重要」という意味であり多く使うと意味が薄れるため、限定的に使うべきとご存知の方もいるかもしれません。

ではHTML5で復活したb要素などは、無制限に使ってもいいのでしょうか。私はそれを勧めません。それは過去の期間において、b要素もstrong要素と同様に「他に比べて重要」という意味を検索エンジンが認識していたことがあります。現段階の認識が変わっているか確認できていませんが、継続している可能性もあります。その場合は、b要素・i要素が大量にあることで、strong要素も意味がなくなる可能性はあります。

HTML4では、b要素やi要素は使わずにCSSで表現するのがWeb制作の常識でした。HTML5でb要素が復活しましたが、使うことが義務づけられたわけではありません。これまで通りのspan要素とCSSを使ったマークアップをしておくことが無難と考えられます。

SEOを考えるとHTML5を使うべきか？

SEO観点でのHTML5でのマークアップにおいて注意するべきポイントを説明してきました。

現段階ではHTML5は普及しきっていませんので、検索エンジンの対応も中途半端です。その状況で何も考えずにサイトをHTML5化した場合、SEOに悪影響を及ぼす可能性はあります。

では、SEOのためにはHTML5は選択すべきではないのでしょうか。それは違います。今後の長期的なWebサイト運営を考えると、私はHTML5化を強くお勧めします。今後、HTML5を採用したWebサイトにはSEO観点でも何らかの利点が出る可能性が高いと考えます。ページの論理構造を作りやすいマークアップや、セマンテックウェブとの適合性は、今後のSEOで利点が出てくると考えられますし、様々な拡張性はより魅力的なコンテンツを作るのにも有益になります。それはSEOには極めて重要なポイントです。通常のWebサイトでは、HTML5を採用するかどうかという選択が行えるタイミングは、数年に一度しかないでしょう。選択できるタイミングでHTML5を選択しなければ、次に変更できるのは数年後かもしれません。その頃にはすでに、HTML5のSEO観点での利点は発生している可能性は否定できません。

冒頭でHTML5化を含むリニューアルで、大幅に検索流入を落としたWebサイトの実例があると述べました。それは詳細を調査すると、必ずしもHTML5が悪いわけではありませんでした。あるWebサイトでは、テキストでの代替コンテンツを含んだFlashコンテンツを全廃して代替コンテンツを含まないCanvasに置き換えたり、iframeを使い始めて検索流入を落としたということもありました。この問題についても、HTML5が悪いわけではありません。SEOの基礎知識がないことと、HTML5の正しい知識が少なかったことが問題です。その二つの知識があれば、HTML5はSEO観点で怖いものではありません。

まずは、今回ご紹介した3つのポイントに注意していれば、大きな問題になることはないでしょう。さらにHTML5を活用するために、SEOも少し配慮してWebサイト構築を進められることをお勧めします。

マンガテレビの紹介

「マンガテレビ」は最新のWeb技術をふんだんに活用し、イベント映像を“リアルタイムでマンガ化”するエンターテイメントツール。俗にいう「技術の無駄遣い」Webアプリケーションです。我らが、HTML5 Experts.jpの編集長「白石俊平」氏が開催している「（白石俊平と）カッコいいやつら」のイベント用ツールとして開発しました。

「マンガテレビ」を説明するのに言葉は不要。とにかく、サイトにアクセスしてみてください。ただし、Chromeでしか動作しません（後述のWeb Speech API利用のため）ので、その点ご注意ください。

なお、初回アクセス時は、下図のようにカメラとマイクへのアクセスを確認するダイアログが画面上部に表示されますので、「許可」をクリックしてください。

かの有名アプリ「漫画カメラ」を最大限に「リスペクト」したことは一目瞭然です。なお、「マンガ化」のアルゴリズムはこちらのslideshare(スライド9)を参考にさせていただきました。

しかし、そのままリスペクトするだけではなく、Webならではの機能をふんだんに盛り込みました。

盛り込んだ機能は大きく二つ。一つ目は「みんなで『かっこいいね！！』」機能です。これにより視聴者参加型の「マンガテレビ」を実現しました。

Webの特徴は、みんなが簡単に繋がれること。そこで、白石さん謹製の「かっこいいねボタン」と連携し、様々なエフェクトがかかるようにしました。「ボタン」を3回連打すると「ざわ・・」、5回連打すると「ゴ・・・」が画面を横切るという仕掛け。イベント参加者が「ちょっと、かっこいいね！」と連打すれば「ざわざわざわ・・」が、「すごい！！かっこいいね！！」と連打すると「ゴゴゴゴゴゴ・・・」と文字が横切っていきます。

もう一つは、「自動吹き出し機能」。最新Webの目玉機能の一つ “Web Speech API” を使い自動認識した音声を、吹き出しとして表示する機能です。

音声認識には誤認識がお約束ですが、その誤りっぷりが相まって、さらにエンターテイメント性を引き立ててくれています。なお、吹き出しの表示位置を調整するために、顔検出機能を利用しています。技術の無駄遣いっぷりは半端ではありません。

また、”WebSpeech API”による音声認識機能を応用し、音声コマンド機能も実装しました。例えば「バーン」と話すと、画面に集中線と「バーン」が表示されます。イベントの盛り上がりに欠かせない機能です。

なお、開発メンバーは、筆者を含め HTML5Experts.jp 編集部メンバー4名で開発しました。

マンガテレビ実装のポイント

この「マンガテレビ」の実装のポイントを紹介します。本稿では、以下の4点について紹介します。

• WebRTC と HTML5 canvas による映像のリアルタイムマンガ化
• WebSpeech API による音声認識
• headtrackr.js による顔検出
• WebSocket によるインタラクティブ機能

getUserMediaとHTML5 canvasによる映像のリアルタイムマンガ化

最初に紹介するのは「マンガテレビ」の基本機能。リアルタイムで映像を「マンガ」にする機能の実装方法の紹介です。

ステップは以下のようになります。

1. WebRTC の getUserMedia() により、カメラから映像を取得する。
2. HTML5 canvasのgetImageData() により、映像から画像データを取り出す。
3. 画像データにフィルター処理を行い、マンガ化する。
4. requestAnimationFrame() により、画像変換処理を繰り返す。

WebRTC の getUserMedia() により、カメラから映像を取得する。

まず、カメラから映像を取得します。これを行うためWebRTCのgetUserMedia()を使っています。(前述のとおり、Chromeを前提としているため、接頭辞 webkit を記述しています）

$v_ = $("video");

// カメラからのストリーム映像を取得し、videoノードのsrc属性にURL指定する navigator.webkitGetUserMedia({video: true, audio: false}, function(stream){ var url = window.webkitURL.createObjectURL(stream); $v_[0].src = url; $v_[0].play(); });

取得するのは映像のみのため、第一引数のaudioプロパティはfalseとしました。第二引数は取得成功時のコールバック関数で、カメラから取得した映像はインスタンスstreamに返されます。ここで、「マンガ化」の変換処理を行うためには、一旦streamをURLに変換し、videoノードにsrc属性として指定する必要があるため、 createObjectURL()を用いています。また、video ノードは、play()をコールしないと映像再生が開始しないため、このタイミングで呼んでいます。

HTML5 canvasのgetImageData() により、映像から画像データを取り出す。

マンガ化する画像変換処理を行うためには、映像から画像のピクセルデータを取得しなければなりません。このため一コマづつcanvasに画像として書きだし、getImageData()により、取得します。

var canvas = $("canvas")[0] , ctx_ = canvas.getContext('2d');

// canvasから画像のピクセルデータを取得する var imgData = ctx_.getImageData(0, 0, 640, 480)

画像データにフィルター処理を行い、マンガ化する。

取得した画像データに対してフィルター処理を行いマンガ化します。アルゴリズムは以下の通りです。

1. 画像を黒・スクリーントーン・白の3階調化する。

1. エッジ抽出を行い、階調画像に縁取りを行う。

（階調処理やエッジ抽出の具体やコードについては次回の記事で紹介します）

上記フィルター処理を行ったデータをcanvasに描画し、「マンガ化」された画像が表示されます。

// 「マンガ化」フィルター処理後のデータを、canvasに書き出す。 ctx_.putImageData(toon, 0, 0)

requestAnimationFrame() により、画像変換処理を繰り返す。

上記操作を16msec毎にループ処理することで、60fpsで「マンガ化」された映像が表示されます(パラパラ漫画の要領です)。このような処理を行う際、これまでだと

// doToon()は、映像の一コマを画像変換する関数 setInterval(doToon, 16);

と、setInterval()を用いるのが普通でした。しかしながら、このコードでは、doToon()の処理に16msec以上かかった場合、処理がスタックしていく問題が生じます。ここで、requestAnimationFrame() を用いると、doToon の処理時間に応じ、画像フィルター処理が繰り返し実行され、適切なフレームレートでマンガ化された映像が表示されます。

requestAnimationFrame(doToon)

WebSpeech API による音声認識

二番目に紹介するのは、音声認識機能です。認識した音声を吹き出しに自動表示したり、音声コマンドを使ったりするためにこの機能を利用しています。

音声認識を実現するために、Chrome で試験実装されている WebSpeech API を利用しました。ちなみに、このWebSpeech APIはW3Cで正式なドラフトも出ていない実験的なAPIです。音声認識が簡単にできてしまうなんて、ほんとブラウザの進化は留まるところを知りません。今後、本格的な仕様化や実装が進んでいくことでしょう。楽しみですね。

インスタンス生成後、start()メソッドをコールすると、音声認識が始まります。

var rec = new webkitSpeechRecognition();

rec.start(); // 音声認識を開始

音声が認識されると、’result’ イベントが発生します。認識結果は、SpeechRecognitionEventオブジェクトとして返されます。

rec.onresult = function(ev) { for(var i = ev.resultIndex, l = ev.results.length; i < l; i++) { if(ev.results[i].isFinal) { // 音声認識が完了した var res = ev.results[i][0].transcript; // 音声認識結果 } else { // 音声認識途中 var res = ev.results[i][0].transcript; // 音声認識中の途中結果 } } }

「マンガテレビ」では、認識結果の値をチェックし「バーン」や「ドーン」などの場合は、音声コマンドとして認識し、映像エフェクトを実施。それ以外の場合は、吹き出しに表示するといった処理を行っています。

なお、イベント中講演者が話し続けているようなケースだと、ずっと音声認識中となり、認識が完了しないケースが頻繁に発生します。これを避けるため

// 認識結果の文字列長が15文字を超えたら、認識を再起動する。 if(res.length > 15) { rec.stop(); rec.start(); }

のように、認識結果が15文字を超えた時点で音声認識を再起動する処理を入れています。

なお、再起動の際に、サイトのプロトコルスキーマがhttpsでない場合、毎回音声認識の許可を求めるダイアログが表示されてしまいます。注意してください。

headtrackr.js による顔検出

次に紹介するのは、顔検出機能です。音声を表示する吹き出しや、音声コマンドで集中線を出す際の位置を決めるために、この機能を利用しています。

JavaScript で顔検出を行うライブラリーとして face.js が有名ですが、検出スピードに難があるため、より高速に動作する headtrackr.js を用いました。

headtrackr.jsは、最初に顔検出を行うまでは低速ですが、一旦検出が完了すると、それ以降は検出した顔の周辺のみを検出対象とするため、face.jsに比べ格段に高速動作します。もちろんハードウェアに依存しますが、筆者の Mac Book Pro では、概ね30fps(frame per second : 1 秒辺りのフレーム数）が得られました。ただし、検出できる顔は一つのみとなりますので、その点は注意してください。

Tracker オブジェクトのインスタンスを生成した後、検出対象のビデオ要素と、検出処理に用いるcanvas要素を指定し、start()メソッドを呼ぶと顔検出処理が始まります。

var tracker = new headtrackr.Tracker({ui: false}); // uiをfalseにしないと、検出状態を示すテキストが表示される。 tracker.init($("video")[0], $("canvas")[0]); // 対象ビデオ要素と、検出処理用canvas要素を指定する。 tracker.start(); // 顔検出を開始する。

顔が検出されると、’facetrackingEvent’ イベントが発生します。認識結果は、コールバック関数にfacetrackingEventオブジェクトとして返されます。

document.addEventListener("facetrackingEvent", function(ev){ // ev.x, ev.y -> 顔の中心座標 // ev.width, ev.height -> 顔の幅と高さ }, false);

これら顔の検出位置情報から、吹き出しの表示位置を決めています。

WebSocket によるインタラクティブ機能

最後に紹介するのは、インタラクティブ機能です。イベント参加者が「かっこいいねボタン」を連打すると、それがWebSocketで「マンガテレビ」に送られ、連打の数に応じて「ざわ・・」とか「ゴ・・・」などの文字が横断するエフェクトが動きます。参加者も一体になって盛り上がれるインタラクティブ機能です。この連打の数を「マンガテレビ」に送るために、HTML5の双方向通信機能WebSocketを使いました。なお、『マンガテレビ」では、socket.ioを用いているため、WebSocket が利用できない環境では自動的にHTTPポーリングにフォールバックします。

「マンガテレビ」では、socket.ioを更にラップし、メッセージ受信をsubscriberモデルとしたZapper オブジェクト(白石さん謹製)を用いています。

Zapperオブジェクトのインスタンスを生成し、connect()メソッドでサーバーへ接続。その後、’zap’メッセージに subscribe()すると、「かっこいいねボタン」の連打データを受信することができるようになります。受信データのcountプロパティに連打回数が入っているため、その値に応じて「ゴ・・・」や「ざわ・・」といったエフェクトをかけています。

// 接続先サーバーを指定してインスタンスを生成 var zapper = new Zapper({ serverUrl: 'http://somewhere/' });

event.subscribe('zap', function(zap){ // zap.count に連打回数が格納されている }); });

次回はパフォーマンスチューニング

今回の記事では、筆者らが最新Web技術を駆使してイベント用に開発した「マンガテレビ」について、そのアーキテクチャを紹介しました。HTML5 の進化によりブラウザの世界観がさらに広がっていくことを感じて頂ければ幸いです。

さて、「マンガテレビ」では、本稿で紹介した各種機能以外に、もう一つ大切な点が。それは「高速動作する」ことです。映像のマンガ化処理に時間がかかると、「マンガテレビ」はカクカク動いてしまい、イベントが興冷めしてしまいますからね。次回は、「マンガ化処理」を高速に行うためのパフォーマンスチューニング・ポイントについて紹介します。

いよいよ本日、HTML5 Experts Night#1を開催します。なんと、このHTML5 Experts.jpでは、編集部が総力をあげてイベントの模様をこの記事で、生中継（ライブライティング？）しちゃいます！イベントの様子を写真付きで逐次アップしていきますので、乞うご期待！

HTML5 Experts Nightとは？

　HTML5 Experts Nightは、HTML5 Experts.jpが誇るWebエキスパートたちと飲めて、学べて、触れ合える、そんなパーティイベントです。日本で最高峰のエキスパートたちが集まった場で、Web技術の話題を肴に楽しめる、そんな場作りを目指しています。

イベントプログラム

さて、イベント開催時間が迫ってまいりました！ 今日のプログラムをお知らせしますね。皆様のご来場、お待ちしております！

20:00 受付開始です

22:00　Finish!!

イベント準備開始！

スタッフが会場入りし、準備が始まりました〜。今日の会場はリクルートさんのメディアテクノロジーラボ（MTL）です！

色々仕込んでいます！何が出るかは後ほどのお楽しみ〜。

エキスパートの方で一番乗りはダニエルさんでした。ようこそ！Experts Nightへ。

@wksさん 会場設営のご協力ありがとうございます！

どこかで見た事がある人も居るかもしれませんが、今日のイベントでもやります！漫画テレビ。 エキスパートで編集部の@komasshuさんが、スペシャルなチューニングを色々と施してます。会場にお越し頂ける方は、是非注目してみてください。

入場開始！!

お待たせしました、入場開始しました。今日はパーティーです！入場したらビールを片手にエキスパートの方々と目眩くWebの世界へ！今日のイベントはエキスパートの方々と一杯飲んでいっぱい語らってくださいね〜。

すでに会場の各所で真剣な（？）議論が始まっています。

白石編集長の乾杯ではじまりました！

乾杯に引き続き、イベントの趣旨の説明。HTML5 Experts.jpが考えるエキスパートの条件の説明や記事寄稿者の告知も！

HTML5 Experts.jpでは一般の方の寄稿も募集する事となりました。我こそは！というかたは編集部までご連絡ください。

エキスパート増井さんとの対談

HTML5 Experts.jp公開以来もっと読まれた記事の著者、エキスパートNo.43の増井さんとの対談です。

編集部の大津谷（写真左）が聞き手となり、色々な話を聞いていきます。

Pukiwiki開発の話から始まり、アメリカへわたった時の話など、楽しい対談が続きました。詳しい内容は後日、レポート記事として起こすとして、いくつかキーワードを。

• 風呂といったら増井さん（お風呂で開発するプログラマー）
• 母国語はRuby？
• 英語はなせなくてもアメリカで仕事できます！
• なぜAppleやGoogleに行かないの？＝＞ ふつうに働くだけじゃつまらないよ！

会場からの質問も受け付け、参加者全員で盛り上がりました！本当に風呂で仕事しているの？など、面白い質問も沢山。

増井さん、本日はありがとうございました。次の記事もお待ちしています！

歓談タイムその２！

増井さんの対談が終わり会場は再び歓談タイム。ここで、開発者のためのChromeガイドブックのサイン入り本のプレゼント抽選会を開催。

エキスパートの吉川さんと小松さんのサインが入っていますね〜。

エキスパートのえーじさんもサインに応じてくださいました。サインの列ができますね！すごい。

当選された方、おめでとうございます！！

HTML5 Experts.jpロゴコンテストの公開コードレビュー

そうしているうちに、目玉企画の一つ、ロゴコンテストの公開コードレビューがはじまりました。エキスパートの小山田さんをゲスト解説にお迎えし、同じくエキスパートの小松さんと一緒に投稿頂いた作品一つ一つをレビューしていきます。

ロゴコンテストに応募された作品はこちらのページでご覧頂けます。
レビューの概要をざくっと記載すると・・・（すみません、一部更新が追いつきませんでしたので、後日レポートします）

1作品目 http://jsdo.it/platism/xkQYH
小山田さん「CSSアニメーション。border-raduisを使って、丸が四角にアニメーションしている。」

2作品目 http://jsdo.it/mermaid1112/logocontest-robot
小山田さん「これもCSSアニメーション。小さいdivをたくさんうまく使っている。」
小松さん「canvasは使ってないんですね。こういうのもCSSアニメーションでできるんですね。」

3作品目 http://jsdo.it/shirayuki/1NEK
小松さん「ちょうちょがひらひらするのはどうやってるんですか。」
小山田さん「そこまで見てなかったんですが。」
小山田さん「(コードを見て)CSSアニメーションのskewをつかってるんですね。」

4作品目 http://jsdo.it/kingpanda/enUm
小松さん「日本の日の出みたいな感じですね。」
小山田さん「これもCSSアニメーションですね。」

5作品目 http://jsdo.it/sapphire_al2o3/u4ed
小山田さん「これはWebGLを使っています。three.jsを使うことが多いですが、これはWebGLのコードを直に書いています。」
小松さん「僕も、three.jsを使わないと書けないです。」
小山田さん「お手本的なきれいなコードですね。」

6作品目 http://jsdo.it/cx20/9lUe
小山田さん「手前のアニメーションはサンプルコードをのままです。」
小山田さん「その背景でWebGLを動かしているんですね。」
小山田さん「ぜひコードを見てみたいと思います。」
(会場からどよめきが。ソースコードにテキストアートのようにロゴが書かれている。)
小山田さん「これを読み込んでアニメーションさせてるんですね。」

7作品目 http://jsdo.it/Xpressive_Team/p1Mj
小山田さん「これも小さい div をたくさん使っています。」

8作品目 http://jsdo.it/xicolo/peA7
(更新がついていけませんでした。ごめんなさ・・・)

ロゴコンテストは面白法人カヤックさんのjsdo.itを利用して行われました。Webブラウザ上で開発しそのままプレビューすることができます。便利ですね〜。

ロゴコンテストはエキスパートの方に審査して頂いていますので、後日審査結果を発表する予定です。乞うご期待！

LTタイム

どんどん、進んでいきます！LTタイムに突入しました。計６つのLTを一人５分のペースで発表していきます。　　

一人目は株式会社ニューフォリアから羽田野さんです。

ニューフォリアさんで最近サービス開始した、アプリ開発支援サービス「アプリカン」の紹介です。 名前の由来はアプリの缶だそうです。好きなエディタでコードを書き、HTML, JavaScript, CSSをZIPしてサイトにアップロードすると、iOSアプリとAndroidアプリをビルドしてくれます。アプリの実行が出来るだけでなく、デバッグツールも付いていて、AppStoreに申請しなくても、アプリのコンテンツを入れ替えることができます。

日本発のアプリ開発支援サービスアプリカンをよろしくお願いします。

二人目は@ogaogaさんです。

@ogaogaさんは株式会社楽天に勤められており、楽天のHTML5の取り組みを発表されました。　 モバイル、koboなどはHTML5で作っていたりと、楽天もHTML5の取り組みを色々と進めているようです。

10月には楽天テクノロジーカンファレンスを開催するそうです。興味がある方は是非！

三人目は金井さん（写真左）と中島さん（写真右）が登場。金井さんはAngular.jsや味見部などの管理人をやっている方で、中島さんはDMMでフロントエンドエンジニアをやられているそうです。

今日は、HTML5Experts.jpを盛り上げるアイデアを持ってきてくれました！その名も、エキスパートスタンプラリー！

まだ、開発中との事ですが、会場ではデモが行われました。今後に期待ですね！！

最後に、金井さんから、「HTML5 Experts.jp関係者の皆さま、買い取りの相談を待っています！」とのコメントが！

次は、白石編集長が登場。ハッカ盆というイベントで開発した、Leap Motion、Node.js、Arduinoを組み合わせたデモを披露。

「指を1本」でLEDが1つ点く、「指が2本、3本、4本、5本」でLEDが1つずつ点灯してくというもの。スワイプ、円を描くジェスチャーにも対応しています。

Node.jsからArduinoを制御できるライブラリを見つけたとの事で、今後も面白いモノを作っていきたいと意気込みを語りました。

最後に再び小山田さんの登場です。Canvas ブレンドモードについてお話しされました。

ピクセルの中にある4つの値を加算したり乗算したりできるが、canvasでは動作が重い、WebGLでGPU支援を利用するとかなり高速になる等、実践的な内容でした。

おわりに

これでイベントの全企画が終了しました！ライブライティングは如何でしたでしょうか？初めての試みでしたが、お楽しみ頂けましたでしょうか。
HTML5 Experts Nightは１０月も開催予定ですので、是非チェックしてみてください。

このレポートに内容を加筆したモノをこちらで公開しています。合わせてご覧ください！
CodeIQ Blog 増井雄一郎さんが人気記事を解説！HTML5/Webエキスパートたちに学んでつながる「HTML5 Experts Night」

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で冷気を表現したサイトがすごいな」を分解してみた！