著者： Jeffrey Veen
日本語訳： yomoyomo
以下の文章は、Jeffrey Veen による Making A Better CMS の日本語訳である。
最近 OpenSourceCMS.com――数十もの CMS がインストールしてあって遊べるファンタスティックなサイト――で少し調査を行ったのだが、かなりがっかりさせられた。僕が体験したのは、ユーザビリティやユーザ体験がないがしろにされて余計な機能が詰め込まれた分かりにくく手間のかかるソフトウェアだった。ギークによる、ギークのために書かれたソフトウェアだったんだ。
その体験により、僕の自説への確信が強まった。つまり、ほとんどのオープンソースのコンテンツ管理ソフトウェアは使えない。これより悪いものがあるとすれば、僕がこれまで使ったことのある商用 CMS すべてということになる。だけど、だからといってそれを好きになる義理はない。
このカテゴリのソフトウェア全体が、執筆者、編集者、デザイナー、そしてサイト所有者のことを考慮して徹底的に再設計されるべきだ。以下にオープンソースのコンテンツ管理システムを書いている人たちへの僕の忠告を記しておく。
ツールを公開する前に、ユーザがソフトウェアを入手してから行う操作をじっくり考慮すれば、あなたのツールはもっと採用されるようになるに違いない。僕としてはダウンロードし、ファイルを展開し、ブラウザでインストーラを走らせたいんだ。二三質問に答えれば、データベースのテーブルを設定し、PHP の設定ファイルや何やらを記述する。
こうなるように制約を課すことだ。つまり、ソフトウェアをダウンロードしてから稼動するまでの10分間、決してユーザにコマンドラインを使わせてはいけないし、テキストエディタをユーザに開くよう強いてもいけない。それは難しいだろうが、難しい問題を解決するのはおたくら得意なんだし、ここのところにかなりの時間が費やされているのだから。
処理がいよいよ複雑になる前に、初めて利用するユーザに一連のクイックウィン（quick wins）体験を与えること。初めてログインする場合、僕はまずウェブページを作りたい。次はいくつかスタイルを追加したい。それから他のウェブページにいくつかリンクをはりたい。その後ナビゲーションシステムを構築し、ようやく他の機能を追加し始める。しかし、システムを使い始めて最初の数分のうちにうまくいっているという感覚を得たいのだ。自分の環境に慣れるまでは、指一本動かすだけで驚くべき力をひけらかしたいとは思わない。
コンテンツの人気ランキング、動的 PDF 生成、コミュニティ・フォーラム、そしてユーザ投票は後にとっておいていただきたい。いずれそうしたものを欲しいと思うかもしれないけど、はじめてログインするときには必要じゃないから。
ほとんどのシステムに、本当に優れたインストールガイドがある。「最初にこれをして、その後これとこれ、そしてこれをしてください」しかし、実際に CMS を使う段になると、各機能の動作概要を丁寧にまとめた機能ベース（feature-based）のドキュメントに戻ってしまうし、そうしたのは概してシステムのバックエンドから見たものになる。
覚えておいてほしいんだけど、僕はすぐに使い始めたいのだから、基本手順をやる順序にそって書いてくれよ。最初にユーザを作成しなくちゃならないの？ 今すぐテンプレートを作ることは可能なの？
僕はスクリプト言語や基本的なコンピュータサイエンスの考え方を十分習得している。自分用のテンプレートは書けるし、必要とあらばオブジェクト指向の Perl や Python のコードに分け入ることだってできる。では、なぜ僕はどのオープンソースのコンテンツ管理システムにも困惑するのだろう。
ほとんどのシステムに管理者とユーザの概念があることは僕も承知している。でも、その変更を行うのにアカウントの切り替えが必須であるべきではない。つまり、両者をインタフェースで分けろということ。
覚えておくこと：あなたのオーディエンスの98パーセントは、システム管理ではなくウェブサイト管理用に CMS を利用している。なのにほとんどのシステムは、その2パーセントのほうに最適化されている。
僕がこれまで働いたことのあるどの組織も、一般公開するウェブサイトとはまったく独立したコンテンツ管理用インタフェースを保持していたが、オープンソースの CMS はほぼどれも両者が混在している。
これらのシステムは、誰もがアカウントを作成し、管理されているサイトから直接その CMS にログインする仕組みを提供しているわけだ。うん、テンプレートを編集してこれを取り除けるのは知っているけど、この機能を本当に必要としているサイトって、オープンソースのプロジェクトだけじゃないかな。この機能は、あなたがオーディエンスを誤認している兆候なのだ。
僕にはポートレット（portlet）が何であるか分からない。さらにいえば、コンポーネント、モジュール、ブロック、それにスニペット（snippet）も分からない。僕がこないだ評価したシステムには「mambots」なるものがあったんだけど、僕には授乳を支援するロボットのように聞こえたね。
マーケットにおける自製品の差異を宣伝するために単語を作り出しているだろうか。もしそうなら、それは止めること。混乱させるだけだ。システムの機能を説明するのに簡単な単語を使うようにしよう。
僕が使ったことのあるかなりの数のシステムが、3カラムレイアウトの概念を採用している。そうしたシステムには、カラムを切り替え、「コンテンツ挿入口（content-slots）」に「ポートレット」を入れる機能が提供されていた。この前提は何に由来するのだろう？
この二年間、僕はカラムのあるウェブサイトは一つだって構築したことはない――またそれらのサイトは、アクセス数の多い商用サイトである。マークアップはすべて連続して書きくだされ、それから CSS を使って希望するどんなカラムフォーマットにもスタイル化される。あまりにも多くのコンテンツ管理システムが、あまりにもコードの深いところまで3カラムレイアウトに凝り固まっているので、それを一掃しようとすると相当なハッキングを要する（君のことだよ、Plone 君）。
皆がテーブルを用いないレイアウトを使い始められるようになったのが二年前なのかもしれないが、どうしておたくのツールは以前のままなの？ 僕がただ「これらの機能をこの順番で表示したい」と指示し、それから表示のすべてを行うスタイルシートを適用できるようなれば、どれくらいおたくの CMS が使いやすくなるか考えてごらんよ。
あらゆるサイトに適合する CMS などないことは承知しているが、「うん、PHP-Nuke を試してみたんだけど、全部が Nuke っぽい見た目になっちゃって」みたいなことを何度聞いたか分からない。それはつまり、ほとんどのシステムは、特定のジャンルのサイト向けにデザインされることを示している。機能やら機能性が基本的なフレームワークの上に追加され、パッケージ全体はアドオンや誤った前提条件がごちゃごちゃになって公開される。
結局のところ、コンテンツ管理システムは執筆者や編集者がコンテンツを作成し、自分達でメンテナンスを行う力を与えるものであるべきだ。僕としては、それが更に一歩前進するところを見たい。つまり、デザイナー、情報アーキテクト、そしてサイト所有者に、CMS を彼らのために機能させることで力を与えるのだ。