クイズメーカーでWordPressとMTとa-blog cmsのクイズを作った感想


今日からウェビングスタジオの2019年の営業開始です。宜しくお願いいたします。

今年もいろいろとCMSで変わったことをするつもりですが、正月休みにさっそくやっていました。
簡単にクイズを作れるサービス「クイズメーカー」で、WordPressとMovable Typeとa-blog cmsの横断知識がないと満点を取れないというクイズを作って公開しています。

すべての知識がなくても、どれかが詳しければ6割は正解できるようにしています。興味がある方は挑戦してみてください。

https://quiz-maker.site/quiz/play/JtfVPB20190102113456

裏付けを取る

軽い気持ちで作り始めたものの、10問揃うのには丸二日かかりました。問題が正しいかの裏付けを取らなくてはならなかったからです。

例えば4問目の「以下のうち、初期状態でダッシュボードに『最近の投稿』が表示されているCMSはどれか。」はすべてのCMSの最新バージョンのダッシュボードをチェックしなくてはいけませんでした。自社開発のa-blog cmsは、しれっと機能が増えていたりするので…

それを逆利用したひっかけ問題もあります。

思ったより正解率が低い

横断知識が必要なものの、すべて選択方式にするなど、個人的には割と簡単にしたつもりでした…が、正解率は現時点で40%くらいです。ううむ、問題文が分かりづらかったのだろうか。正直すまんかった。

WordPressの基本用語を問う1問目の回答率が、これを書いている時点で33%でした。
私は勉強会で、初心者の人には用語は無理に覚えなくていいと話しています。しかし実務で頻繁に使うようになり、テクニカルディレクションをする場合は話は別です。基本用語の正確な使用は、資料作成の際に、読み手=更新担当者の理解度に直結します。MTユーザーが多かったのかな?と思いつつも、この結果はちょっと残念です。

全く同じ機能は少ない

横断知識を問う問題を作りはじめた段階で、CMS間で機能の概要は同じでも、完全に同じとは限らないということに気付いてけっこう悩みました。

特にテンプレートタグは、細かいオプションが異なるとか、適用範囲が異なるとかの障害が多く、思ったより問題を作ることができませんでした。「これはどのCMSのタグ?」なんて簡単すぎますし…

10問目の問題文に「各CMSの記事中には、常に一点の画像もしくはアイキャッチが存在する前提とする。また、属性は無視する。」という冗長な前提が書いてあるのもそのためです。WordPressのthe_post_thumbnail関数は属性も出力するためです。
更に細かいことを言うと、10問目のMovable Typeは、このタグだけでは期待した動作にはなりません。前後を「記事中にアップロードされたアセットを呼び出す」ブロックタグで囲む必要があります。ここで間違えて「ファンクションタグ」と書こうとしてMovable Typeの公式ドキュメントを調べに行ったのは内緒です。

「クイズを作る」というブレインストーミング

このような高難度クイズになってしまいましたが、せっかくなのでもっとたくさんの人にやってみてほしいです。

クイズを作りながら「CMS間の横断知識を書いたサイト」を作るための構想を練っていました。これは数年前から考えていたことで、「○○をするには△△のCMSでどのようにすればよいか」というのをまとめたいのです。クイズのような軽いものは、ちょうどいいブレストになるなあと思いました。

何かをしたことをきっかけに、新しいアイディアが芋づる式に出てくるかもしれません。迷いも多いですが、私もいろいろ手を動かしてみようとおもいます。


投稿者名 うぇびん 投稿日時 2019年01月07日 | Permalink

2018年の振り返り

2018年もあと3日です。今年は曜日の関係で昨日まで営業日だったので、来年は6日まで休みです。自分の制作やサーバーのメンテナンスをする予定です。 今年は公私ともに、あとでターニングポイントになるだろうと思える年でした。売上や体外活動などは、10周年とは思えないほど微妙でしたが、思ったより自分を責める気持ちはありません。

自分と向き合う



今年の4月1日で、ウェビングスタジオとして開業して丸10年になりました。節目の年ではありましたが、二年ほど続いている体調不良や気力の衰えがひどく、投げやりになっていることを周囲に指摘されるくらいでした。
10周年だからと、無理に何かをはじめても良い結果にならないと思い、仕事のペースを落として弱った自分のケアにあてました。

体調不良については病院を変えて定期的に通った結果、薬が効いて、ずいぶん集中できるようになりました。

さらに、週二回くらいは運動する習慣をつけようと、ウォーキングをはじめました。夏の間は豊平川の河川敷を歩いていましたが、雨の日や冬の日はどうする、という問題にぶち当たったので、今は近所のジムに通っています。

やせるとか筋力をつけるとかは置いといて、自分が苦手としている「細く長く続けること」を重視しています。

気力の衰えについては「なぜこんなに弱っているのか?」「結局自分はどうしたいのか?」という自問を続けています。また「完璧を目指さない」「この状態で8割できればいい」と考えるようにしてきました。
10月から再開したこのブログが自前ではなく、a-blog cmsの公式テーマなのもそういう理由です。

来年からは、またがんばらないといけないなと思っています。貯金ができるくらい稼ぎたいですね。5,000兆円欲しい。

CMS関係の節目

仕事の方では、普段扱っているCMSすべてに、大きなバージョンアップがありました。

3月に、管理画面からのアップデートと大幅なテンプレートエンジンの変更を実装した、a-blog cms2.8がリリース。
4月に、コンテンツタイプを実装したMovable Type7.0がリリース。
そして12月に、ブロックエディタを実装したWordPress5.0がリリースされました。

これに伴って、それぞれのコミュニティは例年よりも活発だったように思います。扱いやすくなったからなのか、私がエバンジェリストをしているa-blog cmsに新規ユーザーがずいぶん増えたのもうれしいことでした。

表では書いていませんが、スマホで更新できる個人的な日記を作ろうと、Craft CMSの構築も少し勉強しました。結局日記は「Bear」で書くことにしたのでそれはお蔵入りになりましたが、UIがすばらしいCMSなので、ぜひもっと勉強していきたいです。

地震のこと


9月6日の深夜、ゲームをやっていて、そろそろ寝ようと思ったところで、体験したこともない揺れがありました。
SwitchとGitHubの丸っこいマグカップが飛んでいきました。うさぎの傍らで何もできずブルブル震えていました。

私が住んでいる地域は道路にヒビが入ったのと、停電の復旧に時間がかかった程度でしたが、それでも物資不足に悩まされる日が一週間続きました。

一ヶ月もすると、街から観光客の姿が消えてしまった以外は平穏を取り戻しましたが、「明日、命にかかわることがあったときに後悔しないか?」と考えるようになりました。いや、どんなに努力しても後悔するとは思うのですが、それだけの気持ちで生きたり仕事したりできているのだろうかと。また、ちゃんと備えはできているのかと。

大杉漣さんやさくらももこ先生など、まだ元気だと思っていた方の訃報が続いたこと、平成最後の年をまっとうしようとする天皇陛下の姿も、気持ちに影響しているかもしれません。

王様ランキング

今年は心に響くメディアにいろいろと出会った年でした。「ラーメン食いてぇ!」「ボヘミアン・ラプソディ」なども心に残りましたが、自分の気持ちに一番影響を与えたのは、ウェブ漫画「王様ランキング」だと思います。

https://mangahack.com/comics/5207

主人公は生まれつき力が弱く、聾唖の障害を持っています。ですが物語が進むにつれ、様々な人との出会いを通して、彼しか持てない能力を見出されて、自分に自信を持つようになります。

その主人公の姿も心打たれるのですが、彼の剣術の師匠が、別れの際にかける言葉がとても好きです。



師匠は主人公に「あなたが気にしていることは、もしかしたらあなたの長所なのかもしれない」「できれば自分の全てを愛しなさい」と言います。

自信を持つということは、自分の長所だけに目を向けるのではなく、自分の欠点(だと思っているだけかもしれない)も愛するということなのかと、じんときました。

同時に、こんな風に相手が求めていることを言い、鼓舞できる人になれたら、とも思います。デスパーさんはナルシストだし金に汚いですけどね。

来年もがんばります



ずっと作っていた、CMSテーマ向けのCSSフレームワーク「echo.css」が、今年の後半になってようやく公開できました。

https://cms-skill.com/echo-css/

まだまだ欠点だらけで、しょっちゅう修正をしています。ですが、現場での現実的な制作を考慮した「私らしい」フレームワークになっていると思っています。このフレームワークは来年も手を入れていきますし、CMSテーマの制作もしたりします。

来年も自分のあり方に悩んだり詰まったりしつつも「昨日より明日を良くするため今日がある」という気持ちで頑張っていきます。どうかお付き合いください。


投稿者名 うぇびん 投稿日時 2018年12月29日 | Permalink

2019年からMovable TypeはASP版の.netを主力にしたい


これはMovable Type Advent Calendar 2018の、15日目の記事です。

Movable Type Advent Calendar 2018 - Adventar

Movable Type 7がリリースされてから、MTDDC HOKKAIDOやCMS Mixやパワーユーザーのブログを通して、一年間今後の事を考えてきました。その結論として、今後の業務での主力はMT7ではなく、ASP版のMovable Type.netにしようと思います。

https://movabletype.net/

誤解のないよう早めに論旨を書きます。消極的な意味で言ってるのではないです。

  • .netの運用に特化した機能追加がすごいっていうかやばい
  • パッケージ版と私とa-blog cmsの関係の変化
  • 私とWordPressの関係の変化
  • 原点への回帰

という理由です。

.netの運用に特化した機能追加がすごいっていうかやばい

MovableType.netはリリースから三年以上が経ちました。リリース当初はあくまでMovable Type6の軽量版に過ぎなかったのですが、現在ではMovable Type 6の主要機能をすべて引き継いでいるだけでなく、常に活発な機能追加・改良が行われています。

特に、パッケージ版のMTでは難しかった、外部連携と運用に関する機能には驚きます。「Movable Type.net活用ブログ」を見ていただくといいですが、特に「えええ?レンタルでそこまでできるの!?」と思ったのは以下です。

IFTTT向けのWebhookに対応しているのは大きいです。Slackに限らずなんにでも投げられそうです。.netではページを公開せず、何かのハブに使うという新しい運用もできるかもしれません。

パッケージ版と私とa-blog cmsの関係の変化

パッケージ版に関して、昨年はMT7を前にして駆け込み的案件が多かったのですが、今年は少なくなっています。おそらく各企業が様子を見ていて、安定した来年から増加するのだろうと予測しています。ただ、札幌市はMTを専門としている会社が多いので、専門ではない私のところにどのくらい相談が来るのかは不透明です。

そんな中、秋のa-blog cms Training Campで、a-blog cmsにコンテンツタイプ機能が実装されるという話が出ました。厳密には既存のブログのコンフィグをパッケージ化して、複数のブログで使い回せるようになるのですが、原理としては他のCMSとあまり変わりません。

a-blog cmsもリリースから10年が経ちます。機能追加や大型化が進んだことで、だんだんMovable Typeパッケージ版との立ち位置のかぶりが多くなってきました。

また、私の中で軽量CMSにどれを使うかというのが決まっていませんでした。Jimdoはブログに難がありますし、BaserCMSやCraftも悪くないのですが、私に来る案件(かっちり系のコーポレートサイトが大半)にいまいち合致しません。軽量なままで機能が増えて、かつこれまでのリソースを活かせる.netを推さない手はないと考えています。

もちろん、MT7も引き続き勉強するので、案件のお手伝いやバージョンアップは十分できると思います。

私とWordPressの関係の変化

推さない手はない、と書いたものの、私がCMSの種類を提案できる案件はとても限られています(以前より増えましたが)。相変わらず、WordPressになるケースが多いです。主に以下の理由です。

  • 初期予算がない(というか抑えなければならない)
  • クライアントがずっとWordPressを使ってきたので乗り換えたくない
  • WordPressからの移行コスト(CMSを乗り換えると一年分の保守コストを上回ってしまう)

一方で、「補助金制度」というものがあることも知りました。それを活用するようなサイトであれば、初期予算がない問題はクリアできます。そしてWordPress5.0のGutenbergです。私は気に入っていますが、ざっとツイートを調べた限りでは一般ユーザーの混乱は大きく、これまでのセキュリティの問題もあって、以前より乗り換えの意識は強くなっています。

こうなると、あとは私の説得力になってきます。

原点への回帰

まあとにかく、正式なアカウントを取って公開サイトを運用して、インプット・アウトプットしないとと考えています。a-blog cmsでもそうしてきました。

個人的な理由になりますが、MovableType.netを見ていると、MTを使い始めた頃を思い出します。
15年前、当時はやっていたウェブ日記が不満で、手探りでMTをインストールしました。あの頃は自分が書いたコードや記事がHTMLで書き出されるのが本当に楽しくて、毎晩「これでどんなサイトが作れるだろう」と試行錯誤していたものです。

MovableType.netは、あの頃の私が望んでいた「MT3.0が成長した姿」かもしれないです。


.net案件は、既に何度か経験済みですので、いつでもサイトを構築できます。また、MT7に関しても良い会社をいろいろ知っていますので紹介可能です。お気軽にウェビングスタジオまでご相談ください。


投稿者名 うぇびん 投稿日時 2018年12月14日 | Permalink

a-blog cmsの、include・extendの実案件での活用について

これは、a-blog cms Advent Calendar 2018の12日目の記事です。
a-blog cms Advent Calendar 2018 - Adventar

今回は、かなり制作者向けの記事です。a-blog cmsを利用していても、運用やディレクションが中心の方には、少し難しい内容であることを前置きしておきます。ですが、テーマの制作をしている方は、ぜひ読んでいただけるとうれしいです。

はじめに

北海道住宅新聞社さんの情報サイト「いえズーム」の管理をはじめてから、一年半くらい経ちます。

【iezoom】(いえズーム)北海道の住宅会社選び | いえズーム(iezoom)

いえズームの制作をはじめた頃は、「includeの変数渡し」「extendによるコードの継承」はリリースされていませんでした(バージョン2.8.0から)。 旧来のインクルードを使用したまま改修を重ねていたら、テーマがカオス化してきたこともあり、新しい機能を使用してコード整理をしています。

新しい機能のそれぞれの特徴と、いえズームでの実際の利用場面を紹介します。

includeの変数渡し

概要

旧来のインクルードは、SSI風の書式で、読み込むファイル名を指示するのみのシンプルなものでした。

<!--#include file="/path/to/filename"-->

しかし、2.8以降では、JSON風の書式で、読み込み先で使用できる独自変数を渡せるようになっています。

@include("/path/to/filename", {"key": "value", "key2": "value2"})

詳細な仕様解説は公式ドキュメントを参照ください。
インクルード | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。 「sample_01.html」と「sample_02.html」は同じパーツ、module.htmlを読み込んでいますが、変数「button」の値が異なるため、実際に表示されるコードが一部変わります。 「sample_01.html」では、新着記事一覧の下に「詳しくはこちら」ボタンが表示されるはずです。



includeの特徴

includeの変数はグローバル変数ではないので、読み込み先以外に干渉することはありません。いくつでも渡すことができ、変数の初期値も定義できますが、長いコードを渡すことはできません(できたとしても可読性が著しく落ちます)。

extendによるコードの継承

概要

いっぽうextendですが、WordPressやa-blog cmsに実装されている「親・子テーマ」の「コードの使い回し」を、テンプレート間で実行することができます。

テンプレート冒頭で「@extend」を書くと、指定したファイルを丸ごと読み込むことができます。ここまではincludeと変わりませんが…

@extend(/path/to/filename)

指定した読み込み元のファイルに「@section(任意の英数字名) 」〜「@endsection 」で囲んだ領域があると、読み込み先のファイルでコードを上書きすることができます。

@section(sample)
  <h2>内容を書き換えちゃうよ!</h2>
@endsection

つまり、読み込み先では、差分コードだけ記述すれば良いのです。

詳細な仕様解説は公式ドキュメントを参照ください。
テンプレートの継承 | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。
レイアウト用に作成した非公開テンプレート「_layout.html」のコードを3つの公開テンプレートで使い回していますが、それぞれ実際の表示結果が変わります。特にsample_03.htmlの「継承しつつ追記」はいろいろ便利です。



extendの特徴

extendは、前もってレイアウト用のテンプレートを作り、どの箇所を継承可能にするか定義することになります。

長いコードをテンプレート間で渡すことができるので、似ているけれど微妙に違うレイアウトが多いサイトでは、書くべきテンプレートの行数を大幅に節約できます。反面、includeとは異なり、条件分岐などに使える変数を渡すことはできません。

いえズームでの活用

includeの変数渡し

いえズームは一見シンプルなサイトですが、訪問者の導線を意識しているため、コンテンツごとに記事の表示件数や体裁、ページ内での表示位置などが細かく違っています。改修を重ねているうちに、モジュール部分のテンプレート数が肥大してしまっていました。

例えば「summary_sub_story_future」モジュールと「summary_sub_story_recent」モジュールは、IDが違うだけでコードがまったく同じなのに別ファイルになっています。

<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_future" -->
・・・
<!-- END_MODULE Entry_Summary -->
<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_recent" -->
・・・
<!-- END_MODULE Entry_Summary -->

これを、includeの変数渡しに書き換えることで、ひとつのファイルでidだけ違うコードを出力することができました。

さらに、なんと、読み込み先のincludeのファイル名に変数を引き継ぐことができることに気付いてしまいました。エントリーの繰り返し部分の体裁だけが違うテンプレートも共通化できそうです。

@include("/include/module/summary_sub.html", {"mid": "summary_sub_story_recent", "loop": "story_media.html"})
<!-- BEGIN_MODULE Entry_Summary id="{{mid}}" -->
・・・
@include("/include/module_loop/{{loop}}")
・・・
<!-- END_MODULE Entry_Summary -->

extendによるコードの継承

いえズームは、すべてのページのフッタ上部に、「いえズームとは?」というサイトの概要が記載されています。



ですが、一箇所だけ例外があります。地域別企業一覧のページでは、ヘッダの地域紹介の直下にあるのです。

札幌圏の住宅会社(ハウスメーカー・工務店)一覧 | いえズーム(iezoom)



地域ページは、冒頭に地域情報のパーツがあったり、地域名を変数に入れていたりと、かなりレイアウトが異なっています。以前は地域ページだけまったく違うテンプレートを用意していたのですが、extendを使うことで、他のテンプレートが利用している「/_layout_col2.html」との共通化ができるようになりました。

@extends("/_layout_col2.html")

@section(head_before)
(地域名を変数に取得)
@endsection

@section(pagehead)
(地域情報とサイト紹介パーツ)
@endsection

以下略

まとめ、使ってみての雑感

このように、わかりやすいところから少しずつコードの整理をしています。

使ってみての感想は、やはりテーマ職人としては、extendが手応えがある分面白いなあと感じています。大幅にテンプレートの数を減らせそうです。ただし、テーマ全体の構成を把握していないと実装できませんから、コーダーとテーマ制作者が違う案件では苦戦するかもしれません。

includeの変数渡しは便利な反面、インクルード先のテンプレートで、その変数がどこから定義されたものなのかわかりにくいという欠点があります(変数名でテンプレートを検索すればいいのですが)。 同じような変数名を使いすぎてカオス化しないよう、ルール決めが必要です。

いえズームは現在も、数週間に一度のペースでコンテンツの改修や追加が続いています。 このため、私も手早く対応できるようにしなければなりません。テンプレートを整理することで余裕が出て、より良い制作や提案ができればと期待しています。


投稿者名 うぇびん(管) 投稿日時 2018年12月11日 | Permalink

WordPressのブロックエディタ「Gutenberg」に対して私たち制作者が考えなくてはならないこと

WordPress5.0がリリースされ、噂のブロックエディタ「Gutenberg」が正式実装されました。

現在私は、同じ構成で構築された、いくつかのWordPressサイトの運用のお仕事をしています。 そのサイトがGutenbergの導入でどのような影響を受けるかの検証と、それだけではなく、今後CMSを扱う立場としてGutenbergとどのように関わっていくかを、この週末に、ざっくりですが検討していました。

Gutenbergさんとどう付き合うか

まず、投稿タイプなどを追加していない、WordPress5.0の基本の状態でGutenbergをひととおり試しました。

私は、10年前からブロックエディタを搭載していたことで知られる、a-blog cmsを長年使用しています。また、スマートなブロックエディタを実装しているブログサービス「g.o.a.t」を一年ほど利用していました。

その経験を含めての感想としては、
「思ったより怖くない」
「これは『ビジュアルエディタの次世代としては』かなり良いのではないか」
です。

基本的に、ブログ記事などでは、HTMLの要素は見出し・本文・リンク・強調・各種サービスの埋め込みくらいしか使いません。それらについては軽快に書けますし、以前のビジュアルエディタとの操作の差も意外と少ないです。 驚いたのが「既存のビジュアルエディタ」がブロックのひとつとして用意されていることです。重くなりそうですが、どうしてもあのエディタでないと、というクライアントへの説得要素にもなるでしょう。



ウェビングスタジオとしては、新規案件の緩いコンテンツなど、利用しやすいところでは積極的に受け入れていきたいし、カスタマイズを学習していきたいと考えています。

長年WordPressを使い込んで、多数のプラグインやPHP拡張を活用してきた人ほど、Gutenbergは厄介な存在でしょう。 WordPressはオープンで自由なCMSです。一切使わない選択肢も用意されていますから、個々の制作者の自由でいいと思います。

使いたくない場合

一方、コンテンツ・マネージメント・システムとしてWordPressを使う場合、「投稿タイプによって適しているエディタが異なる」という問題が生じます。

例えば私の件の運用サイトの場合は、以下の3つの投稿タイプを持っています。

  • post・・・ブログ記事
  • page・・・がっつりマークアップした渾身のメインコンテンツ
  • works・・・カスタムフィールド職人らしいフィールドのみのコンテンツ

worksでは、「Advanced Custom Fields Pro」のリピートフィールドで、こんな感じの簡易なブロックエディタを作成しています。簡易な方が操作しやすく、更新の効率が良くなるということは往々にしてあります。



この場合、pageとworksでGutenbergを使うことはできません。

このように、第一に制作者が考えなければならないのは、現在運用しているサイトの各投稿タイプで、Gutenbergにしても問題ない箇所と、使ってはいけない箇所を明確にしておくことです。

では、特定の投稿タイプだけ無効にすることはできるのでしょうか。管理画面にもそういった項目は見当たりません。困っていたら、WordPressをはじめとするいろいろなCMSに詳しい安部さんがTwitterで教えてくれました。

これです。ドンピシャです。 高橋文樹さんが、Gutenbergがベータ版の頃から各種回避策を書いてくださっていたようです。

Before Gutenberg アーカイブ - Capital P

pageとworksでブロックエディタを無効にすることで、これまでのWordPressと変わりない環境にすることができました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

プラグインとの衝突問題

次に考えなければならないのは、プラグインです。

一通りコンテンツを確認したところで、カスタムフィールドを管理している「Advanced Custom Fields PRO」の編集画面に入ったら、ページが真っ白になりました。 フォームプラグイン「MW WP Form」も編集画面だけ真っ白になっています。

プラグインは問題がないと思っていただけに慌てましたが、これについても高橋文樹さんがすでに原因を書いていました。 “エディターのない投稿タイプは動かない” そうです。

Before Gutenberg - カスタムフィールド職人の命運やいかに? - Capital P

つまりプラグインの投稿タイプでも無効にしなければならないわけで、最終的に以下のようなコードになりました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'acf-field-group' )
        ||( $post->post_type === 'mw-wp-form' )
        ||( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

あまりスマートじゃなくなってきました…postだけ許可する、ホワイトリスト方式にした方がいいのかも。

この不具合については、頻繁に更新されているプラグインであれば早い段階で解決されると期待していますが、しばらく混乱は続くのでしょう。 これを機に、プラグイン制作者に問い合わせる前に、まず検索する習慣を身に付けたいものです。

既出かもしれませんがQiitaに寄稿しました。

WordPress5.0でプラグインの新規追加画面・編集画面が真っ白になった場合の対処 - Qiita

発展途上?なUI

ざっと使ってまず気になったのが、「ブロックを追加・挿入するボタン」の表示がわかりにくいことです。

最後に追加するならEnterキーを押せばボタンが出るのですが、挿入の場合は、前のブロックにマウスを置くと出る枠線の「上の線」にカーソルを置かないとボタンが出てこないのです。これがかなりシビアな操作になっています。 それ以前に、感覚的には一般に「下に追加する」と感じるので、一つ前のブロックの下線にボタンが出るべきじゃないですかね…



ボタンブロックについても、色の選択があるのですが、よりにもよって背景色だけでなく文字色まで自由に選択できるUIになっています。

サイトを明るくしようとした更新担当者さんが、ボタンの色をピンクとかライムにする未来が見えます。

これがインラインスタイルで入るのか、クラスで入るのかまだ確認できていないですが、とにかく色は個別に選ばせたくないですし、外観についても丸と四角、塗りつぶしとボーダーはそれぞれどのような役割で使うのか決めておかないと、わけのわからないことになります。


また、WCAN 2018/10でたにぐちさんも指摘されていましたが、パーマリンク設定の場所もわかりにくいです。WCANに参加していなければ見つけられませんでした。更新担当者にパーマリンクをいじらせてはいけない、という禁止系インターフェース…と考えられなくもないですが。

たにぐちさんがさらに指摘されていた「なぜかテキストブロックの文字の寄せ方向だけ、クラスではなくインラインスタイルになっている」件は、私はあまり気にしていません。文字色などとは異なり、文字の寄せ方向はテーマやCSSが変わっても、同じであることが多いからです。しかし、UIのブレであることは確かですし、インラインスタイルは優先度が高いので、上書きしようとするとimportantまみれになる問題があるのですが…

少なくともこれまでと相当感覚が違うので、リモートで運用をしている場合は、更新担当者にどのように操作説明をするか考える必要があります。 a-blog cmsユーザーの多くがやっていたことですが、往訪できない場合はブロック一種類ずつに対して、操作している動画を撮って見ていただくのが確実と思います。

特定のブロックを使わない自由はあるのか

ボタンのところでも触れましたが、Gutenbergの「機能が多すぎる」ことも私の中で課題になっています。 多数のブロックがありますが、すべて対応していられないとか、コンテンツの性格上、使ってほしくないケースもあります。

私がa-blog cmsを気に入っているのは、コンテンツ(ブログ)ごとに、使用できるブロック(ユニット)を管理者が指定できることです。 もう少し情報を調べれば既に出ているのかもしれませんが、特定のブロックを使わない自由を公式に設けてほしいものです。

Gutenbergさんは悪くない、悪くないんだ

繰り返しますが、私はGutenbergが気に入っていて積極的に使いたいです。

ただ、日頃「すべての人が自由に気軽に使えるCMS」を謳っていながら、「ユーザーが、GUIを通して機能を選択(無効ではない。選択)できない状態でリリースした」強引さに若干呆れています。

今後各国のWordPressコミュニティは、一定のウェブ制作の知識を持たない人(いわゆる個人ブロガーなど)へのサポートを切り捨てるか、これまでのようにGUIで管理できるプラグインの開発やブログ記事などの情報を充実させるかの、大きな選択を迫られるのでしょう。

個人へのサポートを既にやめている私としては、前者が幸せじゃね…?と思ってしまいつつ、制作会社・企画会社との協業媒体としてのWordPressに、Gutenbergをどう活用していけるか、前向きに考えていきたいと思います。


投稿者名 うぇびん(管) 投稿日時 2018年12月09日 | Permalink