2008年10月30日木曜日

ストリームジョッキー

今朝、ある知人のブログを読んでみたら、なんだかヘヴィーというか、やけにしんみりとしたエントリーがあがってました。

仕事でいろいろ振り回されて、くじけそうになって、そこであらためて自分なりの人生の原則を確認した、みたいな内容なんですが、そのとき、ふとある唄が思い出された、ときて、YouTubeにあがってるその唄の動画が貼ってあるんです。

Great3 の「STAR TOURS」

それから、

かまやつひろしの「ゴロワーズを吸ったことがあるかい」

具体的には何があったのかわかりませんが、文面の調子で、気分が多少感染してしまっているところへ、こういういい唄がすっと流れてくる。

両方とも知ってる曲だし、それぞれいいってのもわかってたことなんですけど、いつにもまして、グッときちゃったんですよね。ふだんはほとんどいることのない午前中のオフィスで、まだちゃんと目が覚めていなかったってのもあるかも知れませんが。

ブログに YouTube やニコニコ動画の動画を貼りつけるなんてべつに珍しくもないことだけど、まあ、たいていは、すごいのあるよ、みてみて、って感じですよね。

でも、こういうやり方、なんていうんでしょうか、こりゃDJですよね、深夜のラジオのほうの。これ、うまい人がやったらひとつの芸として成立するんじゃないでしょうか。ビデオジョッキーじゃちょっと違うかんじなんで、ストリームジョッキーというのはどうでしょう。

▼ストリームジョッキーの例

SEXY AOR / きっと死ぬまでギリギリなんだ
http://motonoji.cocolog-nifty.com/sexy_aor/2008/10/post-3078.html

へこんでる当人には失礼な紹介のしかたかもしれません。ごめんなさい。でも感じ入っちゃったんで。

ちょっと違うけど、週刊文春で近田春夫がやってる連載みたいなのも、こういうかんじでできたら面白そうですよね。
-----------------
sent from W-ZERO3

インジケーター狂

テレビで野球の試合を見ていると、画面の左上隅に表示されているインジケーターが気になります。対戦チーム、スコア、イニング、ボールカウント、ランナーの状態をあらわしてる、あれですね。あれが、美しく、無駄のないデザインだったりすると、いいなーこれって惚れ惚れと見とれてしまいます。ま、2〜3秒のことですけれども。

Webでも、そういうインジケーター的な要素をデザインすることは結構あって、野球のあれを見習って真似したいなと思ったりします。

逆に、そういうインジケーターもので、これはどうなんだろうなと思うのが、JRの車両のドアの上にある液晶パネル、次の駅や路線図を表示しているあれですね。あれは、ごちゃごちゃで、不揃いで、美しくない。わかりにくいことはないんで、機能性としては問題ないと思うんですが、でも、もっとすっきり、もっとわかりやすくすることができそうな気が、見るたびにするんですよね。

JRの駅構内のさまざまな標識や案内板の類のデザインはどれもよくできてるのに、なんであれはあんなにダメなんだろうって。

あれ、表示エリアが大きく上下に分割されていて、面積としては、上が1/3、下が2/3くらいですね。

あらためて表示内容をよく見てみると、上が現在の状態の確認、下がこれからのアクセスのヒントって具合に、上下できれいに役割分担ができています。

▼上

・運行の種類、各駅とか急行とか 
・行き先
・次の、ただいまの駅
・何号車
・時間

▼下

・さまざまな粒度、着眼点の路線図
・乗り換え案内
・どちらのドアが開くか
・乗車位置、停車位置と駅構内の関係
(ほかに乗車上の諸注意も)

この整理は、情報デザインとしてはいけてると思うんです。これがうまくいっているので、けっしてなにがなんだかわからないってことにはなってないんですよね。

問題なのは視覚的なデザイン処理。

まず、とにかく無駄な罫線、囲み、色の塗り分けが多くて、見る者によけいな負担をかけています。そういうのを全部とっぱらっても、配置と余白に気を配りさえすれば、今できているチャンクが崩壊するようなこともないはずです。

それからたぶん、上側のレイアウトがあんまりうまくできていない。

左上隅に運行の種類、右上隅に車両番号、右下隅に現在時刻、そして中央に終点と次の駅名ってなってます。目をとめる場所が4ポイントもあるんですね。

たとえば、運行の種類、車両番号、現在時刻を、なんかシンボリックなアイコンでもつけて、左側に小さくコンパクトにまとめてみたらどうでしょう。

そして、行き先と次の駅、停車駅については残りのスペースを大きく使って、交互に表示してみたらどうでしょう。

すると、目をとめる箇所は左右の2ポイントだけになりますし、左側が常時表示エリア、右側がアニメーションエリアとなって、画面に対する注意の配分に戸惑うようなこともなくなると思います。

あとは、色が1〜2色多くて、強調してるつもりが全体を散漫にしているだけ、みたいな配色もありますね。運行の種類の黄色がそうだと思います。黄色って各駅停車の色で、快速がオレンジ、特別快速が赤ってなるんですけど、この色分けは比較対照がないとあまり意味ないですしね。

まずは、そのあたりの修正をプロトタイプで確認してみたいって、そんなことを思いながら電車に揺られて、今、これを書いています。
-----------------
sent from W-ZERO3

2008年10月29日水曜日

Mokuji β版

いつの間にか Mokuji で作った目次がかっこよくなってますね!

Mokujiで作ったこのブログの目次

前に「ブログ・トップページ・ジェネレータ」ってエントリーを書いたんですけど、そのときイメージしてたのも、まさにこんなかんじでした。これ見ると、本当にMokujiのほうをトップページにしてもいいなって思えてきますね。

勝手な要望としては、ページのタイトルのところ、ブログシステムによっては記事につけたタイトルの前に強制的にブログのタイトルがついてしまうので、Mokujiで表示する場合はこれがうざい。そこで、あらかじめ予約しておいた語句をタイトルから省いてくれる機能があったりするといいかな、なんて思いました。

それから、RecentEntryだけじゃなく、よりぬき記事や注目の記事にもスニペットを表示したほうが、目次、あるいはトップページとして、より魅力的な見栄えになるような気もしました。

しかし、こうなってくると、Mokujiの見栄えをよくするためにエントリーに画像を添付することも考えないといけないな、なんて思っちゃいますね。

読者は、エントリーへの直リンク、または、検索エンジンやフィードリーダー経由でアクセスしてくるのが普通で、ひょっとするとふだんは「ブログ」とか「サイト」とかっていうパッケージなんて意識することは少ないのかも知れないけど(自分がそう)、ときに、おやっと思った場合、これ書いている人誰? このブログ何? なんて興味が沸いちゃった場合、Mokujiの存在というのは、まずはじめに確認すべきものとしてうってつけだと思います。

おもしろい。

2008年10月28日火曜日

faviconのストイシズム

favicon デザインする上で一番大切なのはブックマークの一覧やタブブラウザに並べられた複数のタブの中にあって、すぐにそれと識別できるかどうか、ですよね。さっき、あるいは、いつか見たあのサイトのことだって、横に添えられたタイトルを読みとるしかない場合よりも手っとり早く。

だから、一番やっちゃいけないと思うのは、それ自体をひとつの独立した作品のように考えて、なにかまったく新しいビジュアルアートを拵えてしまうことですね。わー、いつのまにかこんなところに見たこともないすてきな favicon があるー!なんて喜ぶ人はいないわけで。

こういう言い方をすると、そんなまさか、と思われるでしょうが、けっこうやってしまいがちだと思うんですよ。

たとえばちょっと前に Google の favicon が変わったと思うんですけど、あれ、混乱しませんでした? だって、紫色の小文字の g って、そんなイメージ、サイトの本体のどこにもないわけで、あれを手がかりに Google のことをぱっと想起するのは難しいでしょう。ユーザにしなくても済む学習を強いてますよね。それとも、あれですか、今後に控えてる大きなデザインリニューアルの先触れなんでしょうか。それにしても、favicon の機能をまじめに考えれば、それはやっぱり順番が違う。

まあ、Google の場合は、使う回数が半端ではないので、そういう UI 学習もあっという間に済んで馴染んでしまいますけどね。でも、ぼくらが制作しているようなサイトではちょっとありえないやり方だと思います。Google だけに許された殿様デザイン。真似しちゃいけません。

では、われわれはどうすべきでしょうか。

存在意義から考えても、サイトIDの縮小版でいけるならそれが一番ですよね。しかし、たいていの場合、サイトIDをいくら縮小しても 16x16 にはおさまりません。

すると、まずやってみようと思うのは、サイトIDの形状のうちで、もっとも個性的な部分を切り出してみることでしょうか。

サイトIDにあしらっているシンボリックなマークだとか、ロゴのうちでも特にクセをつけている部分とか。

ただ、サイトIDから切り取ったその自慢の一部分が、本当にユーザに強い印象を残せているのか、あるいは、本当にその一部分で全体を代表させることができるのか、一度疑ってみる必要はあると思います。

たとえば、DELL のサイトの favicon は、DELL のロゴのEの部分、あの斜めに傾けて図案化されたEなんですけど、あそこだけを切り取ってみせられても、それが DELL の E だなんて、いわれてみないとわからないかもしれません。実はブックマークに入れたのを後で見て、ぼくは一瞬わかりませんでした。

いや、DELL の E が、それだけの状態で、サイトのいたるところ、目につきやすいところに繰り返し出現していれば、favicon を見たときに、おお、あれこそはたしかに DELL のサイトの一片だって思えたかもしれません。でも、こっちはロゴのゲシュタルトしか見ていないわけで。あの E のところだけで再認を求められてもってかんじです。

それならいっそ、サイトIDと同じフォントと色で DELL の D を favicon にしてもらったほうがわかりやすいと思います。

それじゃあ、デザインのやり方としてあんまり安直だし、ちょっとまじめすぎてつまんないなんて思われるかもしれませんが、favicon の要件の第一は、あのサイトのことだってわかってもらう機能性にこそあって、それでサイトのトーン&マナーに新しい価値を付け加えることじゃないわけですから。

アイコンとしての表象性や再認性を実現するもっとも確実な方法は、音韻と色調に頼ることだったりするんですよね。

だって、サイトのタイトルってちゃんと覚えてなくても、頭文字や一部を提示されると、ああ、そうそう、それそれ、そんなかんじってなりますよね。

それから、サイトの全体のトーンを決定づけているカラーというのは、やっぱり心に残るもんで、ほら、なんだっけ、あの CSS リファレンスの黄色いサイト、なんていう人、結構多くないですか。

キャラがあったりするとまた別なんですけど、アイコンにとっての"絵"は、そのへんに実はあんまり貢献してくれないんですよね。

favicon を作るときは、そのへんをわきまえつつ、結構ストイックに取り組むべきかも知れないなって思うんです。なんか、かっこいいのが欲しくなっちゃうんですけどね。

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

2008年10月22日水曜日

サイトの裏にメモを書く

Web サイトの運用を続けていくと、制作過程では見過ごしてしまったさまざまな欠点が少しづつ露わになってくるものですよね。あー、なんであのときそこに思いが至らなかったかなー、なんて。

理想的には、日々改善の精神で取り組みたいわけですが、限られた予算、人的リソースではスケジュール化された更新ルーチンをこなすので精一杯。見直し、改修は他日に期してToDoリストに書いておけ、ってなことになりがちです。

そのへんはいかんともしがたいところです。でも、これが、ToDoリストに書き加えることまで面倒くさがっちゃったりするんですよね。それもたしかに人情だろうけど、プロなんだからそこは頑張れ、なんていってね。でも、そういう ToDoリストは毎日書くものじゃないから、引っ張り出してくるのにけっこう骨が折れたりするのもまた事実なんで。

結局、そういう気づきは実際の画面を目の当たりにして生まれてくるものだろうから、その場でちょこっと、みたいなかんじでメモを残していけたらいいんじゃないかな、なんて思います。指摘したい箇所をくだくだしく指し示す手間も省けますしね。

たとえば、Wikipedia のノートみたいかんじとか。あれって、サイトの各ページにはまっしろな"裏"があって"表"に関するメモを好きに書いておけるという、そういう、裏書きメタファーですよね。

しかし、全部のサイトを Wikipedia みたいに作るわけにもいかないし。ファイル納品ってのもあるわけで。

じゃあ、あるサイトとまったく同じリンク構造をもっていて、ページが一対一で完全に対応する Wiki を別に持つってのはどうでしょう。サイトの裏 Wiki とかいって。

その Wiki のページは、対応するページのスクリーンキャプチャ、対応するページに含まれるリンクのリスト、そしてメモ欄からなっている。スクリーンキャプチャやリンクは専用のボットがクロールしてとってくるんです。

リンクをクリックすると、リンク先のページに対応する Wiki のページが表示される。

リンクのリストは、アンカー以外のインライン要素と、子孫にアンカーを含まないブロック要素を取り除いた DOM ツリーにしたがって表示されて、グローバルナビとかローカルナビとか、それなりに元のページのナビゲーションデザインを反映した状態で見ることができる。

一方、スクリーンキャプチャをクリックすると、対応するページが表示される。裏に戻れるナビゲーションが入ったフレームつきで。

サイトのあるページの URL を指定すると、対応する Wiki ページがすでに存在していればそれが表示されるし、なければ、新規に対応する Wiki ページが作られる。Wiki ページにリストされたリンクを辿っても同じこと。そうやって、求めに応じて、どんどん裏ページ、裏サイトが作られていく。裏ページへのアクセスはもちろん要認証でスタッフオンリー。

それでクライアントにも、何かお気づきの点がありましたら裏に書いておいてください、とかいうわけです。

あるいは、そういう Wiki を作成するサービスを一般に公開してみちゃうとか。勝手裏サイトを作るサービスなんていってね。

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

2008年10月21日火曜日

要求でも仕様でもなく説明がほしいのだ

要求を定義して、実装仕様に落とし込むまでに作るドキュメントにおいては、なにしろ要求と仕様と説明の三つをごっちゃにしないようにすることが肝心だといわれます。

やってみると特にやっかいなのは、要求や仕様から説明を引きはがすことですね。どうしてそれを要求するのか、なぜそのような仕様を選択するのか、その事情や背景を説明しようとする言葉が、うっかりすると、要求や仕様の定義の中に分かちがたく埋め込まれてしまいます。

もっとも、UMLで要求や仕様を表現するようになってからは、コメントとして説明を決まった場所に書けるようになったので、そうした混乱もだいぶ少なくなってきました。

ただ、UMLのコメントの場合、あくまでもそれは任意のもので、必ず書かなければいけないというかんじがしてきませんね。しかし、要求や仕様から分離された上での説明は、ドキュメンテーションの全体の中で、もっと重要視されてもいいんじゃないかな、と最近思います。

恥ずかしい話ですが、運用フェーズに入ってから、なにかトラブルに直面して、ああ、なんでまたそんな大事なところをアンドキュメントのままにしておいたんだなんて後悔することがけっこうあります。そういうときって、要求や仕様の定義ではなく、実は説明の欠如が問題になっていることが案外多いような気がします。何をどう作ったのかは明らかだけど、なんでそうしたのかがわからない。だから、ここの仕様をシステムの都合だけで変更していいものか、にわかには判断がつかない、とか。

こんな言い方には語弊があるかも知れませんが、要求は結果的に成果に置きかわるわけですし、仕様はソースコードそのものだ、という言い方もできます。しかし、説明は、制作の過程の中で何かに姿を変えて生き残るといことがないですね。

それなのに、ちゃんと書くか書かないかは任意、みたいな気になっているので、まるで書かれていなかったり、書かれていてもあとから探しにくいところにひっそりと書かれていたりして。

要求や仕様に混ざることなく、積極的に書き込まれ、参照されもするような説明の残し方ってなにかないでしょうか。

映画には記録係とかスクリプターといって、撮影記録をつけ、カット間の、いわゆる"つながり"を保証する役割の人がいますけど、Web の場合は、Web ディレクターが同じようなプライドで、こまめに記録係もこなすようにする。そういう努力が払われることは、まず大前提として。

でも、説明をどこに書けばいいでしょう。

後から参照することを考えれば、出来上がった各画面の説明が必要な部分に、直接付箋を貼るようにして書いていきたいですね。 でもそうすると、出来上がるまで書けない。

いや、Subversion なんかでバージョン管理をするのであれば、コミット時のコメントこそ、そういう説明を書く場所としてはうってつけかも知れませんね。あわせて Trac も使っていれば参照しやすくもなるし。

欲をいうと、Web サイトや Web アプリケーションの実際の各画面からコミット時につけられたこれまでのコメントをすぐに見られるように、どうにか手を回せないですかね。MVC と層があるわけだから難しいでしょうか。あと、コミット時のコメントに追記ができるようになるといいですね。コミットしたユーザ以外でも。

説明のドキュメンテーションについては、なんかそういう方向で進化させることができないかなあと、今は夢のように思うだけなんですけど、いずれ、なんとかしたいものです。

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

2008年10月17日金曜日

求人情報レビュー

求人情報掲載サービスもいろいろあって、うちの会社もときどき求人情報を出しますが、それぞれそれなりに値が張るわけで、そうそう、あちこちに出せるもんじゃないですよね。

いつもA社に出していたのを、ためしにB社に替えてみると、応募してくれる人たちの傾向もちょっと変わるね、なんて思ったり。求職するほうも、そんなにたくさんの求人サイトにアンテナを張りめぐらすなんてわけにはいかないでしょうしね。

そうすると、求人情報アグリゲーターみたいなのがあったら、求人するほうも求職するほうももっと幸せになれるんじゃないか、求人サイトだって流入口が増えて喜ばしいんじゃないか、ニュースとかと違って、読んでおしまいじゃないわけだから、アグリゲートされて価値が外部に流出するってこともないだろうし、おお、これって三方一両得?とかって思うんですけど、きっとそうはいかないんですよね。

まず、これの価値は網羅性にこそあるわけで、各求人サイトにマッシュアップ向けのAPIが揃っているならいざ知らず、あちこちのサイトをスクレイピングしてがんばるシステムをつくって回すのには結構バカにならないコストがかかるでしょう。だからって広告モデルなんていいはじめたら人のフンドシで金を稼ごうとするんじゃない、なんて怒られるに決まってるし。

それから、やっぱり、求人サイトが嫌がるでしょうね。アグリゲーターで探して、各求人サイトの末端の情報ページにディープリンクって経路ができちゃうと、サイト内での表示位置、表示面積にもとづく価格体系が脅かされてしまう。あと、ひょっとすると、求人側としては、どこかひとつの求人サイトに情報を掲載すればよくなるので、二股三股がなくなって、全体の市場規模が小さくなっちゃうかも知れない。なんて。

でも、じゃあ、アグリゲーターじゃなくて、こういうのはどうでしょう。

今の職場に漫然と不満があって、ヒマさえあればあちこちの求人情報を見ている Web ディレクターがいて。なかなか踏ん切りがつかないもんだから、結局、来る日も来る日も求人情報を漁ってはため息をつく毎日。でも、その人の求人情報を見る目はどんどん肥えていくし、また厳しくもなっていく。その上で、日々、ああ今もし転職するとしたらここに応募してみるな、なんて思ってる。そのうち、ただそう思ってるだけってのもなんなんで、いいと思った求人情報を出してる会社のことをちょっとネットで調べて、どこに惹かれたのかを簡単なコメントにまとめて、求人情報ページのURLをブログにアップしはじめて...。

ブログのタイトルは「今転職するならココだ!Webディレクター求人情報レビュー」とかいって。これ、転職を考えてる Web ディレクターならちょっと見てみたくなるんじゃないですか。それで、この人がやがてジョブボードみたいなので稼ぎはじめても誰も文句はつけないでしょう。

なんでこんなことを考えたかというと、ひとつ前のエントリーにコメントをつけてくれた   Web人さんのサイトを拝見して、なるほど、こういうのっておもしろいかも、と思ったからなんです。

Webデザイナー求人情報館
http://jo-ho-you.com/web/
Webデザイナーの仕事を募集している会社を紹介。転職、就職、派遣、新卒、未経験等あなたにピッタリの仕事が見つかるはず。

これですね。説明文はWeb人さんにお送りいただいたものです。

ただ、これ、もし求人サイトの許諾をとってないとすると、無断転載で怒られちゃう可能性もあるんじゃないでしょうか。ちゃんと許諾をとっていらっしゃるとのことです。憶測で勝手なことを書いてしまい、誠に申し訳ありませんでした。(2008/10/29 追記)

いや、個人的には、これで誰かが得をすることはあっても、損をすることはないはずだし、むしろ社会に貢献してるといってもいいくらいのすばらしい企画だと思うんですけど。

やっぱり、そういうつまらない突っ込みを避けるためにも、転載部分が公正な慣行と正当な範囲内の引用になるよう、求人情報レビュー、求人情報評論家の草分けっていう路線で攻めてみるってのはどうでしょう。


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

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