Hatena::agenda

CSS、HTML、XHTML、XML、DOM、XSLT、XPath、ECMAScript、Python、ウェブユーザビリティ、その他に関連する文書等のリソースを挙げていったりします。より本質的な議論を志向。
注意:Hatena::agendaの更新は終了しています!過去の記事はagenda のホームページよりどうぞ。今後の更新情報の取得は、agendaのフィード(XML/Atom)から。

 |  

2007-08-30 -moz-column-*系プロパティが真価を発揮するとき

しまったなんで気づかなかったんだろう。いやこの糞ぶろぐでリキッドマルチカラムをやるというのが無謀というかそりゃデメリットがあり過ぎるだろ何を今更っていうツッコミはやる前から重々承知していた。-moz-colomn系のマルチカラムは文章量によって適切な指定が異なるから、文章量の不定なHatena::agendaに適用させても縦スクロールを要求してしまう記事も出てくるんだ。そうではなくて、-moz-column系プロパティを、どうして今までGoogle検索結果ユーザースタイルシートとして使わなかったかってことだ。つまりコンテンツの物理的な量が概ね分かっていて、かつその量を閲覧者が調節できて、かつ一覧性が重要なものに対して、-moz-column-widthプロパティは適切なスタイル指定となる。

@-moz-document domain("www.google.com") {
div#res{
  -moz-column-width: 25em;
  -moz-column-gap: 1em;
}
div#res table {
    width: 100%;
}
}

人によってはgoolge.co.jpかも。よく分からなかったらStylishとか使えば幸せになれるかも。ウィンドウを最大化してGoogle。UXGA以上推奨かな。WXGAのノートでも相当使い勝手がいいけど。フィットしなければ表示件数を調整すべし。

今まで様々なブラウザを同時に使ってきたし、特定のブラウザを薦めるということはしなかった。だが今は敢えて言おう。Firefoxこそ真のウェブブラウザであると。こういうことが出来てこそウェブブラウザだ。まあ明日になったら気が変わっていると思うけど。わらい。いやーなんで昔検証したとき気づかなかったんだろう馬鹿だな自分。

追記。縦書きならリキッドなマルチカラムの弱点が消えるという話。Re:-moz-column-*系プロパティが真価を発揮するとき 及び Re:リキッド・マルチカラム考察 (インターネット帳面)。そもそも一寸した縦スクロールが本当に問題なのかという示唆もあり。

Hatena::agenda - Googleをマルチカラム環境に最適化するに続く...

2007-08-29 本物のリキッドレイアウト - 補足

Hatena::agenda - 本物のリキッドレイアウトの続き。

リキッドなマルチカラムの実例

Hatena::agendaは実験場ではないけれども、CSS3 Columns - MDCで紹介されているmozilla独自拡張プロパティを使用してリキッドマルチカラムにしてみた。デメリットもかなりあってまだ改善の余地があり余っているものの、場合によっては低解像度から高解像度まで、シングルウィンドウから並行閲覧まで手広くカバーできる。

このプロパティを実装していないブラウザ向けに、一応スクリーンショットを用意してみた。

念を押しておくが、-moz-で始まる独自拡張プロパティは、正しく使えば問題ない。これはCSS validatorを通らない。しかしCSS実装は、不明なプロパティは無視しなければならないことになっているし、事実上-moz-で始まるプロパティを他のベンダが重複して定義することなどない。一部の似非W3C信者に騙されないように。

高解像度も視野に入れるのが本物のウェブデザイン

Liner Note - リキッドカラムデザインの実験 :実践1カラムテクニックス(3)より引用:

今まで「どの解像度環境を最低基準にしてデザインを進めるか」ばかりが注目されてきて、「高解像度環境」ではそれに見合ったメリットが得られないどころか、逆に見づらくなるデザインも散見されてきたと思います。*

笑えるのは、それを率先してやっているのが専門家だという事実。情報デザインの何とかとか、ウェブユーザビリティの何とかを自称する連中だ。おかげでPersonnelに影響されました!とか言っていた人も釣られて固定幅に改悪してしまった。

私は固定幅デザインを絶対にウェブデザインとは認めない。だって、様々な媒体を選択可能なウェブの特性とは何の関係もないもの。そういった無数の固定幅デザインを各媒体向けにサーブする技術の一部としてありかもしれないけれども、それ単体をウェブデザインと思い込んでいるのは大間違いだ。特に日本ではウェブユーザビリティの専門家を名乗る連中がこれをやらかし始めている。リキッドレイアウト、及びウェブデザインというものの本質を最初から理解していなかった証拠だ。彼らが一時的にリキッドレイアウトを採用したのは、単にそのころ800×600px程度の低解像度モニタの利用者が、1024×768pxと同程度に存在した為、両者の都合に合わせてみたからに過ぎない。つまり彼らは、ウェブデザインをやっていたのではなくて、800×600pxと1024×768pxの二つにマッチさせようとしていただけなのだ。だから今になって800×600pxの解像度がマイナーになって一つの解像度に分布が集中するやいなや、笑止、態度を豹変させて待ってましたとばかり安易な固定幅デザインに移行したというわけだ。

Hatena::agenda - -moz-column-*系プロパティが真価を発揮するときに続く...

2007-08-27 本物のリキッドレイアウト

どうやら世の中の「リキッドレイアウト否定派」はリキッドレイアウトの真の姿をまるで知らないらしい。想像力が足りないのだろう。リキッドレイアウトというのは、ウィンドウ幅を小さくしても横スクロールバーがでないとか、本来そんなちんけなものではない。

リキッドレイアウトを否定するというのは、ウェブデザインを放棄することと同義だ。固定レイアウトというのは、例えば1024*768px向けデザインとでも言うべき代物で、ウェブデザインと呼ぶに相応しくない。

本物のリキッドレイアウトは隙間に流れ込む水のような振る舞いをする。Hatena::agenda - ブログのサイドバーは要らないではサイドバーを否定したが、実は一つ例外がある。本物のリキッドレイアウトを採用しているなら、サイドバーも有用となり得るのだ。

もちろんサイドバーとは何かを知っていなければならない。簡単にいえば、サイドバーのようなインターフェイスは、ユーザーのタスクの完了を補助するために使用できる。言い換えると、ユーザーが、今見ているメインの領域ではタスクを完了できない場合に、ユーザーをタスク完了のための適切なコンテンツにナビゲートしたり、ヒントを与えたりする為のある程度柔軟性のあるスペースとなり得るのが、サイドバーである。要するに意味不明なぶろぐぱーつや全然関係ない広告でなければそれでいい。

まず本文の部分はCSSでいうところのmax-widthプロパティが指定されたようにふるまう。閲覧者のウィンドウ幅が充分広くなると、当然左右、あるいは左右どちらかにスペースができる。そのスペースがある一定以上の幅になったとき、そのスペースに、それまで本文の下部にあった(あるいは異なるURIをもつ外部にあった)補足情報などがサイドバーとして登場する。つまり、ウィンドウをたくさん並べて並行閲覧していても、あるいは低解像度のモニタで閲覧しても、本文がキチンと表示されて利用しやすいリソースとなり、一方、高解像度のモニタでウィンドウを大きくしてみる閲覧者には、その投資に見合ったそれ相応の利益がある。

リキッドレイアウトのもう一つの有用な姿を。現在のウェブブラウザのページのメタファは、未来の利用者、あるいは現在のハイエンドな高解像度モニタ利用者にとっても本当に酷いものだ。あんな最低な縦スクロールで長い文章を読む気になるのは、他に選択肢がないからだろう。しかし本物のリキッドレイアウトは違う。あまった隙間に、今までスクロールして見ていた部分が流れ込むようになるのだ。本の見開き一ページのメタファを持ったスタイルシートをかぶせることも容易になる。もちろん閲覧環境によって1カラムだったりするし、場合によっては3カラムにも変化する。

実装について考えると、HTML5などという馬鹿げた進化の痛手を被る必要は全くない。本物のリンクタイプを色々追加して標準化してしまえばよいだけの話だ。例えば、margin:autoの隙間へリンクタイプ「contents」の外部リソースを自動で流し込むとか。ああ、「contents」は元々あったっけ。じゃあ今すぐにでもできるだろ。ついでにarticle要素とやらも、相当するclass名を標準化してしまえ。それで後方互換もバッチリだ。まあ私に言わせればarticle要素というのはbody要素のことだけどな。わらい。iGoogleかなんかでは「ぱーつ」をポンポン放り込んでカスタマイズできるようだけれども、全てのウェブページで出来たほうが圧倒的に便利。右上には「author」というタイプでリンクされた外部リソース、左側には同様に「contents」とか。全てのウェブページで同一の構成を保持できればもう迷うこともないだろう。

つづき

2007-08-24 リキッドレイアウトの弱点を克服

リキッドレイアウト採用にあたって問題点を再検討してみた。ブラウザで解決できる問題だとは思うので、リキッドレイアウトに起因するデメリットではないが、少なくとも現在ある問題としてこれは明らかにまずい。

  • ブラウザのサイドバーを利用するなどしてメイン領域の幅を変更すると、文字の表示位置が大きくずれ、読んでいた場所が分からなくなる。

今のところ回避方法としては、内容が長大な場合には複数のページに分割するなどして縦方向のスクロールを多く要求しないようにすることくらいしかないが、よく考えてみればそれはウェブデザイン的に結構基本的なことだったりする。

ここで陥ってはならないのが、逆も真(謎)と思い込んでしまって「ある程度縦長にならざるを得ない場合には幅固定の選択肢もあり」と判断してしまうミス。複数のページに分割とは、何も物理的に分割しなければならないわけではない。こういう止むを得ない状況を打破するためのCSS + Javascriptであり、スライドショーのような方法で解決できる。

2007-08-23 全文掲載の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で記事を探せるようにしてある。

2007-08-22 ウェブサイト運営方針を考える(長文注意)

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

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

2007-08-19 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コードが書ける。したがってよく使う関数を複数定義しておいて、簡単に呼び出す、ということができる。

続きは後ほど。

2007-08-17 コンテクストメニューの役割

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

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

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

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

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

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

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

2007-08-14 はてなスターの消し方

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」を使はずに「はてなスター」だけを無效にする

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

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

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

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

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

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

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

2007-09-21追記。

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

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

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

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

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

 |