全文掲載のRSSはRSSリーダーに登録しないという選択肢

自分でRSSリーダーを作れば済むのだけど、ウェブサービスであることの優位性には替え難いので、不満が出てきたがGoogle Readerを使い続けることにする。広告があるのは御免なので選択肢としてはあまりないんだよね。

Googleリーダーには「Expanded view（記事と要約あるいは内容が表示）」と「List view（タイトルのみが表示）」の二つの表示方法があって、タブで切り替え可能だ。しかし何故この二つに分けなければならないのだろう。RSSリーダーに求めるのは、読みたい新着記事をすばやく探すことだ。List viewでは記事のタイトルしか表示されないので、それが良いタイトルでない限り情報が足りない場合が多い。その為に要約を配信可能になっているのがRSSなのに、それを閲覧するモード、つまりExpanded viewは「タイトル + 要約」の形式のRSSアイテムと「タイトル + 内容」の形式のRSSアイテムをごっちゃに表示してくれる。これではすばやく記事を探せないのだ。まあ「タイトル + 内容」のRSSを配信するのはどうかしているが、それはもうRSSの定義がめちゃくちゃになってしまった現在、もう言う気力もない。だからこれからは無理にRSSリーダーに理想を追うのはやめて、「タイトル + 内容」のRSSは購読せず、アンテナで更新を取得しようと思う。

greasemonkeyスクリプトとかユーザースタイルシートでなんとかなるかもしれないが、アンテナとRSSの使い分けをして、アンテナも有効に活用したいので、これでいいかなと思っている。

ちなみにJintrick::Antennaのスタイルシートは、割と「タイトル + 要約」的なviewで記事を探せるようにしてある。

ウェブサイト運営方針を考える（長文注意）

ウェブサイトを構築する上で、私が最初に読んでおくべきと考えている、オンライン・ハイパーテキストのためのスタイルガイドを久しぶりに熟読し、及びこの文書にリンクしている文書を読み漁った。その中で変わらないURIこそがクール - 徒書は参考になった。

「変わらない」ということがクールなURIであることの必要十分条件。ファイルの拡張子が示されていても、変わらなければクールなのだ。拡張子がなければクールかといえば全くそうとは限らない。例えば止むを得ない事情で、コンテントネゴシエーション等が使えないサーバに移転することになったら? 運営する主体によってクールなURIの形式は変わってくるかもしれない。

個人で運営する以上は、その個人に関する情報がURI、特にhost名に含まれてしまう。結局のところ消失しないPURLを取得しておき、ハイパーリンクはなるべくPURLを用いてInternet Archiveなどのウェブサービスに拾ってもらうことで、リソースの永続性を保っていくしかないのだろうか。

私がPURLを利用し始めたのは6年程前、言葉 言葉 言葉の野嵜さんに紹介されたのがきっかけだった。PURLにおけるtop-level domainというのは所謂TLDとは違い、http://purl.oclc.org/ tld/ の tldの部分をいう（※）。通常の申請ではtop-level domainは得られず、/NET/以下に「sub domain」と呼ばれるものを登録するのだが、PURLの管理者に申請する必要がある。私のときはメールフォームを使用したが今はどうだろう。there is no guarantee that your request will be grantedとあるから、申請しても却下されるケースはあるのだろう。JINTRICKというtop-level domainを申請したときには、why?と聞かれて困ったので、永続的なURIの重要性だの理念だのをつらつら書いて返信したところ、done.と返事が返ってきたのを覚えている。

※日本でこういうことをすると必ず「トップレベルドメインという言葉を誤って使っている云々」という馬鹿馬鹿しい揚げ足取りがやってくるが、単にその文脈における「最上位のドメイン」を意味する言葉なのだから、別にどうということはない。一部の日本人はカタカナで書いたとたんにその言葉の意味を狭義でしか考えなくなるので困る。

将来HTML4.01という形式をXHTML1.1に変更するとして、同じリソースとして同じURIで提供すべきなのだろうか。このあたりの問題を考えるとき、私はどうも拡張可能なXML形式のHTML、すなわちXHTMLの採用について疑念を抱かざるを得ない。たぶんMark Pilgrim氏と同じような理由だろうが、アクセス性を考えてもtext/html形式はまだ必要だと思う。また、数年XHTML（というかXML）を使ってみて、その厳密さから「公開に当たって必ず何らかのCMSを通さなければならない」と確信した。私は既存のCMSがあまり好きではない。というか無駄なものばかり吐くし、使用言語からして嫌いだ。だから自作したものの、それを改善したくなって時間をとられる。そこが時間の無駄遣いのような気がしていた。つまりローカルルールに関する意思決定の連続がである。私はこういったローカルルールとどうやら馬が合わない。

サイト側ですべきことは何だろう。trackbackがWeb2.0だとかなんとか言うひともあるが、私はそうは思わない。そういう文書間の自然な繋がりは第三者が提供すべきものなのではないかな。trackbackさえ辿れば十分というわけではなく、結局その文書に言及している文書を調べるときにはGoogle等のウェブサービスを利用したほうが潤った結果を得られることが多い。文書を提供するサイト、繋がりを提供するウェブサービスといった具合に、分散していたほうがすっきりする。それに大した根拠も示せない持論だが、閉鎖されたネットワークは必ず腐ると思っている。RSSとかtrackbackとか、その仕組みの中だけで完結されるような環境にいると、腐ってくるような気がする。個人的にRSSを提供してくれるサイトの方が有難いけれども、提供がなかったらなかったでアンテナがあるし何とかなるものだ。別に必要じゃない。というわけで決定。色々なサービスを提供しようとしてウェブサイトのインターフェイスをグチャグチャするより、そういったサービスは第三者にやってもらおう。ウェブサービスが潤沢な今、賢い閲覧者は関連文書を見つけることなどたやすい。賢い閲覧者をターゲットにしよう。

結局のところ、HTML文書を公開し、HTMLで可能な限り明示できるものをしっかり明示しておくことによって、既存のニーズの多くに答えることが潜在能力的に可能なんじゃないかと思う。XHTMLの採用は見送り、必要なときだけとする。Tim Berners-Lee信者（謎）としては苦渋の決断だけど。いざってときにはPythonでSAXのようなインターフェイスを経由してHTMLを扱える環境を持っているし、なんとかなるでしょ。

まあこんな調子だから、この世界では絶対に食って行けないわけですよ。もう気持ち悪くて全部とっぱらいたくなってくる。

Firefox ブックマークのkeyword命名規則のガイドライン

Hatena::agenda - スリムなFirefoxでサイト内検索の補足記事。

ブックマークのkeywordは、ある程度reasonableなルールを決めておくことで、CUIの弱点を補い、メンタルモデルの混乱を避けることができる。

単にページに移動するだけなら、名詞を使用する。例えばkeywordを「レシピ」としてlocationに
「http://cookpad.com/」とか。

ここで「cookpad」のような固有名詞にしてはいけない。「レシピ」を知りたいという状況は将来も発生するだろうが、cookpadという名前は忘れてしまうかもしれない。それに、固有名詞をkeywordにするくらいなら、普通にGUI経由でブックマークを開いた方がよい。keywordの優位性があまりないからだ。

また、単にウェブページを開くのにわざわざキーボードで文字を打つのであるから、GUI経由に対する優位性のあるケースで使用すべきだ。例えば単一のページではなく、関連した複数のページを開くのに使用するなどである。私の場合、情報収集の際にはアンテナとRSSリーダーとニュースを同時に開くのだが、これは次のようなブックマークレットで可能だ。そしてkeywordは「news」である。 

javascript:
location.assign("http://a.hatena.ne.jp/jintrick/?gid=null");
void(window.open("http://news.google.co.jp/"));
void(window.open("http://www.google.co.jp/reader/view/"));

現在表示しているページに関するコマンドなら、動詞を使用する。例えば様々なログイン制のウェブサービスを利用中、れぞれの管理ページにアクセスするというコマンドなら「edit」という動詞のkeywordを使う。

以下は、はてなダイアリ、はてなアンテナ、Google Readerを利用中、それぞれの管理ページにアクセスするブックマークレットの例。 

javascript:(function(){
    var base;
    with(location) {
        base = protocol + "//" + host + path;
        if(host == "d.hatena.ne.jp")
            assign(base + "admin");
        else if(host == "a.hatena.ne.jp")
            assign(base + "edit");
        else if (href == "http://www.google.co.jp/reader/view/")
            assign("http://www.google.co.jp/reader/settings");
    }
})();

そして次のブックマークレットは、現在開いているウェブページに言及しているウェブページを調べる。このときもkeywordは「compare」などの動詞とする。 

javascript:(function(){
var h = "http://b.hatena.ne.jp/entry/";
var g = "http://www.google.com/search?q=";
var y = "http://search.yahoo.co.jp/search?p=";
with(location){
    var s = search? search : "";
    var uri = protocol + "//" + host + pathname + s;
}
window.open(h + uri);
window.open(g + encodeURIComponent(document.title + " -site:b.hatena.ne.jp -site:a.hatena.ne.jp -site:r.hatena.ne.jp"));
window.open(y + "link:" + uri);
window.open(g + "link:" + uri);
})();

検索に関するコマンドで、%sを使用するなら、keywordの最後に?を追加する。例えば「英和?」「和英?」など。個人的に結構使うのがgoo 映画を利用した映画検索。英語の原題も分かるし一言内容紹介もあるので、英wikiと並行利用すれば十分なデータが得られる。Bookmarkletとする必要はなくキーワードは「film?」としlocationにhttp://movie.goo.ne.jp/search/result.php?n=%sを指定すればでいい。

%s変数を使用する場合、それを目的語にとる他動詞を使用する。これはあまり使わないかもしれないし、ちょっと微妙だ。目的語は、Javascirptで自動的に参照可能な現在開いているページに関するものになることが多い。またbookmarkletにおける%s変数はそのままの形で評価される、つまりJavascriptコードとすることが可能だ。keyword、半角スペースに続いてJavascriptコードが書ける。したがってよく使う関数を複数定義しておいて、簡単に呼び出す、ということができる。

続きは後ほど。

コンテクストメニューの役割

A Successful Failure - SleipnirユーザのためのFirefox乗り換えの手引き経由でMenu Editor :: Firefox Add-ons。これでコンテクストメニューをスリム化できたので改めてコンテクストメニューについて述べておく。

コンテクストメニューは、ポイントされているオブジェクト、または位置に関する操作を行う為のメニューに絞るべき。なぜなら、それ以外の操作はメニューから行うことが容易であり、かつ、ポイントされたオブジェクトに関する操作はポインティングデバイスから選択するのが最も容易だからだ。

また、そのような棲み分けをすることによってUIに関する整った（正しい）メンタルモデルも確立される。ポイントした何かについての操作をしたいとき、そのときに限りコンテクストメニューを思い出せばよくなり、何でもかんでもコンテクストメニューで行おうとする場合に比べて手順の道筋が整う。行う操作の種類が多くなったとき、この整ったメンタルモデルは非常に重要になるはずだ。すなわちタスクを完了させるまでの手順をユーザーが予測しやすくなるということ。

というか、「何故コンテクストメニューなのか」を全く考えないまま、直感的に便利だからという理由でコンテクストメニューに機能を詰め込んでいると思われるアドオンが多すぎ。「ポイントしなくても良い操作なら、コンテクストメニューにしてはならない」くらいの制約をまず課して考えてほしい。

今回の話もまた、天秤の話だ。確かにコンテクストメニューは「厨房」にとって便利だし、実際便利な場面も多々ある。コマンドにアクセスするプロセスが短くて済むのだから。しかし本来そのメニューに位置していなければならないコマンドを圧迫し、かつ、メンタルモデルを複雑化してまでして得るべき利便性なのかどうか、天秤にかけるべし。

ちなみに「戻る」「進む」のような非常に良く使う機能はRocker Gestureに割り当てるなど別の更に高速かつ適切な方法で実現すると良いだろう。ロッカージェスチャこそ必要 (kuruman.org > Kuruman Memo)を見ると必要と思っていないユーザーが多いらしいが、２ボタンマウスのような一般的なポインティングデバイスを想定するなら、あり得ない結果である。

ちなみにマウスジェスチャに関しては、同様に「移動」や「大きさの変更」に関連する操作に特化させると良い。軌跡を描くという行為は「移動」と直感的に結びつく故。マウスジェスチャを使ってアプリケーションを起動させたりすると、メンタルモデルが複雑化する。自分の脳内も最適化し、もっと大局的に使いやすさを考えようではないか。なんつって。

はてなスターの消し方

http://d.hatena.ne.jp/user/configview から設定で消せるようで。 

.hatena-star-comment-container,
.hatena-star-star-container {
	display: none;
}

はてなスター邪魔だからCSSで消した（つもり）。あ。あと、はてブとやらのコメントは言論、言及として認めていないので悪しからず。基本的に全部「こだわりません」付き（謎）として解釈する。当然だけど。

野暮ながら書くと（100文字等に）規制されているものは言論ではない。すなわち、そんなメディアを通じて何か言った気になるのはアホ。それはさておき。

一昔前も、自分の「ほーむぺーじ」にちょこちょこ動くマスコットだの占いだの置く人が多かったけれど、ウェブに何かを公開するという力の使い方を知らなかったんだろうね。今再びそういう参画者が増えた。それだけのことのような気もするし、劇的に敷居が低くなった分、浜に打ち寄せられるごみは年々増え続けるような気もする。

はてなスターをそんな「ブログパーツ」と同列に考えるのはどうかと思うが、少なくとも「気が散る」。それにウェブの投票系アプリケーションは信憑性に欠ける。お遊びのレベルでは人気度は興味深いパラメタかもしれないが、仕事とかもっと真面目な用途で考えれば人気度ではなくて信頼度が重要になってくる。だから本当は「信頼できるユーザーに評価された信頼度」こそ読者が知るべきパラメタだろう。

前にも書いたが、Ajax系のアプリケーションの9割はシーズ指向、つまり「できるからやってみる」類のお遊びであって、本当に必要なものが提供されるのはごく稀だ。

ユーザー側から消す場合は次を参照のこと。MORIYAMA Hiroshi's Diary - Firefoxで「NoScript」とか「Adblock Plus」を使はずに「はてなスター」だけを無效にする

「ブログのサイドバーは要らない」の反論にこたえる

ウェブで糞議論をする気は最早毛頭ないんで。

ざっとみて一番多かったのが、文章が横に広がりすぎてウザイとか、横幅100%ウザイとかいうぼやきだった。わらい。Hatena::agenda - ブログのサイドバーは要らないでは、文章を横に広げろとか、横幅を100％にせよ、とは言っていない。むしろ適切なmax-widthプロパティを場合によっては推奨してもいいくらい。所謂「最大化厨」対策。うちでは、「閲覧者は馬鹿、的な発想」でCSSを書いている気がして嫌だったから今までやらなかっただけ。だが昨今法外に横幅を奪うデザインのサイトが多いので、そういうサイトをよく利用する人にとってはウィンドウ幅を変えずに済んで便利だろうと思い直してCSSを改善してみた。失うものも殆どないからね。

次。そのブログの過去の記事等を辿りづらいという主張。あんなちっこいカレンダーとかサイドバーに押し込められたリストを使うより、それ専用のページを使って辿ったほうが楽なんだけど。どうしてもというなら、ナビゲーション専用のページにリンクしてリンク先を得意のAjaxとやらで上手に扱えばいいじゃないの、と指摘し済み。

サイドバーは自分用なんだという主張もあった。ブログは自分の為のコンテンツなんだ、と。自分を中心とした情報ポータルのような使い方をしたいということらしい。しかしそれは自分が良く見るブログの更新用ページでやれば十分であって、いわゆるpermalinkというか保存版の記事にまでサイドバーをつける価値があるのかは再考すべき。

マルチタスクはマイナーだといった主張も。いいからストレスなくやれる環境を借りてやってみろと述べ済み。

あとは取るに足らない電波だったので一々挙げない。

2007-09-21追記。

趣旨には同意／記事を兎に角読ませたい自己顕示欲の露出にも見える／ブログを見る時、大抵の場合、必要な情報を見たいのであって『筆者の記事』が見たいのではない。整理がなってないブログはカテゴリくらいないと。

はてブコメントに何か意味があるとは思えないが、珍しい意見だったので紹介しておこう。

べつにカテゴリの否定はしていない。Hatena::agendaでカテゴリ分けをしていないのは、はてなダイアリのカテゴリ分けが、まるで使い物にならないからだ。例えば[Javascript]というカテゴリへのリンクを辿って、なんで記事の見出しのリストが出てこないで、限られた数の記事がそのまま並べられているの? 気が狂っているとしか思えない。まあそれはいいや。

必要な情報がみたい? RSSリーダーなり他サイトの紹介なりで、あなた（閲覧者）は記事のタイトルを目にしたはずだ。あなた（閲覧者）はそのタイトルの記事を読みに来たのではないのか？それが必要な情報でなかったら、そのときはじめて、その記事からリンクされている（かもしれない）関連記事を読みにいくはず。

自己顕示欲というのはさっぱり意味が分からん。Hatena::agendaのことを言っているのかな? 当たり前だろう。読ませたくないものを公開する馬鹿がどこにいるんだ。特にうちは嫌でも読めというスタンスだ。しかし自己顕示欲というなら、むしろサイドバーにカテゴリリンクだの何だの、自分のブログ内のほかの記事へのリンクを埋め込むことこそ、「自分のブログを兎に角読ませたい」自己顕示欲の現われだろう。私の場合は記事を読んでもらえればそれでいい。結果としてユーザーのニーズに応えただけだ。しかしサイドバーを無理に埋め込むということは、記事のみならずブログ全体を読んでもらいたいということだろう。その行動だけ比較すれば。どちらが自己顕示欲が強いかは明らかではないか。

スリムなFirefoxでサイト内検索

昨日のフォクすけブートキャンプ＋の続き。アドレスバーに「site 検索キーワード」と入力するとサイト内検索できるようにFirefoxの外面をいじってみる。

まずこんなブックマークレットを書いた。 

javascript:
(function(){
	var hn = location.hostname;
	location.href = "http://www.google.com/search?q=site:" + hn + encodeURIComponent(' %s');
})();

次にこのコードの改行を払って、Bookmarks → Organize bookmarks → New Bookmark → File → New Bookmarkに次の情報を入力し、ブックマークとして適当な場所に登録した。

Name
サイト内検索
Location
改行を取り除いた上記のブックマークレット
Keyword
site

終了。アドレスバーに「site 検索キーワード」と入力するとサイト内検索ができる。

補足：スリムなFirefoxとは

スリムなFirefoxの必要条件：

  • View → Toolbarで全てのツールバーを非表示にする。
  • View → Toolbar → Customizeでアドレスバーのみをメニューバーにドッキングさせる。
  • メニューバーとステータスバーのみの状態にする。

なぜそんなことをするかといえば、それはとにかくより広いコンテンツ表示領域の確保が目的だ。マルチタスク環境でもアドレスバーが使用できるように、検索バーも非表示にする。動作を軽快にするため、可能な限りAdd-onも使用しない。

この「コンテンツ表示領域の確保」に大きな価値を見出している人はあまりいないかもしれない。しかし、上下左右の殆ど使用しない、というか表示させておく必要のないアイコンだのツールバーによって表示領域が狭くなっているとしたら、直接ストレスを感じないにしろ、100％確実に生産効率を低下させているということに気づくべきだ。これ金銭に換算すると恐ろしいことになると思う。自分の気づかないうちに、毎日ちょっとずつ損をしているのだ。時にはごっそり損をすることもあるだろう。ほんの数10pxの差で、スクロールバーが出るか出ないかが決まることがある。重要なリンクや単語を見逃すことだってありうる。

今日、というか昔からだけど、「さいどばー」に始まってナビゲーションリンクだのコメント機能欄だの、ただでさえウェブページのコンテンツ領域は非常に狭いのだから、ブラウザ側でできることはやっておきたい。

次。数分ででっちあげたスクリプトだからアレだけど、変に複雑なことをしなければ十分使えるので公開。 

javascript:(function(){
    var s = location.search.substring(1).split("&");
    for(var _,i=0;i<s.length;i++) {
        _ = s[i].split("=");
        if(_[0] == "q") {
            s[i] = "q=" + _[1] + encodeURIComponent(' %s');
            with(location) {
                assign(
                    protocol + "//" + host + pathname + "?" + s.join("&")
                );
            }
            break;
        }
    }
})();

これを同じようにブックマークレットとして登録して、たとえばKeywordを「+」とすれば、アドレスバーに「+ more_query」と入力してGoogleの検索結果を絞り込むことができる。