Badgeが抱える曖昧さを分析してみた
はじめに
株式会社ドワンゴのニコニコ生放送でフロントエンドを担当している misuken です。
あなたはWebフロントの世界で「Badge」という名前を見たときに、どのようなものを想像しますか？
通知数、何かの状態を伝えるもの、あるいは何かを達成したときにもらえるものでしょうか。
今回は、Webフロントの世界でごく当たり前に使われている「Badge」という名前が、実は様々な側面を持っていて、その曖昧さが問題を引き起こす原因になることをご紹介します。
この問題の解決策は次の記事で書く予定なので、今回はその問題を理解するための前提知識として、Badgeが抱える曖昧さを分析してみたいと思います。
2024/10/15追記
解決策となる BadgeからIndicatorへのパラダイムシフト を公開しました。
Badgeの曖昧さ
まずはじめに、BadgeにはUIとしてのBadgeとドメインとしてのBadgeの二つの側面があります。
UIにおけるBadge
UIにおけるBadgeにも、主に「見た目からの視点」と「役割からの視点」の二つの視点が存在していると考えられます。
Badgeという名前のコンポーネントは、各UIライブラリに存在しますが、ライブラリごとにその役割は様々で、特に数値の表示と状態の表示という点において、その曖昧さが見られます。
それぞれで全く違った役割を持つため、混同しないように注意が必要です。
見た目からの視点
UIの見た目としてのBadgeは、小さな丸など、形状が由来していると考えられるものです。
また、小さな物を何かの上に重ねて配置する(取り付ける)というレイアウト的な意味合いも一部に含まれていると考えられます。
各ライブラリでは、数値のみを表示するものと、数値に加えてアイコンを表示できるものがあります。
| MaterialUIのBadge | InfragisticsのBadge |
|---|---|
 |
 |
- 数値のみを表示するもの
- 数値に加えてアイコンも表示できるもの
役割からの視点
UIの役割としてのBadgeは、それがどのような状態であるかを表す印としての意味が由来していると考えられるものです。
これらは主にラベルのような見た目で表現されます。
| Adobe SpectrumのBadge | GitLabのBadge |
|---|---|
 |
 |
ドメインにおけるBadge
Badgeという名前はドメイン名としても何らかの証しを示すものとして使われます。
- サービスから認証や認定されたことを示す印にあたるもの
- 組織やグループの会員であることを示す徽章にあたるもの
- 達成などを象徴する記章にあたるもの
ドメインのBadgeとUIの関係性
次に、ドメインのBadgeとUIのBadgeの関係性について考えてみましょう。
例えば、何かを達成した証しとしてバッジが付与される機能があるとします。
ドメイン名を AchievementBadge(達成バッジ) とした場合、ユーザーに付与されたバッジがどのようなUIで表示されるでしょうか。
ほとんどの場合バッジの一覧を開いたときに並んでいるのは、バッジそのものではなく、バッジのイラストと、バッジのメタ情報が表示されるはずです。
もし関心の対象がバッジではなくユーザーであれば、これはUserCardに該当するでしょう。
UserCardのサムネイルやアバター相当の部分が、バッジのイラストにあたります。
つまりこれは、AchievementBadgeCardというコンポーネントになるのが自然ということを指します。
このように考えると、現実のバッジ自体はアイコン or 画像であり、ドメインのBadge自体はBadgeというコンポーネントで表示されることはないと考えられます。
ドメインのBadgeがUIのBadgeで表示されない理由
ドメインのBadge自体はBadgeというコンポーネントで表示されることはないと述べましたが、まだしっくり来ない部分もあると思うので、もう一つの別の場面を考えてみましょう。
ユーザーのアバター画像の右下に獲得したバッジが複数並ぶような表示があるとします。
このとき、一覧で表示されるものはたしかにバッジですが、UIとしてはIconで十分でしょう。
もしも、Badgeというコンポーネントを作ったとしても、それはIconと機能が同じになるはずで意味がありません。
結果として、どのような場面でもドメインのBadgeを表示するためにBadgeというコンポーネントを使用する必要が無いことを意味します。
改めて整理するとこのように解釈できます。
- ドメインとしては Badge の一覧ですが、UIとしては Icon の一覧
- ドメインとしては User の一覧ですが、UIとしては Card の一覧
これにより、ドメインのBadgeはUIのBadgeとは直接的には無関係であることがわかりました。
Iconで十分ではない場面
上で「Iconで十分でしょう」と書いたものの、鋭い方はまだしっくり来ない部分が残っているかもしれません。
それは、Iconは アイコン単体を表すものであり、アイコンの周囲を丸い背景色やボーダーで囲った形状になる場合、Iconの責務を超えているのではないか？というものです。
元からバッジの見た目が完結しているアイコンであればIconで十分ですが、そうでない場合はIcon以上の何か、見た目由来のBadgeコンポーネントが欲しくなります。
解決策は次回の記事でまとめて説明する予定なので、ここではこういった問題を抱えることがあるということを認識しておいて頂ければ十分です。
BCD Designの観点から見たBadge
次はコンポーネントを体系的に分類するうえで基本となる BCD Design の観点から、Badgeについて考えてみましょう。
Badgeがコンポーネントの型を表すBaseとなる場合、見た目由来の小さな丸で数字を表示するものか、役割由来のラベルのような形状で状態を表示するものになります。
つまり、BaseにBadgeというコンポーネントを定義しようとしても、見た目由来と役割由来のどちらにするか決めが必要になったり、プロジェクトによって分かれてしまうなどの問題が発生します。
さらに、Badgeという単語がドメイン名としてCommonやDomainにも出現し始めると、さらに混乱が生じます。
例えば、BadgeListというコンポーネントがあるとき、ここで指すBadgeは何かのドメイン的な証しの一覧なのか、小さな丸が並んでいるものなのか、はたまた状態を表すラベルが並んでいるのか区別が付きません。
Badgeから始まるコンポーネントをBaseに入れるのか、Commonに入れるのかも曖昧になってしまいます。
このように、BCD Designの観点から見ても、Badgeというものは曖昧さを持っていて、混乱を生じさせる原因になることがわかります。
まとめ
今回は、Badgeという名前が持つ曖昧さについて分析してみました。
UIとしてのBadgeは見た目由来、役割由来によって大きく異なる存在になってしまうこと。
ドメインとしてのBadgeは証しを示すものを意味し、それをUIで表現する場面ではBadgeというコンポーネントを使う必要がないこと。
そして、Badgeという名前が見た目由来のUI、役割由来のUI、ドメインのどれを指すかが明確でないため、混乱を生じさせる原因になることがわかりました。
今回の記事はここまでで、次回の記事ではこの混沌とした問題を解決する方法を紹介します。
2024/10/15追記
解決策となる BadgeからIndicatorへのパラダイムシフト を公開しました。
株式会社ドワンゴでは、様々なサービス、コンテンツを一緒につくるメンバーを募集しています。 ドワンゴに興味がある。または応募しようか迷っている方がいれば、気軽に応募してみてください。
Discussion