Days on the Moon

はてなブックマークがリニューアルしました。新しいはてなブックマークの個人ページにはページ自動ロード機能、通称 AutoPagerize 機能 (そう呼んでいる人がどれだけいるかは知りませんが) がついています。さて、AutoPagerize のような一般の Web ページにも適用しうる機能は誰が提供すべきでしょうか。ページの製作者でしょうか? ユーザー側が (ブラウザの拡張機能も含む) ユーザースクリプトとして導入すべきでしょうか? はたまたブラウザ側の仕事でしょうか? Twitter 上でそのことに関するやり取りがあったので少しまとめてみました。

hotchpotch

bbeta ってデフォルトで AutoPagerize ついてるんだ。変なボタン押すと有効になるっぽい(haihai sakura sakura) (2008-11-10 11:50)

os0x

はてなブックマークβ の AutoPagerize SITEINFO どうしたものかね。個人的にはサイト側で用意されている機能を優先したい。 (2008-11-10 18:10)

サイト側で(Greasemonkey の)AutoPagerize をブロックできる仕組みがあればいいのかな。 (2008-11-10 18:31)

nanto_vi

@os0x AutoPagerizeに限らずユーザースクリプトと製作者スクリプトの競合を解決する仕組みが作れればいいんですけどね。 (2008-11-10 18:36)

製作者スクリプトは<meta name="UserSideAutoPagerize" content="no" />を生成する、AutoPagerizeはそのようなmeta要素があったら停止する、というのを思いついた。 (2008-11-10 18:42)

http://nanto.asablo.jp/blog/2008/08/02/3668606 の延長線上の話で。 (2008-11-10 18:42)

meta要素生成だとユーザースクリプトを強制することができないけど。 (2008-11-10 18:44)

os0x

metaタグで拒否Script名を書くと、それにマッチするユーザースクリプトは実行されないとか。名前変えればいいだけだけど、それぐらいで丁度良さそうな気がする。 (2008-11-10 18:43)

@nanto_vi 見事に同じことを考えてました。 (2008-11-10 18:53)

AutoPagerizeについていえば、製作者スクリプトとして提供されたほうが望ましいと思う。わざわざ SITEINFO なんて用意しないといけないのは、製作者がやることを強引にユーザースクリプトで対応しようとしているからだし。 (2008-11-10 18:56)

kanasan

@nanto_vi autopagerizeをsite側で切れるようになると、ニュースサイトは全滅しそう。page viewが稼げないから...。 (2008-11-10 18:54)

nanto_vi

@kanasan あー、「ユーザースクリプトのAutoPagerizeを使わない」と「製作者スクリプトのAutoPagerizeを使う」を同一視してました。この二つは別物でしたね。 (2008-11-10 23:21)

hotchpotch

AutoPagerize が入っていればデフォルトで有効にしたいなー。 (2008-11-10 20:18)

snj14

@os0x AutoPagerizeはユーザスクリプトでやるべきじゃないってのには同意．ただ，製作者スクリプトでやるってのには同意できないです．あれはブラウザが標準でやるべきことだと思います．ブラウザの標準機能でナビゲートされることを期待されていたrel-nextなんかと一緒． (2008-11-11 00:21)

os0x

@snj14 ブラウザが提供するなら、OperaのFast Forwardぐらいになると思います。 http://labs.gmo.jp/blog/ku/2007/10/operafast_forward.html AutoPagerizeみたいなページ壊しちゃう機能をブラウザが実装ってのはあんまり現実的じゃないかと。 (2008-11-11 00:28)

snj14

@os0x Siteinfoなんて物を用意しないといけないのは別の問題で，ページを機械的に操作されることを予期せずにフリーダムにマークアップしても「人間が見えればオッケー」な風土を作った誰かが悪くて，rel-nextを考えたような人の描いた通りになってれば問題無かったと思います． (2008-11-11 00:29)

@os0x ページなんて，コンテンツを表示するためのガワでしかないのだから，ぶっ壊れようがなにしようが，コンテンツさえ見えれば(それが本来の目的なのだから)全然問題無いと思ってます． (2008-11-11 00:35)

@os0x あ，ちょっと違いました．本来の目的はコンテンツを見ることによって情報を得るだとか，楽しむだとか，そういうことです．そのための手段としてコンテンツを見ます．ページはそのコンテンツを表示するための手段です．本来の目的により近い部分が達成されれば下位はどうでも良いかと． (2008-11-11 00:42)

os0x

@snj14 その発想はユーザー側の発想で、コンテンツ提供者の意見も取り入れないといけないブラウザの立場ではないと思います。確かにユーザーの目的は常に情報を得ることですが、提供者側の目的は様々です。 (2008-11-11 00:46)

snj14

@os0x コンテンツ提供者はユーザでもあります．メモをWeb上に取っておいて読み返す人なんて典型的です．ユーザの目的を多く達成することを優先するほうが理に叶ってると思いますが．逆に，ページレイアウトが崩れて困る人ってどういう目的の人でしょう? (2008-11-11 00:54)

os0x

@snj14 すみません、コンテンツ提供者と製作者(サイトオーナー)が混ざってました。ここでは製作者側、特に個人ではなく企業とかでサイトを作っているケースを考えています。 (2008-11-11 01:35)

@snj14 Twitterとかはてなとかlivedoorとか各種ニュースサイトとかのことです。 (2008-11-11 01:37)

@snj14 ただでさえ日ごろクロスブラウザには手を焼いているのに、ブラウザの機能でページが崩れることを容認できるとは思えません。製作者は可能な限り自分達の管理下に置きたいと考えます。実際、はてなもそうなんだと思います。 (2008-11-11 01:47)

指定パスのDocumentを取ってきて表示するとかone linerで出来て、AutoPagerみたいなのも数行で実現できるようなブラウザってのが現実的な落とし所なのかなぁ。 (2008-11-11 02:44)

いや、それが標準化されてなきゃ意味ないか。 (2008-11-11 02:45)

hotchpotch

@os0x レイアウト崩れる、デザインの見せ方以外にも、スターなどのJS周りの付与なんか(APがfilter でできるようなJSの実行）もしたいというのがありますね。 (2008-11-11 08:48)

snj14

@os0x 企業の目的ってのは，ページを壊さないことでなくて，利益(利潤?)を得ることの筈．利益を得る為の手段としての広告が，とかページビューが，とかの話ならば，広告やらの「ユーザから嫌われるもの」を守ってまでユーザの体験が正当に進化しないのは企業にしたって本意でないと思います． (2008-11-11 22:34)

@os0x 客でもあるユーザに嫌われる役を買ってまで今の広告スタイルを守らなくても，コンテンツと広告の距離がもっと近く(今のgoogleのやつよりも．)なれば，adblock使ってまで対策を取るようなことにはならないし，その方が広告効果も見込めそうな気がしてならないのですが． (2008-11-11 22:44)

@os0x そして，ユーザの興味を持つコンテンツに近い広告効果のあるナニカを作ったとして，そのユーザに届けるためには，ユーザに関する機械可読なデータ(その人が何に興味を持つのか，等)が必要不可欠であると思います．なので，ユーザに機械可読なアウトプットをさせる必要があります． (2008-11-12 00:34)

@os0x ユーザにアウトプットさせるためには(そしてそれを持続可能にするためには)，軽い，面倒臭くない，AutoPagerizeのような，TomblooのようなUIが必要だと思います． (2008-11-12 00:43)

@os0x なので，今すぐ利益があるとは言えませんが，AutoPagerizeのようなUIをブラウザ側で実装することではてな等が未来永劫不利益を被る，ということにはならないとおもいますし，むしろ，適当にそれっぽく表示している今より良くなると思ってます． (2008-11-12 00:53)

たぶんだけど，Siteinfoもちゃんと考えてSemanticWebの方向に持っていくと，Trustとかの層まで来て，人の繋がりの情報を持った方が精度があがっていって．スパムがどうとか考えなくてすむようになるんじゃないカナー (2008-11-12 01:18)

os0x

@snj14 ブラウザ側AutoPagerizeはWEB製作を難しくしてしまいます。セマンティック・ウェブは特に、ですね。メリットがあることは理解できるけど、正直なところ現実的な方法とは思えないんです。 (2008-11-12 01:25)

@snj14 逆に、いわゆるデータマイニング的な手法のほうが現実的で、将来性があるんだろうと思います。 (2008-11-12 01:28)

@snj14 実際、履歴データだけでもそれなりのレコメンデーションは実現できています。情報が足りなくて精度が低いなら、幾つかの選択肢を用意すればユーザーが選んでくれます。 (2008-11-12 01:35)

(つい、話がレコメンデーションに。。) (2008-11-12 01:36)

@snj14 それで、ブラウザ側で実装されちゃうとコッチ(製作者)でコントロールできなく(し難く)なるので、歓迎できないって感じです。だから、AutoPagerizeが簡単に実現できるブラウザなら大歓迎です。 (2008-11-12 01:39)

bulkneets

@os0x それが当然になったなら、それに合わせてビジネスモデルとか作るモンじゃないの (2008-11-12 01:47)

os0x

@bulkneets そうなったらそうでしょうね。ただ、現状でも自前で実装してAutoPagerが活きるビジネスモデルは出来ますね。身も蓋もないけど、広告も挿入されるとか。 (2008-11-12 01:58)

なんだかんだ言って、ブラウザが実装するAutoPagerizeのイメージが湧いてきた。少し手を動かしてみるか。 (2008-11-12 02:21)

まだ出来は良くないとはいえ Google Chrome に Greasemonkey が乗ったから、Safari が追従することが期待できるし、ブラウザの標準機能になる可能性も見えてきた。 (2008-11-14 02:37)

AutoPagerize に関していうなら、個人的にはこれはユーザースクリプト、またはデフォルトで無効にされたブラウザ組み込みの機能 (私はこの二つにあまり違いを感じません) として提供されるべきだと思っています。文書内容をじかにいじるものをブラウザが提供し、さらにそれをフォルトで有効にするというのには少々抵抗を感じます。

SITEINFO をどうするかという問題はありますが、上のやり取りで言及されていた Opera の Fast Forward の仕組みや本文抽出モジュール (ちなみにそこで紹介されている Perl モジュールは第 1 回はてなインターンの成果が基になっています) などを組み合わせれば、意外と多くのページで期待通り動くのではないかと思います。HTML 5 が正しく運用されればそんなヒューリスティックに頼る必要も減るでしょうし。

しかしながら、はてなブックマークのように製作者側でプラスアルファの機能をつけたいということもあります。ユーザースクリプトと製作者スクリプトでは、CSS のように、重要指定付きユーザースクリプト、製作者スクリプト、通常のユーザースクリプトと排他的な優先順位を設定する仕組みが整っていればいいと言いましたが、CSS のようにという観点からすれば排他的な部分の粒度はもっと細かくして全体としては多層的、すなわちユーザースクリプトの動作を製作者スクリプトがフックできるような仕組みが望ましいのではないかと思います (現状の AutoPagerize でも、DOMNodeInserted イベントを監視し、それらしき要素が挿入されたらといった具合にフックすることは可能でしょうが)。