2023年が終わりますね。めっちゃ寒いです。
2023年は色々とあった年でした。かつ、来年以降はこれまで以上に色々とありそうな予感に包まれています。
そこで現時点までに調べたり考えたりした、Material Designについてのあれこれをまとめておきます。 来年からは、今までよりアプリケーション開発に関わっていきたいな〜、みたいな気持ちでいっぱいです。
はじめに
このブログでは、Material Designの登場(2014年中旬)から現在(2023年末)までを、一通り確認します。
最初に、Material Design 1 (M1)の登場からMaterial Design 2 (M2)まで。その当時の状況を、記事などから補足しながら、整理していきます。 次に、この整理を踏まえた上で、M2からMaterial Design 3 (M3)への変遷を確認します。
ブログを通して達成したいことは、M1やM2への理解を2023年末の視点から深めることです。 というのも、M3は明らかにこれまでの経緯を踏まえて説明されます。しかし、AndroidマニアなAndroidエンジニアならまだしも、なかなかMaterial Designが解決しかった課題感などは把握しにくくなっており、特にM1やM2で何が達成されていたのかは把握できません。
次の文章は、Material Designのフッターに記載されている、Material Designのコンセプトです。 このコンセプトに対して、適切な批判の眼を向けるためにも、時代的な背景をベースにMaterial Designを把握することを目指します。
Material Design is an adaptable system of guidelines, components, and tools that support the best practices of user interface design. Backed by open-source code, Material Design streamlines collaboration between designers and developers, and helps teams quickly build beautiful products.
ブログの終わりで、新ためてコンセプトを確認します。 はじめとおわりで、コンセプトに対する印象が変わっていれば、何よりも嬉しいです。
AndroidとMaterial Design
筆者の理解では、Material Designの構成にはAndroidのプラットフォームとしての特徴が色濃く反映されています。 言い換えると、iOSやWebではなく、AndroidアプリケーションをAndroid SDKを使って開発する体験に、近いものがあります。
そして、Material Designの初期(つまりM1)は、それ以前のAndroidのデザインの影響が見て取れます。
この章では、Androidのシステム的な要素(Theme)とMaterial Design以前のAndroidデザイン(Holo Theme)を紹介します。
Theme
Androidには、アプリケーションや画面ごとにUIに関する設定を行うThemeという仕組みが存在します。*1
API levelは1となっており、本当の最初から存在するクラス(概念)です。
This class holds the current attribute values for a particular theme. In other words, a Theme is a set of values for resource attributes; these are used in conjunction with
TypedArrayto resolve the final value for an attribute.
クラスではなく概念としての解説は、次の公式ガイドを確認いただければと。 内容は逐次更新されており、執筆されている情報は最新のものになっています。このため、内容は最新の知見が盛り込まれたものに更新されており、リリース当初のものとは全く異なっています。
ここでは、テーマが実現している内容(以下の引用部)に注目してください。
テーマとは、色、タイプ、シェイプなどのスタイルまたは属性のセットで、ユーザーのモバイル デバイスや大画面デバイスやアプリ内エクスペリエンスに影響します。
混乱しやすいThemeとStyleについて。
テーマの説明にも出てくるのですが、AndroidではThemeとStyleの2つの概念を扱います。
すごい簡単にまとめると、ThemeはStyleを組み合わせて構築されます。この仕組みは、次のドキュメントで紹介されるように「ベースとなるThemeを選び、任意のStyleを差し替える」運用を実現します。
Android のスタイルとテーマを使用すると、ウェブデザインのスタイルシートと同様に、UI 構造と動作からアプリデザインの詳細を分離できます。
スタイルとは、単一の View の外観を指定する属性の集まりです。スタイルでは、フォントカラー、フォントサイズ、バックグラウンド カラーなどの属性を指定できます。
テーマとは属性の集まりであり、個々のビューだけでなく、アプリ、アクティビティ、またはビュー階層に適用されます。テーマを適用すると、アプリまたはアクティビティのすべてのビューで、サポートされているテーマの各属性が適用されます。テーマでは、ステータスバーやウィンドウ バックグラウンドなど、ビュー以外の要素にもスタイルを適用できます。
Androidの開発においては、LightとDark Themeの切り替え対応が、最もThemeを意識しやすいものではないでしょうか。
仕組みがわかっていれば簡単に実装できるものなので、Themeの仕組みが理解できていると、次のダークモードに対応するための手引きがざっくりと把握できるようになります。
なお、次の注意書きは、Themeの特徴を抑えるために重要です。
Themes and styles
Avoid using hardcoded colors or icons intended for use under a light theme. Use theme attributes or night-qualified resources instead.
少し話が飛ぶのですが、Themeは一種のデザイントークンだと、筆者は認識しています。
もともとが、プログラム上でViewに関するプロパティを統一的に制御するための仕組みとなります。このため、結果としてViewを構築する最小の単位になっており、ほぼデザイントークンではないかなと。
デザイントークンについては、Adobeのサイトから定義を引用します。
デザイントークンとは何か？
デザインシステムにおけるトークンは、UI要素のスタイル、たとえば、色、タイポグラフィ、パディング、シャドウなどの値を表します。デザイントークンはデザインシステムを構築する最小単位とみなすことができ、Web、モバイル、デスクトップのすべての環境で利用可能な一貫したスタイルを生み出すために使われます。
一方で、AndroidのThemeは、Androidの仕組みに載った仕組みです。 このため、Androidが持つ構造上の問題の影響を受けます。
一例を挙げると、TextViewがButtonの親になっている問題があります。 現代の感覚から見れば、当然、TextViewとButtonは同じ階層に並ぶViewです。 しかし実装上は、継承関係にあります。
このため、Android ViewではTextViewに与えた影響がButtonに及ぶ関係性になっており、意図しない影響が及ぶことがあります。*2
2023年現在、AndroidはAndroid Viewによる実装からJetpack Composeによる実装に置き換わりつつあります。 Jetpack Composeはゼロベースで実装されたシステムであり、Android Viewにおける様々な知見が生かされています。
Jetpack Compose を使用すると、デザイン システムを簡単に実装できます。また、テーマ設定やコンポーネントなどにより、一貫性のあるデザインをアプリに施すことができます。
とはいえ、Jetpack ComposeはMaterial Design以後のシステムです。今回は、Material Design以前のThemeを確認します。
*3
Holo Theme (Android 4 ~ Android 5)
Android 4.4以前のバージョンについて書こうとすると、正直なところ紙面が足りません。 本来はAndroid 2系と3系についてを整理した上で、おおよそAndroid 4.0から導入されたと表現しても誤解のないHolo themeについて書くべきなのですが、今回は4.0未満のバージョンについては割愛します。
Andorid 4系は、スマートフォン向けに開発されていた1系から2系と、タブレット向けに開発された3系が統合されたバージョンです。
Ice Cream Sandwichと名付けられており、多くの場合ICSと省略されます。
公式の紹介ページには明記されていないのですが、当時の記事を探すと、Holo themeについて紹介されている投稿があります。
Android 4.0 showcases the Holo theme family, further refined since its debut in Android 3.0. But as most developers know, a new system theme for some Android devices isn’t a new or uncommon event. For developers new system themes mean more design targets for their apps. Using system themes means developers can take advantage of a user’s existing expectations and it can save a lot of production time, but only if an app designer can reliably predict the results. Before Android 4.0 the variance in system themes from device to device could make it difficult to design an app with a single predictable look and feel. We set out to improve this situation for the developer community in Ice Cream Sandwich and beyond.
android-developers.googleblog.com
ちょっと長めに引用しているのですが、気合を入れて読んでもらうと"But as most developers know"以下の文章に違和感を感じるかもしれません。*4 この迂遠な表現は、次のテック記事ではより直接的に記述されています。
A new unified UI toolkit to help developers match ICS's new look and feel, including a new requirement for hardware-accelerated 2D drawing for UI effects on Android 4.0 devices. That includes a new "Theme.holo" theme that developers can use to guarantee a consistent UI across different devices (in other words, if a developer uses this theme, an OEM can't change the look and feel of the app).
※ 太字は筆者による強調
実際にどのような変更が行われていたかを調べようとしたのですが、検索で見つけることができませんでした。。 筆者もAndroid 4未満をターゲットにしたソースコードを触ったことはあるのですが、駆け出しの頃だったので、Themeに関して対応を行った覚えがありません。有識者の方がいれば、お伺いしたい次第です。
今回Holoを紹介したのは、HoloがAndroid 4系における標準的なThemeであることが、その後のThemeのあり方に大きな影響を与えているためです。
現在では、メーカーごとのThemeに対応する実装は、まず見かけません。
つまり、2つのメーカーが異なるAndroid端末上でアプリケーションを実行したときに、Themeが異なり見た目が変わる状況が当たり前ではありません。メーカーがプリインストールしているアプリケーションでは異なっていると思われますが、それは別のアプリケーションであるからで納得できる範疇にあります。
プラットフォームにおける標準的なThemeが提供されることで、アプリケーションごとのThemeは定義しやすくなります。つまり、メーカーごとのThemeというオリジナリティが高い環境よりも、メーカーによらないThemeが提供される方が、各アプリケーション開発者にとっては自由度が高くなると言えます。*5
この共通的な基盤を作ることで、逆に多様性を確保する方向性は、その後のデザイン基盤の文脈に色濃く残ることとなります。一見すると当たり前ですが、Holoが標準的なThemeとして提供されたことで、現代では当たり前の話になっているという大きな功績なのではないかなと思います。
Material Design (Android 5~)
ついに、Material Designの登場です。
紹介動画は今見てもワクワクしますね。 今見るとちょっとこなれていない印象はありますが、十分に新しい印象はあるのではと思います。
Material Design (M1)はGoogle I/O 2014で発表されました。同年にリリースされるAndroid 5系 (Lollipop)から、導入されることもアナウンスされています。 なおAndorid 5は2014年11月にリリースされています。そのほかのGoogle製アプリでも、2014年末ごろからM1の対応がなされています。
当時のAndroidエンジニアの受け止め方としては、cookpadさんのブログが参考になります。 というか、当時の状況で広く見通しているブログはすごいです。かくありたい。
小さな画面で膨大な情報を扱うAndroid Wearにも、車の運転に注意力の大半を持っていかれるAndroid Autoにも、OSでありブラウザでもあるChromeでも、ユーザが迷わないためにプラットフォームやデバイスを超えてデザインをする必要があります。各プラットフォームがバラバラにデザインされるとユーザが混乱してしまうので、Material Designという統一的なデザインガイドラインを定めて、ユーザは一つのコンテキストを知っているだけで操作できるようにしようとしているのだと思います。ガイドラインを読むとMaterial Designは、インタフェースはシンプルに、タイポグラフィはどのデバイスでも見やすく、クロスプラットフォーム・マルチデバイスを意識して設計されているということが分かります。
M1とHoloの比較をなされているブログもあります。 もう10年近く前の環境になるため、手元で比較させることも容易ではありません。インターネットで検索すると、過去の情報が見つかるのは、素晴らしいなと思います。
なお、M1とHoloどちらを利用するべきかは、2016年のredditに話題が上がっていました。 コメントを見る限り、Materialを支持する声が多そうです。
https://www.reddit.com/r/Android/comments/4tva3j/holo_vs_material/
Android 5系以後では、M1が開発するThemeのベースになっていきます。*6
ただ、直接Materialライブラリを参照している記憶はないかもしれません。というのも、サポートライブラリ(appcompat)を介して、Materialライブラリを参照しているためです。
サポートライブラリは、例えば新しい API 向けの下位互換性を提供します。
例えば、Android 7以降で利用できるRecyclerViewのメソッドを、Android 6系以下でも利用できる、といったものです。アプリケーションの開発者がコード上でif分岐なしで機能を利用できるため、コードの複雑さを抑えることができます。
DroidKaigi 2016の基調講演が、サポートライブラリとはなんなのかを、最も明確に説明しています。
Themeの指定には、Theme.AppCompatを利用します。
Theme.AppCompatの中身を紹介するのは大変なのでざっくり端折ると、Android 5以降では(v21以降では)Widget.Materialライブラリを参照しています。それ以前のバージョンでは、様々なプロパティの設定を駆使して、M1っぽくThemeを構築しています。
こういった事情のため、Android 5以降のアプリケーション開発では、Material Designを常に意識する必要があります。
Androidアプリケーションを開発するためには、Themeを利用する必要があります。Android Viewによるアプリケーションは、Themeに定義されているデザイントークンを利用することになるので、その考慮が常に必要です。
このThemeのベースが、Android 5以降ではMaterialに統一されました。
Androidプラットフォームにおける標準的なThemeがMaterialになったということは、標準的な仕組みを利用する大半のケースで、Materialの影響を受けることなったことを意味します。
2014年ごろの傾向
M1は2014年にリリースされたわけですが、ほかのプラットフォームの状況も簡単に確認しておきます。
この頃の最も大きなGUIにおけるインパクトは、Windows 8のModern UI (MetroUI)でしょう。 2013年10月にリリースされたWindows 8に搭載され、Windows Phoneでも利用されました。*7
iOSにおいては、フラットデザインが取り入れられたiOS 7が2013年9月にリリースされています。
ある意味で、モバイルデバイスにおけるデザインの方向性が定まってきた頃、と言えます。
Material Design 2 (2018~)
Google I/O 2018でMaterial Designのアップデートが発表されました。 以後、当時の表記としてはMaterial Design 2、このブログではのちのバージョンと並べるためにM2と表記します。
Google I/O 2018 では主に次の3つの発表がありました。
1 : Material Theming : よりカスタマイズしやすいデザインシステム
2 : Material Tools Suite : Material Theme Editor, Gallery 等のツール群
3 : Material Components : Material Design を実装する上で利用可能な、Android、iOS、Web、Flutterのライブラリ
上記noteにまとまっているように、Google I/Oではいくつかの要素がまとめて発表されました。 M1との比較で書くと、それぞれ次のようにまとめられます。
- よりブランドに合わせたカスタマイズがしやすくなった
- エンジニア以外の関係者が利用しやすいツールが増えた
- Android以外のプラットフォームで利用しやすくなった
これらを俯瞰してみると、M2がM1よりもアプリケーションのデザインシステムとして採用しやすくなっていることがわかります。 とりわけ、Material Themingはある会社のMaterial Design themeを作る仕組みとして、強調されています。
次のブログでは、実際にGoogleのプロダクトに対して、作成したMaterial Themingを適用している様子を紹介しています。 Googleのプロダクトも、Googleが作ったMaterial Themingを利用しているだけで、Material Designを採用している1つであるというアピールですね。
狙いについては、率直にMaterial Designの統括者が語っています。 Material Designの話をすると、多くの場合に聞こえてくる「アプリがGoogleっぽくなる」といった声に対応するためのもの、と捉えるべきでしょう。
新ツールの狙いは、開発者がボタンやナビゲーションに関するGoogleのMaterial Designシステムを守りつつ、ブランドの個々の独自性を反映する特徴を追加できるように支援することだ。
~~~
Material Designは自らの成功に犠牲者になってしまったとの考えを、GoogleのMaterial Design統括者であるMatías Duarte氏はThe Vergeに語った。そして、開発者がそれを「金科玉条」のように扱うようになり、同じような外観のアプリがあふれる事態を招いてしまったという。
M1がAndoridアプリケーションのためのものであったのに対し、M2はアプリケーションのためのものであると言えます。
筆者の印象として、Material DesignはAndroidエンジニアに好意的に受け入れられました。 一方で、Material Designに対するAndroidエンジニア以外の関心は低く、Google製アプリケーションの見た目に似たものとして捉えられていました。*8
この状況では、Androidアプリケーションに対してMaterial Designが適用されることはありません。 というのも、多くの企業や多くの開発チームにおいては、Androidアプリケーションのデザインよりもアプリケーションのあるべきカタチの方が重要だからです。
この状況に対する回答として、Material ThemingによるブランドごとのThemeの提供、ならびにAndroid、iOS、Web、Flutterのライブラリがリリースされました。 また、Androidエンジニア以外のステークホルダーとコミュニケーションするためのツールとして、GalleryやMaterial Theme Editorが提供されるようになります。
また、Material Designチームとして、ブログを開設し情報発信を始めるようになりました。*9 このあたりが、M2がリリースされた頃の大まかな状況です。
Material Design
ようやく本題です。 これまでに、Material Designの登場 (M1)から、Material Designのカバー範囲を含めた発展 (M2)を確認してきました。
ここからは、Material Designそのものを再確認していきます。
Material Designの思想
まず、Material Designとは何なのか。一番知りたいことになりますよね。 この話題については、DroidKaigi 2019のセッションがベストです。
筆者も時々見直しています。
セッション内で引用されている記事が、下記のリンクです。時間が許すようであれば、セッションを見る前に見てくと、理解が深まりやすくなります。 万が一消えてしまった場合には、Web魚拓もご確認ください。
introducitonはこちらです。
このため、エッセンスが下記のページに残っているのみです。前述のインタビュー記事の方が、より思想を確認しやすいでしょう。
もし、気合いで動画を見れる方がいれば、そのものずばりの動画があります。冒頭10分ほどを視聴いただければと。 2014年の動画なので、青写真の話になっていますが、それだけにコンセプトはわかりやすいと思います。
DroidKaigi 2019のセッション中に語られるべきことは語られているので、書くべきことが見つかりません。 セッションに感謝です。
Material Designとの付き合い方
同カンファレンスで行われた、Material Designとの付き合い方について。 当時はSketchでアプリのデザインが行われていた覚えがあります。歴史ですね。
現在では、figmaで利用できる様々なツールが提供されるようになっています。
この記事では、今改めて読むと、M2と開発者やデザイナーの関係について多くのことを語っています。 全文を通して読むのと、抜き出して読むのとでは印象が異なるため、できれば全文読んでもらえればと。とは言え、サッと確認するには辛いかと思うので、特に重要そうな箇所を抜粋します。
”We spent two years telling people ‘this is how to make Material yours,’” Duarte says, “and it didn’t work.” But he doesn’t blame developers. The problem is that Google didn’t provide the right tools. Specifically, he believes Google’s guidelines didn’t separate out the styling of the button from its function. Google wants apps to work like other Material Design apps, but it never meant for all Android apps to look like each other.
デュアルテ氏の発言。M1をそれぞれの企業向けにカスタマイズする方法を紹介してきたが、全く成功しなかったことを述べています。 機能とスタイリングがガイドラインで分割されていない点は、Material Designらしいユーザー体験と、Material Designらしい見た目の違いが、M1を採用したチームに理解されなかったことを指していると思われます。このため、適切なツールの提供が重要であると考えているようです。
Rachel Been, the design lead for the new Material Design, says that the tools for creating design systems based on Material are just as important as the core design guidelines themselves — if not more so. “We had to create the full infrastructure,” she says. So there are palette tools and font tools to help designers create a version of Material Design that feels native to their brand but also comprehensible to users.
レイチェル氏の発言。Material Themingとしてリリースされた、Material Designをそれぞれのアプリケーションが取り入れるためのツールについて述べています。
full infrastructureと表現していることからも、力を入れたツールを作らなければ、Material Designを取り入れたチームらしいMaterial Designが運用されないであろうと考えていることが伺えます。
Duarte describes it as “a design system for making design systems.” So the original version of Material Design had a single theme that was getting applied to all apps with minimal customization. The new Material Theme tools are meant to help developers create their own design systems — systems that are nevertheless based on Material Design principles.
デュアルテ氏の発言。M2をデザインシステムを作るためのデザインシステムと表現しています。独自のデザインシステムを、Material Designの原則に基づきつつ、作る世界観を持っていることが伺えます。
デザインシステムの2つの強度
デザインシステムには、2つの評価軸があります。ひとつはデザインとしての強度、もうひとつはシステムとしての強度です。
Material Designに対する評価は、主にデザインとしての強度に寄ったものです。 つまり、「Googleっぽさがある」や「波紋がiOSに合わない」などの、プロダクトにMaterial Designを組み込んだ時の違和感です。
一方で、Material Designが他のデザインシステムに比べて優れている*10のは、システムとしての強度です。 デザインシステムを作るためのデザインシステムであるMaterial Designは、この観点が強く意識されています。
デザインシステムにおける、システム部には、次のような機能が求められます。
- デザインを分解し、高速に再構築する機能
- デザインを対応するプラットフォームに、高速に適応させる機能
- デザインしたい項目ににおいて、不足している要素を補う機能
多くの場合、評価されるのは1つ目の観点です。というのも、デザインを起こし適用する中で、最もペインとなるのが1つ目の高速に再構築する機能であるためです。
一方で、2つ目と3つ目は軽視されがちです。いくつかのデザインシステムに関する発表を見る限り、2つ目はエンジニアがデザインの適用を頑張るという形で実現されています。 3つ目としては、design languageやaccessibilityとしてのデザインシステムが挙げられます。この観点をカバーしようとしているのは、OSを提供する企業が出すデザインシステムぐらいしか、存在していないように思います。
2018年以後、毎年Material Designの開発チームは、開発ツールやブログによる情報発信を続けています。 しかし、市場を見る限り、それらのツールはほとんど利用されていません。
こうした状況の中、2021年にM3がリリースされました。
M2からM3へ
Google I/O 2021にてM3が発表されました。 M3は変更点が大きく、一見すると、全く新しいデザインシステムが登場したように見えます。
しかし分解していくと、既存の延長線上にあるものと、新規に追加されたものが綺麗に分かれています。
- 特定のプラットフォームベースの概念の抽象化
- 新たなデバイス、ディスプレイ、環境への適用
- デザインシステムを支えるツールの発展、強化
特定のプラットフォームベースの概念の抽象化
M3では、M2からのアップデートとして、特定のプラットフォーム依存の概念がより抽象的な概念に更新されています。 最もわかりやすいのは、Typographyです。
M2では、TypographyはHTMLベースの分類になっていました。H1やH2、bodyなどでテキストの装飾を表現しています。
M3ではオリジナルの分類に更新されました。HeadlineやBodyなどの要素と、それぞれにLearge/Medium/Smallの種別を行っています。 命名から一致する箇所と、そうではない箇所があると思われますが、マイグレーション用のブログ*11を見ることで移行は比較的容易に行えるはずです。
筆者としては、この対応により、M3がプラットフォームに対して中立的な概念になったと評価しています。 H1やH2などの表記は、HTMLの文脈があるため、認識を合わせやすいものです。一方で、「AndroidアプリケーションにH1の概念をどう持ち込むか」のような、もともと概念が存在しないプラットフォームにどのように持ち込むか、という問題が生じます。HTMLの文脈がある以上、なんとなくで当てはめることもできません。
Material Designは、前述の通り、アプリケーションのデザインシステムのためのデザインシステムです。 このため、Material Designそのものが概念を定義する方が、それぞれのアプリケーションのデザインシステムとして運用しやすくなります。
同様の領域としては、強いて言うとShapeが該当するように思います。 四つの角を個別にいじることはどのプラットフォームでもできるでしょう。ただそれらを実現することを考えると、実装が容易なのはAndroidだけだったのではないかな……と思います。
新たなデバイス、ディスプレイ、環境への適用
Designing and building for more devices
Google I/O 2021では、大きなディスプレイに対応するための考え方を紹介するセッションが開かれました。 M3の特徴の一つに、スマートフォンよりも大きなディスプレイへの対応、つまりChromebookやTabletへの対応があります。
2014年に発表されたM1においても、タブレットへの対応は検討されていました。しかし、市場においては、Androidタブレットは全く存在感がない状態が続きます。 結果としてM1やM2の文脈においては、スマートフォン向けの対応のみにフォーカスされていました。
2020年は、コロナ禍によりChromebookの出荷台数が大幅に増加した年です。 様々な分野において、リモートで行われる必要性が生じ、そのツールとしてChromebookやTabletの市場が大きく伸びました。 こういった端末では、特に制限をかけていない場合、ディスプレイを広く使う状態でAndroidアプリケーションが動作します。
M3は、こういったスマートフォンよりも広いディスプレイで動作することが実際に起こるようになった、その後にリリースされています。 このため、M2に比べると、非常に強く様々なデバイスやディスプレイで動作するデザインシステムであることを強調しています。
M1からM2においては、Material Designを採用しているのは、主にGoogle製のアプリケーションです。 Material Design Componentsを採用したアプリケーションもありましたが、決して主流であるとは言えません。
この状況を変えたのは、Flutterです。 Flutterは、そのUIコンポーネントをMaterial Designの定義に則って実現しています。 UIコンポーネント群を作る際に利用する概念として、Material Designを採用している、といってもいいかもしれません。 結果として、Flutterが広まれば広まるほど、Material Designはより多くの環境で動作することが求められることになります。
Build for any screen
2021年3月時点で、AndroidとiOSに加え、Webも正式なサポート対象でした。 このためFlutterの採用例が増えていくと、Material DesignがChromebookやAndroid Tablet、iPadなどに加えて、デスクトップPC上のブラウザで動作することが見込まれる状況にあったと言えます。
デザインシステムを支えるツールの発展、強化
M1からM2への反省点の1つに、ツールの提供の問題がありました。 M3では消極的なツールの提供から、積極的なツールの提供に方針を切り替えている、と筆者はみなしています。
M2からの延長線上にあるツールの提供としては、Compose Material CatalogやMaterial Symbolsの提供があります。 これらのツールは、M2と同様に、エンジニアやデザイナーが任意のタイミングで活用することができます。
他方で、M3はM2に比べると、明らかに意見を強く主張している箇所があります。色の定義です。
開発者が色をカスタマイズする機能が減り、利用者が色をカスタマイズする機能が追加されました。 もちろん従来通りの運用も可能なようになっていますが、これは従来の方向性からすると異質な印象を受けます。 つまり、M2においては企業ごとのブランドを表現しやすくする方向に進んでいたのに、M3では色によるブランディングをしにくくする方向に進んでいます。
これは、下記のブログで明らかなように、アクセシビリティを確保するためのM3の思想の表れです。 つまり、M3はブランドのカラーをアピールする機能を持たず、代わりに様々なユーザーの視認性が確保される機能を持っています。 ソフトウェアがどの色を使うべきかを判断することで、適切なアクセシビリティを確保するのが、M3のカラーシステムです。
この方向性は、現在策定が進んでいるWCAG3のコントラスト基準と合致していると、筆者は認識しています。
この方向性は、既存の文脈からすると、非常に違和感の大きな箇所になると思われます。 しかし、生活に支障のない程度の色弱を持っている筆者からすると、デザインシステムとして備えているべき機能であるようにも思えています。
上記ブログで紹介されているように、M3では、様々なコンポーネントが見やすいものであるように意思決定されています。
Material Designの思想にあったように、Material Designは、多くのアプリケーションのベースとなることを目指して開発されています。 この文脈からすると、ユーザーにとって見やすく判断しやすことは、最も重視されるべきことなのかもしれません。
おわりに
ブログでは数度書いているのですが、デザインシステムという単語は、曖昧な定義づけがなされていることが多くあります。
筆者は、基本的にAndroidやiOSアプリケーション開発を念頭に置いた状態で、意見を表明しています。また、「1つのデザインシステムをベースとした時に、どのような開発を行うと、効果的な運用がなされるのか」に主な関心があります。このため、ある意味で、企業やチームがアプリケーションを通じてブランディングを行う手段としての、デザインには関心があまり向いていません。
このような筆者から見た時の、本ブログのまとめを最後に書いておきます。
M1とM3の対比
M1がリリースされた2014年と、M3がリリースされた2021年は、案外似ている状況にあります。 とりわけ、ディスプレイサイズがより多様になることが期待されているという意味では、2014年の想定が2021年にようやく実現したと言えます。
この意味では、M3はM1からの発展というよりも、再度Material Designがリリースされたようなものなのかな、と思っています。 もちろん既存の資産や知見の質と量は、M1の頃からは比較になりません。一方で、Material Designが一般にあまり見向きされていなかったという意味では、新たにMaterial Designを開発者たちが検討し始めたところ、と言えるのではないかなと。
Jetpack Compose向けのライブラリや、Flutter向けのコンポーネントがM3対応が2023年にようやく纏まりました。 2024年こそが、Material Designについてゼロから学び直す年になるかもしれません。
ユーザーのためのアプリケーション
筆者の理解では、ダークモードが普及した現在では、色によるアプリケーションやサービスのブランディングは難しくなっています。 とりわけ、時間帯によってディスプレイの色が変わる最近の端末においては、アプリケーションが発色をコントロールすることは不可能です。 紙に印刷するのではなく、ディスプレイで表現されるアプリケーションでは、色の効果を見直す必要があるように思えています。
こういった状況を踏まえた時に、M3は色の問題をコードで解決することを提案しています。 自分の開発しているアプリケーションを振り返ってみると、確かに、技術力や余力の不足を言い訳にして、見やすいアプリケーションを開発できていません。しかし、これはアプリケーション開発のあるべき姿ではないように思います。
これからはM3を活用してみたという発表がでてくるといいなと。 1人のエンジニアとしても、努力していきたいなと思います。
Material Designのコンセプト
改めて、Material Designのサイトのフッターにある、コンセプトを引用します。
Material Design is an adaptable system of guidelines, components, and tools that support the best practices of user interface design. Backed by open-source code, Material Design streamlines collaboration between designers and developers, and helps teams quickly build beautiful products.
いかがでしょうか? ブログを書き上げた筆者としては、これこそがDesign Systemの目指すものであるなぁ、と感じます。 一方で、目指すものの大きさに対して、関係する人々へのアプローチに苦心し続けているシステムであるとも思います。
非常に長いブログとなりました。 ここまでお付き合いいただき、ありがとうございました。良いお年を。
*1:ここでは、Android ViewのThemeを扱います
*2:よく知られている問題なので、対応もなされやすいものではあります
*3:Jetpack ComposeにもThemeが存在しますが、それはMaterial DesignにおけるThemeです。 https://developer.android.com/jetpack/compose/themes?hl=ja
*4:違和感を感じてもらえること自体が、この試みが成功したことを示していますね。
*5:メーカーごとの差分に対応することで手一杯となり、大切なオリジナリティを表現できなくなるとも言えます。
*6:Holoの後の仕組みなので、納得感があるのではないでしょうか?
*7:されるはずでした。
*8:2023年末現在でも、大きく変わっていないと思います。
*9:Android Developersを読むのは、Android開発者ぐらいですからね。
*10:もしかしたら、優れすぎているのかもしれません
