ユーザー主導でアプリケーションの外観を決定するには
我々が普段使うアプリケーションには大きさや形の異なるさまざまなオブジェクトが配置されています。どんなアプリケーションもその外観は（少なくとも初期の外観は）設計段階で決定されます。開発者はユーザーのことを考えてプログラムの外観をできるだけ良いものにしようと努力しますが、何が最も良いかはユーザー個人の判断で決まるものなので、設計者が主導するタイプのアプリケーションである限り、この課題に解決を見出すことはできず、設計者とユーザーの対立はいつまでも続きます。
この対立の根源は、設計者主導のアプリケーションという基本的な考え方にあります。適応インターフェースや動的配置を採用したところで、問題に片を付けることはできません。この厄介な問題を乗り越え、プログラミングとアプリケーションのすべてをもう一段高いレベルに進めるには、ユーザー主導タイプのアプリケーションに移行するしかありません。ユーザー主導タイプのアプリケーションとは、設計者はアプリケーションの目的や計算アルゴリズムだけを決め、アプリケーションの外観は完全に個々のユーザーが決定するというものです。
この問題を解決するために必要なのは、すべてのオブジェクトを移動可能／サイズ変更可能なものに転換できるようにするアルゴリズムを設計することです。このようなアルゴリズムには大きく次の2つの条件が課せられます。
アルゴリズムの条件
第一に、どんなオブジェクトでも簡単に実装できなければなりません。第二に、完全に自然なやり方で移動やサイズ変更ができなければなりません。何も知らないユーザーでも、ごく自然に移動やサイズ変更ができるようにする必要があります。ユーザー側が知らなければならないのは、「すべてのものが移動可能／サイズ変更可能である」という事実だけです。
設計者主導タイプからユーザー主導タイプへの移行は、ある意味で革命的な一歩と言えます。アプリケーションを扱う主体には開発者とユーザーという2種類のコミュニティがあり、先ほど挙げた第一の条件は開発者がこの一歩を踏み出すための助けになり、第二の条件はユーザーがこの一歩を支障なく踏み出すための鍵を握ります。
アプリケーションに含まれるすべての要素を移動可能／サイズ変更可能にするという条件は、ユーザー主導アプリケーションの中核機能に関わってきます。たった1個の移動可能オブジェクトをアプリケーションに実装する場合でも、そのためには周囲のすべての要素やリンクされたすべての要素に同じ性質を持たせなければなりません（道路上に移動できない要素を1つでも置いたら大事故になるということと同じです）。
アルゴリズムと実装の例
アルゴリズムの簡単さは、ユーザー主導アプリケーションを設計する上で決定的に重要な要件です。アルゴリズムと実装の例を見てみましょう。アプリケーション「GraphicsMRR」は、4つのフォームにサンプルを表示します。アルゴリズムの詳しい説明はwww.sourceforge.netのMoveableGraphicsプロジェクト（大文字と小文字が区別されることに注意！）にあります。ここでドキュメントとプログラムを手に入れることができます。
用語説明
最初にいくつか用語を説明します。このアルゴリズムの基本的なアイデアは、移動やサイズ変更の操作を開始するための場所（感応領域）をいくつも用意し、それでオブジェクトを覆うというものです。あるオブジェクトに関する感応領域の全体集合により、オブジェクトのカバー（Coverクラス）が形成されます。カバーのそれぞれの領域は、CoverNodeクラスに属します。オブジェクト上の任意の点で移動できるようにするためには、オブジェクトの全領域が一連のノードで完全に覆われなければなりません。ノード同士が重なり合うことは当然起こり得ますが、それはまったく問題になりません。
Moverクラスのオブジェクトは、登録されたオブジェクト（つまり、Listに含められたオブジェクト）の移動／サイズ変更プロセスの全体を監視します。オブジェクトのカバーはさまざまな方法で構成できます。同じクラスのオブジェクトであっても違ったカバーを持つことができます。重要なのは、オブジェクトがMoverに登録された順序です。なぜなら、移動／サイズ変更の対象となるオブジェクトは、List内のオブジェクトの順序に従って決まるからです。すべてのオブジェクトを移動可能にすると、オブジェクト同士が重なり合う場面が多くなるので、この仕組みは重要です。
