この記事は「PowerPoint を使ったプロトタイピング」の続きにあたります。 ページベースの Webサイトを制作するのであれば、多くの方が利用出来るということも含めて PowerPoint や Keynote といったプレゼンテーションアプリが最適だといえます。しかし、Ajax や Flash を利用したページを移動することなくデータにアクセスするサイトや Webアプリケーション、ショッピングサイトのような会員/非会員によって異なるコンテンツやフォームを必要とするサービスでは、ページベースで Webサイトを考えるのは困難です。 ユーザーテストをする際も PowerPoint や Keynote では難しい場合もあるでしょう。共に高度な描写が可能になり見た目の質は高くなりましたが、クリックしたときの動作や、「戻る」「進む」のようなブラウザを介した操作、そしてマウスやキーボードを使った操作までテストすることが出来ません。ページベースでプロトタイプを作るのでインタラクションも平面的になってしまい、テストをしながらプロトタイプを改善させるには少し物足りない場合も出て来るでしょう。 以前、「よりリッチなWebサイトプロトタイピング」で紹介した Axure はひとつの解といえるでしょう。Ajax のようなダイナミックなインタラクションをプロトタイプに付け加えることが出来るだけでなく、サイトマップやフローチャートとプロトタイプと連動させて作ることが出来ます。作成したプロトタイプはブラウザ上で観覧出来るのでユーザーテストも難しくありません。 Axure よりハイエンドなプロトタイピングアプリケーションを探している方は iRise は必見です。最大の特徴はワイヤーフレーム、ユーザーテスト、サイトの評価といった UX デザインに必要なことがすべてひとつのパッケージになっているところでしょう。Axure にはないプロトタイプに使うウィジェットの共有や、リアルタイムでプロトタイプを修正/変更することが可能です。サーバーサイドにプロトタイプやレポートがアップロードされているので、メールをつかった無駄なやりとりをせずに情報共有が可能ですし、ユーザーテストもリモートで行うことが出来ます。iRise の唯一の『弱点』は最も安いプランでも 5,000ドルするところでしょうか（Axure は 600ドル）。 プロトタイプを作るツールを決めるとき、誰に何を作るかに注目すると良いでしょう。Webアプリケーション開発でも、プロトタイプに触れる方が同僚やアプリケーションに関する深い理解がある方であれば PowerPoint でも十分です。また、何度も使えるライブラリを用意出来たり、文書化するときに簡単にデータを書き出し出来るかも重要な点になってくるでしょう。プロトタイプを作るのは一見『手間』のように見えますが、ビジュアルやHTMLのコーディングを終えてから変更するコストを考えると有効な投資といえます。

そろそろ大まかな形でワイヤーフレームを作っていこうと思っているわけですが、その前にいろいろ準備しておきたいことも幾つかあります。そのひとつが、拡張性を考えて、どのようなデータをどの辺りに配置するのがベストかを考えること。これは Webアプリケーション開発において特に重要になってくることだと思いますが、大幅な改変をしなくても、機能やミニコンテンツといったコンポーネントを付け加えることが出来るように設計しておく必要があります。もちろん、すべての可能性を考慮することは不可能ですが、あらかじめ拡張されることを考慮して設計を始めるか始めないかでは大きな違いがあります。 下の図はページを大まかに4つに別けて、異なる配置を考えたものです。 ※ ワイヤーフレームの基盤のような存在なので、実際のサイトのワイヤーフレームを作っているわけではありません。 ナビゲーション サイトのグローバルナビゲーションに当たるエリア。Webアプリケーションにおいては機能を示すことが多い コンテキスト / データセット 現在観覧しているページがどういったページが示していたり、サイト全体からみたページの位置を示しているエリア。パンくずがあるケースも メインコンテンツ ページのなかで最も重要とされるデータ。ブログであればブログエントリーのことを指す 関連データ / フィルター メインコンテンツに何かしらの形で関連したデータであったり、メインコンテンツを操作するためのコマンドがあるエリア どれが拡張する可能性があるのか見極める グローバルナビゲーションはサイト全体を大まかに見渡すことが出来る重要なエリアですが、サイトによっては幾つか増える可能性がある場合もありますし、ネーミングを長くしなければならないこともあるでしょう。そういった場合、ナビゲーションを横に配置すると、２列になってしまうなど限界が出てしまいます。名称が長いと、配置出来るナビゲーションの数も減っていくでしょう。そういう可能性があらかじめ分かっている場合であれば、横ではなく縦に配置したほうが良いです。 例えば Amazon.com の書籍ページをみてみましょう。「ベストセラー」「バーゲン」といった要素はそう変更されるわけでもないので、横のナビゲーションとして配置しています。しかし、書籍のカテゴリは再び再編成したり増やす可能性があるので縦に配置しているのが分かります。２種類の違うナビゲーションも今後どのように拡張するかによって明確に配置の仕方が違って来るわけです。 デザインも拡張出来ているかチェック Photoshop や Fireworks でピクセルパーフェクトなモックアップを作るのは良いですが、どのようなデータがきても良いようなデザインにしておく必要もあります。例えば左図のように常にナビゲーションの名称が１行で済むわけではなく、時には２行になることもあります。そのときに矢印が中央に来るように CSS でマークアップしているかどうか、そして背景が途中で切れていたり不自然な形でリピートしていないか考慮する必要があるでしょう。 それは縦だけでなく、横のナビゲーションでも同じです。下図のように Amazon.com では、文字のサイズを変えても中央揃えに文字がきれいに配置されているだけでなく、分割線の下がグラデーションがかかって不自然ではありません。こうした配慮はアクセシビリティとデザインを上手く同居させるのに必要なテクニックです。 どのデータが拡張される可能性があるのかを考えることは、ワイヤーフレームを考える上で重要なだけでなく、デザインやマークアップを考慮する際にも忘れてはならない重要なことです。データを細かく分散して情報の配置を考える前に、まずは大まかにデータをグループ別けし、拡張する可能性があるデータはどこに配置したら良いのか模索するというやり方は、ひとつのスタートになると思います。

この記事は「カテゴリとタグを上手に使い分ける」の続きにあたります。 カテゴリに関して迷っている方は少なくないみたいですね。前回、提案したブログエントリーをタイプ別に分類する提案をしましたが、それに対して様々な意見や感想が出ているので、ここで共有しておこうと思います。 lilacさん(カテゴリは) ふつうにいらないんじゃね？みたいな。明確に必要、という答えが出せないんですよね・・・ 他の方も書いていらっしゃいましたが、機能が提供されているからといって使わなければならないというわけではないと思います。無理にいろいろ使おうとするとかえって複雑化してしまうので、そういった場合は思い切って省くことも重要です。これはデザインするときには重要な考え方のひとつでしょう。 今回のようにカテゴリをタイプと見なして使うのは自分のサイトにはフィットしているように思えたから採用しましたが、ブログによってはタグだけで管理したほうが治まりが良いのもあるような気がします。 タグの扱い方いろいろ 前回のエントリーではカテゴリにフォーカスした話題でしたが、タグはどうでしょう。役割が明確になってきたので、コンテンツに関わるキーワードを記入していけば良いわけですが、多くなって来るとどうページに表示させて良いか迷うところです。Tag Cloud の見せ方はいろいろあり、中には参考になるのも幾つかあります。情報を視覚的に見せるという意味ではタグ専用のページを設けて Tag Cloud にするのは有効な手段だと思います。しかし、これをサイドバーに掲載したとしても読み難いですし、多くなって来たときの問題解決にはならないでしょう。 そもそも Tag Cloud のようにしてすべて（もしくはほとんどの）タグをすべてのページに掲載したほうが良いのかという疑問が残ります。Webサイトにおける基本３要素の中のひとつである『体験』を向上させるために、いかにメインコンテンツと関係のある情報を明示するかという課題があります。つまり、すべてのタグを掲載するのではなく、コンテンツの関連タグやサイトで人気のタグ又はお勧めのタグを紹介したほうが良いわけです。 greenhug のトップページには「greenhug は◯◯について書いています」という文章があります。この部分は greenhug で取り上げている記事のキーワードのトップ5が自動生成されています。よく取り上げているキーワードは greenhug の内容を反映しているものでしょうし、どのようなサイトなのかを伝える際には有効な手段だと思います。こうしたページの目的に合ったものをピックアップしてタグを掲載する方法もあります。 カテゴリとタグの役割が明確になったのは良いことですが、だからこそ単にリスト表示で OK にはいかなくなってくるわけです。 hilokiさん 記事の振り返りや学ぶためにまとめて見たいときには、同一テーマの記事として記事へのリンクがリスト化されているのが好ましいのではないか。 コメントで指摘されていますが、「Follow Up」はタイプとは言い難いのではないかというところ。確かに他に比べると少し分かり難いタイプといえますし、単体で存在していないエントリーという意味で特殊な存在といえます。個人的にこれはタイプと見なしているからこそ使っていますが、扱いには気をつけないといけないなと思いました。 今のところ「Follow Up」になっている記事は「前編」「後編」といった具合に２つのパートに分かれてるだけですが、それ以上続く場合も出て来るでしょうし、ミニシリーズをまとめて読みたいというケースも出て来るでしょう。こうした課題を解決するためにも関連タグのみを掲載するのはひとつの解決策になります。また、ミニシリーズ用にひとつのタグを用意するのも手段でしょうね。 WordPress 以外のオプションで考えると、Drupal にある Book という機能が魅力的です。Web マガジンを作るのに最適な機能が出そろっている CMS で、Book機能はミニシリーズを目次のようにまとめることが出来ます。これだと余計にタグを増やすこともないから良いですね。 前回書いたタイプ別にすることによって発生する課題の中に「タイプに応じて異なるレイアウト (情報配置) の提供も考慮するべき」と書きましたが、これはタグの見せ方にも同様のことがいえるでしょう。例えば「Links」タイプのように、エントリーに明確なテーマがない場合は、もしかすると Tag Cloud のようなものを掲載して、他のページも見てもらうように促したほうが良いのかもしれません。タイプとタグの関連性を見極めることでタグの見せ方のヒントも見えて来るかもしれませんね。

CMS にタグというコンセプトが組み込まれる以前は「カテゴリー」はどういった情報がコンテンツに含まれているのかを示すものでした。例えば、Mac、映画、ライフハック、仕事といった具合だと思います。しかし、タグ機能が CMS に導入されるようになると、以前カテゴリ名として扱っていた名称 (キーワード) がタグへ移行していきました。 ここで課題になってくるのが、タグがコンテンツに含まれている情報を示すようになったので、カテゴリに明確に違う役割を示さなくてはならないところです。もし従来のように「Mac」というカテゴリを作ってしまうと、Macに関する情報が書かれたエントリーに Mac というタグを書き込むことは重複になりますし、管理する側もこれはカテゴリなのかタグなのかというのが分かり難くなり、記事によって異なる示し方になりかねません。 ブログエントリーとひとことで言ってもエントリーによって様々なタイプ (形式) があります。徒然と文章が書かれていることもあれば、リストだけで終わっているものもあります。どういったブログエントリーを書くかによって、文章の構成は変わりますし、場合によっては文体も変わるでしょう。そこでカテゴリをエントリーのタイプと見なして考えてみました。 このサイトではブログエントリーを７つのタイプに分けています。 Article (記事) たぶんうちのサイトでは、これがメインコンテンツになっていると思います。以前から心がけていますが時間が経過しても、さほど色あせしないエントリーを書いているのが記事にあたります Review (レビュー) 音楽、書籍、セミナーなど様々なレビュー(感想)を書きたいときに選択します。もちろんマークアップは hReview です Follow Up (追記) 追加情報、続編、フィードバックに対する応えなど以前書いたエントリーの続きを書きたいことがあります。ちょうどこの記事のように「◯◯の続きです」と明記し、前の記事にもアクセスしやすくします Round Up (まとめ) その名のとおりひとつのテーマに沿って幾つかの小さな情報をひとまとめにしておきたいときに使います。主にリンク集とサイトの解説になります Links (リンク) まとめは特定のテーマに沿ってリンクや情報をリストするタイプですが、こちらはリンクを自由にリストします。いろいろエントリーみたいなやつですね Announcement (告知) セミナーの告知や制作に携わった仕事の紹介など時系列と密接に関係したエントリーを書きたいときに選択します Diary (日記) これ説明しようがないですね。普通に日記です こうした分け方をするメリットは幾つかあります。例えば読者によっては、この人が選ぶリンクだけが見たいと考える人もいるでしょうし、最近の活動や近状報告だけみたいという方、じっくり記事を読みたいという方もいるでしょう。タイプ別けすることでその人に合った情報 (もしくはその人の今のムードにあった情報) を提示しやすくなります。あらかじめ「Article」と分かっていたら後で読むかどうかの判断もしやすいかもしれません。また「Mac」というキーワードで検索をした場合も、タイプに応じて自分で飛ばし読みするか、ブックマークするかといった判断もしやすくなるでしょう。 今回デザインしていくサイトに記事を蓄積していく際にタイプ別けはひとつのソリューションだと思いますが、課題も幾つかあります。 そもそも7タイプがすべてなのか。それとも分け過ぎなのか。これは皆さんの意見も聞きたいですね URLの投稿スラッグ部分が重複してしまう可能性がある。そう考えると日付 URL と迷うところ タイプが明確に分かるデザインが必要 タイプに応じて異なるレイアウト (情報配置) の提供も考慮するべき タイプ別に検索出来たり、キーワードから特定のタイプを引き出すといった絞り込み検索は可能かどうか 他のカテゴリ機能の使い方は考えられるか ブログエントリーの管理の仕方という、かなり基本的な部分ですし、さらに多くのエントリーを書かないと見えて来ない課題も幾つかあると思います。しかし、ここを考えるか考えないかでデザインの取り組み方も変わって来るのではないでしょうか。大事な『材料』なのでこれからも吟味していこうと思います。