ナビゲーションとは何か、そしてそれは「分離」すべきなのか (agenda)が抽象的すぎるので補足。まずは最初の段落から。 しかしながら、製作者側はユーザーの目的を正確に知ることができない。知っているのはユーザーがそのハイパーテキストノードを閲覧しているという事実だけであり、そこから目的地を推測するしかない。この時推測される目的地は、正にそのハイパーテキストノードと深く関係しているはずだ。そして、そのようなリソースへのリンクを提供することは、ハイパーテキストシステムにおける各ノードの主要な役割である。真のナビゲーションに接近する方法として、製作者側が取れる、あるいは取るべき手段は、そのハイパーテキストノードを中心としたリンクを提供してやることだけである。私はこのようなリンクを論理的なリンクと呼んでおり、殊更にナビゲーションと呼んでコンテンツと区別しない。何故なら、論理的なリンクはハイパーテキ

追記の前に、ブックマークコメントに関して少し。 はてなブックマーク - vantguarde - 2009年1月31日より。 何故なら、論理的なリンクはハイパーテキストノードにとってコンテンツと同義といっても過言ではないからだ。 コンテキストから対象リソースへの関係を明記すること/明記したもの、ってことかしら。 ユーザーという人間に対してreasonableなリンクであるということであって、この文脈ではメタデータが付加されているかどうかが本質でなく、そもそもハイパーテキスト記述言語「HTML」が未熟なので、豊富な関係性をソフトウェアに伝えることはできない。 はてなブックマーク - Metalog（メタログ） - 2009年1月31日より。 WWW全体を俯瞰するような視点に基づいた総合的なナビゲーション WWWブラウザがWWWに自律的にアクセスし、その文書のトピックがWWWでどうあるかリンク

WWWの文脈においてナビゲーションという言葉の意味を考えるとき、浮かんでくるのはやはり一人一人のユーザーの姿である。それぞれのユーザーの目的地（目標）に導いてやるためのインターフェイスというのがナビゲーションのエッセンスだ。 文書製作者側が提供できるナビゲーション しかしながら、製作者側はユーザーの目的を正確に知ることができない。知っているのはユーザーがそのハイパーテキストノードを閲覧しているという事実だけであり、そこから目的地を推測するしかない。この時推測される目的地は、正にそのハイパーテキストノードと深く関係しているはずだ。そして、そのようなリソースへのリンクを提供することは、ハイパーテキストシステムにおける各ノードの主要な役割である。真のナビゲーションに接近する方法として、製作者側が取れる、あるいは取るべき手段は、そのハイパーテキストノードを中心としたリンクを提供してやることだけであ

 CSS3 モジュール： マルチカラムレイアウト 2007-06-06 W3C 草案 原文 http://www.w3.org/TR/2007/WD-css3-multicol-20070606 原文の編集者 Håkon Wium Lie, Opera Software, howcome@opera.com 訳注 Jintrick.netによる意訳です。正確な情報と異なる可能性に留意してください。 Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply. 概要 このモジュールは、CSSにおけるマルチカラムレイアウトを説明する。これはCSS3ボックスモデルモジュールに基づいており、要素の内容を複数行にする機能を追加

まとめて(答え|応え)てみるテスト。まずはてなブックマーク - マルチカラムとウェブ・ユーザビリティ (agenda)のコメントに対して。 スクロールのコストってそんなに高いと思えない。 テストすべし。 全文が見えていると概要をつかめるという理屈も謎。 それは私の書いた条件節を脳内で消している為。 まー結局好みの問題ですしね。 まあそうだが、程度の問題として、Firefox3のCSS3 multicol先行実装はほんの一部であって十分ではないとか、agendaがビジュアルやUIに全く無頓着である等々、様々なマルチカラムの本質以外のバイアスがかかっている可能性は十分にある。たとえばbookreader.jsははてなブックマーカにも「読みやすい！」と好意的に受け止められている。 マルチカラムが有用ってことを言えるわけではない。 どのようなgoalに対しての「有用」なのか。多くのgoalに対して

ウェブページの文章を読むときは「上から下へリニアに」というスタイルが一般的というか、恐らく99.9％がそうだと思う。マルチカラムで読んだ人がその慣性から引き剥がされて不快感を覚えたとしても不思議はない。視線を下への移動だけでなく上にも移動させるという、いつもと違うことをしなければならないというのは、それだけでユーザビリティ的に問題を引き起こす要因となり得るだろう。しかし、必要な「技術」は視線を移動させることだけだ。スクロールは必要ないし、マウス操作も必要ない。マルチカラムに関して生じているウェブ・ユーザビリティ的問題は、結局のところ主観的満足度の低下だけだと私は想像している。私が主観的満足度よりも重視しているのは視線の移動を失敗したりせずに「内容をきちんと読めたか」、そして「どのくらいのスピードで読めたか」。この2点。もともとスクロールが発生しないほどの短い文章ではマルチカラムが敗北するが

「ウェブアプリケーションのGUI以外にposition:fixedを使わないよーに。」 ウェブログにおいて記事が主役である限り、ナビゲーションにposition:fixedを使うのはreasonableとは言い難い。馬鹿げた縦幅を持つサイトロゴ部分＋ナビゲーション部分をスクロールで消して記事を読もうとしたら、そいつらがくっついてくる。こいつは本当に頭に来る。かといってそういうサイトをブラウザデフォルトのスタイルシートで閲覧すると、ナビゲーション用の画像がリストとしてズラズラならんでしまって、さらに記事に辿り着くのが面倒になるんだ。まあ仕方ないんだけど、あの「ナビゲーションバー」のどこがUL要素なんだよって言いたくなることがある。 ユーザにとってウェブログはハイパーテキストアプリケーションの一種だ。それを操作するためのグラフィカルなインターフェイスは、ブラウザのボタンなりメニューなりに集約さ

スタイルシートの文脈で文書指向ウェブデザインを説明すると、文書を読みに来た閲覧者のみをターゲットにしたデザインということだ。正式版をjintrick.netで公開する前に1時間で書いたプレビュー版を糞ブログに「流して」おこう。 前景色は黒（#000）、背景色は白（#FFF）にすることで、より確実な可読性を確保できる。眩しくて読みづらいというよくある批判に対する答えはこうだ： モニタの輝度を落とせば良い。 モニタの輝度を落とさなければならない状況が考慮されていない。 特に後者はまだ誰も言及していないんじゃないかな。 左右のマージンを小さくすることで、より幅広い状況に適応できる。相対指定の2～3%程度で十分だろう。それでも左右が詰まっていて息苦しいという批判に対する答えはこうだ： その閲覧者はデザインを眺めに来たのであって、文書を読みに来たのではない可能性が高い。 CSSにおけるmax-wid