アプリ内ブラウザの「戻る」機能

スマートフォンのネイティブアプリケーション (いわゆる「アプリ」) の中には、ブラウザ機能が備わっているものがあります。たとえば Twitter アプリ、Facebook アプリ、RSS リーダーのアプリ、メールクライアントのアプリ、などでは、コンテンツに Web ページへのリンクが表示されていると、それをタップすることで、アプリ内で Web ページを表示することができます。

アプリ内のブラウザ機能でいくつかの Web ページを遷移しているとき、画面左上にあるアイコン (「戻る」ボタンっぽいもの) をタップしたら、直前に見ていた Web ページではなく、Web ページを開く前のコンテンツに一気に引き戻された...という経験は、ありませんか?

アプリ内ブラウザを使ってページを遷移する例

よくよく見たら、ブラウザの「戻る」ボタン (直前に見ていた Web ページに移るボタン) に相当する機能は、画面の左下にありました...というオチです。

Facebook アプリの場合。ブラウザの「戻る」ボタンに相当するアイコンは画面左上ではなく、左下にある。
Facebook アプリの画面
Gunosy アプリの場合。ブラウザの「戻る」ボタンに相当するアイコンは画面左上ではなく、左下にある。
Gunosy アプリの画面

この経験をした人は少なくないと思いますが、「今、自分は、アプリ内でブラウザ機能モードに入っていて、画面左上にあるアイコンは、ブラウザ機能モードを閉じるためのボタンなんだ」とユーザー自身が強く意識していないと、簡単に引っかかってしまいそうです。恥ずかしながら私自身、頭では理解しているつもりでも、「直前の Web ページに戻る」意図で画面左上のアイコンを無意識的にタップしてしまい、思いがけずアプリ内ブラウザが閉じてしまって、再びリンクをタップしてアプリ内ブラウザを起動し直し、そこからリンクを辿って見たいページまで戻る...ということがしばしばです。

混乱の原因

このような混乱の原因は、ひとえに「メンタルモデル」の形成にあります。「画面左上のアイコンは、直前のコンテンツ (アプリのコンテンツか、Web ページか、の区別なく) に戻るためのもの」というメンタルモデルが、ユーザーの頭の中に形成されるからです。

改めて、図で見てみましょう。Twitter アプリ、Facebook アプリ、RSS リーダーのアプリ、メールクライアントアプリ...いずれも、下記のように「コンテンツ一覧 (タイムラインや記事などのリスト)」→「個別コンテンツ」→「Web ページ」→「Web ページ」という遷移を辿るかと思います。

アプリ内ブラウザを使ってページを遷移する例
  1. 「コンテンツ一覧」から「個別コンテンツ」を開くと、画面左上に「戻る」アイコン (左向きの矢印) が表示されます。「戻る」アイコンをタップしたときの戻り先は、直前のコンテンツである「コンテンツ一覧」です。
  2. 「個別コンテンツ」内に記述されているリンクをタップすると、アプリ内ブラウザが起動して「Web ページ」が開きます。画面左上の「戻る」アイコン (左向きの矢印) をタップしたときの戻り先は、直前のコンテンツである「個別コンテンツ」です。この時点において、画面左上の「戻る」アイコンの挙動は一貫性があって自然なので、この挙動がユーザーのメンタルモデルに植え付けられることになります。
  3. 「Web ページ」の中にあるリンクをタップして、さらに次の「Web ページ」を開きます。上記までに形成されたメンタルモデルを抱いたユーザーは、画面左上の「戻る」アイコン (左向きの矢印) をタップすると直前のコンテンツ (Web ページ) に戻れるものと期待しますが、実際には「個別コンテンツ」まで引き戻されます。ユーザーが抱くメンタルモデルと実際の挙動との間にギャップが生じ、ユーザーは混乱してしまいます。

解決方法

この混乱を回避するには、いくつかの解決方法があります。よく見られるのは以下の3つのパターンです (もちろん、これら以外の解決方法も、今後生まれてくるかもしれません)。

「一歩ずつ戻る」パターン

ユーザーが抱くメンタルモデルに忠実に、画面左上の「戻る」アイコンを、直前のコンテンツ (アプリのコンテンツか、Web ページか、の区別なく) に戻るための機能として実装します。Feedly や Newsify はこのパターンを採用しています。

Feedly アプリの場合。画面左上の「戻る」アイコン (左向きの矢印) をタップすると、直前のコンテンツ (アプリのコンテンツか、Web ページか、の区別なく) に戻る。
Feedly アプリの画面

「別途ブラウザアプリを開く」パターン

アプリのコンテンツから Web ページにリンクする際、別途ブラウザアプリ (Safari や Chrome など) を開くように実装します。異なるアプリが起動したことをユーザーに明示することができるので、混乱は減りそうですが、ブラウザアプリから元のアプリへの導線が途絶えてしまう、というトレードオフがあります。iPhone ではホームボタンのダブルタップによって起動中のアプリを表示できるので、そこから元のアプリに素早く戻ることが可能ですが、これを知っているユーザーは多くなさそうです (一度やってみるだけで十分学習可能だとは思いますが)。

iPhone ではホームボタンのダブルタップによって起動中のアプリを表示できる (そこから元のアプリに素早く戻れる)。
iPhone における起動中アプリの表示

「アプリ内ブラウザをレイヤー表示する」パターン

アプリ内ブラウザの表示を「レイヤー」として位置づけ (元コンテンツの手前に重ねるように見せて)、それが視覚的にユーザーに伝わるようアニメーション表示させます。画面左上のアイコンも「戻る」ではなく「レイヤーを閉じる」ようなデザインにします。最近は、このパターンを採るアプリが多くなっています。

Twitter アプリの場合。アプリ内ブラウザの起動は、画面の下から上に向かってアニメーション表示される。画面左上のアイコンも「←」ではなく「×」になっている。
Twitter アプリの画面
Pinterest アプリの場合。アプリ内ブラウザの起動は、画面の下から上に向かってアニメーション表示される。画面左上のラベルも「戻る」ではなく「閉じる」(実際には英語表記の「Close」だが) になっている。
Pinterest アプリの画面
Evernote アプリの場合。アプリ内ブラウザの起動は、画面の下から上に向かってアニメーション表示される。画面左上のアイコンも「←」ではなく「×」になっている。
Evernote アプリの画面
LINE アプリの場合。アプリ内ブラウザの起動は、画面の左から右に向かってアニメーション表示される。「×」アイコンが画面右上にある (左上でなく) のもユニーク。
LINE アプリの画面

いずれはデザインパターンとしてひとつにまとまる?

上に挙げた「解決方法」のうち、どれが正解かと言うのは難しいところですが (アプリ内ブラウザ機能の位置づけや使用コンテキストはアプリの種類によって異なるでしょうし、また、この手のアプリの継続的な使用を通じてユーザーのメンタルモデルがどう熟成されてゆくかも影響するからです)、いずれは、デザインパターンとしてひとつにまとまってゆくのかな、と期待しています。

現時点で多くのユーザーが抱くメンタルモデルに沿うという意味では、「一歩ずつ戻る」パターンが無難な気がしますが、最近は「アプリ内ブラウザをレイヤー表示する」パターンも多く見られるようになったので、あるいはこれがスタンダードになるのでしょうか。レイヤー表示である旨を巧くアニメーションを用いてフィードバックできれば効果的ですが、アプリ内ブラウザが起動する瞬間にそのフィードバックに気づいてもらえなければならず、また、視覚的なフィードバックを享受できないユーザー (視覚障害者など) に対してはどうフィードバックを返すか、ということも課題になりそうです。

ユーザーのメンタルモデルが今後さらに熟成して、デザインパターンとしてひとつにまとまることを期待する一方で、使用方法の自由度を個々のユーザーに解放すべきでは (アプリの設定画面/プリファレンスで、どのパターンを採るかユーザーが任意に選択できるとよい) ...などとも思いつつ、今後も引き続き、ウォッチしてゆきたいと思います。