Goodpatch AdventCalendar 21日目の記事です。
昨日は @roothybrid7 の声に出して読みたいAppleのiOSサンプルコードでした。
(本記事は実装とあんま関係ないことが多いので、頃合いを見て削除&移行します。)
はじめに
2014年6月に発表されたマテリアルデザイン。まだまだ普及したとは言えないですが、MaterialDesignライクなアプリをよく見かけるようになりました。
今後Androidアプリのデザインは、MaterialDesignありきになっていくと思います。
僕は仕事でAndroidアプリの受託開発をしています。今年は6本の制作に関わりました。設計~実装まで関わったものは4本,デザインのみ関わったものが2本です。その全てに、MaterialDesignを適用しました。
今年１年関わってみて、思ったことなどが書いてあります。
これからマテリアルデザインを使おうと思っている方の参考にでもなれば幸いです。
なぜMaterial
自分の場合
そもそもなんでMaterialDesignやるのという話ですが。
僕(たち)がMaterialDesignを適用するのは、ぶっちゃけそれが好きだからです。
Googleのコンセプトや、Matiasさんのいうことに共感しているということもあります。
また、とあるデザイナーさんに叩きこまれたことがあります。要約すると
「ソフトウェアのデザインはOSありきであり、それぞれ設計思想が異なっている」
という原理。そして、その設計思想にうまくマッチするデザインを適用しないといけないという。
だから、iOSではHumanInterfaceGuidelineは最低限押さえておくべきだし、AndroidではそれがMaterialDesignというお話です。
それ以外にも理由というか、メリットが有ります。
まず一つは短期的に見て、Googleにピックアップしてもらえる確率が上がるということです。
GoogleはMaterialDesignを普及させたいので、きちんとデザインを当てたアプリを少しでも全面に出したいはず。
マテリアルデザインアワードや、DevelopersBlogで取り上げてもらえたり、もしかしたらPlaystoreで検索エンジンに優遇してもらえるかもしれません。
長期的に見ると、マテリアル化しないリスクが有ります。
長期的に見ると、AndroidではMaterialDesignがスタンダードになっていきます。
すると、マテリアルデザインではないアプリが、Androidぽくないというふうに見えてしまう。
このデザインを適用しないことで、ユーザーへの違和感につながってしまうのではないか、という懸念があります。
Googleの場合
ところでマテリアルデザインがどういう意図を持って設計されたか? GoogleのMatialDualteさん(MaterialDesignのパパ)が言うには
- ユーザーに対し、クロスデバイス・クロスプラットフォームで統一した体験を提供する
- 脳への負担を軽減して、よりデバイスとの距離を縮める
ことが目的だと言っています。MaterialDesignは別に、Androidのみのために作られたデザイン言語ではありません。
とはいえ、この記事はAndroidにおけるMaterialDesignの話なので、そこに絞って話を進めたいと思います。
どうやってMaterial
僕がどうやってMaterialDesignについて学んだかというと、主に以下の４ステップを踏みました。
- MaterialDesignのガイドライン, コンセプトを読み込む
- 周辺情報を読み込む ex) マティアスさんインタビュー
- 実際に適用したアプリを参考にする
- MaterialUpでデザインコンセプトを見る
ガイドラインは本当に充実していて、どうすればいいか、なぜそれがよくて、なぜそれがだめなのかが丁寧に書かれています。
もちろん読むだけでは頭に入ってこないと思うので、実際にデザインしながらそこは覚えていくといいと思います。
わからなくなったら辞書的に調べて読んでを繰り返す。
そうして掴んできたら実際のアプリを見ます。
MaterialDesignアワードのアプリが参考になるかもしれません。
とはいえ、実装だとどうしても再現できないことがあるので、純粋にデザインのコンセプトだけを見たいならDribblleやMaterialUpで素敵な作品群を鑑賞しましょう。
あとはひたすら応用あるのみ。
現実のMaterial
さあ、デザイン言語は理解した。ビジュアルデザインも出来た。
でも、作らなければならないのは、アプリです。
現実は厳しかったです。
いくらビジュアルが完璧でも、それが実際に作れなければ意味が無い...。
クライアントワークは常に時間と実装上の制約との戦いです。限られた時間の中で最も効率のよい成果を出すということは、何かを捨てて何かを選ぶということです。
僕が選んだ方針は、
- 標準UIを活かす
- 動的なインタラクションは最低限にする
- OSSで出来ることはできるだけOSSの力を借りる
- 下位互換を出来るだけ切る
- メンバー間で常に実装上の話をする
標準UI
Androidの標準コンポーネントは、下位互換も含めて現状MaterialDesignのテーマが一般的になっています。特に頑張らなくても、コンポーネントには予めMaterialなスタイルが適用されています。
この標準テーマをできるだけ上手く活用することで、大幅にコストカット&クオリティ担保できます。
インタラクション
スペーシングをガイドラインの通りにしたり、コンポーネントを配置するだけなら結構すぐ終わ...いや、実はすぐには終わらない。レイアウト一つ組むのも、なかなか大変です。
さらにさらに、細いインタラクションや表現の部分になってくると、とたんにハードルが上がります。
インタラクションはMaterialDesignのキモといっても良い点なので、欠かすことは出来ません。
でも、実際つらい。ロジック考えるのも実装も時間かかるし、保守性保つの難しいし。
でもでも、ちゃんとやろうとすると、アニメーションなくすことは出来ない。
OSS
そこでOSS。
多分有名なのはObservableScrollViewやFloatingActionButtonでしょうか。
もちろん、使えるものは限られています。
たまに細かいことをやろうとなったときに、かゆいところに手が届かないことがありました。
デザイナー「ここ、こうしてほしいんだけど」
俺「あ、ここライブラリ使ってて、この子だと無理です...」
デザイナー「あ、無理なんだ...(´・ω・｀)」
俺「(´・ω・｀)」
今年半ばにGoogleが出したデザインライブラリも使いました。かなり強力な公式ライブラリです。
とはいえ、これを使う時も注意が必要でした。思った通りの挙動をしてくれないことがあります(たとえばCordinatorLayoutのパララックスアニメーション, 出た頃のTabLayoutのindicator)。
制約もあります。たとえば、パララックスはRecyclerView or NestedScrollViewでないと使えないとか。
僕はデザインライブラリを使ってみて思ったことがあります。
「お前ら、デザインにこだわってインタラクションしっかりしたいならちゃんと自前でやれ」
そう案に言われてるのではないか、と。
下位互換の話
OSのバージョンも常についてまわりました。4.4以下のOSだと下位互換のために実装コストが増えます。
- MaterialDesignで重要な「elevation」のプロパティは、5.0以上ではないと使用することが出来ません。
- Activityの画面遷移に伴うアニメーションは、5.0以上ではないと使用することが出来ません。
- FloatingActionButton(FAB, ふぁぶ)は標準コンポーネントではありません(今はデザインライブラリで一応標準のような立ち位置にいる)。
- RippleEffectは5.0以上ではないと使用することが出来ません。
- etc.
影やFABなら、shapeや9-patchやデザインライブラリを使えばなんとかなりました。
でもアニメーション周りは相当きつい部分が多く、時間的に実現不可能なものが結構ありました。
あと、もし2系のOSに対応するとかなったら、言わずもがなですよね。
ここは、要件定義というか、最初の段階で対象OSを絞ってしまうしかありません。
サービスに依っては、切れないことも多々あるので、無理はできないところです。
あとは、機種依存の問題にも悩みました。たとえば色彩が端末ごとにぜんぜん違ったりとか。
メンバーとこまめに実装上の話をする
絵に描いた餅にならないように、こまめに実装上可能かどうかを確かめます。
使えるリソースも有限です。限られた時間、限られた予算でプロジェクトは行われなければならないからです。
まずは動くものを作ることが先決、というのが普通のあり方だと思います。
完璧にデザインを再現することが、そのコストに見合っているかどうかも議論されます。
その上で、最適解を目指さなければなりませんでした。
特にデザイナーさんとは予めよくコミュニケーションしておくことで、手戻りを少なくすることが出来ます。
それでもMaterial
僕は別にMaterialDesignを無理して適用する必要はないと思います。サービスが表現している世界観にそぐわないなら、それは適用すべきではないはずです。
でも、その世界観に合うようにこのデザイン言語をアレンジすることができたら、というか、出来なくてはいけないと思っています。
そう思うのは、Googleの用意した世界の上にのっかって仕事をしているからだし、そうである以上彼らの世界観に従うのがマナーだと思うからです。マナーだし、多分そうすることで良いアプリが出来上がると思っています。
原理主義を超えて
ただガイドラインに従うだけであれば、割とすぐ誰でもできると思います(実装はまた別として)。
何故かは簡単で、そういうふうに作られているからです。やってみればわかります(実装はこの限りではない)。
とても事細かに規定があるので、素直に守るだけで一定のクオリティが担保されます(繰り返すが実装はry)。
デザインのためのフレームワークとも言えるかもしれません。本当にすごくよくできてる。
けど、それじゃ面白く無いですよね。
ガイドラインを順守するのは、考えなくていいからラクです。でも、ガイドラインが足かせになってしまうことがあるとしたら、それはデザイナーのロジックを優先していいと思います。
(基本的に非推奨なことは、やめたほうがいいと思いますが...)
MaterialDesignのアワードを取ったアプリって、どれも独自に解釈をしているふうに見えます。
そういうところを狙って行きたいな、と思うわけです。
とかなんとか書いていたら
UI GRAPHICS ―世界の成功事例から学ぶ、スマホ以降のインターフェイスデザインという本が12/17に発刊されました。
その中で、THE GUILD の深津さんがMaterialDesignについて寄稿されています。
とても深い考察が書かれているので、ぜひ買って読んでみてください！(アフィではないです)
ほんの少しだけ引用すると、
たしかにマテリアルデザインそのものは優れた設計コンセプトである。だが、皆がマテリアルデザインに厳格に従ってしまえば、新しいデザインやインターフェースは生まれにくくなる。また、たとえ新しいものが出ても、移行や普及が難しくなってしまうだろう。フレームワークに乗りつつも、必要に応じてフレームワークから外れることが今後のデザイナーの課題となる。
これだけ引用しても全体像わからないので、興味ある人は買って読んで下さい。MaterialDesignに関する記事の中で、今までで一番感動した記事でした。この本の紹介に記事変更しようか迷ったくらい良かったです。
さいごに
まだまだ、Androidのアプリのデザイン世界は豊かになる余地があると思ってます。僕もまだまだ若葉マークです。
Google純正アプリのコピーですら大変なのに、自分たちのオリジナル解釈するとなると、実装のハードルはさらに上がります。
大変です。
大変だけど、頑張りたいです。
以上。
明日は弊社の @mariokada がお送りします。