AWAインタラクションの主軸は『ギャップレス』

【GIFアニメーション多用につきPC推奨】

AWAをリリースして3ヶ月ほど経ちましたが
これまでインタラクションについてしっかりと説明したことがなかったので、
今回はAWAのインタラクションについてまとめていきます。
 

※ここではインタラクションに完全にフォーカスして書きます※この記事では iOS版 AWA v1.2.0 時点でのインタラクションをまとめています

はじめに
 

インタラクションというと右脳的・感覚的な要素が強いですが、

開発においては右脳的に良くするするために左脳をかなり使うので、作成段階はかなりロジック的です。

今回はそうして作ってきたAWAのインタラクションをあえて深いところまで説明して、

左脳的な部分を備忘録的に露出いきたいと思います。
 

■ インタラクションはあくまで直感で理解してもらうための手助け

AWAのインタラクションを作るうえで最も大切にしたポイントを一言でいうと、

ギャップレス
 

です。

インタラクションはあくまで「ユーザーがインターフェースを理解するための手助け」であり、この理解が進めば進むほど「使いやすさ」が得られると考えています。

「ギャップレス」にしていくことで自然と「理解促進」に繋げています。

AWAにはそのためのアニメーションをなるべく多く組み込みました。

Building AWA Interaction


▼ 現実世界の動きとのギャップを作らない

普段私達が現実で目にしている動きとのギャップを小さくするようにしました。


■ パララックスやシャドウ、ブラーによる構造の明確化

メインページとメニュー間の関係性維持

パララックスによる位置関係の明確化
ブラーによる視点移動のスムーズ化

サムネイルへの影付けアニメーション

 

あえて説明する必要もありませんが、現実世界では「後ろの模様の動きが遅いから、あれは遠くにあるものだ」なんて意識して理解してる人はいないと思います。

脳が無意識に理解している部分です。

ということは、アプリ内の動きを現実で目にしている動きに近づけるだけで、ページの構造を直感的に理解してもらうことができます。

パララックスやシャドウはまさにここに直結していて、これを正確に使うことは直感的なUIにするための最も簡単な方法と言ってもいいかもしれません。

AWAでもパララックス、シャドウを正確にアニメーションさせることに気をつけました。

またスクロールするにつれて背景にブラーをかける処理（ライブリーブラーと呼んでいます）も

近くにあるものに視点を合わせると、他の部分はボヤけるという現実世界の現象に合わせて、

プレイリストを見やすくするとともに視点の移り変わりをスムーズにしています。


■ 位置関係はそのままに、アニメーションスピードの違和感を消す
 

ただし、

正確にやり過ぎると違和感に繋がることもあります。

例えばプレイリスト詳細ページから戻る際のアニメーション。
 

 

TOP100などの縦スクロールが長いプレイリストの場合、

下までスクロールするとサムネイルは相当上に位置していることになります。

これをそのままの位置からアニメーションさせてしまうと、

サムネイルの移動だけやけに早くなり、急なスピードの差に違和感を感じてしまいます。

そのため、"上にある"という位置関係だけは変えずに、

アニメーションの開始位置を画面のすぐ上になるようにすることで、

現実世界とのギャップを小さくしつつ、スピードによる違和感は消すようにしています。



▼ ジェスチャーとアニメーション間のギャップを作らない

ジェスチャーのスピードに合わせてアニメーションのスピードを変えるようにしています。

プレイリスト

プレイヤー

トラックメニュー

 

この理由について、

「使い慣れた人にとってゆったりとしたアニメーションは鬱陶しいものになるので、操作によって解消できるようにした」とは言ったりもしますが、本髄はそこではありません。

もっと単純に「その方が自然だから」です。

「使い慣れた人にとって～～」はそれによる副産物です。

実はiOSの標準インタラクティブアニメーションにも

連動性は低く条件付きですが、

ジェスチャーの速さによってアニメーションの速度を変える処理がわずかながら入っています。

※ただし、カスタムトランジションにする場合は、そこまでは自動でやってくれないので、独自のカスタマイズが必要です。

実際にiOS標準アプリでインタラクティブポップジェスチャーをするとそれがわかります。
 

例：AppStoreで奥の階層からエッジスワイプで戻る

ある条件をクリアするジェスチャーのみ考慮

条件外のジェスチャーは考慮されない

 

標準がこうしている理由もある程度伺えますが、

標準並みにジェスチャーのスピードとアニメーションのスピードとの連動性が低いと「機械っぽさ」が出てしまいます。

この「機会っぽさ」は後述の「継続性」に関わる部分で、ジェスチャーとアニメーションにギャップが出た瞬間、ユーザーの脳はそのギャップに気が向いてしまい、それまでの行動を忘れてしまいやすくなります。「継続性」を失うポイントとなります。

このギャップを無くすために、AWAのカスタムトランジションのほぼ全てにジェスチャーのスピードを考慮するための仕組みを入れました。



▼ OSの思想とのギャップを小さくする
 

とはいうものの前節のような部分以外で

OS標準な動きに近づけられる箇所に関してはなるべく近づけるようにしています。

普段使用している(目にしている)ものに近づけることで、直感的理解を促進しています。

例えば、プレイリストのトランジションはカスタムしているものの、

サムネイルと背景の透過アニメーション以外の部分は標準アニメーションに近づけるようにしています。

前のViewのズレ幅や境目のシャドウの変化などiOS標準のアニメーションと同じになるようにしています。

AppStore

AWA

▼ ユーザーの連続的な動作の中にギャップを作らない

■ 継続性を保つトランジション

「継続性」を保つことはアプリの使いやすさに直結する大きなポイントの一つだと思っています。

ユーザーが連続的な動作をするときには、無意識に思考の連鎖が起きています。

「AからZまでプレイリストが並んでいる→Aというプレイリストがある→この中身を見てみよう→他にももっと並んでいたからもっと見てみよう→さっきはAを見ていたから、Aではないものを見てみよう→Bというプレイリストがある→...」

この思考の連鎖をなるべく保つようにすることで、スムーズに使えるアプリになっていきます。

例：プレイリストのトランジション

  フィード上のプレイリストをタップ
→フィードに表示していたサムネイルがページ間で継続される
[タップしたものを見ていることを理解]
→バックすると今度は詳細にあるサムネイルがページ間でも継続される
[今まで見ていたものはフィード上にあることを理解]
[同時に他のプレイリストは今見ていたサムネイル以外のものであることを理解]

これをただ切り替わるアニメーションにしてしまうと、

ユーザーの連続的な動作の間に、今までの行動とそれに関わる要素を脳が再構築する時間がわずかに生まれ、

直感的でスムーズな操作がしづらくなってしまいます。

AWAではなるべく継続性を保てるようなトランジションになるように気をつけています。

また、ボタンタップでも、ジェスチャーでも、

"行き"と"戻り"が同じ動きになるように作ることで、さらに継続性を失わないようにしています。

こうしたトランジションにすることは、

最近では必須といっていいほど標準アプリにも組み込まれてきています。

 

■ 意味合いの合う要素をアニメーションさせる

トランジション以外でも同様に、

継続性を持たせるアニメーションにすることで、ユーザーの無駄なステップを減らすことができます。

プレイリスト作成時の曲選択アニメーションでは、

選んだことを確認するステップをアニメーションによって短縮しています。

選択した曲のジャケットをボックスに移動させる

 

このアニメーションにより、

「＋」マークの色が変化したことを確認したり、ボックスを見て選んだものが正しく入っているかどうかを都度確認するステップを減らし、よりスムーズなプレイリストの作成に繋げています。

また、誤タップによって誤って曲を選択してしまった場合でも、即座に気付くことが可能です。

ここで注意したのは、単純に継続できそうな要素をアニメーションさせるのではなく、

ユーザーがアクションを起こした位置(タップした位置)からその要素のアニメーションを入れることです。

AWAでアルバム内の曲を選ぶときはセクションヘッダーにジャケットがあり、曲単体にはジャケットはありません。

上部に同じジェケットがあるからといって、そのジャケットをアニメーションさせると、

上記のような効果が得られないアニメーションになってしまいます。

また、ここで表示しているジャケットはアルバム全体を意味しているため、要素の意味合いとしてもズレてしまい、直感的なアニメーションにはならなくなります。

単純に継続できる要素をアニメーションさせるのではなく、

その要素の役割とユーザーのアクションの意図を意識して、適切な要素をアクションした位置からアニメーションさせることに気をつけています。

 

■ あえて継続性を断つ

この考え方をもとに、

あえて継続性を断つアニメーションにしているのがメニューからのトランジションです。
 

 

メニューにならんでいるのは、それぞれ用途が大きく違うページへのリンクです。

ここでの遷移では連続的な動作は発生しないため、

あえて瞬時に切り替えることによって、全く違う行動への切り替えがスムーズにできるようにしています。

ここからはギャップレスとは少し離れますが、さらに直感的にするためのちょっとしたアニメーションの工夫点を書きます。

▼ 遅延アニメーションを利用したパーツの理解促進

AWAではひとくくりのアニメーションの中に遅延アニメーションを入れることで

パーツの直感的理解を促進しています。

実際は見ればだいたいわかることも、少しの違いを加えるだけで、

そのページを開いた瞬間からの理解速度を向上させることができます。

プレイヤー

トラックメニュー

ログイン画面

Settings全般

 

このようにパーツ毎にアニメーション速度や開始速度を変えることで、

その一つ一つが別ものであることを直感的に把握させています。

特にトラックメニュー、ログイン画面では一番下に戻るボタンがあるため、

「そのページでのメインとなる内容→戻る導線」

の順番にアニメーションさせることで、ユーザーも順番に理解できるように意識しています。



▼ ジェスチャー時の遷移を示唆

継続的なトランジションに加えて、

ジェスチャー中にトランジションすることを示唆するようなアニメーションを入れています。

例えば、一番わかりやすいのが、マイページやアーティストページの画像拡大ページです。

マイページ

アーティストページ

 

ジェスチャーによる画像の移動幅に合わせて背景のブラーを弱めて、

元のページをくっきり見えるようにすることで、

このジェスチャーは元のページに戻れるということを示唆しています。

またブラーを弱めていくことで、視点がだんだんと後ろの要素に移動していくため、

スムーズな遷移に繋げることができます。

※もちろんタップでも戻れます



▼ タップ操作だけでなくジェスチャー操作も加える

前節のマイページ、アーティストページの画像の箇所もそうですが、

タップだけでなくジェスチャー操作も増やすようにしています。

その理由は単純で、

スマホの持ち方と人間の手の構造上、タップという行為よりも、スライドなどの行為の方が楽だからです。

また、最近では端末の画面が大きくなってきたこともあり、

タップ操作は対象の位置まで指を移動させること自体も難しくなっています。

AWAではなるべくジェスチャー操作でも同じことをできるようにしました。

メニューはジェスチャーでも開ける

 

特にメニューは、ボタンが上にあるためタップだけだと使いづらくなってしまう箇所です。

そのためメニューボタンのあるページでは、上から下にスワイプすることでもメニューを開けるようにしています。

このときスクロールのジェスチャーと競合してしまうため、

スクロール位置がトップの場合のみ有効になるようにしています。

 

また、今回は詳しく書きませんが、

ジェスチャーは一つの動作の中に複数の処理を入れることができる点も、タップだけでなくジェスチャーも入れるメリットの一つです。

ここについては今後のAWAのアップデート後に説明できればと思います。

▼ ユーザーの行動を阻害しないアテンション

■ チュートリアル
 

基本的にチュートリアルはユーザーにとっては不快なものです。

チュートリアルは行動を強制され、サービス自体の本質的な体験とは全く別の領域にあるからです。

まずAWAではチュートリアルをそもそも入れないようにしましたが、

HOMEの5画面の位置を認識してもらうために1つだけ入れています。

AWA唯一のガイドアニメーション

 

ここで気をつけたことは、チュートリアルどおりの行動を強制しないようにすることです。

例えば、まだ右のページを見ていないときに、「◎」をアニメーションさせスワイプできることを示唆します。
※AWA社内では訳あって通称「流星」と呼んでいます（笑）
 

このとき、他の操作を無効化してガイド通りのスワイプを強制する、ようなことはしていません。

ユーザー自身が気付いて、やりたいときにその行動をしてもらうだけにしています。

認識度の観点でみても、実際このアニメーションだけでユーザーには十分伝わることがサービスイン後の数値からわかっています。

（このガイドが出る前にスワイプする人も多数）

丁寧に説明して強制的にチュートリアルをさせるサービスと数値を見比べてみても遜色ないどころか良い結果が出ていることが確認できています。

とはいえ、これを意識して実装すれば、チュートリアルを多用していいわけではありません。

あくまでチュートリアルはサービス側が学習してほしいがために出しているため、

ユーザーにとっては学習と引き換えに本来やりたい行動が阻害されていることを常に意識しなければなりません。

AWAでは「どうしても」というこのポイントにのみ、ユーザーの行動を阻害しないようにガイドアニメーションを入れました。


■ ローディング
 

ローディングもまた、ユーザーの行動を阻害する一つの要因です。

一般的な画面中央にクルクル回るローディングアニメーションは

ユーザーにとっては「行動できない時間」となることが多いためです。

AWAではなるべく全操作ができないローディングにはしないようにしています。

また、操作できないようにしていても、

クルクル回るアニメーションはユーザーに反射的に行動を止めさせてしまうため、

Homeの各ページではページタイトルを光らせて、他の要素を邪魔しないようにローディングを表現することで、

行動の阻害を二重に避けています。

 

Homeのローディングアニメーション

 

このアニメーションに掛けあわせ、システム的にも通信を感じさせない工夫が施してあるため、相乗的にユーザーの行動を阻害しない作りを意識しています。

最後に

■ 左脳で作って、右脳で決める

かなり左脳的に作っていますが、最終的に判断するのは右脳です。

作成段階で深く説明しない理由はなるべく右脳で判断してもらいたいからです。

作ってみたものの自分で感覚的に良くないと判断して捨てたインタラクションもかなりあります。

■ コンマ数秒の理解のためにコンマ数秒の違いを調整するのがインタラクション

インタラクションは右脳に響かせる部分であるが故に、

実際に作り、触って判断しなければその良し悪しがわかりません。

「AWA-IxD」というインタラクション専用のアプリを作った理由はそこにあります。

動きを確かめるツールはたくさんありますが、やはり実際にアプリにして見てみないと正しく判断できません。

コンマ数秒の理解スピードの差を埋めるために、

コンマ数秒の違いを調整していくインタラクションにおいて、

ツールと実際のアプリでの小さな誤差が右脳での感じ方を変えてしまうからです。

■ たくさん壊して、たくさん創る

実際のアプリと同様にフルコードで作成するため、

コードを大量に書きますが、大量に捨てることにもなります。

がんばって考えて書いたコードを捨てるのは大変苦しいかもしれませんが、

捨てた分だけ良いものができるのがインタラクションだと思います。

捨てたコードがまた資産となって活用されることも多分にあります。

（文字が光るローディングも一度捨てたコードから活用されました）

■ 軸のあるインタラクションに

インタラクションに正解・不正解はありません。

かといって、何も考えずにアニメーションを盛り込んでいくと、

一貫性がなくなってしまい、より使いづらいものになってしまいます。

インタラクションを作る際は、その軸を決めておくことが重要だと思います。

軸があることによって、その良し悪しを判断できるようになるからです。

AWAのインタラクションにおいてはギャップレスを軸として作っています。

■ 意味のあるアニメーションを付ける

直感的にするためのインタラクションにおいて

最も大切なのは「意味のある」アニメーションにすることです。

ここまでのポイントの中でもあったように、

意味がそぐわないとユーザーの混乱を招くことになり

真逆の効果に変わってしまいます。

Googleマテリアルデザインのガイドラインにも

「Meaningful transitions」という項目がありますが、

まさにこれと同じです。

一つ一つの要素の役割、それらを全体で見た時の役割、サービスの特性、

そのときのユーザーのアクションの意図を考えてアニメーションを付けていくことが

直感的でスムーズな使用を手助けするインタラクションに繋がります。

AWAでは必ず意味のあるアニメーションにしています。

■ 課題はまだまだ多い

これらのポイントを意識して作っていますが、

まだまだAWAのインタラクションには課題が多いと感じています。

例えばGENRE/MOODのトランジションです。

上述したいろんなポイントが最も競合しやすい箇所になるため、

非常に悩ましい部分ですが、現状のアニメーションよりもまだまだ良くできる部分だと思っています。

引き続きより使いやすく音楽を楽しめるアプリを目指して、インタラクションには力を入れていきます。

 

次回は「AWA-IxD」をどう作ったか、について書こうと思います。


Thank you for your time.