当サイト、オリジナルWordPressプラグイン「OJapp PWA Marketing」を使用しています。
各記事は専用アイコンでホーム画面に追加できます。ぜひお試しください。
PWAでは、WebサイトやWebページをホーム画面に追加し、Appのような入口として使うことができます。
これまでPWAについて考えるとき、「開発者がどのようなAppを作るか」という視点が中心でした。サイト全体を1つのAppとして設計するのか。それとも、特定のページを1つのAppとして設計するのか。
OJappでもこれまで、1S1A（One Site. One App.）と1P1A（One Page. One App.）という2つの設計を実際に検証してきました。
ただ、その先を考えていくと、Webにはネイティブアプリとは大きく異なるものがあります。
URLです。
URLは「ページ」だけでなく「状態」も表現できる
URLは、単にWebページの場所を表すだけではありません。
Query Parameterなどを使えば、同じページでも異なる状態をURLとして表現できます。
例えばタイマーなら、こんなURLです。
/timer/?time=2&mode=up&seconds=onこれは同じタイマーページですが、URLの中には「2分」「カウントアップ」「秒表示あり」という設定が含まれています。
では、このURLをそのままPWAの入口としてホーム画面に残したらどうなるのか。
さらに、どの状態をホーム画面へ残すのかをユーザー自身が選べるとしたら。
「どのようなAppにするのか」を、最後はユーザー自身が決めることもできるのではないか。
そこから考えたのが、PWA UDA（User Defined App）です。
PWA UDA（User Defined App）とは？
PWA UDAは、開発者が完成したAppの使い方をすべて固定するのではなく、ユーザーがWeb上の機能・ページ・状態から自分に必要なものを選び、自分のAppとして定義できるようにする設計思想です。
ここでいう「User Defined」は、ユーザー自身がプログラムを書いてAppを開発するという意味ではありません。
機能を開発するのは、これまで通り開発者です。
ただし、
- どの機能を使うのか
- どのページを入口にするのか
- どの状態から起動するのか
- 何を自分のAppとしてホーム画面に残すのか
この最後の定義をユーザーへ渡すのがUDAです。
タイマーで実際に試してみた
今回、この考え方を実際にタイマーで検証しました。
実際に今回の検証で使ったタイマーはこちらです。
PWA UDAのタイマーを実際に試してみる
例えば、ユーザーがタイマーで「2分・カウントアップ・秒表示あり」を選ぶとします。
その状態をURLへ反映すると、次のようになります。
/timer/?time=2&mode=up&seconds=on通常であれば、これは単に「タイマーを特定の設定で開くURL」です。
しかし、このQuery Parameterを含んだURLそのものをPWAの起動URLとしてホーム画面へ残すようにすると、意味が変わります。
ホーム画面から起動するたびに、ユーザーが選んだ「2分・カウントアップ・秒表示あり」という状態からタイマーを使えます。
さらにホーム画面名もその状態に合わせれば、例えば、
2m↑ タイマーという1つの専用Appのように扱えます。
ここで面白いのは、開発者が「2m↑ タイマー」という別のAppを開発したわけではないことです。
開発者が作ったのは、設定を変更できる1つのタイマーです。
そこから「2m↑ タイマー」という自分専用の入口を選び、ホーム画面へ残したのはユーザーです。
Appになり得る機能を開発者が作り、最終的なAppの形をユーザーが定義する。
これがPWA UDAの基本的な考え方です。
設定をサーバーへ保存しなくても成立する
今回試したタイマーには、もう1つ面白いところがあります。
ユーザーが選んだタイマー設定を、アカウントやデータベースへ保存する必要がありません。
設定そのものがURLに含まれているからです。
?time=2&mode=up&seconds=onこの文字列自体が、ユーザーの選んだ状態を表しています。
そのため、このような用途であれば、
- ユーザー登録をする
- 設定をデータベースへ保存する
- ユーザーIDと設定を紐付ける
- 起動時にAPIから設定を取得する
といった仕組みを用意しなくても成立させることができます。
URLが設定であり、URLがAppの入口でもある。
そして、そのURLをユーザー自身がホーム画面へ残すことで、自分用のAppとして使えるようになります。
これは、以前検証したPWAのstart_url: “.” で「入れたページに戻る」設計を、ページよりさらに細かな「状態」へ進めて考えたものでもあります。
UDAは「QueryごとにPWAを作る技術」ではない
ここは、PWA UDAを考えるうえでかなり重要です。
UDAは、「Query ParameterごとにPWAを作る技術」の名前ではありません。
今回のタイマーではQuery Parameterを利用しましたが、これはUDAを実現する方法の1つです。
重要なのは技術ではなく、
ユーザーが、自分に必要な機能・ページ・状態を選び、それを自分のAppとして定義できること。
という考え方です。
だから、UDAの対象はタイマーだけではありません。
例えばECサイトなら、ショップ全体ではなく「よく見る商品」を自分の入口としてホーム画面へ置く。
Webサービスなら、サービスのトップではなく「いつも使う機能」を入口にする。
SaaSの中に複数の機能があるなら、ユーザーが必要なものだけをホーム画面へ置く。
さらに状態をURLで表現できるWebアプリなら、「ページ」より細かな単位までユーザーが選べる可能性があります。
開発者が想定されるすべての用途に対して、個別のAppを作る必要はありません。
Appになり得るWeb機能を提供し、最終的な形をユーザーに選んでもらう。
それがUDAです。
1S1A・1P1A、そしてUDAへ
これまでOJappでは、PWAの設計を考えるために1S1Aと1P1Aという考え方を検証してきました。
1S1A（One Site. One App.）では、サイト全体を1つのAppとして考えます。
一方、1P1A（One Page. One App.）では、1つのページを1つのAppとして考えます。
ここまで考えていたのは、
何を1つのAppとするのか。
というAppの単位でした。
Siteなのか。
Pageなのか。
UDAでは、そこから問いが1つ変わります。
そのAppを誰が定義するのか。
1S1Aや1P1Aでは、基本的に開発者がAppの単位を設計します。
UDAでは、その先にある最終的な入口や状態の選択をユーザーへ渡します。
Developer Defined Appから、User Defined Appへ。
1S1Aや1P1Aを置き換える考え方ではなく、その先にある別の軸です。
Webだから「ユーザーがAppを定義する」が成立する
この考え方が面白いのは、WebにはもともとURLという仕組みがあることです。
Webは、検索から直接ページへ入れます。
リンクを共有できます。
Query Parameterで状態を表現できます。
そしてPWAを使えば、そのURLをホーム画面の入口として残すこともできます。
OJappではこれまで、Webページをホーム画面へ残すことを「アプリをインストールする」というより、URLを次回の入口としてホーム画面へ置くものとして考えてきました。
UDAは、その考え方をさらに進めたものでもあります。
開発者が「このAppはこう使ってください」と完成形をすべて決めるのではなく、Web上に機能を用意する。
ユーザーはそこから、自分が必要な場所や状態を選ぶ。
そして「これを自分のAppにする」とホーム画面へ残す。
WebのURLが持つ自由さと、PWAのホーム画面という入口を組み合わせると、こういうAppの作り方も成立するのではないかと考えています。
「WebをどこまでAppにするのか」の、その先へ
これまでPWAを検証しながら、「WebはどこまでAppになれるのか」ということを何度も考えてきました。
でも、UDAまで来ると、この問い自体が少し変わってきます。
Webには、検索ですぐ発見できる、インストールする前から使える、URLで共有できるというWeb本来の自由さがあります。
PWAは、そのWebを必要なときだけホーム画面へ残すことができます。
そしてUDAでは、さらにその先へ進みます。
何をホーム画面に残すのか。
どの状態から起動するのか。
それをどんなAppとして使うのか。
そこまでユーザー自身が決める。
開発者が完成したAppを定義して配布するだけではなく、開発者は「Appになり得るWeb機能」を提供する。
そしてユーザーが、自分に必要なAppを定義する。
それが、今回タイマーの実装と検証から考えた、
PWA UDA — User Defined App
という設計思想です。
PWA UDAの考え方は、実際に触ってみるとかなり分かりやすいと思います。
今回検証したタイマーはこちらです。
GoogleでOJapp Tipsを優先する情報源に追加
今後、Google検索でOJapp Tipsの記事を見つけやすくできます。
WPプラグイン[OJapp PWA Marketing]リリース！ 
