(x)HTMLの煩雑さと文書構造のマークアップ

あるシステム会社との打ち合わせをしていた時に先方から

「MovableTypeって、流行ってるみたいだけど、結局のところ使いづらいよね」

なんて言われた。
ある見方をすればその通りだし、他方違う見方をすればそうともいえない有用なツールだとも思う。

Web デザイナーに求めたい 5つのこと | WWW WATCHを読んで思ったんだけど

先にもちょっと触れましたが、今後の Web サイトは、様々なデバイス、ユーザーエージェントによるアクセスへの柔軟な対応、様々なプログラムとの連動やコンテンツリミックスなどを視野に入れながら設計していかなければいけなくなるでしょう (というよりすでになっている) 。その際に、文書構造と見た目を分離、またソースをコンパクトにして (X)HTML 文書の再利用性を高めておくことは必然。そのためには Semantic なマークアップも必須でしょうから、普通に考えれば table レイアウトなんて選択肢はないんじゃないかなと。

たしかに、しこしこと手打ちで(x)HTMLのコーディングをやっていて悩むのが、どれだけ文書構造をふまえた構造を維持するべきなのかってところ。

自分でコーディングの仕方を判断や決定できるモノに関しては、「自分ルール」を基準に、コンテンツの下書き(見出しや段落の意味に合わせたマークアップ)を最優先でデザインをハメていく手段(デザインを無視しているわけじゃない)をとっているけど、(x)HTMLに明るくないWebサイト更新担当者が更新するためのシステムの導入にかかわると、文書構造云々なんてただのオナニー(エロくないほう)じゃないのかと思ったりもする。

MovableTypeの不便さ

いくつかのMovableTypeの設置やデザイン、CMSっぽい導入とかを手伝っていていろんなギャップを感じるな。
MovableTypeを使ってもらって多く聞くのが

  • 書いている記事がどんな感じに表示されるかわからない
  • 画像の配置をドラッグアンドドロップできたら良いのに
  • ここの文字、赤くできないの?
  • ここの文字、大きくできないの?
  • せっかくスペースいれて、ツラあわせしたのにちゃんと表示されないじゃないか!
  • livedoorみたいにデザイン変えれないの?

ごもっとも。
そうだよね、標準の状態じゃMovableTypeって使いにくいかも。(次期バージョンでは画像管理がマシになりますなんていっても無理)

顧客からの「文書構造的に正しくない要望」

でも、これらの要望は導入前の設計の時点でいくつかのプラグインと多少の配慮をすれば可能になるし、いくつかWYSIWYGを実現するものもあるので、対応は出来るんだと思う。
じゃ、WYSIWYGを可能にするプラグインをいれれば解決。

で、コードはどうなっているのかってところが気になってくる。

そこにはパラグラフ(<p>とか)がどうとか、見出しのマークアップ(<H1>)なんて関係ない。
更新した担当者のセンスを元に、すべてが太字になっていたり、パラグラフ全体が真っ赤になったり。
改行されずに、前の行末から次の行頭までは全角スペースでうめられていたりする。

要望に応えるためのジレンマ

そんな状態をみると
「はぁ〜一生懸命構造を考えたのに…」
なんて、落ち込みそうになるけど、そこは自分がわかりやすいガイドラインを提供できなかったのにも原因があるんだろうし、そもそも「ブログの感覚」を持たせてしまったの最大の失敗なんだと思う。

「ところで、デザインもサクッと変えれるんだよね。」

「え、えぇまぁ…」(そんなの文書構造がしっかりしていないと…)

クライアントのリクエストを実現しないと!

でも、これはこれで正解なのかも。

「目立たせたい部分は全部」
なんて、おかしなやり方は別として、マークアップがどうこうという以前に一番伝えたいところとそれの付随情報というレベルはあるわけで、一番伝えたいことを強調したいのはあたりまえ。

それが
「そういう強調の仕方は文書構造的にオカシイので、ダメです。こうしてください」っていうのはナンセンスなんだなと、つくづく感じちゃう。

「文書構造?なにそれ。人間に見てもらうんだから見た目が大事だよ、見た目が!そこ金赤ね!」

これ、正しいと思う。

いろんなところで、コミュニケーションの欠如

サイトをCMSとかシステムを使っての更新をしてもらう際には、そのサイトに合わせたコンテンツの作り方、それぞれの要素の緩急のつけかたなんかも併せて、サポートする必要があるのかもしれない。

そのコミュニケーション怠ると、クライアントが「文書構造が正しい」Webサイトを作れるシステムを求めているのか、
「簡単ホームページ作成」を求めているのか見誤ってしまうし、そんな状態で

「この文字、赤くしたいな」
「その機能は打ち合わせの段階で、仕様に含まれていなかったので別途費用で実装します」

なんてやっていると、最終的には文書構造もクライアントの求めるシステムも両立できないでものになってしまうんだろうな。

じゃ、これからは「文字を赤くする機能」を付け加えればいいとか「WYSIWYGで更新を…」いうことじゃなくて、その機能がない理由があってなっとく出来るガイドラインや説明があればいいんだと思う。
(もちろん、必要ならはじめっから実装する必要はある)

とか、偉そうな事書いてるけど、自分が出来ていない事の自戒も含めて書いてみた。
「○○がすべてだ!」という言葉はあまり好きじゃないけど、他の仕事をしている人も当てはまるんじゃないだろうか。

他から見れば僕は「Webデザイナー」ってこととになるんだろうけど、デザイナーって言われるほど成熟していないので自分からデザイナーと名乗った事は無いけど、名乗れるようにがんばらないとね。

Web デザイナーに求めたい 5つのこと | WWW WATCHにトラックバックを送ったのも、このあたりの話題が十分に議論されればいいなって思いまして。

Rlated & Feedbacks

http://www.trapon.jp/cms/mt-tb.cgi/120