先日、WhoVoiceというマテリアルデザインを意識したアプリをリリースしました。ネタは以前に作ったWebサービスのAndroidアプリです。

一応Android2.3から対応していて、実装していく中で Android5未満のマテリアルデザイン対応に対する自分の指針が定まってきました。

マテリアルデザインはとても奥が深いので下手なこと言うと怒られちゃいそうで怖いんですが、自分なりの指針を示しておこうと思います。

ユーザーの考えること減らす

僕にとってマテリアルデザイン対応の目的は ユーザーの考えることを減らすという一点に尽きます。これがそのまま対応是非の指針になっています。

いやいや、より洗練された体験を提供するとかデザインの統一とか他に色々あるじゃんよ、と言われるかもしれませんが、突き詰めて考えていくと最終的にはここに帰結しました。

例えば SharedElementによって実現される画面遷移があります。前の画面の一部が次の画面の一部になる、みたいなやつですね。デザインガイドラインにもMeaningful transitionsの中で触れられています。

f:id:konifar:20150421013444g:plain

これはコンセプトビデオ見てもめちゃくちゃかっこいいんですが 要はTransitionを情報のつながりを表現するものとして扱うことで、ユーザーの混乱を減らすことを意図していると考えられます。

ガイドラインの規定の細かさ

マテリアルデザインと言うと なんかフラットで余白が大きいやつでしょ みたいな印象が強いかもしれませんが、ガイドラインにはとてもとても細かく規定されています。読んでみると、全てに信念があって設計されたデザインだということがわかります。

例えばアニメーションの項目を見てみると、画面遷移の例とともになぜそのアニメーションが必要なのかといった解説も明記されています。 アニメーションのパターンはもちろん、加速度はどうつけるべきかといったところまで書いてあります。

その他、余白の取り方やアイコンの設計方法、フォントや文字サイズの使いどころまで細かく30項目以上にわたって明記されています。

マテリアルデザイン対応の目的を明確にする

これだけ多くの規定のあるマテリアルデザインに対応するというのはどういうことなのでしょうか。ここで重要なのは 対応の目的を明確にすることです。色々考えたんですが、つまるところ対応の目的は2つしかないんじゃないかなぁと思います。

1. ユーザーの考えることを減らす

最初に述べた指針の話になっちゃうんですが、要はこれです。マテリアルデザイン対応のアプリが増えてきている中で、遠くない未来にマテリアルデザイン対応したアプリが一般的になる時が来ます。経験知というのは非常に重要なので、ユーザーが普段使ってる他のアプリと同じように使えるようにする、というのはとても重要な視点になります。

また、transitionやアニメーションに関しても同様で、急に画面が変わってユーザーがぎょっとしてしまうよりは、マテリアルデザインのガイドラインに沿ってtransitionを設計すべきかもしれません。

2. Googleのトレンドに従う

これは正直ユーザーのためでも何でもないんですが、意識しておくことが大事かなぁと思います。 マテリアルデザインに対応してるアプリはフィーチャーされやすい と聞いたことがあります。実際どこまで本当かわからないんですが、今後は対応をしておく方がいいだろうなと思います。

ユーザーのため以外でデザイン変えるなんてけしからんと思うかもしれないですが 対応時期の判断をする場合なんかにこのあたりの目的も意識しといたほうがいいかもという話です。

例えば、マテリアルデザインに少しずつ対応したらユーザーのアクションの数値が下がったとします。その時元に戻すかどうか判断するのに、こういう側面の目的もあることを覚えておいた方がいいんじゃないかなということです。

何をいつやるかという判断が必要

では、目的を明確にした上でじゃあどうするのかという話です。

ユーザーの考えることを減らすという指針があると、何をやるべきかを判断しやすくなります。つまり、マテリアルデザインとして規定されている内容でも、ユーザーに違和感を与えたり混乱を増やしたりするとしたら導入しないという判断をするということです。

何のためのマテリアルデザイン対応かを常に意識するのがとても大事です。

例えばFacebookやTwitterはFloating Action Buttonの導入時期を探っているように見えます。自分も本業のTaptripで一度マテリアルデザイン対応するためにAppCompat v21を導入してみてすぐに戻したことがあります。エラーは出なかったんですが、DAUが著しく下がったからです。

目的を意識した上で、ガイドラインの中でどの項目をいつ採用するかという取捨判断が必要になります。この判断をどうするかは、アプリによるところが大きいです。

例えばAndroid5以上のみ対応する場合は、今からできる限り対応しておいたほうがいいかもしれません。おそらく特に判断に迷うのは Android5未満の対応をどうするかというところだと思います。

Android5未満まで対応してみた時の所感

ガイドラインの項目を見ながら対応してみた時の所感を述べます。 判断に迷った時はGmailやGooglePlayといったGoogle純正アプリをよく観察して従うことが多かったです。

ちょっと無理矢理ですが、以下のように判断結果をつけておきます。

◎ : 対応すべき
◯ : 対応した方がいい
△ : しなくていい
× : しない方がいい

Animation

Authentic motion ⇒ ◯

機械的なアニメーションじゃなく緩急をつけて暖かみのある表現にした方がいいよねという話です。 急に動きが変わると体験が悪くなりユーザーが混乱すると考えると、従った方がいいかなと思いました。

実装もInterporatorを工夫するだけなので難しくはないです。以下が参考になるかもしれません。

Responsive interaction ⇒ △

タッチフィードバックなどのインタラクションの話です。わかりやすいのは Ripple Effectをつけるか というところです。

ここは対応する必要はないんじゃないかなと思います。RippleEffectはまだAndroid4だと浸透していないので、逆に変に感じさせて混乱を増やす可能性があるからです。

一応対応する場合は、ライブラリを使ってわりと簡単にできます。

[Materialデザイン] Android5.0未満でRipple effectを実装する

Meaningful transitions ⇒ ◯

意味のあるtransitionの話です。タップしたらそれが広がって次の画面の一部になるようなやつです。

考えることを減らすという指針から考えると必須ではないんですが、必要に応じて対応した方がいいと思います。ここはユーザーのためというより 作り手としてどちらがいいと思うかというエゴによる判断でもいいんじゃないかなと思ったり。

Android4以下でSharedElementによる遷移を実装することも一応可能です。

v21未満の端末で、AirbnbアプリのようなShared Elementっぽい動きを実装する

Delightful details ⇒ ×

細かいところまで気を遣って洗練させるべき、という部分です。Drawerのハンバーガーアニメーションみたいなやつですね。

個人的には、やるなら気づくか気づかないかくらいのアニメーションにとどめた方がいいと思います。 というのも、InstaMaterialというマテリアル対応Instagramのモックアプリのアニメーションを嫁に見せた時、動きがキモいと言われたからです。

このモックアプリはいいねのカウンター部分など細かいところのアニメーションにもかなり気を遣っていたんですが もしかしたら今Andorid4以下に慣れているユーザーにはまだ早いのかもしれないなぁと思いました。純正Instagramのように、ほとんどアニメーションがないけどパッパと動くアプリの方が、今のユーザーには混乱が少ないのかもしれません。

Google純正アプリのDelightful detailsを見ながら対応時期を判断すべき、というのが自分の感想です。

Style

Color ⇒ ◎

色も細かく指定されていますが、 テーマカラーに関しては従う必要はないと思います。

白や黒などグレースケールに関しては従った方がいいです。例えばメインのテキストとサブテキストなどは色が規定されて決まっているので、それに従った方がユーザーが迷わないからです。

Icon ⇒ ◯

アイコンの大きさや色に関しても、できれば従った方がいいと思います。この設計に従えば、マテリアルデザインに入れた時に違和感のないアイコンが出来上がるからです。 できれば、とつけたのはこの設計を意識してアイコンを作るのは大変そうだからです。

アイコンに関しては以下がとても便利です。

Imagery ⇒ △

GoogleCalendarなどを例に、画像の配置や大きさはこうあるべきだよね、という指定を記述しています。

これは正直マテリアルデザインに関わらず意識すべきことが書かれているので、対応できるならやるべきかなという感想です。

Typography ⇒ ◎（フォントは×）

フォントや文字サイズの指定です。 文字サイズは純正アプリでもほとんど従っていてスタンダードになってきているので対応すべきだと思います。

フォントはRobotoやNotoを使うのがよいとあるんですが 正直違いもほとんどないし日本語の場合Notoフォントファイルの容量が結構大きいので対応しない方がいいんじゃないかなと思います。

対応する場合はこちら。AndroidでNotoフォント・Robotoフォントを使う

Layout

Metrics & keylines ⇒ ◎

余白の取り方やリスト表示時のサムネイル画像の大きさなど。これも揃えておけば純正のアプリと同じように扱えて混乱させないので対応しておくべきだと思います。

Structure ⇒ ◯

Toolbarは多くのアプリも対応してきたので、AppCompatを使って従うべきだと思います。他はどちらでもよさそうです。スタンダードになってきたら対応すればいいかなというレベル。

Component ⇒ ◯

これは小項目が多いので全体的な所感を。

基本的にAppCompatで実現できるコンポーネントや、リストなどの余白の取り方の指定で対応できるところはやるべきだと思います。 TabやTooltipなどライブラリを使って実現すればできるところもありますが、細かいコンポーネントに関してはAndroid4以下の端末ではそこまでユーザーに考えさせることはないと思うので無理することはないというのが感想です。

PagerSlidingTabStripのタブにMaterialデザインを適用する方法

shadowに関しては結構難しいところで、やるとしたらAppCompatのCardViewを使うか、shadowの画像を使って実現するのがいいです。マテリアルデザインにおけるshadowは、Animationの項目でもあったとおりz軸のアニメーションで指に吸いつくような質感を表すところもセットで重要だと思うんですが、これもやはり無理しない範囲であまり気にしないのがいいと思います。

ちなみにz軸のshadowアニメーションをAndroid4以下で実装するなら、ZDepthShadowを使うとよいです。

Patterns ⇒ ◯

これも小項目が多いので全体的な所感を。

Componentと同じように NatigationDrawerやSwipeToRefreshといったAppCompatで簡単に実現できるところはやるべきだと思います。

ScrollTechniqueやLoadingImagesといったところはどちらでもいいかなと思います。必須ではないけれども、機械的な動きではなくぬくもりのある印象を与えるようなパターンなので、急に画面が切り替わったりすることがないという点ではユーザーの混乱が多少減るかもしれないですが、Android4以下のユーザーにそこまで必要かといわれると要らないんじゃないかなと思います。

もし実装する時は以下が参考になります。

materialish-progress マテリアルデザインのスクロールテクニックを実装する

Usability ⇒ △

AccessibilityとBidirectionalityの項目がありますが これはMaterialデザインどうこう関係なく意識すべきことだと思います。アラビア語対応した時は逆のレイアウトにして動くべきといった部分など、アプリにとって重要な観点が書かれています。

まとめ

長くなりましたが、最後にまとめを。

自分のマテリアルデザイン対応の指針は 『ユーザーの考えることを減らす』
マテリアルデザインの目的を常に意識するのが大事。
自分の考える目的は 『ユーザーの考えることを減らす』 『Googleのトレンドに従う』の2つ。
目的を意識しながらガイドラインに沿って実装してみた所感は以下のとおり。

項目	対応可否	所感
Authentic motion	◯	機械的なアニメーションじゃなく緩急をつけて暖かみのある表現にした方が混乱が少なくなる。
Responsive interaction	△	RippleEffectはまだAndroid5未満だと浸透していないので、逆に変に感じさせて混乱を増やす可能性がある。
Meaningful transitions	◯	考えることを減らすという指針から考えると必須ではないんですが、必要に応じて対応した方がいい。
Delightful details	×	純正Instagramのように、ほとんどアニメーションがないけどパッパと動くアプリの方が、今のユーザーには混乱が少ないのかもしれない。
Color	◎	テーマカラーに関しては従う必要はないが、白や黒などグレースケールに関しては従った方がいい。
Icon	◯	アイコンの大きさや色は難しいけどできれば従った方がいい。
Imagery	△	マテリアルデザインに関わらず意識すべきことが書かれているので、対応できるならやるべき。
Typography	◎/×	文字サイズは対応すべき。フォントは対応しない方がいい。
Metrics & keylines	◎	揃えておけば純正のアプリと同じように扱えて混乱させないので対応しておくべき。
Structure	◯	ToolbarはAppCompatを使って対応すべき。
Component	◯	AppCompatで実現できるコンポーネントや、リストなどの余白の取り方の指定で対応できるところはやるべき。
Patterns	◯	NatigationDrawerやSwipeToRefreshといったAppCompatで簡単に実現できるところはやるべき。
Usability	△	Materialデザインに関係なく意識すべき。