（作成：平成10年8月18日、更新：平成10年8月20日）

　Apple社によって提唱されたOpenDocのソフトウェア技術は結局、今後の開発が凍結されてしまいましたが、ユーザーインターフェースという部分では非常に興味深いものがありました。まずはUIの話しに入る前にOpenDocの特徴を簡単に説明しておこうと思います。説明するのは非常に難しいのですが、こんな感じでした（すこしはずしているかもしれません）。

• ソフトウェアのコンポーネント化
  • 肥大化するアプリケーションに対する一つの解答であったと思いますが、結局のところ、OpenDocもシステム部分でいうほどコンパクトにはなっていなかったように感じます。肥大化しつつあったアプリケーションはその反面非常に高機能で作業の生産性をあげるのに役立ったと思っていたりしています。それでOpenDocの方はというと、高機能という程のものでないにも関わらずメモリーなどのリソースに割と負担があったように思うのですが...（確かに、文書空間のメモリーは少ないですが、システムメモリーが非常に膨らんでおりました）
• アプリケーションの枠組みをなくす
  • うまく説明できませんが、従来のアプリケーションの形態ではなくパーツという形態で、文書の編集機能などを提供します。アプリケーションのように独立はしておらず、一つの文書でいくつかのパーツを呼び出す事ができるような仕組みで複合文書を作成できるという事になっていました。またそれによって、今まではアプリケーションのバージョンアップによる機能拡張しかなかったものが、パーツの機能アップや他のパーツの組み合わせ追加によりあたかも編集機能のバージョンアップのような仕組みを提供していました。（MRJのバージョンアップがそのままCyberdogのJAVA機能のバージョンアップのように感じた事があり、OpenDocの奥の深さに感嘆した事があります）
  • よくMicrosoft社のOLEと比較されますが、こちらはあくまでアプリケーションの延長ですが、OpenDocの方が考え方が美しく志しが高かったように感じます（これだけの説明だと？？？かもしれません）。ですが、結局OpenDocの将来性はなくなってしまった現状ではOLEの方に軍配はあがったのではないかと思います。MacOSにはリンク（発行/引用）の機能はありますが、埋め込みの機能がありません。この辺りの機能提供はOpenDocで...という事だったのですが、結果的に今となってはMS-Officeの導入によるOLEに頼らざるを得ない状態は少し寂しい状況です。
  • アプリケーションの枠組みをなくすというのはやはり既存資産のアプリケーションに対してかなりの修正を要求していたのではないかと思います。それが強いてはOpenDocパーツの不足（対応製品が少なかった）へとつながったと思います。そういう意味では最近のラプソディのイエローボックスAPIの戦略を、カーボンAPIへと移行させたのは正解ではないかと思います。
  • ちなみにOpenDocが一時Apples社の救世主的扱いだったのは、上記の理想もさる事ながらMacOSのもつメモリ管理の未熟な部分の解消に役立てようとしていたのではないかとも思います。
• ドキュメントセントリックなUI
  • OpenDocによって、ユーザーインターフェースが変わろうとしていました。この部分に私は非常に興味をもちました。この部分を詳しく取り上げたいと思います。

OpenDocによって変わったユーザーインターフェース

　ここからが本題となりますが、ユーザーインターフェースに変革をもたらす項目をあげると以下のものになります。

• アプリケーション起動する事がない（ひな型ファイルで立ち上げる）
• アプリケーションの切り替えでなく、文書の切り替えになる。
• 文書のファイルメニュー（正確にはドキュメントメニュー）が変わった！！
  • このメニューからファイルの削除ができる。
  • コメントなどを編集できる→（つまりFinderでできる事がここからできる）

アプリケーションを起動しない

　これだけだと、なんの事かよくわかりませんが、アプリケーションの枠組みがないのでアプリケーションを起動しないのです。それじゃどうやって新規文書を作成しはじめるかですが、ある（コンテナとなりうる：これがルートパーツになる）パーツのひな形ファイルを開く（ダブルクリックする）事になります。つまり、ひな形ファイルがひとつの白い紙（場合により制定用紙）であり、そこから文書作成がはじまるという事で、これがドキュメント指向といわれるゆえんです。

　ちなみにもともとからMacOSのファイル管理では、ひな形ファイルという形式があってこれを立ち上げる事によってひな形ファイルの内容/書式をひきつぎ新規文書を作成する事が可能でした。また既存ファイルもFinderから開く事で（自動的に該当アプリケーションが起動し）編集する事ができました。つまりユーザーインターフェース上はドキュメント指向な部分を提供していたのです（が、さすがに既存ファイルの立ち上げはFinderから実施する事が多くても、新規ファイル作成時はアプリケーションを立ち上げる（これにより新規ファイルが開く）方が慣れ親しんだ方法ではないかと思います）。

　それで、こういう意味では、OpenDocでアプリケーションの枠組みを（APIをがらりと変えてまで）なくす必要があったのか？？って今でも疑問です。アプリケーションという枠組みでも複合ドキュメントやドキュメント指向のユーザーインターフェースも可能だったはずです。既存の資産（ここではアプリケーションプログラム）をいかせる緩やかな移行が可能な方法をとってもらいたかったです。

（余談１）ちなみに、Windowsでも（OSの機能ではなく）アプリケーションでテンプレートの機能があります（MS-Wordの場合 ．ＤＯＴファイルですね）。ですがこのDOTファイルをWindows3.1の時はファイルマネージャーから立ち上げると新規文書作成ではなく、テンプレートファイル編集になってしまいました。あくまでテンプレートファイルを使うには、アプリケーションからテンプレートファイルを選ぶ必要がありましたね。（なお今はWindows95かOffice97のどちらか？の機能で、ちゃんと？.DOTファイルをExplorerから立ち上げるとMacOSのような動きになっているようです）

（余談２）MS-WordのMac版（Ver6.0）のテンプレートファイルも変です。ひな形ファイルになっていなくてFinderから立ちあげると、Oop！テンプレートファイルの編集モードです。全然文書指向じゃないし、テンプレートを使う場合は、一度アプリケーション立ち上げて、それから新規作成メニューからテンプレートを選ぶ必要があるのです。（なおExcelのテンプレートはひな形ファイルの形式になっていました。）

（余談３）Windowsでも文書指向を強化する意味でよい方法/機能が追加されています。例えば、デスクトップなどから新規文書を作成できるようになっている点です。右クリックメニューで新規ファイルを選ぶ（サブメニューでテンプレート選べる）と、そこにファイルができあがり、それを開いて編集ができるという感じです。ユーザーインターフェースとしてはなかなかよくできていると思います。

アプリケーションメニュー

メニューバーの一番右にあるアプリケーションメニューは複数のアプリケーションを切り替えるために使いますが、OpenDocを利用している場合は、複数のドキュメントを切り替えるような感じになります。これは非常に便利です。

以前、アプリケーションだけでなく、アプリケーション内の（文書単位の）ウィンドウをサブメニューで切り替えたり、隠したりできたらいいと書いた事があるのですが、OpenDocの場合はそんな事しなくても、同じような事ができてしまうと考えてもいいですね。

アプリケーションメニューの例 　左図はドローパーツを二つたちあげている（その他オーディオもパーツ）例ですが、通常のアプリケーションならドローがひとつになるのに、ここでは二つになっている。つまり文書ごとにメニューが現れる。 →文書単位できりかえられて、とても便利である。

次のページへ続く