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