アプリケーションを「紙の比喩」から解き放つ
説明するのは難しいが、何かしらの電子的な体験の話をすると、亡霊のように、何処からともなく「紙の比喩」が出てきたりして困惑することがある。それは電子書籍の話は典型的であるし、あるいはウェブ上のページについても、明確には言えないけど、「ああ、これは紙の比喩の臭いだな」という感覚的なものが刺激されて、少し違和感を覚えることがある。もちろん、「紙の比喩」だけで悪いことではない。何故なら、紙が切り開いてきた体験の歴史もあるだし、紙を使うことによってわかりやすくなる側面も、多分にしてある。
とはいえ、「紙の比喩」といっても何のことがさっぱりわからないので、具体的な例で考えてみる。個人的には、紙の比喩がもっとも出てくる場所というのは、電子書籍に関する話題のときだと思う。たぶん、電子書籍なんかで一番評判が悪いエフェクトの一つに、「ページめくり」のエフェクトがあると思う。このエフェクトにも、適切な用法というのはあるんだろうけど、ただ「電子書籍なんだから、書籍っぽいものを作ればいいよね」という発想の場合だと、これは邪魔でしかない。こういうのを、僕は「紙の比喩」だと思っている。
自分で実践するのは難しいと十分承知しつつ、やはり電子書籍の体験というのは、たぶん「書籍的」な体験ではない。なぜなら、書籍的な体験というのは、それこそ、暴力的な言い方をすれば「紙の束」であるほうの書籍で充分だ。少なくとも、日本の文庫本というのは「書籍的な体験」としては、とても快適すぎると、自分は思っている。だからこそ、日本で電子書籍が上手くいかないんじゃないか、と感覚的には思う。例えば、紙の質がよいとか、製本がきちんとしているとか、そういう話だ。
とするならば、電子書籍というのは、「電子的な体験」のほうが問題になってくるはずなのだ。そして、勘違いしてはいけないのは、「電子的な書籍」というのは、恐らく＜視覚的なエフェクト＞のことではない。例えば、一番「電子的な体験」として優秀なのは、電子辞書だと思う。たまに家電量販店に行くと、電子辞書が山のように並んでいる。あれはあれで（受験生産業にのっかっているだけ、という見方はできるけれども）、やっぱり電子書籍というフィールドでは成功しているものの一つだと思う。
電子辞書が成功している理由のひとつとしては、やはり「検索性」という一点だと思う。辞書というのは「検索」するためのものであるからだ。最初から一枚ずつ読むのは、好事家じゃないかぎり、あんまり無いだろう。井上ひさしという作家は読んだといっていたけれども。とにかく、「検索」という需要に特化し、もはや「紙」の辞書とはまったく違うものなんだけど、あれはやっぱり「電子辞書」なのだ。
最近で、「電子辞書」の体験として「いいなぁ」と思ったのは、Kindle Whitepaperで、線を引いたところを、一覧してWeb上から閲覧できるようになっているということだった。自分が線を引いて読まないと、本を読んだ気になれない人間だからそう思うだけかもしれないけれど、こういうのは、電子的でとてもいいなあと思う。そして、別にFacebookで共有できるとか、あるいは読書したページが記録されるというのにはあんまり魅力を感じないのだけれど、これも人それぞれだとは思う。とに かく、電子書籍が「電子的な体験」を切り開いてくれることに、自分はちょっとだけ期待している。
追記：そうそう、右クリック禁止とかいう奴、あれもたぶん「紙の比喩」だと思うところはある。
机の上のカオス
恐らく職場の中でも俺の机はかなり汚いほうに分類されると思う。入社してから四ヶ月程度でとにかく自分の机周辺にモノを置きまくっており、酷いことになっている。とはいえ、自分自身がモノを整理している状態というのが苦手で、何かの作業をするときは、とりあえず「散らかす」という作業をやる部分は多少にある。
とにかく、職場にいろいろなものを持ち込んでおり、例えば壁に貼れるホワイトボードっぽいものであったりとか、あるいはスピーカーであったりとか、ディスプレイであったりとか、自分が快適に過ごせるようにする何かをひたすらと持ち込んでは配置している。現在の会社がそういうのに理解があるので、そうやっている。たぶん、その理由はよくもわるくも「ベンチャー」だからというのはあるんだろうと思う。とにかく、いろんなアイテムを持ち込んでは、会社にぶちこんでいる。
基本的に、自分は、我々人間というのは環境に支配されやすいものであるという前提で考えている。例えば、知り合いの女の子は、半分ほどニートみたいな生活を送っていて、生活習慣もグダグダであったが、喫茶店で短時間のバイトをはじめたところ、だんだんと生活習慣が朝方にシフトしていって、朝に起きられるようになったらしいが、恐らくそういうものだと思う。（とはいえ、本当の理想を言うならば、遅刻できるようなところがあるほうが望ましいとは思うけれども）以前に読んだ『ピープルウェア』にも、確かそういうことが書いてあったと思う。だいぶ前のことになるから、覚えていないかもしれないけれども。
あともう一つとして、単純に、職場にいる時間が8時間程度であるとする。一日に24時間与えられている。労働時間において、一日の中で既に1/4の時間が束縛されている。睡眠時間が7時間だったとして、通勤に往復1時間かかるとするならば、その時点で既に1/3の時間を削られているわけで、そのように考えるとするならば、やはり労働時間は大切にせざるを得ない。快適に仕事ができる空間というのは、それこそ自分の身というか、生活を考える上において、それなりには重要になってくる。なので、「自分にとって居心地の良い場所」というのを目指して、色々と工夫する必要がでてきたりする。（ただ、個人的には、職場に「ずっといる」というのもよろしくはないとは思っていて、なるだけちゃんと帰れるようにしたいというのもある）
たぶん、自分が快適な空間というのは、そういう風に介入していくという空間なのであり、そういう介入できる余地があるということを、モノを持ち込むことによってやっていきたいという側面はある。ということを言い訳にしつつ、俺は周りに迷惑がかからない程度に机を汚すのであった。
jQueryとわたし
仕事でjQuery Mobileを使っていたのだけれども、色々と困ったことがあったので、自戒を込めてここに書いておく。
jQuery Mobileが少し癖があるなーと思ったのは、下のあたりくらい。
- 基本的にajaxで通信しているので、たまにPostで辛いことが起きたりする
- あとはハッシュが潰されているので、ページの中でジャンプしようとすると痛い目を見る
最初に関しては、たぶんページを移動して、ページの内容を表示しようとするときに、白くなったりするのは如何にもウェーヴ感が出てしまうのが難儀、みたいな発想なんだろうなとは思って、だとするとbody全体をそのまま埋め込んでしまったほうがいいじゃんかね、という感じなんだろうなと思ったりするんだが、油断してheadタグ内部にJavaScriptを設置したりすると、ページのURLを直で叩いたときに動いていたJavaScriptが、ページ遷移したときには動かないというわかりやすいバグを生む。意識の高いJavaScriptの人であるならば、「bodyの最後にJavaScript埋め込んで、体感的にページが先にRenderされるようにしろやボケ」ということになるわけで、その通りにしたら、ページ遷移しても動いたのでよかった。
あともう一つの問題として、ファイルのアップロードが出来なくなるということも発生して非常にFuckなことになったので、属性にdata-ajaxをfalseにすることによって解決するとか、そういう風にやっていた。
その辺は、挙動を見ていたら「たぶんそういうことなんでしょうね」と把握しやすくて良かったのだが、問題は2番目で、この辺に関しては、現時点で模索する形になるが、どちらにしろ面倒くさい。
jQueryのライブラリ自体は、それなりに素晴らしいなあとは思う一方で、こういう風に、よく言えば「あまりにもダイナミックにページの挙動自体を規定してしまうモノ」形になってしまうと正直辛いよなーという気持ちになることは否めない。それは、そのプラグインの中の挙動であって、それ以外では通用しないし、しかしその挙動は、それを使う上において当たり前になっている。
そのあたりは、何も考えずにjQuery Mobileの前提というものを調べているからとんちんかんなことになっている可能性もある。どちらにしろ、楽しようと思ったら別のところで躓いたりする。そういうものだと思う。
Backbone.jsをいじりはじめての感想
Backbone.jsをいじって、アプリケーションの準備をしているのだけれども、Backbone.jsは何かと便利だ。とはいえ、それほどBackbone.jsらしいメリットを享受しているわけではないのだが、しかし何かしらの基準があるということは素晴らしいことだ。正直、Backbone.jsのMVCの分け方は少し不器用な感じがしなくもないのだけど（個人的には、ControllerからRouterに名前が変わったところにそういうのを感じてしまう）、でも基準が生まれたことによって書きやすくなっている部分はある。まさに背骨。
以前に「大規模、大規模というけど、お前の言う大規模とは何か」みたいな話をされてしまって、考えてみればそれほど大規模ではなかった。というより、ミサワ的なドヤ顔をしたいために大規模、太規模言っているだけだった。反省。中規模？ただそういうことを考え始めるとただの定義問題となってしまう。基本的には「ファイルを分けていく必要があれば、とりあえずそれは中規模くらいに考えてもよさそう」という感じの気持ちはある。既に羊頭狗肉になっているけど、気にしないことにする。
とはいえ、じゃあ「ブラウザに読みこませるためのチューニングアップ的な奴」以外にファイルを分ける必然性があるときってどんなときだろう、というと、自分としては「変更可能性がありそうなパーツを一まとめにしておく」という感じでまとめたりしていた。例えば、Backbone.jsを使う前は、下のような感じだった。
- フォームの値をParseしてデータ構造を作ってくれる関数一式
- 受け取ったデータ構造からHTMLを組み立ててくれる関数一式
- イベントと実際の挙動を結びつけるための関数一式
- 実際の挙動
みたいな。こういう分け方だったので、結果として、Backbone.jsに手直しするときも、それなりに楽だった気はする。逆に、こういう構造だったときに、辛かったのは、DOM構造自体を一種のModelみたいな扱い方をしていたという点であるところと、あとEventがひとまとまりになっていたので、どの部分がどのEventを必要としているのか、という見通しができなくて、ちょっと辛いことになっているくらいだった。
逆にBackbone.jsでなれてなかったのは、Model、Collectionをどう取り扱うのが一番いいのか、とか、あと元のURLの仕様自体が別段Backbone的に構成されているわけではない(RESTfulにMethodでPUT/DELETEとか使う感じでは無い）ので、そのあたりを調節していって、現在利用しているフレームワークの利用的に辛い部分とかがちらほらしていたことくらいかなーとは思う。このあたりに関しては、本気で使いたくないときはチューニングできるっぽいので、それはそれでいいかなと思う。現時点では、Backbone.jsにはそれなりに満足している。
