今数えてみると、私がコンテンツを作っているサイトはプログラマーズフォーラムを含めて少なくとも5つある。最初に RIMNET に作った Phinloda is here が一応メインのはずなのだが、@nifty にある裏ページ、@nifty のブログの裏の裏ページ、Jugem のプログの裏表、そしてここ Ameblo の裏ご意見番だ。「少なくとも」と書いたのは、これ以外にも工事中とか休眠中のサイトがいくつもあるからだ。

なぜこんなに分散しているかというと、ブログ以外では各サイトの容量制限が原因。ブログは仕様を知りたいということもあって、わざと複数作っているのだ。

これだけ分散してしまうと、どこに何を書いたか分からなくなることがある。もちろん、どこに書いていいか迷っても仕方ないから、基本的には、どうでもいいことは「裏の裏」、コンピューティング関連は「裏表」、少しコラムっぽく書いてみたいというのがここ「裏ご意見番」という感じで使い分けてはいるのだが。

ブログによっては、サイト内検索の機能があるのだが、これが意外とヒットしないことがあったりするし、だいたい、どのブログにあるのか分からないのに、そのブログの中で探すというのは、ちょっと手間がかかりすぎて面白くない。

そこで便利なのは google だ。これなら複数のサイトを一度で検索できる。私のページは意外と google で最初の方に出てくることが多い。例えば「Ameblo ユーザーインターフェース」という2つのキーを指定して検索してみると、最初に出てくる。

しかし、当たり前だが google でいつも最初に出てくるとは限らないし、もちろん、出てくるという保証もない。そこで作ったのが、私のブログだけをターゲットにした、ブログの横断検索機能である。どのようにして実現しているか紹介すると、次のようになっている。

1. まず、各ブログに書いた内容を、発言ごとに pc に保存する。

簡単そうに思うかもしれないが、実はこれが一番難しい。ポイントは、発言部分だけを保存するということである。ブラウザで表示したブログの画面は、広告やリンクなど、余計な情報が多数入っているので、検索の邪魔になるからである。

2. 次に、namazu を使って、検索情報を作成する。

namazu というのはフリーソフトウェアで、これを使えば、指定したディレクトリに入っているファイルを調べて全文検索することができる。実績のあるソフトで、公式サイトに採用している企業、団体も多い。pc で使えば、例えば、自分の pc に入っているドキュメントを全文検索することができる。最近、OS に全文検索機能を入れるとか話題になっているが、少し技術のある人は、数年前から pc 内の全文検索は既に使っているのだ。

3. 最後に、作成した検索情報を、インターネット経由で利用できるようにする。

このためには、Webサーバーが必要になる。私の場合は、LINUX 上に apache を走らせて、外から使えるようにしている。ちなみに、1. の処理は、同じ LINUX 上で Java で書いたプログラムを実行している。2. も同じ LINUX 上で行っている。

このブログの左サイドの一番下に uraura Search というリンクがあるので、興味がある方は実際に試すとどんな感じか分かると思う。namazu の検索にはコツがあるので一つだけ紹介しておく。namazu は単語を割と厳密に解釈するので、単語の一部でヒットさせたい場合には「*」を使うとヒットする数が多くなる。「*」は、そこにどんな言葉が来てもいい、という意味になる。例えば「ユーザーインターフェース」を検索したいなら「ユーザー」ではなく「ユーザー*」と指定するのがよい。
AD
Webページのデザインでよく問題になるのは、どこをクリックできるのか明確になっていないデザインである。例えばここ「フィンローダの裏ご意見番」の場合、画面の先頭にタイトルとして表示されている「フィンローダの裏ご意見番」という大きな文字はクリックできるのだが、見ただけではそのことが分からない。

これを書いている2004年9月の時点で選択しているデザインでは、リンクは基本的に水色に下線を引いた状態で表示されているから、なんとかそこをクリックできることが分かる。Webページでは、昔から、青色の文字に下線を引いてリンクを表す慣習があった。このため、青色の下線付きという選択は強烈な意味を持つのだが、これ以外のデザインにした場合に、どこがリンクなのか分からなくなる問題を解く必要がある。

※ブログのデザインは後から変更できるので、将来はデザインが変更されているかもしれない。ただ、その場合でも青系の文字に下線という条件を満たさないデザインは選択しないつもりだが。

他にも慣習的なルールはいくつかある。例えば三角のマークがあれば、その右(あるいはマークそのもの)をクリックできる、というルールがある。ただ、この種のお約束も、知らない人には通用しないため、どの程度認知されているかということもポイントになってしまう。

認知度とは無関係にクリックできることを分からせる方法がある。立体的なボタンを表示するのだ。前にも書いたが、人間は本能的に飛び出ているものを押そうとする。従って、画面上に立体的なボタンが表示されていたら、何の説明がなくても、そこが押せるものだと理解することができる。

従って、画面をデザインするときに、押せないのに立体的なボタンのように表示するのは望ましくない。また、画面全体が立体的すぎるのもよくない。いずれも、どこが押せるのか判断するのに妨げになるからだ。
AD
@nifty のホームページを改革するということで、β版が公開されている。アンケートが行われていたので、左上に会員が見て意味のあるものを配置して欲しいと回答しておいた。

ページレイアウトでよく言われるのは、見る人がどういう流れでページを見るのか考えろということである。全体の配置から視線の流れ、サービス移動の関連まで考えると、単に美しさというだけでなく、どのような理由でページを見るかというあたりまで考えなければならず、難しい問題だ。

そこで簡単な原理を紹介したいのだが、最初に見るのはページの左上、という法則がある。これはなぜかというと、横書きの文章は左から右、そして上から下、という流れで読まされるので、必然的に、最初は左上に視線が行くからだ。

※もちろん、特別な条件付けがある場合はその限りではない。例えば、縦書きのドキュメントなら最初に右上を見るはずである。

広告のレイアウトでは、Z状に売りたいものを配置いろ、というような法則もあるが、これもまず左上を見て、右へ視線が移動し、大雑把にそこから左下に流し読み、最後は右下で終わる、というパターンに従う人が多いことが分かっている訳だ。

そこで、左上に何を配置するかというのは重要なポイントなのだが、ここ Ameba Blog はどうか。ロゴが入っている。慣習的なものがあるのか、そのような配置のサイトは多い。ウィンドウをたくさん使う人は、最初に左上を見ると何のページか分かるという意味で、それなりに重宝する配置だが、あまりロゴが大きいと、最初に見るという重要な位置をうまく使っていないような気がして、どうももったいない。

Ameba Blog で評価したいのは、ログインのためのテキストボックスが左上の近くにあることだ。これが右側にあるサイトも結構あるのだ。

livedoor はどうかと思ったらメンテナンス中で確認できなかった。ココログはどうだろう? 左上には @nifty のロゴがある。これは仕方ないのかもしれないが、パッと見た所にニュース性がある内容がないのはもったいないような気もする。とはいえ、実は私はココログのトップメニューは殆ど使っていない。

えーと、「裏ご意見番」ですか…。だってレイアウトを自分で作れないし…というのは言い訳にもならないか。基本的に、このプログは、本文だけ読めばいいという感じなのだし。
AD
年月日をユーザーに指示させるというのは、ユーザーインターフェースとしては、設計するのが難しいものの一つである。そんなバカな、単に数字を指定させればいいだけだろ、とか思うかもしれないが、その順序が意外と決まっていない。年月日の表記は、文化や慣習によってまちまちなのだ。

例えば、年月日を技術的なドキュメントの中に入れろと言われたら、プログラマーの私の場合は、次のように書く。

  2004-09-27 15:00:00

なぜこういう書き方をするのかというと、この書き方が JIS で規定されているからだ。もし私信のような手紙の最後なら、次のように書く。

  平成16年 9月 27日

実はこの書き方が意外と優れている。誤読のしようがないのである。ただし、日本語が読めないと話は別で、訳の分からない記述になってしまうのだが。ユーザビリティエンジニアリング原論という本に、

> 月の表記は数字よりも文字にする方がよいでしょう。
(p. 195)

と書いてある。邦訳すると意味が分からないかもしれないが、つまり、9月だとSeptember と書け、というのである。英語圏ではそのようして、月を年や日と間違うことを防ぐことができる。日本で「月を文字にしろ」と言われても長月と書かれたらピンと来ない人が多いのではないか。冗談はともかく、日本には何年何月何日というような優れた書き方があるのだから、そのように書かせたらいいものを、今回は次のように書くように指示されている。

02/10/09 21:55    ← 受信日時

このように、スラッシュ(/)で年月日を区切る記法は、主に欧米で使われている。コンピュータの技術が先行したアメリカで使われている形式を日本にそのまま持ち込んでしまったこともあり、それ以前からも使われていたかもしれないが、日本でも結構よく使われている。

この記法の欠点は大昔から指摘されている。年、月、日の順序が国によって違うのだ。例えばアメリカでは月/日/年の順に書く。ということは、02/10/09は、09年2月10日を意味する。これがイギリスでは日/月/年の順になる。02/10/09は、09年10月2日ということになる。

日本では年/月/日の順に書くことが多い。02/10/09は、、02年10月9日ということになる。だから、この例を書いた人は、もしかするとスラッシュで区切った年月日は年、月、日の順に書くに決まっていると思い込んでいたのかもしれない。そのような思い込みは、しばしば危険な結果を招く。実際、今回、もしそれが許されるとしたら、年月日をどのような順序で書いても構わない場合に限るのだ。

では、どうしてもスラッシュで区切った表記をして欲しいとして、どのような例を示せばよいだろうか。割と簡単である。次のようにすればいい。

02/10/09 21:55    ← 受信日時 (年/月/日)

たったこれだけでも間違いは減るはずだが、次のようになっていれば、なおよい。

2004/09/27 21:55    ← 受信日時 (年/月/日)

どこがよいのだろうか? まず、2004 というのは月や日としてはあり得ないから、ここが年を書くところであると分かる。1文字を送信するのに何円もかかる世界ならともかく、こんな所で2桁ケチる意味は既にないのだ。

残った数字は09と27だが、09月はあっても27月はあり得ない。従って、残りが月/日の順であることが分かる。10/09という例では、10月9日なのか9月10日なのか分からない。だから、例示するときに、日の値を13以上にするのは重要である。というか、常識である。しかも、このような年月日の判断は、殆どの人は無意識に瞬時で行うことができるはずである。見逃しがちなポイントである。

もう一つ、これは細かい話だが、「09」と表現することで、9月を09と書くことが分かる。10月を例にすると、10月を「10」と書くことは分かっても、9月を「9」と書くのか「09」と書くのか分からないのだ。もちろん、「09」と書いてあっても4月を4と書く人は必ずいる。09と書いたから2桁で書いてくれると思い込むのも危険なのである。それに、その程度のゆらぎは後始末はソフトウェアで何とかするべきだ。

結局、何と最初の例は、年月日の3つの欄を「/」で書いてくれという情報しか与えていなかったのだ。どんな順序で書けばいいかを判断するヒントは何一つないのだ。

※但し、2002年にこれを見た人は最初の02が年だと思っただろう。年はそう頻繁に変わるものではないから、年を例示する場合は現在の年に合わせておくというアイデアがある。

さて、実はこのページで最も大きな欠点は別にある。このような問題を感じたときに、おせっかいな人が一言いいたいと思っても、どこに連絡していいのか分からないのだ。

どこかに連絡先のメールアドレスを書いておくだけでいい。実際、それが分かったら、私は今回書いた内容をメールで連絡したかもしれない。しかし、どこに連絡してよいか分からないのに、それを探して連絡する程の暇もない。ということで、結局連絡していない。偶然このコラムを担当者が見て修正してくれるといいのだが。当分あのページの例は、今のまま表示されることになるのだろう。

*

参考文献:
ユーザビリティエンジニアリング原論 ユーザーのためのインターフェースデザイン
ヤコブ・ニールセン著、篠原稔和監訳、三好かおる訳
東京電機大学出版局 ISBN4-501-53200-9
迷惑メールというと、spam とウィルス、これが二大勢力だと思うのだが、個人的には、一番迷惑なのはプロバイダやメーカーからの「重要」というタイトルのメールで、何かサービス停止の予告とか、ソフトウェアに欠陥があってアップデートしろとかいうのかな、とか思いつつ読んでみたら、新しいサービスを始めますという単なるDMだったという。

この種のメールは強制的に読まされてしまうので、迷惑この上ないのだが、契約しているプロバイダからのメールを全部読まないという方法で対処しているので、実際はあまり迷惑でもないのだが。

ウィルスメールは論外として、勝手に広告を送りつけてくるものは、「未承諾広告※」という文字をメールの題名に入れることが、日本では法律で義務付けられている。なお、私の所に来るメールは8割以上が海外からなので意味がない。

この表示義務違反のメールが来た場合、報告すれば対処してくれる機関があることをご存知だろうか?  財団法人 日本産業協会と、 財団法人 日本データ通信協会である。

前者の場合、連絡方法がトピックス/表示義務違反メールの情報提供についてに書かれている。これによれば、来たメールを転送すればいいので、楽に情報提供できるのだが、そのときに送信元アドレスと受信日時を先頭に追加することになっている。後者の場合はフォームに必要事項を書くのだが、その方が手間がかかるので、私はまだ使ったことがない。

とはいっても、このページ、昨年の10月7日付けで行政処分が行われたみたいなことが平気で書いてある。というか、昨年の10月7日以降は、行政処分が一件も行われていないのだろうか?

まあその話はおいといて、さて、今回注目したのは、情報提供時にメールの先頭に書けという、受信日時についてである。先に紹介したページには、こう書いてあるのだ。

02/10/09 21:55    ← 受信日時

これだけでもいろいろなことを想像しなければならない。受信日時というのは実際にメールを受信した日付なのだと思う。つまり、メールに表示されている日時ではないはずだ。これが意外と正確に思い出せないのである。受信日だけでもいいのか、とか悩んでしまうのだ。それに、例はいわゆる全角英数で表記されているのだが、そうしないといけないのかな、とか…。

(続く)
数日前の asahi.com に、押した手応えを与えることのできるタッチパネルが開発されたという記事が出ていた。実用化には数年かかるそうだが。

液晶画面上にタッチパネルを配置することのメリットは、画面上に表示されたボタンを直接押すという、一見当たり前の操作を実現できることである。パソコンやゲームの操作に慣れている人は、画面上に出ているカーソルをマウスやコントローラーで操作することに違和感がないかもしれないが、対象となるモノを直接ではなくマウスカーソルによって遠隔操作するというのは、かなり不自然な操作なのである。

ところが、その「直接指す」という当たり前の操作が、使いにくいと評されることもよくある。一体何がいけないのか。押したという感覚のフィードバックがないからである。

画面上のボタンを押す操作と、本物のボタンを押す操作、大きな違いが2つある。

まず、画面上のボタンを押したときにカチッという感覚がないこと。ここでいう「感覚」とは、カチッとか、パチッという感じの手ごたえのことである。カチッという感覚で、人間はそのボタンを確実に押せたことを知るのだ。

ボタンが押せたかどうか分からないと、ボタンを押した状態になったことに気付かずに、もう一度ボタンを押してしまうことがある。あるいは、ボタンを押した状態になっていないのに、押したと錯覚してしまうこともある。この種の誤操作を避けるために、タッチパネルを使った装置のユーザーインターフェースはいろいろ考えて作られている。例えば、押したら音が出るとか、ボタンが反転した状態になるとか。基本的には、押されたらすぐに次の画面に移るなどして、そのボタンをもう一度押せなくすることが望ましい。

もう一つの違いは、画面上のボタンは、そこがボタンであることを触れただけでは判断できないということ。実際のボタンは、目視で確実に確認しなくても、触感だけでだいたいの位置が分かる。ボタンを押すという操作は、まずボタン上に指を持っていって、それから押す。この最初の行動で、ボタンが押せる位置に指がある、ということが触感で判断できるのである。

触っただけで分からなければ、目視で確認するしかない。基本的に、眼で確認するというのは、大脳に負担のかかるもので、ストレスの原因になる。その結果、使い辛いということになる。

昔はATMや切符の自動販売機とか、機械式のボタンで操作したものだが、ある時期にタッチパネル化が急激に進んだ。このとき、特に盲人の方から大反対の声があったと記憶している。タッチパネルになると、手探りで操作することができなくなるからだ。

郵便局には、ボタンを併用できるタイプのATMが置いてある。だったらボタンだけでもいいじゃないかと思う。実際、このATMを使うとき、私は殆どの操作をタッチパネルではなくボタンで行っている。その方が簡単なのだ。(実は例外があるのだが、それはまたの機会に紹介したい。)

ボタンが見えない人は、タッチパネル化で「使えない」という致命的な問題が発生するから、そりゃもう反対するしかない。だが、ここでもう一つの問題はあまり騒がれることがなかったと記憶している。そうでない人も「使いにくくなる」という問題である。

触感によるフィードバックが軽視された結果、間違って押してしまう等の弊害は発生しているはずなのだが、少し使いにくくなる程度だと、社会的にはあまり重大なこととだとは思われていないのかもしれない。
ユーザーインターフェースの記事、細かい時間があったので少しずつ書いたのだが、最後に[決定]を押したところで無反応になった。ブログも表示されない。今日の14:30~15:00頃のことである。

今見ると、もちろん登録されていないし、書いた文章は消滅。この種のトラブルは、サーバーが動いていないから、ブラウザを使っただけのWebアプリケーションとしては対応が難しい。専用のアプリケーションから使うようにすれば、原稿をpcに保存するような機能で対処できるはずである。ブログの場合、アプリケーションから投稿するための手順が規約になっているので、その手順に従ったクライアントソフトを作ればいい。

ソフトウェアを作るときに、必ずその前の状態に戻ることができるようにするという方新がある。例えば、ファイルを削除する機能を用意するのなら、削除の取り消しができるようにする。編集中には undo という機能で、少し前に戻すことができるようにする。このような安全装置を用意することで、使い勝手が大きく向上するのである。

今回のような事故は、本文をブラウザではなくエディタやメモ帳のような他のアプリケーションで作ることでも回避できるが、基本的に、人間に注意を強いるという方針はよくない。ソフトウェアの作り方で回避できるのなら、その方がいい。いくら注意しても、ミスは発生するものだからだ。

もっとも、普通のブログなら、サーバーが無反応で記事が消滅するようなことは滅多にないのだが。

雑記 (3)

テーマ:
その他、気付いている内容をメモっておきます。

用語集の IP の綴りが「Weblog」になっている。しかも説明が凄い。訳が分からないというか爆笑ものなのだが、真面目なのだろうか? 百歩譲るにしても、多分そこに書いてある内容は「IPアドレス」の説明のつもりではないかと思われる。

用語集の「アーカイブ」。「過去の記事やトラックバックなどの一覧を見ることができます」というのは、確かにそういう機能なのだが、一般的な「アーカイブ」の説明ではないと思う。しかも、例えばアーカイブの「2004年9月」をクリックしても、9月の記事はなぜか途中までしか表示されない(9月24日現在)。

FAQの「デザインについて」の「アフィリエイト広告を貼り付けたいのですが」の回答が「プロフィールへの画像貼り付けは貼り付けはできません」という意味不明な言葉になっている。

雑記 (2)

テーマ:
相変わらずここは不安定なようですが、先ほどここを見ようとしたら、

Warning: main(dbgfunc.php): failed to open stream: No such file or directory in /usr/local/apache/htdocs/define.php on line 3

Fatal error: main(): Failed opening required 'dbgfunc.php' (include_path='.:/usr/local/lib/php') in /usr/local/apache/htdocs/define.php on line 3

なんて表示されていたのは何だったのだろうか、とか思ったりしますが気にしません。

本題なのですが、実は私は裏ページをいくつも持っていて、どこが何やらわからなくなってしまうので、縦断検索できるように…いやまてよ、横断検索? あれ? 分からなくなったな…まあ気にしないことにして、とりあえず、ココログというブログと、Jugem というブログ、どちらに書いた内容も全文検索できるようにしています。テスト版ですが、uraura Searchをお試しください。

これはどういう仕組みかといいますと、Jugem の方にプログラミングのネタが集めてあるので、あちらに詳しく書くかもしれませんが、要するに、自分のブログの内容を解析して本文と必要最低限の情報だけ抜き出し、それを検索のキーにできるように処理する、という感じなのですが。

ということで、Ameba Blog の「裏ご意見番」も検索対象にしたい、というのは当然の成り行きです。もちろん、しようとしました。ところが、この全文検索用の前処理プログラム、ブログの内容がある程度正しい HTML (または XHTML)であることを前提にしています。プログラムはまさに機械的にデータを解析しようとしますから、予想もしないモノが現れたら爆発してしまうのです。

もちろん、ブログの中のレイアウトは各ブログによって全然違いますから、それぞれに応じた作戦をある程度考える必要があって、このブログの場合は何々という文字が出てきたらこう処理してみよう、みたいに考えるわけですが…。

ところが、Ameba Blog は凄いです。あまりの凄さに、ちょっと後退りしました。これは、プログラムで解釈可能なのか、いや、でも、ブラウザは表示しているようだし…。ある意味、ブラウザがこれを画面に表示しているのは奇跡に近いのではないかと。例えば、カレンダーのところ、

<td>4</tr><tr></td>

とかいう並びが平然と出てきます。これってどういう感じか、HTML を知らない人にも分かるようにいいますと、

「おっと(びっくり)」

と書くべき所なのに

「おっと(びっくり」「)

になっていると。こんなのプログラムが機械的に解釈できるのだろうか? もっと凄いと思ったのは、最近の記事一覧のところです。<a> タグが閉じていない!のです。このあたりで、作戦立てるというのも諦めて、本格的な秋が来るのを待とうかな、と考えている今日此の頃です。

(しかし、それではナニなので、実は、密かに昨日までのココの記事も検索できるようになっていたりします。)
9月22日付で、次のような障害報告が発表されている。

記事投稿の際に「 < 」を入れるとそれ以降の記事が消えてしまう。

なぜかというと、< を本文中に入れると HTML タグと認識されてしまうから、というのだが、これはかなりおかしな話である。なぜなら、Ameba Blog では、HTML タグは使えないことになっているからだ。HTML タグが使えないのなら、本文の内容が HTML タグだと認識する必要はないのである。つまり、この説明は説明になっていないのだ。

なお、これが障害だというのは、「<」以降の本文が消えてしまうからではなく、むしろ、プレビューでは「<」以降もきっちり表示されているから、安心して[決定]ボタンを押してしまったら最後、二度と元に戻れない、という致命的な結果になるからだ。プレビューと実際の表示が異なっていることが問題なのである。

さらに、障害報告の中には「<」を独自タグ以外の場所で使うな、という趣旨のことが書かれている。これがまたおかしな話だ。独自タグというのは一体何なのだ? 例として「<太字>」が紹介されているのだが、例だけでは分かったようで分からないし、かといって、困った時に見ろという「用語集」には、「独自タグ」という言葉は説明されていない。(9/24現在)

ここはまず、独自タグとは何なのかを明確にすべきだと思うのだが、まあしかしここは一歩譲って、意味不明だが、独自のタグと言いたいのだと解釈しておこう。

しかし、「<」が使えないと困るのではないか? 特にプログラミング系の話題を書きたい場合には致命的なのでは。心配はない。「<」と書きたいときには、「&lt;」と書けばいい。実はこのことは FAQ にも出ている。しかも、そうやって書いた記事を編集しようとすると、「&lt;」が「<」に変わってしまうことまでサラッと書いてある。個人的には、そのことの方が、よほど重大な障害だと思う。一旦書いてしまったら、膨大な手間をかけないと編集できないことになるからだ。

そこで、「&lt;」のような文字列を本文に書いている場合は、とりあえず本文全部をコピーして手元のパソコンに保存しておいた方がいい。そうしておけば、後で変更したい場合は、保存しておいた本文を修正して、全てコピーすることで対応できるからだ。