阿修羅ワークス開発日誌　テーマ開発で使用するCSSフレームワークをUIKitにする

マッチングサイト用のデモサイト作成用にテーマ開発をすることになったわけだけれど、CSSフレームワークを何にするか色々と悩んだ挙げ句決めた。

「UIKit、君に決めた」

今まではSemantic UIを使っていたんだけれど、最終更新が2018年で、かつjQuery依存があるため、今の流行ではないんだよね。
それにWordPressに組み込むと他テーマでクラス名が一部バッティングすることがあるというのも問題だった。
デザインとか機能についてはSemantic UIが好きなんだけれどね……。

そこで調べていたらWordPressへの組み込み実績があり、かつクラス名のバッティングが生じにくいCSSフレームワークとしてUIKitを発見。
JavaScriptを使うけど、脱jQueryだし、データセットの指定も独特でバッティングし辛そう。デザインもシンプルでおしゃれ。

そんな理由から採用することにした。
ただ、今まで採用していたSemantic UIの画面のこともあるので、しばらくは同居しそう。

さて、テーマ開発なんだけれど、以前うまくいかなかった理由を書いておく。
うまくいかない最大の原因は、クライアントの「あのサイトと同じやつがいい」という要望なんだよね。

ウェブデザインをされている方であればよく耳にする、クライアントの「○○のサイトっぽいもの」とか「○○のサイトと同じもの」とか「○○のサイトを参考にして」みたいな言い回しって、実はコストがめちゃくちゃかかる。
クライアントとしてはヒントを出したわけだからアイデアを出さない分コスト削減に貢献したでしょ？　と思っているかもしれないが、その逆。

特にWordPressのようなテンプレートエンジンに組み込む場合、下手をするとテーマをフルスクラッチで作らなければならなくなって、コスト削減どころかコスト増になる。

では、既存のテーマを流用するとどうなるかというと、やはり設計と構造がすでにある以上、柔軟に対応することが難しい部分が出てくる。
この「一部分」が結構問題になるんだよね。
相手は素人だからちゃんと理解してくれるかどうか分からない。

部分のために全体のバランスを崩してまで解決するか、説得によって妥協してもらうかは予算次第。
(バランスを崩すということは＝デザイン以外にプログラムの書き直しも意味する)

ところが、WordPressと付くと公式テーマが無料なせいか安くできると高をくくっているクライアントが多いので、大抵は低予算。
かくして、妥協してもらうしかないという……。

あと、Elementorやページビルダーのような拡張ビジュアルエディターを使うとクライアント側の保守が楽だろう、という見込みがあるんだけれど、結局は完璧に編集はできないのでトラブルになったりする。中々悩ましいところだ。
Elementorやページビルダーで編集できるのはあくまでも投稿の記事であって、テーマのテンプレートファイルではないんだよね。

そこで狙うべきはビジュアルエディターよりは不便だけれど、テーマをフルスクラッチするよりは低コストな仕組みにすること。
今考えているのは各ウェブページをパーツごとに編集して登録するツールを作ること。
パーツ単位で編集して、それを必要に応じてショートコードで呼び出すことによって低レベルだけれど高いカスタマイズ性を維持できるはず。

また、テーマとプラグインをページごとに切り替えできるようにすることで、ページごとに使用するテーマを変えるといったトリッキーな運用も可能になる。
よしっこれで行こう。