従来のPWAが抱えた問題と、「1P1A」という新しい設計思想

従来のPWAが抱える「サイト単位」の設計を見直し、1ページを1つのアプリとして扱う「1P1A(One Page. One App.)」という新しい設計思想を解説。ブックマークの手軽さとPWAの快適さを両立する、ページ単位のホーム画面体験を紹介します。

目次

PWA(Progressive Web Apps)は、Webサイトをホーム画面へ追加し、アプリのように起動できる技術です。

ブラウザからアクセスしていたWebサイトがホーム画面にアイコンとして残り、そこから直接起動できる。

これは非常に便利な仕組みです。

しかし、従来のPWAには一つ、大きな前提がありました。

「1つのサイトを、1つのアプリとして扱う」

という考え方です。

私はこの設計を、

1S1A(One Site. One App.)

と呼んでいます。

そして現在、OJappではこれとは別に、

1P1A(One Page. One App.)

という設計を採用しています。

これは、

1ページを1つのアプリとして扱う

という考え方です。

この記事では、なぜPWAをページ単位で考えるようになったのか。

従来のPWAが抱えていた問題から考えてみます。

従来のPWAは「サイト」をアプリにしていた

一般的なPWAでは、Web App Manifestにアプリの情報を記述します。

たとえば次のような構成です。

JSON
{
  "name": "Example",
  "id": "/",
  "start_url": "/",
  "scope": "/",
  "display": "standalone"
}

サイト全体を一つのアプリとして定義し、ホーム画面から起動するとサイトの入口から始まる。

これは自然な設計です。

Webサイトを、

Text
Webサイト
    ↓
Webアプリ

へ変換すると考えれば、

Text
1 Site
↓
1 App

になるからです。

これが1S1Aです。

しかし、ユーザーが残したいのは本当に「サイト」なのか

ここで少し視点を変えてみます。

ユーザーがWebを使っていて、

「これ、あとでも使いたい」

「これ、ホーム画面に置いておきたい」

と思う瞬間はどんな時でしょうか。

必ずしもサイトそのものとは限りません。

たとえばECサイトなら、

Text
この商品

かもしれません。

ブログなら、

Text
この記事

かもしれません。

Webツールなら、

Text
このツール

かもしれません。

予約サービスなら、

Text
いつも使う予約ページ

かもしれません。

つまりユーザーが残したい対象は、

「Webサイト」ではなく「今見ているページ」

であることがあります。

ブックマークは昔からページ単位だった

これは新しい行動ではありません。

Webブラウザのブックマークは、昔からページ単位です。

たとえば、

Text
https://example.com/tools/calculator/

をブックマークしたら、次回もそのURLを直接開きます。

サイトトップへ戻されることはありません。

ユーザーが保存したものと、次に開くものが一致しています。

Text
保存したページ
↓
そのページを開く

非常に単純です。

ところがPWAになると、考え方が少し変わりました。

PWAでは長い間、

Text
サイト
↓
アプリ

という設計が中心でした。

ここに、Web本来の「ページ」という単位とのズレがあります。

1S1Aでは複数のページを独立したアプリとして扱えない

もちろん、従来型のPWAでも start_url に個別ページを指定することはできます。

そのため、

「PWAでは個別ページを直接開けない」

という話ではありません。

問題はそこではありません。

1つのサイトを1つのアプリとして識別する設計では、

Text
商品A
商品B
商品C

を、

Text
アプリA
アプリB
アプリC

として、それぞれ独立してホーム画面に残すことを前提としていないため、できません。

サイトそのものが1アプリだからです。

他のページをホーム画面に残そうとした場合、アプリを開くという表記になってしまいます。

これはサイトをサービスとして使う場合には合理的です。

しかし、Webにはもっと細かい単位があります。

それが「ページ」です。

そこで「1P1A」という考え方

1P1A(One Page. One App.)では、考え方を逆転させます。

Text
サイト → アプリ

ではなく、

Text
ページ → アプリ

です。

たとえば、

Text
https://example.com/product/a/
https://example.com/product/b/
https://example.com/product/c/

というページがあれば、

Text
product/a → App A
product/b → App B
product/c → App C

として扱います。

それぞれが、

を持ちます。

ユーザーが残したいと思ったページそのものが、ホーム画面のアプリになります。

ブックマークの手軽さと、PWAの快適さ

この設計を考えるうえで、一番分かりやすいのがブックマークとの比較です。

従来のブックマークには、

目的のページへ直接アクセスできる

という大きなメリットがあります。

しかし、開くのはブラウザです。

アドレスバーやタブなど、ブラウザのUIも表示されます。

一方、PWAでは display: standalone を使うことで、ブラウザUIを抑えたアプリらしい画面で起動できます。

つまり、

Text
ブックマーク

ページへ直接アクセス
○

スタンドアロン表示
×

に対して、

1P1Aでは、

Text
1P1A

ページへ直接アクセス
○

スタンドアロン表示
○

という形を作れます。

言い換えるなら、

ブックマークの「ページを直接残せる」という性質と、PWAの「アプリとして起動できる」という性質を組み合わせたもの

が1P1Aです。

では、サイト全体をアプリにしたい場合はどうするのか

ここで一つ疑問が出ます。

「サイト全体を1つのアプリとして使いたい場合は?」

もちろん、それも必要です。

しかし1P1Aという考え方に立つと、特別な仕組みを用意する必要はありません。

トップページも一つのページだからです。

Text
https://example.com/

このページを1P1Aとしてホーム画面へ追加すれば、

Text
トップページ
↓
ホーム画面アイコン
↓
トップページから起動

となります。

結果として、従来の1S1Aに近い役割を果たします。

1S1Aは1P1Aの特殊ケースとして考えられる

ここまで考えると、1S1Aと1P1Aを完全に別々の概念として扱う必要があるのか、という疑問が出てきます。

1P1Aでは、

Text
/page-a/ → App A
/page-b/ → App B
/page-c/ → App C

です。

そしてトップページも、

Text
/ → App

にできます。

つまり、

Text
1P1A
├─ /
├─ /page-a/
├─ /page-b/
└─ /page-c/

という構造の中で、

/ だけをアプリとして使えば、サイト単位のPWAに近い使い方になります。

そう考えると1S1Aは、

1P1Aの中で「トップページをアプリとして選択した状態」

として捉えることもできます。

実装上の違いも実は小さい

OJappでは、この違いがかなり分かりやすくコードに現れています。

1S1Aでは、アプリのURLをサイトトップに固定します。

JavaScript
const appUrl =
  window.location.origin + "/";

そして、

JavaScript
id: appUrl,
start_url: appUrl,
scope: appUrl

とします。

一方1P1Aでは、

JavaScript
const cleanUrl =
  window.location.origin +
  window.location.pathname;

として、現在のページを基準にします。

そして、

JavaScript
id: cleanUrl,
start_url: cleanUrl,
scope: cleanUrl

とします。

つまり根本的な違いは、

Text
1S1A

origin + "/"

なのか、

Text
1P1A

origin + pathname

なのかです。

たったこれだけの違いですが、「何をアプリとして扱うか」という設計は大きく変わります。

Webはもともとページの集合体

Webサイトは、一枚の巨大なコンテンツではありません。

Text
トップページ
記事
商品
プロフィール
予約ページ
Webツール
お問い合わせ

さまざまな意味を持ったページの集合体です。

URLもそれぞれに存在します。

それなのに、ホーム画面へ追加する瞬間だけ、

Text
全部まとめて1つのアプリ

として扱う必要があるのでしょうか。

ユーザーが商品を残したければ、その商品を残す。

記事を残したければ、その記事を残す。

ツールを残したければ、そのツールを残す。

トップページを残したければ、トップページを残す。

その方が、Webがもともと持っているURLという仕組みにも自然です。

「サイトをインストールする」から「ページを残す」へ

従来のPWAでは、

Webサイトをインストールする

という考え方が中心でした。

1P1Aでは少し違います。

今見ているWebページをホーム画面に残す。

その結果として、そのページがアプリのように起動します。

この違いは小さく見えますが、ユーザー体験としてはかなり大きな違いがあります。

インストールする対象をサービス提供者が決めるのではなく、

ユーザーが「残したい」と思ったものが、そのままホーム画面に残るからです。

まとめ

PWAそのものに問題があったわけではありません。

Web App Manifestにも、display: standalone にも、大きな可能性があります。

問題は、

「PWAはサイト単位で作るもの」

という前提にあったのかもしれません。

Webはページの集合体です。

そしてユーザーが価値を感じる単位も、必ずしもサイト全体とは限りません。

だから、

Text
One Site. One App.

だけではなく、

Text
One Page. One App.

という選択肢があっていい。

さらに突き詰めれば、トップページも1つのページなのだから、サイト全体への入口が必要ならトップページをホーム画面へ残せばいい。

商品なら商品を。

記事なら記事を。

ツールならツールを。

そしてトップページならトップページを。

ユーザーが残したいものを、そのままアプリにする。

それが、1P1A(One Page. One App.)というPWAの設計思想です。

Webサイトを最も簡単にアプリ化する方法 | OJapp PWA Code

Webサイトを最も簡単にアプリ化する方法を紹介。無料の1P1A・1S1AコードをHTMLに1行追加するだけで、manifest.jsonを作成せずWeb App Manifestを動的生成し、PWAとしてホーム画面に追加できる仕組みを解説します。

おじゃち

OJapp代表 WPプラグインPWAマーケティング・OnePage.OneApp.(1P1A)・ホーム画面名刺&SNSのPetal・その他OJappToolsなどを開発。PWA・ホーム画面・Safari挙動・軽量Web体験を中心に、実験しながらWebアプリを開発しています。

← 記事一覧へ戻る