挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ 2

前回のエントリの第2弾で、続きのお話になります。

今回はステートフルWebアプリケーションとしてシステム構築を行った場合、その基本的な動作のお話（おさらい）、戻るボタンに伴う動作、そして携帯端末におけるシステム利用と戻るボタンによる動作の違いについて、図による解説を含めて紹介します。

(4) ステートフルWebアプリケーションの基本動作

例えば以下の図1のようなサービスがあったとしましょう。

図1. 3画面間を遷移するサービス

PageA, PageB, PageC という3画面があり、PageAからPageB、そしてPageBからPageCという画面遷移を行うサービスであるとします。
ステートフルなシステムとして構築する場合は、PageAをスタート地点として、PageAからPageBへ行きたいという「toB」指示が出るとPageBへ遷移、同じくPageBにいる状態で「toC」指示が出るとPageCへ遷移するという意味になります。ステートフルですので、必ずPageAから始まることを限定しています。またPageAにいる状態で「toC」と言われても遷移することもありません。
このサービスを実際に実行した例が図2になります。

図2. 3画面遷移を実行した例

緑色のマークはこのサービスを利用するユーザ（クライアント）です。PageAから始まり、「toB」指示と共にPageB、その後「toC」指示と共にPageCへ遷移していることを示しています。PageA〜PageCまでを閲覧しているページ、緑色マークは現在閲覧中の場所の目印、黄色のふきだしはGET/POSTリクエストで、赤矢印はそれに伴う画面描写の切り替え（リフレッシュ）と観るとさらに分かりやすいかもしれません。

(5) 戻るボタン使用による状態の非遷移

上記図1の3画面遷移サービスに対しブラウザの「戻る」ボタンを使用するとどうなるでしょうか。

前述したように、あるページを表示している状態において想定していない遷移指示が出たとしても勝手に遷移するようなことはありません。通常は「意味のない指示」と判断し、その場の状態に留まろうとします。（ステートフルなWebアプリケーションを実現するためのライブラリおよびフレームワークの仕様に基づきます。）

例えば PageC まで遷移済みの状態から戻るボタンを押下した場合、ユーザは PageC の1つ前のページ、つまり PageB に戻ると想像することでしょうが、図3のように画面リフレッシュが行われたにも関わらずPageCが再描画されるという動きになります。

図3. 戻るボタンを押しても現ページが再描画される

(6) 携帯キャリア毎における戻るボタン押下と画面〜システム状態の認識ずれ

さて、この3画面遷移サービスを携帯端末で利用するとします。キャリア毎に携帯端末の仕様がありますが、基本的なWebアクセスのための通信機構はPCのものと何ら変わらない仕組みになっているため、PCと変わらないサービス内容を利用することができます。これは、戻るボタンに関する事柄も全く同じです。

前回にも紹介しましたが、Docomo, Softbank 端末の場合戻るボタンを押下すると1つ前に行ったサーバリクエストを改めて実施します。これはPCと同じ仕様のため、図3と全く同じ動きになります。
PCによる画面表示の情報量に比べ携帯端末は若干少ないため、「あれ、ひょっとすると画面が戻っていない？」と認識するまでに時間を要する可能性があるかもしれません。今まで当たり前のように利用していた戻るボタンがまさか効かないと考えることが出来ず、行動に対する応答内容のズレに混乱をきたす利用者も出るかもしれません。

au の場合はさらに悲惨なことになっています。前回のエントリの通り、auの戻るボタンはページキャッシュの再表示です。容赦なく前回ページをそのまま再表示しますので、図4のように完全に画面〜システム間の状態相違が発生します。

図4. auにおける画面〜システム間の状態相違

ユーザは戻るボタンでPageBに戻っているつもりですが、システムでは PageC にいることになっています。仮にこの遷移サービスが図5であったとしましょう。PageB からは PageC だけでなく、「toD」指示で PageD へ行ける遷移になっているとします。このようなサービスにおいて、au 端末で戻るボタンを駆使して画面遷移を行おうとすると、図6 のようになってしまいます。

図5. 画面間遷移するサービス その2

図6. ユーザにとって思いがけない画面遷移

PageC から戻るボタンで PageB に戻り、PageD へ行こうとします。画面上では PageB に戻ったことになっていますし、PageD へ遷移するための「toD」に相当するようなページリンクもあるでしょう。しかしPageB は「戻ったつもり」の扱いとなっており、PageD へ行こうとしても実際は PageC にいるわけですから、「PageC を再描画する」という動きとなります。ユーザにとっては「どうして！？」という動きに違いないでしょう。

このように、携帯キャリア毎にシステムそのものの挙動が異なることになっています。これらは統一した挙動となるよう、調整をかける必要があるでしょう。
またこれとは別に、戻るボタンそのものについてその取り扱いを考える必要があるでしょう。システムとして不具合が発生せぬよう制限を設けることは重要ですが、だからといってユーザビリティを損なうようなサービスにしてしまってはいけないということです。ということでもう少しだけ続きます。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3