nantekkotai's blog

おもに技術とお仕事に関連することを書いています。

ページ遷移のインタラクションはブラウザに任せっぱなしにせず、もっと画面側で制御した方が良いのではないかと云う話

pocketのログインで気付いたことを書きます。

pocketというのは「あとで読む」系の人気サービスです。
最近日本語化されました。
僕は、はてブなんか使わないで、こっちをメインに利用しています。

pocket
https://getpocket.com/

日本語化される少し前に、ログインフォームが変わりました。
今ログインしようとすると幅の狭いフォームが表示されます。

f:id:nantekkotai:20140403225847p:plain

ログインフォームの入力項目はAjaxでPOSTされて、そこでエラーならメッセージが返ってくるし、成功だったらそのまま自分のpocketのトップページに遷移します。
それでAjax送信中に当然のごとくloadingの表示があるわけですが、ログインに成功すると以下画像のようにloading状態のまま遷移するわけです。

f:id:nantekkotai:20140403225914p:plain

僕はこれを「いいな」と思いました。
ただログイン情報をPOSTして、成功したら別画面に遷移するだけなんですけど。
このWebページが切り替わるフローに、あまりストレスを感じないということが「いいな」と。

大抵のWebサービスやサイトでは、遷移中の反応をブラウザに任せているわけですよ。
Chromeのタブの中でクルクル回るローダーをよく見ますよね。あるいはURLバーでクルクル回るやつ。

ブラウザのリンクを押して別画面に遷移するアクションでも、リンクの近くでローディングなんてさせないじゃないですか。
ブラウザの機能としてクルクル回るのあるから別にいいやって今まで思ってたわけです。

でもpocketの「submitしてから遅延無くローディングが始まって、成功したらそのまま遷移する」のを見て、おやっと思いました。
この一連の流れであらためて気付かされたことは「ブラウザの緩慢な遷移に対しては単に慣れていただけ」「本当は見えないストレスを感じていたのではないか」ということです。

Webの遷移をストレスと感じる傾向は、スマホアプリを利用するようになって顕著に感じられるようになりました。アプリのあのスムーズな遷移を体感してしまうと、スマホでWebアプリとか使う気にならないんですね。

Webブラウザでは、

  • 通信して
  • HTMLとCSSを取得して
  • layoutして
  • paintして

という処理にどれだけ速くても数百ミリ秒はかかってると思います。
サーバが重くなってたり、通信状況が悪かったりすればもっとかかります。
Webのフロントエンドを担当する僕らみたいな人間は、こういう処理と処理の隙間の時間に対してもっと敏感なって、インタラクションを設計したら良いんじゃないかと思いました。

pocketのログインはAjaxだからこそこういう動作を取り入れたのだと思いますけど、通常の遷移するリンクやボタンにもローディングやプログレスを画面上に出す工夫があって良いかと。
片っ端から適応するとアレなので、ログインとか投稿とかユーザーによる明示的なアクションに対しては、インタラクションをブラウザに任せっぱなしにせず、ちゃんと画面上で反応を返す設計を行うべきかもしれません。

マイクロインタラクション ―UI/UXデザインの神が宿る細部

マイクロインタラクション ―UI/UXデザインの神が宿る細部