アプリがインターネットを失ったらどうなる?(そして作業を続ける方法)

WiFiが切れる。アプリでフォームに入力している最中——半分の項目は入力済みで、すでに5分もかけている。何が起こるか?

オンライン専用のアプリなら、こうなる。ページがリロードまたは更新される。入力したデータは消える。最初からやり直しだ。アプリを閉じ、二度と戻ってこない。

オフラインファーストのアプリなら、話は違う。入力を続けられる。データは安全だ。WiFiが戻ってくれば(3分後でも、3日後でも)、すべてが同期される。これがオフラインファースト設計を一言で表したものだ——アプリはインターネット接続なしでも動き続け、変更内容をローカルに保存し、オンラインに戻った瞬間に同期する。

多くのアプリビルダーはオフライン対応を省略する。そのほうが作るのが簡単だからだ。しかしオフラインファーストは複雑なのではなく、意図的なものだ。それは、人がまた使いたくなるアプリと、削除されるアプリの分かれ目になる。

アプリがインターネットを失うと、実際に何が起こるのか?

アプリがインターネットを失ったとき、動き続けるか、動かなくなるか——その中間はない。そして接続が切れるのは珍しいことではない。機内にいるユーザーにはインターネットがない。トンネルの中のユーザーには電波が届かない。郊外のイベント会場にいるユーザーは通信が不安定だ。深夜3時に自宅のルーターが再起動して繋がらなくなったユーザーもいる。スマホのテザリングを使っているユーザーは通信量上限に達してしまう。

こうしたケースすべてで、アプリは動くか動かないかのどちらかだ。

私たちはフリーランサー向けの勤怠管理アプリを作ったことがある。オフラインではクラッシュしていた。あるフリーランサー(電波の届かない建設現場で使っていた)はアプリを使うのをやめてしまった——鉛筆と紙に切り替えたのだ。少なくとも鉛筆はどこでも使えるから。3ヶ月後、オフラインモードを追加した後、その人は戻ってきて、それ以来ずっと使い続けている。

仕組みはシンプルだ。インターネットが切れたら作業内容をローカルに保存し、接続が戻ったら同期する。それだけのことだ。

オフラインにはどんな種類があるのか?

想定しておくべきオフラインには3種類ある——意図的なもの、不意打ちのもの、そして遅いもの。それぞれに別の対策が必要だ。

意図的なオフライン —— ユーザーが自らオフラインで作業することを選んだケース。飛行機の中にいる、あるいはWiFiが悪いことを知っている。後で同期されることを想定している。作るのは最も簡単だ。下書きをローカルに保存し、接続が戻ったら送信するだけでいい。

不意打ちのオフライン —— インターネットが予期せず切れたケース。ユーザーは作業の途中だった。文の途中で作業を断ち切られれば、当然腹が立つ。対策自体は同じ(下書きをローカルに保存する)だが、UXはもっと親切であるべきだ。アプリが動き続けていることを見せ、オンラインに戻ったタイミングを知らせよう。

遅いオフライン —— 接続自体はあるが、遅すぎて実質切れているのと同じ状態。顧客がフォームに入力して送信ボタンを押し、送信完了まで20秒待たされる。その頃には何か壊れたと思い込み、もう一度送信ボタンを押してしまう(結果、重複登録が発生する)。これがテストするのに最も難しいケースだが、対策は正直であることに尽きる。作業が進行中であることを見せる(スピナーを表示する)か、下書きを失わずにその場を離れられるようにする。

ビルダーにオフラインモードをどう依頼すればいいのか?

一度に大きな機能として依頼するのではなく、少しずつ依頼するのがいい——オフラインファーストは単一のチェックボックスではなく、設計思想そのものだからだ。ビルダーに持ち込める具体的な依頼を5つ紹介する。

下書きをローカルに保存する:「誰かがフォームやメモに入力したら、その端末やブラウザに保存してください。ページを更新しても、フォームの入力内容が残っているようにしてください。」テスト方法:何か入力してからブラウザのタブを閉じ、また開いてみる。フォームの内容がまだ残っていればOKだ。
オフラインでも動く:「インターネットがないとき、アプリは手元にあるデータを表示し、ユーザーがそれを読んだり変更したりできるようにし、変更内容はインターネットが戻ったときに同期されるようキューに入れてください。」テスト方法:WiFiをオフにして何か有用な操作をしてみる。それからWiFiを戻し、データが同期されるのを確認する。
静かに同期する:「変更内容を同期しているとき、大きなダイアログは表示しないでください。「保存中…」のような小さなインジケーターを上部に表示し、完了したら消えるようにしてください。保存に失敗した場合は、変更内容をローカルに保持し、後でもう一度試してください。」
真実を見せる:「どのデータが最新か(サーバーと同期したばかりか)、どのデータがローカルのみか(まだ同期されていないか)をユーザーに伝えてください。小さなインジケーターやラベルを使い、怖がらせるのではなく、正直に伝えるだけでいいです。」
中核の作業だけは、まずローカルで:「ユーザーがそのアプリを使う本来の目的(予約を確認する、メモを書く、時間を記録する)はオフラインでも動くべきです。あればうれしい機能(過去の記録をすべて検索する、リアルタイムの価格を取得する)はインターネット接続が必要でも構いません。」

実際にあった話

あるウェディングプランナーは、RSVP(出欠確認)を管理するアプリを作った。彼女はリストを印刷し、会場を歩き回りながら回答をチェックしていた。しかし会場のWiFiはひどいものだった。そこで彼女はオフラインファーストを依頼した——チェックリストをローカルに保存し、帰宅したら同期する仕組みだ。今ではそれが彼女のメインツールになっている。スマホの電波は届いているのに、データの読み込みを待つことなくアプリが動くからだ。彼女はこれをとても気に入っている。

ある教室の先生は、生徒の進捗を追跡するアプリを使っていた。教室から教室へ移動する際、通信が不安定で編集内容を失い続けていた。オフラインモードのおかげで、自由に作業し、後で同期できるようになり、スマホと仕事のどちらを取るか選ばずに済むようになった。たった一つの変更が、大きな信頼につながった。

ある保険の損害査定人は、現場で損害報告書を入力していた(郊外の一部エリアには電波が届かない)。もともとのアプリは送信にインターネットが必要だった。私たちはオフラインの下書き機能を追加した。今では彼はフォームに入力し、オフラインのまま送信し、車で戻る道中に同期される。「家に着くまで何も送信できない」ということはもうない。

この3つのケースはすべて「もっと良いWiFiを用意すればいい」で片付けることもできたはずだ。しかし、現実世界はそんなふうには動かない。オフラインファーストは、単なる同期の改善以上に、信頼における大きな転換点だった。

オフラインファーストにするとアプリは速くなるのか?

そうだ——オフラインファーストのアプリはサーバーの応答を待つ必要がないため、速く感じられる。入力すると、アプリはその場でローカルに保存し(瞬時に)、バックグラウンドで同期する。スピナーもなく、待ち時間もない。インターネット接続があっても、サーバーが処理の邪魔をしないため体感速度は上がる。

オンライン専用のアプリは、あらゆる変更についてサーバーからの確認を待たなければならない。キー入力 → ネットワークリクエスト → サーバー側の検証 → レスポンス → ユーザーへの表示、という流れだ。通常はこれで問題ないが、通信が遅いネットワーク(あるいはサーバーの応答が遅いモバイル環境)では、あらゆる操作がもたついてしまう。

オフラインファーストの実装にはどれくらいコストがかかるのか?

オフラインファーストは、事前にエンジニアリングの時間を要する。ビルダーは以下を考える必要がある。

ローカルストレージ:アプリがクラッシュしてもデータが消えないよう、スマホやブラウザにどうデータを保存するか。難しくはないが、意図的に設計する必要がある。
競合解決:ユーザーがオフラインである項目を変更し、その後同期される前に誰か(あるいは別の端末)が同じ項目を変更した場合、どちらが優先されるべきか?通常はオンライン側(より新しいから)が優先されるが、ユーザーには驚かせるのではなく、事前に知らせるべきだ。実例:2台のスマホが同じメモをオフラインで編集し、両方がオンラインに戻る——後から同期したほうが優先され、最初のユーザーには「あなたのバージョンは古いものでした。こちらが最新版です」と表示される。
古いデータ:ユーザーが3日間オフラインだった場合、再接続時にアプリはすべてを黙って更新すべきか、それとも先に確認すべきか?確認するほうが安全だ——古いデータに未保存の変更が紐づいているかもしれないからだ。

これらは考え抜くのにタダではないが、思っているよりずっとシンプルだ。

見返りは、ユーザーに信頼されるアプリになることだ。オフラインファーストのアプリは「これを使うにはインターネットが必要です」と言い訳をせず、作業内容を失わせることもない。それは非常に大きい。

アプリがオフラインで動くかどうかはどうテストすればいいのか?

テストするのに飛行機に乗る必要はない——スマホの機内モードがテスト環境になる。手順は次の通りだ。

アプリを開いて何か入力する:普段どおりの操作をする(フォームに入力する、メモを追加するなど)。
オフラインにする:機内モードをオンにするか、WiFiをオフにする。
作業を続けてみる:もう一度同じ操作を試してみる。アプリが拒否するなら、オフラインファーストになっていない。動けば良い。分かりにくければ、「オフラインです」という明確なインジケーターをビルダーに依頼しよう。
オンラインに戻る:機内モードをオフにする。
同期を確認する:変更内容は自動的に同期されたか?「同期」ボタンを押したり、更新したりする必要があったなら、まだ完成度が足りていない。

最も優れたオフライン対応アプリは、あまりに自然すぎてオフラインだと気づかないほどだ——ただ、アプリがちゃんと動いていることに気づくだけだ。

あなたが作ったアプリは、本当にオフラインで動く必要があるだろうか?「うちのユーザーは通信が不安定だったり、電波の届かない場所で作業したりする」というのが答えなら、必要だ。「常に安定したWiFiに接続している」というのが答えなら、今は見送ってもいいかもしれない。しかし、誰かが「作業内容が消えた」と言った瞬間、もっと早く依頼しておけばよかったと思うはずだ。