Web App Manifestはiconを置く前にnameとstart URLを決める

Web App Manifestは、web applicationのname、icon、起動時に開くURLなどをJSON fileへまとめる仕組みです。iconを一枚置くだけでは、何を起点に開き、どのURLをapplicationの範囲とするか決まりません。先にnameとstart URLを決めます。

W3CのManifest for a web applicationは、manifestをweb applicationに関係するmetadataを一か所へ置くJSON-based fileとして定義しています。name、iconへのlink、起動時に開くURL、orientation、display mode、scopeを宣言でき、HTML documentはmanifest link typeでfileと関連付けます。

manifestはsiteの紹介文を書く場所ではありません。利用者が画面上で見分ける名前と、最初に開くURL、そこから扱う範囲をそろえるためのfileです。会社名をそのままnameにするか、予約用の入口として別の名称にするかは、iconの見た目より先に決めます。複数の事業を同じdomainで運営している場合に、どの事業の入口なのか分からないnameを付けると、開いた後の内容と表示名が食い違います。

start URLも、単にトップpageのURLを入れる欄ではありません。予約の確認、在庫の検索、会員向けのお知らせのように、利用者が始める作業が決まっているなら、その作業へ進める入口を選びます。ただし、直接そのURLを開いた人が何もできない状態にしてはいけません。ログインが必要なら、ログイン後に戻る先や、必要な説明へ進めるかも確認します。URLを書いたことと、利用者が目的を始められることは別です。

iconとapplicationの範囲を混同しない

会社site全体を扱うなら、start URLはトップpageになることがあります。予約や会員向けの一部だけを扱うなら、トップではなくその機能の入口を起点にする方が自然です。URLの役割を決めずに画像だけを設定しても、利用者が何を開いたのか分かりません。

scopeは、applicationとして扱うURLの範囲を考える項目です。問い合わせform、外部の決済画面、別domainの予約serviceまで、同じsiteの仕事に見えてもURLの範囲は一つとは限りません。外部へ移るlinkを、application内の画面と同じように扱う前提で設計しないようにします。利用者が外部serviceへ進む場面では、どこへ移るのかを本文やbuttonで分かるように伝えます。

URLに一時的な値を付けている場合も注意します。広告の識別子や検索条件、ログイン後だけ有効な値を含むURLを起点にすると、次に開いたときに同じ操作を再現できないことがあります。start URLは、入口として継続して使えるURLを選びます。個別の利用者にだけ見せるpageや、期限のある案内をapplicationの起点にしない方が、後の管理が楽になります。

manifestを書く前に入口を一つ選ぶ

1. 利用者が最初に行う作業を一つ決める。
2. その作業を始めるURLをstart URLの候補にする。
3. 関連するpageと、外部へ出るlinkを分ける。
4. 表示するnameとiconが、その入口の役割を伝えるか確認する。
5. HTMLのmanifest linkが正しいfileを指すか確認する。

siteの改修を外部へ頼む場合は、manifest fileを置く人と、name、icon、start URLを決める人を分けないでください。fileは制作側が書けますが、利用者へ何を入口として見せるかはsite側の判断です。

決める順序を逆にすると、画像に合わせてnameを短くしすぎたり、iconの色に合わせるためだけに入口を変えたりします。まず利用者が最初にする作業を書き、その作業へ進むURLを選びます。次に、画面上で何という名前なら内容を誤解しないかを決めます。iconは、そのnameを小さな表示でも見分けられるようにするためのものです。制作物の順番と、利用者に必要な判断の順番を混同しません。

JSON fileの書式も、見た目では確認できません。nameやURLを直したあとに、引用符、comma、括弧を誤ればfileを正しく読めません。HTML側のmanifest linkが古いfile名を指していないか、fileを移したあとにURLが変わっていないかを確認します。設定を一度にtheme、server、JSONへ分けて変更した場合は、どこを変えたのかを残します。次の変更で、どのfileが表示を決めているか迷わないためです。

iconは一種類だけを渡せば終わりではありません。小さい表示で文字が読めるか、背景が変わっても形を判別できるか、事業と無関係な飾りになっていないかを確認します。logoと同じ画像を流用できる場合もありますが、横長のlogoをそのまま縮めれば、名称が読めなくなることがあります。nameを別に表示する前提なのか、画像だけでも区別できる必要があるのかを分けて考えます。

manifestを追加しても通常siteの導線は残す

manifestはmetadataを渡す仕組みです。menu、本文、問い合わせ、検索から来た利用者の導線を代わりに作るものではありません。start URLだけを整えても、そこから必要なpageへ進めなければ目的を果たせません。

たとえば予約を受ける入口をstart URLにしても、料金、利用条件、連絡先が見当たらなければ、利用者は予約を進める前に不安になります。会員向けの入口なら、ログインできない人が問い合わせる先も必要です。applicationの起点を決める作業は、menuを減らす作業ではありません。起点から何を読めるか、どこで戻れるか、困ったときに誰へ連絡できるかを通常のpageと同じように確認します。

また、manifestを置いたことで、すべての利用者に同じ表示や操作が約束されるわけではありません。対応する環境、利用者の設定、実際に開くURLによって扱いは変わります。だからといって、何も決めずにfileだけ置く理由にはなりません。対象を決め、実際の画面でname、icon、start URLを確認し、期待と違う場合にfileを外すか直すかを判断します。

外部へ依頼する場合は、納品物をmanifest fileだけにしません。決めたname、icon file、start URL、scope、HTMLに入れたlink、変更したtemplateを一覧で受け取ります。更新時にiconだけを替えたのか、入口URLも替えたのかを区別できれば、利用者が開く画面を意図せず変える事故を防げます。設定作業を頼んでも、入口の責任まで相手へ渡さないことが大切です。

最初の一手は、manifestを使いたい対象について「起動後に最初にしてほしいこと」を一文で書くことです。その一文からname、icon、start URL、scopeを決めます。