2008年10月15日水曜日

チートポスター

きのう本屋で「お客をつかむWeb心理学」という本を立ち読みしました。バンドワゴン効果、カクテルパーティー効果、吊り橋効果、ピグマリオン効果、ハロー効果とかね、そういう一度は耳にしたことがあるような社会心理学系の概念をコンパクトに解説して、じゃあそれをWebサイトのインターフェース設計やユーザー導線設計に活かしてみたらどうなるかっていうのが、一種、カタログ風にまとめられていました。

これですね。

きのうはちょっと持ち合わせがなかったのとヒマだったのとで、立ち読みでほとんど全部読んじゃったんですけど、これは今度ちゃんと買おうと思いました。

ちょっと前のエントリーで、メッセージチャートとかいって、ワイヤーフレームに行く前にユーザーの心の変遷をダイレクトにとらえられるような設計図を作るべきなんじゃないかなんて書きましたけど、そういう作業をやる上で、こういうカタログはきっと役に立つと思うんですよね。

なにも、すみずみまでナントカ効果で計算されつくされた隙のないサイトデザインとか、そういうのを目指すわけではなくて、たとえばこの本に書かれているような心理学の知見を、設計のプロセスの中でいつでも名指して参照できる頭をもっておくことが大事っていう。そうしないと、メッセージチャートとかいったって、いっつもまっさらなところから、勘だけを頼りに作業するハメになっちゃう。

プログラマーの人たちにとってのデザインパターンとか、ああいうのは、仲間内のコミュニケーションを効率化するための符丁でもあるけど、設計に役立ちそうな過去の経験やテクニックを呼び起こすための符丁だったりもするわけですよね。まてよ、そこ、テンプレートメソッドにすればきれいにいくんじゃね?とかってね。たぶん。

Web ディレクターやデザイナーにも、そういう符丁がもっともっと必要なんじゃないかといつも思うんです。かろうじて、画面を構成するパーツだとか、ナビゲーションの種類ぐらいは名指せるようになりましたが。でも、この本が紹介してくれているようなナントカ効果の数々も、われわれの内で当然のように流通する符丁の仲間に入れておくべきなんじゃないでしょうか。

今、うちの会社のオフィスってずいぶんと殺風景なんですよね。あんまりなんで絵でも飾るかなんていってるんですけど、絵じゃなくて、たとえば、ギャレットのユーザ中心デザインにおける5段階の図とかね、そういうのをかっこいいビジュアルにまとめてポスターにして貼っといたらどうかなとも思ってるんですよね。

ナビゲーションの種類とか、オライリーの「デザイニングインターフェース」という本に列挙されているデザイン手法のリストとか、CSSのチートシートとか、標準的なWebアプリのアーキテクチャの概念図とか、そういう、われわれの仕事に関係する図表、つまり符丁の早見表みたいなものをカラフルな"絵"にして。

これ、チートポスターとかいってシリーズで作れたらいいかんじじゃないかななんて思うんですけど、どうでしょう。もちろん、ナントカ効果がたくさん散りばめられてる Web 心理学ポスターも作りたいです。
-----------------
sent from W-ZERO3

2008年10月14日火曜日

WSHでJemplate

前に「文房具としてのWSH」ってエントリーを書きました。

http://chushoww.blogspot.com/2008/09/wsh.html

このとき、WSHスクリプトでJemplate使えたら便利そう、今度やってみよう、なんていってたわけですが、ちょっと時間ができたのでホントにやってみました。

問題なく動きますね。

Template Toolkit の記法で、たとえば、template.html っていうファイルを作成して、これを、Jemplate でコンパイルしますね。

jemplate --runtime=lite --compile template.html > template.js


みたいにして。

そして、出来上がった template.js を wsf ファイルにインクルートします。

<?XML version="1.0" standalone="yes" encoding="utf-8"?>
<package>
<job>
<script language="JScript" src="template.js" />
<script language="JScript">//<![CDATA[

// your code

//]]></script>
</job>
</package>


そうすると、

var data = {
// some keys and values
}
var str = Jemplate.process('template.html', data);


これで、変数 data の値を template.html に展開した文字列が変数 str にちゃんと入ります。

CSVデータを元に一定のフォーマットで大量のHTMLファイルを生成したいときなんかに重宝しそうですね。ファイル生成を行うマシンに特別な環境設定を行う必要もないですしね。でも、Jemplateをコンパイルしなくちゃいけないのが、ちょっと面倒かな。

あと、WSHでローカルのテキストファイルを簡単に取り扱うためラッパーも書いてみました。

http://code.google.com/p/wsh-sugar-folder/source/browse/trunk/folder.js

これをインクルートして使うと、

http://code.google.com/p/wsh-sugar-folder/

にも書きましたが、

var f = folder.getFileByFilename( filename )
f.innerStr( str )


みたいなかんじで、ブラウザでJavascriptを動かしてDOM操作を行う感覚で簡単にテキストファイルの内容を出し入れできるようになります。ファイルの内容をCSVデータとして読み込むこともできます。

Jemplate とこれを一緒に使うと、

for ( var i in folder.files) {

if ( folder.files[i].filename.match(/\.csv/) ) {

recs = folder.files[i].csv()

var data = {
"recs" : recs
}

var str = Jemplate.process('template.html', data);

var output_filename = "output" + i + ".html";

folder.create( output_filename, str )

}

}


なんて、こんなことができるようになります。

まあ、時と場合と人によりけりですが、これはけっこう便利なんじゃないかなって思ってるんですけど、どうでしょう。

2008年10月10日金曜日

サイトのハートビート

サイトデザインの一種の常套として昔からあって、今でもときどき見かけるので、意味がずーっとわかんないのが、トップページの一番メインのところに What's New を置くやつ。新着コンテンツをフィーチャするっていうんじゃなくて、更新履歴、いや、もう更新作業記録ですね、「○○を更新しました(×月×日)」とかっていうのがずらーっと並んでんの。

なんかWebサイトならなんでもかんでも更新感が大事とかって思われちゃう風があるけれども、そんなことないよ。それに、そもそも、その作業記録を見て、おっ!なんていうやつが作業者の仲間か上司ではないとしたら一体誰なんだって思う。

あと、それに近いので、月単位でユーザアクセスをみて、リピーターを増やせってのを至上命題みたいにいわれるんだけど、何でこのサイト、この手の情報に、ちょくちょくアクセスしなきゃいけないのか、そのリピーターってやつがいるんだとしたら、いったいどういう奴なのか、それがよくわからないっていうのもある。

必要な人が探せばちゃんと見つかって、更新なんてないけど、いつもきっとそこに存在してくれていて、また次に必要になってアクセスしたときに、ああ、ちゃんとこれがあってくれてよかったなって思える、そういう価値のあるサイトっていうのがあっていいし、げんに、いっぱいあるでしょ。

いや、たとえば、なんか保険やら税金やらの手続きがあって役所のサイトにアクセスするときとかね。製品を買うとき、壊れたときの製品メーカーのサイトとか、そう思います。

でも、たしかに、そういう情報を取りにいって初めて訪れるとき、ここに書かれてることは古くなってたりしてないかな、って思うことはある。そういうときに、どっかに更新日付があったりすると、おー、ちゃんと今現在もメンテナンスされているんだなって安心できる。ただ、それは更新感なんじゃなくて、一種の生命反応なんだよね。ハートビートっていうか。だからそれがトップページの真ん中にでーんってのはいただけませんよ。

そういう場合で、一番いいなと思うのは、日々そうやって訪れるユーザにたいして、サイト側として、できれば目に入れていってほしいメッセージなりコンテンツがあって、それがときどき入れ替わるんで、更新日付がついてるとかですね。

ほかにも、ハートビートの鳴らし方にはいろいろ考えられるでしょう。

だから、更新しましたって言葉をあんなところにずらっと並べるのはもうやめよう。ハレンチだよ。

それから、そういう、リピーターに対して更新感を与えてこそっていうのとはタイプが違うサイトの存在価値を評価する方法が必要かもれないですね。なんだろう。ブクマ数とか、リファラなしのアクセス数か。検索語のタイプを分析していわゆるナビゲーションサーチの割合を調べるとか、滞在時間を重要視するとか。うーん、自然なかんじでURLを分割してコンバージョンみたいなのを作るとか。

-----------------
sent from W-ZERO3

2008年10月8日水曜日

グローバルナビゲーションいらず

ちょっとした行きがかりで、今日、全国の県警のサイトのトップページをずらっと見てみました。

なんていうか、そういえば前に自衛隊のを見たときも同じことを思ったんですけど、なんだかみんな悪質サイトみたいなデザインですよね。開いた瞬間に、やべ、とかいって、すぐバックボタンをクリックしたくなります。とても職場ではじっくり読めないっていうか。

まあ、でも、そういう、いわゆる表層的なトーン&マナーのことはいったん置くとしても、やっぱり、このサイトは何のためにあるのっていう視点とか、他でもないこのサイトで、ユーザーのニーズとサイトの目的がマッチするケースにはどういうのが考えられるのとか、そういうところから逆算されるべき情報デザインがあんまりうまくできていない印象も強く受けますね。

それでも、いくつかよさげなのはありましたよ。たとえば、事実上のウェルカムメッセージが、犯罪にご協力ください、とかいって手配中の事件をどーんとリストしてる県警とか、そうかと思うと、落とし物情報を一番にフィーチャしてる県警もあったりして、ちゃんと、警察がWebサイトを運営することの意義をわきまえていたり、そこにわざわざアクセスしてくる訪問者の動機に応えようとしているのが伝わってくるようなグッドデザインのやつ。

そんな中でも、トップページだけ見て特に好印象を抱いた、というか、よくできてんなー、と思ったのが富山県警でした。よかったんで、自然と第二階層以下も巡ってみちゃったんですが、このサイト、グローバルナビゲーションっていうのがないんですよね。ブレッドクラムはあるんです。だから、サイト構造としてはトップページをルートとしたツリーそのもので、系列の違うノード間のショートカットなんてまるでないんですよね。

グローバルナビゲーションは、いつも視線誘導上の始まり付近にあって、サイトのどこにいても、どこから入ってきても、全体の構造をほのめかしながら、サイトに対する期待をユーザの心のうちに形成するという重要な役割を担っていて、それこそサイトデザインには欠かせない要素であるはずです。

でも、たしかに、警察のサイトを訪れるなんて、交番に足を踏み入れるようなもんで、もう心に決めた目的があってのことに違いないでしょう。なんとなく訪れてなんか面白いことないかなーとかってサイト内を巡回する人なんてきっといないんじゃないか。

そうした訪問者にとってみれば、全部のページページの上部に強制露出するグローバルナビゲーションなんてうざいだけ、レイアウト効率の上でのロスでしかないのかも知れませんね。

ひょっとすると、このサイトをデザインした人は、そこまで見切って、あえてグローバルナビゲーションを外したのかも知れない。これは相当な手練れの仕業?ってかんじで、今日はたいへん勉強になりました。


-----------------
sent from W-ZERO3

2008年10月7日火曜日

もしもインディーズバンドだったら

もし、今、自分があと20歳くらい若くって、バンドなんかやっていて、おれたち天才とかって盛り上がってたら、ひょっとして、メジャーデビューしたいなんて思わないかも知れないですね。

たぶん MySpace かなんかに曲やらライブ映像をばんばんアップして、 ファイル数や容量に制限があるんなら、載せきれないぶんはYoutube にでもアップして、あと、Onpoo とかも最大限活用して、それで少しでもたくさんの人に自分たちで作った歌を聞いてもらおうってことでいいじゃん、なんていって。チラシにはQRコードを載っけて、自分たちの曲の着うた(R)をダウンロードしてもらえるようにして、その場でどんな曲をやってるのかすぐわかっちゃうようにしてね。権利関係なんてどうでもいいし、もちろん全部無料で、きっと、その時分なら、金儲けなんて汚いとかいって粋がってるはず。あ、でも聞きかじりで、やっぱりクリエイティブコモンズで、なんてことは言ってるかもしれない。

当然、ブログもやるでしょうね。なんていうか、常にメイキングみたいなやつ。新しい曲ができたら、ギターと鼻歌のデモの段階で公開して。それで、スタジオに入るたびに録音して、アレンジが固まっていく様子をブログにアップしていくとか。最初は歌詞もちゃんとついてなくて、歌詞は歌詞で言葉を選ぶのにいろいろ悩んでる途中のも載せてね。どうだろ、これ、なんて聞いちゃったり。あと、今日は曲が仕上がるぞなんて日のリハの様子は、全編 UStreamでストリーミング配信ですね。

そしたら、なんかそういうことがやりやすい練習スタジオはないかな、なんて思うでしょうね。特別なセッティングをしなくても、リハの様子は全部録音録画できてて、練習が終わった後、ネットもデータの編集環境もばっちり完備のミーティングルームで、今日のデータをサーバーにアップしつつ、反省会なんつって。

さあ、自分たちは天才、が大前提ですから、やってる音楽はもう最高。そうすると最高なわりに、いまいちお客が増えないのはどういうわけだってなことになって。あとは、こう、自分たちの音楽をできるだけたくさんの人に聞いてもらうには?って、バンドのプロモーションについて考えていくことになるでしょう。

でも、なんかいいインディーズバンドはいないか、とかいって、いつもそんなのを探しているような音楽に飢えたやつなんて、まあ、滅多にいないんで、結局は、誰かに強く薦められたとか、他のバンド目当てでたまたま行ったライブの対バンがよかったとか、その店にあったチラシで気になったのがあったとか、それこそ、出会い頭のバイラルでしか広がらない。

だから、たぶん、インディーズバンドのポータルサイトとかランキングサイトとかには、あんまり期待できなくて。むしろ、たとえば、そういう出会い頭で気になったときの深堀りのしやすさとか、人に薦めたいときの紹介のしやすさがモノをいうわけだろうから、そういうプロモーションツールを持つことこそがまずは第一だよねってなって、そういう意味で、MySpace、YouTube、 Onpoo なんかを使い倒しつつ、さらに、いつもメイキングなブログを更新していこうと、きっとそんなことを考えるだろうと思います。

音楽産業は音源の配布と演奏の興業とそれらの宣伝から成り立っているわけですけど、いまやメジャーの産業によらなくても、そんなかんじで、音源の配布と宣伝のところは済んじゃって、そうすることで、もう少し世間に広くリーチできるミュージシャンのみなさんも結構少なくないんじゃないかな、なんて思います。

アメリカでの MySpace の立ち上がりにドライブをかけたのは、そういうセンスによるところが大きかったみたいですし、Onpoo が excite と組んでやろうとしていることも、そのへんに着眼してのことでしょう。

課金までできるみたいですね。可能性としては、それで"成り上がる"ことだってできるわけですよね。

あとは、ライブハウスやスタジオとかの設備ビジネスが、そうした流通とプロモーションのことも視野に入れたサービスを開発してくれると、だいぶ開けてきそうな気がしますね。

むかしバンドやろうぜなんて雑誌がありましたけど、今やるとしたら、その手の特集が多くなりそうじゃないですか。
-----------------
sent from W-ZERO3

2008年10月3日金曜日

ユーザーモデルのスケッチ

Web アプリでも、Web サイトでも、さっさとプロトタイプなりモックアップなりを作って、実際に目に見えるもの、手にとれるものを前にして、試しては失敗し、作っては壊しながら、あーでもないこーでもないとやるのがいいですよね。

結局ユーザーに届くものってのは、アイディアでもコンセプトでもなくてプロダクト、ユーザーにとっては UI こそすべてってわけですから。

でも、じゃあ、とりあえずざっくりワイヤーフレームでも書いて、あとは見た目重要なんていっていっきに制作、開発ができるのかっていうと、そうじゃないですね。

ユーザーにとって UI こそすべて、っていう言い方はたぶん正確ではなくて、UI をつうじて心の中に出来上がるサービス/システムのイメージこそすべて、と言うべきでしょう。それをユーザーが抱くモデルって意味でサービス/システムのユーザーモデルなんていったりしますね。

そうすると、提供側の下心のほうのすべては、自分たちのアイディアやコンセプトにしたがって、ユーザーモデルをうまく誘導したり、コントロールしたりすることにあるといっていいでしょう。

それで、そういう、人の心を誘導したりコントロールしようなんていう大それた不逞を働くには、それにふさわしい準備、デザインが必要です。インタビュー、調査、データ分析なんかの上に、ありったけの想像力なんかも駆使して、とにかく、想定ユーザーモデルとでも呼ぶべきものを描いてみないことにははじまりません。

モックアップやプロトタイプ、それからワイヤーフレームは、そういうユーザーモデルデザインの検証には役立ちます。デザインされたユーザモデルをユーザーの心の内に作り上げることができるかどうかということと、ユーザーモデルデザインそのものに不足や偏りはなかったかという二面で。

でも、それらで、直接ユーザーモデルをスケッチすることはできないわけです。

ときに、なんだこりゃ、と思わずにいられないワイヤーフレーム、モックアップ、プロトタイプに出くわすんですが、そういう場合は必ずといっていいほど、ユーザーモデルデザインのプロセスがないがしろにされていますね。

ぼくは、システム設計、特に MVC のモデル層の設計の根拠としてだけでなく、ユーザーモデルのスケッチとして、概念モデル図はつねに書かれるべきだと思います。あるいは、マインドマップでもいいんですけど。

そして、要件定義、設計、実装の各段階、ギャレットの五段階でいえば、戦略、要件、構造、骨格、表層の各段階において、そういうユーザーモデルのスケッチが毎度参照され、点検されるべきだと思いますね。

オライリーから出ている「デザイニングインターフェース」という本は、いってみれば、UI デザインのカタログですけれども、その一部に、ユーザーマインドの類型化を試みている箇所があって、これは非常に参考になります。そういうかんじで、UI のむこうにあるユーザーモデルをモデリングする技術とか、ユーザーモデルをデザインする上でのデザインパターンだとか、そういう方向にこそ、Web ディレクターとしての技術のコアがあるような気がするんですよね。


-----------------
sent from W-ZERO3

2008年10月1日水曜日

コンセプトセンシティブFAQ

ある Web アプリケーションの導入にあたって、マニュアルの整備や操作方法を学ぶための e ラーニングのあり方についてディスカッションする機会がありました。

専門的で、やや複雑なデータを取り扱うアプリケーションということもあり、ユーザが抱くシステムイメージを形成するところからして骨が折れそうなのに加えて、ヘビーユーザになって初めて利便性を感じることができるような濃やかなオプションなんかも結構あって、これは一筋縄ではいかないね、みたいなかんじでした。

とりあえず、導入とシステムの概要の理解、それから、アプリケーションを用いた典型的なワークフローなんかについては、e ラーニングで学んでもらう。

一方、各画面内に表示されるデータやインターフェースの意味と役割とか、また、テクニックだの TIPS の類は、オンラインマニュアルやFAQ としてまとめておいて、利用中に適宜参照してもらう。

と、まあ、ふつうに考えるとそうなりますね。

ただ、はじめの、入門としての e ラーニングの方はいいんですけど、マニュアルと FAQ は、書こうと思えばいくらでも細かく書けるようなかんじなんで、ユーザの便宜のことも考えて、何か工夫できることはないかな。という話になりました。

それでひとつは、マニュアルや FAQ をベースにしつつ、ユーザ同士で教え合うナレッジコミュニティを作ってみてはどうかと。アクセスログの集計に基づいたリコメンドやランキングなんかもあったりして。

たしかに、そういう集合知関連のテクノロジーをこのジャンルに活かしていくってのは、間違いなく有用だし、これからどんどん普通になっていくことだと思います。

ただ、なんていうか、今、まな板にのってるこのアプリケーションは、まさかホビーの対象ではないですし、正直いって、一日もはやく、誰にも負けないパワーユーザになることを目指して、日々新しい操作を覚える努力を怠らないとか、そういうマインドで接してくるユーザなんてほとんどいないはずなんです。

そうすると、わざわざ、そういうコミュニティサイトにアクセスしてくることもないでしょうし、仮にアクセスしてみても、たとえば、最近よく参照されてるヘルプランキングとか、このヘルプを参照した人はこんなヘルプも参照しています、とか、そんなのに惹きを感じるなんてことはないように思うんですよね。

そういうのは、うっすらとした欠乏感とともにある自発性に向けての刺激なんで、これの場合は、たぶん、できれば早めに切り上げたい、といのがユーザマインドの基調でしょうからね。

だから、教えてナントカみたいなナレッジコミュニティにしても、ある種の出会いを期待しつつ多少なりともワクワクしながら網をはって気長に待つなんてこともないでしょう。一応、サポートデスクはあるんで、八方塞がりでワラにもすがる思いなんていうケースもちょっとなさそうです。

いや、集合知とナレッジコミュニティ自体に文句はないんです。ただ、ユーザにどうやって入ってきてもらうかってことですね。アプリケーションの外でサポートサイトとして待ちかまえていても、あんまり見てもらえそうにないという。

やっぱりこの手のものは、必要なときに、ドンピシャのヒントなりアドバイスを引き出せる、ってのがユーザとしては一番幸せなわけですよね。

だから、ヘルプボタンにしても、画面の右上あたりに、リモートナビゲーションとしてあるんじゃなくて、メッセージやボタンのすぐそばに、コンテクストセンシティブヘルプとかいってあるべきですよね。

で、そういうふうにその場その場で引き出せる情報が、ナレッジコミュニティを通じた集合知によって充実していく、というのが理想じゃないでしょうか。

で、思うのは、ここはひとつ、コンテクストセンシティブFAQ、CSFAQとでも呼ぶべきものをやってみるのはどうでしょう。ヘルプだけじゃなくてね。それと、CSお問い合わせがあって。

なんていうか、はてなスターみたいに、アプリの画面の要所要所に、FAQの項目数を表現したマークがついてるとか。あと、回答待ちの質問数もわかって、画面の操作中、気が向いたユーザが善意で回答を寄せることもできるとか。そうすると、同じアプリを使っている者同士の仲間意識が芽生えて、思いのほか、回答が集まったりして。


-----------------
sent from W-ZERO3