ユーザビリティ

PDFへのリンク、嫌ですよね。非力なマシンで対策(PDF Downloadとか)もなくクリックしてしまった日にゃ、「PDFトラップ」なんて言葉も思い浮かぶってものです。

でも、なぜか、官公庁はPDF大好きだし、それもHTMLへのリンクと同じように並んでたりするからタチが悪い。

そこで、ひと目でPDFへのリンクがわかるようになるGreasemonkeyスクリプトを作成しました。

• Show icon before PDF link for Greasemonkey

これを導入して、たとえば、厚生労働省のWebサイトを見てみましょう。

まずはbefore。

つづいてafter。

「緊急情報」に隠されたPDFトラップが白日の下に! アイコンちっちゃく見えるかもしれないけど、実際使ってみると十分なサイズですよ。

処理としては、a要素のhref属性が「.pdf」で終わってたら、アイコンを追加するという簡単なもの。URLが.pdfで終わってない場合は無力です。

ただし、適用範囲がhttp通信のWebページ全部と広すぎるので、場合によって適用範囲を制限してください。

あんまり技術系の記事ばっかり続けるのも気が引けるんだけど・・・。

ユーザーがコピーする内容をテキストエリア/テキストボックスで表示したとき、クリックしてフォーカスした際にテキストが全選択状態になると便利だ(特に内容が収まりきらない場合)。

Firefox / Opera / IE だと

onfocus="document.form_name.textarea_name.select()";

または

onfocus="this.select()";

で問題なく実現できるのだが、Safari / Chrome (ようはWebkit) だと、うまくいかない。

これで試してみてほしい。

挙動をよく見てみると、マウスのボタンを押す→全選択される→マウスのボタンを離す→選択が解除され、カーソル位置にキャレットが移動する、となる。

つまりこういうことになってるものと思われる。

• Firefox / IE / Opera
  →マウスのボタンが押され、離れた時点で、キャレット移動→onfocusイベント実行
• Safari / Chrome
  →マウスのボタンが押された時点でonfocusイベント、離れたらキャレット移動

じゃあ、どうすればいいかといえば、キャレット移動が終わってから選択するようにすればいい。

onfocus="setTimeout(function(){document.form_name.textarea_name.select()},0);"

setTimeoutを利用して、0ミリ秒後に選択している。

一応、これで Firefox / Opera / IE でも Chrome / Safari でも動く。Firefox だとフォーカスする→フォーカスはずす→もっかいフォーカスすると、なぜか選択が解除されちゃうけど、まあ、これくらいはいいかな。

なんかひさしぶりにこのブログを見たら巨大な広告が入って、なんだなんだと思ったら、「上記の広告は１ヶ月以上更新のないブログに表示されています。新しい記事を書く事で広告が消せます。」との事、ビューの少ないブログでの広告効果上昇と、記事執筆のモチベーション上げ効果を狙ってるわけか。閲覧者にとっては単なる迷惑だろうけど。

証拠写真。広告のせいで、ほとんど記事が見えない。

とまあ、そういうわけで、メモっておいたことを記事にしておきます。偶然にも上の話とも関わってるし。

まずは結論

横長ディスプレイ環境下において、縦方向のスペースは貴重である。

Webページではスクロールなしでアクセシビリティを確保しなければならないし、ソフトウェアのインターフェイスではコンテンツ表示部を圧迫しないようにしなければならない。

ディスプレイは横長、コンテンツは縦長

そもそもディスプレイが横長なのは人間の視界に合わせてのことだろう。左右の目で見る人間の視界は横長であり、ディスプレイやスクリーンが横長なのは合理的である。

一方で多くの文書は縦長である。文書も本のかたちで見れば横長なのだが、それぞれのページは縦長である。あまり一行が長いと目で追うのが大変なのがその理由だろう(縦書きのノベルスや、横書きでもA4などの大きな版では多段組になってるのも行の長さの関係)。ブラウザの横幅いっぱいに行がひろがるWebページを思い出してみればいい。

もちろん見開きの状態でディスプレイに表示するという手もあるのだが(実際、組版を行うソフトウェアやAdobe Readerなどでは見開きで表示することがある)、構造的にはページは縦に連なっているし、(横方向へのスクロールを想定しない場合)見開き2ページ分の横幅を確保すると、1ページあたりにさける画面スペースがかなり小さくなってしまう。

縦方向スクロールの問題

そんなわけで、現在は、横長のディスプレイに縦長のコンテンツを表示するというのが一般的な状況にある。見開きを表示しても十分な解像度が確保できる環境は少ないし、縦横両方にスクロールしなければならないというのはちょっとストレスが多い(表計算ソフトでは一般的だが、やっぱりストレス。Apple Mighty Mouseみたいな横スクロールできるマウスあると少しはましだけど。)。ということで、(前置きが長かったが)縦方向にのみスクロールするというのが標準的なつくりである。

しかし、スクロールが可能ということは、理論上無限のスペースが縦方向にはあるわけで、コンテンツ以外もの=操作系や広告、外見上の要素などが大きなスペースを占めていることがすくなくない。

Webページのデザイン

スクロールが必要なレイアウトは情報の一覧性を失ってしまうし、ページ遷移が起こると毎回スクロール位置が初期化されてしまうWebページでは、同じスクロール操作を繰り返し要求され、ストレスがたまる。

Webページでスクロールが必要となるのはほぼ避けられないが、スクロールしない状態で見えるページの左側、上側だけで十分なアクセシビリティを備えていなければならない(逆に高いアクセシビリティを必要としない要素は、スクロールしなければアクセスできない位置にあってもよい)。

ソフトウェアのインターフェイスデザイン

また、ソフトウェアの操作系は画面の上部に表示されることが多いが、コンテンツが縦方向にスクロールするのに対し、普通この部分はスクロールされることはない。そのため、この部分に大きなスペースが割かれると、貴重な縦スペースを占有し、コンテンツ表示部を圧迫してしまうことになる。

Microsoft Office 2007の「リボン」は確かに慣れると使いやすいが、解像度の低いディスプレイでは、あまりにも多くのスペースを取りすぎる。Google Chromeが非常にすっきりした印象を与えるのも、コンテンツ表示部以外の部分を最大限切り詰めたからだろう。小型のノートパソコンや、ネットブック、スマートフォンなどの低解像度環境ではかなり重要なファクターになる。

余談

ところで、コンテンツは縦長ということを前提に書いてきたが、実は縦書きの場合、コンテンツは横長になる。巻物(まさに横「スクロール」だ)を見てみれば一目瞭然である。横長のコンテンツが基本で、横スクロールが一般的であれば、横長ディスプレイとの親和性は高かったかもしれない。

Microsoft製のインスタントメッセンジャーを入れようと思って、調べてみたらWindows Live Messengerというのが最新版らしいので、Firefoxでhttp://messenger.live.jp/へアクセスし、ダウンロードした。

いきなり英語ページに飛ばされたのがやな感じだったが、まあ、インストーラは日本語とか、インストール時に言語が選べるとか、最悪、設定で日本語に変えられるんだろうと思ってた。しかし・・・

• インストーラ：英語
• インストール時の言語の選択：無し
• Messengerのメニュー表示：英語
• Messengerの設定での言語の選択：無し

ってことで、愕然としてヘルプを見る。

• Windows Live ヘルプ
  http://help.live.com/JA_JP/
  （信じらんないことに記事固有のURLがないので、「別の言語の Windows Live Messenger をインストールする」で検索してください）

アンインストールしなきゃいかんというのにもびっくりだけど、なんでIEの言語設定が関わってくるねん・・・。

そこで、ふと気づいて、IEでおなじページを見てみると、ダウンロードページが日本語になってる！

　

左がFirefox、右がIEでアクセスしたもの。

URLは一緒だけど、表示が違う。

で、ダウンロードしたファイルのプロパティを見てみると言語が違う。

左がFirefoxでアクセスしたページからダウンロードしたもの、右がIEでアクセスしたページからダウンロードしたもの。

ファイル名は同じだけど、バージョン情報の言語が異なる（ファイルサイズもちょっと違う）。

インストールしてみたらちゃんと日本語になってた。

---

どうやら、ダウンロードページに飛ぶ時にブラウザの言語設定をチェックしてるらしい。

でも、

• 日本語のページから飛ぶのにわざわざチェックする必要があるのか！
• Firefoxで自動的に日本語で表示されるサイトがある。つまり、より一般的な言語選択の方法があるんじゃないか？
• せめてダウンロード時に何語版か表示し、また選べるようにしてほしい。
• つーかそもそも多言語対応するのにわざわざバイナリ変えんでも、言語ファイル作って設定で選ばせてくれよ！

と思った。

相変わらず余計なお世話が得意なMicrosoftさんでした。

---

ま。そんなわけでようやく導入したので、使ってるかたは以下のアドレスへコンタクトください（知らない人から来ても拒否するけど）。

• labocho_k@yahoo.co.jp

最近、どうもFirefoxが遅くて、落ちることもしばしばあるので、Windows版のSafariを入れてみた。

評判どおり動作はかなり軽い。サクサクという形容がしっくりくる。見た目にかなりこだわってるのに、これだけ軽いというのは驚きだ。

(ClearTypeじゃない)独自のエンジンで描画してるという文字の表示もすばらしく綺麗。不思議なもので文字がなめらかだと、紙に文字がはりついているような、印刷物を見ているような感覚になる。読みやすいし、なにより綺麗というだけでちょっと病みつきになる感じだ(家のテレビでデジタルテレビ放送を見た時の感覚に近い)。

それ以外にもAppleだなあと思わせる部分が多々あって、なかなか楽しい（特にページ内検索は秀逸）。エモーショナルデザインという点から見れば、ほかのブラウザに比べて格段に良くできてると思う。

が。

本格的に使おうと思うと、不満が出てくる。マウスジェスチャがない、Googleツールバーやはてなツールバーがない、デスクトップにショートカットが作れない、Greasemonkeyがない云々・・・。

なんか、Firefoxだと全部拡張機能で実現してた機能だ。結局、Firefoxが便利なのは、膨大な拡張機能ライブラリがある点に尽きると思う。

であれば、Safariも拡張機能が充実すれば、十分メインのブラウザとして使えるはず（その分重くなってしまう可能性はあるけど・・・）。コアの部分はFirefoxより出来がいいと思うし。幸いSafariも開発環境を提供してるので、もはや時間の問題かもしれない。もうちょっとシェアが大きくなればGoogleやはてなも対応するだろうし。

まあ、しばらくはメインにFirefoxを使いつつ、Safariの動向をチェックするという感じでいこうかと思います。

しかし、こんな状況でも、一部のサイトでは、いまだに恐ろしく重く使いにくいIEを使わざるを得ない、というのはなんとも癪なものです。

---

ところで、iPodを通じてiTunes、重いIEに対して軽いSafariと、Apple製ソフトは着実にWindowsユーザに浸透しつつあると思う。これで、「Macは使いやすい」と印象づけられるし、Intel Macの登場で、Windowsとのデュアルブートも可能になるし（ついでにMacOS XはUNIXだし）で、どんどんMac移行への敷居が低くなってる気がする。私も欲しい。

Windows VistaはそうしたユーザをWindowsにつなぎとめておくべきものだったのに、デザインはいまいちだし、日本語フォントはガクガクだし、ありえないほど遅いしで、むしろWindowsから離れるきっかけを作ってしまったように思う。IE7やOffice 2007も然りだ。

最近、HD=High Definitionという言葉をよくきく。要は、高い解像度の映像だ。

我が家でも最近、地上・BS・CSデジタルチューナを導入し、ハイビジョン映像を楽しめるようになった（アナログ接続だけど）。

ハイビジョンの精細な画像は、たしかに一度体験してしまうと、ちょっとやめられない魅力がある。

しかし、ちょっと考えてみてほしい。

Wikipediaによれば、HD映像規格の走査線数 – 要は画面の縦の点の数 – は720〜1125くらいだ。つまり一般的なPCの画面と同程度と考えればよい。

解像度というのは、ある長さにいくつ点があるかで決まる。最近までのWindowsでは96dpi、すなわち1インチに96の点がある（ただし実測とはずれがある）。

一方で、一般的な商業印刷の解像度は300〜600dpiである。300dpiとしても、ディスプレイの3倍の解像度である。ディスプレイの点一つがさらに3×3の9つの点からできていると言えば、その細かさが想像できるだろうか。HDだなんだと騒いでも、まだまだ紙のほうが解像度は高いのである（まあ、紙では動画の表現はできないけど）。

実感としても、ディスプレイの点一つ＝1ドットというのは結構大きい。マウスを1ドット単位で動かすのは難しいことではないし、ドット絵では1ドットで大きく見た目が変わる。なによりアンチエイリアシング（中間色で色の境界をぼかすこと）を行わなければ、文字や図形がギザギザに見える。

最近のMacOSやWindows VistaではClearTypeにより、文字などに限り擬似的に横方向の解像度を3倍にしているが、縦方向の解像度は変わらないため、細い横線には相変わらず弱い。例を挙げれば、スコアのような細かい楽譜の表現はまだまだ難しい。

大画面化もいいけれど、1ドットをより小さくすることができれば、映像装置はより利用の幅が拡がるだろう。

（もっともドット絵やビットマップフォントの魅力というのもなかなか捨てがたいものがある。すべてが高精細になってしまうのもちょっと寂しいファミコン世代。）

MacやWindowsの普及で、GUIはもはや、なくてはならないものになってしまった。多くの情報や操作系をわかりやすいかたちで表現できるGUIはたしかに便利だし、洗練されてもいる。しかし、一方で、GUIが使えない人には不便きわまりない状況となってしまったのではないか。

最近のWebデザインの本を見ると、必ずといっていいほど、Webの読み上げソフトに対応するため、TABLEタグによる複雑なレイアウトを避けるなどの注意を促している。しかし、そうした注意をしたところで、膨大なメニューや広告がいちいち読み上げられるかと思うと、いかにも大変そうだ。

読み上げソフトや音声による操作など、聴覚的なインタフェイスもなくはなかったが、洗練されているとはいいがたい。単にGUIの「翻訳」ではなく、一からのデザインが必要ではないか。聴覚的インタフェイスの研究は、GUIが使える人にとっても、大がかりなデバイス（ディスプレイやポイントデバイス）を必要としないUIとして、有用性が期待できる。

聴覚的インタフェイスの実相案としては、3Dサウンドの利用がおもしろそうだ。頭の向きのセンサやポインティングデバイスの操作で、聞こえる音が変化すれば流し読みならぬ「流し聴き」ができるかもしれない。

ここであげたのは、聴覚を利用するものだけだが、触覚的な出力デバイスもいろいろ考えられる（いわゆるフォースフィードバック）。さすがに味覚や嗅覚はどうなんだろう・・・。

ソフト開発をしていると、実は一番手間がかかるのがユーザーインタフェイス(以下UI)だと思うことがある。
大規模なソフトウェアや、速度を求められるソフトウェアでは、処理部分に時間がかかるのかもしれないが、私の作るような簡単なものの場合は、間違いなくUI関係に時間がかかる。
最近ではGUI=グラフィカルUIが当然だが、このGUIというやつはユーザからのアクションが予想しにくいというか、あらゆるアクションに対応しなければならないために、コードが煩雑になり、例外（エラー）も起こりやすくなる。
さらに、ファイルを処理するユーティリティだと、「ファイルを開く」ボタン（あるいはメニュー）、ウィンドウへのドラッグ＆ドロップ、コマンドライン引数でのファイル指定、のいずれにも対応するのが、結構めんどくさい。
また、Tabによるフォーカスの移動や、Enterを押した時の動作なんかも、操作性に大きな影響を及ぼすので、頭を悩ませる。
ただ、特に簡単なソフトは使いやすさが命なので、UIで手を抜くわけにもいかず、「自分で使うだけなら楽なのに」と愚痴を言いながら、コードを書くわけである。
基本的なUIをウィザードかなんかで簡単綺麗に作れる（変更できる）と、だいぶやる気がでるんだけどなあ。