• Multicol Google Search 2010-05-10 (GMScript本体)
• スクリーンショット

Firefox3.5から-moz-opacityプロパティが廃止されていたようなので、CSS3のopacityに変更した。

Googleの新しいフィーチャーは全て却下というか、取り入れていない。検索オプションなんかも自分は滅多に変更しないんだし、必要ならGoogleのロゴをクリックして「検索オプション」というアンカーをクリックすれば済むことかなと思った。

さて、新しくなったGoogleの検索結果画面だが、左側にサイドバーが設けられたようだ。上段が同じ検索クエリに関する書籍、画像、地図等の検索結果へのリンクで、下段が検索結果の絞り込みに関するリンクとなっており、検索結果に密接に関連するリンクではあるので、無駄ではないと思う。

問題は相変わらず固定幅のために、必要な横幅がサイドバー分だけ広がった点にある。Googleの検索結果をブラウザのサイドバーに入れ、結果アイテムをメインフレームに表示するようなブラウザ側の応用に対してますます使いにくくなった。 ]]> http://jintrick.net/agenda/2010/05/multicol-google-search-googles.html http://jintrick.net/agenda/2010/05/multicol-google-search-googles.html Google リキッドマルチカラム Sun, 09 May 2010 13:31:52 +0900 はてなブックマークFirefox拡張をインストールしてみた。

まず「ユーザー」と「はてなブックマーク」との架け橋（UI）はツールバーとステータスバーがこれを担っている。デフォルトの設定ではポインティングデバイス依存で、代替手段が提供されないが、ツール→はてなブックマークから色々設定を変更できる。ここまでは別にいい。しかしキーボードショートカットを変更する手段がまたポインティングデバイス依存なんだよ。こんなUI見たことも聞いたこともないよ。入力欄を「クリック」すると（「アクティブ」じゃあない）、「キーボードを押して、ショートカットを設定します」というモーダルダイアログ系がポップアップされる。これには「キャンセル」ボタンがついていて、押すとこのポップアップ表示が消える。問題はショートカットの入力を受け付けるのは、このダイアログがポップアップされているときだけだという事実。俺はこんなUIをみたことがない。ポップアップして警告しなければならないのは、設定ダイアログの最後に小さく表示されている「ショートカットの反映に、ブラウザの再起動が必要な場合があります」という文句、それだろう。

はてなブックマークサイドバーは、一部期待された動作をしない。現在表示されているウェブページのタブをドラッグドロップしても何も起こらん。だったら、フォルダのアイコンを用いるべきではない。これは、何かを格納できることを示唆するときに用いるべきものだ。タグはツリー構造のデータでないから、これにフォルダのメタファを使うべきかどうかも、俺には疑問。ユーザビリティ的にも多分間違いだろう。期待されている動作と異なるからな。Microsoftがフォトギャラリーでやっている方法の方が概念をうまく表現できている。

ティム・ガン風に言うと、「洗練されてない」。

• はてなブックマーク Firefox 拡張のベータテストを開始します - はてなブックマーク日記 - 機能変更、お知らせなど

「はてなブックマーク Firefox 拡張」を開発する上で、「はてブユーザー」の意見を聞くべきではない。理由：

• はてなブックマークをすでに利用している人間が、より便利に利用できるようにはなるかもしれないが、新しいユーザーを獲得するための直接的な方法ではない
• ユーザーの「意見」にはバイアスがかかる。ましてやコアな「はてブユーザー」は一般的なユーザーとはまったく違った使い方や習慣、癖をもっている可能性がある。

「バグ報告」だけを聞くべき。

ではどうすればよいか。さっさと公開したい記事なのでとりあえず一言で済ましておく。「ユーザビリティの専門家にご相談ください」。]]> http://jintrick.net/agenda/2009/04/-firefox.html http://jintrick.net/agenda/2009/04/-firefox.html Firefox ブックマーク ユーザビリティ Fri, 03 Apr 2009 03:56:30 +0900 追記の前に、ブックマークコメントに関して少し。

はてなブックマーク - vantguarde - 2009年1月31日より。

何故なら、論理的なリンクはハイパーテキストノードにとってコンテンツと同義といっても過言ではないからだ。 コンテキストから対象リソースへの関係を明記すること/明記したもの、ってことかしら。

ユーザーという人間に対してreasonableなリンクであるということであって、この文脈ではメタデータが付加されているかどうかが本質でなく、そもそもハイパーテキスト記述言語「HTML」が未熟なので、豊富な関係性をソフトウェアに伝えることはできない。

はてなブックマーク - Metalog（メタログ） - 2009年1月31日より。

WWW全体を俯瞰するような視点に基づいた総合的なナビゲーション WWWブラウザがWWWに自律的にアクセスし、その文書のトピックがWWWでどうあるかリンク網を構成するようなイメージかな / たぶんあとで修正する

私のイメージとしては、WWWブラウザがウェブサービスを応用することで現在閲覧しているリソースに関係しているリンクや情報を様々な形提供したり、またはブラウジングの傾向からユーザーの嗜好、次に何を求めるかを推測してリンクを提供する、など。前者については現在でも（応用例としてはあまり良いものではないが）、GoogleツールバーがPageRankを表示してそのウェブページの信頼性に関する情報を提供したりしている。後者については、文字列等を選択したときに、それが英単語であれば辞書の結果に素早くリンクする、など。とにかく書ききれないし、また本題ではないのでこれくらいに。

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

たとえばそのサイトのホームページを閲覧しているユーザーに対しては、そのサイトについてより知ろうとする動機を推測することができるため、グローバルナビゲーションをはじめとした豊富なナビゲーションを提供することができる。サイト内の文書へのリンクはすべて論理的なリンクである。逆にただの一記事であれば、その記事に類似した文書や記事の著者に関する情報、コンテクスト等へのリンクが論理的であり最も目立っていなければならないが、全然関係のない同サイト内の別セクションに導く「グローバルナビゲーション」は非論理的な邪推に過ぎず、広告に近い。

非論理的なリンクは全て、ナビゲーションではない。それはユーザーを彼らの目的に導くものはなく、新たな目的を持たせるよう誘導しようとするものだ。広告と大差ない。広告的なリンクを否定するつもりはないが、ナビゲーションとは峻別すべきだ。ナビゲーションのあるべき本当の姿を考察するとき、「広告」を一緒くたにしてはいけない。

文書製作者側が提供できるナビゲーション

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

cf. 一方で、今、一般的な意味でウェブサイトの「ナビゲーション」と呼ばれているものは何か。それは文字通り「ウェブサイトのナビゲーション」であり、ユーザーのものではない。ユーザーの目的に導くよう設計されたものではなく、ウェブサイト内をうまく渡り歩いてもらうためのものだ。もちろんベン図を描けば論理的なリンクとかぶるところもあるだろうが、指向しているもの自体が違う。

WWWブラウザが提供できるナビゲーション

WWWブラウザには、現在ユーザーに提供しているハイパーテキストノードを中心としたナビゲーション（論理的なリンク）だけではなく、WWW全体を俯瞰するような視点に基づいた総合的なナビゲーションも要求されるし、その中間的なものもあって良い。あまりにも多岐にわたるので一々例示できないが、製作者側が提供すべきナビゲーションと峻別する意味で、認識しておきたい概念だ。

WWWブラウザが提供するナビゲーションは、あらゆるハイパーテキストノードに対して同質のものを提供できるという点で製作者側それぞれのものと異なる。これはどういうことか。WWWブラウザが提供可能な、あるナビゲーションについて考えると、あらゆる場面において、製作者が用意するという手法に対して優位であることを意味している。

文書製作者が提供すべきナビゲーション

ほとんど自明だが、文書製作者が提供すべきナビゲーションは、WWWブラウザが提供していないもの（本質的には、提供「できない」もの）ということになる。

多分追記する。 ]]> http://jintrick.net/agenda/2009/01/post-442.html http://jintrick.net/agenda/2009/01/post-442.html ウェブデザイン ユーザビリティ （ハイパー）リンク Sat, 31 Jan 2009 01:01:49 +0900 deadspaceにモロに影響を受けて、気軽に書ける見出しのないウェブ日記っぽいものをやってみようと思った。「書いて、公開する」というストレスを軽減すること、つまりスピードを最重視し、ほとんどデザインのことを何も考えず、システムレス、メンテナンスフリーで運営できるのにもかかわらず、何故か言及、参照、再利用ができないこともない、というコンテンツを目指す。後方互換性を完全に無視し、前方互換性はある程度考える。ウェブアクセシビリティは以上の特長を妨げない限りにおいて考慮する。完璧主義はごめんだ。以上が理念。具体的には以下のようにする。

記事形式について

各記事はリストアイテムとして羅列する。文字数制限なし。時には長文を書くこともできるし、object要素を経由して可能な限りのフォーマットが使用可能。ブラウザの実装は無視して表現を優先する。後方互換性より前方互換性を優先する。

今回はXMLアプリケーションを使う必要が出てくる可能性が高いので、XHTML形式を採用する。当然XHTMLを手書きするなんて馬鹿なことをするわけにいかないので、XHTMLインスタンスを吐くソフトウェアを探さなきゃならないが、色々面倒くさいのでいつものように省略文法HTMLを書いてTidyに通す。

配信（RSS）はどうする?

RSSに関しては、静けさの空き地で知ったPage2RSSを利用させていただく。だからRSSを吐くソフトウェアを自前で用意する必要なし。RSSというフォーマットは完全に腐っちゃってるし、バージョン等にこだわる必要なしとする。RSSリーダーで記事全文を追えればそれでいい。

パーマリンクはどうする?（←今ここ）

分散、集合の程度は決定しなければならない。

各記事はリストアイテムだが、各アイテムに対して一つのURLを提供した方がいいのか、それとも月単位で提供してURI参照すら与えずにいくか、云々。前者+XHRでコンテクストを提供すれば流れも含めて読めるかな。後者は楽で最高だが、XPointer使えとは流石にまだ言えないわな。自分自身もう忘れちゃったし。実装どうなってるのかも知らないし。

DOM3の良い実装があれば、システムもなにもPythonスクリプトを少し書けばOKなので、そこを確認してから決める。

というわけでもうちょっとだけ考える。昔ながらのあのウェブ日記の「スピード」と「軽さ」に、ついていきたいけど全然ついていけない。はてなブックマークとかtwitterとかじゃ表現しきれないんだよなー。

この「メモ」、公開すべきかちょっと微妙だ。もう少しまとまってからにした方が良いのではないか。とか何とか。うざー。]]> http://jintrick.net/agenda/2009/01/post-441.html http://jintrick.net/agenda/2009/01/post-441.html ウェブデザイン Wed, 14 Jan 2009 02:05:41 +0900 var要素をプログラムコードではない通常の文章に使った例文を以下に挙げる：

私はこのようなvar要素を「散文的変数」と呼んで愛用している。

というか、ウェブブラウザの正義って、どれだけ多くのウェブコンテンツやウェブサービスを利用できるか、その1点がほとんど全てだと思うのだけれど、レイアウトエンジンを選択できるブラウザって過去いくつか出てきているのに、どれもパッとしなかったな。レイアウトエンジンそのものが成熟していないからかな。

IE6に気を使わなくてもいい理由とか「そういう系」 の話を聞くと、なんで非営利個人サイトが自分の嫌いなウェブブラウザなんかに一々気を遣わなきゃならないんだとか思う。もちろん気を遣うのには色々理由があるだろう。だが「気を遣わなくてもいい理由」というのもあっていいんじゃないか。そう思ってだらだらと悪文を書いてみた。本当に悪文だからまとまりはないよ。

相手にしていられないほど膨大な種類の「ウェブブラウザ」

この文脈においてはウェブブラウザではなく、所謂レイアウトエンジンやHTMLパーサの種類を把握すべきだろう。たとえばSleipnirもfubも、同じMSHTML.dllを利用しているなら一つとしてカウントできる。

ウェブページのレイアウトエンジン

レイアウトエンジン等の名称	主なバージョン（2009年1月現在）	応用しているプロダクト他
MSHTML（Trident）	4.0系, 5.0系, 5.5系, 6.0系, 7.0系, 8.0系（系統別に多数あり）	Internet Explorer（Windows版）、IEコンポーネントブラウザ各種
Tasman	未調査	Internet Explorer 5 for Mac
Gecko	1.9.1まで多数あり	Firefox他のMozilla系ブラウザ
KHTML	未調査	Konqueror、KHTMLはWebkit他のレイアウトエンジンのベースにもなっている
GtkHTML	3.0.10	Evolution他GTK+アプリケーション
WebKit	r12084～r39572まで多数あり	Safari, Epiphany, Google Chrome, Omni Web, Adobe Dreame Weaver CS4, Adobe Air他
Presto（Opera）	2.2まで	Opera（7以降）, Nintendo DS Browser, Internet Channel（Wii）他
iCab	未調査	iCab 1-3
Prince XML	未調査	Prince XML（CSS対応レンダリングエンジンを搭載したPDF変換プログラム）
Boxely	未調査	AOL Explorer、他AOL系ブラウザ
NetFront	未調査（多数の系統あり）	i-mode、 PSP、Dreamcast他
NetSurf	未調査	NetSurf
Gzilla	未調査	製品未調査（Gzilla is a web browser written in the Gtk+ frameworkとのことなので個人開発は多数ありそう）
Tkhtml	未調査	Hv3などのTkアプリケーション
HTMLayout	未調査	参照：HTMLayout - Wikipedia, the free encyclopedia
Links	0.80～0.99まで多数あり	Linksの他、 応用したELinks、Links(2)、Links Hackedがある
Lynx	2.8.6まで	Lynx
w3m	0.5.2まであり	w3m、w3m-mee

この他にもいくつかあるが、無名なアプリケーションしかないものは除外した。Javascriptエンジンはまた別だったりする場合がある。また、スクリーンリーダーもここでは除外している。要するに、HTMLをパースする（そしてレンダリングする）ソフトウェアは、数えきれない。

こんなものに一々一々気を遣っていられない。実際に「気遣い」できるのは本当に極一部の、メジャーなブラウザだけだろう。そのメジャーなブラウザだって1年や2年で変化していくのだから、気を使う「必要」はないだろう。とりあえずHTML文書が壊れていないことを確認すれば、あとはソフトウェアが適当に処理してくれるのを信じるしかない。何かとバグがつきもののCSSだが、凝ったことをするのなら、自分が確実に確認できるレンダリングエンジンに対してのみ適用されるような配慮をすればいい。

ウェブブラウザに気を遣わずに済む方法

極論すれば、CSSやJavascriptなんか使わなければブラウザに気を遣う必要は激減するわけだ。これは「すっぴん」で公開しろと主張するわけではなくて、先述したとおり、自分が確実に確認できる、あるいは確認するレンダリングエンジンに対してのみ、CSSやJavascriptが有効になるような配慮をすればいい。そういう配慮が不可能なレンダリングエンジンに対しては、「すっぴん」でいいんじゃないかと。

私の場合、UTF-8を扱えないソフトウェアを完全に蹴るという政治的判断はあるものの、それ以外の部分では上述したような方針を取ってできる限り互換性を追求したいと思っているので、いつかやると思う。

DTDの再確認

まずスキーマを見てみる。p要素の内容モデルを確認するのに必要なのは次の箇所：

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->

<!ELEMENT P - O (%inline;)*            -- paragraph -->

<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

<!ENTITY % fontstyle
 "TT | I | B | BIG | SMALL">

<!ENTITY % phrase "EM | STRONG | DFN | CODE |
                   SAMP | KBD | VAR | CITE | ABBR | ACRONYM" >

<!ENTITY % special
   "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">

<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">

つまり、終了タグを省略することができ、ins, del, %inline;以外を内容に持つことができないというわけだ。しかし実装は異なる。

この仕様を正しく実装するなら、次のような処理が必要だ:

• 1. 当該p要素の開始タグが現れ、その終了タグが出現するまでの間に、p要素の内容として許されない要素が出現したとき、当該p要素を終了させなければならない
• 2. 当該p要素の開始タグが現れ、その終了タグが出現するまでの間に、当該P要素の親要素の終了タグが出現したとき、当該p要素を終了させなければならない

1. の処理を完全に行わないソフトウェア ――Gecko, MSHTML, Webkit, Opera

p要素の内容としてtable要素の出現が許される場合がある。場合があるというか、ほとんどの場合許されるといっていい。IEだろうがFirefoxだろうがOperaだろうがsafariだろうが、p要素の内容にtableが許される。これは恐らく、レガシーな記述に対応するために後方互換として意図的にやっているのだろう。

とかいいつつ、実はこの後方互換処理を行わせない方法もある。HTML4.01 Strictを宣言する。Gecko、Webkit、Operaで有効だが、MSHTMLに関してはこの限りではない。DOCTYPEスイッチで後方互換処理を無効にできないばかりか、table要素以外にも、form要素をp要素の内容に持てるようだ。

2. の処理を完全に行わないソフトウェア ――MSHTML, Webkit, Opera

ちょっとまてと。もう一度「2.」を読み返してみる。平たく言えばこういうことだ。「親要素が終了したら、終了していない子要素も終了する」。これってエラー補正処理を考える上で当たり前の振る舞いじゃないか? だが、その当たり前の処理を難しくしているらしいのが「ins及びdel要素」だ。次の例を見てみよう：

<ins datetime=".."><p>挿入された文章..</ins> <p>古い文章..

MSHTML、Webkit、Operaは、p要素内において開始タグの出現なしに出現したins/del要素の終了タグ「</ins>」を無視する。これは後方互換性とか何とかではなく、単なるバグであろう。恐らくp要素の内容として許される要素について、その開始タグの出現なしに終了タグが出現した場合、それをエラーとみなして無視しているのだと思われる。お粗末。

感想とか

さて。これらは「p要素」の終了タグの話に過ぎないという点に注意。これだけ色々面倒があることを知っていたら、省略をフル活用したHTML4.01を採用することは、ひょっとしたらなかったかもしれない。だがこれまでに色々調べたり経験したりして「知って」しまったのだからもう後戻りするコストを払う意味はないし、個人的には利点の方がはるかに多い。あくまでも「個人的には」。

HTMLでタグを省略するのは、普通の人はやめておいた方がいいよ。「普通の人」が読んでいるとは思えないけれども。まーとにかく色々あるし、もともと公開書庫のコンテンツとしてHTML4.01の実践的な部分は書こうと思っていたので、これからも少しずつ省略についての考察等々は公開していく予定。

テストページも用意したけど、要らないよな。公開書庫に移す時には付録として公開すると思うけど。]]> http://jintrick.net/agenda/2008/12/p.html http://jintrick.net/agenda/2008/12/p.html HTML Fri, 12 Dec 2008 14:54:09 +0900

このサイトの生い立ちは、とある掲示板で議論が起こり（というよりも一方的に筆者が起こしたものだが）派生したのが理由だが、その掲示板にとあるサイトからの引用が投稿されたので紹介（引用）並びに筆者のそれ対する意見を記しておく。

Personnel - 2001/7/1～15 - agenda - Personnel

私は、サイト構造を明確に示したナビゲーションの存在は、ウェブサイトの構築に是非とも必要なものだと思っている。各文書が、全体構造を示したファイルと直接結び付くことで、初めてウェブサイトたり得るのではないか。結果としてユーザビリティを高めることになるが、本質的な意味はそこにあるのではないかと思っている。

ところがフレームでは、サイト構造と各文書を論理的に結び付けることはできない。視覚的に結び付いていることができるのでさえ、玄関となるトップページを開いた時だけである。ゆえに私はフレームを用いてサイト構造を分離しようとは思わない。

サイト構造を明確に示したナビゲーションのくだりは、前述の通り筆者も同じ意見だ。しかし、2段落目のフレームでは、サイト構造と各文書を論理的に結び付けることはできないというのはどういうことなのだろう。そもそも論理的とはどのような理なのかを考えてみたい。

ろんり 【論理】〔logic〕

1. 思考の形式・法則。議論や思考を進める道筋・論法。
2. 認識対象の間に存在する脈絡・構造。

言うまでもなく、サイト構造と各文書を繋ぐのはナビゲーション、つまりリンクである。論理的な結び付きというのは非常に難しい言葉である。その論理の定義がどのようなものなのかははっきりと記されていないが、つまり、"全体構造を示したファイルと直接結び付くこと"＝論理的結合、だと推測する。だとすれば、"フレームでは、サイト構造と各文書を論理的に結び付けることはできない"というのは疑問を残す言い回しだ。何故ならば、文書を結び付ける手段は先述したように『リンク』なのだから。フレームは無関係である。

ナビの考え方（frame.s26.xrea.com）より引用

強調Jintrick。認識対象の間に存在する脈絡・構造。と書いてある通り。文書を論理的に結びつけるというのは、何故、それらが結びついているのかという、その何故を明示するということ。言い換えると、結びつけた理由をそのハイパーテキストの構文で示すことだ。

Framesetのやり方で結びついただけでは、ソフトウェアはそのファイルが全体構造を示していることを理解できない。理由が示されていないからだ。リンクの方向や文書間の主従関係も示されていない。たとえば左側ペインが目次、右側ペインに本文という「フレームページ」を考えてみると、本文と目次は直接結びついておらず、framesetの文書型を宣言された空っぽのHTML文書が、目次文書と本文文書にそれぞれ匿名リンクしているだけだ。図1に示す:

図1. フレームのリンク方向

主従がめちゃくちゃなんだよ。論理的に両者を結び付けると、本文が目次に「目次ですよ」とリンクするのが自然だ。図2に示す:

図2. 論理的なリンク方向

これが私が、何年前だっけ？6年前？に考えていたと思われる抽象的な理念。実際にどんな問題/ご利益があるかなんて今やどうでもよくなっているけれども、一つ今思いつくのは、ブラウザはフレームで構成されたウェブページの主従関係を知り得ないため「アドレスバー」とやらにヘンテコなURLを表示してユーザーを困惑させているだろう。これがその非論理性が顕在化した例だ。

あと、フレームの「ボーダー」。文書と文書の境目。こんなものをHTMLで表現すべきではない。これはブラウザがやるべきだ。左に目次のペインを作り、右に本文のペインを作る。こんなのは典型的なハイパーテキストブラウザの仕事だろうよ。デスクトップアプリケーションの文脈で言うなら、HTMLはデータに相当する部分だろう。ソフトウェアとデータの関係を考えれば、フレームがあまりにも異常なのは明白ではないか。

rel="contents"をまともに利用できるブラウザがないため、この関係が極めて重要な時、仕方なくフレームを利用することはあり得るかな。