こんにちは、株式会社スマートバンクでアプリエンジニアをしているロクネムです。
みなさんはDynamic colorという機能をご存知でしょうか？ Dynamic colorとは、ユーザーの設定した壁紙における優位な色を元にパーソナライズされた配色を生成してアプリへ適用することができる、Android 12から提供を開始した機能です。 色という非常に主観的な要素をカスタマイズ可能にすることによって、ユーザーの嗜好をより尊重するデザインの提供を実現しています。
本記事では、このDynamic colorという機能について、どのようなアルゴリズムをもとに優位な色を抽出し、そこからいかにして調和の取れたカラースキームを生成するのか、内部の仕組みを徹底解剖しながら説明していきます。 そして最後には、Dynamic colorをアプリのUIへ適用する上での具体的なデザインフローについてもご紹介します。
※ こちらの記事は、DroidKaigi 2022にて発表させていただいたセッション『Anatomy of Dynamic color』について、内容を書き起こしたものとなっております。
Dynamic color導入の背景
Dynamic colorの機能について詳しく見ていく前に、まずはそもそもどのような背景を持って導入された機能であるかについて説明をさせてください。
この背景について説明するにあたって、Material Designが発表された2014年にまで時を遡ります。 当時のMaterial Designの掲げるビジョンは「テクノロジーを誰にとってもシンプルで美しいものにし、モバイルとWebを横断する体験の合理化を支援する」というものでした。
しかしそこから数年の時を経て今日に至るまでテクノロジーは成長を続け、さまざまな形で多くのデバイスが我々の生活の至るところに現れるようになりました。 それに伴い、ユーザーも自分のデバイスにより高い表現力と操作性を求め始めます。 このような個々のユースケースやユーザーのニーズに対して、画一的なアプローチによるデザインでは、次第に対応できなくなっていきました。
そこでGoogleは、あらゆるスタイルやニーズ、そしてデバイスに対応する生き生きとしたデザインを追求する Material You を掲げました。 2021年5月18日のGoogle I/OでMaterial Youは発表され、Dynamic colorはその中核をなす機能として取り上げられました。
さらにこのMaterial Youを掲げてアップデートされたMaterial Designは Material Design 3(M3) として発表され、同時に2014年に発表されたものをMaterial Design 1(M1)、2018年に発表されたものをMaterial Design 2(M2)と呼ぶようになりました。
概念をまとめると、Material YouはM3の一部であり、さらにDynamic colorはMaterial Youの一部ということになります。
Material Designの観点から見るDynamic color
Dynamic colorの機能についてMaterial Designの観点から説明を補足すると、Dynamic colorは生成した配色をもとにM3のカラースキームを構築します。
この構築されたM3のカラースキームが、そのままアプリへ適用されるというわけです。 言い換えると、Dynamic colorに対応させたいアプリは、M3のカラースキームに対応している必要があります。
コントラストの十分な配色の動的な生成
Dynamic colorで動的に生成される無数の配色は、どんな色の組み合わせでも十分なコントラストを実現できるような工夫が凝らされています。 このセクションでは、Dynamic colorがどのようにコントラストの十分なカラースキームの動的な構築を可能にしているのか、そのアルゴリズムについて詳しく説明していきます。
WCAGのカラーコントラスト
そもそも、十分なコントラストとはどのような定義になるのでしょうか。 コントラストの達成基準は WCAG(Web Content Accessibility Guidelines) というウェブコンテンツのアクセシビリティに関する世界的な標準となっているガイドラインに、以下のように定義されています。
このように十分なカラーコントラストとは、文字と背景の色の間にある コントラスト比 が十分な大きさに保たれていることを指します。 では、このコントラスト比はどのように計算される値なのでしょうか。
コントラスト比の計算方法
色のコントラストを数値化するにあたって、まずは色相における比較を検討してみます。 色相とは、赤, 青, 緑のような色の違いを表す値です。 しかしこの色相というものは、色覚多様性をもつ利用者によっては、通常とは異なる色みとして知覚されます。このため、有効なコントラストおよび読みやすさは、人によって異なってしまいます。
色覚多様性は非常にさまざまであるため、定量的なデータに基づくコントラストのための有効で一般的な色の組み合わせを規定することは実現不可能でした。 そこで、色覚とは無関係な輝度や明度といった、色によって人間が認識する明るさの違いを利用することで、色覚多様性を考慮することなくコントラスト比を計算することを目指しました。
コントラスト比の計算式
輝度を採用したコントラスト比の計算式は以下の通りです。
L1は明るい方の色の相対輝度を、L2は暗い方の色の相対輝度を表しています。 0.05という値は、相対輝度が0に近い場合や環境光による影響の補正を考慮して追加されたオフセットです。(参考: https://juicystudio.com/article/luminositycontrastratioalgorithm.php)
続いてこの相対輝度はどのように求められるかを見ていきましょう。
相対輝度
相対輝度とは、最も暗い黒を0に、最も明るい白を1に正規化した色空間内の任意の点の相対的な明るさを指します。 モニター等で標準的に利用される sRGB色空間 においては、色の相対輝度は以下のように定義されています。
この式は、緑を明るく感じ、青は暗く感じるというような、光の波長ごとに人間の感じる明るさの強さを反映しています。 そして、このR、G および B は以下のように求められます。
これは何をやっているのかというと、 ガンマ補正 のかかった非線形の色を線形に変換しています。
ガンマ補正
ガンマ補正についても少し説明をさせてください。
例えば、人間が知覚する中間階調の50％のグレーは、実は光の20％しか反射していません。 ガンマ補正とは、この20％を対数的に「カーブ」させることで、人間が50％のグレーを自然に認識できるように補正することを指します。
コントラスト比を計算する安定した基準を作る上で、このガンマ補正によって非線形化された値を線形に戻す必要があるのです。
このようにコントラスト比の計算方法は人間の直感に反しており、非常に複雑なものとなっています。 Googleはより直感的にコントラスト比を計算できるように、正確に輝度を表現する色空間の採用を検討しました。
HSL色空間
輝度を表現する色空間として、 HSL色空間 が挙げられます。 HSL色空間とは、Hue(色相), Saturation(彩度), そしてLightness(輝度)の3つの成分からなる色空間です。
- Hue: 色味を0から360度までの角度で表し、0度は赤を、120度は緑、240度は青を表している
- Saturation: 色の鮮やかさを表し、100%が最も鮮やかな純色となる
- Lightness: 明るさを表し、100%で白、50%で純色、0%で黒となる
しかし、このHSL色空間は1970年代のコンピュータで色を高速に計算するために作られたものであり、人間の知覚を表現する数値として正確とは言い難いものでした。
相対輝度の説明では、光の波長、つまりは色相によって人間の感じる明るさは異なってくるという話をしました。しかしこのHSL色空間の輝度は、この違いを考慮した値となっていないのです。以下の画像は、異なる色を同じ輝度で表示したものですが、グレースケールで表現し直すとまったく明るさが異なってしまっていることがわかります。
さらに、単一の色相における明るさの変化は直線的に表現されていません。以下は色相を固定したHSLにおいて、輝度を一定間隔で上げていった画像です。赤色の画像では左から3番目と4番目の色の違いよりも、2番目と3番目の色の違いの方がはるかに大きく見えます。
また、上の画像をグレースケールで表してみると、赤色と青色で明るさの変化がことなることがわかりやすいかと思います。
HSLを使って「数値上」は区別しやすいように色を使い分けたと思っていても、実際に見てみると区別しにくい色使いだった、ということが起こりえるわけです。
HCT色空間
そこでGoogleは、新しい色空間である HCT色空間 を開発しました。 HCT色空間は、Hue(色相), Chroma(彩度), そしてTone(トーン)の3つの成分から構成されています。
- Hue: 色味を0~360の数値で表す
- Chroma: 色の鮮やかさを0~150の数値で表す
- Tone: 色の明るさを0~100の数値で表し、100で白、0で黒となる
この3つの成分自体はHSLとほぼ同じですが、より人間の知覚的に正確な色空間となっています。
以下の画像は、HSL色空間上では輝度が50と表現されている色を横に並べたものです。 HSLでは色相による色の明るさを表現できていないため、グレースケールしてみると人間の目に映る明るさの違いがわかります。 しかし、同じ色をHCT色空間上で表現してみると、トーンによって明るさを正しく数値化できていることがわかります。
HCT色空間は、アクセシビリティの基準を満たすことをより簡単にします。 HCTは、コントラスト比という直感的でない指標を使う代わりに、単純な明るさの差、つまりHCTのトーンの指標を用います。複雑な計算をすることなく、トーンの数値が十分に離れている色を選ぶだけでコントラストが保証されるというわけです。 例えば、WCAGのコントラスト要件である4.5:1のコントラスト比を満たすためには、背景とのトーンの差が50以上にする必要があります。3:1のコントラスト比の場合、トーンの差は40以上必要です。この原則は、どのような色の組み合わせにも一貫して当てはまります。
このHCT色空間の利用によって、Dynamic colorはコントラストの十分なカラースキームの動的な構築を可能にしているわけです。
Dynamic colorにおけるカラースキーム生成のアルゴリズム
さて、それではいよいよDynamic colorにおけるカラースキーム生成のアルゴリズムについてみていきましょう。
まずは、設定された壁紙画像の連続的なアナログデータを、離散的なデジタルデータとして扱えるように量子化します。 画像中にある何千もの色をHCT色空間上で統合して、より少ない数に減らしていきます。
次に、量子化された各色に対して、非常に暗い色や無彩色のような不適切な色を取り除きつつ、色の占める割合および色の濃度を基準にスコアリングを行います。 ここでもっともスコアの高い色がソースカラーとして選択されます。
余談ですが、もしここで画像に不適切な色しか存在しなかった場合どうなるでしょう。 公開されているソースコードをみると、Google Blueがソースカラーとして選択されるようになっていました。
試しに真っ黒な背景画像を設定してみると、確かに青色を基準としたカラースキームが生成されました。 こういった発見があると少し面白いですね。
さて、話を戻して続いては、この選択されたソースカラーを基準に、Primary, Secondary, Tertiary, Neutral, Neutral Variantの5つのKey colorを作成します。
各Key colorのHue(色相)およびChroma(彩度)は以下のように一定の数値となるように調整されています。
次に、それぞれのKey colorを元に、13のトーンからなる Tonal palettes を生成します。
あとはこの5つのTonal Paletteを元に、M3で使用するカラースキームを構築します。
Material DesignではPrimaryとOn Primaryのように、背景色と文字色が対になって定義されています。よって、これらの色の組みにおいて十分なコントラストを確保するようなトーンをTonal Paletteから選択してカラースキームを構築していくことになります。
例えば以下の画像だと、Primaryの色として選択されているPrimary40 はPrimaryのTonal Paletteからトーン40の色が選択されているということです。対してOn Primaryは Primary と十分なコントラストを保つべくトーンの差が50以上になるように Primary100が選択されていますね。
以上がDynamic colorにおけるカラースキームの動的な生成の仕組みです。 このように、HCT色空間という人間の知覚する色を適切な数値で表現する色空間を導入することで、コントラストの計算を単純化し、正確で一貫したカラースキームの提供を可能としました。
Harmonious Custom color
ここまではDynamic colorの生成するカラースキームにフォーカスしたお話をしてきました。 しかし、実際にアプリへ適用することを考えるとある課題の存在に気づきます。
例えば、スマートホームのアプリでは、照明, 暖房, 冷房などのUIを直感的に表現するために、それぞれ照明は黄色, 暖房はオレンジ, 冷房には青などの色を使用したいケースがあるかと思います。 このような、意味を表す色をSemantic colorと呼びます。
しかし、このSemantic colorとして追加する色はDynamic colorで動的に生成される配色と比べるとやや浮いた印象を与えてしまう可能性があります。 この違和感を排除すべく、Dynamic colorのカラースキームと調和の取れた色合いにSemantic colorを調整する必要があります。 ではどのような調整をしてあげるのが適切なのでしょうか。
例えば、赤やオレンジ, 黄色は暖かさを感じさせる色であるため暖色と呼ばれ、逆に青や緑, 紫は寒色と呼ばれています。 実はこの暖色系、寒色系の色の中にも暖色系と寒色系の色調が存在しています。 以下の画像における左側は暖色系の黄色でややオレンジがかっているのに対し、右側は寒色系の黄色で緑色の影響を受けていることがわかります。
Googleは、Dynamic colorで選択されたソースカラーへSemantic colorの色相を近づけるとより調和の取れたSemantic colorとなることを発見しました。 以下の画像では、緑がDynamic colorによって選択されたソースカラーなので、Semantic colorである黄色を、黄色という色の定義から外れない範囲で緑側に色相を近づけることで調和を取ろうとしています。
このように、Dynamic colorによって動的に変更されたくないSemantic colorについては、ソースカラーへ色相を近づけて調整した Custom color として利用することで、調和の取れたカラースキームを崩さないデザインを可能としました。
Material color utilities
ここまでDynamic colorの機能について一通り説明をしてきましたが、これらの機能を提供する Material color utilities というライブラリがOSSとして現在GitHub上で公開されています。 画像からソースカラーを抽出してM3のカラースキームを生成する機能はもちろん、先ほど紹介したHarmonious custom colorの機能も備わっています。
Androidプラットフォームに限ったライブラリではなく、Dart, TypeScriptといった言語にも対応しており、今後はC/C++, Objective-Cの対応が予定されています。
まだJavaライブラリがPackage化されていませんが、こちらが完了するとAndroidのプロジェクトへ組み込むことが可能になり、コンテンツベースのカラースキームの生成も実現できることが予想されます。
コンテンツベースのカラースキームとは、アプリ内のコンテンツに基づいてカラースキームを生成して適用する機能です。例えば音楽アプリでは、再生中の曲のアルバム画像の色をベースとしたカラースキームを生成して関連するUIへその配色を部分的に反映させることができるというものです。
アプリのコンテンツに由来する色は、人の視覚的, 感情的な体験を高めることが可能です。これにより、Material Youの方針であるパーソナライズされた体験の提供をより促進することができるようになります。
Dynamic colorのアプリへの適用
最後に、Dynamic colorをどのようにアプリへ適用していくのか、その具体的なデザインのフローについて、弊社の開発するB/43というアプリを例にご紹介しようと思います。
B/43
B/43（ビー ヨンサン）は、チャージ式Visaプリペイドカードと家計簿アプリがセットになった「家計簿プリカ」サービスです。
B/43にはひとりで使うマイカードとふたりで使うペアカードの2種類のカードが存在しています。
マイカードとペアカードどちらも有するユーザーの場合は、ドロワーから表示するカードを切り替えることができるようになっています。
それでは、このB/43アプリにどのようにDynamic colorを適用していくのかみていきましょう。
Material Design 3対応
Dynamic colorに対応するとはつまり、M3のカラースキームへ対応することとほとんど同義です。 実装を含めた全体的なMaterial Design 3移行については以下のセッションが非常に参考になるかと思いますので、そちらをご参照ください。
本記事では、既存のアプリの配色を極力変えないままM3のカラースキームへ対応するという方針で、デザイン観点でのM3対応について検討をしていきます。
Material Theme Builder
M3のカラースキームへの対応を進める上で、 Material Theme Builder というツールは欠かせません。 こちらはGoogleが用意してくれているツールで、M3のカラースキームを動的に生成してアプリへ適用し、見た目を確認できるWebアプリとなっています。
Figma上で使用できるプラグインも用意されているので、今回はそちらを使用して話を進めていきます。
M3のカラースキームを生成
まずはベースラインとなるM3のカラースキームを、Material Theme BuilderのFigmaプラグインを用いて生成しましょう。 最初にプラグインを開くと以下のような画面が表示されます。
Create theme ボタンを押すと、M3のカラースキームが生成されます。
各色はM3の定める デザイントークン の命名に従って、FigmaのStyleとして登録されています。
デザイントークン
デザイントークンとは、デザインシステムにおいて最小単位のスタイルを定義するものです。 デザイナーとエンジニアの共通言語として機能し、一貫性がありつつも柔軟なデザインの構築を可能にしてくれます。
M3にもデザイントークンが細かく定義されており、Reference tokens, System tokensそしてComponent tokensと3階層で構成されています。
例えば色のデザイントークンでは、Reference tokenはTonal paletteの一つの色を指し、System tokenはReference tokenを参照してPrimaryやSecondaryのような役割を与え、Component tokenはSystem tokenを参照してどのコンポーネントで使用される色であるかを表現します。
Dynamic colorを考慮したM3のカラースキームへの対応
Dynamic colorを考慮したM3のカラースキームに既存アプリの色を対応させていく上で、M3で定義されたデザイントークンとDynamic colorのアルゴリズムを意識して進めることが重要です。
では具体的にはどのようなことに注意する必要があるのでしょう。 今回は3つほど意識しておきたいポイントを挙げたいと思います。
1. Component tokenのデフォルト値
M3のコンポーネントはデフォルトでどの System token を参照するのか明確に定義されています。 Google標準アプリでは基本的にはこれらのコンポーネントがそのまま使用されているので、自社のアプリの配色もこれに倣った方がデバイス全体のUIとして統一性を持たせやすく操作に一貫性を与えやすいことでしょう。 しかし、これに倣っていない既存アプリに後からこの定義を遵守させていくのは影響範囲の大きい難しい要件になることが予想されます。
例えば、B/43アプリではFilled Buttonの色に黒色を採用しています。
しかし、M3のFilled Buttonに使用されるComponent tokenではPrimaryのSystem tokenが参照されています。
B/43アプリのFilled Buttonは各画面で広く使用しているため、安易にPrimaryへ変更するにしては影響範囲が甚大です。 解決策として、他のStyle tokenで代用できないかを考えましょう。 M3では Inverse surface という、Snackbarなどで使用されるStyle tokenが定義されています。 今回はこちらをB/43のFilled Buttonの色として採用することを検討してみます。
このように、基本はComponent tokenのデフォルトで参照しているStyle tokenの利用を検討するのが正しいですが、既存アプリへの導入の際にはうまく代替案を模索していくことも大切です。
2. Dynamic colorで生成される各色の関係
例えばDynamic colorではPrimaryとSecondaryは近い色合いのものが生成されます。
Dynamic colorのソースコードを見ると、HueはPrimaryとSecondaryで同じ値が指定されており、ChromaはPrimaryがSecondaryよりも大きくなるように指定されています。 よって、このPrimaryとSecondaryにHueの大きく異なる色を指定すると、いざDynamic colorに置き換えた際に意図したデザインから遠いものになってしまいます。 まったく同じではないにしても、近しいHueで、ChromaはPrimaryよりSecondaryの方が小さめという条件は守った方が良いでしょう。
また、M3からElevationの定義が変わりました。 M2では、Light Modeだとshadow、Dark Modeだと白のオーバーレイを用いてElevationを表現していました。
M3ではLight, Darkに関わらず、Primaryのオーバーレイを用いたElevationの表現に変更されました。
Dynamic colorのソースコードを見ると、PrimaryはChromaが48を下回らないように設定されています。 Surfaceに透過してオーバーレイしても機能するように、ある程度の色の濃さが必要ということですね。 ElevationのあるSurfaceがどこで使用されるかを意識しつつ、PrimaryはSurfaceの上に透過してオーバーレイされるので一定の色の濃さが必要ということを考慮して配色を考えなければなりません。
3. Custom color
基本的にはアプリの各色はM3のデザイントークンで表現しますが、動的に変更されて欲しくないSemantic colorやアプリのブランドカラーがある場合はCustom colorとして追加しましょう。
例えばB/43アプリだとマイカードのオレンジ, ペアカードの緑や友達招待の黄色がCustom colorに当たります。
Custom colorはMaterial Theme BuilderのExtended Colorセクションから追加していきます。
そうすると、Custom colorについてもFigmaのStyleへ登録してくれます。
生成される色はHCT色空間上で調整されたものになっているので、既存アプリの色味へ再度調整してあげましょう。
ただし、Custom colorに何でもかんでも色を詰め込みすぎないように気をつけましょう。 Custom colorを増やしてDynamic colorで動的に変わる色が少なくなると、ユーザーのパーソナリティを尊重するというDynamic color本来の価値が薄れてしまいます。 例えばB/43アプリではペアカードを表す緑色は、ペアカードと関連していない箇所でも、要素を強調する役割で使用されています。
ペアカードを表す緑色はSemantic colorとしてCustom colorに定義するのが妥当ですが、要素を強調する役割の同じ緑色については別なデザイントークンで表現できないか考える余地があります。 今回はペアカードのCustom colorと分けて、TertiaryのStyle tokenとして追加することにします。
B/43アプリにおけるM3カラースキームの対応例
以上のポイントを踏まえてM3のカラースキームに対応させたB/43アプリをご紹介します。
まず、こちらがM3のカラースキームに対応したアプリの配色です。 PrimaryとSecondaryにはDynamic colorのアルゴリズムを考慮した配色を設定しており、Tertiaryにはペアカードと同じ緑色を指定しています。 またCustom colorとして、My Cardのオレンジ色, Pair Cardの緑色, Friend Invitationの黄色を追加しています。
ドロワー画面はこのようになりました。 M3のNavigation drawerにデフォルトで指定されたComponent tokenを元に、一部調整した配色となっています。
こちらはマイカードのホーム画面です。 M2のBottom navigationはM3のNavigation barに置き換えつつ、一部配色を調整しています。 カードの背景色のグラデーションにはCustom colorで追加したMy Card, My Card Containerを指定しています。
他の画面は以下のようになりました。 ペアカードに関連しない部分で使用されている緑色はTertiaryを、Filled ButtonにはInverse surfaceを指定しています。
このように既存のB/43アプリの配色を極力変えないままM3のカラースキームへ対応することができました。
B/43アプリへのDynamic colorの適用
では、最後の仕上げとしてこのアプリにDynamic colorを適用してみましょう。
まずはMaterial Theme Builderを起動し、Current Themeをタップします。
すると、Themeを追加する導線が表示されるのでタップし、Dynamic color用のThemeを追加します。
今回は dynamic-theme という名前で追加します。
すると、新たに dynamic-theme という名前でM3のカラースキームが生成されます。
この新たに追加したThemeに、B/43アプリで必要なCustom colorも追加していきます。
あとは、このDynamic colorのThemeを適用したい対象のFrameを選択した状態で、Material Theme Builderの SWAP ボタンをタップすると、そのFrame内で使用されているM3のデザイントークンが dynamic-theme の色を参照するように入れ替わります。
実際にDynamic colorを適用したものがこちらです。
しかしマイカードやペアカードといったCustom colorについてはDynamic colorと調和が取れておらず、やや浮いた印象を与えてしまっています。
これらのCustom colorの調整を行うために、 Extended Colorsの右側にあるチェックボックスをオンにします。 すると、Dynamic colorのソースカラーに色味が寄せられたCustom colorが生成されます。
実際に調整後のCustom colorを適用すると以下のようになります。
Dynamic colorによって他のソースカラーが選択された場合にも同様に調和の取れたCustom colorが適用されるようになります。
まとめ
今回、Dynamic colorはどのような背景を元に導入されたのか、どのようにコントラストの十分なカラースキームを動的に生成しているのか、アプリ固有の色へどのように対応しているのかについて説明しました。 そして最後にDynamic colorをアプリへ適用するにあたっての具体的なデザインフローについて、意識すべきポイントを挙げながらご紹介しました。
本記事が、Dynamic colorの導入についてチームで議論を進めていく上での参考になれば幸いです。
参考資料
達成基準 1.4.3 を理解する | WCAG 2.0解説書
デザインで「人間が感覚的に見分けやすい色」を選ぶ方法をデータ可視化のプロが解説 - GIGAZINE
Dynamic color – Material Design 3
The Science of Color & Design - Material Design
Designing Harmony into Dynamic Color - Material Design
Visualizing dynamic color in your app | Google Codelabs
