ブロックエディタや可変フィールドの設計は難しい：デザインシステム編
ブロックエディタや可変フィールドといった要素の構成に応じてフィールドやブロックを自在に管理画面で編集できる機能が様々なCMSであります。
この記事では、ブロックエディタや可変フィールドの設計が難しいという話題で記事を分けて解説します。
この記事では、MTAppjQueryのマルチフィールドに利用したときのデザイン設計について紹介していきます。
- ブロックエディタや可変フィールドの設計は難しい：デザインシステム編
- ブロックエディタや可変フィールドの設計は難しい：CMS設計とマークアップの関係編
- ブロックエディタや可変フィールドの設計は難しい：CMSとマークアップの関係
Movable Typeのブロックエディタや可変フィールドで利用されるブロックエディタや可変フィールドではどのような設計が考えられるのかを解説します。
ブロックエディタと可変フィールドの違いについて
まずはじめに、ブロックエディタと可変フィールドについて説明します。
両者の大きな違いは、以下と考えています。
| ブロックエディタ | 可変フィールド |
|---|---|
| ビジュアルエディタ方式 | カスタムフィールド方式 |
従来のCMSでは、入力方式としてリッチエディタとカスタムフィールドの2つの方式が取られていました。
テキストや文中にリンクや絵文字を挿入など、コンテンツ管理者が自由にコンテンツを入力する方式としてリッチエディタを利用していました。
CMS（コンテンツマネジメントシステム）という言葉が登場する前は、ブログツールとして利用されていたMovable Typeでした。
そのため、単純なテキストやリンクの装飾や画像などの配置だけできるツールでした。
カスタムフィールドの登場したことによりCMSとして利用され始めました。
利用方法は様々ですがカスタムフィールドは、特定の表示部分にテキストや画像などを登録・表示できるフィールドです。
この機能を活用することで特定な部分にバナー差し替えをCMSから登録管理できます。
しかし、運用する上でリッチエディタやカスタムフィールドでは自由にコンテンツを管理するには難しい部分が出ていました。
そこで登場したのが、ブロックエディタや可変フィールドです。
- ブロックエディタ
- 可変フィールド（マルチフィールド）
ブロックエディタと可変フィールド（マルチフィールド）の特徴は、コンテンツをそれぞれ自由（レイアウトや見た目）に作れることです。
両者の違いは冒頭に書いた通り、ビジュアルで管理できるブロックエディタとCMSのフィールドで管理する可変フィールドになります。
現在では、Movable Typeの実装において両者を使い分けして設計や実装しています。
従来コンテンツ管理よりも柔軟にコンテンツ作ることが可能になりました。
しかし、入力パターンが多くなるということは機能が多く運用負担は大きくなります。
また、詳細設計や操作マニュアルも作る必要があります。
このように昨今のCMSは、設計やその後の運用まで考慮した実装が求められます。
デザイン・ワイヤーの段階から情報設計や仕様を確定させる
長くなりましたが、ここから本題に入ります。
まずデザインやワイヤーの段階から情報設計や仕様をある程度確定させます。
デザインやワイヤーを先行で作ってしまうと、あとのCSM設計やマークアップに考慮漏れや実装できない問題が発生するためです。
実装に入ってしまえば、調整ができる部分はあるものの最初の段階である程度方向性は決めておきましょう。
- 情報設計と要件定義
- ドメインを知る（現在の運用方法や業種固有知識を知ること）
- どこをCMS管理するのか
- サイトマップを確定させる
- 現在の運用方法とこれからの運用方法
- コンテンツ管理者は複数人いるか
- 選定してたCMS（Movable Type）で行えるコンテンツ管理方法を確定させる
- マルチフィールドかブロックエディタ
- 管理方法に応じて見せ方の方向性を考える
- 静的ページの管理がある場合はどのように管理するのか（デザインだけのページ）
- 管理するコンテンツのレイアウトパターンはいくつ作るのか
- デザインシステム（コンテンツ管理する部分）のレイアウトをある程度制限する
情報設計と要件定義
お決まりのことですが、CMSに限らず単純なウェブサイトでも情報設計や要件定義は必須です。
大規模になるとこれらの情報設計や要件定義に不備が多いと、実装破綻してしまうからです。
まずは、要件定義する上で必要なこととして ドメインを知る ことが大切です。
ドメイン駆動開発の言葉から受けた部分ですが、対象となるクライアントの業種や運用を知ることが大切です。
CMSを単純なウェブサイトで運用するのか。それともデジタルサイネージなどの他のデバイスを前提にしているのかなど、ターゲットを確定させそれに応じた要件や運用が出てくるはずです。
例えば、営業の顧客データとして利用する場合は、顧客データの情報はどのようなものがあるのかを知る必要があります。
また、営業はスマホやタブレットで入力できる前提が良いでしょう。
このようにまずは、周辺の知識や固有ルールをデザイナーやエンジニアが知っておくことで、どのようなアプローチが取れるかを提案や設計に落とし込むことが可能になります。
ウェブサイトであれば、どこのページを更新したいのかすべてのページを管理したいのであれば、どのような更新フローが取れるのかなどを決めておくことが大切です。
ブロックエディタや可変フィールドを駆使すれば、ウェブサイトを全部更新できるんですよね。という勘違いが起きます。
たしかにノーコードのCMSを利用すればすべてを管理は可能です。しかし、Movable Typeにおいては、全部を管理するためには考慮する部分や運用フロー負担を考えるとすべてを管理すべきではありません。
※ノーコードCMSを利用する場合は、出来ることできないことをデザインをする前に把握しておくことが大切です。管理的には可能だが運用が難しいようなデザインは作る前にすり合わせしましょう。
最後にサイトマップやコンテンツの管理者が何人いるのかなどを確定しておきましょう。
サイトマップやディレクトリ名が決まっていないと、どこにコンテンツを管理するか何個子サイトで分ける必要などが考える必要があるためです。
構成要素から情報設計しワイヤーとフィールド設計を考える
サイトやアプリを作るときは構成要素がなにか情報整理と設計がすべてです。
情報設計をしたら、ワイヤーやデザインすることは正しいワークフローではありますが、ワイヤーやデザインだけが独り歩きをするのは避けましょう。
情報設計とワイヤーやデザインを作るときは、必ずエンジニアの意見は必要です。
どのような運用を期待しているのかをデザインやワイヤーだけでは判断できないことが多いからです。
まずは、情報設計の段階で選定したCMSやツールで出来ること出来ないことを文書化して、その上で要件や仕様を明確にして共有することが大切です。
Movable Typeではどのようなことをできるのか改めて整理する
Movable Typeをすべて熟知しているエンジニアの場合であれば、要件に対して即回答できる場合もあります。
しかし、実際にはアップデートに伴う機能追加やプラグインまでを網羅して要件にあった方法を提案することは難しいでしょう。
そのため、実際には要件があがったタイミングでゴールを明確して、どのようなアプローチが取れるのかアルゴリズムを考えていきます。
- どのような使い方をしたいのか（どのようなデータがあるのか）
- 周辺環境の構成（サーバやソース管理やフロントエンド技術選定）をどうするか（どの構成が要件にあっているかを見極める）
- ワークフロー（運用の流れや選定技術の把握）を可視化する（プロトタイプ）
- Movable Typeの機能だけでは足りない部分をどのように補うか（プラグイン構築検討）
- 可変フィールド・ブロックエディタの範囲を確認とデザインシステム
1〜4は、デザインやワイヤーを始める前段階で決めておきましょう。
情報設計や構成（検証も含む）を整理することで、どのような機能が必要で選定CMSで対応可能かを見極める大切な部分です。
また、ワークフローや管理画面などのプロトタイプなどを具体的に可視化しておくことでクライアントも運用イメージをつかみやすいです。
可変フィールド・ブロックエディタの範囲を確認とデザインシステム
この記事の本題となる部分は5の可変フィールド・ブロックエディタの範囲を確認とデザインシステムです。
可変フィールドやブロックエディタはコンテンツをブロックを積み上げるような管理をします。
しかし、クライアントへの説明やイメージしずらい部分です。
従来のCMSでは固定フィールドが主流だったため、定義された部分へのブロックのようにコンテンツを構成する形を言語化することは難しいと考えます。
CMSの可変フィールドやブロックエディタのプロトタイプを作るとよりイメージしやすいと感じています。操作性はサンプルを見せて説明すると良いでしょう。
デザインシステムの定義とは、UIコンポーネントやその他ルールなどをまとめたデザインのドキュメントです。
デザインドキュメントがあることで、品質の担保や一貫性をもったUIコンポーネントを管理しチームが効率よく開発可能です。
デザインのドキュメントとして使われる言葉ですが、ここではCMSの可変フィールドやブロックエディタにおいてのUIコンポーネントのあり方を解説します。
フィールドパターンはいくつ作るべきか
例えばブログやお知らせのような可変フィールドやブロックエディタを利用する場合、フィールド数やレイアウトパターンはいくつ用意するか事前に決めましょう。
デザインのレイアウトパターンは、作りすぎないことがポイントです。
（目安：10フィールド）
デザインの状態（色やフォントサイズなど）は、入力数や配置さえ決まったパターンであれば状態に応じて管理できるためフィールドを集約可能です。
入力値が多くなると運用の手間なども考慮して、ワイヤーやデザインをする前に考えておくと良いでしょう。
余白フィールドは必要か
ページのコンテンツの間の余白について解説します。
意図して余白をつける場合もあるため、余白フィールドで対応するケースはあります。
しかし、本来のデザインシステムで作る場合、一貫性をもった余白にすることが望ましいです。
可変フィールドやブロックエディタといった自由にブロックを積み上げ式での余白フィールドの可否は、実装前に確定しましょう。
特定のデザインでもシステム化できるのか
特定のデザインでもここのパーツだけはシステム化する方法はあります。
例えば別のデータとして管理しておき、ページ投稿側でリレーション（関連）したりするなどで補う方法などが挙げられます。
技術的には可能な領域と運用の複雑さをどちらを取るかが決めてなるのかなと考えます。
- 達成できるが運用が複雑になる
- 複数のリレーションで構成されてしまうと分かりづらくなる
- 設計書が複雑になる
- 内容によっては実装が複雑になる
- ユーザガイドに落とし込まければいけない
リレーションを貼ることで目的は達成できるかそれらをユーザガイドに落とし込む的にわかりやすく説明することが難しいです。
運用負担を軽くするためにシステム化するのがCMSの役割です。
しかし、目的や構成デザインや仕様（やりたいこと）を優先してしまうとシステムが複雑になり、大量なフィールドとルール尽くしのユーザガイドが出来上がります。
運用疲れしてしまうような設計は避けなければなりません。
デザインやワイヤーのミーティングは設計や実装するエンジニアが同席すること
デザインシステム破綻をまずは避けるためには、設計や実装するエンジニアが同席するべきです。
設計者だけ同席でも問題ありません。機能理解が少ない設計者の場合は実装者も同席しましょう。
先に挙げた非エンジニアには、何か見せなければいけないという経緯を考えるとやはりデザインやワイヤーが先行してしまいます。
この時、ワイヤー段階でそれらが実現可能かどうかのジャッジをする役割が必要です。
こんな見た目だといいよね？とかそういう絵の話が先行して、どのようなデータを保持しておきたいのかどう管理したいのかが置き去りされてしまうと、最終FIXしたデザインを修正しなければなりません。
どのような要素が必要のヒアリングで、どう組み立てるかどう管理するかがセットで決めることが大切です。どちらかが置き去りにされると最終的に詰んでしまうからです。
- デザインやワイヤー段階のミーティングには設計者・実装者は同席すること
- 構成に応じて出来ること出来ないことを正確に伝えること
プロジェクトマネージャや上流部分で決定してしまうと必ず実装の見直しやデザインに見直しが発生するため、実装方法やできる方式の案を必ずエンジニア目線で行うことが大切です。
システムは一定ルールの連続である
CMSに限った話ではなく、システムとは一定ルールや制限の中で構築されるものです。
細かい調整ができるようなフィールドを作ることはできます。
しかし、ユニークな変更可能な設計になる場合、運用側への負担は大きくなります。
要素数の違いやレイアウトの違い（余白など）がある場合は、例外的な対応が多発するためCMS化対象範囲は基本的の構成を作っておき、それらをルールに基づいて構築するべきでしょう。
まとめ
デザインとCMSのフィールドは、イコール（見た目とフィールドレイアウト）になることはありません。
デザインの状態や運用方法に応じて設計していくべきしょう。
- フィールドパターン数は、多くならないようにして必要なフィールドに絞って作る
- 余白フィールドや特定デザインしかできない設計はCMS化すると運用破綻する可能性が大きい
- デザインやワイヤーのミーティングはエンジニア同席して、技術的な意見をいうこと
- システムは一定ルールの連続であり、そのルールに応じたデザインシステムを設計する
Discussion