2008年8月アーカイブ
小説家は出版される本の3倍以上の文字を書き、推敲を重ね、そぎ落とし、研ぎすまされた文章を作品として発表するらしい。最近の小説家はどうなのかは知らないけれど、ヘミングウェイとか明治、昭和の小説家とかは、なんかそんな風な書き方をしていたらしい。
ぼくは最近小説を読まなくなって、最後に読んだ小説は村上龍の「半島を出よ」で、3年くらい前になる。
基本的にだらだらした感じの文章が好きで、紙いっぱいに文字がならんでいて、いつまでもはなしが終わらない感じの文体が好きで、最近の作家だと、舞城王太郎とかが好き。最近の作品は読んでないけど。
具体的には明治とかの暗くてドロドロしたはなしが好きだけど、昼ドラはどうにも好きになれない。
Webの文章は散文的で、文章としての美しさはないような気がする。叙情的な文章はむしろオナニーを見せられているようで、気持ちが悪いことすらある。検索を前提としているのだから叙情詩なんて無意味だろうし、だとするとWebはそういった目的の媒体としては成熟できないのかもしれない。
ケータイ小説というのは味気なくて読む気がしないけれど、最近の若い世代というのはむしろ散文を好むらしくて、何かヒットして映画化したりする。はなしとしての灰汁がなくて、なんかキレイにまとまった文章で、ケータイだから横書きで、心情よりも視覚にうったえかける表現が多いようなイメージがある。
かといって最近の純文学が読みたいとも思わなくて、それはやっぱりなんかはなしが抽象的すぎて、好みに合わない。別にぼくは文学のことなんて全くわからないし、ただの好き嫌いだけど、なんかもっと具体的なはなしのほうが読む気になる。
去年、ばあちゃんが死んだ時に、部屋から遺品にと拝借した有吉佐和子の「恍惚の人」がおもしろくて読んでたけど、結局途中までで読み終わってない。
そう考えると別に小説の内容ではなくて、ただたんに小説を読むのがメンドウになっただけっぽい。
デジタル化された情報はやっぱり淡白な気がする。別にビットだからとかいうのではなくて、その目的が実用で、叙情の入り込む余地がないのだと思う。ムリから叙情をネジこむと、なんか変な感じになる。やっぱりひとは触感のあるものが好きで、紙に印字された文字には感情が入り込む余地があると思う。
合理的なアーキテクチャに基づいた情報は、実用的で、大きな利益を産むのだろうけど、情報と知識は違うくて、情報がWebにあるからひとの頭の中には知識はいらないというわけではなくて、知恵は知識から産まれるのだろうから、知らないことを識るということは、知性を磨いていくということだと思う。どんなにネットワークは張り巡らされたところで、人間そのものがネットワークにつながるわけではないし、つながるべきでもないだろうから。あくまで、ネットワークはただの倉庫なのだから、倉庫から必要なものをとりだして、それをどう使うのかという知恵は不可欠になってくる。電卓があるから計算ができなくていいというのは、人間が道具の奴隷になるというのと同じことで、あくまで道具は道具して使うもので使われるものではないという基本的なことがわかってないひとがたくさんいて、なんでもコピペですまそうとするきらいがある。
でもコピペでつくったものに価値なんてまるでない。たとえ不細工でも自分でつくったものには一定の価値が生まれるし、そこから次のステップをつくりだすための反省もできるし、なによりそういうのは合理化とは呼ばない。
楽をすることは素晴らしいことだけど、それは怠けるのとは違う。コンピューターは楽をするための道具で、怠けるための道具とは違うと思う。そもそも人間は識るということに快楽を感じる生き物なのに、識るということを放棄してしまったら、それは損をしているということになると思う。
そもそもWebデザインってのはナンなんだろうか?
プロからすると意味不明なこの言葉について、ほっこりほっこり考える。
Webの目的として考えられるのは集合知、情報共有、自己表現(組織も含む)などであるから、それらのソリューションの一端を担うのが仕事だといえる。
中でも商業におけるWebソリューションにおいて重要な、企業の行う表現というのは、既存の広告という概念ではなく、正しく“表現”という概念でよらえられるべきで、無価値なFlashを、動くという意味不明な理由だけで“ホーム”'(トップ)ページに使用するというは、これはWebサイトをただの看板広告くらいにしか考えておらず、それでは本来得られるであろう利益を喪失してしまいかねない。
なにもFlashが悪いというのではなく、動くということは、逆に言えば動くのを待つ必要があるということでもある。だとしたら、目的を持って訪れる大半の(見込み)顧客に対するアプローチとしては、むしろ時間という概念をもたない通常の画像やテキストのほうが、より確実な方法ではないだろうか。いったい30秒以上“ホーム”'(トップ)ページに滞在するユーザーが何%いるのか、解析してみるとどういう結果がでるのか。情報へのナビゲーションである“ホーム”'(トップ)ページで30秒以上滞在するというのは、むしろナビゲーション設計に致命的な欠陥があるとも考えられる。
では表現と広告の違いは何か?
広告とは不特定多数にたいし、より短時間に、必要最小限の情報を告知するということだとして、表現とは、組織のあり方、商品、サービス、CSRなど、をより具体的に伝えるということだと考えられる。
つまり最も重視するべきは、情報そのもの、そしてその情報にどういったかたちでナビゲートするのか、ということになる。
信用のおけないWeb屋ほど、情報構造、表現手法をないがしろにし、絵でごまかそうとする。
ではWebの視覚デザインの価値はどこにあるのか? それは情報にたいする適切なナビゲーションと、情報アーキテクチャに基づく視覚的構造化にある。
ひとは自らの利益にたいしてのみ金銭を支払うのだから、その利益を以て商品とするべきだというのは、他の業界では当然すぎるくらい当然のことなのに。
生み出された価値にたいする報酬として金銭があり、その金銭がまた新たな価値を産む、というが経済活動のあるべき姿だとしたら、Webデザインのスコープとは、その他のあまねく職業に違わず、価値の創出だといえる。
それにしても最近涼しくなりました。もうすぐ秋ですね。
長いので別ファイルにまとめました。
しかしやっぱりプレーンなHTMLが一番美しいです。なんでみんなわかんないんだろう?
ちなみにhresumeは履歴書とか職務経歴書を記述するためのMicroformatsです。
偶然か必然か。どっちかはわかりませんが、なんか出てきた。
六角レンチとドライバーを借りてなんとか解体してみたけれど、どうにもむかしから物理的な作業というやつは不器用で、ミニ四駆すらまともに組み立てられないぼくです。
案の定二度と再生不可能までにコジ開けられた愛しのMacちゃん。
肚の中はなんかターミネーターみたい。
なんとかハードディスクはとりだして中のデータはバックアップとったけど、その後はウンともスンともいいません。
ご臨終なので、叩き壊して、土に埋めようかと思います(燃えないゴミにちゃんとだします)。

GETの値をXSLTのパスに代入してるだけです。
if(isset($_GET['xsl'])){
$xslPath = $_GET['xsl'];
}else{
$xslPath = "table";
}
8月30日に Web Barbarians Conference 2008 Summer「夏祭り!アドビ特集」powered by CSS Nite があるそうです。
ぼくは他に用事があるのでいきませんけど、AdobeのRIA戦略とかは聞いてみたい気もする。
福岡でもこんなイベントがもっとあって、もっといろんな人があつまるようなセミナー(エンジニアだけじゃなくて)が増えればいいと思う。
Web Barbarians Conference 2008 Summer「夏祭り!アドビ特集」powered by CSS Nite
なんか盆で実家に帰ってて、久々起動させてみたら、モニタがつかない...。
もう4〜5年くらい使ってたし、扱いもあまりよくはなかったので、限界なのねMacちゃん。
ありがという。そしてさようなら。
そんなわけでソッコーでビックカメラにいってiMacを購入してきた。どうも新しいキーボードにはなれないけど、まあそのうち慣れる。
とりあえずハードディスクだけはとりだしたいけど、なんか固いのね。Winだと結構簡単に取り出せるけど、六角レンチとか買ってこにゃならんらしい。
あと環境構築がちとメンドい。まあPHP使えるようにして、あとアプリとフォントをインストールするだけなんですけど、なんかメンドいのよね。
まあ新しいだけあってモニタもデカいしきれいだし、速度もはやいんでいいけど、13万はキツイ。
あとiPodついてる! とか思ったらリモコンだった。このへんのインターフェースって徹底されてるのはさすがApple。しかし、リモコンて、なんか家電だね。
セルがいっぱいあるときとか、の視認性が向上する例のやつです。
イベントはtrにセットしてあるけど、IEのattachEventでthisを渡すと何もかえってこなかった。なのでevent.srcElementをthisの代わりに使ってみたんだけど、そうしたらevent.srcElementに入ってきたのはtrのchild node(thとtdと空白ノード)。仕方なくparentNodeで一回親ノードに戻ってから処理を継続。
Firefoxでは苦もなく動いたけどIE対応がメンドかった。
ちなみに引数は、tableHover("イベントをセットするテーブルのid","マウスオーバーで変更する色")です。
それにしても最近暇。
たしかに最近Flashとかでビジュアライズされたりだとか、ゲームができたりとかしてはいるけど、それはまた別の可能性というか、情報を取得する。という意味とは異なる使い方としてみれば、やっぱ携帯の方が情報のツールとしての認識が強いような気がする。
パソコンのWebサイトを作ると、そうしても絵のほうに目がいきがちで、コンテンツのクオリティよりもビジュアルのクオリティにばかりに右往左往するような気がする。
ここの色がどうだとか、ここに模様を入れろとか。でもそんなことはデザインのスキームのはなしなので、へたに素人が口をだすと設計が崩れてしまいかねない。むしろ文体が統一されているかとか、この概念に対する単語、送り仮名はこれに統一するとか、ここの表現はこの言い回しで正しく伝わるのかとか、ナビゲーションを形容詞で統一するとか、そういったことのほうが大切だったりする。
そういった意味では、パソコンからケイタイへのシェアの移行も案外悪いことじゃないのかもしれない。
ただどうにもケイタイはXMLがよめなかったりだとか、通常のHTMLが使えないとかあるので、その辺の問題さえクリアしてくれれば(スペック的にはもう問題ないような気がしなくもない)、ぼくももっと携帯コンテンツの制作のスキルを磨いていきたいとか思う。
別にActionScriptのバージョンだとかJavaScriptへの対応とかは後回しでもいいので、構造化データに対する対応に注力して欲しい。そっちの方がユーザーの求める情報により的確にナビゲートすることが可能になるだろうし、そうすれば携帯端末としての意味もより鮮明になってくるだろうし。ほいで、それを利用したサービスを提供すれば、シェアだってのびるだろうし。
けっこう便利だけど、検索とかで欲しい情報にたどり着きづらいケイタイ。なんか今までの検索とは別の、ひたすら実用性のみ追い求めるとか、そんな検索サービスがでれば、もっと使うのラクなのに。とか思う。漠然と。
主な変更点は以下の5点です。
- Micorformatsの記述に合わせてid class名を大文字区切りから"-"区切りに変更
- CSSの設計を変更(common.cssとpages_layout.cssをskin.cssに統合)
- default.cssをreset.cssに名称変更。
- Templateを廃止。DesignModuleに統一。
- Microformats reference 追加
未来、というか一部で既に現実化されてる話なのだけど、こりゃあ便利、というはなしなのでちょっと紹介してみる。
つまりある一定の規則にもとづいて構造化されたデータは、他のアプリーケーションやWebサイトでの利用が可能になり、そこから生み出される利益は計り知れないというはなし。
しかもそれはたいしたコストもかからず(利用する側は)、導入も簡単なことで、だけどそのためにはより多くのひとの参加が必要だったりする。
たとえば登録されているすべてのWebサイトで、住所の情報が同じ構造でマークアップされていた場合、プログラムを使用し、すべてWebサイトから住所の情報を取得して、それらの一覧情報をポータルサイト(たとえばタウンページとか)で公開できるようになる。
つまり、いちいちポータルサイトへ連絡することなく、Webサイトを更新することで、ポータルサイトの住所情報も同時に更新されるようになる。
ほかにも、もしすべてのアプリケーションで同じ構造化データを使用していれば、ワンクリックでアドレス帳へ登録できたり、アプリケーションを乗り換える場合にも、データだけを別ファイルとして出力して、新しいアプリケーションへ読み込むことが可能になる。
構造化マークアップと、ほんのちょっとの気遣いで、混沌としたWebの未来は明るくなる。デザインが制約される? CSSがあるので無問題。
そんなわけで、Microformatsリファレンスを公開してみます。完全版ではないので、ひょっとするとなんかまちがってかもしれませんが、本家のサイトやアドオンなので、確認しつつ、ちょっとずつ完成系に近づけていきたいとおもいます。
ちなみに、SEOにも効果があるとかないとかいうはなしもあります。
なんか今日3時間ぐらい考えてた。
xsl:for-eachで決まった数のブロック毎に親ノードを追加する方法。
帰りに自転車こいでる時にふとおもいついて帰って書いてみたらうまくいったので覚え書き。
<xsl:for-each select="./section/box[position() mod 2 = 1]">
<xsl:variable name="p"><xsl:value-of select="position()"/></xsl:variable>
<xsl:element name="img">
<xsl:attribute name="src">
<xsl:value-of select="./image" />
</xsl:attribute>
</xsl:element>
<xsl:element name="img">
<xsl:attribute name="src">
<xsl:value-of select="../box[position()=$p+$p]/image" />
</xsl:attribute>
</xsl:element>
</xsl:for-each>
ループする毎に加算される値はないものかと、いろいろ調べてたんだけど、たしかにposition自体が加算されるのは自明の理。けっこう入門書に書いてあるような代入なのに、いやーまったく気づかなかった。