CMSを構築するうえで、運用を考慮したUI/UXを設計することは非常に重要なことです。
いくら高機能なシステムでも使われなかったら意味がない。それは存在しないに等しい。使われてなんぼ、使いやすくてなんぼ、なわけです。
WYSIWYGエディタを基本として考える
WordPressの入稿画面はWYSIWYGエディタを基本としています。
TinyMCEというエンジンが採用されています。
HTMLの知識がなくてもWord感覚で記事を入稿できるビジュアルモードと、HTMLの知識がある人向けのテキストモードが用意されています。
editor styleの適用
WYSIWYGというのは「最終的な仕上がりを画面上に表示して確認しながら編集できると」という意味です。
つまり、WYSIWYGエディタの編集画面がフロントの見た目と一致していなければ本来の意味を果たしません。
ディフォルトのまま使うと入稿画面とフロント表示は一致しません。
WYSIWYGエディタにテーマのスタイルシートが適用されていないからです。
そこで、editor styleを適用させます。
関数リファレンス/add editor style – WordPress Codex 日本語版
テーマのスタイルシートをWYSIWYGエディタに適用させることで、入稿画面とフロント表示を一致させることができます。
WYSIWYGエディタでの入稿をメインに想定している場合は必要な設計です。
WYSIWYG内に定型テンプレートを挿入する
WYSIWYGエディタはもっとも自由な入稿フォームです。
ビジュアルモードのツールバーに加えて、テキストモードではHTMLタグも使えるので、まぁどんなページでも作成できます。
ただ自由すぎて戸惑うユーザもいるかもしれません。
そんな時は、AddQuicktagとTinyMCEテンプレートプラグインを使うと、WYSIWYGエディタ内に定型テンプレートを挿入することができるようになります。
WYSIWYGエディタの中に自由配置でパーツを組み込めるようにすることで、自由と定型の両方を兼ね備えたUIを構築することができます。
カスタムフィールドを使ったUI/UXの構築
自由フォーマットから定型化への流れの中で、カスタムフィールドで入稿フォームを細分化する手法もあります。
カスタムフィールドで完全に定型化すると、HTMLの知識はまったく不要になるばかりか、WYSIWYGエディタの操作さえおぼつかないユーザにも親切な入稿画面になります。
上から下へ、用意されたフィールドを埋めていくだけでページが完成するからです。
カスタムフィールドを使って入稿画面を設計しだすと、とにかく定型化された入稿画面こそ優れていると思いがちですが、実際はそうとは限りません。
定型化しすぎると、ユーザから自由なページ作成を奪うことにもなるので注意が必要です。
自由と定型のバランス、その両方を適切に設計することを忘れてはなりません。
でも、カスタムフィールドの本来の意味とは
カスタムフィールドは入稿画面のUI/UXを優れたものにしてくれますが、そもそもの意味は違います。
カスタムフィールドは、タイトルと本文のメインデータとは別のメタデータであり、データ構造を細分化するものです。
WordPressのデータベース構造を見ても、タイトルと本文はメインのpostsテーブルに、カスタムフィールドはpostmetaテーブルに格納されます。
カスタムフィールドを定義するメリットは、ずばりデータの再利用性にあります。
WordPressにもRSSやREST APIが搭載されており、データを外部サイトや外部サービスにプッシュすることができます。
その時に、データが適切なメタデータとして格納されていることは重要です。
また、将来的にデータの整理や、サイトの移管、またはデータのインポートが発生した場合、適切にメタデータが格納されていることは非常に重要な意味を持ちます。
カスタムフィールドは入稿画面のUI/UXを優れたものにしてくれ、適切にメタデータを格納してくれるからオールオッケー！
というわけでもありません。
主に以下の点には注意したいところです。
検索フォームの実装時には注意
検索エンジンとしてWordPressのディフォルトの検索エンジンを使用しようとした場合は注意が必要です。
WordPressのディフォルトの検索エンジンでは、タイトルとWYSIWYGエディタから入力された本文のみがヒットします。
メタデータであるカスタムフィールドは検索対象外になるので、検索フォームを設置する場合は、検索ロジックをカスタムする必要が出てくることにも留意しなければなりません。
バッグエンドのパフォーマンスに注意
カスタムフィールドはメタデータとしてpostmetaテーブルに格納されていきます。
記事データは、本来メインデータ1レコードですが、カスタムフィールドがあれば2レコードになります。
2つあれば3レコードです。
カスタムフィールドが多くなればなるほど、レコード数が増加していきます。
つまり、なにげなく書いたテンプレートタグですら、裏では膨大なクエリを発行していて悲鳴をあげているっていうパターンもあるかもしれませんよ。
SQLクエリのパフォーマンスについてもシビアに設計するならば、その辺もちゃんと考える必要があります。