ロゴの解剖

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

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

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

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

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

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

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

それはともかく。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ネットのニッチ

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

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

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

検索エンジンの出始めでも、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();

以上です。

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

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

文房具としての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

数字とグラフで見る自分

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

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

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

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

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

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