コンピュータに対して、ユーザーがあるアクションを与えた場合、目の前でどのようなことが起こるかは、ユーザー体験にとってとても重要な要素だ。OSはもちろん、アプリケーションや、小さなユーティリティでも、考えに考えて振るまいが決められていなければならない。 ●フォルダの統合と置き換え たとえば、デジカメで撮影した写真を、コンピュータの適当なフォルダにコピーしたいとする。通常、デジカメは、メモリカードのルートにDCIMというフォルダを作り、さらに、その中に自機名を称するフォルダを作り、そこに連番を持った画像ファイルを生成する。このDCIMフォルダをメモリカードのウィンドウから、コンピュータのHDD内の適当なフォルダウィンドウにドラッグ&ドロップするとしよう。 Vistaでこのアクションを与えると、異なるドライブ間のドラッグなので、コピーをしたいのだと見なされる。コピー先にDCIMフォルダがなければ、DCIMフォルダの内容がそっくりそのままコピーされる。また、コピー先にDCIMフォルダがあり、その中に過去にコピーしたファイルが格納されていれば、Vistaはダイアログボックスを表示し、フォルダを「統合」するかどうかを尋ねてくる。 この宛先には既に'DCIM'フォルダが存在します。 統合を指示すると、既存のファイル、フォルダ類はそのままに、新しいものだけをコピー、もし、同名のオブジェクトを見つけた場合は、コピーして置換するのか、コピーしないのか、コピーするが両方を保持するのかをどちらを保持するのかをたずねてくる。また、オプションとして、今後同じ処理を他の競合にも適用するように指示することもできる。 Mac OSで同じことをすると、その振る舞いは大きく異なる。Mac OSでは、 'DCIM'という名前のより古い項目がすでにこの場所にあります。現在移動中のより新しい項目で置き換えますか? というダイアログボックスが表示される。 ダイアログボックスのタイトルは「コピー」で、期待通りコピーを行なおうとするが、メッセージは「移動」だ。もし、ここで「置き換える」を指示した場合、何が起こるかというと、フォルダそのものが新しいものに置き換わる。 これが何を意味するかというと、古い撮影済みファイルがすべて消えてしまうということだ。Mac OSとしては、フォルダを置き換えろというから置き換えたのであって悪気があるわけではない。初めてこの振る舞いを体験したときは蒼くなってしまったが、環境内で振る舞いの思想が統一されていればそれでいいと納得することにした。Mac OSにとっては、フォルダもファイルもオブジェクトのひとつであり、中に何が入っていようが関係がないのだ。そういう意味ではVistaは気が利きすぎているともいえる。 ●プログラムを作る側と使う側 久しぶりにちょっとしたプログラムを書いている。プログラムといっても、単なるVBスクリプトだから、プログラムというのもおこがましい。 何がやりたかったかというと、VistaノートPCの液晶(LID)を閉じたときに、スリープするのか、何もしないのかを簡単に切り替えたかったのだ。クイック起動に登録しておいて、クリックするだけで、LIDクローズ時のアクションを切り替えるようにするスクリプトで、たったそれだけのことだが作り始めると奥が深い。 Vistaには、powercfg.exeというユーティリティが含まれ、これを使うと、現在の電源プランの取得や、その設定の変更を行なうことができるので、スクリプトからこのプログラムを呼び出すことにした。電源プランや各設定には、GUIDと呼ばれる識別子が割り当てられ、これを使って変更対象を指定することになる。VBスクリプトからは、標準出力さえ取得できないので、リダイレクトして一時ファイルに書き出すなど、けっこう煩雑な処理が必要だ。 プログラムを作っていて、VBスクリプトについてよくわからないことがあったので、本誌でもおなじみの塩田紳二氏にメールで尋ねてみたところ、同種のスクリプトを書いてくださった。プログラムを見ると年期が入っていることがよくわかる。ただ、他人の作ったプログラムを読むのは本当に難しい。 それはともかく、ユーティリティとして見たときに、それをどう振る舞わせるかの考え方がまったく違うのに驚いた。 ぼくは、単純に、プログラムを実行したときに、指定したことが起こるようにしたかったので、起動時オプションを用意し、「何もしない」、「スリープする」を指示するようにした。もし、オプションが指定されなかった場合は、ダイアログボックスを表示して、どうするのかを尋ねるようにプログラムを書いていた。また、スクリプトは自分自身のファイル名を取得できるので、同じスクリプトを別のファイル名で用意しておき、ファイル名で振る舞いを決めることも考えていた。 一方、塩田氏から送られてきたプログラムは、現在の設定を読んだ上で、 DC時、液晶クローズで何もしないに設定されているとき 液晶クローズでスリープするように設定されているとき と振る舞うようになっていた。 液晶を閉じたときに、スリープしないようにしたいというケースは、部屋から部屋へのちょっとした移動や、電車の乗り換え、会議中にバッテリ節約などのためにメモしないときには液晶を閉じておくといった、一時的設定の場合が多い。 塩田氏のプログラムは、ダイアログボックスを出しっぱなしで一時停止するような使い方も想定されていて、そのための仕様が盛り込まれている。だから、ダイアログボックスが表示されたときには、すでに設定は変更されていて、「はい」、「いいえ」にしたがって、元に戻すかどうかに分岐する。問い合わせのダイアログボックスを放置して他の作業を続け、目的が終わったら元に戻せるわけだ。 明示的に何かを指示していないのに、設定の変更が行なわれるのは、あまり気持ちのいいものではないが、実際の使い方を考えるとスマートだ。それに、プログラムを実行した時点で、ユーザーは、すでに何かを指示したと考えることもできる。 ●開発の現場の若い人たちへ ほんのちょっとしたプログラムにしても、その振る舞いを考え始めると、実際にコードを書いている時間よりも、多くの時間がかかってしまう。まして、Mac OSにおいて、フォルダの上書き時に、フォルダごと置き換えてしまうかどうかを決めるのには、歴史的な経緯もあるのだろうが、相当の議論があったにちがいない。実際、Mac OSのターミナルでは、UNIXのcpやmvコマンドが使えるが、これらの振る舞いは、Mac OSのシェルであるFinderとは異なる。 プログラムを使う側としては、作った側の意図を想像するしかない。その想像がはずれると予期しない結果を招き、場合によっては混乱に陥ってしまう。だからこそ、作る側は、使う側の期待を、あらゆる観点から想像して振る舞いを決めなければならない。 世の中には、ウェブアプリやインタラクティブコンテンツを含めて、多くのソフトウェアが存在するが、そのすべてが、きちんと使う側のことを考えて作られているかというとそうでもなさそうだ。これは、ハードウェアのデザインにだっていえることだ。3分でも使ってみたら都合が悪いことくらいすぐにわかるだろうと思えるようなデザインも多く経験する。 この春から開発の現場に携わることになった若い方も多いと思うが、たまにはそういうことも考えてほしいと思う。
(2008年5月16日)
[Reported by 山田祥平]
【PC Watchホームページ】
|