ブログ用はブログ用でしかない

それらのレディメイドテンプレートはほとんど『ブログサイト向け』の構造になっています。
つまり、単体ブログを基盤として全ての記事詳細ページ、それにカテゴリや月別アーカイブページ、というブログ型のテンプレートとなっています。
単なるブログ単体のサイトマップを作りたい場合はそれで十分ですが、MovableType は特に中規模サイトCMSとして利用されることが多く、1サイトに複数のブログが存在する場合は専用テンプレートをコーディングする必要があります。

複数ブログの更新情報を全てまとめる

XMLサイトマップを出力させるブログを1つ選び、インデックステンプレートを作成し、サイトマップフォーマットに従って MultiBlog タグで他のブログを順番にインクルードしてサイト全体を俯瞰するサイトマップを出力します。

そのブログは各ブログからの再構築トリガーを設定しておきます。一般的にはトップページとXMLサイトマップ、RSS出力だけのためにブログを１つ設ける形が多いと思われます。

MovableType を巧みに設計して使っている ＝ 非常に複雑な設計である場合が多い為、いわゆる誰でも使える汎用テンプレートは作りにくく、その都度サイト構成を考えながらテンプレートをコーディングしていく必要があります。

例えば製品情報とニュースリリースをブログ、その他のコンテンツも全てウェブページとしてMovableType配下に置くサイトがあったとすると、

製品情報コンテンツを出力するブログはニュースリリースブログよりプライオリティを上げてループ処理で出力し、次にほとんど固定情報となる会社情報を直書き、ニュースリリースをループ出力、あとは細かいページを直書き。

といったコーディングが考えられます。

出来るだけ詳しく、正確に

例えばXMLサイトマップの書式の中で

• lastmod：最終更新日時を表す（例 2009-08-20T12:12:33+09:00）
• changefreq：更新頻度を表す（例 daily, monthly, yearly）
• priority：重み付け（例 0.1〜1.0）

は省略してしまっている場合も多いですが、不確実な情報やスパムまがいのテクニックばかりが氾濫するSEO対策処理の中、確実な部分は確実に作り込んでいくべきだと考えています。

また出力したサイトマップファイルを Google ウェブマスターツール や Yahooのサイトエクスプローラー に登録する処理も忘れずに行いましょう。

最後に

この辺りの細かい作業はWEB制作している人でも知らない人がいたりします。
あえてお客様に説明するほどでもない細かくて見えない部分ではありますが、制作側でできる最大限の事として手抜きせずに行いたい作業です。

※ここに書いた「ブログ」「サイト」という概念はMT4までのもので、MT5では若干変わってきます。

クライアントから受け取った原稿がWordのなんの構造情報もない、広い草原のように平たいファイルだということはよくあります。まあそれは致し方ないとしてもExcelでセルごとにレイアウトされた日にはもう泣きそうになりますから、その考え方には賛成です。

今回はそれを実現するために、DreamweaverとContributeを使った方法を紹介されていたのですが、よっぽどの超大規模サイト、大規模制作会社でない限りその方法を採用するメリットはないように思えました。（もちろんそういう会社の方の話なので当たり前といえば当たり前ですが…）

比較的小さな規模でそれを実現するには例えばどういう方法があるか、を私なりに構想してみます。

制作環境としてMovableTypeを利用する

公開環境ではなく、制作環境の母艦としてMovableTypeを利用するというのはどうでしょうか。

1. まず自分とクライアントだけがアクセスできるテスト環境にMovableTypeをインストールします。そしてサイト構成やワーヤーフレームが決定した段階でHTML、MovableTypeテンプレートにしてしまいます。もちろんワイヤーフレームに沿って共通項目は全てモジュール化します。
2. 管理画面も分かりやすくカスタマイズし、更新権限をクライアントに渡します。クライアントはブラウザから入力項目に沿って入力していくことで、原稿を作成していきます。見出し等は入力項目そのままで、wisywigもルール（改行を連打しないでね等）を守って入力してもらえば出力タグは制御できます。
3. 同時進行でデザイニング、そしてデザインをCSSでワイヤーフレームのHTMLに実装していきます。
   ２つの作業が終了した段階で、既にサイトはほぼ完成しています。
4. 最後にMovableTypeスタティックパブリシングで再構築して出力したHTMLファイルを公開サーバにアップロード。
   もちろんこの段階で「更新も簡単なCMSサイト」が出来上がっている訳なので、あえて静的ファイルを納品する意味はないですが、その辺は初期予算や更新や保守をどうするかという営業的な事情によって、でしょうか。

ということで、別にContributeのような特別なソフトウェア環境、また MSOffice ような一手間増えるファイル形式をクライアントに要求しなくても、誰でも持っているウェブブラウザを使った新しいワークフローは実現できてしまいます。
ここでMovableTypeとしたのは、オープンソースの中でもモジュール管理系がやりやすいかなと思っただけで、もちろん他のものでもいけると思います。

といえど、会社としてのワークフローについては、他にどんないい方法があっても簡単には変えられないものだと思います。

会社のワークフローは古風である必要すらある

ワークフローの統一はは会社の複数人での業務効率化という意味では大切だけど、逆にそれに縛られてしまうという面も確実あります。

会社としてのワークフローがしっかりしていればしているほど保守的であり、古風である必要すらあるのです。

例えば誰かの1人の能力が高く新しい方法を採りたくても、ディレクタを含め制作者全員が理解できるレベルにないとそれを社内フローとして定義することは出来ません。

1年前の手法が古く感じるこの世界だからこそ起こる仕方のないことだと思いますが、この辺り、WEBデザイナーのフリーランス転向率が高い理由の1つじゃないかなと思っています。

Dreamweaver を捨てるとまではいかないが

私も数年前までは Dreamweaver をバリバリに使っていました。
上のイラストは誇張でありゴミ箱に捨てるまでは行きませんが、今では起動することすら滅多にありません。

そもそもオープンソースCMSがこれだけ充実した今、HTML管理ソフトで微動だにしない静的HTMLファイルを大量生産すること自体、あまり意味ではと感じています。

CMSにする予算がないからだよ！とつっこまれると思います。しかしこれは私の感覚ですが、10ページ超えるくらいであれば CMS にしちゃった方が制作工数は少なくできてしまう場合は多いです。

メインとなる絵はイラストレーター、ほんまきよこさんによるものです。

頂いたイラスト原画をスキャニングする所から始め、紙ではなくWEBで表す上での制限の中、どれだけ絵本の雰囲気を残し、どれだけWEBとして機能するHTMLで表現するかに専念し、そのHTMLを更新しやすいCMSに落とし込みました。

1つ1つ情報構造が全く異なる各コンテンツページ、またスタッフの皆さんで更新する3つのブログを全て同じ管理画面で更新できるよう、MovableTypeを細かくカスタマイズしています。
表示される全ページがMovableType（MT4）生成で、全ての更新作業はWEBブラウザから行います。

1枚の原画からマウスオーバーやノートの無限繰り返しを表現するために、スキャンした原画を切り抜きやスタンプを利用して手作業でレイヤーに分けていく作業が少し大変でしたが、どんなサイトになるのか自分でもワクワクしながら制作することができました。

イラストレーターほんまきよこさんのサイト：うたたねハンモック

コスモホームさんには雑貨店『eco shop 和』が併設されていて、エコな雑貨やイベントなどで家を建てる人以外の人も集っています。
名古屋近辺の雑貨好きの方にはぜひおすすめです。

私は商用サイトCMSとして利用する場合、通常版の5万円のライセンス料は全く高くないと思っています。
制作側・運営側のメリットを考えると十分すぎるほどのコストパフォーマンスがあると思います。

しかし、CMSを使うメリットが理解できていない人にとって5万円というのはハードルであり、ライセンス料を制作費で消化するか別請求するかはおいといて、初期予算が20万30万といった小規模サイトにとっては大きな問題となるのは明らかです。

費用だけで採用するCMSを比較する事は出来ませんが、このような小規模案件にとって大きな選択肢の１つとなってきそうです。

オープンソースとは無料ではなく無償。
あくまでユーザフィードバックを元にした現在進行形の構造であることを忘れずに、SixApart社に敬意をこめて活用していければと思ふ。

MovableType.org “Movable Type Open Source”

Can’t call method “archive_url” on an undefined value at lib/MT/Template/ContextHandlers.pm line 2212.

というエラーメッセージが表示されてユーザを作成できないというエラーに遭遇。
CustomFieldsプラグインの一部を修正することで解決。

環境
MT 4.01 with CustomFields 2.1b4

解決策
plugins/CustomFields/tmpl/reorder_widget.tmpl
にある <mt:staticwebpath> というタグを　<mt:var name="static_uri">　に置換。

source：http://plugins.movalog.com/forums/

今回は解決策が見つかったが、MTをフルカスタマイズして最終段階の時にシステムエラーが出るのは非常に怖い。
CustomFieldsのようなシステムに割と大きな変化をもたらすプラグインを利用する際、システムの各設定・動作に問題が出ないか、早い段階でチェックしたい。