Inside Macintosh
Inside Macintosh Volumes I&II（日本語版）
昔の開発者向けのドキュメント『Inside Macintosh Volumes I&II（日本語版）』 の中に「2 The Macintosh User Interface Guidelines」という項目がある。（月刊漫画雑誌のようなボリュームに対して40ページ程度と割合としては少ないが、ここから徐々に記述量が増えて今につながっていると思うとなかなか良い）
開発者向けのドキュメントの最初にガイドラインが位置づけられていて、こう紹介されている。
第2章 The Macintosh User Interface Guideline。すべてのMacintosh アプリケーションは、一貫性のある親しみやすいインタフェースを確実にエンドユーザーに提供できるように、これらのガイドラインに従う必要があります。
そしてセクションのまずはじめに次のような記述がある。
Macintoshは、今までコンピュータに対して恐怖感と不感を抱いていた人を含めたプログラマ以外の人を対象に設計されています。この目標を達成するには、アプリケーションは習得しやすく、使用法が簡単でなければなりません。アプリケーションがなじみやすいためには、すでに得た知識の上にさらに知識、技能を積み重ねていくようなアプリケーションでなければならず、新しい知識の習得を強制するものであってはなりません。ユーザーがコンピュータをコントロールしているという実感が重要で、その逆、つまりユーザーがコンピュータにコントロールされているように思わせるものであってはなりません。これはアプリケーションに以下の三つの性質を持たせることにより実現されます。
繰り返そう。
「ユーザーがコンピュータをコントロールしているという実感が重要で、その逆、つまりユーザーがコンピュータにコントロールされているように思わせるものであってはなりません。」とはっきりと宣言している。
応答性、融通性、一貫性
アプリケーションで重要な性質を応答性、融通性、一貫性と３つ挙げている。のちに別冊となった Human Interface Guidelines だと10原則まで増えているので、それに比べるとシンプル。
応答性とはユーザーがとる措置が直接の結果を生み出すことです。ユーザーが「Cという命令を実行するにはAとBをまず実行して・・」などと考えてしまうようなものではなく、瞬時に直感的に判断できるものでなくてはなりません。例えば、pull-down menuを使うと、必要なコマンドを直接、即座に選べるようになっていることなどです。
これは「直接操作感」やHIGにある「操作の直截性」につながるものかもしれない。
融通性とはアプリケーションがユーザーがしたい事は何でもできるようになっていることです。つまり、システムではなくユーザー自身が次に行うべきことを決定できることです。さらに、エラーメッセージが頻繁に出ないようになっていることです。ユーザーが矢継ぎ早にエラーメッセージ攻めにあう場合は、どこかで何かがうまくいっていないことを示しています。
アプリケーションが融通のきくものであるためには、モードの使用を避けることが必要です。これは非常に重要な事項なので別の節“Avoiding Modes”で説明します。
これも、HIGで言えば、システムではなくユーザー自身が次に行うべきことを決定できるという点は「ユーザーコントロール」、メッセージがそもそも表示されないという点では「寛容性」あたりと似ている。しかも「モードの話は重要で長くなるからまた後で」とでもいうような力の入った書き方になっている。
最後にあげた一貫性、これが最も大切な原則です。ユーザーは通常、複数のアプリケーションを使用するので、アプリケーションごとにまったく新しいインタフェースを習得する必要が生じると、ユーザーは混乱し、いらだちます。本章の主要な目的はMacintoshアプリケーションの共用インタフェースの概念について説明することです。この結果、新しいアプリケーションを作ろうとする開発者は、既存のアプリケーションの開発とテストに使われた時間を新しいアプリケーションに費やされたものとして活用することができます。
一貫性は大事。実際にはどの部分を一貫させるかというのは判断に迷う部分もあるが基本として大事。
「Macintoshは成長するシステムであり、新しい設計概念を必要としています。しかし、すべてのアプリケーションに備わっているような一般的機能は、ユーザーがアプリケーション間を簡単に行ったり来たりできるように、必ず同じように製作する必要があります。アプリケーションがガイドラインに沿った機能を備えている場合には、その機能がガイドラインに述べられている通りに動作しなくてはなりません。中途半端にガイドラインに従うくらいならまったく別のやり方にした方がよいくらいです。」という記述もあり、特に一般的な機能に関しては一貫していることを強く求めている。
アプリケーションとガイドラインのどちらに従うか？
アプリケーションとガイドラインの間にある逸脱と規則化の繰り返しの観点からも興味深い記述がある。
本章で説明する機能の大部分は既存の様々なアプリケーションに見られるものですが、このガイドラインにある事柄を逐一すべて備えたアプリケーションはおそらくありません。既存のアプリケーションを学ぶことにより、Macintoshのユーザーインタフェースを理解することは大切ですが、本章に述べられたガイドラインは根本的なものです。もし、あるアプリケーションがガイドラインと一致しない場合は、そのアプリケーションではなくガイドラインに従ってください。
ガイドラインに一致しないアプリケーションの存在を認めつつも、ガイドラインを重視している点がおもしろい。つまりガイドラインに一致しないことはあるけれど、それは暫定的、試作的なもので、基本的な考え方はガイドラインに立ち返って考えてほしいということなのかもしれない。
現在でも、Apple は自ら規定したHIGから逸脱したアプリを作ることもあるので、これは普遍性のあるトピック。アプリがAppleに買収された直後はガイドラインに従ってないデザインになっていることもよくある。そういった時にアプリとガイドラインのどちらを参照してほしいかと言えば、ガイドラインになるだろう。
また、こういった原則は、そもそも複数のアプリのデザインを元に、汎用性のある部分をガイドライン化するので、こういうスタンスになるのもわかる。暫定のまま、試作のままで終わるか、それとも目指すべきデザインとして新たにパターン化するのか、微妙なバランスの上でガイドラインは更新されていく。
Avoiding Modes
後回しにされていた「Avoiding Modes」というセクションを見てみる。HIGの「モードレスオペレーション」の記述と近い内容になっている。
モードは、アプリケーションの一部であり、ユーザーはそのモードから出たり、入ったりする必要があります。またモード内ではオペレーションは制限されます。通常、人間は実生活でモードにより行動することはありませんので、モードを持ったコンピュータのソフトを使用すると、コンピュータは不自然なもので好きになれないという考えが強くなります。モードほど間違えると混乱するものはありません。誤ったモードに入ってしまうと、以後の制作は今まで行った動作に影響し、良く知っているオブジェクトやコマンドの動作が制限され、場合によってはいつも行っている動作が意外な結果を生むことになりかねません。
既存のソフトは非常にモードに頼っているので、Macintosh アプリケーションでもモードを使用したくなりますが、あまりひんぱんにこの誘惑に負けていると、ユーザーはアプリケーションに使う時間を、有意義な経験というよりもくだらない仕事をする時間であると考えてしまいます。
直接的なモードの定義は書かれていないが、知っていたはずの操作を制限するものであり、間違えると混乱する、思わぬ結果（おそらく悪い結果）を生むものというように書かれている。その結果「くだらない仕事をする時間」になってしまうとも。「くだらない仕事」はパワーワードだ。今だったらブルシットジョブって呼ばれるやつかもしれない。『About Face』 の間接的負荷を思い出す。またHIGと同様にモードの種類についての記述もあった。
Inside Macintosh はいくつかのバージョンがあるようで、近しいものの英語版はInternet Archiveにあるので、興味がある方は是非。
ラリー・テスラー
おまけとして、Internet Archiveのさらに古いバージョンを見てみると、この時点では「About Modes」というセクションがあり、ラリー・テスラーのモードの定義が引用されていた。
We adhere to the principles of modeless behavior. Larry Tesler defines a mode as follows:
Inside Macintosh Vol 1 1984（Internet Archive）
A mode of an interactive computer system is a state of the user interface that lasts for a period of time, is not associated with any particular object, and has no role other than to place an interpretation on operator input.
『Byte』 Vol.7 No.4 の Star について書かれた「Designing the Star User Interface」ですでに引用されており、注釈18によると、元々はラリー・テスラーの私信にモードの定義があった様子。
18.Tesler, Larry. Private communication; but also see his excellent discussion of modes in “The Smalltalk, Environment.”BYTE, August 1981, pp. 90-147.
『Byte』 Vol.7 No.4