この記事は「ブログでの会話を見えるようにするには」の続きにあたります。 従来オンライン上の会話は一元化されていました。例えばフォーラムや掲示板で会話を始めるためのネタが挙り、それに対しての反応がその場に連なっていました。ブログが使われるようになると、フォーラムでの会話だけでなくブログを中心とした会話もスタートしました。簡単にブログを設置することが出来るので会話が一カ所ではなく数多くの場所で発生するようになったものの、ブログにあるコメントやトラックバックによってなんとなく繋がり合っていました。また、TechnoratiやGoogleブログ検索を利用してある程度、会話を追うことも可能です。しかし、現在はさらに会話を追うのが難しくなってきています。 今はブログより気軽に自分の意見を書き込む場所が数多くあります。Livedoor クリップをはじめとしたソーシャルブックマークサービスのメモ機能。Tumblrのようなスクラップサービス。Newsingのようなソーシャルニュースサイト。コメントが集中するところは特定出来ますが、それでも膨大な数のサービスが存在します。最近ではFriendFeedのようなライフストリーム系のサービスでもコメントを記入出来るような機能を実装しており、類似サービスも幾つか登場してきています。 自分の意見をサクッと書く場所として最も敷居が低いのはTwitterやTimelogのようなプチブログ。1日に数十もの言葉を発している人も少なくないところから、インプットの敷居の低さが分かります。Twitter のようなサービスが典型といえますが、最近の会話が起こる場所はよりリアルの会話に近づいてきたといえます。リアルタイムかつ簡単に出来るだけでなく、発信するための道具も豊富にあるので、自分の発言スタイルやネットワーク (友達との繋がり方) にマッチしたものも選べば良いわけです。一元化されていてフラットだった会話がダイナミックでソーシャルになってきたといえるでしょう。 自分のブログを中心に発生する会話の場所も分散化しています。中心から離れるほどリアルタイムになり追ったりアーカイブするのが難しくなります。 このように単純にブログをチェックしているだけでは特定のトピックを取り囲んで行われている会話が追えなくなってきています。ここで課題になってくるのが、いわゆる Web 1.0 的なツールであるブログでの会話と Web 2.0 的なソーシャルサービスでの会話をどのようにマッチングさせていくかだと思います。ブログやフォーラムが全盛期だった頃は会話がある程度一元化されていたので、会話を追うことはそれほど難しくありませんでし、時間が経過しても会話がまとめてアーカイブされるので後で見るのも便利です。会話が分散してしまった現在では全体像をみるのが困難です。 これはブログを書く人、もしくは読者だけの課題ではありません。Webマーケティングやカスタマー・リレーションズにおいても重要な課題といえるでしょう。数年前は単純にブログスフィアでの会話を追えば評判やフィードバックを得ることが出来ましたが、現在はブログスフィアをみているだけではユーザーの反応の半分も得ていないといっても良いかもしれません。アクセス解析のリファラだけでは何処で濃い会話がされているかというのも確認することは難しいでしょう。 現在は、リファラや有名サイトやサービスを起点にして地道に探すしかないのかもしれませんが、同時にビジネスチャンスといえるでしょう。数多くのサービスに分散化した会話を追うことが出来るサービスが今必要とされてると思います。全体像をみることが出来る視覚化ツールではなく、特定のURLや話題がどのように会話されているのか理解出来るツールがあれば、誰でも好きなツールを使いつつ会話に参加しやすくなるのではないでしょうか。

サイドバーはブログが広まる前から存在していたコンポーネント。メインコンテンツ以外の情報を上部に載せることが出来るので、多くのサイトでサイドバーが採用されています。実装も簡単に出来ますし、３カラム、４カラムと増やすことも出来るわけですが、実装の敷居も低いのでただの賑やかしになってしまいがちの部分でもあります。情報の配置の仕方によって、情報が活かされるときもあれば、そうでないときもあります。サイドバーもメインコンテンツ以外の情報を放り込む場所ではなく、的確な情報が載る場所として扱わなくてはいけません。 ブログのサイドバーで必要なもの サイドバーによくある情報は 最近のエントリーリスト 最近のコメントリスト アーカイブリスト カテゴリリスト タグクラウド Feed をはじめとした購読ボタン ウィジェット諸々 アクセス解析やサイトコンセプトによってサイドバーの使い方も変わってきます。このサイトは Feed は多くの方に登録されていますが、サイトまで訪れる方はその中のわずかな数ですし、エントリーによってアクセス数も数倍違うこともあります。よって、情報収集家が最も多いと仮定出来ます。もちろん、検索から訪れる方も少なくありません。つまり、レギュラー読者より初めてもしく時々サイトに訪れる方のほうが多いといえます。Feed を購読している読者もたまに訪れるわけでですから、彼らが久しぶりに訪れたときに便利な情報も欲しいところです。 ブログのサイドバーの情報の置き方で参考になるのは、ニュースサイトです。asahi.com>の記事ページをみると、サイドバーには「注目」や「特集」といったサイトでベストコンテンツが掲載されています。この傾向は国内外関係なく NYTimes.com でも同じです。訪れたサイトがどういったサイトなのか、どんな情報が載っているサイトなのかというのが一望出来る要素がサイドバーに置かれてるわけです。 下に置くという選択 2年くらい前から横ではなく下に様々な情報を置く「フッターデザイン」が流行し始めました。スクロールするにつれて単調になってくるので、フッターデザインはサイトの良いアクセントになることは間違いありません。「35 Website Footer Designs, Trend and Styles」をみても分かるように魅力的なフッターデザインも少なくありません。 しかし、サイドバーに掲載したほうが効果的な情報も少なくありません。例えば「このサイトはどういうサイトなのか」を表した情報はサイドバーのほうが効果的でしょう。では、フッターに置かれているべき情報はどういった情報でしょうか。 サイドバーによく掲載されている「最近のエントリー」や「関連エントリー」は下のほうが適している情報のひとつです。読者が記事を読み終わった後に再びスクロールアップしてサイドバーにある最近エントリーや関連エントリーをみるというのは、あまり便利な使い方ではありません。読み終わったあとに欲しい情報を、その場で提供出来るようにしておきたいところです。コメント・トラックバックがエントリー下にあるのもそのためでしょうし、ブログスィアでの反応も下で読めると便利かもしれません。 タイプによって情報配置も変わってくる サイドバーにぜひ欲しい情報が見えてきました このサイトについて分かる情報、もしくはすぐにアクセス出来る導線 サイトのベストコンテンツ (アクセスランキングや筆者のレコメンド) 購読のようなサイトの『ツール』を提供 これら以外にも欲しい情報はありますが、フッターも含めてメインコンテンツのタイプによって情報の扱い方も変わってくるでしょう。情報収集家にとって、筆者が最近何を書いているかより、同じ系統の記事があるなら読みたいという思いのほうが強いかもしれません。「Links (リンク)」や「Round Up (まとめ)」のようなタイプによって「最近のエントリー」のリストも「同タイプの最近エントリー」のほうが適している場合もあります。場合によって、フッターのほうが適しているもしくはその逆も考えられるでしょう。 これからタイプ別に情報配置も考えていくわけですから、単に「最近エントリーはこのあたりに配置します」とするのではなく、「こういう種類の最近のエントリーが配置されます」とタイプ別に吟味していけたらと考えています。

以前 Google の UX プロセスというエントリーで、Google が考えるユーザー体験を向上するための対策を紹介しました。Google のような数多くのサービスを運営している大企業でなかったとしても、参考になる項目が幾つかありましたが、先日 Google Operating System で Google's Design Guidelines という記事が掲載されました。Google アプリケーションのユーザー体験を担当する Jon Wiley 氏が WritersUS Conference で語った Google のデザインガイドライン10項目がリストされています。 使える: 人々の生活、仕事、夢にフォーカスする 早い: ミリ秒でも早くする シンプル: 簡略化することの重要性 魅力的: 初心者にも上級者も引きつける何かをつくる 先進的: 新しいものを生み出すことに意欲的になる ユニバーサル: 世界のためのデザイン 有益: 今日、明日のビジネスのことについて考える 美しい: 心を乱さず目にやさしいものを 信頼性: 人々の信頼を勝ち取れるものになる 人柄: 何か人間らしさを加える ビジュアル面では賛否両論があるかもしれませんし、「デザインしているか？」と考える方もいるかもしれません。しかし、生活に溶け込んだものを作ろうとしている意味ではネットを利用した生活そのものをデザインしていると言えるでしょうし、それは上記のガイドラインを反映させているように思えます。 「ユニバーサル」と提示していますが、ローカライズも同時にしているのが興味深い点です。例えば少し前に Google Japan は独自の見た目になりましたし、韓国もしばらく前から独自路線です。もちろん、コンセプト自体は国に関係なく同じなので、ユニバーサルといえますが、ちょっとしたチューンナップを国によって行っているのは 1項目目の「人々の生活にフォーカス」と 10項目目の「人間らしさ」が反映しているのかもしれません。 こうして 10項目を見て感じるのが、それぞれの項目に応じて携わる人も違ってくるのではないかというところ。企業としてこの 10項目を守るためにどのように管理してプロジェクトを進めているのか興味深いところです。

ブログエントリーをタイプ別に振り分け、どのような読者がサイトを訪れているのか漠然的ですがみえてきました。そして、ついにプロトタイプをそろそろ作って行くという段階に近づいて来たわけですが、ここでプロトタイプからテスト、もしくは公開までの進め方を紹介していこうと思います。 通常、上図のように分析、プロトタイプ、デザイン、コーディング、テストというプロセスが順に行われます。それぞれのフェーズにサイト全体を考慮しつつ進めて行くわけです。このプロセスは多くのサイト構築に使われていますし、特に問題もないと思いますが、別の方法も考えられます。特に様々なタイプのページが存在するところだと、全体を一気にデザインしたりコーディングするのではなく、細分化して進める方法もあると思います。 こうした進め方をするメリットは幾つかあります。 一部の機能やページに特化するのでフォーカスしやすくなるだけでなく、ビジョンの共有もしやすい ひとつひとつ組み立てていくことで全体的な方向性も見えて来る可能性がある 先に行われたサイクルが次のサイクルを進めて行く上で参考になるので、より洗練されていく フィードバックの数が必然的に多くなる まったく同じワークフローを繰り返すのではなく、サイクルを進めて行くにつれてより全体的なデザインへと進化していく ひとつのサイクルを終わせるごとに達成感を味わえる 特に最初に挙げた「ビジョンの共有」が、オープン Web デザインで重要な部分になっているところだと思います。サイト全体をどんどん構築するのはそれほど難しいことではないですが、その分あなたが消化しなければならない情報量が多くなります。しかも考慮しなければならない項目が増えれば増えるほど追うのが難しくなりますし、結果的にフィードバックが少なくなってしまいます。ひとつひとつ作ればそれだけ情報はフォーカスされた話題にもなりますし、プロセスもスピーディになるのではないかと考えています。 今までまとめて作っていた Webサイトを細分化して作って行くので、気をつけなければならない点も幾つかあります。 全体的なゴールを把握し、それをどのように細分化して複数のサイクルをつくるのか検討する サイクルごとに何がゴールなのかを明確化すること 細分化してもサイト全体のゴールがぶれないように気をつける どのサイクルから先にするかを検討。下階層からスタートするのが理想的 トップページやアーカーブページなどいろいろありますが、まずはこのサイトのコアにもなるブログエントリーのページから攻めて行こうと思います。ブログエントリーのタイプごとにサイクルを組み立てて最終的な形へもっていこうと考えています。順番は以下のとおり。 Links（リンク） Round up（まとめ） Review（レビュー） Diary（日記） Announcement（告知） Article（記事） Follow up（追記） 文章があまりないリンクからスタートして、徐々に文章量や関連情報が多くなりそうなエントリーへ徐々へ進めて行きます。特に先の3つはフォーマットもある程度決まっているので作りやすいのではないかと考えています。まずは簡単なものから皆さんと考えて行き、難しそうなものへ挑戦していきましょう。 恐らくサイクルごとに完全なビジュアルを決定することはないと思いますが、それはサイクルが進んで行くごとに形になっていくのではないかと予想しています。よって、ひとつのサイクルのゴールはある程度の見栄えを整えてきちんとコーディングされた状態までを指すことにします。 これまでと同様、ブログや SBM 等であなたのコメントをチェックしているので、何か意見や感想などがあれば書き込んでいってください。

この記事は「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のコーディングを終えてから変更するコストを考えると有効な投資といえます。