[&] From High-DPI to multi-touch: cutting edge mobile web

Chrome Tech Talk
--------------------
モバイルアプリの最新動向 - High DPI とマルチタッチ
（ From High-DPI to multi-touch: cutting edge mobile web ）
（講演者:Boris Smus）

プレゼン資料
http://smustalks.appspot.com/japan-12/#1

みなさんこんにちは Boris といいます Mt.View で仕事をしています。

モバイルweb開発がいかに増えてきているか？
モバイルで使っているユーザーが増えてきています。
ごらんのように2014年くらいに、Mobileユーザーがデスクトップユーザーを
追い越すことが予想されています。
モバイルというのはどういうことでしょうか？
デスクトップではありませんね？
モバイルWEbのバリエーション
スクリーン密度
フォームファクター
インプットのタイプ
いろいろ問題になりますが、後で触れます。

●スクリーン密度、Density のバランスの話から。

初期のPCは、解像度が非常に低いものでした。
現在のPCでは増えています。
多くのピクセルを使って表現できます。
なので、固有のピクセルを指定してしまうと、画面上では小さくなってしまいます。
CSS pixelsで定義します。
Density には関係なく、利用できます。

拡大ができるものとしては、テキストや SVG, CSS は簡単に拡大できます。
ビットマップ画像に関してはできません。
ボタンとか Gradients など、UI部品に関してはイメージを使うのを避けるのが良いです。
とはいってもフォトギャラリーのように使わざるを得ない時もあります。
できるだけ効率よく、ハイクオリティーな画像でサービスをすることが必要です。

アプローチとしては二つの方法があります。
一つの画像を最適化します。
一連の画像のセットから、最適なものを選んで使う方法があります。

したがって、
クオリティの高いイメージを選ぶと大きさが大きくなってしまう。
２倍から４倍くらい大きくなってしまいます。
それに対して、WebP は 30% くらいさらに圧縮して小さくできます。
必ずしも全てのブラウザがサポートしているわけではないので、
うまく使えないときもあります。

したがって、そういったものに対するソリューションとして、
クオリティーを犠牲にして利用するのは、
1x quality 90, 2x 30%
ピクセルサイズではなく、画像のクオリティを下げて使う。

イメージのアーティファクトが出てしまう。
可能な限り、マニュアルでスケーリングした方が良い。
自動でするよりも。
複数のイメージのアプローチにする。マニュアルでスケーリングして
一番いいものを選ぶのが良い。
JavaScript で利用できます。
多くのスクリプトで利用できます。

しかし、loolahead のパーサーを使うとうまくいきません。
Server-side で対応する方法もあります。
唯一判別できるのはユーザーエージェントの文字列しかありません。
ですから、クライアント側で JavaScript を使わない方法としては、
Media Queries を使う方法です。
デフォルトでクオリティの低い画像がロードされるようになっています。
スクリーンとして高画質に対応できるものに対しては、高画質のものを使います。
スピードが遅い接続状態で、高画質のものをロードするのは困ります。
ですから、そういった場合に、ブラウザの image-set を使います。
ブラウザが最適化されていれば、ネットのスピードに対応します。
これはまだ Chrome と Safari でのみ現在利用可能です。

このように、スクリーンイメージでは、BackGround のイメージの話をしましたが、
コンテンツのイメージに関しては？
CSS4 の srcset はまだ実装されていません。
image-set で代用して試します。

まとめ。
適切な fallback で、image-set を使う。
クオリティが良く無いイメージでも我慢できるのであれば、圧縮画像を使う。

●From Factor variations
モバイル開発をする場合、こんな風景と相対さないといけません。（端末がいろんなものがある）
どう対応するのか？

例１
一つのバージョンを作って、それでえいやっと全部に対応してしまう。
サイズが小さすぎるとか、全然機能しないとかが生じる。

例２
別の方法としては、個別対応があります。
しかし非常に無数に数があるので、そんなんこともできません。

中庸：
二つの極端な例の間をとります。
いろんな異なるフォームファクターがあり、スマートフォン、タブレットサイズ。
しかしそれ以外で、プラットフォームの違いがありますが、
フォームファクターの違いの方がおおきいです。

一つのアプローチとしては、
レスポンシブデザインを使うということです。
CSSをロードし、ページの幅に依存して調整します。
あるいは、Developer Tools を利用して、ページを小さくしてためしてみることができます。

Media query Limitations
場合によってはメディアクエリでは十分ではありません。
あるフォームファクター特定の機能をロードする必要があります。
JavaScript でこれが実現できます。
任意のメディアクエリを評価することもできます、
あるいは変化に対して、注意深く問い合わせることもできます。

Multiple Version
別のアプローチとしては、タブレット用、スマホ用と切り分ける方法もあります。
タッチサポートを確認するために Modernizr.touch を使います。

スマートフォンとタブレットの特性を十分に分けておく必要があります。
いろいろな解像度があります。
縦横画面モードがあります。それを加えると複雑になります。
したがって650ピクセルでラインをひくと...........

ドキュメトの一番頭で、そのセマンティックを記述します。
github.com/borismus/devices.js
自動的にロードします。
自分が宣言したものを見て、その中でどれかを選びます。

サーバー側での対応；
deviceatlas.com
wurfl.souceforge.net
ユーザーエージェント文字列を使う例もあります。
デスクトップ上でこれらのエージェントを Chrome Developer TOols ではシミュレーションして使えます。

●Input variation
最後のセクションは、インプットのバリエーションです。
マウスとかキーボードとかが一般的な方法です。
これがスマートフォンになっても、キーボードがついているものがありますが、
タッチが登場して、大きく入力の方法が変わりました。

覚えておくべき大切なことは、
タッチはマウスとは全然違います。
そもそも、hover state は無いし、マルチタッチもないし、
入力そのものが精度が無く、荒いものです。





タップ、ダブルタップ、ジェスチャなど。

Touch events
タッチイベントの仕様
events: touchstart, touchmove, touchend , touchenter, touchleave
properties, touches, targetTouches など。

Chrome 上でタッチイベントをエミュレーションすることもできます。
lab.hakim.se/scroll-effects/mobiel.html
タッチそうさをべミュレーションするというところにチェックすると、
タッチデバイスと同じようにスクロールできます。

スクロールが邪魔なので、スクロールしたくない時もあります。
ほとんどのブラウザでは、touchmove しないようにしてます、
IEの時はちょっとやり方が違って CSS で対応しています。
ブラウザ固有のジェスチャなので、ものによっては上書きできないものもあります。
ピンチ、スーミングが出来ないものもあります。
そういったニーズが無い、適切な使い方を。

Touch performance
モバイルWEbでタッチはクリックにくらべて、遅れます。
マウスイベントに比べて、300ミリ秒の遅れがあります。

More on touch performance
同時に多くの指がある場合、そういう場合は
タッチのパフォーマンス問題にぶつかります。
したがって、入力と描写の描く作業を分ける必要があります。
アニメーションフレームをリクエストする方法があります。
何時レンダリングするのかをブラウザ側で決めます。
ここで問題があります。
だいたい、マウスもタッチも両方サポートしたい場合があります。
そうすると、両対応の必要があります。

ジェスチャーは実装しにくいものです。
ピンチズームの例としては....
あまりにも長過ぎます。

ポインタイベントを使うという方法です。
マイクロソフトからのアイデアです。
最近これが規格になっています。
大部分のブラウザでは使えませんが、ライブラリがあります。
github.com/borismus/pointer.js
すべてのマウスイベントがポインタイベントに変換されます。


many JS Gesture Library いろいろライブラリがあります。
リロース的にはポインタの上にジェスチャを実装したいのですが、
なかなかそうもいきません。

https://github.com/borismus
http://smustalks.appspot.com/japan-12/#1
@borismus