ステートについて検証した中で気になったことをまとめました。あと、その過程で「リンクされたアセット」の事例に触れるため、ついでに最後にその機能紹介もします。ステートメリットデメリットBootstrapXDへのステート定義検討まとめおまけ:リンクされたアセットメリットデメリットステートコンポーネントへの複数ステートの追加。画像は公式サイトより引用コンポーネントごとに、スタイルやレイアウトのバリエーションをステート(状態、state)として定義し呼び出すことができます。2日目のえびさんの記事では、その登録や活用方法を詳しく紹介されています。メリットAdobe公式マニュアルではこう説明されています。ユーザーの操作によって外観が変化するコンポーネントは、忠実度の高いプロトタイプを作成するうえで非常に役立ちます。コンポーネントを作成し、複数のバリエーション(ステート)を追加した後、それらを接続することで、実際のユーザービヘイビアーを模倣できます(コンポーネントを複数回コピーする必要はありません)。コンポーネントにステートを定義すると、アセットの管理とインタラクティブデザインシステムの作成も容易になります。プロトタイプの精度を高める用途のようで、従来アードボードを複数に分ける必要があったインタラクションもステートを活用すれば簡単に表現できます。「ホバーステート」機能が特徴的で、プロトタイプ上でそのコンポーネントにカーソルを載せると「ホバーステート」として定義した外観に自動で変化します。ユニークなところは、ホバー以外にも定義を好きなだけ追加できることです。何をどう定義するのかはユーザー次第であり、CSSの擬似クラスに留まらず、サイズ違い、配色違いなど、様々なバリエーションを持たせることもできます。これはプロトタイプの精度を高めるのみならず、アセットの管理、デザイン制作の効率化にも役立つ可能性があります。デメリットアセット管理用途だと、現状使い勝手が悪いです😅。定義したステートの並び替えや階層化はできませんし、アセットパネルと違い検索できないので命名規則での管理も不可能です。後からの編集・変更も大変面倒なので、ガンガン自由に定義していくなら早めの段階でルール(どんな順番でどんなステートを登録するのか)を整える必要があります。定義は良くも悪くもユーザーの自由なので、あまりに大量・複雑にしてしまうと、データの共有・引継ぎが大変かもしれません。ここでは、私が配布しているテンプレートドキュメントBootstrapXD(Mac用)を例に考えてみます。このデータは「アセットのリンク」活用を前提とし、多数のアセット(カラー・文字・コンポーネント)を登録しています。現状はカラーを中心としたアセット構成になっていますが、コンポーネントに何かステートを新しく定義することで、ソースドキュメントとしてより使いやすいものにならないかどうか検討しました。Bootstrapの「.btn」コンポーネントは、一体どんなステートを定義すると良いでしょうか。次のような候補が思いつきます。outline)これら全てを定義してしまうと、192ものステート数になります。現状のステート選択UIでは並び替えも検索もできませんから、これほどの数を扱うのは無謀です。数の多い「配色」のステート定義は諦めます。いって、それぞれコンポーネントにすると、例えばボタンの角丸サイズを変更したい時に配色毎のコンポーネントを個別に編集する必要が生じ、非効率です。背景・枠それぞれ必要となりますが、配色はアセットのカラーで管理するべきです。装飾(outline)についても同様です。サイズについては、少なくともアセット管理用途ではコンポーネント・ステート定義どちらでも良いのですが、Bootstrapにおいてはプロトタイプでインタラクションを扱う際のステート選択肢に「サイズ」があっても無駄なので、コンポーネントにするのが無難でしょう。disabled)のみをステート定義するのが良いと考えました。ところが実際やってみるとうまくいきません。それぞれの色が、配色毎に異なっているため、配色毎のコンポーネントまたはステート定義も必要だったのです。.btnの一元管理と、配色毎のステート管理とがトレードオフにあり、ドキュメント管理者がいずれかを選択するならば、利用者にその内容と意図をどこかで伝えなければなりません。するだけなので、ステート定義が活かせます。disabledだけ定義されているのも不自然ですし、こうした意図や注意事項を利用者に伝えるのも困難です。よって、BootstrapXDではステートの設定を見送ることにしました...。まとめステート機能は便利ですが、アセットの管理という視点では、既にあるガイドライン(Bootstrapなどフレームワーク含む)との相性が悪いケース、どこで折り合いをつけるのか判断が難しいケースなどあるだろうなと思いました。ステート定義は自由ですから、客観的にわかりやすい定義を心がけ、独自な定義をするなら共同作業メンバーにもしっかり共有しなければなりません。そんなこんなで現状、「アセットの管理」目的では積極的に使うべきではないし、使うにしても事前のルール整備が欠かせないでしょう。「ホバーステート」は用途もルールもわかりやすいのでとっかかりとして良さそうです。そこから少しづつXDとステートの特性に慣れ、プロジェクト・プロダクトのドキュメントに工夫して取り入れてみてはいかがでしょうか。おまけ:リンクされたアセットリンクされたアセット。Assets)ことで、あるクラウドドキュメント(ソースドキュメント)上のアセットを、今開いている別のドキュメントに読み込ませることができます。Assets)と呼ばれます。メリットこの機能によって、複数ドキュメントを用いた制作と、そのドキュメント(デザインデータ)の運用が効率化されます。このようなドキュメント構成です。プロダクトの実装済み機能Cのリデザイン・プロトタイプ実装側で何か既存のアセットに変更があった場合、ソースドキュメントだけを更新しドキュメントA〜Cのアセットも「更新」すれば、各進行中のドキュメントも簡単に最新の状態にアップデートできるのです。規模の大きい開発では、全ての画面のデザインデータを最新に保ち続けるのは相当なコストです。ソースドキュメント(最低限のアセット)のみ最新として他のデザインデータは使い捨て、くらいの向き合い方が現実的ではないでしょうか。ソースドキュメントとそれ以外とで役割を分けると、間違えて最新アセットを上書きしちゃった!みたいなリスクも減ります。ソースドキュメントの変更操作が限定されバージョン管理がしやすくなり、ミスがあっても気付きやすくリストアも容易です。あと、この構成であればドキュメントごとにプロトタイプ発行も可能です。従来、一つのドキュメントの元でプロトタイプを分けようとすると、いわゆる「目次ページ」を手動で作って管理し関係者にも説明する必要がありましたがその手間が省けます。デメリットリンクされたアセットは、「デザインデータ一度作って終わり」のようにドキュメントを分ける必要自体ないプロジェクトではほとんどメリットがないでしょう。一つのドキュメント内にアセットも制作中の画面もプロトタイプも全てまとめた方が作業効率が良いはずです。Title/URLこの記事を書いた人ろくぜうどんid:rokuzeudonモノ・コトをより良くするWebデザイナーです。サービス開発におけるUIデザイン・LP制作・HTML/CSS実装・プロジェクトマネジメントなど幅広く立ち回っています。(3)このブログについて|プライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。