GoogleがOpen Automotive Allianceを結成し、AppleがCarPlayを発表するなど、
今年になってから車載アプリの動きが盛んになってきています。
車載アプリはその使用形態がSmart phoneとはまるで違うので、異なるUIが求められます。
Sound Fireは当初から車で使う事を想定して開発していたのですが、実際に作ったものを車で試すと、当初考えていた以上に様々な問題と直面しました。
ここでは、そんな使ってみて分かった車載アプリに求められる要件と、それを達成するために行ったSound Fireでの実装を紹介します。
車載アプリを使ってみて気づいたこと
運転開始時も想像以上に忙しい
運転中に忙しいのは想像がついていたのですが、運転開始時も意外と慌ただしく感じます。車に乗り、座席を合わせ、シートベルトを付けて、エンジンを掛け、ギアを入れて、サイドブレーキを外してという多くの必要な動作がある中では、スマートフォンであれこれ操作をするというのが通常以上に苦痛に感じます。
細かな操作は無理
運転中に携帯を持っての操作は法律で禁止されています。車載スタンドを使っても、細かな操作は殆どできません。
画面が眩しい
夜間運転している時は、明るい背景のアプリは眩しく運転の妨げになってしまいます。操作可能な時間は短く、不定期
信号停車時などに操作をするとき思いの外時間がありません。信号が赤だと、ゆっくり信号に近づいてとまるので、車が完全停車している時間は思ったより短いです。
加えて田舎や高速道路では数十分から一時間単位で全く停車しないことが有ります。
アニメーションは危険
車の中では視界と三半規管が矛盾するので、通常に比べて何が動いていて何が止まっているかの判断が付きづらくなります。特に一方向のアニメーションが続くと自分が反対方向に動いているような錯覚に陥ったり、誰かが飛び出してきたかのように見えて注意が削がれてしまいます。
ナビが重い
車内で使うスマートフォンアプリといえばGoogle Naviなどのカーナビアプリが一番の筆頭でしょうが、これが意外と重い。そのため同時に動くアプリは軽めに作っておく必要があります。
車載アプリに求められること
上記のことから以下の要件が車載アプリに必要なことがわかりました。最小操作
操作はできるだけ少なく、簡単であることが求められます。Sound Fireでの実装でいうとVersion1はNFCにかざすだけでアプリが立ち上がり音楽が再生される仕組みになっていました。
Androidの仕組み上NFCはアプリの機能と切り離した方が都合が良いことがわかったため、Version2でNFCの機能を外しましたが、代わりに一度でも検索した音楽は自動保存され次回からはワンタップで再生できるようにしたほか、ロックを解除しない状態での操作やウィジェットでの操作に対応させました。
即時レスポンス
操作時間を短くするためにはレスポンスも高速でなくてはいけません。操作を行ってその結果がエラーだった場合、ユーザーが次にそのリカバリーをできるのは数十分〜数時間後かも知れません。
Sound Fireの場合Version1では毎回クラウドに問い合わせていたのを、Version2では検索結果を端末内に保存することで2回目以降のレスポンスを大幅に改善しました。
Version3では初回の検索時も分割して行うようにして、検索が完了する前に音楽を再生する仕組みになっています。
音声操作レスポンス
画面を見ながら操作をしている場面でも、信号が青になるなど突然画面を見る事ができなくなることが有ります。そのため、音声操作を受け入れ、全てのレスポンスは音声で返してやることが望ましいです。
検索キーワードは音声で入力可能なほか、レスポンスは音声で返しています。
シンプルな操作
走行中の車内は揺れるのでマルチタッチや長押しは絶望的だし、スワイプも上下左右程度の精度でしか操作できず、ドラッグ・アンド・ドロップのような操作は不可能です。ボタンサイズは通常のアプリでは9mmが目安ですが、車載時はその倍は必要です。
Sound Fireではボタンのサイズを大げさなくらい大きくして、文字の大きさも大きめです。
画面切り替えは1次元なスワイプで行い、誤操作を避けるために曲操作以外殆どの操作ができなくなる詳細画面もあります。
曲リストの修正は別画面で行い、暗黙的に運転中は行わないよう促しています。
また、カーナビが対応している場合はカーナビに付いている物理的な再生、一時停止、次へ、戻るボタンを使用することが出来ます。
暗く彩度が低い色を使う。
運転中の眩しさを抑えるために、画面上の彩度や明度は低く、ウィンドウに近い画面上方は特に色を暗くして運転時の妨げにしないようにする必要があります。信号と誤認する色は避け、集中力を阻害する彩度の高い色は控えるべきです。
Sound FireではAndroid4.3までのOS標準色に近い青と水色の中間に近い色のみを使い画面全体での統一感をはかりました。
背景は薄く色づいていますが、明るいのは画面下だけとして、上部に行くほどグラデーションで暗くしています。
コントラストで表現
短い時間で情報を認識させるには彩度での表現よりコントラストでの表現のほうが有効です。Sound Fireでは操作可能な部分を明るい白で表現しました。
よく使う戻る、再生、次へボタンは大きめのボタンにしているため画面が明るくなりすぎるのを抑制するため、輪郭だけでボタンを表現しています。
輪郭での表記は視認性に劣りますが、ボタンサイズと、常にそこに表示するという習慣性でカバーしました。
自動リカバリー
なにかエラーが発生した場合、それを修復できるのは数十分〜数時間後かもしれないため、可能なら自動でリカバリーを行い、ユーザーの操作を不要にしてあげるべきです。Sound Fireでは検索データが見つからなかった場合には、エラーとして再生を止めるのではなく、それまで再生していた再生リストをそのまま再生し続けるようにしています。
音楽データにアクセス出来ない場合は自動的に次の曲を再生するようにしています。
ユーザーの操作をタイムアウトしない
いくつかのUIではユーザーが暫く操作を行わないと通常画面に戻る仕様のものがありますが、ユーザーの操作が短時間で細切れに行われる車載アプリの場合、この方法ではユーザーが途中まで行った操作を勝手に取り消しされてしまう可能性があります。Sound Fireでは複数回の操作が必要な操作そのものを減らすとともに、スリープを無効化出来るようにしています。
アニメーションは最小限に
アニメーションはアプリの楽しさを提供してくれますが、車載アプリでは安全のため大げさなアニメーションは控えて、短く、少なくが鉄則です。
Sound Fireでは詳細画面で曲が切り替わるときにアニメーションを使っていますが、アーティスト、タイトル、アルバムアートをそれぞれ別のスピードでアニメーションすることでユーザーが幻惑されないように注意しました。
しかし、正直なところこれでも余計に感じてしまうことが有ります。
省メモリ 省CPU
同時実行するアプリのためにメモリーやCPUは少なめにしておきましょう。ただし、バッテリーの心配が必要ないのでスリープなどの必要はなく、平均値は高くてもいいけれど、最高を抑えるという作り込みが必要です。
Sound Fireでは画面の階層を抑えたりキャッシュを少なく使いまわすことで最大消費メモリー、CPUを控えめにしています。
結論
このように、車載アプリでは考えないといけないことが沢山ありますが、大きくまとめると、最小の操作、地味な画面、高速なレスポンスが、通常のスマートフォンアプリ以上に求められているということがわかります。
今後は車載センサーなどとも連携した、よりユーザーの思考を先読みするアプリが求められてくると考えられます。