公開メモ日記
というわけで、トラックバック2.0について。
人気ブログサイトなんかに、トラックバックがずらずらとたくさん表示されていますけど、アレってもはや、「数そのものが人気の指標になる」程度の意味しか持っていない気がします。1つや2つならまだしも、5コも超えると、もう読みたいと思わないね。特に要約文なんて、まともに「要約を」つけてくれるブログはほとんどないので、一度も役に立った試しがないです。
そこで、幸之介の＠をリニューアルするときは、リファラアクセスのランキングを相手ページのタイトル付きで表示させることで、トラックバックと同様かそれ以上の効果を得るつもりです。
キモは3つで、まず、アクセスランキングという序列を与えることで、影響の大きい、または関連の強いページが、わたしのサイトの閲覧者にとってわかりやすくなります。上位をいくつかチェックするだけですませることができる。なお、あるサイトのトップページからのアクセスと個別ページからのアクセスは、まとめて表示させるようにします。そして2つ目のキモは、要約を表示しないこと。だって意味ないし。前述したように、特にたくさんのページが並んだときは、いちいち要約があると一覧性を著しく損ねます。いちおうtitle属性には入れてあげるので情報は失われません。3つ目のキモは、トラックバックを備えない（または打たない）サイトからのリンクにも対応できること。これきわめて重要。
参照関係を読者に示す機能としての「トラックバックよりも優れた方法」について、トラックバック2.0の視点からの解説はしてみたものの、既存のリンク元アクセスランキングとどう違うのかも解説しよう。
キモはふたつ。
まず、相手ページに逆アクセスしてタイトルを取得すること。たぶん実装済みのサイトもある気がするんだけど、お目にかかったことはないと思う。アクセス数の数字だけの表示とか、URLだけの表示とかは見たことがあるけど、タイトルが表示されることで一気にわかりやすくなるはず。
もうひとつのキモは、同じサイトと思われるリンク元をまとめて表示させること。先にも書いたけど、サイトのトップページからのアクセスと、個別記事からのアクセスは、階層を落として並べて表示させる。ただ、これは少し仕様を練る必要がありました。結論だけを言うと、あるURLからのアクセスがあったとき、そのURLを完全に内包する（または内包される）URLからのアクセスがすでにあればそれらは同じサイトと見なし、内包される（URLが短い）方が親ページになります。こうすれば、プロバイダのトップページとかブログポータルのトップページからリンクされるようなめったにない事態を除いて、うまくサイト単位の親子ページ関係を構築できるはず。
リンク元表示について、若葉ちゃんとakくんに話題が広まっています。これにあと某所の小林くんを加えて4人で議論すると、はてな会議クオリティが実現するんじゃなかろうか。大阪と信州と東京じゃあつらいものがあるが。
さて、a 要素と link 要素でサイトをまとめる方法については、相手が必ず礼儀正しいサイト（またはブログ）とは限らないのでうまくいきません。RSSなどを読みに行くことも考えたのですが、やはりWebサイト全般に活用できるほうが便利なので、URLの内包方式がよい。
検索円陣からのリンクについて。なななななるほど。検索エンジンだけは主要どころをあらかじめ登録しておかないと、「URLが内包するかしないか」だけではまとまってくれませんな。それと、読者の利用目的を考えると、検索エンジンからのアクセスは別枠にする必要があると思った。似た機能を持つtDiaryの「本日のリンク元」もそうなってる。かつ、きっといっぱいでてくる些末な検索語からのアクセスを隠すとすれば、全体で上位5件とかに制限するのがいいね。そんなにたくさんあってもクリックされるワケじゃないし、あくまで参考である。
ちなみに、検索エンジンからのリファラこそ、タイトルを読みに行くメリットが大きい。検索エンジンのクエリを読み解いてデコードしたりせずとも、タイトルがそのまま検索語になってくれていて、かつそのタイトル単位で集計すればクエリの些細な差を吸収してくれるのでたいへん便利。
で、似た機能のツールについて。実は若葉ちゃんの言及を読んでからわたしもいろいろ検索したのですが、tDiaryの「本日のリンク元」はそういえば見たことありました。でもこれはリファラURLをたどらないので、個別サイトURLに対してわざわざ日記タイトルを指定しなきゃイカンらしい（さもなくば単なるURL表示）。その点、Nucleusのreferer2は日本であまり実装例がないもののタイトルを取得して表示するんだね。しかしリファラスパムが防止できていないように見える。
というわけでリファラスパム防止のため、タイトルを読みに行くついでに相手ページからのリンクが確かに存在するかをチェックします。あと、自分のサイト（knoa.jp）からのリンクはカウントしない。
これで完璧かしら。
もちろんお菓子のクッキーじゃなくて、Webサイトの情報記録に使うCOOKIEのことです。
さて、幸之介の＠のうち、あなたがいつの更新まで見たかを判断して、初めて見たであろう新着情報にだけ色を付けたりする仕様を考えています。（たとえば公開メモ日記のタイトル部分のグレーが、初めて見るものだけオレンジになったりする。）
このしくみはウザイでしょうか。どのページにアクセスしてもクッキーが書き換わるので、食べるクッキーをすべてチェックしているひとはウザイかもしれません。でもそうでない多くのひとにとっては便利じゃないかなぁと思うんですが、どうでしょう。
クッキー期限は30日程度を考えています。
Webに載せる記事を書くとき、いちいちHTMLを書かなくてすむように、各種Wiki文法やはてな記法を参考にして、文法の乱立に荷担して申し訳ないと思いつつ、幸之介の＠2.0のための記法を考えてみました。まだ実装してませんが、われながら、超使いやすいと思います。HTMLもそのまま書けるし。
そして、この記法で書かれた記事データを、記法のままとHTML変換後のふた通りで保存しておく仕様を考えています。記法だけを保存すると、記事を表示するときに毎回HTMLに変換するので効率が悪いし、HTML変換後だけを保存すると、修正時に記法に戻す処理やそれに伴って事前にやっておかなくちゃいけない記法への可逆変換処理がスマートではないと感じたためです。サーバーのCPUよりテキストを保存するディスク容量のほうがコスト低いし。
ちなみに、こんなメモ日記を興味を持って読んでくれるのは、10人もいないと思います。
リリースしてわずか1時間余りの幸之介記法（仮称）ですが、ビックリマークを前後にふたつずつ付ける !!テキスト!! で強調させるのは、まずいと思いました。
ビックリマークふたつは文章中に比較的よく出てくるので、特にスタパ斉藤さんあたりだと、強調しまくりでめちゃくちゃになってしまいそうです。
というわけで、ビックリマーク3つに変更。根本的解決になってない気はしますが、複数の種類の記号を使うとタイプしにくいし、Wikiでよくある '''テキスト''' 方式は引用符で強調というのが不自然に思えるから。表に出さない仕様として、ブロック要素をまたぐと!!!の開始をリセットするので、きっと問題ない。
例によって若葉ちゃんやakくんに大変ご好評いただいております幸之介記法。akくんは詳細な感想と要望を付けてくれたので、それに応えます。
「見出しのアンカー処理の自動化」は部分的に採用し、[#anchor テキスト]とすると、テキストに対して見出しで指定したanchorにリンクします。しかも[#anchor]だとアンカー先のテキストに対するリンクにしてくれます。
akくんの仕様の[#テキスト]だと、中身に一字一句違わない見出しを書くのは危ういし（IEでテキストをコピーすると最後に半角スペースが入ったりする）、アンカーの自動生成は当初考えていたのですが、やはり一意性の問題と、人間可読性の問題があるためにやめました。
「パラグラフは一行空きの方が良いのではないか」は採用。空行で段落を生成し、単なる改行はまったく無視します。
これも当初迷っていたところで、初心者に対するユーザビリティとして、改行したのにそれが反映されないというのはかわいそうに思えたのでした。しかし心を鬼にします。それに、改行と折り返しの区別が付かなくなるのはわたしもよく体験します。
「引用形式が不適切な気がする」はほぼ不採用。blockquoteにcite属性は付けますが、要素としてのciteはやはりblockquoteの中です。
要素の位置関係については Web KANZAKI を参考にしました。また、blockquoteのtitle属性にcite属性の中身のページタイトルを入れる件ですが、blockquoteそのもののtitle属性としてはなんか違う気がするので不採用。ついでに、引用ブロックの上にマウスを置いたときにIEの仕様でtitleがポップアップするのが邪魔に思います。
「強調」は了解。ブログサービスとして公開する際の説明文としても少し意識していたので「太字」と書きましたが、初心者の人には空気を読んでもらうということで「強調」に改めました。
em要素にも触れられてしまったので、半角スペースを挟んで ! !テキスト! !で強勢にします。実際のスタイル適用も、letter-spacing:0.5em;あたりにしようと思っています。emは「強調」ではなく「強勢」と表す方がよいと、声を大にして言いたい。emとstrongの違いについては一家言あるので、また今度書きます。
「記法の停止」は不採用。
偶然半角スペースが入る事態に出くわしたことがないのと、記法の停止が利用者にとって致命的ではないから。プレビュー画面で気づけばすぐ修正できます。それに、エスケープ記号は美しくないと感じるのです。
あと、自己改善ですが、[1]などで表す画像の[]を二重にすると、画像をクリックしたときに最大640*640pxの大きさでポップアップウィンドウが開くようにします。[[1]]という感じ。われながらいい記法表現だと思います。
各所に議論が巻き起こっている、大人気の幸之介記法です。まぁ、各所といっても若葉ちゃんとakくんの2ヶ所だけど。先日のブラッシュアップ直後にakくんが「幸之介記法 (2)」を書いてくれたほか、一日じらした甲斐があったか、より有益な記事をふたつも読むことができました（若葉ちゃんによる「Re: 引用のマーク付け」と、akくんによる「幸之介記法 (からちょっと逸脱)」）。
論点はblockquote要素のマークアップに絞られているようです（記法自体はもう論点から外れたっぽい）。
結局、若葉ちゃんの現在の結論はcite要素を中に入れるのかどうか明言されていないのですが、わたしとしては、blockquote要素がなにも直接的に引用そのものである必要はなくて、「引用したコト」のひとつの情報として、中にcite要素を入れることに抵抗はまったく感じないのです。唯一気になるのは、引用する文章の中に元々cite要素が入っている場合に峻別が難しくなる場合ですが、それを人間にも（もちろん機械にも）わかるようにするための努力は、blockquoteの外に出したcite要素をblockquoteと結びつけるためにする努力と、何も変わらないように思います。であれば、レアケースな前者を気にするより、後者から逃れられる方が楽ではないでしょうか。
ちなみに、この問題については『blockquote要素の中に出典を示すcite要素を包含すべきか』に関する議論リンク集に多くの意見が載っているようです。
そういうわけで、幸之介の＠のリニューアルに向けていろいろ考えています。すべてを考えています。
RSSへのリンクに与える見出しはどうすべきか。最初は「このページの更新情報」にしようと思っていたんですが、もとより更新情報はHTML上にも「更新履歴」として10件並べるつもりなので、峻別の意味でふさわしくない。というところから、よく見る「Syndicate this site」「このサイトと連携する」の意味を調べてみたり。きっと「わかりにくい」という指摘がオンラインにあるだろうと思ったら、案の定、「このサイトと連携する(XML)」ってなんやねん？という記事を見つけた。
現段階の結論としては、次期 Internet Explorer による一般へのRSSの普及もにらみつつ、「更新情報の配信」という見出しに決定。
ところで、現在の幸之介の＠の「新着情報」欄もそうなっているように、各ページそれぞれに、自分のページ以下の階層のすべての更新情報を、コメント（読者の声）も含めて載せるつもりです。RSSも、すべてのページに対してそれぞれ生成されます。
すると問題がふたつ。
既存のほとんどのブログは、コメントやトラックバックの更新情報と、新しく書いた記事の情報は別々の欄に載せています。わたしにはこれが「シンプルではなく、画面スペースと視線移動時間のムダである」と感じられるのですが、果たしてブログスタンダードと異なる仕様にすることによって、かえってユーザビリティの低下を招きはしないかという心配。
もうひとつは、現状もそうなのですが、読者からのコメントもひとつのRSSアイテムとして配信されることです。わたしには、サイトのあらゆる更新を受け取れるので便利に思えるのですが（むしろ、ふだんRSSで読んでいるひとでも、コメントをチェックするためにはWebサイトを訪れなければならないのは面倒じゃないのかしら）、これもまた、ブログのスタンダードとは異なる仕様です。
いまのところは気にしていませんけど。
細かいことまで考えています。
現在のタイトルロゴは特にフォントを指定していないので、WindowsならMSゴシック系のフォントで表示されているはずです。ひょっとしてマックOSXのひとには美しいヒラギノで表示されているんでしょうか。見てみたいなー。
さて新しいロゴ。テキストにするか、画像にしてしまうかについて、けっこう悩みました。テキストのほうが、閲覧者がサイトタイトル文字をコピーしやすいし、文字サイズを可変にできるというユーザビリティ上の利点があります。しかし、閲覧環境によってフォントが変わる上に、MSゴシックはなかなか美しくない。というわけで、しぶしぶながらも美しいフォントを使って画像にしてしまうことにしました。
当初は書道家の武田双雲さんにロゴを作っていただくのもカッコイイかなと思ったのですが、あの迫力はちと目指すイメージが違う気がしたのと、自分でデザイン可能という汎用性を考えて、市販フォントで作ることにしました。で、オリジナリティのあるところでナウ書体も捨てがたかったのですが、これまたやはり汎用性を考えて、広く普及していて、かつウェイトバリエーションの豊富なヒラギノを採用しようかな、と思っています。個人サイトとしての「幸之介の＠blog」のほか、事業サイトとして作る予定の「幸之介の＠enterprise」、あとは名刺とかにも使うつもりなので、気合いの入った決断なのですよ。こんど買ってくる！
なお、この画像はヒラギノ角ゴシックW3に似ている、ナウ-GMで作ったロゴ。まぁキレイだよね。
現在の幸之介の＠のロゴですが、やまだくんやakくんから、マックでの見栄えを見せていただきました。ありがとう。そして次期ロゴについては、ヒラギノ角ゴシック体W3と、ナウ-GMと、新ゴLの3フォントを候補として、あらためて超悩みました。雑誌 Web Site Dseign Vol.7 のフォント特集のほか、ウェブにおけるフォントのヒントやもじマガ_文字の巨人といったサイトも参考にしつつ、果てはフォントの分かる男まで読み返して悩みました。
新ゴについては友達の彼女さんにご協力をいただいて、「幸之介の＠」を書いていただきもしました。画像は上から順にヒラギノW3、ナウGM、新ゴLです。若干気になる文字が見受けられますが、よくあることです。
さて、まず「幸」の文字で、ヒラギノで4画5画目が離れているのがややイケてない。ナウはわずかに重心が高いがOK。新ゴはふくよかで良好。
そして「＠」は、ヒラギノはわずかに手書きの味を残している。ナウは真円に近くイメージに合っていて好印象。新ゴは残念ながら線が他の文字よりも太く、形もややテクノ系フォントに似ている。
ナウと新ゴは、これらの文字に限らず全般にわずかに重心が高いが、むしろ好印象。文字のふくよかさでは、新ゴが抜きんでている。
価格面ではヒラギノが3ウェイトで2万円、ナウは2ウェイトをすでに持っており、新ゴは1ウェイト2万円。
ヒラギノはウェイトも豊富で明朝などの書体も同系統で充実。ナウはウェイトがやや少ないが、新世代明朝のナウMファミリーがあり、すでに持っている。新ゴはウェイトは多いが同系統はゴシックのみ。
ヒラギノはマックOSXに標準添付されて普及しまくり。ナウはそうでもない。新ゴはDTP界で普及しまくり。
というわけで、いずれも数長数短です。タイトルロゴに含まれる「blog」の文字や、名刺に含まれる数字なども考慮したのですが、やはり最も重要な「幸之介の＠」が美しく見えるかですべてを判断することにしました。
結果、ナウGMを採用することにします。ヒラギノ、新ゴ、さようなら。
しかしまぁ、サイトのタイトルを画像にすることで、すんなりテキストとしてコピーできないとなると、サイトを紹介されるときにますます「助」の間違いが起きそうだな…。
（Webサービスにおける）この法則は、わたしにとってたぶん非常に強固で、幸之介の＠2.0のブログシステムも、そのリンク元アクセスランキングのしくみも、その記法のHTMLへの変換も、すべて既存のツールやプラグインを使ったりするのがイヤで、自分で作らないと気がすみません。それはコード単位でも、どこかから参考になるコードをペタッと持ってくるようなことは気持ち悪くてできないし、正規表現ひとつにしても、中身を把握していないものはコピーしたくないのです。
すでにある優れたものを使わないのは決して能率的ではないのですが、自分の思うがままにカスタマイズできるし、なにより自分の技術力を高めるいい動機付けにもなってくれるので、好きな自己特性のひとつです。
まだ一歩も踏み入れていないAjaxも、prototype.jsなんて使わずにゼロから自分で書けるものなら書きたいくらいです。少なくとも、prototype.jsの内容は完全に把握してから使いたい。そもそもまだJavaSciptもよく理解してないんだけど（笑）。
いまのところ、ページを表示してから書き込みボタンが押されるまでの時間が短いものを弾く「10秒ルール」と、NGワードのブラックリスト方式のふたつで対抗する予定です。あと、書き込みには必ず確認画面を挟むようにします。
しかしこれでは、相手が10秒ルールを学習していた上での初回の書き込みを弾くことができません。そこで、「書き込みボタンを10個用意して、うち正しく書き込めるのは1つだけ」という方法も考えました。9つ用意されたダミーの書き込みボタンをすべてスタイルシートで隠すことによって、相手が人間ならちゃんと正しい書き込みボタンを押せるというわけです。もちろん正しいボタンの位置は、動的に生成されるスタイルシートと共に毎回ランダムで変わります。
HTMLにダミー要素が加わるのがちと美しくない気もしますが、書き込みの確認画面だけに実装するなら、許せる範囲でしょう。また、スタイルシートを読まないブラウザでアクセスされた場合は、断りのメッセージと共に、管理人の承認後に書き込みが反映される書き込みボタンを11個目として表示させます。
とはいえ、がんばるスパマーがスタイルシートを解析するようになれば、この方法もうまくいかなくなります。根本からのスパム対策はふた通りあって、ひとつは、スパマーが手動で対応しなきゃならないような対策を、自動でいくつでも生成できるしくみ、「自動いたちごっこシステム」。もうひとつは、スパマーがAに対応している間は必然的にBには対応できなくなるしくみを使って、AとBが自動で切り替わっていく「あちら立てればこちらが立たずシステム」。しかし、いいアイディアが浮かびません。
スケジュール押し気味でしたが、だいぶスピードに乗ってきました。
日が昇る前までに記事の作成とトップページの閲覧部分までだけでも公開できないかなぁ〜無理だなぁ〜。
以下、本ブログシステム（名前決まらん）の特徴。
■カンタン操作、シンプル設計
機能を削ってでもシンプル設計を重視しました。面倒な設定は、できるだけしなくてもすむように、見せないようになっています。
■記事はすべてツリー構造
個別の記事それぞれに対して、子記事を作成することができます。親記事は、カテゴリの代わりとしても使えます。
■いくつかの記事を「一連の記事」としてまとめられる
上下関係になるツリー構造とは別に、ある記事に対する「続きの」記事も作成可能。ミニトマト栽培日誌のようなシリーズが簡単にまとまります。
■複数人で管理できる
記事を作成できるユーザーを複数登録できて、個々の記事にはその記事を作成したユーザーのプロフィールが載ります。
■便利な記法
独自仕様ではありますが、ユーザビリティを重視したつもりだぜ。
■速い
現在の幸之介の＠と同様の速さ。既存の商用ブログに比べればかなり速いでしょ。
