はてなブックマークFirefox拡張の感想とか (agenda)
はてなブックマークFirefox拡張をインストールしてみた。 まず「ユーザー」と「はてなブックマーク」との架け橋（UI）はツールバーとステータスバーがこれを担っている。デフォルトの設定ではポインティングデバイス依存で、代替手段が提供されないが、ツール→はてなブックマークから色々設定を変更できる。ここまでは別にいい。しかしキーボードショートカットを変更する手段がまたポインティングデバイス依存なんだよ。こんなUI見たことも聞いたこともないよ。入力欄を「クリック」すると（「アクティブ」じゃあない）、「キーボードを押して、ショートカットを設定します」というモーダルダイアログ系がポップアップされる。これには「キャンセル」ボタンがついていて、押すとこのポップアップ表示が消える。問題はショートカットの入力を受け付けるのは、このダイアログがポップアップされているときだけだという事実。俺はこんなUIをみたこ
「はてなブックマーク Firefox 拡張」はユーザビリティテストをすべき (agenda)
取り急ぎ要点だけ述べる。 はてなブックマーク Firefox 拡張のベータテストを開始します - はてなブックマーク日記 - 機能変更、お知らせなど 「はてなブックマーク Firefox 拡張」を開発する上で、「はてブユーザー」の意見を聞くべきではない。理由： はてなブックマークをすでに利用している人間が、より便利に利用できるようにはなるかもしれないが、新しいユーザーを獲得するための直接的な方法ではない ユーザーの「意見」にはバイアスがかかる。ましてやコアな「はてブユーザー」は一般的なユーザーとはまったく違った使い方や習慣、癖をもっている可能性がある。 「バグ報告」だけを聞くべき。 ではどうすればよいか。さっさと公開したい記事なのでとりあえず一言で済ましておく。「ユーザビリティの専門家にご相談ください」。 « 「ナビゲーションとは何か、そしてそれは『分離』すべきなのか」に寄せられたコメント
リンクと参照 (agenda)
リンクは参照か - 徒書 及び iframeは参照か - 徒書 の補足を目的とした記事。別名「援護射撃」。 リンクとは何か リンクとは、開始リソースと終了リソースとの間の関係、繋がりのことです。この関係もしくは繋がりをブラウザがどう表現するかは、リンクの本質ではありません（参照：link （Hypertext Terms））。 社会通念上は、クリック等すると画面遷移等が生じる「アンカーとなる文字列」のことをリンクと呼ぶようですが、ウェブページ制作者にとって、このような概念のごちゃまぜは恥です。 参照とは何か 参照とは、「あるリソースを他のリソースと照らし合わせてみること」です。また、「他のリソースを指し示すもの（ポインタ）」を意味することがあります。 あるリソースを他のリソースと照らし合わせてみること 他のリソースを指し示すもの（ポインタ） アンカーとなる文字列などはポインタとしての参照で
サイト内の検索について
上のようなサイト内検索が必要になったとしても、そのサイトが提供していなかったら意味がない。どのサイトでもサイト内検索を可能にする方法を紹介する。 ブックマークレットを使う方法 次の二つのアンカーをポイントしてコンテクストメニューを開き、ブックマーク（お気に入り）に登録し、ブックマーク（お気に入り）を呼び出す形で実現できる。 [Bookmarklet] ドメイン内検索（ドメインを持っているサイト内を検索するブックマークレット） [Bookmarklet] サブサイト内検索（他人のドメインを借りているサイト内、またはサブサイト内を検索するブックマークレット） ブックマークレット（Bookmarklet）は、ブックマーク（お気に入り）を選択する手順で、現在表示しているページのコンテクストでJavascriptを実行するというもの。ブラウザによっては、「リンク」と呼ばれるフォルダ内に登録しなければ
var要素をプログラムコードではない通常の文章に使う (agenda)
きちんとしたPNG画像で「作品」を公開したところ、GIF画像しか読めないソフトウェアで閲覧しようとして失敗した事実を突き付けられ、「馬鹿には見えない作品なのですか？」と、とぼけられたり、駄目ソフトウェアがクラッシュした事実を突きつけられ、「観れないどころの騒ぎじゃないですね。もしかして、あなたのいう『作品』というのは『正しいPNG画像フォーマットで書かれたアプリケーションクラッシャー』のことを指しているのですか？ そう仮定するなら、なるほど、なんとも素敵な作品です。天才的なセンスを感じます。」とか皮肉られたので、画像ビューワの実装が悪い、とお決まりの反論しておいた。この画像ビューワ、何百、何千と種類があってしかも、その多くはPNG画像を表示できて無料なのに。自分は何か間違っているのでしょうか。云々。例文終わり。 私はこのようなvar要素を「散文的変数」と呼んで愛用している。 というか、ウェ
p要素の終了タグを省略する際の注意点 (agenda)
HTML4.01ではp要素の終了タグ「</p>」は省略することができるようになっている。数ある省略可能なタグの中で、最も気を付けなければならないのがこの「</p>」。 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 | STR
フレームは非論理的、再掲 (agenda)
このサイトの生い立ちは、とある掲示板で議論が起こり（というよりも一方的に筆者が起こしたものだが）派生したのが理由だが、その掲示板にとあるサイトからの引用が投稿されたので紹介（引用）並びに筆者のそれ対する意見を記しておく。 Personnel - 2001/7/1～15 - agenda - Personnel 私は、サイト構造を明確に示したナビゲーションの存在は、ウェブサイトの構築に是非とも必要なものだと思っている。各文書が、全体構造を示したファイルと直接結び付くことで、初めてウェブサイトたり得るのではないか。結果としてユーザビリティを高めることになるが、本質的な意味はそこにあるのではないかと思っている。 ところがフレームでは、サイト構造と各文書を論理的に結び付けることはできない。視覚的に結び付いていることができるのでさえ、玄関となるトップページを開いた時だけである。ゆえに私はフレームを用
はてなブックマークの「お気に入り」って何？ (agenda)
なんか自分でも恥ずかしいくらい今更な話なんだけど、はてなブックマークのお気に入り機能って何なんだ？ お気に入りページでは、お気に入りに加えたユーザーのブックマークを新着順にまとめて閲覧することができます。 RSSリーダーに登録しておけばまとめて読めるのに、お気に入り機能を使う理由が分からない。 お気に入りユーザーがブックマークにつけたコメントも合わせてみることができるので、あなたにとって価値の高い情報だけを凝縮して閲覧することができます。 強調Jintrick。「都合のいい情報」の間違いでは？そんな薄気味の悪い情報収集をしていると目が腐るぞ。いや腐っているから云々というべきか。 お気に入りゼロの状態でお気に入りページを開くと、こんな誘い文句が踊る。 気になるユーザーの新着ブックマークをまとめて一覧できる「お気に入り機能」を活用すれば、はてなブックマークが自分だけのネットサーフィンガイドブッ
はてなブックマークの「お気に入り」って何？ の続き (agenda)
はてなブックマークの「お気に入り」って何？ (agenda)の続き。 はてなブックマーク - はてなブックマークの「お気に入り」って何？ (agenda) なんか、言いだしっぺの私が言っていいのか知らんけど、はてなブックマークの「お気に入り」がRSSリーダーより優位な点って、はてなブックマーカー達による「情報の重複」を避けられることじゃないのか？とふと思った。たとえば、RSSに登録しているはてなブックマーカーが10人いて、10人が10人同じ記事をブックマークしたとすると、RSSリーダーでは10もの個別フィードを消化することになる。しかしはてなブックマークのお気に入りに「隔離」しておけば、記事一つにコメントが集められる形で表示されるのですっきりする。 と思ったら、すまん既にいくつかブックマークコメントされてた。恐らく同じような意味。だと思う。ピンと来なくて気付かなかった。 はてぶのお気に入り
代替テキストで悩む瞬間 (agenda)
IMGのalt属性・title属性について考える（後編） ｜ HiGash.Net なんとなく面白そうだが、実際無縁な話だなと思った。 装飾のための画像を一切入れないから、「CSSかIMGか」で迷うことがない 代替テキストが空だからといって、それが気持ち悪いとは思わない 私の場合代替テキストを空にすべきか考える事例そのものが少ないような。覚えているのは自分を紹介する文書で、顔写真を使ったときくらいか。このときは久しぶりに代替テキストをどうしようか考えたが、適切なものが頭に浮かばなかったので空にした。別に気持ち悪くもなんともない。 画像を利用できないシチュエーションを想像して、情報の伝達に支障が出るなら、そこをテキストで補う。想像力がないなら、画像を非表示にしてみて、文書を（「眺める」のではなく）きちんと読んでみる。それでちゃんと伝わるならカラでも何でもいいだろう。 良く考えてみると、問題は
Re: はてなブックマーク - マルチカラムとウェブ・ユーザビリティ (agenda)、他 (agenda)
まとめて(答え|応え)てみるテスト。まずはてなブックマーク - マルチカラムとウェブ・ユーザビリティ (agenda)のコメントに対して。 スクロールのコストってそんなに高いと思えない。 テストすべし。 全文が見えていると概要をつかめるという理屈も謎。 それは私の書いた条件節を脳内で消している為。 まー結局好みの問題ですしね。 まあそうだが、程度の問題として、Firefox3のCSS3 multicol先行実装はほんの一部であって十分ではないとか、agendaがビジュアルやUIに全く無頓着である等々、様々なマルチカラムの本質以外のバイアスがかかっている可能性は十分にある。たとえばbookreader.jsははてなブックマーカにも「読みやすい！」と好意的に受け止められている。 マルチカラムが有用ってことを言えるわけではない。 どのようなgoalに対しての「有用」なのか。多くのgoalに対して
マルチカラムとウェブ・ユーザビリティ (agenda)
ウェブページの文章を読むときは「上から下へリニアに」というスタイルが一般的というか、恐らく99.9％がそうだと思う。マルチカラムで読んだ人がその慣性から引き剥がされて不快感を覚えたとしても不思議はない。視線を下への移動だけでなく上にも移動させるという、いつもと違うことをしなければならないというのは、それだけでユーザビリティ的に問題を引き起こす要因となり得るだろう。しかし、必要な「技術」は視線を移動させることだけだ。スクロールは必要ないし、マウス操作も必要ない。マルチカラムに関して生じているウェブ・ユーザビリティ的問題は、結局のところ主観的満足度の低下だけだと私は想像している。私が主観的満足度よりも重視しているのは視線の移動を失敗したりせずに「内容をきちんと読めたか」、そして「どのくらいのスピードで読めたか」。この2点。もともとスクロールが発生しないほどの短い文章ではマルチカラムが敗北するが
サイトのナビゲーションとしてサイドバーを採用すべきでない理由 (agenda)
サイドバーとは左側に位置するウェブサイトのナビゲーションのことである、とここでは定義する。擬似段組などによって主に左側に配置される。何年か前にも一度批判したことがあるが、当時は疑いを述べたにとどまっている（段組の利点 - 3つの情報ブロックがある場合 (agenda)）。その5年越しの「続き記事」といってもいいかもしれない。 第一に、サイドバーがナビゲーションバー（サイトロゴの下部に配置され、インライン方向に伸びるナビゲーション）と決定的に違うのは、それがナビゲーションかどうか分からないことである。サイドバーは今流行りの「ブログパーツ」かもしれないし、広告の塊かもしれない。自分のサイト内のコンテンツの宣伝である場合もしばしばだし、コンテンツに密接に関連した他サイトの記事へのリンクかもしれない。仮にナビゲーションであったとしよう。この時、サブカテゴリ内のリンクになっているケースもあればグロー
ウェブページの要約、そしてRSS、SERPの理想と現実 (agenda)
Jakob Nielsenの考えによると、検索エンジンの検索結果ページ（SERP）に示されるべきは、ページの著者によるそのページの適切な要約であるという（彼の著書「ウェブユーザビリティ」参照）。そして著者がmeta要素を用いて適切なキーワードをつけることでその検索結果に正しく反映される。しかしこれは適切な要約や適切なキーワードを付加することも可能なイントラネットには言えることかもしれないが、WWWにおいては全くの絵空事であった。人々は面倒臭がって要約をつけないか、あるいは不適切で何の役にも立たない「要約」を記述するだけであり、宣伝目的のでたらめなキーワードで検索エンジンを騙そうさえとしたのだ。 私はmeta要素に書かれた質の低いウェブページの要約や嘘っぱちキーワードがちっとも役に立たないことを、ウェブの検索エンジンを使い始めて間もなく知った。だからこそGoogleが使われるようになったし、
見栄えするだけのスタイルシート (agenda)
メインページ - MDC スタイルシートが改悪されとる。また一段とスペースを無駄遣いしているな。スクロールしないとコンテンツリストがチラりとも見えねーよ。ユーザはMDCに技術文書を参照しに来るのに決まっているから、何のためにスクロールを強要するのかよく分らん。 私も数々の糞スタイルシートを書いていたのを思い出してきた。h1要素が異様にでかく、かつ目次ばっかりで、場合によってはコンテンツがチラリとも見えないやつ。今ではなんであんな馬鹿な事をしたのか１ミリも理解できない。何故か「見栄えがいい！」と信じていたようだ。馬鹿だよ。デザインには理由があることを想像できない馬鹿だ。情報へのアクセスを妨げない限りにおいて、そういう制約の下の自由として「見栄え」がある。その制約とどう戦うかが腕の見せ所なんだよ。 まあこの個人サイトでは見栄えにこだわる必要が全くないから、全然「腕」なんか発揮していないが。 さ
position:fixed大嫌い
「ウェブアプリケーションのGUI以外にposition:fixedを使わないよーに。」 ウェブログにおいて記事が主役である限り、ナビゲーションにposition:fixedを使うのはreasonableとは言い難い。馬鹿げた縦幅を持つサイトロゴ部分＋ナビゲーション部分をスクロールで消して記事を読もうとしたら、そいつらがくっついてくる。こいつは本当に頭に来る。かといってそういうサイトをブラウザデフォルトのスタイルシートで閲覧すると、ナビゲーション用の画像がリストとしてズラズラならんでしまって、さらに記事に辿り着くのが面倒になるんだ。まあ仕方ないんだけど、あの「ナビゲーションバー」のどこがUL要素なんだよって言いたくなることがある。 ユーザにとってウェブログはハイパーテキストアプリケーションの一種だ。それを操作するためのグラフィカルなインターフェイスは、ブラウザのボタンなりメニューなりに集約さ
新聞ブログ (agenda)
シックスアパート社の新聞ブログのデモを見てみた。 テキスト選択すると、カラムの変わり目で途切れてしまう 固定幅なので並行閲覧すると新聞がちょん切れ、しかももともと文字サイズが小さめなのでズームアウトすると文字が読めなくなる 文章が途中でちょん切れている それは最初、バグかあるいはデモだからなのかと思った しかし実は記事の見出しが全文にリンクしており、クリックすると全文がポップアップ表示される仕組み しかもそのリンクの表現がJavascriptで実装されているので、リンク先を新しいウィンドウで表示しようとするなどしてブラウザ側のリンク表現を利用すると同じ画面が現れ、全文は読めない つまりHTML的には各見出しは記事全文にリンクしておらず、そのHTML文書自身にリンクしているだけである これは記事を適当な「決め打ち長」でぶった切って貼り付けているだけで、しかも連続してすらいない。ウェブ用のマル
HTML5の役割：ゴミ捨て場：agenda
私がHTMLを使用しているのは、互換性の問題がある為であり、また、2008年現在まともなハイパーテキストを出力してくれるソフトウェアがこの世に存在しない為である。つまりはただの妥協。本来私はXHTML派というか超右寄りのXHTML2.0派だ。これは一度書いておいた方が紛らわしくなくて良い気がした。勧告され、ちゃんとした編集環境があって、誰もが閲覧可能なら今すぐにでも移行したいと思うだろう。リンク関係のモジュール等を組み入れたりすることでハイパーテキストとしてもそれなりに強力になる。 HTML5はどうか。私のユースケースでは単に互換性が低くなるだけなので使わないが、ブログサービスがHTML5に移行するのは個人的には大歓迎だ。ユーザースタイルシートで余計なものを消すのが容易になる。ユーザースクリプトで必要な時だけ「ブログパーツ」を利用できるようにするのも容易くなるだろう。何よりそのようなスタイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Chrome導入前の感想のようなもの 2 (agenda)
Google Chrome導入前の感想のようなもの (agenda)