Progressive Web Apps Roadshow Tokyo 2017 〜すべてはユーザー体験の向上のため〜

最近 PWA が盛り上がってきているので、以前参加したイベントのメモを共有しておきます。
https://events.withgoogle.com/pwa-roadshow-tokyo-2017/

ちなみに全部メモとってたんですが途中で全部消えてしまった(涙) (lighthouse という PWA 判定ツールを入れて実行した時に メモ取ってた web サイトのlocalStorage がぶっ飛んだ。みなさん、　　lighthouse で計測する際はご注意を（笑）)

当日の togetter まとめ
https://togetter.com/li/1153523

当日の発表資料一覧
https://drive.google.com/drive/u/0/mobile/folders/0B55wxScz_BJtV1lGbTBOYlhLTVk

## キーノート
[Progressive Web Apps 資料](https://docs.google.com/presentation/d/1MyLqhAesKd9GKzKz5BN6Uj3en9HQeIoQ2x2_dguvvXM/edit#slide=id.g26127fb814_2_79)

- 80% の人はホームスクリーンでアイコンを動かしている
- 78% の人はTOP3 のアプリ以外ほとんど使わない
- だいたい必要なアプリのインストールが終わるとユーザーは１ヶ月に一度もアプリを入れない
- 53% の人は 3秒以上の読み込みで諦めてしまう。

これから大事なのは、アプリやウェブという枠組みだけでなく、「ユーザー体験」.

**FIRE**を定義.

- **Fast（速さ）**
 - とにかくスピードが大事、回線が遅くても早く表示したり、キャッシュを使う
- **Integrated（変わらない体験）**
 - WEBやアプリなどの環境を超えて同じ操作感や、アクセスのしやすさを整える。
- **Reliable（信頼）**
 - ネットワークに繋がっていないとアプリが見れないとか、そういうのをなくし、ユーザーを裏切らない
- **Engaging （ユーザーを惹きつける魅力）**
 - ユーザーが興味のある情報を適宜提供するべき。Push通知は タイムリーでわかりやすくパーソナルに行う。

上記の FIRE を満たすために、PWA にしていく必要がある。 ServiceWorker（PUSH や キャッシュ）を利用したり、PaymentAPI  などを利用し、より良いユーザー体験を提供する。
twitter モバイルは PWA のすごく良い例なので、ぜひ参考にしてほしい。

## Integrated Experiences
[Integrated Experiences](https://docs.google.com/presentation/d/1TJSaBfxiwm2pIsyQpd9PSbCuwqeKyqbKx4YGQFZRTfU/edit#slide=id.g253b2f824e_1_79)
アプリやウェブといった環境を超えて、同じようなユーザー体験を生み出すには？

- 80%のユーザが意図的にホーム画面上で並び替えている
- ユーザにとって、ホーム画面上の何処にあるかはとても重要
->Add to Home Screen でホーム画面に表示するようにできる. いいえを押すと 90 日は出てこない.無視は 14 日後
- Payment Request API で、決済のUIを標準化する
- クレジットカードや住所をブラウザに登録しておけば、ワンクリックで決済可能
- Payment Request API はオープンスタンダードでUIのみ。決済機能は別。
- autocomplete  属性をうまく利用して、ユーザーの入力を最小化する
 
## Reliable Experiences
[Reliable Experiences
](https://docs.google.com/presentation/d/1ZAQuIW3BCT1VvVPP-FyutKSc3tTjtno7q5dSvKqXytQ/edit#slide=id.g1ff06aa0e6_2_79)
ネットワーク接続に依存しないアプリを作り、ユーザーの信頼を失わせない。

- Lie-fi という繋がらない wifi とかでユーザー体験が損なわれる
- 世界の 60% は 2G 接続。新興国とか。
- Service Worker は２回目の読み込み時に機能し、キャッシュがあればそれを使う
- ちなみに、キャッシュは 最初にキャッシュを呼び出しつつ API から呼び出した結果を更新する方法がオススメらしい。実装によってそれらを使い分けれる。
- ServiceWoker を開発するときは、ClearStorage を頻繁に行わないとバグる。
- workbox.js というのを使うと、デプロイ時などの service worker のキャッシュコントロールを行ってくれる（？）


## Engaging Experiences
[Engaging Experiences](https://docs.google.com/presentation/d/1Tff_-bFhW_nhMewWVgZa6lT77CMuIaLIatz3YoR2260/edit#slide=id.g26123bc6f4_1_79)
ユーザーにとって魅力的なサービスを提供する

- 自分に関係ない push 通知が来るとユーザーはアプリをアンインストールする。
- 良い通知とは？ **タイムリーで、わかりやすく、パーソナルである。**
- 急に出てくる push 通知の許可は 43 % しか ok しない。
- そして、その通知はいいえを押すと二度と出てこなくなる
- なので、設定画面を用意してユーザーに選択させるべき
- service worker を使えば、そういった設定が可能

## HTTPS
[HTTPS](https://docs.google.com/presentation/d/1o9GiCqU-U2rfgO5FYBSd1HXNyqm3UAZLVAQxLjn3WiU/edit#slide=id.g261259c8c9_2_216)

- man in the middle attack を防ぐ
- httpsにする事で得られるもの
  - identity同一性
  - Confidentiality機密性
  - Integtity 改ざんされたものがユーザに届くことが無い
- そもそもServiceWoker は https じゃないと動かない
- Let’s Encrypt letsencrypt.org で 証明書のコストを抑えられる。６ヶ月に一度更新が必要。crontab でやろう。
- https にすると通信料が多くなるので若干スピードが遅くなる。しかし http2 に対応すれば結果的に早くなる事例もある

## AMP
- 0.1s feels instant, 1s feels natural, 10s ... lost user's attention
- とにかく早くコンテンツを表示する仕組み
- `<html ⚡>` で宣言 ⚡ が速い感じを出してる。
- AMPは以下の3つで構成
・AMP HTML
・AMP JS
・AMP Cache
- ampで記述されたコンテンツは各所に配置された edge server より配信されるためものすごく高速
- ServiceWorker と組み合わせると、オフラインで表示したりもできる。（この辺難しかった・・）

## 所感
FIRE を満たすために、PWA の ServiceWorker（PUSH や キャッシュ） や、AMP（とても速くコンテンツを提供できる仕組み） と言った機能を今後取り入れていくべき。twitter lite がかなりもてはやされている感じだったので、design とかも含めて、twitter lite の考え方は積極的に使って行ったほうがよさそうな気がしてる。
そして、なんども強調して言われていたのは、「**すべてはユーザー体験の向上のため**」であって、むやみに PUSH の通知を送ったり、 WEB の新しい技術に飛びついてユーザーの体験を損なうことをしないように。 ということでした。エンジニアとしては新しい技術に飛びつきたいところですがぐっと我慢して、ユーザー体験をよくする取り組みを優先的に取り組まなければと反省した次第です。


## その他
pwa を利用しているサイト一覧 https://pwa.rocks/