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

2008年8月6日水曜日

Google Street View の”解像度”をあげる話

Google Street View にはほんと、びっくりしましたね。日本中に電柱をたてて電気をくまなく行き渡らせようって決めたのとたぶん同じくらいの気合いがはいってんじゃないかって。

あまりにも細かい路地までカバーされてることもあって、今は、あれになにが写り込んでるかで盛り上がってますけど、たぶん、面白くなるのは、何を写り込ませるかってほうじゃないでしょうか。

写り込ませるというより、あのパノラマをみんなの写真で補足していくっていうか。街のあらゆる地点から見た四方八方の風景を、ソーシャルなフォトアルバムの台紙として使う、みたいなイメージ。

たとえば、ラーメン屋の入り口にむかって、その店のラーメンの写真を添付する、桜の木を見上げた角度に、その桜が満開の写真を添付する、終電間際の駅前のそこのところでいつも歌ってるにいちゃんの写真を添付する、川が氾濫した時の様子、昼時、行列がどれくらい長くなるか、へんてこな看板のアップ、たんなる記念撮影、そんなふうにして、みんなでよってたかって、Google Street View の、事実上の"解像度"を上げていくわけです。

写り込んでまずいものを報告するインターフェースがありますけど、そういう補足情報の登録もおんなじインターフェースでいけそうですよね。写真だけじゃなくて、ムービーも、テキストも、URLも。そうしたら、セカンドライフなんかより、よっぽど面白くなりそうだけどな。セカンドライフやったことないけど。

もちろんプライバシーとか、さまざまな権利関係でややこしい問題がつきまとうでしょうけど、おおきな方向性としては、そっちが面白そうじゃないですか。もう考えられていて、きっと最初の試みはじきに始まるでしょ。どうでしょう。

それで、そういう活動が盛り上がって、かりに10年、20年、50年つづいたら、それはものすごい歴史的資料価値が出てきますよね。ケーブルテレビでときどきGメン75とか見るんですけど、ドラマのスジなんかどうでもよくって、昭和50年代の東京の風景を見るのが楽しかったりしますよ。これ渋谷かあ!とかいって。

あ、タイムカプセルもいいかもしれませんね。写真貼付するんだけど、今すぐは見られなくて、20年後に公開されるとか。いわく因縁ありのその場所でね、あんなことやこんなことを。それはやばいか。


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

2008年8月5日火曜日

身に沁みてわかった REST

あるクライアントのケータイサイトでのお話です。

ユーザはサイト上に自分のポートフォリオを作れて、サイトで取り扱われているアイテムで気になるものがあれば、そこにどんどん追加していけるという機能がありまして。

アイテムにはそれぞれ詳細情報のページが用意されているんですけど、そのリンク集を、サイト上に作っておけるってわけですね。

そのアイテムの性質上、まあ、何度かその詳細情報を確認したくなることはありえて、でも、そのたびに検索するのも面倒臭いだろう、と、一方、そのサイトはキャリアの公式メニューに入ってるんで、端末 ID ベースでそうしたパーソナライズを行うんでも、ユーザに手間をとらせることもないからいいんじゃない、ということで。

で、それはいいんですけど、キャリアの公式メニューの検索窓にあるアイテム名を入力して検索すると、そのアイテムの詳細ページではなくて、ポートフォリオのページがヒットしちゃうってことを、今日、クライアントからつっこまれました。

検索結果から、そのリンクをたどって、ポートフォリオのページにアクセスすると、前にこのサイトでポートフォリオを作ったことがあれば、かつて登録したアイテムの一覧が、そうじゃなければ、ポートフォリオにアイテムを登録しましょう、ってなインストラクションが表示される。だから、たいてい、検索キーワードとはまったく関係のないページが表示されてしまって、これはいかんですね。

でも、なんで、そんなことになっちゃうの?

まず、キャリア公認のロボットって、ちゃんと端末 ID つきでクロールしてくるわけですね。

それで、ポートフォリオにアイテムを追加するリクエストを、フォームじゃなくて、リンクで書いてたんですよね。だから当然そこもクロールしてくれて、すると、クロールしたときに、ロボットの端末 ID でポートフォリオができちゃってた。

そのあとで、ポートフォリオのページもクロールして、そこは、前にロボットが登録したアイテムが表示されている状態ですから、そのアイテム名がキーワードになってインデキシングされていたと。

おそらく、ざっと、そんなかんじだろうなと、パートナーのプログラマーが解説してくれました。

ぼくは、ロボットが自分のポートフォリオを拵えてるなんて、いやーなかなかファンタスティックですなあ、なんてのんきなことをいってたんですけど、プログラマーは、いやいや、これは、本来 REST でいえば POST でやるべきポートフォリオへのアイテムの登録を、デザインの調和の問題とかいって強引にアンカータグで書いて GET にしたのがいけなかった。GET メソッドは、いうまでもなく URI で特定されたリソースの取得、これをロボットが取り込もうとするのは当然のこと。ちなみにこの場合、ポートフォリオへの追加が PUT ではなく POST なのは、リクエスト側が持っている情報が追記分にすぎず、それをもってポートフォリオ全体を差し替えることはできないから。つまり、データ操作機能をあらわす URI に POST メソッドでデータを引き渡し、追記作業を依頼すべきだから。まあ、そもそも PUT メソッドなんてキャリアがサポートしてないんですけどね。といったような意味をたぶん込めて一言、やっぱりあそこはふつうにフォームで POST にしとくべきでしたね。といってました。

ほんとは、あとで、イントラに公開されている彼の業務日誌 Wiki に、この件について以上のような REST 的な問題が指摘されているのを読んで、いやあ今回はいつになく身に沁みて REST のことがわかっちゃったなあ、と、しみじみ感じ入ったのでした!

ちなみに、今回の件については、robots.txt で対応することにしました。
-----------------
sent from W-ZERO3

2008年8月4日月曜日

ポケットに入れておくギター

このあいだ27時間テレビのエンディングで、Begin の人が歌ってるのみて思い出したんですけど、ボーカルの人が開発した楽器ってありますよね。沖縄の三線とギターをあわせたようなやつ。

これですね。

一五一会
http://skysky.eco-sky.net/ichigoichie21/

弦が5本で、チューニングが三線に似てて、いろんなコード鳴らすのに、押さえる弦が少なくて済むという。

たしか、キース・リチャーズも、弦5本で、全弦開放でいきなりGが鳴らせる、オープンGチューニングとかいってやってたと思いますけど、きっと、それの影響もあるんでしょうね。

それはともかく、その、Begin の人の一五一会から、またさらに思い出したのが、あの「えいご漬け」で有名なプラトが、その「えいご漬け」の大ヒットの後、いったい次は何をやるんだろうと注目を集めていたところへぶつけてきた、これ。

弾いて歌える DS ギター
http://www.dsguitar.net/

今のDSベースの学習ソフト市場の活況を先取りしていた、まさにスモールeラーニングの元祖とでもいうべき「えいご漬け」を作って、ぼくも eラーニングの制作に携わっている者の一人としてプラトにはかねがね畏敬の念を抱いていたんですが、その次がこのDSでギターっていうんで、もう完全にやられましたね。ぜんぜん違うのを出してきて、でも、スモールってところでは一貫してて。かっこいいなあ、と。いや、どっちも買ったわけじゃないんですけどね。すいません。でも、すげー、と声が出たもんです。

で、DSギター、これは、使うコードをプリセットしておいて、十字キーで、曲の進行にあわせてコードを切り替えつつ、画面に表示されている弦をジャンジャカ弾くっていうもので、音もリアルだし、すごく楽しそうなんですけど、もしかすると、そこまでバカチョン化を進めず、もう少し人に努力を要求するような楽器ヅラをしてもいいのかもしれない、とは思いました。そのほうがホビー感も強くなるし、もしかすると、その楽器を習うこと自体、スモールeラーニングたりえるんじゃないか、なんて。

でも、じゃあ具体的にどうすれば、っていうのはなかったんですけど、テレビで Begin をみて、思ったわけです。ピックでストロークするほうを自動演奏にして、画面にはネックのほうを表示して、たとえば、一五一会のチューニングで、弦を押さえて演奏するのはどうかなと。DS よりも iPhone のほうがいいかも。フレットの移動も指でシュッと画面をこする、いわゆるフリックでね。

いまちょっと w-zero3 で手のかたち、指のかたちをやってみたんですが、ちょっといいかんじかも。

ギターのネックだと思って左手の親指をデバイスの裏面にあてがって、左手のその他の指は身体の外に向けた液晶画面の上に乗せます。

本物のギターだと、右手はピックを持って弦を鳴らすわけですけど、そこは自動でやりますんで、この場合の役割は、ネックの上側の端、5弦の上の部分をフリックしてフレットを移動したり、ストロークのパターンの切り替えボタンをタッチしたりするのに使う。自然、デバイスを右側から支えることにもなります。

アコギでコード進行だけじゃんじゃか鳴らしながら適当に歌を歌うのが好きだった10〜20代を過ごしてきたぼくには、なんだかとっても魅力的に思えるんですが、どうでしょうか。ポケットに入るサイズの専用機でもかわいいかもしれないですよ。
-----------------
sent from W-ZERO3

2008年8月1日金曜日

CSS Sprite 失敗

ページの読み込みが速くなる、管理も簡単になるってわけで、遅ればせながら、このあいだある案件ではじめて CSS Sprite に挑戦しました。

CSS で指定する複数の画像を、でかい一枚絵の中に適当に配置してまとめておくっていう、あれですね。

でも、すっかり舞い上がっちゃって、いろいろしくじりました。

最初に、まず、全画像入りの一枚絵を作るような意気込みでのぞんじゃって、いやいやいや、gif と jpg は一緒にできないよって、軽くがっかりしてる自分にあきれました。アホですね。でも、それだけじゃありません。

1、可変サイズのとこは無理!

これもはじめから気づくことができないのはどうかしてると思いますが、CSS Sprite が使えるのって、大きさが決まってるHTML エレメントに対する no-repeat な背景画像としてのみなんですよね。

あたりまえだけど、タイル状に敷き詰めるようには使えないし、サイズが子要素に依存するエレメントの上端や左端だとかに no-repeat で置くなんてこともできない。エレメントが大きくなると一枚絵の隣の画像が見切れてきちゃたりして。

それに気づいて、一枚絵からいらない画像を次々はぎ取っていったんですけど、けっこうその手のが多くって。しかも、せっかく採取した座標は惜しいから、イキのやつはそのまんま、そしたら、だだっぴろい空間にぽつーんぽつーんと無造作に画像が散らばった、スカスカの一枚絵になっちゃいました。見られたらはずかしいです。

2、コンテンツまで Sprite すんな!

あと、調子にのって、コンテンツとしての画像まで入れちゃって。CSS なんてコンテンツと装飾を分離するためにあるんであって、スタイル切って消えちゃうのが装飾、まだ見えてるのがコンテンツってわけなのに、スタイル切ったら文字しか残らなかったよ! CSSバカの仕事。

3、せっかくの CSS がだいなしだ!

ね。コンテンツとスタイルの関係はなるべく疎であるべきなんで。だから、エレメントの id や class の名前は、文書構造上の論理名だったり、セマンティックなものにしとけって、これはもう鉄則。それなのに、同じ一枚絵の画像を背景に使うエレメント全部に文書構造もなにもなく、みんな同じ class 名を与えちゃって、その class のスタイルの定義として、一枚絵の画像パスを指定してる始末、こりゃ同じこと何回も書く手間が省けていいや、なんて。おいおい、それじゃ特定のスタイルに密結合しすぎだよ。CSS をはじめた頃に抱いたあの志、もう忘れちゃったの?

なんてな具合でして、誠にお恥ずかしい限りです。自戒をこめて、ここに告白しておきます。


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