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