「Chromeでホーム画面に追加が出なくなった」
PWAについて調べていたところ、こんな内容の質問を見つけました。
他のサイトでは「ホーム画面に追加」が出るのに、普段見ているサイトでは表示されなくなった。 代わりに「○○を起動」のような表示になってしまう。 このページをChromeのままホーム画面に追加したい。
サイト名は伏せますが、かなり興味深い質問です。
質問している本人は、PWAについて困っているわけではありません。
ただ単純に、
「今見ているページをホーム画面に追加したいのに、ホーム画面に追加がなくなった」
と困っています。
ところが、そのサイトのmanifest.jsonを確認してみると、原因らしきものがかなりはっきり見えました。
manifest.jsonを見るとサイト全体が1つのPWAになっていた
実際のサイト名やURLは伏せますが、manifest.jsonの構造はだいたい次のようなものでした。
{
"name": "Example",
"short_name": "Example",
"start_url": "https://example.com/",
"scope": "https://example.com/",
"display": "standalone",
"icons": [
...
]
}注目したいのは start_url と scope です。
"start_url": "https://example.com/",
"scope": "https://example.com/"起動先はサイトトップ。
scopeもサイト全体です。
つまり、このサイトは
「example.com全体を1つのWebアプリとして扱う」
という設計になっています。
これは私がPWA LABで整理している設計思想でいうと、1S1A（One Site. One App.）です。
1S1Aとは「1サイト＝1アプリ」の設計
一般的なPWAの多くは、この1S1Aです。
例えば、
example.com/
├── article/a
├── article/b
├── product/a
└── product/bというサイトがあったとしても、アプリとしては
example.com = 1つのPWAとして扱います。
記事Aも商品Aも別々のアプリではありません。
全部まとめて「Example」という1つのアプリです。
Webサービスそのものをアプリ化したいなら、これは非常に自然な設計です。
問題は、ユーザーがサイトではなく特定のページをホーム画面に置きたい場合です。
ユーザーは「サイトをインストールしたい」とは言っていない
今回見つけた質問で一番重要なのはここだと思います。
質問者は、
「このWebサービスをPWAとしてインストールしたい」
とは言っていません。
やりたいのは、
「今見ているこのページをホーム画面に追加したい」
です。
しかしサイト側は1S1Aとして設計されています。
サイト運営者は、
このサイト全体
↓
1つのアプリとして提供しています。
一方、ユーザーが求めているのは、
今見ているページ
↓
ホーム画面に置きたいです。
ここで、サイト運営者とユーザーの意図がズレています。
「ホーム画面に追加」がなくなったように見える
PWAとして認識されるサイトでは、Chromeのホーム画面関連の表示が通常のWebページとは異なる場合があります。
さらに、そのPWAがすでにインストールされていれば、ブラウザ側からすれば新しく同じアプリを追加する必要はありません。
その結果、ユーザーから見ると、
以前：ホーム画面に追加
現在：アプリを開くのような変化が起こります。
ブラウザ側としては正常です。
「このサイトにはすでにアプリがありますよ」という判断です。
でもユーザーからすると、
「いや、そのアプリを開きたいんじゃなくて、このページをホーム画面に置きたいんだけど？」
となります。
これが「ホーム画面に追加できない」という悩みになるわけです。
原因はブラウザではなくサイト側のPWA設計かもしれない
ここがかなり重要です。
「ホーム画面に追加できない」と聞くと、普通は次のような原因を疑います。
- Chromeの仕様変更
- ブラウザの設定
- Androidの設定
- manifest.jsonのエラー
- キャッシュ
- PWAのインストール条件
もちろん、これらが原因の場合もあります。
しかし今回のケースでは、PWAが壊れているわけではありません。
むしろ逆です。
PWAとして正常に動いているからこそ、ユーザーがやりたいホーム画面追加と衝突している可能性があります。
これはかなり面白い問題です。
PWA対応したことでホーム画面追加が便利になるはずなのに、設計によってはユーザーから「ホーム画面に追加できなくなった」と見えてしまうわけです。
1S1Aが悪いわけではない
ここは誤解しないようにしておきたいところです。
1S1Aそのものが悪いわけではありません。
サイト全体を1つのWebアプリとして提供したいなら、1S1Aは正しい設計です。
例えば、
- SNS
- 管理画面
- Webメール
- 業務ツール
- サイト全体で動くWebアプリ
などは、1サイトを1アプリとして扱う方が自然です。
問題なのは、
ユーザーがページ単位でホーム画面へ残したくなるサイトまで、すべて1S1Aとして設計してしまうことです。
例えば、
- 商品ページ
- ブログ記事
- レシピ
- 予約ページ
- ユーザープロフィール
- イベントページ
こうしたページは、「サイトそのもの」より「このページ」を残したいケースがあります。
そこに1S1Aしか用意されていないと、今回のようなズレが発生します。
1P1Aなら「このページ」をホーム画面にできる
そこで考えられるのが、1P1A（One Page. One App.）です。
1S1Aが、
1 Site = 1 Appなのに対して、1P1Aは、
1 Page = 1 Appとして考えます。
例えば、
/product/apple
/product/orange
/product/bananaという3つの商品ページがあるなら、それぞれを独立したホーム画面の入口として扱います。
ユーザーがAppleの商品ページを見ながら追加したならAppleへ戻る。
Orangeの商品ページを追加したならOrangeへ戻る。
サイトトップへ強制的に戻す必要はありません。
start_urlをトップ固定にしない
1P1Aでは、例えばmanifestを次のようにできます。
{
"name": "Apple",
"short_name": "Apple",
"start_url": ".",
"display": "standalone"
}ポイントは、
"start_url": "."です。
サイトトップを固定で指定するのではなく、現在のページを起点として扱います。
これなら、
- 記事から追加 → その記事
- 商品から追加 → その商品
- プロフィールから追加 → そのプロフィール
というホーム画面体験を作れます。
ただしAndroidで複数のページをそれぞれ独立したPWAとして扱う場合は、start_url だけでなく id や scope の設計にも注意が必要です。
ここをサイト全体で共通にしてしまうと、結局同じアプリとして扱われる可能性があります。
1S1Aと1P1Aは「誰がアプリを決めるか」の違いでもある
今回の質問を見ていて、もう一つ面白い違いに気付きました。
1S1Aでは、基本的にサイト運営者が、
「このサイトを1つのアプリとして使ってください」
とアプリの単位を決めます。
一方で1P1Aでは、ユーザーが、
「私はこのページをホーム画面に置きたい」
と選べます。
つまりこれは単なるmanifest.jsonの書き方の違いだけではありません。
ホーム画面の主導権を誰が持つか、というUXの違いでもあります。
「ホーム画面に追加できない」はPWAが原因の場合もある
今回見つけた質問は、かなり象徴的でした。
ユーザーはPWAについて質問していません。
manifest.jsonについても質問していません。
1S1Aなんて言葉も当然出てきません。
ただ、
「ホーム画面に追加がなくなった。私はこのページを追加したい」
と困っています。
しかし、その裏側のmanifest.jsonを見ると、サイト全体を1つのアプリとして扱う設計になっていました。
つまり「ホーム画面に追加できない」という問題の一部は、ブラウザの不具合ではなく、サイト側が採用したPWAの設計思想によって生まれている可能性があります。
まとめ
PWA対応すれば、ホーム画面追加が便利になる。
基本的にはその通りです。
でも、サイト全体を1つのアプリにする1S1Aでは、ユーザーが特定のページをホーム画面へ残したい場合に意図が衝突することがあります。
サイト運営者は「このサイトをアプリにしたい」。
ユーザーは「このページをホーム画面に置きたい」。
どちらも間違っていません。
ただ、目的が違います。
だからPWAを設計するときは、単に「PWA対応するか」だけではなく、
何を1つのアプリとして扱うのか
まで考える必要があります。
サイト全体を使ってほしいなら1S1A。
ページそのものに意味があり、それぞれをホーム画面へ残せるようにしたいなら1P1A。
今回の「ホーム画面に追加が消えた」という一見するとChromeの問題に見える質問は、実はこの2つの設計思想の違いがユーザー側に表面化した、とても分かりやすい例でした。
