OJapp Guide

UDAとは？URLの状態をそのままアプリの入口にする考え方

スマホのホーム画面に複数の状態を置くイメージ

UDAは、User Defined Appの略です。

ひとことで言うと、 開発者がAppの入口を全部決めるのではなく、ユーザー自身がURLによって自分用の入口を決める という考え方です。

1P1Aでは「1ページを1つのApp」として扱います。

UDAでは、そこからもう一段細かくして、 同じページの中にある状態までホーム画面の入口にする ことを考えます。

ページは同じでも、URLが違えば中身の状態が違う。 なら、その状態ごとホーム画面に置けるのではないか。

それがUDAの出発点です。

ページではなく「状態」をAppとして扱う

たとえば、Web上にタイマーがあるとします。

URLがただ、

/timer/

だけなら、ホーム画面から開いたあとに毎回時間を設定する必要があります。

でも、URLに設定を持たせて、

/timer?time=3&mode=down

とすれば、「3分のカウントダウン」という状態をURLで表せます。

同じように、

/timer?time=20&mode=up

なら、「20分のカウントアップ」です。

ページ自体は同じです。

でもユーザーから見れば、この2つはかなり違う道具です。

だったら、最初から別々の入口としてホーム画面に置いてしまえばいい。

UDAでは、こうしたURLが表す状態をAppの入口として扱います。

1P1Aとの違いは「誰が入口を決めるか」

UDAは1P1Aとかなり近い考え方です。

1P1Aでは、基本的に開発者側が「このページをひとつのAppとして使う」と決めます。

ページごとに名前やアイコン、起動URLを用意して、ユーザーはそのページをホーム画面に追加します。

UDAでは、さらにユーザー側へ自由度を渡します。

同じページでも、使う人によって必要な状態は違います。

タイマーなら3分を使う人もいれば、25分を使う人もいる。

検索ページなら、検索条件が違う。

商品一覧なら、カテゴリや並び順が違う。

その状態をURLに持たせられるなら、それをそのまま自分専用の入口にできます。

URLの違いによって表示状態が変わるイメージ

Site → Group → Page → State の一番細かい単位

OJappでは、PWAの設計単位を次のように整理しています。

1S1A、1G1A、1P1Aと進むにつれて、Appとして扱う範囲が細かくなります。

UDAは、その先にあるStateの考え方です。

つまり、

Site → Group → Page → State

という流れの中で、ユーザー自身が一番細かい入口を選べるようにします。

URLに状態を持たせると何が変わる？

Webでは、URLに状態を持たせる方法がいくつかあります。

たとえばクエリです。

?time=5&mode=down

これだけでも、同じページに対して別の設定を持たせられます。

URLを開いた瞬間にその設定を読み込めるようにしておけば、毎回入力し直す必要がありません。

この「設定済みのURL」をホーム画面に置けば、ユーザーは設定画面を飛ばして、最初から自分が使いたい状態で始められます。

ここがUDAの一番おもしろいところです。

ホーム画面のアイコンが、ただページを開くだけのものではなく、 自分の設定まで含んだ入口 になります。

たとえばタイマーなら、使う人ごとにAppが変わる

UDAを説明するとき、タイマーが一番分かりやすいです。

開発者が「5分タイマー」というAppを作って配るのではありません。

開発者は、時間をURLで指定できるタイマー機能を用意します。

そのうえでユーザーが、

のように、自分が使う状態を選びます。

そして、それぞれをホーム画面へ置く。

同じWebページなのに、ホーム画面では複数の自分専用Appとして使えるわけです。

開発者は「完成したApp」ではなく「機能」を提供する

UDAでは、開発者の役割も少し変わります。

従来のAppでは、開発者が完成した入口を用意することが多いです。

このAppはこのアイコン。 起動したらこの画面。 この設定で使ってください。

UDAでは、そこを少し開きます。

開発者は、 URLによって状態を表せるWeb機能 を用意します。

その機能をどうホーム画面に置くかは、ユーザー自身が決める。

開発者が「Appを作る」というより、 ユーザーが自分用のAppを作れる材料を用意する 感覚に近いです。

ユーザーが自分用のホーム画面を作るイメージ

UDAが向いているWeb機能

UDAは、URLによって状態を変えられるWeb機能と相性がいいです。

たとえば、

のようなものです。

毎回同じ設定を入力しているなら、その設定をURLに持たせるだけでかなり使いやすくなることがあります。

特に、設定してから使うタイプの小さなWebツールとは相性がいいです。

URLそのものが設定ファイルのようになる

UDAでは、URLがただのページ住所ではなくなります。

URLそのものが、

まで表すようになります。

つまり、URLが小さな設定ファイルのような役割を持ちます。

そのURLを共有すれば、同じ状態を他の人にも渡せます。

ホーム画面に追加すれば、その状態を自分専用の入口として残せます。

Webらしい仕組みをそのままAppの入口に使う。

UDAは、かなりそこに寄った考え方です。

UDAはPWAの必須仕様ではない

ここは誤解しないようにしておきたいところです。

UDAは、PWAの公式仕様名ではありません。

OJappで、URLが表す状態をホーム画面の入口として扱う考え方を整理するために使っている呼び方です。

PWAを作るならUDAにしなければいけない、というものではありません。

サイト全体をひとつのAppとして使うなら1S1Aで十分です。

ページごとに分けたいなら1P1A。

さらに、同じページの中でもユーザー自身が状態を選びたいならUDA。

必要なときだけ使えばいい考え方です。

ホーム画面から考えるとUDAは分かりやすい

技術の話から入ると、クエリやURLパラメータの話に見えてしまいます。

でも、ホーム画面から考えるとかなり単純です。

「このアイコンを押したら、毎回3分タイマーで始まってほしい」

「こっちは20分カウントアップで開いてほしい」

それなら、その状態のURLを別々にホーム画面へ置けばいい。

ユーザーから見ると、それぞれ別のAppに近い感覚で使えます。

ページをAppにするところから、 URLが表している状態をAppにする ところまで細かくしたのがUDAです。

1P1Aの先にある考え方

1P1Aでは、「ページごとに意味があるなら、ページごとにAppとして扱えばいい」と考えます。

UDAでは、そこからさらに、

「同じページでも、状態ごとに意味があるなら、その状態も入口にできるのでは？」

と考えます。

そのため、UDAは1P1Aとまったく別の設計というより、 1P1AをStateまで拡張した考え方 として見ると分かりやすいです。

OJapp全体の設計単位については、 OJapp でも紹介しています。

まとめ

UDA（User Defined App）は、 ユーザー自身がURLによって自分用のAppの入口を定義する考え方です。

1P1Aではページを単位にしますが、UDAではそのページが持つStateまで入口にします。

たとえば同じタイマーページでも、

を別々のホーム画面入口として使えます。

開発者が完成したAppをすべて決めるのではなく、機能を提供し、ユーザーが自分に必要な状態を選ぶ。

Site → Group → Page → State。

UDAは、この一番細かいStateをホーム画面の入口にするための考え方です。