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

さっきまで 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

入門シリーズ

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

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

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

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

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

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

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

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

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

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

たとえば、

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

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

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

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

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

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

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

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

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

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

テキストのココロ

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

デザインは誰のもの？

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

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

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

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

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

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

たぶん残るのは、

１、組版

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

できないかな、自動で。

CSS 書いてフローしよう

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

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

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

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

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

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");
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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