2008年12月25日木曜日

うごメモは、たぶん

うごメモはたぶん、はてなのところは一種の予選会場で、あそこでみんなにほめられた作品は、もっといろんなところへ、ネットの中はもちろん、ネットの外にまで飛び出していく。任天堂がDSの広告枠をつかってね。

特に、ネットの外こそ決勝リーグみたいなもんで、テレビはもちろん、電車の車内ディスプレイやコンビニのレジのところにあるディスプレイ、あと街頭ビジョンとか。そこら中に、自分が作ったパラパラアニメみたいなのがハンドルネームとともに流れる。あーいまみた?あれおれの!なんつって、自分の手の中にあるDSがそういうメジャーなメディアにつながっているというわけで、これは燃える人は燃えるでしょう。特に小中学生、高校生、大学生。

なんだかんだCGMとかいっても、こういう非対称性こそ投稿モノの肝でしょう。ケータイ大喜利とかね。また、そうなってこそ、はてなもつられて全国区ってなもんでしょう。いや、そこまでいく話はついてるんじゃないですか。

きっとニコニコ動画あたりも大きなヒントになっているんだと思いますが、なにか誰にでも気軽にクリエイティブな活動ができる道具を作って、配って、その道具によってこそ日の目を見るような才能をあぶり出して、同時にオーディエンスとしてそれらを冷やかせる場も用意して人も呼んで(というか、最初の火種としてはてな界隈を選んで?)。そして任天堂パワーがあれば投稿ゴコロのくすぐりかたも並大抵じゃないよ?という。モノのデザインがそこまでの射程で考えられているってかんじで、これはすごいですね。

このパターンは音楽とか、ひょっとしたら映画とか、DSベースでいろいろ出てきそうな気もしますね。DS自体の進化とともにね。

って、これはやっぱり妄想でしょうか。

そういえば、今度カヤックがリリースしたFlashムービーを作成できるWebアプリ、あれは開発環境と Perl でいう CPAN みたいな開発者コミュニティ&ソースコードライブラリが一体になっているかんじでおもしろいですよね。あ、うごメモも人のを改変できたりするから、そういう一面があるのか。

とにかく、クリエイティブとクリエイティブをめぐるそうした一種のエコシステムを一挙に提供するって方向、それに加えて、思い切ったアマチュアリズムっていうのか、何かそういうのに光がありそうですね。

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

2008年12月18日木曜日

喜びの声の機能

本とかソフトウェアとか、あるいは、テレビの夜中の通販で取り扱っているものとか、自分のものにするまで、よくわからないことが多いものを買うときは、すでに自分のものにした人たちの意見を聞きたくなりますよね。

Amazonの評価とかね、もともとは立ち読みできないことを補うって発想だったのかも知れないけど、ぼんやりした自分の頭だけで立ち読みして判断するより、なんていうか、よっぽど、機能的ですよね。

購入を検討している人にとっての評判の確認って、ふたつ効果があるんだと思います。

第一に、こんなの買っちゃって自分だけが馬鹿を見るんじゃないかっていう不安や迷いの解消ですよね。それがそもそもの目的だし、本人も自覚していることですね。

あと、もうひとつ、そうやって先行する人たちの自慢を見せつけられているうちに、つい羨ましくなっちゃって勢いづいちゃう、という面もあると思うんですよね。

バイラルとかクチコミとかって、存在そのものを知らしめる手段としてターゲティングやコストの面で効果的ってだけじゃなくて、リーチのプロセスそのものが、そうやって購入動機の形成や購入の決心に良い影響を与えるからいいんですよね。

じゃあ、あれはどうでしょう?通販サイトとかで、ユーザーの皆様から喜びの声が続々 ... とかってやるやつ。

今、まじめに考えて、Amazonの評価とか他のブログや掲示板に書き込まれたレビューと、売り込もうとしている張本人が仕込んだに違いない、宣伝媒体に掲載されているユーザーの声を、同じものとしては受け取れないですよね。

いや、でも、それは、Webがあってこその比較なのかも知れないですけどね。

ブログやらSNSやら、もう全体として「評判データーベース」と呼んでもそんなに的外れじゃないような代物が目の前にあって、いうなれば、一億総レビュアー時代、今こうしている間にもきっとどこかで誰かが何かをレビューしているのです、ほら、あなたの隣にもって具合ですから。

つまり、売り手でもすでに買い手でもない"第三者"に、これだけアクセスしやすい状況は、Web以前になかったわけでしょう。

でも、購入前の評判の確認をめぐる動機や効果はWebとは関係なく昔からあって。すると、パンフレットやテレビ番組で、そこんところに刺さる情報をを提供しようとすれば、おのずと、おなじみの、ユーザーの皆様から喜びの声が続々 ... というかたちにならざるをえない。

話はそれますけど、こういうふうに、コンピューターやネットワークが発達してみて、これまでの実現形態やデザインが実は次善の策だったり挫折形態だったことが判るってことは結構あるような気がしますね。たとえば辞書とかね。あれは明らかに紙媒体には向かないコンテンツでしょう。
長い年月の間、辞書が分厚い冊子としてあったのは、それがベストだったからではなくて、それ以外にやりようがなかったからですよね。

それはともかく。

で、その喜びの声ですけども、でもね、テレビの通販番組なんか見てると、上に挙げた評判の確認の効果とは別の意味で有意義に活用されているな、とも思うんですよね。

セールストークの基本は、セールスポイントを繰り返し説いて、強調して、ユーザをその気にさせることですよね。しかし、売り子の目線と言葉で繰り返してると、ほんとに同じことに繰り返しになって飽きられちゃう。そのとき、有効なのが、喜びの声ですよね。

代わる代わる違う人が出てきて、結局はいくつかのセールスポイントに収斂していく話をするわけです。
これで、言葉は悪いかも知れないですけど、飽きさせずに同じことを刷り込んだり、植え付けたりできるようになる。

仕込まれた喜びの声だから話半分で聞くわけですけれども、ここには、スリーパー効果ってのがあるそうです。あまり信頼できない人から真偽のほどが定かではないことを聞くと、その場では胡散臭く思う。
でも、時間がたつと、話の内容と話した人から受けた印象は記憶の中でだんだん切り離されていくんだそうです。で、結果として、話の内容にまとわりついていた胡散臭さはとれちゃって、セールスポイントだけがフラットに残る。

そのへん、ちゃんと狙って作ってるのかなあ、とも思うんですよね。
そんなわけで、外部により信頼のおける第三者の声があふれかえっている世界においても、売り手の宣伝媒体における喜びの声にまったく意味がなくなったわけではないと思います。

だから、たとえば、ぼくらが何かのプロモーションサイトなんかを作っていく上では、喜びの声は、そうした、セールストークをリフレインするための手法として考えていくのがいいんだと思います。

間違っても、かつて喜びの声にも期待されていた、購入の一歩手前にいる人の背中を押すという役割を担わせようなんて思ってはなりません。

そっちは、正々堂々、外部のブログとか評価サイトとかにまかせる、というか、購入を検討してくれた人はたぶん自分で探しにいくんだろうから、サービスとしてそういう外部リソースのアグリゲーションくらいやってあげてもいいんじゃないでしょうか。仮にマイナスの評価が含まれてしまうとしても、あえて大目にみて太っ腹にね、公正に。

きっとそのほうがユーザーの皆さんとはやく仲良くなれますよ。

2008年12月16日火曜日

思わず完成させたくなるような立派なコンファメーション

入力フォームのデザインやユーザビリティ、それに HTML/CSS のコーディングのしかたについてはたくさん語られもするし、いろいろなサンプルが出回ってもいるんですが、確認画面、コンファメーションのところはどうなんでしょうね。

一回送信してしまったらあとで編集したり取り消したりできないような情報の登録については、この内容でよろしいですか?なんて画面を必ず挟むわけですけど、あれのうまいやり方とか、やってしまいがちな失敗とか、そういうのって何かありますかね。

なんとなく前から思っているのは、あれ、あんまり入力フォームに似てちゃ駄目なんじゃないでしょうか。たんに入力フォームの部分がテキストになっているだけみたいなのだと、面倒くさいのを我慢して今入れたばっかりのをもう一回あたまからなぞらされるなんてもううんざり、なんて、結局スルーされちゃいがちなんじゃないかって。

ブログ書いてても、編集画面では全然目にとまらなかった誤字脱字が、公開ページではパッと発見できたり、eラーニング教材のデータを作っていても、データを入力したメディアで何度も文字校正をかけたはずなのに、実際の学習画面を見始めると、また急にあちこちに修正が入ったりして。

結局、入力内容の確認は、入力時とは異なる見栄えでやったほうが有利ってことなんでしょうか。経験的にいっても、慣れや飽きが注意の敵なんだというのはなんとなくわかりますしね。

じゃあ、事前に空欄の確認用レイアウトを見せて、これを完成させるために入力フォームを使うって了解にもとづいて入力してもらうのはどうですかね。入力し終わったときのユーザーの気持ちが、うまくできたかな?になるような。ブログとかのプレビューがそれに近いわけですけれども。なんか Flash とかで立派な申請用紙みたいなのができてるとかね。無駄かな。

細かい話ですけど、入力のしやすさ、データ表現の揺れの回避、あるいはデータの取り扱いやすさのために、入力欄を分けることはあっても、確認するときはそれらをまとめて表示したほうがユーザーとしては目や頭に入れやすいってものもありますよね。入力の都合の単位とユーザーが把握しやすい情報のチャンクは必ずしも一致しないわけで。姓名、住所、電話番号、日時とかね。だから、あながち、完成させたくなるようなやたら立派な確認画面ってのも、無駄にゴージャスなだけってわけでもないような気がするんですよね。

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

2008年12月12日金曜日

ネットの万次郎

夜中にケーブルTVで同時通訳も字幕もなくなったCNNに見入っちゃうことがあります。番組にしろCMにしろ、ビジュアルの作り方が日本のTVとは大分違ってておもしろいんで、何いってるかよくわからないながらも、頭からっぽでついボーっと見続けちゃうんですよね。そうしてみると、英語もまったく聞き取れないわけじゃなくて、知っている言葉はちゃんとわかるな、っていうか、聞いてると、今のあれか、って、知っている単語のスペルやカタカナと今聞こえた音声が急に一致する瞬間があって、地味に小さな感動を覚えたりします。いや、アホ丸出しで恥ずかしい話なんでけど、そうなんです。

だから、

英語ができないたった1つの決定的な理由
http://anond.hatelabo.jp/20081101050330
http://blog.livedoor.jp/dankogai/archives/51133522.html

なんかで言われていることは本当なんだろうな、とか思って、ふだん英語なんておれには無縁と決め込んで暮らしてても、ちょっと乗ってみたくなりますね。

しかし振り返ってみると、中学から大学出るまで、覚えさせられた英単語のそれぞれをネイティブがどう発音しているのか、ほとんど確かめてこなかったような気がします。だめだこりゃ、ってかんじですよね。今や、goo や excite の英和辞書には音声がついてるし、電子辞書でもそういうのがあるんだろうし、昔より格段にネイティブの発音を確かめやすい環境が整っているでしょう。今、中学生や高校生をやってたらちょっとは違うのかな、どうなんでしょう。心がけ次第っていやそれまでですけど。

そういう意味では、iKnow! のブックマークレットがすごいですよね。ブラウザに表示されている英単語の訳だけじゃなく発音までその場で確認できるというやつ。

http://www.iknow.co.jp/bookmarklet

できれば、マウスオーバーで音まで出るといいんですけどね。そしたらこれと一緒に毎日適当にIT系のニュースを追っかけていくだけでもけっこう英語が聞き取れるようになれそうな気がしちゃいます。ってそれは気のせいかな。

あと、上に紹介したURLで、dankogai さんがいってることも、そうかもなーって思うんですよね。要するに、あれでしょ、パックン英検みたいにして、和英じゃなく、英英で、語句の意味のネットワークを自分の頭の中に作り上げていくのがほんとの近道、ってことですよね。

パックン英検
http://www.nhk.or.jp/night/pakkun.htm

思うに、ジョン万次郎なんて、そうやってがんばったんでしょうね。これなんていうの?これどういう意味?って聞いても、英語でしか返ってこないわけで。たぶん五感との対応で直感的に了解できる語を自分のものにするところからはじめてね。

そういえば、学習したい言語で日記を書いて、それをネイティブの人に添削してもらって、その一方で、自分は自分の母国語で書かれた外国人の日記を添削してあげるという lang-8 ってありますよね。

http://lang-8.com/

これは外国語学習のグローバルなエコシステムってかんじで、なんて素晴らしい実践なんだろうと思うんですけど、これをパックン英検でやったらおもしろそうじゃないですか。

各国とも自分の国の言葉のうち基本中の基本で使用頻度の高そうなのを2000ぐらいピックアップして、みんなでその語句の意味を外国人に聞かれたつもりで、なるべく平易な言葉つかいでわかりやすく説明してみるんです。できれば音声で、だめならテキストで、音声かテキストにイラストや写真を添えるのはOKにして登録。で、それをいろんな切り口でまとめて、ID3タグつきのMP3とかでダウンロードできるようにしたりして。

なんていうんでしょう、ひとつの言葉の意味を確かめるのに、いろんな人の説明を聞いてみるってかんじで。そういえば、CNNを英語がわからないながらに聞いていると、話す人によって、なんか聞こえてくる語感の印象がけっこう違うんですよね。

いろんな人の、それぞれに他とは微妙に違う感じのする音声にたくさん触れて、そういう言葉をしゃべっている人たちがうじゃうじゃ確かに存在していることを感じながらボキャブラリーを増やしていくのって、学習方法としてもけっこう効果的なものになりそうな気がしませんか。教えてくれる人のキャラがたってたりして、その人なりに一生懸命説明してくれている様子が伝わってきたりすると、いわゆるエピソード記憶としても心に残りそうでしょ。特に中学生になって英語を習い始めるときなんか、最初にまとめて聞く英語が日本人教師の日本語なまりのっていうのよりは、だいぶいいんじゃないでしょうか。

さて、教えてもらったら、教えてくれた人にちゃんとありがとうと言うのが礼儀ですよね。だから、どんなんでもいいから、音声でもテキストでも、感謝のメッセージを送れるようにしておくんです。それと、自国人としてみて、その説明はうまい!というのをオススメできるようにもしておく。で、それらの数をポイントとしてみて、登録された説明をレーティングしてみたりして。そうやって自分の国の言葉の意味やニュアンスをどううまく説明できるものか、みんなで知恵を出し合っていく、すると、それが自国語を学びたい外国人のためになると。で、それはめぐりめぐって、ちゃんとお互い様になっている。

いやあ、なんていうか、実に愛にあふれた、善のかたまりみたいな活動じゃないですか、これ。いかがなもんでしょう。

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

2008年12月9日火曜日

サイトメッセージチャートの書き方

前に、サイトストラクチャからいきなりワイヤーフレームを描くのは乱暴で、その間に「サイトメッセージチャート」といって、各ページでユーザーに提示されるメッセージとページ間を結ぶユーザー導線を一望するような図を描いてみるのはどうか、というエントリーを書きました。

http://chushoww.blogspot.com/2008/09/blog-post_23.html

で、これを描くためのツールをずっと探していたのですが、いろいろ試してみた結果、Judeのステートチャート図で描くのがよさげ、という結論に達しました。

Jude
http://jude-users.com/ja/

ためしに、Firefox の製品情報サイトを図にしてみたのがこれです。

http://dl.getdropbox.com/u/223789/site_message_chart_sample.png

こう書いてしまうと、じつにあっけないもんですよね。しかし、このあっけなさで、サイトデザインをいったん把握しておきたいんですよね。そうしないとワイヤーフレームを描くという行為がなんだか当てずっぽうなものになってしまうわけで。

さて、以下、作図のしかたの簡単な説明なんですけど、Jude でステートチャート図を描いた経験があることが前提になってしまいますので、悪しからず。

いや、特に知らなければ読みとれない記法があるわけでもないですし、その気になればパワポなんかで書いてもいいわけです。Jude じゃなきゃ書けないというわけではありませんよ。念のため。だけど、この図を描くのに、なるべく作図のオペレーションに気をとられないようにするには、と考えたときに Jude がおすすめかな、ということです。

えー、前置きが長くなりました。では、いきます。

一見しておわかりいただけるように、なにしろ「ステート(状態)」をページに見立てて描いていくわけです。当然、ステートの「名前」はページのタイトルになりますね。

そして、ステートの「内部遷移」の「イベント」に、当該のページにおけるユーザーへのメッセージを書きます。「イベント」と一緒に「ガード」と「アクション」を入力できますが、ふつう、これらを使うことはないでしょう。でも、ある条件の下でのみ表示されるメッセージの場合は、条件を「ガード」に入力するのがいいかもしれませんね。メッセージの記述順は、ユーザに提示する順番、もしくは、重要度の高いものから、と考えてよいでしょう。

ページ遷移=ユーザー導線は、「遷移」の矢印つきの線でページとページを結ぶことで表現します。「遷移」の「イベント」に、当該の導線に対応するリンクやボタンのラベル名を入力します。「アクション」には、その際の、ユーザーの動機や要求を想像して入力しておきます。

Jude のステートチャート図では、ステートを入れ子にすることができます。
必要に応じて複数のページをグルーピングしておくと、作図が冗長になる(導線だらけになる)のを避けることができます。グルーピングのためのステートの「名前」にはグループのタイトルを入力します。グループの「名前」は、それがページではないことをあらわすための記号(例:"▼")から始まるようにするといいでしょう。

また、グループ内に含まれるページに共通するナビゲーション上の要件や特徴を明示したい場合は、グループのステートの「ステレオタイプ」に書いておくのがよさそうです。たとえば、ランダムにアクセスされる並列コンテンツの一群であれば「ランダムアクセス」とか。認証が必要なコンテンツの一群であれば「要認証」とか。

このようにして、あるページでユーザーに提示されるメッセージの内容とオプションのラベル、あるオプションを選択するユーザーの動機や要求、そして、オプションを選択した結果として提示される次のメッセージの内容とオプションのラベル... と、こういった流れがスムーズに、自然につながっていることを確認しながら、要件段階で定義されたサイトの目的とユーザーのニーズをページに分解していけばいいのではないかと、こういうわけです。

しかし、いまのところ、いってみれば、これはプロトタイピングの段階ですね。これからいろんなケースに適用してみながら、本当に使って役立つものになるのかどうか、見極めていきたいと思います。

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

2008年12月5日金曜日

リッピングしてシンクしてあとで読む

通勤中や移動中の電車の中、w-zero3 の IEで、はてブをみたり、青空文庫を読んだり、気になったことをググったりします。でも通信で待たされたり、通信が途切れたり、いくらフルブラウザっていっても、PC向けのデザイン、レイアウトをこの中にレンダリングするってのにはやっぱり無理があったりで、相当に便利なんだけど、快適かっていうと、あんまりそうでもない。

いや、何か検索したいときってのは、不思議とそういう困難も、べつにたいして気にならないんですよね。もう、探すってこと自体が、いろんな検索キーワードの組み合わせを試したりして、全体に試行錯誤上等のチャレンジングな行為だからかもしれませんね。

でも、ぼーっと、はてブを斜め読みしたいときなんかは、通信やレンダリングがうまくいってないと、ああ、もう!ってすぐ思っちゃいますね。読むこと以外のことに気を使う時間が長すぎる!って。

ね、おんなじツールの話でも、コンテクストによってこうも違うわけですよ、ユーザー体験って。なんてね。

それはともかく。で、思ったんですけど、検索は今のままでいい。その気になれば、モバイルでどこにいてもインターネットのリソースにアクセスできることが担保されているっていうのは非常にすばらしい。でも、なんかちょっと時間をみつけての軽い読書、っていうか、雑誌や新聞に目を通すような体験は、今のままではつらいんで、これはたとえば、iPod=iTunesモデルで臨むべきかもなって。リッピングしてシンクしてあとで読む、みたいなかんじ。もちろん PC ありきの話として。

いや、話は単純で、リッピングって、ようするにダウンローダーですね。PCでフィードを読んで、新着 URLの内容をダウンロードしておく。ただ、Googleやはてながやっているモバイル向け変換を施してね。あれは、大変助かります。でも、権利関係的にはどうなのかな、とちょっと疑問でしたが、これならいいでしょ。個人の楽しみだけのためで。

それで、w-zero3 を PC に接続すると、ダウンロードしといたのを、だーっと Active Sync でシンクっていうか、w-zero3 に取り込んでね、で、あとでオフラインで読むと。

これ、どうでしょう。iTuneに相当するものとして、livedoor Reader みたなやつがあったりして。

そういえば、サイドフィードのサービスで、「あとで読も」っていうのがありましたね。

http://press.sidefeed.com/archives/2007/01/post_15.html

これしばらく気にいって使ってたんですけど、ぼく実は非常に怠けもので、人がブックマークしてくれたやつを読みたいんですよね ... 。

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

2008年12月3日水曜日

アクセスレポートは自然に出こない

Google Analytics のおかげで、Webサイトのアクセス状況を把握するのもずいぶん楽になりましたが、ケータイサイトではその恩恵に与れないんで、必要に迫られて http の生ログと格闘することもしばしばです。PC向けのサイトにしたって、なんでもかんでも全部 Google 頼みでいいかというと、規模やその他諸々の事情でそうはいかない場合もありますしね。

そもそも、Google Analytics を使うかどうかも含めて、要求段階でアクセスレポートについての定義が行われるべきだし、サイトストラクチャを書いてユーザー導線設計を行う際にも、ロギングについての計画があわせて検討されるべきですよね。それは直接に URL 設計に影響を与えるだろうし、HTTPのアクセスログの解析では得られないデータが要求されるのであれば、当然、専用のロギングシステムの実装を検討しなければいけないわけだし。

Web のメディアとしての特性のひとつは効果測定を正確に行えるところにあって、なんつっても、それって、だまってほっといてちゃなかなか容易なことではないんですよね。バンバン記録しといてください、あとでびっしびし読み解きますから、なんていうのは、実はぜんぜん通用しない。ログというものはあっと言う間に膨れ上がるもんで、そうそう手放しで長期間とっておけるもんでもないし、あとでこれこれこういう切り口で集計したいっていっても、げんに今ある数々のURLのバリエーションから、はたしてそうしたまとまりをつかみ出せるかどうかわからない。

このあいだ自分でHTTPの生ログを相手にそういう後出しの集計をやってみて、その無謀さをほとほと思い知らされました。これはじつに面倒くさい。

で、そうやって、ロギングについて思いをいたしてみると、この領域はメディア特性の一大特徴みたいに言われるわりには、けっこうまだまだプリミティブな状態にあるんじゃないかなあ、とも思うんですよね。

たとえば、ロギングの単位、じゃなくて、集計の単位は必ずしも URL じゃないんじゃないか、とか。まあ、これは集計ツールの汎用性をいかに担保するかということにも絡むんですけど、しかし、よくクライアントから求められるのは、あるセクションの(1)トップページと(2)その下位階層全体のアクセスレポートなんてかんじだったりします。把握したいアクセスの粒度はそれくらい大ざっぱで、また、下位階層っていうときの階層って、URL のパスの階層と一致しない場合もあるんですよね。効果測定の対象は、そういうふうに認識されているコンテンツのまとまりなんであって、けっして、URLがその表現となるようなデータ構造ではない、っていうか。

プリミティブっていいましたけど、たぶんサーバーを運用するエンジニア向けのレポートと、マーケティング向けのレポートが未分化なんですよね。いや、もともと、たいていのアクセスログ解析ツールは前者の要求に応じて作られてきたわけなんでしょう。Google Analytics は、そこのところを後者にふってみたという意味で画期的だったんですね。でも、まだ、前者にひきずられているような気もします。

ユーザー導線設計の抽象度にフィットしたロギングの定義を事前に行って、マーケティング指向に対して必要充分なアクセスレポートを残すことをサポートするような、CMS なり、Web アプリケーションフレームワークなりが出てくるといいなって思うんですけど、どうでしょうね。まあ、まずはそこまでいかなくても、個別の案件で、プログラマーと相談しながらそういう方向を追求してみたいなと思ってます。それもWebサイトデザインのうちってことで。

 

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

2008年12月2日火曜日

Webサイトのイメージチャンプルー

あたらしいWebサイトを作るとき、サイトの存在価値や運用上の目標が定まったならば、次に、サイトの具体的な姿についてのイメージを、クライアントも含めたプロジェクトメンバー全員の間でしっかり共有しておくことが肝心です。これがきちんとできていないと、細部をつめていくごとに、みんながてんでばらばらなことを言い出して、Webディレクターは悲しい思いをすることになります。

しかし、Webサイトのイメージをみんなで共有しようとして、いきなりラフスケッチとかワイヤーフレームとかモックアップとかプロトタイプとか、画面のイメージに近づこうとするとのは、ぼくは間違いだと思います。これらは、それぞれ、広い意味でのユーザーテストの対象といっていい、中間成果物です。

ラフスケッチをユーザーテストの対象というと、奇異に聞こえるかも知れませんが、それをレビューする側は、スケッチから読みとれるナビゲーションやコンテンツの片鱗をヒントに、頭の中でいろいろと補完して、そこから何が読みとれ、そこでどんなアクションを起こしうるかシミュレーションするわけです。脳内の想像的なユーザー体験がうまくいかないと、ラフスケッチのあちこちを指さして、これはどういう意味?、ここはなんでこうなってるの?とラフスケッチを描いた人の頭の中にあるイメージを問い質すことになります。でも、それこそ、あらかじめ共有しようとしていたものでしょう。

どんなに粒度が粗い状態であれ、画面というのは常に最後の難関なんだと思います。画面は何かを表現するものですが、そこで表現されるものをプロジェクトメンバーの間で共有する目的でなら、画面よりももっと端的で直接的な方法があると思います。

たとえば、そのサイトに訪れたユーザーに一体どんな経験が待っているのか、ユースケース図やユースケース記述を書くほうがいい場合があります。また、ユーザーとWebサイトとの間の具体的なインタラクションに特徴があるなら、その部分をシーケンス図で書くほうがいいでしょう。あるいは、情報のカテゴライズに工夫があるなら、ツリー状のサイトマップを書けばいいでしょう。そして、そうしたさまざまな表現方法を必要に応じて大胆に混ぜながら、全体として共有されるべきイメージが描き出せればいいはずです。Webサイトのイメージチャンプルーですね。これは、あくまでもテストのアンチョコであって、けっしてそれ自体がテストされるようなものであってはなりません。

そして、イメージチャンプルーで明らかにされたことをうまく画面表現に変換できるかどうかを探るためにラフスケッチを描き、発見された画面表現の一貫性を確認するためにワイヤーフレームを描き、ワイヤーフレームに基づいた最終的な視覚表現の良し悪しを評価するためにモックアップを作成し、インタラクションのユーザビリティをチェックするためにプロトタイピングするわけです。

だから、web creators 2009年1月号の特集ページで「Web サイト制作をラフスケッチから始める」とか、「ラフスケッチでイメージを共有する」とかいう見出しが掲げられているのを見ると、正直、ちょっと違和感を覚えてしまいます。

もちろんチャンプルーの一部として、ラフスケッチを使うことが有効なケースはありえます。たとえば、レイアウトやインターフェースデザインの独自性を狙う場合など。しかし、ラフスケッチをWebサイトのイメージを共有するためのキラーメソッドだとしてしまうのには無理があります。

実は、ぼくの職場は元々編集プロダクションだったこともあって、ある時期までまさにラフスケッチドリブンな制作を行っていました。そしてその結果、以上の認識にいたるような失敗を繰り返してきたのです。いや、今でも、ラフスケッチをワイヤーフレームと言い換えただけで(これ自体間違いなんですが)、同じ失敗を繰り返してしまうことがあるくらいです。

ユーザーテストを軽視してきてしまったのも、「編集部員」がラフスケッチ=ワイヤーフレームを描いて「編集長」や「デスク」にレビューを乞うというプロセスが、不十分なかたちでユーザーテストを先取りしてしまっていたからではないか、などと疑っています。

なんていう自戒をこめつつ、Web サイトのイメージを共有するならチャンプルーでいこう、だから Web ディレクターたるものいろんな作図法に明るくなくちゃね、と、少なくとも自分の周りには強く主張したい次第です。


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

2008年11月27日木曜日

漢字かな交じり文が亡びるとき

「日本語が亡びるとき」を友達に借りて読みました。最後のほうは、なにかもう絶叫調といってもいいくらいの高いテンションで、日本語が亡びるのはフランス語が亡びるよりも人類にとってよほど大きな損失である、とか、読んでるほうがはらはらするようなファナティックな言いぐさもぽんぽん飛び出して、べつにこれは皮肉じゃなく、なんだかじつに楽しく読めました。

ただ、たんに楽しいだけじゃなく、漢字かな交じり文という書記システム自体が、ほかでもない日本の国語教育の楽天性を底で支えてもいる表音主義=音声中心主義の批判として意義を持つのだ、という指摘には、たしかに、と納得させられるものがありました。

世界中のどこででも、近代的な国民国家を作るときには、誰にでもすぐに使える共通語として、表音主義的な国語の整備、日本でいえば言文一致のようなことが行われます。それはいいんですけど、そこで、自然に話せる主体とはすなわち達者に書ける主体でもあるという錯覚が起きちゃうのか、たいして読まないくせに臆面もなく書く主体がのさばりはじめたりしちゃうわけです(いま、自分のことは棚に上げて書いています)。あげくのはてに誰もが感じたままに書けばそれでたちまちオンリーワンの価値が生まれるでしょう、なんて言い出す始末。

人は書記システムの制約の範囲内でしか思考できないのだから、書記システムの充実こそが文化全体の隆盛をもたらすといっても言い過ぎではない、としてですよ。ある文化の書記システムを鍛えるのは、優れた書き手によって脈々と書き継がれる歴史そのもの、そして、その優れた書き手を養うのは、書くことの前に、そうして書き継がれたものを読みこむ体験に他ならないでしょう。

だからかんたんに書く前にもっと読みなさいよ、そうしないと、日本語の書記システムはどんどん貧しくなってしまいますよ、と、こういうことですね。この本がいう国語から現地語への転落というのは、質の高い書記システムを失うということです。

こうした考えは、表音主義にもとづく錯覚から目覚め、ますは、日常の用のための口語と思考の道具としての書記システムを峻別して使い分けなければならないとする認識から生まれるわけですけれども、そのことを疑うのなら、ほら、この漢字かな交じり文の妙を見よ、と、こうなるわけです。たとえば、同じ語句を漢字、ひらがな、カタカナで書けて、それぞれに異なるニュアンスを託すことができるこの豊かさといったらどうだ、口で言って耳に聞くんじゃ、こうはまいりますまい?といった具合に。

でも、肝心の漢字かな交じり文の妙に関する説明がちょっと説得的じゃないんですよね。

この点については、柄谷行人の「日本精神分析」を読んだほうがいいと思います。

「日本精神分析」には、漢字かな交じり文の書記システムとしての特性が日本人の思考(日本精神)をどう規定してきたのかについての論考が含まれています。中華、西洋から外来する宗教や思想を取り込みつつ、それらを完全には日本のものとしない巧妙なからくりが漢字かな交じり文によって仕掛けられていたのではないかという話で、水村美苗がいうニュアンスの話も実はこのからくりの結果にすぎないといっていいと思います。

大学生のころ、この話にはじめて触れたとき、ふだん無意識に読み書きしている日本語を急に書記システムとして外から眺められるようになったような気がして、ずいぶん興奮した覚えがあります。「日本語が亡びるとき」を読んだすべての日本人は「日本精神分析」を読んだほうがいいような気がしないでもないですよ。

それから、「日本語が亡びるとき」で、さかんに批判されている「想像の共同体」のベネディクト・アンダーソンですけど、たしか柄谷行人と一緒にやった講演の内容が載った雑誌を昔買ったよなと思って家の中を探してみたら、埃をかぶったのがありました。「文学界 2000年10月号」。これに「創られた『国民言語』」という講演のために準備された論文が出てまして、柄谷行人が明らかにした漢字かな交じり文のからくりと同じようなことが、タイ語でも行われていたことなどが紹介されています。漢字とかなのように種類の違う文字を使うわけではないんですけど、綴りに特徴をもたせて外来語を区別したりするみたいなんです。

なんてかんじで、「日本語が亡びるとき」、昔の本を引っ張り出して読みたくなるほど、ぼくにとって刺激的な本だったことには間違いありませんでした。でも、帯で煽っているような、地政学を度外視するインターネットによってますます勢力を拡大する"英語帝国"の周縁にあって、はたして日本語は生き残ることができるのか、という本では、実はなかったと思います。それはむしろ話のきっかけにすぎなくて、そうした外的な情勢とは本質的には関わりのないところで、<書き言葉>としての日本語の質が失われていくことに警鐘を鳴らす内容といったほうが当たっているのではないでしょうか。

あ、あと、一章と二章は、外国人作家との出会いをつうじて、自分が日本語で書いていることに動揺してしまった日本人作家の姿を描いた短編小説としておもしろかったです。今はこの人の「続明暗」を読んでみたいです。


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

2008年11月21日金曜日

星にまつわる内省的デザイン

きのうの深夜のことなんですけども、酒がきれちゃいまして、でもまだ飲み足りないかんじだったんで、仕方なく近所のコンビニまでのこのこ買いに出かけたんですね。そういうときは、ほら、一日のうちでもっとも余裕しゃくしゃくな時間帯ですから、ふと夜空なんて見上げてしまいがちなんですけれども、まー星がきれいに見えてまして。ほえー!なんてあてのない声が出たりして。でも、学がないもんで星座なんてオリオン座くらいしかわからないんですよね。

それで思ったんですけども tonchidot のセカイカメラじゃないけど、こう、ケータイかなんかを空に向けると、モニターに、向けた先に見えるはずの星が映し出されたりしたらおもしろいんじゃないか、なんて。GPS と 傾きセンサーみたいなのがあれば、なんかできそうじゃないですか。いいかげん酔っぱらってたんで、おーこれはおもしろい、帰ったらブログに書いとこうなんて、一人で盛り上がってたんですね。

でも、ちょっと調べたら、もうあったんですね。しかも2006年に。

携帯電話で星空を楽しむ、月刊星ナビVアプリ「星座をさがそ」を開発
http://www.astroarts.co.jp/release/2006/03/v_seiza/index-j.shtml

これ、けっこう画期的なおもちゃだと思うんですけど、当時話題になったんでしょうか。全然知りませんでした。

ただ、今度は、タイトルをかえてDS版を出すみたいですね。

【新製品情報】ニンテンドーDSR用ソフト「星空ナビ」を開発中
http://www.astroarts.co.jp/news/2008/03/05ds-hoshizora/index-j.shtml

こっちはかなりくるんじゃないでしょうか。すでにいろんなブログで期待感をもって取り上げられていますしね。実際、欲しい。ような気がします。

いや、最初、「星座をさがそ」を見つけたとき、でも冷静に考えると、ケータイアプリだとなんか1回見てふーんで終わっちゃいそうだなって気もしたんですよね。なんででしょう。なんとなく、専用端末として作ってかんたんな天体望遠鏡にでもくっつけて、それなりの値段でクリスマス商戦のおもちゃ屋に並べたほうが売れそう、っていうか受け入れられそうな気がする。

よーし見るぞー!っていう意気込みというか興奮みたいなのとともに、わざわざそれだけのためのものを手に入れたい、なんて、そういうかんじがほしいというか。

使用価値としてはほとんど同じなんだけれども、このへんが、ほら、ドナルド・A・ノーマンのいう内省的デザインっていうのに関わるところなんじゃないんでしょうか?ちがうかな。それで、ここのところは、デザインとマーケティングが一番接近するところでもあるんじゃないかな、とも思うんですよね。


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

2008年11月19日水曜日

ペルソナ作ってどうするの?

前から読もう読もうと思っていた「ペルソナ作って、それからどうするの?」、ようやく読みました。読もう読もうと思ってたのは、正直、「ペルソナ(なんて)作ってどうするの?」という疑問があったからです。

この本に書かれているデザインプロセス(の前半部分)をかいつまむとこうなります。

まず、ふつうに市場調査のプロセスがあります。定量的な調査と分析にもとづいて、何種類かのセグメントに分けてターゲットユーザーを設定します。

つづいて、セグメントごとに何人かのユーザー代表をリクルートして、コンテキスチュアル・インクワイアリーと呼ばれるインタビューを試みます。弟子入りして師匠=インタビュイーから、これからデザインするモノに関連しそうなさまざまな活動について学ぶわけですね。まとめたり抽象化したりして理解に努めるのではなく、インタビュアーは師匠のもとであくまでも体験学習をしてくるのです。

そうして師匠から学んだことを、今度は、ワークフローとしてモデリングしてみます。モデリングの観点は次の5種類。関係者とのコミュニケーション、個人的に行われる作業のプロセス、リファレンス類の用い方、物理的な作業環境のあり方、そして、社会的、対人的な背景です。

ユーザー代表ごとのワークフローモデルが描けたら、これを分類したり、まとめたりして、典型として把握できる何種類かのパターンに落とし込みます。そしてこれらのリデザインに取り組みます。つまり、これからデザインするモノを投入することで、ユーザーたちのワークフローを現状よりもよいものにできるかどうかに挑むわけです。モノのデザインとはつまり、モノをつかって行われるコトのデザインなのだ、というわけですね。このことは、この本の全編を通じて強調されていることでもあります。

と、ここまで読んで、これだけで充分すばらしいじゃん、この上、ペルソナなんて作る意味あるのかな、と思いました。本文中にも「ユーザーグループ別に行動やニーズの分類を自分たちの手を使って、時間をかけて作業を進めてきたプロジェクトチームにとっては、もはやユーザーの行動や経験は自分たちによく馴染んだものになっているはずです。そこまでたどり着いたメンバーにとっては、改めてペルソナを作らなくても具体的なデザインを進めることは可能です。」なんて書いてあるしね。

それと、ここまでの話は、たとえば、ワークフローの As Is と To Be をはっきりと描き出し、そのギャップを、開発における設計がそうであるように、論理的、合理的なプロセスを通じて分析していくことで、正しい要求を「開発」していこうとする、いわゆる要求開発の話に似ているな、とも思ったんです。

で、それが似ているって思ったところで、またちょっと転回がありまして。いや、既存の、ある程度出来上がっていて、それなりに有用なワークフローのリデザインだとしちゃうから、ペルソナなんていらないと思っちゃうんで、そもそも、何かの改善というんでは間尺があわないような新しいモノ、コトの話ならどうなんだろう、と。

一生懸命苦労して把握したワークフローが、直接のリデザインの対象にはならない場合。これからデザインしようとしているモノ、コトが、ワークフローのある部分を置き換えるというよりも、そうしたワークフローに隣接して存在できるかどうかが問われる場合。

たとえば、ウォークマンがない世界でウォークマン的なものをデザインするときに、コンテキスチュアル・インクワイアリーとワークフローモデリングで明らかにできることって、リデザインの対象ではないでしょう。

そういう場合、デザインする側はいってみれば丸腰なわけです。To Be に向かう論理的で合理的なプロセスなんて望めやしません。そこでなら、典型化されたワークフローモデルを、さらに人格化してチーム全体でつねに名指せるようにしておくことは役にたちそうです。あいつがこれを使おうと思ってくれるか、使ってくれるとしたらそれはどういう文脈でのことなのか、その文脈で使う場合、使いにくいところは出てこないかってね。デザインプロセスは全部試行錯誤でも、しかし、むやみやたらなものにはしなくて済むのかも知れません。

うーん、なるほどなー、なんて、いまのところ、ペルソナについては、そんなかんじの理解です。ただこの本、タイトルは一種の釣りで、もっといろんなことが書いてあります。いまはざっと一読してみただけですけど、しばらく手元においてつきあってみたいなと思ってます。


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

2008年11月13日木曜日

甘酸っぱいウェルカムメッセージ

駅のホームにHONDAのLIFEのポスターがずらっと並んでました。キャッチコピーは、SMILE! LIFE! Honda New ライフ debut! ってなってて、笑顔の女の子のバストショットのが1枚と車の正面写真のが1枚、これが1組になって、それが3組、合計6枚。

女の子の3枚はそれぞれシーンが違うんだけど、どれも、なんていうか、単純にSMILE! LIFE! ってかんじじゃないんですよね。線路を挟んで向きあってたぐるなびの忘年会の広告みたいに、そんなに元気いっぱいって印象をこっちにぶつけてくるようなのじゃなくて。

むしろ個人的にはちょっとせつないようなかんじ。いや、なんかいい年して急に甘っちょろいことを言い出しちゃってみっともないんですけれども。

一枚はちょっと季節はずれの砂浜で、女の子は向こう向きに座ってて、フレームには入っていないけど、たぶん隣に一緒に座っているだろう人に笑いかけているところ。それを、微妙な距離感でななめ後方から見下ろすようなアングル。

他の二枚も同様、視線が合わないどころか、はすに見下ろすか見上げるかで、なんとなく他の誰かと楽しそうに座ってる/立っている彼女を、こっちは逆に立って/座ってるかしてチラ見してるようなかんじなんですよ。これは、あれでしょ、片思いの思い出アングルでしょ、なんて思いついちゃいました。たんにぼくがかわいそうな人なだけかも知れないですけど。

いやいや、きっとそうだよ、そうやってこっちを焦がれるような不安定な気持ちにさせといて、そこを見計らって商品を刷り込んじゃう。焦がれる気持ちを商品の上に転移させて、はぐらかされるような女の子の写真とは対照的な正面を向いて愛嬌たっぷりの車の写真、ここでしっかり受け止めちゃう。いや、もう、あられもなく受け止められちゃいますよ。

って、LIFEって女性ターゲットの車でしたね。それじゃ、そんな片思い癖のついた男の心をよろけさせても仕方ないですね。でも、ぐるっとまわって、そんなふうにチラ見されるほど輝いているわたしのSMILE! LIFE!ってことなのかもしれませんね。もう勝手にしろってかんじですね。しかし、広告ってのは、それくらいたくらんで作られるものでしょう。

Webサイトでも、ウェルカムメッセージとして、トップページに派手なビジュアルを乗っけることが多いですけど、案外まだ、そういう人の心の機微を狙ってくるようなのって見かけないですよね。車の広告でいえば、よくて、いい車がいい景色の中を走ってんなーレベルのとか。○○、誕生。とかいって。見栄えのクオリティ即訴求みたいな。

予算の関係もありますけど、しっかりたくらんでSMILE! LIFE! みたいなのもやってみたいですよね。甘酸っぱいやつとか。そういえば、あんまり甘酸っぱくないですよね、Webって。しょっぱいのはいっぱいありますけど。

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

2008年11月11日火曜日

俺のクラウド

このあいだまで、W-ZERO3の通称エスを使ってたんですが、ある人から通称アドエスを譲り受けまして乗り換えることにしました。SIMを差し替えただけで、契約はそのまんま。かんたんです。

ただ電話帳を移すのがちょっと面倒でした。もちろん端末同士で直接なんてわけにはいかないし、エスとアドエスでは外部メモリがminiSDとmicroSDとで違うし、ちょっと調べて、結局、PIM Backup というソフトを使ってPC経由で移しました。

PIM Backup
http://www.freewareppc.com/database/pimbackup.shtml

手順としては、両方の端末にこのソフトをインストールして、エスでバックアップファイルを作成し、これを Windows Mobile の Auto Sync で PC に移し、つづいて PC からアドエスに移し、そしてアドエスでレストア、といったかんじ。

じつに、面倒ですね。面倒ですけど、でも、あらためて思い知らされたのが個人用の汎用計算機としてのPCの有り難さですね。これなかったら、やっぱり、サービスデスクみたいなとこに行くしかなかったのかも。

関係ないですけど、iPod だってPC がなかったらどうにもなんないわけですしね。

それでちょっと思ったんですけど、最近、マシンの仮想化技術や分散化技術の進歩を背景にクラウドコンピューティングなんて言葉をよく耳にしますけど、個人用の仮想マシンをオンラインに持つっていうようなのはありえないんですかね。

今のPCそのまんま、というのではなくて。それだと、いわゆるシンクライアントみたいになっちゃって、なんか歴史は繰り返すみたいな話になっちゃう。

暴論かもしれませんが、仕事以外のPCの用途って、インターネット端末と汎用のデータエクスチェンジャーってところなんじゃないかな、なんて。

で、インターネット端末としての役割は、たいていケータイで十分みたいになってくると、残るのは、データの取り込み、変換、書き出し。

CD をリッピングして、iPod に入れるとかね。

うまくイメージできていないまま、あてずっぽうで書いてるんですけど、じゃあ、たとえば、ネットワークインターフェースと外付けデバイス用のコネクタだけがローカルにあって、計算機とストレージはオンラインにあるとかってことになったらどうなんでしょう。

どこからどんなデータを取り込んで、どう変換して、どこに書き出すのかという処理をYahoo Pipes みたいなインターフェースでモジュールの連結として設定したりして、それが、まあ、このコンピュータのオペレーションシステムになるわけですけど、そのへんは全部ケータイ向けのWebページでやるとか。

つまり、ブロードバンドひいてその先をPCで受けるんじゃなくて、その先っちょにはいろんな専用端末をつなげられるコネクタの口があいてるだけ。それで専用端末間のデータエクスチェンジと、あと、データストレージはオンラインサービスで、ていう世界。

これのなにがいいのかというと... なにがいいんでしょうね。エコ?

いや、ひまにまかせてちょっとあてもなく妄想してしまいました。それでこのエントリーのタイトルが俺のクラウドっていう。雲をつかむような話ってことで。えへへへ... すみません。

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

2008年11月7日金曜日

Webディレクターは正気を失う

トップページに並べられる複数の項目には重要度に応じたランクがあって、ランク上位のものから上から下へ順に、上のものは大きく、下にいくにつれて小さく、つまり、ニュースサイトのレイアウトのしかたがその典型であるようなレイアウトパターン。まずワイヤーフレームの段階ではそうした情報構造が指向されていたはず。

それを表層段階のビジュアルデザインに変換する際の試行錯誤で、なかなかレイアウトに格好がつかず、ニュースサイトでいえばトップ記事にあたる情報を、ウェルカムメッセージエリアのようなデザインで処理してしまったのが失敗。

そうしちゃうと、そこは、後続するリストからのピックアップ、特出し、フィーチャーのようにみえてしまって、だから、それが後続するリストに存在していないことのほうがむしろ不思議、そんなふうにユーザーを混乱させてしまいました。

そこでつまづくとWebアプリ全体が機能しないような入り口のメニューの話なんで、ユーザーからのクレームも多数寄せられまして、しかも、それでようやくそうした誤りを犯してしまったことに気がづく始末。

もう、いわれてみれば、どうしようもない手落ちなんですよね。それをデザイナーもディレクターも制作作業のさなかではまったく気づけなかった。

その、レイアウトがなかなか決まらない、ってところで頭がおかしくなっちゃってるんですよね。たぶん。で、本質をないがしろにして、表面的な結構のみを追求してしまい、そこが解決したところでもう力尽きてしまっている。

やっぱり、現場ではどんなに当たり前のように見えることでも、ユーザーテストは絶対必要だと思い知るわけですけど、しかし、大前提として、作業中は正気を失っている可能性があることの自覚を常に持つようにしないといけませんね。

特に、それなりに大きな問題を解決したと思ったとき、紆余曲折あってやっとここまできたなんて思ったときあたりが危ないみたいです。

ただ、一方では、ワイヤーフレームを雰囲気だけで書いてしまって、トップページに配置される項目のそれぞれについて、情報構造上の役割を明確に捉えていなかったことにも、デザインをあさっての方向に向けてしまった原因の一端があったと思います。

デザインを間違わないようにするためには、

1、ワイヤーフレームがそう書かれたことの理由にあいまいなところがないか

このチェックを徹底した上で、

2、ワイヤーフレームで意図したことが実現できているかユーザーテスト

これをちゃんとやる。

それから、ユーザーのタイプやコンテクストの洗い出しをちゃんとやっておくこと。そうしないと、そもそもワイヤーフレームは書けないはずだし、ユーザーテストもできない。

そのへんをさぼっている限り、一度失った正気は取り戻せない。

実は今回の失敗の根本的な原因はこれなんですよね。結果的に、あるタイプのユーザーの存在を無視してデザインが暴走してしまったといっていいくらい。

なんて、今、反省しているところです。

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

2008年11月5日水曜日

プライベートスポーツニュース

先月、小学生の子供の運動会に行ったんですけど、校庭と校舎の位置関係の都合で仕方ないんですが、赤組白組の得点表示が場所によっては非常に見にくくって。特設のケータイサイトでも作って、そこで、今の得点とか、次の種目とか教えてくれればいいのに、なんて思いました。

あるいは、いっそのこと、ライブで更新される運動会専用のニュースサイトみたいなのをやってみたら面白いんじゃないか、とか。

あの、校長とか来賓が座っているテントの中にプレスルームみたいなのを設けるんです。そこにPCを持ち込んで担当の先生と係りの児童で運動会の進行にあわせてどんどんニュースをアップしていく。[5年生80M走]赤組、1位に大量16人、総合点でも白組を追い上げ。とかって。できれば、個人成績も細かくフォローしたいですね。もちろん、運動会に特化したCMSが前提で。

そうすると、プログラムを紙で配らなくてもいいし、途中から来た人でもすぐにノって応援できそうだし、仕事の都合とかで来られないお父さんお母さんでも、リアルタイムに様子を確認できて、あとで子供に、ニュースみてたよ、なんて言えたりして。

最近の小学生は国語の教育目標としてメディアリテラシーを身につけるとかなんとかあるらしいですから、教育の一環としてそういうのもアリなんじゃないでしょうか。

運動会だけじゃなくて、こう、会場が広くって、参加者の情報共有がいっぺんにいかないもの、たとえば、ゴルフのコンペとかでも、そういうニーズありそうじゃないですか。

なんていって、ほかに適用できそうな例を、今はぱっと思いつかないんですけど。


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

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

2008年9月26日金曜日

ロゴの解剖

Web サイトのサイト ID なんていって、ロゴデザインを何案もつくったりしますね。やってるうちに何がいいんだかだんだんわからなくなってきたりして。そういうとき、なかば切れ気味にいったいロゴってなんなんだって改めて問いただしてみたくなります。

ロゴはサイトの隅に書きつける一種の署名みたいなもんで、機能的にみても、たとえば手書きのサインなんかと似ているところがあるね、なんて考えてみたことがあります。

それは、とりあえずこの世で唯一無二のものとしてあって、他とあきらかに区別できなくちゃいけない。そして、何度でも同じように書けて、そのどれもが書いた当人ただ一人を指し示すものでなくちゃならない。さらに、なんとなくではあるけど、書いた人の人柄なり雰囲気なりを表現していたりもする。

固有性と再現性と表象性ってかんじでしょうか。ロゴもそれらを備えて成立していると考えてよさそうですよね。

でも当然まったく同じというわけではなくて。まず再現性はね、ロゴの場合は技術的に当然のものとしてあるんで、あえて特性としてあげるまでもないですね。それは置いといて、ロゴとサインではその主な用途、というか目的が異なりますね。いってみれば、サインは証明、ロゴは認知。だから、サインでは可読性は二の次だったりしますけど、ロゴではそれがけっこう一大事ですよね。

それから、ロゴには再認性っていうのも問われます。サインとちがって、はじめてみた人になるべく強い印象を与えたいし、再び見た人には、ああアレね、とすぐに再認してもらいたい。つまり人々の記憶に残りたい、という。

一部の有名人のサインには、再認性のかたまりみたいなのがあったりしますけどね。ぼくが子供の頃の王選手のサインとか。あれは今でも目に浮かびますよ。

それはともかく。

ロゴの固有性と表象性の追求は、そのまま、再認性の追求の手段になったりしますね。

固有性と表象性そのものの追求だけならば、サインのように地味な見栄えでも構わないはずなんだけど、強い再認性の獲得にむけて、それらがエスカレートしていきますね。

たとえば、固有性や表象性を高めるために、こんなことをするはずです。

まず、ふつうに流通しているのじゃなくて、オリジナルのタイポグラフィーや飾り文字を使おうとするでしょ。

それでも弱いってなって、次に模様やイラストをあしらいはじめる。あしらい方のやり口は大別して次の3種類じゃないですか。文字とは独立した要素として入れる、文字の飾りのバリエーションとして入れる、文字の背景として入れる。あるいは、それらを組み合わせる。

そうしていろいろ凝っているうちに可読性が損なわれちゃったりするんですよね。これが。なんていうか、表音性を失う、みたいなかんじ。一見して頭の中にその名前の音がしてこない。じゃあ、そのぶん、表意性が増しているかというとそうでもなかったり。へんな渦まきがあって、意味なんて説明されないとわからないようなこじつけしかなくて。

そんなふうに、ロゴの再認性と可読性はトレードオフの関係にあって、ロゴのデザインの失敗は再認性が弱いか、可読性が悪いかのどっちかだったりしますね。

この再認性と可読性のバランスをどうとるか、あるいは、固有性と表象性にしてもどっちをより優先して考えるか、そのへんは、ロゴばっかり睨んでいても決められなくて、ロゴの使い道や、すでに獲得している認知の度合い、競合の存在の仕方とか、そういうコンテクストもちゃんと踏まえて考える必要がありますね。

たとえば、コンビニの看板というかネオンサイン?あれも一種のロゴと考えると、あれは遠目にもそれとわかる配色パターンによる再認性こそが第一で、店名の可読性なんてもうどうでもいいんじゃないかと思ったりしますけどね。でも、WebサイトのサイトIDじゃそうはいかない。

なんて、あたりまえのことをわざと理屈っぽくいってるだけのようですけど、こういうわかりきったことでもあえて愚直に分析してみて、析出された各要素にラベルをつけてですね、いつでもそれと名指せるようにしておくことは、ロゴデザインに限らず、この仕事では結構大事だと思うんですよね。少なくとも熱くなって失敗しそうなときにブレーキをかけたり、頭を冷やしたりするのに役立ちます。おいおい、再認性のことばっかり考え過ぎじゃないか、とかね。

それから、そうして機能分解をやってみると、これらの機能をなにもロゴという局所に押し込むこともないんじゃないかなんてことに思いが至ったりしますね。

Webサイトの場合、検索結果だとかのリスティングの中で固有性、表象性、再認性を発揮しなければいけないわけでしょ。そうするとロゴという意匠よりも、サイト名のネーミングやURLで勝負しなければいけないのかも。商標登録でいうと、「標準文字」による登録ですね。それに、アンカー文字列をクリックして訪れたサイト上の各ページでは、サイト名の伝達の優先順位なんてもうそんなに高くないわけです。すると、固有性、表象性、再認性は、サイトのトーン&マナー全体で実現すべきではないか、とかね。

あ、そう考えると、むしろコンビニのネオンサインに近くなっちゃうのかも。
-----------------
sent from W-ZERO3

2008年9月24日水曜日

対面で交換する電子的なプライバシー情報

ケータイの赤外線通信で電話番号やメアド、最近ではプロフの URL とかを教え合ったりしますね。って、実は、ぼくの端末には赤外線通信の機能がついてないんで、やったことないんですけど。

だから、以下の話もまずは自分でやってみてから言えってかんじかもしれませんが、まあ、そこは話半分ということでお願いします。

電話番号やメアドはともかく、プロフを教えるとか、交換するってのはおもしろいと思うんですよね。次世代の名刺というか、名刺よりも当然奥行きのある表現が可能ですし、それを集めれば、これも当然、自動分類や検索だってできますしね。まあ、そもそも、そういう位置づけを狙って考えられたサービスなんでしょうね。

でも、プロフは公開しても、名刺を公開して、電話番号やメアドをネットにさらす気にはなれませんよね。名刺は、対面で相手がそれなりに信頼できる・すべき人物であることを確認して渡すもので。

じゃあ、対面で名刺を交換するような人たちにだけ見せられるようなプロフは作れないでしょうか。そうするとどうしたって認証が必要になっちゃうんですけど、認証つきの名刺を渡すなんて、そんなまどろっこしいもの誰も欲しがらないですよね。だいいち、なんか失礼だし。

で、ちょっと考えてみたんですけど、いや、これ、今現在の話としては実現可能性ゼロの与太話に過ぎませんが、対面の赤外線通信で、プロフの URL とともに、双方の端末 ID を交換するってのはどうでしょうね。

やりとりには、ケータイアプリを介在させるとかして、相手の端末 ID をサーバに登録する。すると、今交換した相手の端末から自分のプロフにアクセスできるようになるとか。

プロフは、一般に公開する部分とプライバシー部分に分かれていて、プライバシー部分は端末 ID による認証が必要で。それから、プライバシー部分も、仕事用とか、友達用とかに分かれていてね、そのへんは対面で端末 ID をもらうときに、どの部分のアクセスを許可するのか設定できるようにして。

.. なんていうの、どうでしょうね。信頼しあう者同士が対面で端末 ID を交換することによって築かれるケータイネットワークなんて。
-----------------
sent from W-ZERO3

2008年9月23日火曜日

サイトメッセージチャート

サイトストラクチャを書いて、OK なら次にワイヤフレームを書くっていうのは、プロセスとして少し乱暴ですよね。各画面のワイヤフレームに盛り込むべき、メッセージ、ナビゲーション、コンテンツにはどんなものがあって、どう配置される(要素間の関係を持つ)べきなのか、その根拠を全部サイトストラクチャに求めるのは無理なんで。

このサイトにはどんなコンテンツや機能があるのか、とか、それらをどうグルーピングしてどんなふうにサイトの全体像を結んでいくのかっていうのは、たいていサイトストラクチャで明らかになります。各画面にそれなりの名前をつけて、セクションの系列をツリー構造にまとめてね。場合によっては、画面ごとの矩形のわきに、各画面の主要な構成要素を書き込んだりして。

でも、それだけだと、いわゆるユーザ導線っていうのが見えてこないわけです。すべての画面は他の画面で行われたユーザの選択の結果として表示されるもんだととらえて、各画面がサイトの目的とユーザのニーズをマッチングさせるためのパスとして有効に機能するためにはどうすればいいのか、なんていう視点での設計やデザイン、これは、サイトストラクチャの記法では描き切れない。

この問題は、でも、ぼくの記憶では、2001年とか2002年あたりから、ユーザエクスペリエンスなんて言葉とともに、いろんなとこで言われるようになった、いまやもう、相当古い話ですね。サイトストラクチャだけじゃなくて、ユーザ導線図も書こうなんていって。

でも、ユーザ導線図なんていって、サイトストラクチャの画面と画面を結ぶ線が増えただけみたいな図を書いても、正直なんだかなーというかんじでした。書くのが面倒な割に、得られるものが少ないっていうか。

ぼくは、ユーザ導線図というのをまともに書いたことがたぶんないです。そのかわり、導線として問題になりそうなところや、特に手をかけなくちゃいけないところだけを抜き出して、局所的なポイント解説つきの画面遷移図をサイトストラクチャに添えたりしてました。

それでこれまで特に問題はなかったと思うんですが、ただ、後輩の Web ディレクターを指導してとかってときにですね、やっぱりユーザ導線設計のあたりにも、思考や作業を誘導するような作図法やツールが確立されているべきだよね、なんて思うようになりました。

それで、どうしたもんかな、と、ここんとこ考えてみてるんですけど、たとえばこれがユーザ導線って思い定めながら画面をあらわす矩形と矩形の間に線をひっぱっているときに、頭の中でいったい何を確かめているのかというと、ある画面においてユーザに何をメッセージして、そこから次にとりうるアクションのオプションとして何を提示して、で、ユーザのとったアクションの結果として何を見せるかって、その連鎖のおぼろげなイメージなんだと思うんですよね。じゃあ、そのイメージを、おぼろげな状態のままでいいから、そのまま図に定着させちゃえばいいんじゃないか。

たとえば、まず、サイトとしてユーザに伝えようとしているメッセージを各画面ごとに書き出してみる。それこそ、ようこそ、からはじまって、新着がありますよ、おすすめはこれですよ、今、こんなキャンペーンをやってますよ、とかね。コンテンツや機能のリストではなく、あくまでもサイトからユーザに向けてのメッセージという視線で。粒度もこれくらいがいいと思います。あんまりくだくだしく書かず、画面がいっぱいあって俯瞰でみてもそれぞれを一発で確認できるように。

次に、各画面でユーザとりうる選択肢を書き出します。これは、ユースケースのように、「〜する」という形式で。それから、それぞれの選択に対応する遷移先の画面へ線を引きます。

線の上には、必要に応じて、線の引き出し元となる選択肢のラベル「〜する」に対応するユーザのマインドを想定して書いてみる。たとえば、「詳細情報を読む」に対して「これってどういうこと?」とか。

こうすれば、画面Aのメッセージ - 画面Aの選択肢 - 線ABのユーザマインド - 画面Bのメッセージ ... といった連なりを確認することができるようになると思います。全体としておおきなアミダくじみたいになるでしょうね。たんにサイトストラクチャの画面間の線を増やしただけのようなユーザ導線図では、結局、どことどこがつながるのかくらいしかわかりませんが、これなら、ユーザをどう導いてどんな体験をさせるのかまで描けるでしょう。

そうすると、サイトストラクチャとワイヤフレームの間に入って、ワイヤフレームを作成する上での検討材料としてもかなり役に立つものになるんじゃないでしょうか。サイトメッセージチャートとかいってね。

ちょっとためしに書いてみて、いいサンプルができたらアップしようと思います。
-----------------
sent from W-ZERO3

2008年9月19日金曜日

ネットのニッチ

昔からよく言われることで、メディアは成熟していくにつれ専門化していくってのがありますね。たとえば、雑誌なんてすごくて、専門外のふつうの人には思いもよらないようなタイトルの専門誌がいっぱいある。たとえば山とトンネルとかってね。数千部はければペイするような規模で、失礼ですけど名前聞いただけで思わず笑っちゃうようなのが。

それで、インターネットなら、そういう傾向はさらにエスカレートするだろう、っていうか、そうできるだろうって。だって、雑誌の制作コストなんて半分は印刷と流通にかかってるんだから、そこがとっぱらいになるネットなら、雑誌よりもさらに小さなマーケットをねらえるだろうって。

つまり、もともとユーザのニーズは無数の個としてあるんだけど、それを満たそうとするサプライヤーのほうがそういう各個を撃破する体力を持てないもんだから、いわば暫定的に、不承不承、サプライヤーの力に見合ったニーズの集約が行われていただけなんだ、なんてね。どんな要因にせよ、サプライヤーの活動能力が上がれば、上がったぶんだけ、そのもともとっていう無数のユーザニーズに対するカバレッジも上がっていくっていうのがトレンドだという。

検索エンジンの出始めでも、SNS の出始めでも、たいがい誰かが、これからは専門化、細分化に向かうとか言い出しますよね。

でも、そういう細分化に応じて、専門サイトが増えるかっていうと、そうはいかないですよね。

ロングテールとかって、長いテールを総ざらいにできるから意味のあるボリュームを出せるって話ですよね。だから、ロングテールねらいでいけるのって、たとえば Amazon とか、そういう、いわばメガサイトだけでしょう。メガな集客があって、はじめてテールがロングになるわけで。おいしいのはしっぽが長いことを認識できる立場で、しっぽそのものを構成するメンバーではないんですよね。

たしかに、全体として千差万別の細分化されたユーザニーズに向かっていくようにみえるんだけど、それに向かっていってるのは、向かっていけるだけの力がありあまってる、つまり俯瞰でしっぽの長さを認識できるメガサイトだけではないのかっていう。

だから、検索エンジンにしても、SNS にしても、メガなところが、ロングテールの長さをどんどんに伸ばすことによって、ますますメガになっていくのがトレンド、っていったほうが当たってんじゃないでしょうか。専門検索エンジンとか、専門 SNS なんて、結局出てこないですもんね。

そのへんをわきまえてみると、雑誌のように、一応それ自体で採算がとれることをねらうニッチなメディアをネットで実現できるかって、実はネットでのほうが、ますます難しいんじゃないかと思いますね。

だって、まず、そういう規模では、雑誌制作における資本投下と労働集約よりも、インターネットのコモンでソーシャルな情報共有のほうが質としても勝っちゃう可能性が高くなるでしょう。

それから、情報発信のためのコストが下がるってことは、情報発信源の稀少性が落ちるってことでもあって、インターネットによって現れたテールの上では、そもそも、その存在すら見つけてもらえない可能性があります。

そんなわけで、信じられないようなニッチな雑誌がいっぱいあったってことに勇気をえて、さらにインターネットなんだからもっとニッチにっていう考えは、少なくとも雑誌のようなビジネスモデルとしてはありえないような気がします。そこらへんは、コモンとソーシャルに真っ先にとってかわられる部分じゃなんじゃないのかなって思います。


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

文房具としてのWSH(追補)

きのうの WSH についてのエントリーですが、会社からの帰りがてらにw-zero3のメーラで書いていたこともあって、実際どんなふうに書いたのかをぜんぜん示すことができませんでした。

あとでコメントで補足しますなんて断りを入れましたが、コメントじゃちょっと書ききれないので、エントリーとしてアップします。

なんでこんなことしてるのかという経緯についてはきのうのエントリーを見てください。

さて、いろんな書き方があるんですが、ぼくは XML 形式で書きました。

<?XML version="1.0" standalone="yes" encoding="shift-jis"?>
<package>
<job>
<script language="JScript">//<![CDATA[

// ここに書く

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

この方法で書くと、いろいろいいことがあるみたいですよ。今回はちっとも関係ないんですけどね。このあたりについては、下記を参照してください。

Windows スクリプト ファイル (.wsf) を使用する / msdn

これにファイル操作をやるためのコードを書いて、*.wsf として保存します。クリックすると実行されます。

ファイル操作を行うためには、まず、Scripting.FileSystemObject のインタンスをつくり、カレントフォルダを参照するオブジェクトを取得します。こうです。

var fso    = new ActiveXObject( "Scripting.FileSystemObject" );
var folder = fso.getFolder( "." );

このあと、folder.files ってやると、カレントフォルダにある複数ファイルのコレクションにアクセスできます。しかし、このコレクションっていうのが、たんなる配列じゃなくて、folder.files[0] なんてしてもファイルにアクセスできない。

そこで、Enumerator というイテレータオブジェクト経由で扱います。

var i = new Enumerator( folder.files );

こうすると、

for ( ; !i.atEnd(); i.moveNext() ) {

WScript.Echo( "ファイル名は" + i.item().name + "です。" );
WScript.Echo( "フルパスは" + i.item().path + "です。" );

}

なんてかんじでファイルの属性や内容にアクセスできるようになります。

ただですね、読み込みたいファイルの文字コードが utf-8 の場合は、さらにADODB.Stream っていうのを使わなくちゃいけないんですね。

var input     = new ActiveXObject('ADODB.Stream');
input.type = 2; // ascii モード
input.charset = 'utf-8'; // 文字コード指定
input.open();
input.loadFromFile( filepath ); // ファイルの内容を読み込んで ...
var alllines = inputs.readText( -1 ); // 取り出します。
// 引数に -1 を渡すと、
// 全行を一括して取り出せます。
inputs.close();

という具合。これで alllines に、ファイルの内容がごっそり入りました。

実は、Scripting.FileSystemObject にも OpenTextFile というメソッドがあって、流れからいっても、そっちを使ってファイルの内容を読み込むのが素直ってもんなんですが、これだと、sjis と utf-16 しか扱えないらしいんですね。ADODB.Stream を使えば、いろいろな文字コードを指定することができます。

さて、読み込んだ内容を処理しやすいように一行ごとに分割して配列に入れます。

var lines = alllines.split("\n");

そして、各行に for ループで 1 行ずつあたって、必要なテキスト操作を行います。

var newlines = "";
for ( var i = 0; i < lines.length; i++ ) {

lines[j] = lines[j].replace(/foo/,"bar");
newlines = newlines + lines[j] + "\n";

}

なんてかんじですね。

終わったら、出力します。出力も utf-8 にしたいので、ADODB.Stream を使います。

var output       = new ActiveXObject('ADODB.Stream');
output.type = 2;
output.charset = 'utf-8';
output.open();
output.writeText( newlines ); // テキスト操作後のデータを書き込んで ...
outputs.saveToFile( outfilepath, 2 ); // 出力ファイルに保存します。
outputs.close();

以上です。

ね、やりたいことにくらべてなんて大げさなってかんじではないですか。

それで、きのうの話になるわけです。失礼しました。


2008年9月18日木曜日

文房具としてのWSH

制作の現場では、ちょっとした Perl スクリプトを書いて、ローカルのテキストファイルをいじったりすることが結構少なくありません。たとえば、CSV データのレイアウトを変更したり、複数の HTML ファイルに共通して存在する文字列を別の文字列に置き換えたり。

そういうのを、文房具としての Perl なんて呼んで、プログラマーじゃなくても、それくらいのことはテキストエディタの延長みたいなつもりでいつでも使えるようにしとこうぜ、なんて言い張っていたりします。

そしてときに、そういうスクリプトをクライアントに提供したいことがあります。でも、Perl とかだと、実行環境をクライアントのローカルに作ってもらわないといけない。Active Perl をインストールしてください、なんて。PAR でしたっけ、Perl スクリプトを実行形式のファイルに変換する方法もありますけど、それなら、いっそってことで、そういうケースでは、Windows Scripting Host で動く Javascript (この文脈では JScript っていうべきなんでしょうか)で書いたりしています。

Javascript は書き慣れてますんで、これはこれで結構、制御構文や文字列の操作なんかを書くのに、いいかんじなんです。でも、ローカルのファイルの取り扱いとかでは、なんていうか面倒なオブジェクトを使わなくちゃいけなくて。オブジェクト名はキャメルケースで長ったらしかったり、4文字くらいの謎の頭文字の連なりだったりしてにわかには覚えられないし、プロパティやメソッドもいろいろごちゃっとあってですね、とにかくたまにしか書かないと、あれ、どうすんだっけなんて、本来書きたいロジックに向かうまでに、毎度毎度同じことをググったりして、正直イライラします。いや、自分がバカなだけなんですけどね。

あの、実際どんなかんじで書くのかは、明日会社いってから、ちゃんと確かなところを確認してコメントで書きます。すみません。

それはそうと、ただ、もう、カレントディレクトリにあるテキストファイルに対してなんかするって目的に特化しちゃえばですよ、そのへんをもっと直感的にっていうか、window.document からはじめて DOM エレメントをいじってる人がもうちょっと類推しやすいような書き方ができてもいいかな、なんて思います。

たとえば、window みたいに folder ってオブジェクトがあってカレントディレクトリにアクセスできるとか、folder.files が、カレントディレクトリのファイルのコレクションになってるとかね。それで、folder.files[0].text() で、対象ファイルの内容にアクセスできて、folder.files[0].text( str ) でファイルに str の値を書き込めるとか。

そのへんの手続きに思い切ってそういうシュガーをまぶしちゃえば、あとはふつうに書き慣れた Javascript を書くだけってかんじ。それこそ、innerHTML をいじるような感覚で、ローカルファイルを操作できるんじゃないかな、と。

って、そういう一種のラッパーは、簡単に書けそうですね。今度ひまをみつけてちょっとやってみましょう。

あと、ひょっとして Jemplate も WSH で動いたら、CSV の内容をあるテンプレートの HTML に変換するなんてのも簡単にできるようになるかも。どうだろ。これもやってみましょう。

CSV はね、名前をわすれちゃったけど、あるオブジェクトを使って、"select 列名 from ファイル名" なんて SQL みたいなのを書いてレコードを抽出できるんですよ。


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

2008年9月17日水曜日

数字とグラフで見る自分

ブログなんて書いてみると、全然たいしたことないのはわかりきっているのに、やっぱり、アクセス状況とか、フィードの購読数だとか、検索結果の順位とか、被ブクマ数とか、気になってマメにチェックしちゃったりしますね。もう、恥ずかしいくらいお猿なかんじで。コミュニティ志向だったり、CGM的な企画では、やっぱりこういうフィードバック機能は疎かにできないな、っていうか、極端な話、そこからユースケース書き始めてもいいくらい大事だよって、あらためて思い知りました。

ブログサービスには、そういうの、はじめから全部こみこみで備えていてほしいですね。ブログパーツ経由で足あとを残すみたいな、ドメイン横断のオープンなSNSっていう、顔のみえるフィードバックって方向もあるでしょうけど、まずは、顔より、数字とかグラフによる見える化ってのをもっと追求してみてもいいんじゃないかな、なんて思います。

それから、そういう自分の活動に対する反応だけじゃなくて、自分の活動自体の見える化というのもありますよね。エントリー数や投稿日時に関する集計はもちろん、何文字何センテンス書いて、よく使われる単語は何で、1センテンスあたりの平均文字数はいくつで、漢字、カナ、英字はそれぞれ何割で、なんて文体研究みたいな統計もやってくれたりしたら面白いんじゃないでしょうか。頻出語のタグクラウドを作ってくれたり。自分でも思ってもみなかった癖がみつかったりして。曜日ごとに頻出語を見てみたら、なんだか意味ありげな偏りがあったりしてね。

あと、そういうのに近いところで、Google Calendar なんかでも、書き込んだ予定や記録を、いろんな角度で数字やグラフにまとめて見せてくれないかなあ、なんて思いますね。月別の出先での打ち合わせ時間の比較とか、予定の種別ごとの月あたりの登録数の遷移だとか。それから、体重とか体温とか、まあ、なんでもいいんですけど、ラベルを決めて数値をカレンダーに入力できるようにして、累積や遷移をグラフで表示できたり。最近してないなー、とか、ちょっとやりすぎだよなーとかね、一目瞭然。

とにかくあれですね、小中学生の体力測定の結果とか、受験生の模擬試験の結果とか、中年になってからの健康診断の結果とか、自分に関する数字やグラフを見るのってそれくらいですよね。でも、もっと、いろんなことで、もうほんと日々ってかんじで見られたら、ちょっと楽しかったり便利だったりしそうですけど、どうでしょう。いや、ひょっとしたら、いやな気持ちになるだけかもしれないですけどね。


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

2008年9月12日金曜日

テキストノード比

ある仕事でいくつかのニュースサイトの許可を得て、記事ページを収集するというのをやってるんですけど、記事ページだけ機械的により分けるのが結構難しいんです。

今は収集先の記事インデックスページのマークアップをしらべて、ここからここまでに含まれるリンクが記事ページのURL、なんてやってるんですが、レイアウトやマークアップのしかたの変化を捕捉して範囲指定をメンテナンスしていくのに相当骨が折れますし、最近では記事ページへのリンクに続けて、カテゴリ別、キーワード別のインデックスページへのリンクが並ぶようになったりして、そもそも方法自体が破綻しつつあるんですよね。

それで、どうしようかってところなんですけど、たとえば、収集したページのテキストノードの数 tn と、テキストノードのバイト数 tb をしらべて、tb/tn がしきい値よりも大きければ記事ページとみなすっていうのはどうでしょうね。テキストノード比とかいって。さらにアンカーのテキストノードの tb を除けば、結構いいかんじでインデックスページと記事ページを識別できるような気がします。

って、まだなんにも検証していない、たんなる思いつきですけど。

あと、もうひとつ、収集した記事ページから本文だけを抽出するってのがまた困難。結局、マークアップに基づいたスクレイピングをやるしかないんですけど、やっぱりここにも相当のメンテナンスコストがかかります。

ブラウザのレンダリング結果をみれば、人にはそれとわかるように、本文部分は他の部分にくらべてテキストが密集しているわけなんですけど、でも、HTML レベルでみれば、いろんなタグがはさまっちゃって、そうでもなかったり。

ひとつのサイトから収集した複数の記事ページのテキストノードで、他のページと完全に重複する部分を取り除いて残った部分がそのページ固有の情報じゃないか、っていうアイディアもあるんですけど、どうでしょうね。

ほかに、どんな手があるかな。

いや、ほんとは、全部の収集先が全部入りの RSS を配信してくれればいいんですけどね。

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

2008年9月11日木曜日

Web ディレクターが書くユースケース

うちみたいに小さな会社で Web の仕事をしていると、SEみたいなことも Web ディレクターの仕事になったりします。システム開発のからまない仕事のほうがむしろ少ないくらいなのに、クライアントと渡り合ってシステムに対する要求を分析したり、要件を定義するための専任スタッフを置けるほどの余裕もなく、このあいだまで動画コンテンツの制作で撮影の仕切りや編集作業に明け暮れていたと思ったら、次はこのクライアントのところにいってシステムの要件をまとめてきてね、なんていわれることも実際にありえます。むちゃくちゃですね。でも、まあ、そのへんが楽しいところでもあるんですが。

システムまわりの仕事をするときは、クライアントの要求をヒアリングしたり、こちらからシステムイメージを提案したりしながら、まずはユースケース図をまとめることが多いです。

でも、このユースケース図っていうのが、最初は書くのが難しいんですよね。いや、べつに作図のルールやツールの使い方が難しいわけじゃなくて。そのへんは逆に簡単なんです。あんなもの、いってみれば、子供の落書きみたいなもんで、かかしみたいな貧相なキャラにフキダシをくっつけるだけですからね。でも、絵心じゃなくて、ユースケース心がない人が書くと、ほんとシュールな出来映えになります。真っ白なところにポツンとかかしが立ってて、「メールを受け取る」なんてね。一見して、ガハハ、だめだこりゃ、とかいっちゃいそうになります。

でも、あれは、実はそこがいいところなんですよね。下手だと全然それらしく見えない。クラス図とか、シーケンス図とかは、結構目くらましなところがあって、よくよく見るとなんか変なことが書いてあっても、ぱっと見はなんだかよさげに見えてしまったりします。あと、なんかごちゃごちゃと書いてある箇条書きとかね。少なくとも、だいぶ苦心してんだな、みたいなことは伝わってきたりして。でも、ユースケース図の出来上がりには書き手の苦労なんてちっとも滲まず、実にあっけらかんとしてますからね。

つまり、それだけに、伝えようとしている内容そのものの真価を問いやすい作図法といえるんじゃないでしょうか。適当にやっつけで書くのが難しい。

ユースケース図は、それによって何を表現しようとしているのか、とか、どんな効用が期待されるドキュメントなのか、なんてところをちゃんと確信できていないと上手く書けないかも知れませんね。

まずつまづくのは、どれくらいの粒度で書くかってことだったりしますが、粒度の決定については、次にあげる必要に応じることが根拠になるんだと思います。

ユースケース図の、特に初期のバージョンは、システムの輪郭をクライアントと開発チームの間で共有するために書くんだと思います。それは、範囲の限定と中心の特定といっていいでしょう。

出来上がったシステムを後でユースケース図に還元したようなものがはじめから欲しいわけじゃないですし、また、そんなの書けるわけがない。これからはじまるシステム設計の、進むべき道を照らし出したいわけです。

なにしろ、こういうシステムを作るんだって説明を受けるほうの身になって考えて、彼らが頭に入れやすいシステムイメージを描くことが先決です。そうすると、自然、中心近くのユースケースの粒度は比較的詳細になっていくでしょう。そこには、聞く人になるほどと思わせるような、ロジックやメカニズムが描かれている必要があります。人がなるほど、とか、わかったと思えるのは、複数の項目の関係の仕方が書かれているからなんですよね。ポツンと「メールを受け取る」とか書かれていてもだめなんです。

逆に、周辺は中心から遠ざかるほどに粗くなっていくでしょう。全部いっぺんに頭には入らないですからね。ただし、範囲を明らかにするためには、粗くても欠落していてはいけません。だから、粗いけれどもきちんと数え上げられているか、ということが問われてきます。

そして、この中心と周辺の落差が、今後の開発の方向づけにもなるわけです。ディレクションという言葉には、たしか方向づけという意味もあったと思います。システムに対する要求や要件をまとめる仕事なんて、なんとなく SE 的と思いがちでけれども、そういうふうにユースケースの意義を確かめていくと、案外、システムエンジニアというよりも、むしろディレクターと呼ばれる職域にこそふさわしいタスクかもね、なんて思わないでもありません。

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

2008年9月10日水曜日

これまでのあらすじ

コメントで訂正しましたが、MoKuJi が Blogger を読んでくれないと何日か前のエントリーで書いたのは、嘘でした。順番待ちだったんでしょうか、ただたんに2〜3日待たされていただけのことでした。すみませんでした。

ブログは、書くのも読むのも、時系列で追っていくだけでいいのがとてもお手軽なところで、これだけ広く普及したのも、そういうふうに、コンテンツマネジメントというか、サイトデザインの自由度を絞ったことがひとつ大きかったんじゃないかと思います。ブログ以前の"個人ホームページ"の時代は、ページ構成やナビゲーションシステムを自前で考えなくちゃいけなかったわけで。もちろん当時から日記サイトはありましたけどね。

でも、ものによっては、常に最新エントリーにフォーカスを当てていくんじゃなくて、MoKuJiみたいに、全体のバラエティーさや傾向を伝えられるようなビューが欲しい場合もあるんじゃないかと。カテゴリ一覧やタグクラウドじゃなくて、エントリーむき出しのやつで、しかも、書くほうの手も頭も煩わせることなくっていうので。

MoKuJi はその点すばらしいんですけど、でもやっぱり、自動は自動なりってかんじに、どうしてもなっちゃいますよね。

それならいっそ、もっとふざけた路線で、「これまでのあらすじ」っていうのはどうでしょうか。いわゆる要約エンジンの一種ですけど、ナントカコミックスとか、続きものの歴史小説とかの巻頭にかかれているようなあらすじを、ブログに書かれた文章を組み合わせて適当にでっちあげるんです。

意味なんて通らなくてもよくて、それらしい雰囲気で、ブログに出てくる特徴的なフレーズをダイジェストでみていければいいと割り切って。

まず、全エントリーから頻出語、特徴語を抽出して、それらの語を含むセンテンスをランダムに選びます。つぎにセンテンスの語尾に着目して、語尾のタイプごと用意された、あらすじ風のフレーズをくっつけていく。

語尾のタイプを、疑問、断定、伝聞、推測、決意なんてかんじで分類しておいて、分類ごとに、その語尾に自然につながる適当な結びのフレーズをライブラリ化しておく。たとえば、疑問で、〜なのかな?で終わる文章には、〜なのかな、という淡い期待は、しかし、ほどなくして裏切られることとなった...。とか。

もう適当でいいんです。〜だったことを知る。〜じゃないかという疑念がぬぐえないでいた。〜しようと決意を新たにするのだったが。〜なんですよね、という謎の言葉を残して、彼は消息を絶った。なんて。

それで、あとは出だしと途中の転換と最後の締めをテンプレート化する。

いきなり、20XX年トーキョー、とかいってはじまっちゃうとか。途中のいい頃合いで、一方そのころ、って入れるとか、そして新たな戦いの火ぶたが切って落とされた、とかいって終わるとか。

あともう勝手に設定や登場人物を決めちゃうのもいいかも知れないです。たとえば、このブログを三国志風のテンプレートでやってみると、こんなかんじ。

▼これまであらすじ

曹操が召集、結成した追討軍のもとに、一説によれば、あるテーマで50エントリーも用意すれば、SEO が一応完成するという知らせが届く。これを深く憂えた曹洪は、Web でやるなら、最初のサイトデザインとかCMS構築なんかにかかる初期費用なんて1号分のお金で充分でしょうと曹操に申し出る。そのころ豹蝉は呂布の嫉妬心を巧みにあおり、ある ID をつけた HTML エレメントの class 属性を、ユーザアクションに応じて、 jquery の addClass や removeClass でつけかえて見た目を変化させようともくろんでいた。

なんてかんじで。で、ブログから抽出したセンテンスの部分は抽出元のエントリーにリンクされてるわけです。

こんなにうまくいったら面白いですよね。

そうなってくると、ブログのセンテンスが入る部分を変数で置き換えたテンプレートが書けて、みんなで投稿できるようにしたいですね。変数の書き方次第で、テンプレートに取り込むセンテンスの語尾のタイプも指定できる。

ひとつのブログで何通りもあらすじが作れて、そしたら、そういうあらすじだけをリストしたポータルってのも見てみたいような気がしますね。


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

2008年9月9日火曜日

先行する50エントリー

それなりに名の通ったスポンサーの受託仕事ならともかく、自主企画でWebアプリを開発して、それで世の中にリーチするってのはなかなか難しいもんです。アクセスはさっぱりなのに、広告やアフィリエイトの引き合いだけは集まったりして。

図々しくもいったんそのWebアプリ自体が持つ訴求力を棚に上げさせていただいて考えると、なにしろ、まずはじめのとっかかり、ユーザーの流入口を確保するのが難しいです。まず、はなばなしくお金はかけられないとして、とりあえずニュースリリースを出してみるとか、検索ボットにくまなくクロールしてもらうようにするとか、ディレクトリ型の検索サービスや、ジャンルによってはランキングサイトに登録するとか、あとは恥ずかしながら自分でソーシャルブックマークに登録してみるとか、なんてくらいではとてもとてもってかんじです。

思うに、そういうのは、それこそたんなる参加申請に過ぎなくて、流入口の確保、っていうかまず獲得してから確保ですね、それにはもっと継続的な、Web アプリの開発と同じくらいリソースをかけた活動が必要なのかもしれませんね。

そうすると、やっぱり力をいれるべきなのはスタッフブログなんじゃないかなと思います。スタッフブログといっても、リリースのアナウンスやサポートをやるってだけのものではなく、その Web アプリに関連のあるテーマのうんちくエントリーを精力的にアップしていくみたいな。もう Web アプリのリリース前から、企画段階の進捗にあわせて。

企画の段階では、いろいろブレストをやったり調べものをしたりするわけで。たとえば、ユーザー参加型のクイズサイトを作るって場合なら、テレビのクイズ番組の歴史を調べたり、既存のクイズサイトを集めたり、クイズにしておもしろそうな雑学ネタを集めてためしにクイズを作ってみたりすると思います。それから、クイズサイトとしてどんな機能があったら面白いのか、出す側、解く側の気持ちになってみていろいろ考えるでしょう。そういうのを全部ブログに書いちゃう。

一説によれば、あるテーマで50エントリーも用意すれば、SEO が一応完成するそうです。 たしか、livedoor ディレクターブログにそう書いてありました。完成っていうのが、どういう状態かよくわかりませんけど、でも、仮にクイズ好きの人たちが一定の層として存在するとして、その層にリーチしようと思うなら、Web アプリがぽつんとあるよりも、そういう、内容として幅を持たせやすくって、外部ともつながりやすいブログみたいなもののほうが確かに有利なように思えます。もちろん、ちゃんと読んで面白くなくちゃだめですけど。

それに、企画段階のいわば遠心的な活動の成果が、実際の開発の段階まで生き残る割合ってそんなに高くないもんだと思いますけれども、そういうプロモーションの一環として役にたてられるなら、これは無駄もなくなっていいじゃありませんか。ほんと捨てるところがないね、ってかんじで。


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

2008年9月6日土曜日

eラーニング教材のアーキテクチャ

eラーニング教材をつくることが多いです。昔は何千何万という HTML、音声、画像、動画ファイルをCD-ROMに入れたり、ローカルにイントールしたりするのが多かったんですが、ブロードバンドがあたりまえになってからは、ほぼ100%、バックエンドに DB を持つ Web アプリになっちゃいましたね。正直いって、それでかなり保守や運用が楽になりました。開発自体もそうですね。このへん、ぼくは本当に孫正義さんには感謝しなくちゃいけないなと思っています。

フル Flash のを作ったりもしましたが、今はあんまりやりませんね。たとえば語学の教材だと、テキスト弄りをいろいろやりたくなるんですけど、Flash だとやりづらいところがあるんですよね。最近は、むしろ、フル Javascript です。

フル Javascript っていっても、たんにいろんな表示上のエフェクトを Javascript で実装してるっていうだけの話ではないんです。教材をひとつのアプリケーションとしてみて、MVC モデルで考えると、もう M も V も C も 全部 Javascriptっていう。極端にいうと、サーバサイドは、クライアントのリクエストに応じて DB の内容を Json に変換して渡すだけだったり。

たとえば、学習画面を開くまでのシーケンスを追っていくとこうなります。

1、コンテナとなる小さな HTML データがロードされる

2、コンテナに記述された script タグにより、Jemplate データがロードされる

3、コンテナに記述された Javascript により、非同期通信で、Json データがロードされる

4、Json データを Jemplate で定義されたテンプレートにしたがって HTML に変換し、これらを操作するビュー層のクラスのインスタンスを生成する

5、Json データをもとに、モデル層のクラスのインスタンスを生成する

Web アプリが動的に出力しているのは、コンテナと Json データだけ。つまり、Web アプリは、フル Javascript 教材を乗せるための、データストレージつきのプラットフォームってかんじですね。

でも、これ、いかにもめんどくさそうですよね。なんか、いたずらに複雑にしているだけような。でもこれがいいんです。その理由の第一は、やっぱりそれが eラーニング教材だからってところにあると思います。

というのも、学習中、画面遷移のたびにサーバとの通信で一瞬でも待たされるのがかったるい。意欲が殺がれます。1画面ずつ完結性のある内容ならまだいいですけど、試験みたいなのとかで1問ずつ画面遷移するタイプのものだとこれは嫌なもんです。それなら、ひと区切りつくところまでのデータを最初にいっきにロードして、あとは、Javascript で表示のコントロールをやればいいじゃん、と、まずこうなります。

だけど、複数画面分の内容のHTMLデータって結構かさばります。たいがい同じ構造のループですから重複も多い。なんとかならないかっていって、じゃあ、マークアップとデータを完全に分離して、Jemplate と Jsonに分けちゃうかと。

そうするとコンテナとコンテンツも分離できることになって、最初に軽いコンテナを到着させて、コンテンツは後からゆっくり、その間はコンテナ上のプリローダでユーザのご機嫌をうかがうなんてことも、なんだか自然にできるようになっちゃいます。

それから、なにしろ、マークアップとデータが分離していますからね、教材としての表現力はぐんと向上します。まあ、たいていのインタラクションは Jquery があれば簡単にできてしまうんですけど、それでも、同じデータでまったくレイアウト構造の違うビューに切り替えたいとか、あるいは表をソートするとかね、そういうのは DOM でがんばるよりもはるかに簡単にこなせちゃいますよね。

あと、これこそ、eラーニング教材ならではだと思うんですが、後から営業用にローカルでも動くバージョンを用意してくれないかなんて話がよく出てきます。そういうときにも、この作り方にしておくと便利です。もちろん、マークアップとデータが一体になった出力を行っている場合でも対応が不可能だというわけではありませんが、こっちのやり方のほうがリーズナブルでしょう。Jemplate と Json をローカルファイルにしちゃうだけで済みますし、デモ用に機能制限を行ったり、データを適当に間引いたりするのも、テンプレートとデータをいじるだけで簡単にできます。

おそらくブラウザベースのフィードリーダなんかも、こんなかんじで作られているんじゃないかと想像しますが、eラーニング教材を作る上では、このアーキテクチャが今のところベストじゃないかなあと感じています。

難点は、富士通さんのLMSに乗らないことくらいかな。

2008年9月4日木曜日

Webで持続可能な論座

論座って朝日新聞が出してる月刊のいわゆるオピニオン誌が廃刊になるそうです。いや、いままでそんな渋い雑誌、立ち読みしたことすらなかったんですが、トップの座談会に学生の頃好きだった柄谷行人が出てたんで、ちょっと冷やかし半分で買ってみたんですよね。そしたら、案外おもしろくて、ぺろっとほとんどの記事を読んじゃいました。

読んで楽しいかんじは、はてブの人気、注目のエントリーをざーっと読んでいくのと似てたかもしれません。はてブだって Web 関連のTIPSを抜いたら、あとはいってみればみんなのオピニオンのぶつけあいですもんね。いろんな人がいろんな立場や見方でもって登場して。

論座は朝日なんで正義とリベラル一辺倒なのかなと思ったら、そうでもなくて、Wikipedia によれば、いろんなテーマで保守とリベラルの論客をかけあわせて楽しむような編集方針らしいですね。それと、けっこうめちゃくちゃで男前な人も出てくるんですよね。あの、フリータの人がすごいこと書いたってちょっと話題になってた、丸山真男をひっぱたきたいとかいうタイトルの戦争待望論も論座に載ったんですね。

廃刊になるのは、赤字だからってことなんですけど、何をいまさらというかんじがしないでもありません。こういうのは、採算よりも、言論機関の使命とか存在証明とか、あるいはデモンストレーションとして、ほかで埋め合わせるのを前提にやせ我慢で出すもんだと思ってました。そんなに多く刷るもんでもないだろうし、そんなに高コストなつくりにも見えないし。どうなんでしょう。

いや、それでも、きっと1号出すごとに1千万単位の費用がかかるんでしょうね。そう考えるとやっぱり大変ですね。広告はほとんど入ってないし。表2に焼酎、表3にめがね、表4に靴の広告が入っていて、あとは誌面のところどころに出版社の広告がちょぼちょぼですからね。

それなら、こういうの Web でやったらどうでしょうね。内容的には、かなり親和性が高いようにも思えるんですけど。論座に載るようなオピニオンのひとつひとつがネットに公開されたリソースとしてパーマリンクを持つなんて、それこそ言論機関の社会的使命の果たし方としては理想的じゃないですか。

雑誌のコストの半分以上はコンテンツよりも、版下制作、印刷製本、取次販売手数料といったブツの製造と流通にかかるそうですよ。

Web でやるなら、最初のサイトデザインとかCMS構築なんかにかかる初期費用なんて1号分のお金で充分でしょう。あとは原則、毎月のコンテンツの制作費だけどうにか捻出できればいい。

論座の中には、広告も含めてたくさん本が紹介されています。ブックレビューもあるし、出てくる人にはみんな著作があるし。なんで、サイト全体でばんばん Amazon アフィリエイトしまくるってのはどうでしょう。

それで、論座にがんばってほしい愛読者たちに、本を買うなら論座経由の Amazon で、とお願いする。つまり、それが一種のドネーションになって論座が支えられるという。あなたが本を一冊読むと、論座サイトの寿命が1時間のびます、とかいってね。それで足りなければ、あとは、焼酎とめがねと靴で、どうにか。だめですかね。

作るほうも読むほうもテンションが上がっておもしろいことになりそうだと思うんですけど、こんな話、中の人には、荒唐無稽とかいわれちゃうのかな。


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

2008年9月3日水曜日

ブログ・トップページ・ジェネレータ

ここに書いてるエントリーなんて、近況報告というわけでもないし、続きもののお話でもないしで、とくに読む順番を拘束する意図も理由も積極的にはないんですよね。

たしかに日々書き足していくわけですけど、日記帳を1ページ目から順番に埋めていくというよりは、なんていうか、タグクラウドのようなものを少しずつふくらませていくというイメージのほうがしっくりくるかんじで書いてるっていったほうが当たってるかもしれません。

だから、サイドバーに出すメインナビゲーションは、カレンダーや期間別のリストより、これの場合はタグクラウドのほうがいいかなあとも思ったんですけど、Blogger にそういうガジェットないみたいですし(探し方が悪いだけかも知れません)、ブログパーツでも案外そういうのは見当たらないんですよね。いや、そもそも、タグクラウドは全体の傾向を知るのにはいいけど、個別のエントリーへのナビゲーションとしてはちょっとダイレクト感に欠けますしね。

Blogger でやるなら、なんとなく自分でよさげなエントリーを選んで、それをどっかのソーシャルブックマークに特定のタグをつけてブクマして、それでそのタグで絞り込んだ状態のフィードを外部フィード表示用のガジェットで読み込むのがいいかな、なんてことも考えました。でも、ちょっと面倒くさい。

そういう意味では、MoKuJi ってサービスのアイディアはすばらしいですよね。

これですね。

MoKuJi
http://mokuji.deckkr.jp/

でも、これ、Blogger じゃ使えないみたいです。残念。

しかし、こんなかんじで、毎度最新のエントリーが登録されたその時点その時点で、ブログ全体のバラエティーさを反映したトップページを自動生成してくれるようなサービスがあってもいいのにな、なんて思います。目次とか、そういうセカンドなのじゃなくて、もう思い切ってトップページ。ちょっと違うかも知れないけど、やりくちとしては、Google News みたいにして。

トップ記事はまあ、鮮度が高いということで、新着エントリーを。サマリーと、写真があれば写真つきで、どーんと。その下にはいろんな角度で拾われためぼしい記事がいくつかのコラムにリストされている。ニュースサイトみたいなレイアウトでね。

MoKuJi がそうだと思うんですけど、たとえば、出現頻度の高いキーワードを集計して、そのキーワードを多く含むエントリーをリストしたり、各記事から特徴語を抽出して、特徴語ごとにエントリーをリストするとか。これで、ブログ全体の傾向と範囲がなんとなく知れるでしょう。個別のエントリーのタイトルがばんばん露出した状態で。

さらに、アクセス、コメント、トラックバック、被リンク、被ブクマの件数などから総合的に評価して注目エントリーと銘打ったリストを作ってみたり。

で、おなじようにトップページを作っていて、内容的に近いところがある他のブログのエントリーなんかもエクストラメニューのへんに出しちゃったりして。

もう、ブログ本体のほうは記事を投稿、管理するためのバックエンドだと割り切っちゃって、一般に公開するのはこっちのURLってことにしちゃえば、各エントリーのページのフッタにも、そういうトップページと同等のナビゲーションを表示できますね。

なんて、そういうのどうでしょうか。実際に自分でブログを書きはじめてみて、まだ間もないんですけどね、でも、なんだか最近そういうのが欲しくなってきました。

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

2008年9月2日火曜日

即席ワイヤーフレーム

Web デザインは、何を元にするかって、先行するプロセスの成果物として出てきたワイヤーフレームだったりしますね。じゃあそのワイヤーフレームはいったい何を元にして書かれているんでしょう。

クライアントへのヒアリングやユーザ調査や既存サイトの運用経験から、サイトの目的もシステムとコンテンツに対する要求もはっきり絞り込まれてるし、予算やらスケジュールやら大人の事情やらも考えて、いよいよ具体的なサイトストラクチャも見えてきたって段階に入ってくれば、たとえばトップページのワイヤーフレームなんて、そりゃあもうほとんどひとりでにすーっと切れていきます。

なんて、そんなことはないと思います。

そうして積み上げられ、つじつまを合わせるのにも苦労した、それなりに図体のあるサービスやコンテンツの全体を、どうやって、それこそ稲妻のようにユーザに伝えきることができるかって、その仕事がここにもう一枚挟まるはずです。情報のデザイン、もっと狭くいうと、メッセージのデザインですね。

そこんところをどうやるか。いろいろやり方はあると思いますが、正攻法では、ぼくはユーザモデル(サイトの利用を通じてユーザが心に抱くサイト像)をマインドマップに書いてみるのがいいと思います。こちらがそうあってほしいと願うやつをね。それで、そこから逆算するようにしてメッセージを組み立てていってワイヤーフレームに落とし込む。

結構、そういう作図法のボキャブラリ次第で検討できる水準や範囲が決定づけられちゃうってところはありますよね。画面遷移図とワイヤフレームだけじゃうまく設計できないような事柄がサイトデザインにはたくさんあると思います。

しかし、でもまあ、それはあくまでも正攻法。実はもうちょっと即席なやり方もあって、もうちょっと簡単に済ませていい場合もけっこうあるんじゃないか。

たとえば、次の3つのポイントを押さえたメッセージを揃えて、あとはできるだけシンプルに、わかりやすく各要素を並べることだけに気をつけてみるとか。

1、これは○○です。

なんであれ、とにかくタイトル、タグライン、ウェルカムメッセージで、これは何であるのかをできるだけ短く言い切る。適切なメタファーやポピュラーなプロトタイプで使えるものがあったらどんどん動員する。

ここで期待するユーザの反応は「へえ」です。

2、たとえばこんなかんじです。

最初の「へえ」は、ほぼ間違いなく「じゃあ具体的には?」という疑問と期待につながっていくものです。そこにぶつけるのは、当然、ライブデモ、ゴールまでのステップの絵解き、メリットのリスト、喜びの声なんかになるでしょう。

ここで期待するユーザの反応は「なるほど」です。

3、今すぐココをクリック

で、最後に、端的に、わかりやすく、いかにも簡単そうに、ユーザがここでやれることを示すことができれば成功でしょう。

ここで期待するユーザの反応は「よし!」です。

もう、ばかみたいに当たり前の話のようですが、たいがいこんなもんでいけるもんですよ。でもこれが案外ちゃんとできてなかったりするんですよね。ワイヤーフレームの段階で。いろいろてんこ盛りで、こういう基本がどっかにいっちゃってるっていうのもありますね。

もちろん、サイトごとターゲットユーザごとに、メッセージの内容はそれぞれですよ。どんなメッセージがユーザに届くか、ユーザを惹きつけるかは、ペルソナとか持ち出して個別に検討しなくてはいけないんですけど、へえと言わせて、なるほどと思わせて、よし!ってその気にさせるっていう運びは、だいたいなんにでも共通するメッセージデザインといっていいでしょう。

あとこれは、他の人が書いたワイヤーフレームをレビューするときのひとつの基準として使えると思いますよ。
-----------------
sent from W-ZERO3

2008年8月29日金曜日

オレMLでマークアップしな

雑誌、新聞、チラシ、電車の中の広告、カップラーメンのフタ、居酒屋のメニューとか、そういうのを目にすると、これは大見だし、これはリード、なんて、つい、要素を分解してそれぞれの名前をちゃんといえるかどうか確認してしまいます。ハシラ、小見出し、キャプション、データ、なんて。タイトルまわりだと、これが情報のカテゴリーや種別を明示するパート、これが内容を端的に伝えるパート、で、これが読者を煽るパート、なんて役割の言い当てをしてみたり。

昔、雑誌の編集をやらされた頃に、その道での師匠でもあるうちの社長から、そういうトレーニングでさんざんしごかれたんですよね。雑誌一冊をまるごと頭からそんな調子で分解していくんです。

まず、構成要素のひとつひとつを名指しで呼べること、そして、それがなぜそこに配置されていて、全体の中でどんな役割を担っているのか説明できること。

それでくせになっちゃったんですよね。挙げ句の果てには、新聞読んで、この見出しのつけ方は間違ってる、なんて言い出したりして。

でも、最近、自分の身の回りに限った話ですけど、そういう、エディトリアルデザインの素養みたいなのを、Web ディレクターや、Web デザイナーたちがちょっと疎かにしすぎなんじゃないかなって思うことがあるんですよね。

ワイヤーフレームやらデザインカンプやらをチェックしてても、そのへんを直してもらうことが多いかもしれない。

Web デザインでも、そういう要素名ってありますけど、ほとんどが、ナビゲーションの種類の名称で、あとは、タイトルやキャッチコピー系のがちょこっとあるくらいじゃないですか?サイトID、タグライン、グローバルナビゲーション、リモートナビゲーション、ブレッドクラム、ウェルカムメッセージ、ローカルナビゲーション、エクストラメニュー、コンテクストナビゲーション、フッタナビゲーション、ページネーション。

で、下手すると、コンテンツはコンテンツの一言で終わりだったり。テキスト、画像、おわり、とかいって。でも、その中の組立てにもいろいろあるわけです。

そうした局所的な小さな情報デザインこそが、実はユーザとのコミュニケーションの本体といっていいわけでしょう。あとは、いってみればそこに連れ込むまでのプロセスに過ぎない(いや、それが大変なんだけど)。

というわけで、むかし受けたトレーニングみたいなのを復活させようかななんて思わないでもないんですが、今なら、ちょっと込み入ったサイトをお手本に、そのコンテントだけぶっこ抜いて、それを自分なりに考えた要素名のタグで思いっきりマークアップしてみるってのはどうでしょう。いわゆる野良XML、それこそオレMLでね。

それをみんなで見せ合うと、おい、これがおまえにはそんなふうに見えてんのかー、なんてね、結構盛り上がるかもしれませんよ。あ、そうだ、そういうのがポストできるサイトってのはどうかな。元のページのURL と共にオレML版のソースをアップ。すると、エクスプローラ風のツリーでみせてくれる。コンテントの対応をみてインスペクタみたいなのができたらすごいな。人によってこうも違うかものかとか、ふざけたタグの名前に笑うとか。

CSS の id と classでやる手もあるけど、それだとあの中途半端なHTMLタグがセマンティック・マークアップの邪魔になるような気がするんですよね。といって全部 div ってのもばかっぽいし。やっぱここは、オレMLで。

2008年8月28日木曜日

IE6 Juggling #ID.Classes Bug?

IE6 の CSS で、ひとつの HTML エレメントに複数の class を割り当てるとろくなことにならない( 最後に書いた class セレクタのスタイルしか適用されない)のは知ってたんですが、今日、おわー、こんなのもあったのかーというひどい IE6 仕様にでくわしました。これも有名な話なんでしょうか?

ある ID をつけた HTML エレメントの class 属性を、ユーザアクションに応じて、 jquery の addClass や removeClass でつけかえて見た目を変化させようとしたんです。

css のほうはこんなふうに書いておいてね。

#target-id { /* default style */ }
#target-id.class-a { /* a style */ }
#target-id.class-b { /* b style */ }
#target-id.class-c { /* c style */ }

それでたとえば、jQuery で $("#target-id").addClass("class-c") ってやれば、c style が適用されて見た目ががらっとかわるってなもんでしょう。

でも IE6 だと、default style のまま。あれ、IE6 って、#ID.CLASS セレクタって使えないんだっけ?って$("#target-id").addClass("class-a
") ってやってみると、これは効くんです。

なんだこりゃってわけで、HTML エレメントの class 属性を直接いじっていろいろ試してみたところ ...

class="a"
-> style a
class="b"
-> style default
class="c"
-> style default
class="a b"
-> style b
class="a b c"
-> style c
class="a c"
-> style default
class="b c"
-> style default

と、まあ、ざっとこんなかんじです。定義の記述順にあたまから並べていけば、一番最後のクラスが適用されるんですよね。いったいどういうメカニズムなんでしょう。

まとめ。

・IE6 で #ID.CLASS セレクタを使うなら、1Id1Classがおすすめ。

・複数のクラスをつかいたいなら、定義の記述順どおりに、HTML エレメントの Class 属性にクラス名をならべよう!

結局もうね、addClass removeClass でやりくりするのはあきらめて、css(key, value) でスタイル指定のひとつひとつを個別に変更することにしました。

まったくあたまにきますね。ひょっとしたら CSS マスターのみなさんの間では常識の類なのかもしれませんが、ちょっとググってみたかんじでは、ドンピシャの情報が見当たらなかったです。IE の CSS バグまとめサイトとかにあるかな、明日みてみます。

2008年8月27日水曜日

ネグリとハートのコモン

Blogger にメールでエントリーを投稿できなくなっちゃった件、トラックバックというかバックリンク?をもらって、まとめサイトを作ってくれてる人がいることを知りました。
リンクはりたいんですけど、どうにもこの、今そのまとめサイトがみつからない。 W-ZERO3 の Opera でも IE でも、パーマリンクにバックリンク表示されないし。ググっても出てこない。あした会社にいったらリンクはります。
ここ最近の Blogger の障害をまとめるよ!!
http://inoshiro.blogspot.com/2008/08/blogger.html
はりました。
そんなわけで、そのまとめサイトで、少なくともこれが Blogger v.s. W-ZERO3 という狭い話じゃないことがじゃないことがわかりましたし、同じように悩んでいる人がいることに、正直、なんだか心強いものを感じました。まったくありがたいことです。
ここんところ、アントニオ・ネグリとマイケル・ハートの「マルチチュード」って NHK ブックスから出てる本を読んでるんですけど、それにコモンって概念が出てくるんですね。いや、ささやかすぎるかもしれないけど、これこそ、まさにそのコモンの一端なのかなって思いました。

コモンっていうのは、なんていうか、こう、政治経済社会全体を股にかけた、いろんな人間活動の基盤となるような共有財とでもいうんでしょうか、知識とかコミュニケーションの機会とかも含めて。
コモンといえば、われわれの界隈では、レッシグのクリエイティブコモンズが有名ですけど、それもその一部として含まれるかんじですね。
で、それが、端的にいえば今の悪としてのグローバル資本主義に対抗する手口の、ひとつの軸になるんだ、みたいな話なんです。
彼らがいうコモンの反対は私有でも専有でもプロプライエタリとかでもなくて、搾取なんですよ。で、搾取ってのはたんに奪われるっていうのとも違っていて、取られるほうも進んでそれに参加しなくちゃいけないような状況としてあるんですよね。
それの、洗練された最新バージョンとしてアメリカ主導のグローバリズムがあって、うっかりしてるとそれでいいなんて人も増えちゃうんだけど、そこには程度問題があって、悪い方にはいつまでも貧困と暴力が残ってしまうよ、と。
左翼ですよね。でも、ネグリなんて既存の左翼のことなんかけちょんけちょんで。左翼の本来は、つねに現状を未完成とみたてて、ひっきりなしに改善の努力を怠らないってことだとすれば、敵の洗練に対抗してこっちもどんどん洗練していかなくちゃ!。ってことなんでしょう。
そんなのを読むと、ハッカーだとかギークっていわれるような人たちがいて、たいていはそれぞれの勤め先を持ちながら、でもコモンの方を向いてどんどん更新を続けていく Web のある世界って、ずいぶんとすてきなもんだよなあと改めて思いますね。はじめに書くプログラムがみんな Hello World!っていうのもかっこいいですよね。
Web ディレクターだって、livedoor のみなさんとかね、惜しみなくコモンに財をもたらしてくれてますもんね。もちろんあれは 企業 PR の一貫なんであって、そういう意味ではぐるっとまわってコモンの反対が目指されてるんだなんて言い方もできるかも知れませんが、仮にそうだったとしてもべつにいいじゃありませんか。どういう下心があったってコモンへの貢献はげんに行われているんだし、むこうの搾取とおなじように密やかに、それと知られず浸透して、気づいたときにはもう外せなくなってるって、それもネグリとハートのいうコモンの特徴なんだと思いますよ。












2008年8月26日火曜日

ジャッジング・センター

オリンピックの野球みてて思ったんですけど、最近はハーフスイングにずいぶん厳しいジャッジが下されるようになってませんか?国際ルールだから?ぼくが子供の頃に見てた野球はもっとおおらかだったよう気がするんですけどね。気のせいでしょうか。

もう、ちょっと打つそぶりをみせただけでも塁審が手を上げてる。あれ、バットが止まって、キャッチャーとアンパイアが、あーっ今のどうなのよ!ってすごい勢いで一塁の塁審のほうを指さすでしょ、そしたら塁審も手を上げかけて、あ、でも今のやっぱセーフ、みたいにちょっと前につんのめりながらおっとっとなんて手を開いちゃって、それを見たキャッチャーがオイなんでーって反射的に関係ない三塁の塁審に指さし確認しちゃったらもんだから、三塁の塁審も、まったくあんちくしょう、普段から優柔普段でグズでどうしようもねえと思ってたら、また、こんな大事なところでしくじりがって、なにやってんだばかやろうって、思わず一塁に向かって高々と右手を上げちゃったりしてね、もうわけがわからない。

えー、なんてまあ、そんなわけでございまして、バッターにしろ、審判にしろ、ね、こう瞬時に判断を下すってのは、とかく難しいものでございます。

それで思い出すんですけど、選挙になるとテレビに政治家を呼んで、なんかタイムアタック風に Yes/No で質問責めにしますよね。あれも見てるぶんにはいいですけど、答えるほうはさぞ大変でしょうね。先に質問渡してもらえるのかな。まじめに考えると、ああいうふうに、即答の妙を競い合うところばっかりいたずらに際だたせるのもどうかと思いますけど、でも、まあ、あれで露わになる面があることも事実でしょうね。

で、あれを、政治家だけにやるんじゃなくて、われわれの人間関係の中にも持ち込んでみたらどうでしょう。

野球の話のながれでいうと、バッティングセンターでボールを打つみたいなかんじで、ばんばん投げつけられる質問に次々答えていくんです。 Yes/Noで。時間内に答えられないと見逃し。 ジャッジングセンターとかいって。

質問は、そうやって誰かの本性を暴きたい人が作る。ピッチングマシンにタマを込める。それでメールとかで答えてほしい相手を招待するわけです。彼女からそういうのが来て、やってみて、なんていわれたら、もうやらないわけにはいかない。やらないこと自体があやしい、なんていわれる。

全部の質問に答え終わると、回答結果が質問者にメールで送信される。質問は何問あるかわからないので、答えるうちに突然終わって送られちゃう。途中でやめても、そこまででおくられちゃう。つまり、ひそかに練習して答えを準備することはできない。

で、質問・回答が終わったあとの問い質しや、言い訳は当事者同士でよろしくやっていただく。うーん、じつに嫌な企画ですね。

いや、そういう疑心暗鬼の恋人同士とかだけじゃなくて、うちみたいな会社の入社試験とかでも使えるかもしれないですね。

あと、そういう対決型だけじゃなくて、○○がわかる20の質問とか、オープンな質問状もみんなで作れるようにして、回答すると、回答結果のパーマリンクが持てて、いろんなプロフィール情報の一部として活用してみたり。

回答結果から一定のロジックで診断するとか判定するとかじゃなくて、そういうふうに、時間制限あり一回こっきりの質問責めにどう反応したか、その様子を記録して評価するっていうWeb アプリですね。あると思います。

2008年8月25日月曜日

Blogger v.s. W-ZERO3

このブログは、たいてい会社からの帰り道、電車の中や、近所のミニストップ、ときには一人で入る和民とかで書いてます。W-ZERO3のメーラで書いて送信してるんですけど、なんか先週の木曜日の深夜あたりから、メールが受け付けられないんですよね。timeoutとかいって返ってくる。

でも、W-ZERO3 から Gmail には送れる。それから、Gmail から blogger にも送れる。W-ZERO3 から blogger に送れないんですよ。

何があったんでしょうか。あと、こういう不具合の報告ってどこからすればいいんでしょう。

これからは、こうやって、Gmail から送ることにしようかな。

2008年8月24日日曜日

おれた心と Web とポテトチップス

コンビニの雑誌の棚のならびの、単行本コーナーのラインアップって、こっちの心身の状態によってはですけど、なんだかすごく魅惑的みえることってありませんか。

すっかり心は折れててですね、もう、はやく家に帰って、びろーんとはらばいに寝そべって、健康とかカロリーなんかまったく気にせず、ポテトチップスやらシュークリームやらをだらしなく食い散らかしながら読みたいような本。

すぐにあちこちシミだらけになって、なんかの食べかすがいっぱいはさまっちゃうような、たとえばそうですね、日本史の謎、都市伝説、怖い話、お宝画像、トリビア、人生のハウツー、占いだとかの、はじめからついでに買われるつもりで待ち構えてるようなジャンクなやつ。

ああいう本がコンビニに並ぶようになったのってそんなに昔のことじゃないような気がします。でも、あれほどコンビニっていう存在の、少なくとも一部の層に対する麻薬的な部分を象徴してるもんも他にないんじゃないでしょうか。なんていうか、ポテトチップだけを買うときには顕在化しない何かが、ポテトチップとそういう本を一緒に買うといっきに立ち現れるでしょ。急にダメ人間臭が漂い始める、みたいなね。

このあいだ、ちょっとわけあって、民俗学とかでの日本の昔話研究ってどんなになってんのかなと、ざっくり Wikipedia で調べてみたら、関連で、日本の妖怪だとか、都市伝説や噂の一覧だとかが出てきて、思わず読みふけってしまったんですけど、そのとき、ああこれって、コンビニのジャンク本の代わりになるかもって思いました。

それこそ、折れた心で寝そべってお菓子たべたいユーザをターゲットに、そういう、コンビニのジャンク本に匹敵するネット上のコンテンツを集めた、一種のまとめサイトを作ると面白いかもしれませんね。ケータイ向けですね。

まずは、Wikipedia のジャンク本的な項目とか2chや教えて系のスレッド、ニュースサイトの記事、マニアックな個人ホームページなんかを集めて、分類して、それをジャンク本の一冊一冊のようなかんじのサイトデザインでまとめておく。

それから、実際のジャンク本やそういうネタのテレビ番組とかのレビュー記事を書いて、内容のさわりがわかるようにするのもいいかもしれないですね。テレビの「虎ノ門」とか「ラジかる」とかで、若手芸人が過去一週間のテレビ番組の内容を、実際のビジュアルは一切なしでくわしく紹介するコーナーがあったりしますけど、ああいうかんじで。

それで、そういう Web サイトを、コンビニが一種のプライベートブランドの商品として開発してですね、単行本の棚とお菓子や珍味の棚のどっかで PR するとか、できないかな。

2008年8月22日金曜日

朝型 Web

ぼくが小学生の頃は夏休みといえば早朝にラジオ体操に行ってはんこを押してもらってたもんです。でも、最近はそういうのないんでしょうか。小5の娘がいるんですけど、いままでそんなのがあるって話は聞きませんね。

あれには、夏休みだからってルーズな生活をおくらないようにっていう教育的な意図があったんですよね。きっと。

あるいは、あれかな、朝から家んなかに子供がいると、もうクソうるさくってしょうがないからっていう、地域ぐるみの陰謀だったのかも知れませんね。ぜんたいに、今じゃ考えられないほどうじゃうじゃいたわけですから。子供が。

それはともかく、早起きの習慣を崩さないようにってことでいえば、早朝の一定の時間だけ学校のサイトが開いて、そこにログインして、たとえば算数のドリルとかをやらなきゃいけないっていうのはどうでしょうね。それが夏休みの宿題の一部にもなってて。

時間がくると、もうその日のドリルにはアクセスできなくなっちゃう。

いままで何日参加して、どれくらいの問題を解いたのかとか、そういうステイタスはいつでもみられるんだけど。

ドリルとともに、時間限定でチャットも使えたりして、友達とちょっとしたコミュニケーションもとれて、それはそれで便利だったりする。でも、先生もときどき入ってきて、いつまでもしゃべってんじゃない、なんて怒られたりして。

それで、終わりの時間が近づくと、画面の隅でカウントダウンがはじまって、3、2、1、はい終了、またあしたーって。

いや、実際には、そんなの PC とインターネットの家庭普及率が 100 % にならないとありえないですけどね。

でも、子供の夏休みの話だけじゃなく、そういう時間限定 Web っていうのも面白いんじゃないかと思うんですよね。

たとえば生活を朝型に変えたい人たちの支援サイト。みんなでおはよう、と声をかけあって早朝になんかちょっとしたクイズ大会をやるとか。缶コーヒーのメーカーがスポンサーだったりして。あるいは、それ経由でAmazonのタイムセールに参加できるとか。

やっぱ企画としては朝がよさそうですね。他の時間帯じゃちょっと考えにくいかな。どうでしょう。

早起きの人限定の朝型 Web。ぼくはぜったい無理ですけど。

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

2008年8月21日木曜日

サイトデザインのプロットとシノプシス

ワイヤーフレームが、画面デザインに干渉しすぎて、不用意にその可能性を狭めてしまったりするのを嫌って、いわゆる構造段階、骨格段階といわれる作業フェーズでは、各画面に含まれる要素のリストアップだけをやって、あとは表層段階のデザインワークにまかせるっていうやり方もあるみたいですね。

ぼくの勤務先は、実はもともとが書籍や雑誌をやっていた編集プロダクションでして、Web の制作にも、編プロ時代のノウハウを持ち込んで自分たちなりにああだこうだいって試行錯誤を繰り返してきた歴史があったりします。

つい3〜4年前までは、構造・骨格・表層段階の区別もなく、編集者が書いたラフをもとにデザイナーがデザインをおこす、といったプロセスでサイトデザインをやってました。

もうラフ中心主義ってかんじで、デザインもラフの清書みたいなのしかあがってこなかったりして。

それが当時、ぼくはけっこう不満でした。ラフはあくまでも情報の構造をスケッチしているだけで、デザインは、見た目としてラフに忠実である必要はないってデザイナーにいってはみるんですけど、なかなかうまくいかない。

まあ、ラフ・スケッチ=デザインの粗い下書きってことなんでしょうから、言葉の使い方からして限界があったんですよね。

そういう経験もあるので、ワイヤーフレーム不要論が求めるところはよくわかるつもりです。

でも、サイトの目的とユーザーニーズのマッチングに向けた情報デザインこそが、最後の表層段階の作業に対するインプットなんだとしたら、やっぱりワイヤーフレーム必要でしょ?って思うんですよね。

ちょっとまとまった原稿を書くときなんかに、まずプロットを作れ、それをシノプシスにまとめろ、それから文章にしろ、になんて教わりました。

プロットもシノプシスも、もとは作劇法の用語だと思いますが、プロットはお話を構成する要素と要素間の因果関係や論理的な関係を箇条書きとかでまとめたものですね。マインドマップなんかでも書けそうなものです。

シノプシスは、話す順番、ストーリーの展開のさせ方、論法や話法を考えた上での、いわば、あらすじのことですね。

プロットは構造で、そこに時間をいれるとシノプシスになる。システムの設計ならクラス図がプロットで、シーケンス図がシノプシス、かな。

ワイヤーフレームは、プロットとシノプシスの両方の側面を持つものだと、ぼくは思うんですよね。

一方で、画面内に含まれる要素のリストアップは、プロットにはなるけど、シノプシスにはならないでしょう。

でも、プロットで確認した情報構造を効率よく、魅力的にユーザに伝えるためには、どういう順番と強弱でユーザの目や頭や心に提示していくべきなのか、そこらへんも、表層段階に入る前に検討しておくべきなんじゃないでしょうか。

そして、そうしたユーザーコミュニケーションのシノプシスを具体的に実現するためには、どのような視覚デザイン、インタラクションデザインが有効でありえるのか、を考えるのが表層段階でしょう。

もちろん、表層段階とその前段階はいったりきたりで、特にシノプシスのあたりは、デザインワークの中でより効果的なやり口がみつかったりして全然いいんです。

だけど、Web ディレクターは、ユーザーとのコミュニケーションに責任をとるわけですから、プロットだけでなくやっぱりシノプシスまで込みで、デザイナーに対する最初のインプットを行うべきだと思います。

ただ、あくまでもワイヤーフレームはそのために書くんであって、けっしてデザインの下書きなんじゃないんだよ、ということは、Web ディレクターと Web デザイナーの双方がよくわきまえてなきゃいけないってことですね。

なんつって、けっこういまだに、あ、調子にのってラフ描いちゃった、っていうことがあるんですよねえ。

やっぱり、一回、ワイヤーフレームなし、っていうのもやってみようかな...。
-----------------
sent from W-ZERO3

2008年8月20日水曜日

グーグル・ロマンチック・ビュー

Google Map みたいな、国土地理院みたいな、ああいう客観的な地図よりも、地元の商店街が作って配ってるやつとか、散歩雑誌の特集記事とかに載っている手書き風のやつとか、歯医者や飲み屋が自分のところにたどり着かせるために作った略地図のほうが、実用的にはよっぽどわかりやすかったりしませんか。

そういうのは、目的やテーマで絞りこまれた主観にむけて、適当なデフォルメが施されているわけですよね。それが人をその場所に連れ込むための工夫だし、またそこに行こうとしている人たちに向けてのサービスとしてあるわけです。

そう考えると、げんに目の前に存在するこの世界へのアクセシビリティをよりいっそう向上させるための営みとして、Google Map から Google Street View へ発展するような方向性を突き進むっていうのもいいけれども、そうした、心理的で便宜的な地図の収集とか、そういう地図のソーシャルな制作の促進っていうのもあっていいんじゃないでしょうか。

たとえば、途中まで Google Map でがーっと絞り込んでいって、ある程度の縮尺まできたら、西荻アンティークマップに表示をきりかえるとかね。

グーグル・ロマンチック・ビューとかいって。べつに Google じゃなくてもいいんですけど。

ちなみに、西荻アンティークマップってのは、JR西荻窪駅の北側に隣接する交番でもらえます。いや、今はどうかな。少なくとも10年前はもらえました。

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

2008年8月19日火曜日

半年くらいかけてゆっくり遊ぶ大人の人生ゲーム

囲碁の対局をメールでやってる人たちっているんですよね。テキストで器用に盤面を描いて碁石を置いて。で、お互いに自分の番で一手だけ碁石を動かしてメールを送信する。気が済むまで長考してよくて、一局終わるまでに一年くらいかかることもあるそうです。

一手一手指すごとのメールのやりとりには、お互いの作戦や戦況についてのコメントとともに、囲碁とは関係のない近況報告もあったりして、そのタイム感がなんとも大人なかんじで、その話を聞いたときは、ちょっとかっこいいかも、と思いました。

そういうかんじで、囲碁よりも人を選ばないゲームで、二人じゃなくてもうすこし大勢でできるものがあったら、面白そうじゃないですか?

そう頻繁に会ったり連絡をとりあったりすることもないけど、でも、ときどきは連絡をとってみたいような気もする、そんな大人同士の友達同士の、ゆるーい場つなぎに。

たとえば人生ゲームを半年くらいかけてゆっくりやってみるとかどうでしょう。

2週間おきくらいに、参加メンバーのところにメールがきて。メールに記載されている URL をクリックすると、メンバー専用の人生ゲームサイトにアクセスできる。

ルーレットを回して、駒を進めて、止まったマスの指示に従うのは、ふつうの人生ゲームと同じなんだけど、ちょっと違うのは、

・コース全体はみわたせない。どんなマスがあるのかはやってみないとわからない。

・誰がルーレットをまわして、いくつ進んで、どのマスに止まったかは、全員にメールで知らされる。

コース設計にもよりますが、それだけで大笑い、という場合もありそうですよね。

・ルーレットを回せるのはメールを受け取ってから3日以内。

・同じく3日以内は、メンバー全員宛のコメントメールが送信できる。

なんかいつでもできるってことになっちゃうと、だれちゃうような気がするんですよね。ときどきオンラインで小さなイベントがあるってかんじがいいかな、と思います。

でも、メンバー全員のマスの移動履歴と、現在の所持金、家族構成なんかの情報と、次回のルーレットデーがいつなのかはいつでも確認できるようにしたほうがいいですね。

・止まったマスの指示で、ときどき、収入と引き替えに、あるいは支出の免除と引き替えに、リアルで対応しなくちゃならないような課題が出される。「今一番大事なものの写真をアップしなさい」とか。

そういうのがあって、ネタになって、ちょっと盛り上がれると、そういう寸法です。

・メンバーがオリジナルの秘密のマスを一人3個ずつくらい設定できる。誰かが止まったら、このマスは○○さんが作りました。と明かされる。オリジナル秘密マスは、ゲームの途中でも好きなときに作成できる。

たしか、結婚記念みたいなかんじで、オリジナルの人生ゲームを作れるっていうサービスを、タカラでしたっけ?メーカーがやってるんですよね。でも、そんなあとあと始末に困るような恥ずかしい盤面を作るよりも、こういうふうに、ネットでやれるようにしたほうが気も楽でいいでしょ?とか思うんですけどねえ。

まあ、といったかんじで、たとえば久しぶりに地元の友達で集まって盛り上がったりしたときなんかに、じゃあっていって、途中で飽きるかもしんないけど、ためしにこのメンバーでしばらくやってみるか、なんてね、そういうふうに遊べるケータイ向けの Web アプリです。

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

2008年8月18日月曜日

目標を整える仕事

うちの会社の開発チームのリーダーの人に、Web ディレクターにどんなパフォーマンスを期待するかと聞いてみたところ、なにはともあれ、まずはプロジェクトの目標を整えるのに力を注いでほしい、といわれました。

目標を整えるーーー目標を設定するではなく、整えるです。なるほど、その言い方は確かに、Web ディレクターの仕事の本質をついているかも知れません。

目標の設定は、それ自体クライアントの依頼とイコールだったり、ユーザーニーズの分析から導き出されるものだったりして、仮にWeb ディレクター=プロジェクトマネージャーだったとしても、けっして専権として行えるものではないでしょう。

ただ、そういう目標は、そのままじゃプロジェクトの中では取り扱いにくいので、進め方に応じて小分けにしたり、小分けにしたのに優先順位をつけたりするわけですよね。

つまり、目標を作業計画とスケジュールに変換するわけです。そこらへんから、目標を整える、って仕事がはじまるんだと思います。

具体的には、Webサイトなら、まず企画やコンテンツ要求の分析から、ワイヤフレームの作成を経て、コンテンツとレイアウトパターンの種類と数量を数え上げる。

Webアプリなら要求定義をやって、ユースケース記述とアーキテクチャの設計を経て、開発のタスクを数え上げる。

それで、それぞれの作業に要する正味の工数を見積もっていきますね。で、一方でリソースの調達でやりくりしつつ、作る順番や確認をとる順番を論理的、合理的に考えてスケジュールを組んでいく。

これをやるには、開発やデザイン、その他、プロジェクトに参加する各種のエキスパートの専門領域のこともひととおり理解して、なにをやったらどれくらいの時間とコストがかかるのかを知ってないといけないですよね。

もちろん、彼らと相談しがら話を進めるんだけど、彼らがいってることが理解できないとどうにもならない。

それから、そうやって目標を小分けにしながらプロジェクトを進めていくうちに、えてして作戦が複雑になりすぎたりして、途中、作業手順の勘違いなんかでチームワークが機能しなくなったり、それこそ目標自体が見失われちゃったりする。

そこのところをいつもチェックして、本来の大目標に照らして、正しい軌道を維持してかなきゃいけない。これも、目標を整える仕事のうちですね。

これをやるためには、開発プロセスに関する議論が参考になりますよね。アジャイルとか、エクストリームプログラミングとか。ミーティングのやり方、プロセス管理の仕方。このへんの話って、開発に限らず、いろんな仕事に応用できると思います。

あと、場合によっては、どうしても当初のスケジュールを守れそうもないときがありますね。そういうときは、どうしてそうなってしまったのかを調べて原因を明らかにしつつ、リスケ、リソースの補強、リリース計画の縮小や段階化などの手を打ってかなきゃいけない。各方面に状況を報告し、謝罪し、対策を提示し、協力を要請するといったコミュニケーションやネゴシエーションに苦心しつつ。

ようするに、失敗のリカバリーですね。ここにも目標を整えるという仕事があります。しかし、このあたりを考えると、なんで、この職業を Web ディレクターと呼ぶのかってことを改めて思い知らされますね。

Web プログラマーとか、Web デベロッパーとかいえば、Web アプリを開発する人でしょう。
Web デザイナーっていえば、Web で見る画面をデザインする人。

じゃあ、Web ディレクターって、Web の何に向かって仕事するのかといったら、人ですよね。結局。 人、スタッフ、チーム。だから、彼らについて詳しくならなきゃいけない。開発やデザインの知識も必要だっていうのはそういう意味で、なんですよね。

ようするに、簡単にいっちゃえば、ちゃんと仕事を仕切ってくれ、ということなんでしょうけど、でも仕切るっていったって、ただ生まれつきのリーダーシップとかを発揮されてもどうにもならないんで、やっぱり、たとえば上にあげたような順番で考えてみて、Web ディレクターってものの立ち位置と、要求されているタスクの内容、それに応えるための方法と技術を一度はっきりさせてみないことには、やれんのかっていわれて、やれんのではないでしょうか。

そういう意味で、目標を整える仕事っていうのはとても示唆的で、Web ディレクターの職域を確認するにはうってつけの、いい言葉だと思ったわけです。
-----------------
sent from W-ZERO3

2008年8月15日金曜日

ねんきん特別便のインターフェース

会社で、ねんきん特別便ってのを渡されまして、おおこれか!なんていって、わりとわくわく封を切りました。

開けると、3枚、紙が出てきますね。最初に目につくのは舛添大臣の筆文字の署名、いきなりド頭といっていい位置に。

ふつうの手紙じゃありえないかんじですけど、でも、その紙は、これからやるべき仕事の指示書にもなっているので、舞い上がって三枚バラバラにしちゃっても、あのサインのおかげで、それが一枚目だってすぐにわかるようになってます。

これはインターフェースデザインとしては評価すべきポイントといっていいでしょうね。なんて。

でもね、あとがいけません。年末調整のときも毎度思うんですけど、どうもこう、すんなり書けない。というか、了解して書き始めるまでがもたもたしちゃう。

つまり、全体に、インタフェースというか、情報デザインが悪いんだと思うんですよ。

三枚紙があって、一枚目が指示書。挨拶と作業指示が書いてある。二枚目が確認書で、加入履歴と納付月数集計が記載されている。三枚目が申告書で、履歴の記載もれと現在の個人プロフィールの記入フォームになってます。

で、これでやることといったらですね、要するに加入履歴に間違いがないかどうかの確認なわけですよ。目的は年金アカウントの正規化なわけでしょう。消えちゃったらしい部分を復元するとか、分かれちゃったのを一元化するとか。

そうだとすれば、納付月数の集計なんて、アカウントごとの利用照会の話だから、フェーズを分けて対応すべきなんじゃないでしょうか。げんに、今回もらった紙にもそれについてなんらかの異議を申し立てる方法は提供されていないわけだし。なんでもいいから疑問があったら窓口にご相談ください、とは書いてあるけどね。

なんで、納付月数の集計は削除しましょう。みせるにしても、メインの作業フローに干渉しないように工夫しなくちゃ。

そうして、本来の目的にかなうように考えると、けっこう一枚でシンプルにいけると思うんですよね。

紙面をまず上下に大きく割って、その上部を左右に割ります。その左側に社保庁が確認できている加入履歴を記載して、これを見て足りないと思ったら右側に記入してください、という。で、下半分が現時点の個人プロフィールの記入欄。これだけでいいじゃないですか。

加入履歴の足りない分が書き切れなかったら、一緒についてくる別紙に記入する。そういうふうに嵩むぶんにはいいんだと思います。フレームワークがシンプルで一回頭に入っちゃえば、それを構成する個々の要素のボリュームがあとで増えることになってしまっても、ユーザの短期記憶にそれほど負担をかけることにはならないはずです。

加入履歴欄もおんなじ。あふれたら別紙。メインの紙の上二段下一段の三分割のイメージを逸脱することがなければ、いくら紙が増えても、構造は単純なまま。

それで、インストラクションやヒントは、その一枚の紙の中に、記入者の視線と注意の遷移にそって、適当な場所に書き込んでおく。

Web アプリのヘルプでも、リモートナビゲーションでヘルプ集のページに飛ばすよりも、入力や操作のインターフェースのすぐそばで、オンデマンドで表示されるほうがいいですよね。コンテクストナビゲーションじゃなくて、コンテクストヘルプとでもいうんですかね。

とにかく、封筒開けてたった一枚、上から読みながら、気軽に、それこそ場当たりに答えていけば、記入のしかたに迷うことなく、つるつると作業を終了できる、そういうのにしてほしいですよね。

それがうまくいったら、大臣からのハートフルなメッセージが認められたお手紙なんてのが、もう一枚別についててもいいじゃないですか。もう顔もだして、なんだかいやに神妙な顔しちゃって。いろいろ文句はあるけど、いっちょ協力するからがんばってくれよ、みたいな気にね、こっちをさせてくれるような。

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

2008年8月14日木曜日

マークアップエディタに関する要求

さっきまで HTML のコーディングをしてたんですけど、ある一連のテキストに対して、繰り返し同じパターンのマークアップをしなきゃならない場面に出くわしちゃったんです。

50 個くらいなんで息をとめてダーっとやれるかな?と思ったんですが、途中でだれて、というか最初の数個をやったところでもうこりゃいかんてなりまして、大元の CSV データから HTML コードを出力する Perl スクリプトを書くほうに、作業を切り替えました。

いまさらなにいってんだって話ですけれども、そのとき急に、もうちょっとマークアップに特化したテキストエディタがあってもいいのにな、なんて思いました。

いや、いままでにだっていろんな入力支援ツールはあったと思うんですけど、手をマウスに持っていかなきゃいけなかったり、インターフェースがなんだかかったるかったり、要するに学習曲線の最初の急勾配に配慮しすぎで、どうも使い込む気にはなれなかったって印象なんですよね。

そういうのじゃなくて。

たとえばこんなかんじです。

なにしろマークアップなんですから、マークアップしたい文字列を選択して、その状態でたとえば a と入力すると <a href="">選択された文字列</a> ってなって、カーソルは href の値を入力できる位置に移動している。文字列を選択して 1 と入力すれば <h1>選択された文字列</h1>ってなる。複数行を選択して、shift + l ってタイプすると、各行がそれぞれ <li> </li> で括られてる。

それから、カーソルが < と > のあいだにあるとき、つまり、エレメントの属性を入力する位置にあるとき、当該のエレメントがとりうる属性名の最初の何文字かを入力するとちゃんと補完してくれて、カーソル位置が属性の値を入力する位置に移動する。

プロジェクトって概念があって、プロジェクトにディレクトリや、リンク先に指定したい外部サイトの URL を登録しておくと、それらが入力されうる位置で入力補完をやってくれる。

画像ファイル名を入力すると、width と height を自動で入力してくれたりもする。

とにかくいっさいキーボードから手を離さず、いかに少ないタイプで HTML をコーディングできるか、というのがテーマ。

Dreamweaver では、それに近いようなショートカットキーもたくさん用意されてるみたいですけど、それやりたいがためだけにってのも、ねえ?

もういってみれば、vi みたいなかんじがいいです。いろいろコマンドを覚えなきゃいけなくて、相当とっつきにくいけど、そのかわりなれちゃったらすごいよ、という、いかにも玄人好みで、使えることがちょっと自慢みたいな。

そういうマークアップエディタを使ってみたいです。ありそうですけどね。 firebug についてるエディタとかちょっと近いですしね。どっかにないかな。


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

2008年8月13日水曜日

入門シリーズ

きのう書いたエントリーで、おもわず少年野球入門なんて出してしまいましたが、そういえば、Web サイトでやってみたいもののひとつに、そういう、子供の頃に読んだいわゆる入門シリーズがあります。

ぼくは、書籍の、特に単行本みたいなのは、 Web よりいまの本の形態で流通するほうが読みやすいし扱いやすいと思うんですけど、入門シリーズについては、 Web でやると本とはまた違ったよさが出せるんじゃないかと思うんですよね。

昔の話ですが、Windows95 が出た頃、ぼくは雑誌の編集をやっていて、当時はまだそれなりに珍しかった PC ユーザのお宅拝見みたいな特集をやったりしてたんです。

そのとき取材した人にダンスのインストラクターがいて、彼にこれから PC をどんなふうに活用していきたいかって聞いたら、ダンスのステップのパターンの最小単位を10秒とか20秒とか動画に撮って、それを何百円とかで売れるようになったらいいな、と。

ダンスのテクニックって、最初はそういう短い単位で繰り返して身につけていくものだし、そういうサイズの、いってみれば超ミニな教材を流通させることができるってあたりが、PC ならではだと思うんだよねーとかいってました。

これを聞いたときは確かにそうだなと思って、もちろん記事にもしましたし、その後もおもしろいアイディアだよねって友達なんかにけっこう話したりもしていたんですが、いまやYouTube とかで、そういうサイズの動画の流通なんて当たり前になっちゃいましたもんね。彼のステップがそれで売れるのかどうかはともかく。

で、入門シリーズの場合、そのへんに、Web でやることの合理性がひとつあると思うんです。

それから、なんにしても入門者っていうのは、基本、心細さとともに存在するわけですから、その周辺には、ユーザコミュニティが発生する温床があるはずですし、さらに、入門者におすすめの道具やグッズ、あるいは、関連スポットなんていって、スポンサーも非常に近くにいると思うんですよ。自由にダイナミックにスポンサードを受け入れられる可能性という点も、書籍より Web のほうが有利なところでしょう。

コンテンツのつくり方のイメージとしては、ナントカ編っていろんなテーマでくくられていても、基本的には、書籍でいえば見開き単位のTIPS集だとおもうんですよね。

だから、あの、GoF のデザインパターンとか、サイドメニューで紹介している「デザイニング・インターフェース」もそうですけど、そういうTIPS=ソリューションごとに、いわゆるパターン言語で書くってのはどうでしょうね。

たとえば、

■ソリューション名
■ソリューションの概要
■ソリューションが解こうとする問題
■ソリューションの詳しい解説
■ソリューションの具体例
■注意点、ありがちなミス

こういうフォーマットにしたがって、動画や図版なんかもたっぷり使いながら、ソリューションごとにコンテンツを組み立てていきます。

野球入門なら、内野守備編で、ダブルプレー、二塁ランナーの牽制、ランダウンプレー、かくし球、なんてかんじのソリューションが、上のパターンで解説されてるんです。

そういうかんじで、つり入門とか、マジック入門とか作る。

デザインは、小学館の入門シリーズのテイストをいただいちゃうってのもあるかもしれないけど、ここは、Number とか Tarzan みたいに気取ったかんじでもいいかもしれませんね。

で、ソリューションごとに、いろんな人がコメントを書けるようになっていて、いやその打撃理論はもう古いとか、もう、けんけんがくがくで。

おすすめグッズやスポットのカタログや関連リンクなんかもついて、さらに、そういうソリューションごとのページにスポンサーがついてたりついてなかったりするっていう。バント処理はミズノで、バックホームがナイキとかね。

あと、当然考えられることとして、そういう入門シリーズを制作するCMSを一般に開放しちゃうとか。マグロ漁入門なんて、ド迫力のすごいのがアップされたりして。

.. なんてのができたらいいなあ。


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

2008年8月12日火曜日

テキストのココロ

Web サイトの制作過程で、結構ばかにならない工数がかかるもののひとつに、原稿テキストやデータベースに投入するデータ等の整理や書式変換があります。

そういうものに立ち向かうとき、たとえば、ちょっとだけでも Perl (ローカルファイルが取り扱えて、テキスト処理に向いている言語ならなんでもいいんですけど)が書けて、正規表現がそれなりに使えたりすると、それはまさに身を助ける芸になると思います。

ま、あんまり深みにはまって険しい道に迷い込むと、思いもよらない大けがをして、逆に仕事を増やしたりして、あとでその道のプロたちに生兵法!と叱られたりもするんですが。

ただ、そういうのは、一種の文房具としてとらえるべきだと思うんですよね。Web の制作現場における読み書きそろばんですね。リテラシーです。

結局、なんだかんだいって、 Web って、ユーザに見える部分も、見えない部分も、われわれのような Web 制作プロダクションが影響を及ぼせる範疇に限れば、ほとんどがテキストでできあがっているわけじゃないですか。

そしたら、ムチをふるってこいつをうまく操れるようになることこそが、売れるスキルの第一になるってもんです。

だから、その制作の全行程になんらかのかたちでコミットしなければいけない立場の Web ディレクターであってみれば、そうした文房具を実際に使いこなしながら、テキストのココロをつかむことに少しでも長けようと思って、けっしてバチはあたらないと思うんですよ。

むかし野球少年だったころに読んだ、たしか小学館の野球入門で、広岡達郎がいってました。「上手くなりたかったらゴロの心をつかめ」って。それを読んで子供心にいたく感心した覚えがあります。つかむのはゴロじゃなくてゴロの心なのか!っていって。

テキスト処理は、文字コードの問題やヒューマンエラーの問題なんかがいろいろ入り交じって、いつもとり損なう気まぐれなショートゴロのようなかんじがして、ぼくのような半可通には、やっぱり、その心がつかみたくなってくるもんなんですよね。

Web ディレクターという立ち位置からは、とかく成果物を実際に構成するHTML、CSS、Javascript に目がいきがちで、下手するとそれでうまくなっちゃって、事実上のマークアップエンジニアみたいに使われてしまったりもしますが、それよりも、テキストの心をつかむほうが、はるかに優先すべきことのように思います。

というわけで、ぼくは、Web ディレクターにも、「はじめてのPerl」を一読されることをおすすめします。

はじめてのPerl
http://www.amazon.co.jp/%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AEPerl-%E3%83%A9%E3%83%B3%E3%83%80%E3%83%AB%E3%83%BBL-%E3%82%B7%E3%83%A5%E3%83%AF%E3%83%AB%E3%83%84/dp/4873111269

この本には、そのココロのことが書いてあるように思うんです。
-----------------
sent from W-ZERO3

2008年8月11日月曜日

デザインは誰のもの?

すこし前から、ちょっとしたレポートやパンフレット、長くて新書くらいのまとまった文章を Web で公開したいときに、ブログ、Wiki、その他の CMS よりも、使い勝手のいいコンテンツ制作ツールをつくってみようという社内プロジェクトをやってまして。

ようするに、ありていにいえば、頭から順番に読みたい一連の Web ページを作るのに、インデックスとかページネーションをシステムが自動に作ってくれる、そういう特殊な Wiki ですね。それだけのことなんですけど。

それのシステムイメージの方向づけをみんなでやってたときに、ふと、デザインって誰のものなんだよって話になったんですよ。

当然、ブログみたいに、テーマとか、スキンとかを取り替えられるようにしよう、ということになるんですけど、もし自由に取り替えられるんだったら、どれにするかを決めるのは、コンテンツの提供側じゃなくて、ユーザー、読者の側であるべきなんじゃない?と。

もちろんそれぞれを見分けて、その内容や価値をなんとなくでも感じ取ることができるように工夫が凝らされたコンテンツごとのデザインっていうのは必要です。でもそれは、たとえば iTunes のアルバムアートワーク、つまり、ジャケットみたいなのでいいんじゃないか。

Web デザインでは、デザインが担うそのへんの役割をトーン&マナーとかいいますけど、それを全部、"ジャケット"に閉じこめちゃうと、Web デザインにはあと何が残るんでしょう。

たぶん残るのは、

1、組版

見出しや本文の文字の大きさ、字間、行間野調整、また、画像、動画、表その他のコンテントの配置

2、インターフェースデザイン

各種ナビゲーションを構成するリストやボタン、また、それらをまとめた"操作パネル"のトータルなビジュアルデザイン

なんじゃないかな。で、そういうふうに分解して考えてみると、たとえば、1、については、新書の場合、タイトルに関係なく、ひとつのシリーズでみんな共通しているし、2、については、いってみれば、iTunes や Windows Media Player とかの再生、停止、一時停止、早送り、巻き戻しの各種のボタン類と同じようなもので、1、2、ともに、かならずしも、コンテントそのものや、コンテンツ提供者のブランドに依存しなくてもいいように思えてきます。

そうすると、それらは、それこそ Windows Media Player でのスキンのように、あるいは、そうだ、ブラウザのスキンやテーマのように、ユーザが選べるものとして提供されてもいいんじゃないかなあ、と。

もちろん、すべての Web サイトがそうである必要はないんだけど、たとえば、Uniqlock に代表されるような、それひとつでチラシみたいなサイトとか。でもフィードリーダーで次々読まれるコンテンツにおけるデザインというのは、そういうふうに考えられていってもいいんじゃないかな、なんて、ちょっと思ったわけです。

デザインをなんでもかんでもコンテンツ提供側が決めるっていうのは、印刷物の生産と流通におけるテクノロジーの制約の名残りに囚われすぎ、みたいなとこがあって、ライブでプロセスできて、パーソナライズもできて、データとスタイルの分離もできてってところでは、そこんところを一回疑ってみてもいいんじゃないの、って、まあ、そういうお話です。
-----------------
sent from W-ZERO3

2008年8月9日土曜日

スネ夫の夢に出てくるスネ夫

あるそれなりにえらい人同士の対談のページを制作しました。二人が笑顔で並んでいる写真に、対談中に口にされた決めゼリフをあしらってタイトルバナーにしたんですけど、デザイナーが気を利かせてくれて、黄色い歯を白くしたり、顔のてかりを抑えたり、寝癖のついた頭を整えたりしてくれました。

よく、アメリカのグラビアだとかでは、そういう補正がすごいっていって、その Before / After を暴露(?)するようなページがありますよね。あと、友達の奥さんがアルバイトで、誰だったか、タレントかミュージシャンの写真集のレタッチの仕事をして、毛穴だのシミだのを消しまくったとかいってました。でも、自分の仕事でそういうのをやったことはなく、今回もあのおっさん二人の見てくれをよくしてやろうなんて思ってもみませんでした。

それで、すっかりつるつるぴかぴかになった御大お二人の笑顔に見入りながら、顔認識とかの写真処理技術がもっと進んで、そういう美顔美肌補正みたいなのまで自動でできたら、面白いことになりそうだなーと思ったんです。

自分の顔を写メで送ると、今よりそうね、1.5倍くらい美男美女になった自分の顔が返ってくるっていうの、あったらはやりそうじゃないですか。どんな顔でも、目元がぱっちりして、すーっと鼻筋がとおって、白い歯が印象的な細面になっちゃって、なんかぜんぜんちがうんだけど、でも、たしかに自分だ、いや、ありえないけど、ひょっとしたらありえたかもしれない自分だ、とかわけわかんないこといって、うっとり。なんて。

で、サービス名が「スネ夫の夢に出てくるスネ夫」っていうの。

のび太が昼寝しすぎて夜眠れなくなっちゃって、あんまり退屈だからってドラえもんに他人の夢を覗けるというなんとも悪趣味な機械を出してもらうんですよね。それで、みんなの夢を見てまわるんだけど、スネ夫の夢に出てくるスネ夫がすごいかっこいいの。のび太も「これがスネ夫!?」なんていって。たしか、みんなが宿題が難しいって泣いてるところへ、そのイケメンスネ夫が登場して、スラスラーと問題を解くっていう夢で、もう、どうしようもないですね、スネ夫。なんか、かわいそうですらある。

まあ、それはともかく。サービスの価値というか意義としては、プリクラに近いのかな、とも一瞬思ったんですが、あっちはとばして、ぼかして、あいまいにしてですからね。「スネ夫の夢に出てくるスネ夫」は、はっきり、くっきりで、1.5倍ですから。それは、かわいいというより、たぶん気持ち悪い。だから面白いんじゃないかなと思うんですけど、どうでしょう。

できないかな、自動で。

2008年8月8日金曜日

CSS 書いてフローしよう

Web ディレクターだなんつって、ディレクターっぽい仕事はすっかり若い衆にまかせて、自分は HTML+CSS+Javascript ばっか書いてます。特に今年はそういうめぐりあわせのようで、いろいろ抵抗も試みたんですが、これといって成果はあがらず、しばらくはおとなしく運命に甘んじて過ごすことにしました。

なんで、ちょっと CSS まわりで地味な話を。

会社のHTML+CSS のコーディング規約を考えてくれた人の提案で、CSS で背景画像を指定する部分は、他の定義と分けて、専用のファイルに記述するっていうのがあって、最初はなんでそんなことしなくちゃいけないんだろうと違和感があったんですが、素直に従ってやってみると、なるほどそれはいいアイディアだったんだねって、最近は思うんです。

というのも、HTML+CSSをコーディングしてて、いわゆるフロー状態っていうんですか、のってるかんじでスイスイいくのを阻害するのって、背景画像関連の定義なんですよ。少なくともぼくの場合は。

具体的にいうと、画像を探す、サイズを調べる、ファイル名をタイプする、この3つの仕事が、テキストエディタとブラウザの往復から遠くかけ離れてるんですよね。頭や心のありかたも、ここでスイッチしちゃう。かんじとしては、その3つはあきらかに割り込みなんです。

Javascript 書いてるときは、それがなくて、けっこうすぐフローに入れます。だから、正直にいうと、Javascript 書いてるときが一番たのしいです。ディレクターなんて、いってみりゃ全部割り込みですからね。一日中打ち合わせでしゃべりすぎて熱にうかされたようになってるときは、フローかもしれませんけど。

まあ、とにかく、だから、そういう割り込みな部分をまとめて、それだけに集中していっきにやっちゃう時間をつくろう、そういう意図があったんじゃないかと。いいだしっぺは、そこんところをちゃんと説明してくれないまま辞めちゃいました。こっちもそこまで頭がまわらず、いるうちにちゃんと聞けなかった。で、今になって、じゃないか、なんていってるわけですけど。

ただ、せっかくそういうふうにしてみても、やっぱり、ページごと、ページを構成するエリアごとに、順番にスタイルを定義していくなかで、割り込んでくるんですよね。なかなか、背景画像の定義だけまとめてっていうのは、難しいです、実際には。

それでちょっと、地味に思ったんですけど、現状、すでにガイドラインにしたがって、CSS ファイルは、カスケーディングなりのディレクトリ構造の中に配置されてて、CSS で使う背景画像も、規則にのっとったディレクトリにまとめられているんです。

そしたら、それをあてにして、Perl + ImageMagik とかでスクリプトをまわして、画像ファイルを総なめにして、ありえそうな背景画像の指定を自動で書き出しとけばいいんじゃないか。

たとえば img/hoge.png という画像があるとすると、img/bgimg.css に次のような定義が自動で書き出されるんです。

hoge-fix {
/* ボタンとか */
display: block;
width: 100px;
height: 100px;
background-image: url("hoge.png");
background-repeat: no-repeat;
}

hoge-lt-nr {
/* 左上隅に見せたいアイキャッチとか */
background-image: url("hoge.png");
background-repeat: no-repeat;
background-position: left top;
}

hoge-rt-nr {
/* 右上隅に見せたいアイキャッチとか */
background-image: url("hoge.png");
background-repeat: no-repeat;
background-position: right top;
}

hoge-rx {
/* 横に繰り返すパターン */
background-image: url("hoge.png");
background-repeat: repeat-x;
}

hoge-ry {
/* 縦に繰り返すパターン */
background-image: url("hoge.png");
background-repeat: repeat-y;
}

hoge-r {
/* タイル */
background-image: url("hoge.png");
}

で、ここに定義されたクラス名を適宜エレメントに指定するもよし、それだと、特定のスタイルに密結合しすぎというなら、コピーして、文書構造やセマンティックに忠実なセレクタの定義にもっていくもよし。

これで、さっきあげた割り込み的な3つの仕事のうち、2、3、は軽くなるでしょう。画像は探さなきゃいけないけど、テキストエディタとブラウザの往復の外に作業がはみ出すことは、だいぶ減るんじゃないかな。

どうでしょうね。今やってるコーディングにケリがついたら、ちょっとやってみようと思います。

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

2008年8月7日木曜日

うるさい!タイトルバナー

最近 Web みてて思うんですけど、デコラティブなタイトルバナーってあんまりないですよね。

サイト ID のことじゃなくて、サイト内のセクションや特集ページだとかで、文字を飾って、背景にもいろんなビジュアルを盛って、ゴテゴテっとしたやつ。

実は、必要があって、そういうデコラティブなタイトルバナーをデザイナーに発注するってことになって、なんか参考になるのはないかなと、ほうぼう見てまわったんですけど、Yahoo! 旅行の特集ページくらいしか見あたらなかったですよ。

逆に、最近けっこう多いなと思う手は、タイトルそのものは、もうテキストで済ます、あるいは画像にするにしても、ほとんど飾りのない太ゴシックとかにしておいて、周辺に、象徴的な写真やイラストを添えておくというやり方。

cnet/zdnet とか、IT 系ニュースサイトの特集ページは、むかしからそんなでしたよね。R25 とかサイゾーのちょっと企画っぽいページでも今じゃそうなんですよね。あと、ちょっと違いますけど、あからさまに素材集っていう写真を記事内容にあわせて毎度選んでくる GIGAZINE のやり方もなんだか印象深いものがありますね。

そういうのは、もちろん、毎日たいへんな量の更新を行っているなかで、コストとの見合いで自然に選択されてきたものなんでしょうけど、ユーザにとってみてもそれで充分、というか、むしろ、それ以上はうるさいっていうのがあるんじゃないでしょうか。

特に検索エンジン、フィードリーダーのリストからタイトルに惹かれて訪問してくる者にとってみれば、再びタイトルをどーん!とやられても、もうわかったよ、みたいなかんじでしかないかも。

いや、そもそも、これはハイパーテキストのメディアなんであって、なんかしら文言をクリックしてユーザはそこにやってくるわけです。そこの場合タイトルっていうのは、行きたい場所にちゃんとたどり着けたことがわかるフィードバックとしてあればいいだけなのかもしれない、なんていうのはちょっと極端かな。

でも、よくいわれることですが、雑誌やテレビや看板なんかと違って、目立たなければ素通りされてしまうっていう質のものでもないわけで。

広告バナーは、そっちなんですよね。だから相変わらずですよね。最近地味になってきた、なんてことはない。まったくない。

広告バナーはクリックするもの、つまり、情報を引き出すもので。それでいったらタイトルバナーのほうは、クリックによって引き出されるものですもんね。

この引き出すものと引き出されるものの区別は結構大事かもしれません。

広告バナーとタイトルバナーの内容がまったく同じ要素で構成されるってことは実際にありえると思うんですけど(Yahoo! 旅行の特集がそうですね)、でも、そういうふうに、ユーザ体験の全体をちゃんと追って考えていくと、おんなじバナーでも、それが引き出すものなのか、引き出されるものなのかによって、デザインプランも変わってきますよね。それぞれに要求される機能が違うわけですから。

たとえば、旅行なら、最初に旅情をかきたてる、引き出すほうのバナーのタイトルはド派手にいきたいですよね。当然。でも、それで引き出されるほうのタイトルはおとなしめでよくて。

ただし、その直ぐ下のリード文や本文の見出しでは、旅情をヒートアップさせなきゃいけないから、引き出すほうで与えた効果をさらに展開したようなトドメの一発を派手にくれてやりたい、とか。

つまり、引き出すほうと引き出されるほうでほとんど同じもの2回みせてどうするよ?ってことですね。展開しようよ、と。それから、タイトルバナーのデコレーションで精も根も使い果たしたってかんじで、かんじんのボディはごにょごにょごにょみたいなのもだめですよね。これも結構多いかもしれない。

なんて、そんなことを考えつつも、仕事はもう動き出してしまっていて、いまさら転回するのはいかにも難しそうなかんじでしたので、発注してしまいましたよ、デコラティブなタイトルバナー。Yahoo! 旅行の特集とか参考にしてね、とかいって。

つぎはがんばろう。
-----------------
sent from W-ZERO3