ボタンの命名は連番!?

Twitterで話題になったこちらについて。

「用途別ではなく機械的に名前をつけるべき」という内容に対して各所から非難轟々だったのですが「ちゃんとした名前つけるのが当然だろ」みたいな反論ばかりだったのが気になりました。

そもそも用途と見た目は独立して取り扱うべきものです。

「一つの用途のUI部品に多数の見た目があるとユーザーが混乱するので避けるべき」という一般論があるのは理解していますが、それでも現実の問題として見た目にはバリエーションがあります。スマホゲームにおいてその最たるものは画面遷移ボタンだと思います。グローバルメニューにあったりヘッダーフッターにあったり、画面内のボタンにあったりし、また重要機能(ガチャやメインコンテンツなど)への導線の見た目が盛られたりと、とても多様になりがちです。

逆に、一つの見た目がさまざまな用途のボタンに割り振られることもあります。

f:id:enrike3:20220222173006p:plain

この図はプリコネから抜粋した例ですが「入手方法」と「キャンセル」が同一用途だと言い張る人はまずいないでしょう。汎用系のスタイルは多用途に横展開されるのが常です(それが汎用系ということですからね。トートロジー)。

冒頭のTwitterの例をみてみると、「用途別」の命名を独立した要素であるはずの「見た目」の問題で否定しているのがそもそもの間違いで、二つの世界が混ざってしまっています。見た目の横展開が楽な見た目都合の連番方式というのは、ロジックを組む用途側の都合を考慮していないということで、変数名であったりコーディング側の感覚で反論が来るのです。

もし「青ボタンスタイル」の見た目のボタンを用途別にOKButton, SubmitButton、SceneTransitionButton…として別々にアセットを作っていたら、デザイナさんが「青ボタンスタイルを更新したい」というときに全部直す必要がでて大変です。当たり前ですがデザイン側は一元管理したいのであり、そのニーズを一方的に無視するわけにはいきません。一方で見た目単位のアセットを正とし、BlueButton1の単位でアセットを各シーンに配置してしまうと、OKButtonだけスタイル差し替えたい、というときに全箇所修正が必要ということになって非常に厳しいことになります。

見た目ボタンと用途別ボタンはどちらも別々に作り、用途別ボタンに見た目を割り当てるということができればベストです。WPFなどのフレームワークならBasedOnプロパティを使ってStyle継承ができますので見た目重視のStyleを継承して用途単位でサブクラス化できます。Unityの場合UI向けのStyle機構がないので、用途別ボタンのPrefabに見た目Prefabを組み込むとか、ツールを使ってスタイル一括適用とかになるでしょうか。とはいえ用途別も見た目別も全部作るなら管理するアセット数は最大になるので、どちらか片方だけを使うというプロジェクトも多いはずです。

さて、見た目ボタンを作るなら命名は連番とちゃんとした名前付けどちらが好ましいのかですが、用途から切り離して名前を付けるというのはなかなか難しいところがあります。物理的なプロパティをかき集めてbutton-blue-frame02-r16 みたいな方法が考えられますがデザイン変更したら名前が変わることになるので変更に弱く、結局button-type01, みたいな連番と大差ないものに落ち着くと思います。テーマやアクセントカラーがはっきりしたデザインならそれらを名前に使うこともできるでしょう。もちろんアクセント1みたいな名前付けをしたとしてもこれは色に対するエイリアスに過ぎず、用途別命名とは程遠いものになります。

「ああ、この人は見た目管理の世界に軸足を置いているんだな」というところが分かればそこまで叩かれるような記事とは思わないのですが、OKボタンの見た目をキャンセルボタンに使うことがあるから、のあたりはさすがに不味かったですかね。

(連番→機械的、に一部修正)