クロスプラットフォームの現実

Tog,

Java は、単一ソースの製品で複数のプラットフォームに対応できると約束して（そしてほぼ現実になって）います。これで、ひとつの製品をより多くの人に使ってもらうことができるようになります。

やがて Java が成熟して、その約束どおりになっていく時、Java はそのプラットフォームとなる環境とどのように調和をとっていけばよいと考えますか？

それらの製品は主に、Macintosh と Windows プラットフォームを対象とすると思われます。そうすると、製品は以下のいずれかのアプローチからデザインされるのではないでしょうか。

1. Windows を真似る
2. Mac を真似る
3. Mac 上では Mac を真似て、Windows 上では Windows を真似る
4. 独自のデザインにする

はじめの二つは、それぞれ他のプラットフォームを無視して問題から目をそらしているし、せっかくの機会を放棄することになります。三番目のアプローチは初期の Java 開発ツールで実装されていましたが、各環境で一般的になっていたコントロールに対する制限のために多くうまくいきませんでした。四番目のアプローチは、開発者たちがデザインの基礎を分かっていないために、なかなかうまくいかないと思われます… そして多くの努力がデザインに注がれるのにも関わらず、ユーザは多種多様の見慣れないアプリケーションに付き合わされる羽目になるのです。

C r a i g O s h i m a
Software Designer

現実的な回答は、片方の大物に焦点を当てることだろう。あなたが優れた Macintosh の利用者でない限り、Mac（もう一つの大物）のためだけにインターフェイスをデザインすることは経済的に自殺行為だ。

四番目の方法は、Kai's power tools の Kai Krause のような特殊な例外を除けば、多くの人にとって有益だとは思えない。人々は、あなたの特異なインターフェイスを学習するよりも他にやらなければいけないことがたくさんある。たとえ通り一遍のユーザテストでそのデザインが受け入れられたとしてもだ。

そうするとほとんどの人にとっては、一番目と三番目の、片方の大物を相手にするのが良いということになる。Craig が指摘するように、三番目の方法は現状難しいだろう… ツールがまだ貧弱すぎるのだ。

ひとつのやり方に絞るのが最も簡単な選択だ。我々のうち何人がたくさんの Mac または UNIX ユーザをサポートしているのだろうか？そして Bill はいつも Windows の外観を持ち込んで我々をサポートしてきたのではなかったか？無料あるいは安価なツールを提供し、彼のやり方を浸透させてきたのだ。私が言いたいのは、そのプログラムのやり方を続ければいいのではないか、ということだ。

恐らくこの話題で14か15のコラムが書けるだろう。この辺で議論の対象を絞った方がよさそうだ。事実は、我々 Macintosh ユーザ ─ それから UNIX ユーザ ─ はやがてウェブに漂うたくさんの Windows ライクなソフトウェアを目にするようになるだろうということである。我々の OS 供給者は、我々がもっと暮らしやすくなるために何ができるだろうか？たくさんある。そして困難はそれだけではない。

Apple にいる友人たちへ：

ここ数年の間我々は、様々なシステムの特性に順応する来るべきクロスプラットフォーム時代のアプリケーションについてたくさん聞かされてきた。

Apple は、Macintosh をもっと Windows に似せるべきである。いやいや、Windows のように下品でごまかしだらけにしろというのではない。ただ、Windows を真似たソフトウェアを使わなければならない ─ または職場で Windows マシンを使わなければならない（なんてこった） ─ Mac ピープルのために、いくつかの小さな変更を施してほしいのだ。

一貫性とは面白いものである。一貫性の中で最も重要なのは、人々がそのことを考えもしないところである；それ故に最も重要なのだ。何のことを言ってるのかって？ショートカットキー。ボタンの順序。そしてそのようにユーザがずっと以前に学習し、吸収されて習慣になってしまっているたくさんの小さなことである。これらの実装のされ方が Windows では逆になっている。いや、言い直させてくれ。これらは Windows では逆だった ─ Windows が市場シェアの90%を獲得するまでは。そして現在では、Macintosh の方が逆をやっているということになるだろう。

キーボード・ショートカット

Macintosh では、主要なモディファイアとして Command キー（スイスの道路標識のサインのついたキー）を使用する。Command-C はカット、などなど。Windows では Control キーを使う。Macintosh と Windows または Windows ライクなソフトウェアを行ったり来たりするユーザは、この違いによって気が狂いそうになる。これについては Windows の方がうまくやっている。Macintosh の Command キーは X と C キーのすぐ下にあるため、このショートカットを使うには、親指を塩をかけられたナメクジのようにねじ曲げなければいけない。Macintosh はユーザが初期設定を変更して Command キーを Control キーに割り当てられるようにするべきである。（現時点でも QuicKeys を使うことによってこれは可能である、しかしメニュー内に表示されるショートカットシンボルを変更することはできない。これができるのは Apple だけである。）

キーを変更するのであれば、1984年の Macintosh ガイドラインが謳っているように、Command-クリックを複数選択に使用できるようにすればいい。これはすぐにでも Finder に実装すべきだ。Shift-クリックという既存の方法については何も変更しなくて構わない。単に Command-クリックの機能を追加すればよいのだ。

ボタンの配置

Macintosh では、「OK - キャンセル」「はい - いいえ - キャンセル」などのボタン列において、デフォルトボタンを一番右に配置している。これについては Windows は全く間違っている。ウェブページに関するユーザのメンタルモデルでは、次に来るページは右側にある（欧米の言語使用者の場合）。だから「次へ」のボタンは右側に配置されなければならない。これは Windows における“デフォルトボタンは左側に置くこと（ただ時々間違えてもよし）”というルールに反している。本当におかしなルールだ。でもそんなことは構わない。Macintosh は堪え忍んでボタンの配置を変更すべきである。これもまた、かたくなに変更を拒むユーザのために初期設定で変更できるようにしておけばよい。

Apple は Windows マシンを数台購入して、Macintosh ユーザがどのような苦労をしているのかをよく研究すべきである。そして上記のように、何を変更すればよいのかをよく考えるべきだ。QuicKeys を知るまで私は、Command/Control の混乱のために Macintosh を完全に放棄しようとしていたぐらいだ。（私はオフィスにそれぞれ一台ずつ持っている。）一日のうちに私は25から30回もキーを押し間違えていた。こんなことで献身的なユーザを失うなんて、企業にとっては全く馬鹿げたことではないだろうか？しかしこういったことが原因で市場から消えていった企業はたくさんあるのだ。最後までその理由が分からないまま。

-Tog