Web開発技術は伝統工芸にはならない。これだけ環境が変する中では最適な制作ワークフローも常に変化する。特に近年のモバイルデバイスの爆発的普及や、モダンブラウザの普及は、開発環境にあらゆる変化をもたらしている。

開発プロセスの変化

例えば私が行う実作業の中では、Photoshopを持ち出すようなビジュアルデザイニングはかなり小さく身を潜めているように思う。それはもちろんデザイナーにとって最も重要な1つであるが、プロジェクト全体においてはあくまで「最終的な」仕上げに過ぎない。ビジュアルデザインに到達するまでのラフスケッチ、ワイヤーフレームの作成が制作業務において、時間的にも重要度的にも大きな割合を占めるようになった。

つまり、全体像をスピーディーに設計し、その価値判断のタイミングを早期にもっていく。デザイナーやプログラマーという専門家が参加する前に多くのことを見極めることができれば、プロジェクトはより身軽になる。より多くのアイディアを具体的に試すことが出来るし、専門家ではないより広い範囲のブレインと共有し、なるべく早い段階で物事を判断できるようになる。

デザイナーがPhotoshopで絵を描き始めてしまったら、プログラマーがコードを書き始めてしまったら、引き返すのは非常に厄介なのだ。（不可能なのではない、「非常に厄介」なのだ。）

Travis Isaacs’s “How to Wireframe Like a Ninja”

今年の5月 the Big Design 2010 conference にて、UXデザイナーである Travis Isaacs 氏が行ったプレゼンテーションを紹介したい。
“Keynote Kung-Fu: How to Wireframe Like a Ninja” と題されたこのプレゼンテーションは、アップルキーノートを使った魅力的で効果的なワイヤーフレームやサイトモックアップの作り方について解説している。

彼はキーノートのオリジナルツールキットを作成し、KeynoteKungfu.comにて販売している。このサイトについては最後に詳しく。

高精度なプロトタイピングの重要性

個人的にこのプロセスにはかなり共感できた。
つまり各工程をどの媒体でどこまで突き詰めるかは、各工程が持つフリクションを考慮したプロジェクト全体におけるリスクの最小化が重要なのである。
そして精巧なビジュアルと、機能を深く表現した High-Fidelity Prototyping（高精度なプロトタイピング）がいかに重要かを教えてくれる。

スライドの多くはキーノートの素晴らしさについてだが、彼が言わんとするのはみんなが既に知っている「キーノートの便利さ」というよりは、「キーノートはWebサイトのモックアップ作成にとても便利」ということだろう。

具体的なデザインと開発プロセスについて

デザインと開発プロセスについての彼のインタビュー。

Isaacs「フロントエンドデザイナーとしてスケッチから始める。ただしかなり精巧なレベルで。ページのスケッチが完成したらそのままキーノートに移す。
インタラクションやインターフェイスの詳細を表現するのにキーノートを使うが、その後の行程が、一般的なフロントエンド開発者と少し違う。彼はそのままコーディングに進むのだ。コードに沿って（またはコードにならって）ビジュアルデザインをすることに意味がある。
コーディングには TextMate を使う。TextMate は全ての言語の構文バンドルを持ち酔いしれるようなキーボードショートカットがある。
フロントエンド言語にはHTML, CSS,そして jQuery。jQueryは唯一の必要なJSライブラリだ。また、960.gs grid system や the new HTML5 Boilerplate 、 the LESS CSS framework などをよく使う。」

キーノートツールキット KeynoteKungfu

彼が作成したキーノートツールキット KeynoteKungfu.com には、ナビゲーション、テーブル、画像やバナー、フォームエレメント、インジケータやソーシャル系ボタン、またタッチスクリーン用のインタラクション表現などのWebに必要なあらゆるエレメントがマスタースライドとして用意されている。

これらのエレメントの作り込み（例えばグラデーションだとかそういうこと）に時間をかける必要はない。彼が代表して作ってくれたのでそれを使わない手はない。12ドルの価値が十分にある。

私が特にいいと思うのは、960.gsのテンプレートを用いる概念だ。今まではワイヤーフレームの段階できっちりとしたレイアウト比率まで確定させたことがなかったが、Photoshopで使うのと同じグリッドガイドを下敷きにすることで、より高精度なワイヤーフレームが出来上がる。960pxかどうかは別として、これはいいアイディアだと思う。

iPhone用とiPad用のツールキットに関しては無料配布されているからぜひ試してみて欲しい。
KeynoteKungfu.com

まとめ

もちろんペーパープロトタイピングに重点を置くことは、今に始まったことではない。
大規模プロジェクトであればあるほど、ペーパープロトタイピングの資料は充実している。しかし、ワイヤーフレーム自体の作り方は実に多様であると感じる。

私自身いろいろなプロジェクトに参加して思うのは、それらの資料はどの程度深く考えられているかに関わらず、実際の描画においては「かなり適当に」作られるように感じる。ワイヤーフレームだからワイヤー（線）だけで表現すればある程度は分かるが、このシンプルな描画作業の品質（例えば丸みであったり、グラデーションであったり）が高まれば物事はよりスムーズに進むように思う。共有したときのリアリティが全く違ってくる。

ボタンがボタンっぽいかどうかなんてワイヤーフレームの段階において取るに足らないことのように思える。もちろん「クオリティの高いワイヤーフレームを作る」ということに情熱を燃やしてしまい、手段が目的化してしまってはいけない。

ただこのような先人の知恵や便利なもの（例えばたった$12のツールキット）はぜひ取り入れたい。

ビジュアルデザインとインタラクションデザイン、インフォアーキテクトとデザイナーやプログラマーのもっとも重要な架け橋がここにある。

あとがき
ご無沙汰しています。この記事は http://mashable.com/2010/11/12/travis-isaacs-web-design/ を参照し、一部引用と私的な感想を混ぜて書いたものです。

しかし現状ではどうしても調べながら書くというか、先に作られたHTML5サイトを参考にしながら解釈し、それをブログにまとめ、またそれを誰かが読んでサイトを作ってみて…ということで、人によって解釈が変わっていたりしてしまっています。

リッチメディア要素の機能で「canvasで何ができる」というような話はむしろ分かりやすい部類で、実際はsectionの扱い方を主としたコンテントモデルの考え方で混乱してしまうことが多いように思います。

HTML5まとめ

このHTML5 FOR WEB DESIGNERSは、本仕様では900ページに及ぶHTML5を簡潔に85ページにまとめた小冊子のようなものです。

HTML の歴史と主な仕様を単純明快に解説し、ざっと読んだだけでかなり分かったような感じになります。いや、そもそも以前にも増してコンテンツにフォーカスが置かれる昨今、HTML5の細かい仕様であーだこーだ議論するよりもここは必要最小限のことをスパッと理解してコンテンツのアイディアを練ろうじゃないか。という感じでよいのではと個人的には思っております。

こちらより購入できます。
http://books.alistapart.com/

そのスジの情報によると今月にもePub版が出るようなので、今からNYからはるばる送ってもらう必要はないかもしれませんね。

でもこういう基本的にウェブベースのややこしい話を、紙媒体ですっきりとまとめてあるというのは結構新鮮で、気持ちいいものです。iPadは目が疲れるし。

1冊余っているので欲しい方いたらtwitterにコンタクトください。無料で差し上げます。

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

それらのレディメイドテンプレートはほとんど『ブログサイト向け』の構造になっています。
つまり、単体ブログを基盤として全ての記事詳細ページ、それにカテゴリや月別アーカイブページ、というブログ型のテンプレートとなっています。
単なるブログ単体のサイトマップを作りたい場合はそれで十分ですが、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では若干変わってきます。

実際の表題記事はこちら：Universal Internet Explorer 6 CSS | For A Beautiful Web

（※今年の5月に下書きして埋もれていた少し古いブログネタですが、最新のWebDesigning8月号の大藤幹氏のコラムで取り上げられていたので便乗して書いてみます）

実際に適用させるとどうなるのか

まず百聞は一見にしかず、一時的にこのサイトに GoogleCode でホストされている『universal-ie6-css（ie6.0.3.css）』を適用させています。

可能であれば実際に IE6 でアクセスし、各ページの様子や細かい表現を確認してみてください。
この記事のURL：http://rostrata.net/blog/2009/07/universal-internet-explorer-6-css/

パッと見は、CSS Naked Day かのような丸腰 HTML のように見えます。
しかし左右に大きくマージンをとったレイアウト、そして文書構造を素のHTML状態をよりももう少しセンスよく、少しだけ成形してあります。（HTMLそのままでいきなり適用させているだけなので若干おかしな部分がありますが、まともなコーディングをしてあれば大抵は綺麗なA4書類のように見えるはず。）

この、どこまでもシンプルで実直で当たり障りのないスタイルを、今現在とても微妙な存在になってしまっているIE6の世界共通スタイルにしようということです。

Andy Clarke氏の主張は以下のようなものです。

• すべてのブラウザに対して同じ見た目を実現するのは現実的な方法ではない
  IE6をうまく処理する方法はいくつかある。しかしながら、すべてのブラウザに大して全く同じ見栄えにすることは現実的でもないし、そもそも実現できない。すべてのブラウザで同じように見せるアプローチ自体に問題がある。
• IE6対応を捨てるべきではない
  よりよいブラウザをベースとしてプログレッシブなアプローチを取るべき。これはIE6を捨てることにはなるが、IE6しか使えない状況におかれている人や環境もあるため、IE6への対応を完全にやめてしまうのは不親切である。
• 重要なのはコンテンツ
  人々にサイトに訪れる理由を訪ねると、答えはいつも「コンテンツのため」である。コンテンツとはほとんどどんな時も「言葉」で書かれており、それはつまり「キーボードで打たれたもの（テキスト）」である。

ということで、IE6のためのユニバーサルCSSを提唱しています。

単に文章を読むことを考えれば、このスタイルはものすごく読みやすい（サイトによってはデザインされた状態より読みやすいかもしれない）。いつもIE6だけの為に数時間の制作時間コストを費やしている人もいるかもしれませんが、このような考え方であれば制作コストが減り、それはクライアントにとってもよいことになります。
ポイントは、IE6を切り捨てたことによりIE6で「コンテンツが読めない（読みにくくなる）」ということがなければ、問題はどこにもないし不幸になる人がいないということだと思います。

まだ現実的ではないが

個人ブログであれば自由ですが、クライアントワークに対して、IE6をこのような形で扱うのは2009年時点では現実的ではありません。しかしながら、IE6の為に魅力的なデザイン表現を諦めるのであれば、それらをIE6対応させるために制作コストが大きく増してしまうのであれば、このような考え方は将来的にとても有効なのではないかと思います。

しかし週が空けてみるフォーラムには問題を報告する書き込みが多数あり、結論としては自動アップグレードにバグがあったようです。個人ブログで失敗するのは別にいいと思うのですが、ビジネスとしてWordPress（以下WP）で構築したサイトをクライアントさんに提供している場合、こういうのは特に慎重になる必要があると思います。

特に最近のバージョンでは自動アップグレード機能が搭載され、さらに管理画面に「アップグレードしてください」と（あたかもエラー表示のように）表示されます。

いつもの管理画面にこんなアラートが出れば、よく分からないけどなんとなくアップグレード手続きを進めてしまうという事は当然考えられます。

そういったトラブルを避ける為に、アカウントごとの権限をしっかりと管理しておく必要があります。一般的にはクライアントさんに渡す管理アカウントの権限設定などどう扱われているのでしょうか？

権限設定はユーザーインターフェイスの最適化でもある

私はいろいろなCMSで沢山のサイトを構築していますが、最高権限（管理者）のアカウントをクライアントの更新担当者さんに渡す事は基本的にはありません。

それは「大事な部分はこっちで握っておいてあわよくば改修費用をとる」という意味ではもちろんなくて、権限を適切に設定することで「日常的に不要な機能を省く」ことができるからです。
画面に大量の選択肢が表示されるだけで「難しい」と感じてしまうのは極めて普通の感覚であり、権限設定によって『メニュー項目が減る、画面上の情報量が減る、自分に必要な選択肢だけ残る』、つまりこれだけで小さな『ユーザーインターフェイスの最適化』が出来ます。

例えばWPでいうと権限によって下図のように管理画面サイドメニューが変化します。

社内の更新体勢、担当者の習熟度によって適切に権限設定する

日常的に更新するため、もしくは十分な知識のない担当者さんに渡すアカウントは「編集者」にしておくべきだと思います。
「作者」は投稿はできるのに編集ができない、という中途半端な位置づけのため実際の所は用途がなく、もし複数人で更新する場合には、責任者を「編集者」としその他の人を「寄稿者」とします。「寄稿者」は記事を公開する権限がないため、下書きとして保存し更新責任者が内容をチェックして初めて公開、という形になり、コンテンツの質を維持する必要のあるビジネスサイトではうまく働くでしょう。

更新担当する方の役割、日常的な作業までしっかりと想像して考えれば、必然的に適切な権限は決まってくると思います。（もし最高権限を渡す必要がある場合でも、管理者アカウントは書類で渡して更新用アカウントを別に作ってあげればいい）

もし今回のように威勢良くリリースされた新バージョンに問題があったとしても、権限をちゃんと管理していれば大きなトラブルを防ぐことができます。

余談

フォーラムや関連するブログエントリーを見ていると、問題に対して厳しく批判しているものも。
実際クライアントさんのサイトが今回の問題で被害にあったとして、復旧作業のコストは誰が持つのか。WPの開発者？（ Absolutely NO ）、知識のないクライアント？制作会社？

ハイリスクハイリターンとは違うかもしれませんが、高機能なシステムを無償で使わせてもらう時点でユーザーは既にハイリターンを得ているのであって、全ての問題は自分の責任、ましてはビジネスでやっている以上は起こりうる問題のリスクマネジメントをしっかりしておかないと大変な事になると思います。

バージョン管理については、セキュリティ関連であればもれなく更新する必要があるし、単純な機能アップであればフォーラムの様子を見ながら慎重に行う、または不要であれば見送る、など判断が必要です。

「やぁ、これオープンだって！じゃあこれバンバン使って楽にWEB製作ビジネスしようぜ！！ユーザーコミュニティ？公式フォーラム？なにそれこわい。」ていう発想は、怖いなと思います。