2
視覚的効果の高いアプリケーションの設計

この章では、グラフィカル・ユーザー・インタフェース（GUI）を開発する場合に役立つガイドラインを示します。

項	説明
2.1項「プロセスの理解」	GUIベースのアプリケーション開発プロセスを簡単に説明します（すでにGUIベースのアプリケーションを開発した経験があれば、この項を読み飛ばして、2.1.3項「ユーザー・インタフェースの計画」をお読みください）。
2.2項「効果的なフォームの作成」	フォーム作成で考慮する必要のある視覚的効果について解説します。この項では、最初に基本的なForm Builderの専門用語を概説し、標準を実施する手段としてのオブジェクト・ライブラリの重要性を説明した後、各GUIでフォーム・オブジェクトを使用するためのガイドラインを示します。
2.3項「効果的なレポートの作成」	レポート・オブジェクトの配置および改ページの発生場所の制御方法を理解するために役立ちます。
2.4項「効果的な図表の作成」	データを図形表示する場合の視覚的な考慮事項をいくつか示します。

2.1 プロセスの理解

効果的なGUIの開発プロセスを理解するよりも、そのアプリケーションを使用するユーザーについて理解することが重要です。実際、効果的なアプリケーションを開発するには、そのアプリケーションで実行される作業、作業の実行順序、実行環境、および期待される機能など、ユーザーについて理解する必要があります。

他の多くのアプリケーション開発と同じ方法で行おうとするならば、この方法は、重点を根本的に変更することが必要になるでしょう。アプリケーションの開発では、通常、内側から外側に作成していきます。データソースからコードへ、コードからGUIへと効果的なGUIを開発する場合、これとは逆のプロセスで行わなければなりません。つまり、最初にユーザーと話し合い、次にユーザー特有の業務をサポートするユーザー・インタフェースを設計して、最後にすべての作業を実行する基本となるコード・ベースを作成します。

図2-1 ユーザーを第一に考える

パッケージされた一連の標準やガイドラインを使用して開発しても、ユーザーのニーズを正確に理解して開発するかわりにはなりません。この章は、ユーザーの特定のグループ専用のインタフェースを独自に作成する場合や、ユーザーについての理解を深めるために役立ちます。

2.1.1 ステージとは

図2-2に示すように、GUI開発のプロセスには4段階の主なステージがあります。

図2-2 ユーザー・インタフェース開発のステージ

この項の残りの部分は、これらの各ステージを達成するためのガイドラインです。

• 2.1.2項「ユーザー要件の定義」

• 2.1.3項「ユーザー・インタフェースの計画」

• 2.1.4項「ユーザー・インタフェース要素の作成」

• 2.1.5項「ユーザー・フィードバックの収集」

注意: この章では、GUI開発のあらゆる問題についての対処方法を網羅しているわけではありません。特定のステージでの作業の進め方について詳細を知りたい場合は、図書館またはコンピュータ書籍を扱っている書店で入手できるでしょう。ユーザー要件の定義およびユーザー・フィードバックの収集の情報源としては、『Handbook of Usability Testing』（Jeffrey Rubin著）が特に優れています。

2.1.2 ユーザー要件の定義

GUI開発の最初のステージでは、ユーザーのニーズおよび現在のアプリケーションから作成可能であるものを判断します。このステージを飛ばして次の設計フェーズに移りたいと思われるかもしれませんが、リスクが大きいので注意が必要です。対象となるユーザーおよび実行したい作業について十分理解していないと、効果的なGUIの作成は事実上不可能です。

ユーザー要件を定義するには

• ドキュメンテーションの収集: 関連する方針、プロシージャ・マニュアルおよびシステムに関する既存のドキュメンテーション（電子化されたものまたはハードコピー）は、ユーザーとの話し合いで必要なバックグラウンドを明確な形で示す場合に役立ちます。

• ジョブを処理するユーザーの観察: ユーザーが実行する作業および実行する作業の順序のリストを作成します。

• ユーザーとの話し合い: GUIベースのシステムで求められているものを把握します。話し合いを行う場合、次の点を考慮します。
  • ユーザーが行う作業のみでなく、作業方法も尋ねます。たとえば、1人の事務員が同時に複数の注文を処理する必要があるか、または1つの注文を処理するだけでよいのかを尋ねます。

  • ユーザーが現行のシステム（コンピュータ化されていなくても）に満足しているか、不満があるかを把握します。

  • ユーザーにGUIの構想を尋ねます。その構想をできるだけ詳しく説明してもらいます。

  • ユーザーをよく理解するようにします。ユーザーは、通常、長時間にわたって同じジョブを行っているか、またはさまざまなジョブを次々に行っているかを把握します。アプリケーションを一定の時間に使用するか、またはたまにしか使用しないかも知る必要があります。あまり使用しないアプリケーションの場合、多くのボタン、テキストおよびガイドラインを用意して、作業時間の無駄を削減できます。日常的に使用するアプリケーションの場合、ショートカットやアクセラレータ・キーを用意すれば、操作に慣れているユーザーは作業を速やかに完了できます。

  • ユーザー側で不具合があるかどうか、または考慮する必要のある特定の状況を調べます。たとえば、ユーザーがアプリケーションを使用するときに立って作業をしているかどうかが挙げられます。ユーザーが立って作業している場合、過度のナビゲーションに費やす時間と精神的な余裕はありません。

• さまざまなユーザーのサンプル採取: 1つのカスタマ・サイトでのユーザーからのフィードバックでは、特定の経験に偏ってしまいます。

2.1.3 ユーザー・インタフェースの計画

第2のステージでは、ユーザーのニーズを満たすユーザー・インタフェースをインプリメントする方法を計画して文書にします。次のものが含まれます。

• 遵守する一連の標準を開発し、必要に応じて自分のチームに標準として採用させます。2.1.3.1項「標準の作成」を参照してください。

• プラットフォーム固有の要件および利用環境におけるその他の制限事項を考慮します。2.1.3.2項「移植性の検討」を参照してください。

• 各画面を詳しくマップして、ユーザーのニーズを満たす効果的な表示をするために、どのタイプのインタフェース要素を使用するかを決めます。2.1.3.3項「プロトタイプの作成」を参照してください。

2.1.3.1 標準の作成

一貫性のある一連の開発標準は、あらゆる開発の作業を成功させるために欠かせません。さまざまなGUI要素のレイアウト、使用および動作に関する標準を開発し、実施することで、アプリケーションから独立している部分にも共通のルック&フィールを装備できます。Forms DeveloperおよびReports Developerでは、複数のメカニズムが提供されており、一貫性のある一連の標準を開発できます。

表2-1 標準のメカニズム

メカニズム	説明
オブジェクト・ライブラリ（Form Builder）	オブジェクト・ライブラリは、開発者が作成して開発チーム全体で使用できるようにした一連のオブジェクトおよび標準です。サブクラスで使用すれば、オブジェクト・ライブラリ内のあるオブジェクトに対して加えられた変更内容が、そのオブジェクトが使用されるすべてのアプリケーションに確実に波及するようにできます。オブジェクト・ライブラリとは、使用しているForm Builderアプリケーションの標準化に際して選択されたメカニズムのことです。 Form Builderには、独自のサイト要件に見合うようにカスタマイズできる2つのオブジェクト・ライブラリがあります。 標準オブジェクト・ライブラリ。Windows 95/NT環境用に最適化された標準が含まれています。 Oracleアプリケーション・オブジェクト・ライブラリ。Windows 95/NT、Solarisおよびキャラクタ・モードなどの標準のプラットフォーム間アプリケーションが含まれています。 詳細は、Form Builderのオンライン・ヘルプのトピック「オブジェクト・ライブラリについて」および「サブクラス化について」を参照してください。
オブジェクト・グループ（Form Builder）	オブジェクト・グループは、オブジェクトのグループのコンテナです。関連オブジェクトを他のモジュールにコピーしたり、サブクラスにするためにパッケージ化したいときに、オブジェクト・グループを定義します。 たとえば、複数のタイプのオブジェクトを使用した面会スケジューラを作成するとします。オブジェクトは、日付と面会内容を表示するための、ウィンドウ、キャンバス、ブロックおよび項目と、スケジュールや他の機能のロジックを含むトリガーです。これらのオブジェクトをオブジェクト・グループにパッケージ化すると、単純な操作1つで、他のフォームにすべてのオブジェクトをコピーすることができます。 詳細は、Form Builderのオンライン・ヘルプのトピック「オブジェクト・グループ作成のためのガイドライン」を参照してください。
可視属性（Form Builder）	可視属性は、フォームに設定するフォント、カラーおよびパターンなどのプロパティで、ご使用のアプリケーションのGUIに表示されるメニュー・オブジェクトです。可視属性は、次のプロパティに組み込むことができます。 フォント・プロパティ:フォント名、フォント・サイズ、フォント・スタイル、フォント間隔およびフォントの太さ カラーおよびパターン・プロパティ: フォアグランド・カラー、バックグランド・カラー、塗りパターン、文字モードの論理属性および白黒 詳細は、Form Builderのオンライン・ヘルプのトピック「可視属性作成のためのガイドライン」を参照してください。
テンプレート（Form Builder、Report Builder）	Form Builderでは、テンプレートを作成して、チームの他のメンバーに新しいフォームのデフォルトの出発点を提供できます。テンプレートには、通常、グラフィックス（会社のロゴなど）、プログラム単位、標準のウィンドウのレイアウト、ツールバー、メニューおよび他の共通オブジェクトなどの一般オブジェクトが組み込まれています。 Report Builderでは、独自のテンプレートを作成してレポートの外観を制御できますが、さまざまな事前定義テンプレートを利用することもできます。レポート・ウィザードを使用して、レポートに組み込むオブジェクトを選択した後で、テンプレートを選択してこれらのオブジェクトを配置し、標準のフォーマット属性を適用します。 詳細は、Form BuilderまたはReport Builderのオンライン・ヘルプの索引から「テンプレート」を検索してください。

2.1.3.2 移植性の検討

アプリケーションを複数の環境で利用する場合には、各プラットフォームでのさまざまなGUI要素の作成方法、およびプラットフォーム相互の要素の制限事項を理解しておくことが重要です。たとえば、プラットフォーム間でのフォーマットの制限のために、Windows用に作成した対話形式のボタンが小さくなり、Solarisで表示したときに読みにくくなります。プラットフォーム固有の制限事項とそれらに関連した作業のガイドラインの詳細は、第5章「移植性のあるアプリケーションの設計」を参照してください。ユーザー・インタフェースの大きな制限要素となる文字モードの検討事項についても、同じ章を参照してください。

2.1.3.3 プロトタイプの作成

プロトタイプは、ご使用のアプリケーションを使いやすくするための最も効率的な手段です。最も効果的なプロトタイプは、対話的な開発モデルに従って、ストーリーボードで始まり、十分に機能的なアプリケーションで終了します。プロセスは、次の手順のとおりです。

1. アプリケーションの実際の表示や動作方法についての明確な青写真ができるように、ストーリーボードを下書きします。ストーリーボードとは、画面を枠ごとに描画したもので、複数の画面間の切替えおよび外観が示されます。ユーザー要件を定義したときに指定した作業と各画面を関連付ける方法を記述するストーリーを組み込みます。

   次に、製品発注用のアプリケーションのストーリーボードから3つのパネルの例を示します。

   
   

図2-3 ストーリーボードの例

2. ストーリーボードをユーザーに示します。計画したアプリケーションでユーザーのニーズが対処され、実行方法どおりに作業がサポートされていることを検証します。

3. ストーリーボードをペーパー・プロトタイプに拡張します。ストーリーボードが上位レベルでの作業およびウィンドウ・フローの概略示すのに対して、ペーパー・プロトタイプでは、アプリケーション全体をかなり詳細に図解したものです。ペーパー・プロトタイプでは、通常、計画した各ウィンドウごとに1枚のペーパーがあり、ウィジェットを用いて仕上げ、作業の流れとナビゲーションを示す矢印などが含まれます。

4. ペーパー・プロトタイプをユーザーに示します。ボタンの配置およびサポートされるダイアログのレイアウトなどの詳細を絞り込むことができるように、構成に関する問題の多くは、ストーリーボードのフェーズで識別しなければなりません。ユーザーに対してセッションを指示する場合の助言は、 2.1.5項「ユーザー・フィードバックの収集」を参照してください。

5. ユーザーからのフィードバックに基づき、Forms DeveloperまたはReports Developerを使用して機能的なプロトタイプを作成します。次の項は、プロトタイプに対して適切なオブジェクトを選択するときに役立ちます。
   • 2.2項「効果的なフォームの作成」

   • 2.3項「効果的なレポートの作成」

   • 2.4項「効果的な図表の作成」

6. 機能的なプロトタイプをユーザーに実地で試してもらいます。以前のセッションに関与していないユーザーを含むようにしてください。新規ユーザーがそのアプリケーションを簡単に理解できるかどうかを判断するためです。

7. ユーザー要件に示されたすべての目的が達成されるまで、ステップ5およびステップ6を繰り返します。

2.1.4 ユーザー・インタフェース要素の作成

ユーザー・インタフエースの作成を開始するには、事前に十分な時間をかけて概念モデルを開発しておかなければなりません（つまり、ユーザーおよびユーザーが実行する作業を十分理解し、それらの作業がサポートされるダイアログのフローをスムーズに設計しておく必要があります）。この章では、次の３項が、ユーザー・インタフェース要素を慎重に選択する場合に役立ちます。

• 2.2項「効果的なフォームの作成」

• 2.3項「効果的なレポートの作成」

• 2.4項「効果的な図表の作成」

2.1.5 ユーザー・フィードバックの収集

ペーパー、あるいはForms DeveloperまたはReports Developerで実行されるプロトタイプをすでに開発してある場合は、最初のフェーズで話し合ったユーザーに試験的に実行してもらいます。ユーザー・フィードバックを効果的に収集するには、次のようにします。

• 作業ベースのアプローチを使用して、ユーザー・テストの方法を作成します。

• 広い視野で見るために、少なくとも6種類の基本的なタイプのユーザーを使用します。

• メモ、音声およびビデオによる監視を使用して、ユーザーのアクティビティを記録します。

• プロトタイプのパフォーマンスについてユーザーに質問します。

• 複数の設計者に結果を解釈してもらいます。

注意: ユーザー・インタフェースが適切であれば、開発中のアプリケーションを実際に使用するユーザーのみがコメントを入れることができます。

ユーザーによるプロトタイプのテストが終了し、ユーザーからのフィードバックを収集したら、作成ステージに戻り、フィードバックに従ってユーザー・インタフェースを変更し、変更後にもう一度テストします。要件定義フェーズで定義した目的が達成されるまで、この作業のサイクルを繰り返します。

2.2 効果的なフォームの作成

この項では、Form Builderを使った効果的なGUIの作成方法を説明します。

注意: この項は、欧州中心の観点から記述されています（欧州以外の顧客を対象に開発する場合は、ユーザーの文化的な背景に配慮する必要があります。実際には、ターゲットとなる客層の複数のメンバーに設計内容を見直してもらいます）。

2.2.1 フォームの理解

フォームの特定の検討事項を記述する前に、いくつかの基本的なフォームの概念を簡単に紹介します（Form Builderを使用した経験があれば、2.2.2項「フォーム作成のガイドライン」に進んでください）。これらと他のレポートに関連したトピックの詳細は、Report Builderのオンライン・ヘルプまたはForms Developerクイック・ツアーの「Report Builder」の項、あるいはその両方を参照してください。

2.2.1.1 モジュールとは

Form Builderを使用してアプリケーションを作成する場合、モジュールと呼ばれる個々のアプリケーション・コンポーネントを使用して作業します。Form Builderには、次の4種類のモジュールがあります。

モジュールのタイプ	説明
Formモジュール	オブジェクトおよびコード・ルーチンの収集。フォーム・モジュールで定義できるオブジェクトには、ウィンドウ、テキスト項目（フィールド）、チェックボックス、ボタン、警告、値リストおよびトリガーと呼ばれるPL/SQLコードのブロックがあります。
メニュー・モジュール	メニュー（メイン・メニュー・オブジェクトおよび多数のサブメニュー・オブジェクト）の収集およびメニュー項目のコマンド。
PL/SQLライブラリ・モジュール	ユーザー命名プロシージャ、ファンクションおよびアプリケーション内の他のモジュールからコールできるパッケージの収集。
オブジェクト・ライブラリ・モジュール	アプリケーション開発に使用できるオブジェクトの収集。詳細は、表2-1「標準のメカニズム」を参照してください。

この章では、PL/SQLライブラリ・モジュールの使用方法は記述していません。このトピックの詳細は、Form Builderのオンライン・ヘルプを参照してください。

2.2.1.2 フォーム、ブロック、項目、領域および枠とは

簡単に言うと、フォーム（またはフォーム・モジュール）は、データソースに格納された情報へのアクセスができるアプリケーションです。フォームを参照すると、チェックボックスおよびラジオ・グループなどのインタフェース「項目」が表示され、ユーザーはデータソースと対話形式で情報をやりとりすることができます。これらのインタフェース項目は、「ブロック」と呼ばれるコンテナに属しています。図2-4では、Customer ID、First name、Titleなどのフィールドはすべて同じブロックに属しています。

図2-4 サンプル・フォーム

ブロックには、次の2種類があります。データソースとユーザー間のリンクとして使用される「データ・ブロック」と、データソースとは関係付けられていない「制御ブロック」の2種類があります。各データ・ブロックによって、ユーザーはデータソース内の1つの表にあるデータを表示したりアクセスできます。シングル・レコード・ブロックをブロックとして使用して、1回にデータの1行を表示できますが、マルチ・レコード・ブロックをブロックとして使用すると、一度にデータの多数の行を表示できます。図2-4のすべてのフィールドは、シングル・レコード・ブロックです。

「領域」とは、ブロック内の他のブロックと論理グループのフィールドを区切る四角形または線のことです。図2-4では、「Customer Information」フィールドをAccountsのアイコンから区切る四角形が領域です。

「枠」とは、あるブロック内に特定の項目を配置する事前定義済みの方法です。たとえば、図2-4に示すブロックは、マージンおよびオフセット、項目とプロンプト間の距離などが設定された枠によって配置されています。

2.2.1.3 ウィンドウおよびキャンバスとは

「ウィンドウ」とは、Form Builderアプリケーションを構成するすべての表示可能なオブジェクトが含まれたコンテナです。シングル・フォームには、任意の数のウィンドウを組み込むことができます。通常、最も単純なフォームでも、それに対応付けられたウィンドウが複数あります。次のタイプのウィンドウが使用できます。

ウィンドウのタイプ	説明
コンテナ（MDI）	すべての他のウィンドウが入っています。たいていの場合、ツールバーとメイン・メニューが含まれています。（Windowsの場合のみ）
モードレス	ツールバーおよびメニューのように、ユーザーが他の任意のウィンドウと対話できます。モードレス・ウィンドウは、ユーザーが多数の作業から自由に選択するときに、GUIで最も頻繁に使用されます。
モーダル	ユーザーは現在のウィンドウにしかアクセスできず、そこで変更を確定するか取り消すかする必要があります。ツールバーおよびメニューにはアクセスできません。ユーザーが作業を続行する前に特定の作業を完了しなければならないときに、モーダル・ウィンドウを使用します。

次は、一般的なForm Builderウィンドウの例です。

図2-5 一般的なForm Builderウィンドウ

ほとんどのWindows 95/NT Form Builderウィンドウと同じように、このウィンドウには次のものが含まれます。

• ウィンドウのタイトル

• メニューバーおよびプルダウン・メニュー

• データに対応していないボタンや他のコントロール

• ブロック内のデータ項目

• メッセージ行およびステータス行が含まれたコンソール

「キャンバス」は、インタフェース項目が表示されるバックグラウンド・オブジェクトです。キャンバスには、次の4種類があります。

キャンバスのタイプ	説明
コンテント・キャンバス	表示されるウィンドウのペイン全体を示します（ウィンドウがスクロール可能な場合は、表示されるペインはより大きなものになります）。各ウィンドウには、少なくとも1つのコンテント・キャンバスがあります。
スタック・キャンバス	現行のウィンドウに割り当てられたコンテント・キャンバスの一番上（つまりスタックされている）に表示されます。スタック・キャンバスは、移入されていないフィールドなど、状況によっては不明確になるコンテント・キャンバス内の領域に対して使います。「ビューポート」を使用すれば、スタック・キャンバスの表示範囲を制御できます。
タブ・キヤンバス	1つの動的なキャンバス上で、大量の関連情報をグループ化し、表示できる一連のタブです。
ツールバー・キャンバス	個々のウィンドウにツールバーを作成するために使用します。

各ウィンドウで、1つ以上のキャンバスが表示される場合もあります。特定の条件を満たしていれば、状況によって、ウィンドウ内のキャンバスを表示できます。

2.2.2 フォーム作成のガイドライン

次の項では、Form Builderで効果的なGUIを作成するための特定の推奨事項を示します。

• 2.2.2.1項「オブジェクト・ライブラリの使用」

• 2.2.2.2項「基本的な設計原理の理解」

• 2.2.2.3項「カラーの追加」

• 2.2.2.4項「キャンバスの作成」

• 2.2.2.5項「ウィンドウの作成」

• 2.2.2.6項「領域の作成」

• 2.2.2.7項「ブロックへの項目の追加」

• 2.2.2.8項「メッセージの設計」

• 2.2.2.9項「オンライン・ヘルプのインプリメント」

• 2.2.2.10項「効果的なメニューの作成」

2.2.2.1 オブジェクト・ライブラリの使用

フォームの開発で使用できる最も重要な標準化の手段は、オブジェクト・ライブラリでしょう。オブジェクト・ライブラリは、開発者が作成した一連のオブジェクトおよび標準です。各オブジェクトまたは標準によって、枠、ウィンドウまたは領域の全体の外観とレイアウトが決まります。オブジェクト・ライブラリ内にこれらのオブジェクトを常駐させると、開発プロジェクトまたはサイトのすべての開発者がそのオブジェクトを利用できるようになり、別の場所で作業をしている開発者でも、同じアプリケーションを作成できるようになります（つまり、共通のルック&フィールを使って同じアプリケーション内の別個のモジュールを作成できます）。サブクラスで使用すれば、オブジェクト・ライブラリ内のあるオブジェクトに対して加えられた変更内容が、そのオブジェクトが使用されるすべてのアプリケーションに確実に波及するようにできます。

オブジェクト・ライブラリの使用方針としては、標準の各論理グループに別のオブジェクト・ライブラリを作成するのが効果的です。たとえば、会社の標準に対してオブジェクト・ライブラリを1つ作成して社内で利用できるようにする場合、プロジェクトの特定のニーズ専用にオブジェクト・ライブラリを作成します。

Form Builderでは、専用のオブジェクト・ライブラリの作成を開始するために2種類のサンプルが用意されています。

• 標準オブジェクト・ライブラリ。多言語のサポートが要件に含まれていない場合に、Windows 95専用で利用されるオブジェクトが入ります。

• Oracleアプリケーション・オブジェクト・ライブラリ。マルチ・プラットフォームでの利用にお薦めします。

オブジェクト・ライブラリを作成する前に、標準またはOracleアプリケーション・オブジェクト・ライブラリの内容を調べて、正しく動作するかどうか、または変更の必要があるかどうかをテストするとよいでしょう。

テストの対象	処置
データ・ブロックの標準オブジェクト・ライブラリ内の項目	データ・ブロック・ウィザードを使用してデータ・ブロックを作成します。 制御ブロックまたはデータ・ブロックの項目をクリックしてから、マウスの右ボタンをクリックします。その項目に適用するスマート・クラスのリストが表示されるので、任意のスマート・クラスをクリックします。
制御ブロックの標準オブジェクト・ライブラリ内の項目	STNDRD20.OLBをオープンにします。 ブロック内に項目をドラッグ・アンド・ドロップします。
標準オブジェクト・ライブラリ内の可視属性のみ	STNDRD20.OLBテンプレート・フォームをオープンします。
Oracleアプリケーション・オブジェクト・ライブラリ内のオブジェクト	APPSTDS.OLBテンプレート・フォームをオープンします。

標準オブジェクト・ライブラリを使用する場合、必ずVAGsタブの下にあるすべての属性をフォームの可視属性ノードにサブクラス化します。多数の標準がこれらの可視属性に基づいているため、可視属性を適用しないと正しく表示されません。可視属性をコピーしないでサブクラス化すると、常に確実に最新の定義にアクセスできます。

すべてあるいはほとんどのフォームで、特定の可視属性グループのセットを使用する予定であれば、標準オブジェクト・ライブラリからサブクラス化された可視属性がすでに含まれているテンプレート・フォームを作成します。レイアウト・ウィザードで入力を要求されたときに、このテンプレートに名前を付けることができます。

2.2.2.2 基本的な設計原理の理解

この項では、フォーム作成の一般的なガイドラインをいくつか示します。

• インチ、センチメートルまたはポイントの各測定単位を使った実際の座標システムを使用してください。単位を1つだけ選んで、すべてのモジュールに共通に使用します。

  ポイント	すべての数字を使用してサイズを指定できるので、最も使いやすい単位といえます。テキストは常にポイントで指定するので、オブジェクトがポイント単位で指定されていれば、テキストに関係付けられたオブジェクトのサイズの指定はより簡単です。
  インチおよびセンチメートル	ポイントと比べて高い精度で指定できます（ただし、テキストとオブジェクトのサイズの比較は簡単にはできません）。ターゲット環境の表示がSVGA専用またはそれ以上の精度であれば、効果的です。
  ピクセル	お薦めできません。これを使用するのは、すべてのユーザーが同じ画面と解像度を使用しており、今後もその状態が続くことが確定している場合のみです。
  文字	文字モードのプラットフォームを実行する場合にのみ使用します。

• 必要に応じてダイアログを使用可能または使用禁止にして、ユーザーの作業を制御します。これを判断する場合、ユーザーの作業状況によって、操作を自由にさせるか、または制限するかを考慮し、ユーザーに関する知識に基づいて決定する必要があります。

  例: アプリケーションに割込みを実行し、後で再開するといった単純な作業については、すべてのユーザーが自由に決められるようにする必要があります。ただし、会社が発行する請求書をユーザーが整理し直すことができるようにすると、会社の標準が無視される可能性があるため、望ましくありません。

  ユーザーが制御する範囲は、ユーザーの経験のレベルによっても違ってきます。操作に習熟したユーザーと未経験のユーザーの両方を対象にアプリケーションを開発する場合には、必要に応じて段階的に操作方法の指示が得られるように、マニュアルに即したウィザードを組み込むことを検討してください。

• 作業が終了したら、ウィンドウをクローズする、別のウィンドウをオープンする、情報メッセージを表示する、のうちいずれかが実行されるようにし、作業の終了がユーザーに明白にわかるようにします。

• 必要な大きさのウィンドウを作成します。

• 情報をグループ化するためにブランク領域を使用します。

• 標準オブジェクト・ライブラリ内の枠オブジェクトを使用して、フォーム・モジュール間で一貫性のあるレイアウト・スタイルが適用されるようにします。

• トップダウンの作業順序に基づいて、画面レイアウトの方向を決めます。左から右へ、次に上から下へと使用順序に従って、ブロック、領域および項目を配置します。

• シングル・レコード・ブロックでは、できるだけ項目を左詰めします（右詰めフィールドには、通貨および数値が入ります）。マルチ・レコード・ブロックでは、項目を横方向にスタックして、それらを一番上の行に配置します。

2.2.2.3 カラーの追加

• ユーザーの注意を喚起するために、使用するカラーの種類は控えます。

• カラーに意味を持たせ、一貫して使用します。例: 必須またはオプションと、表示専用フィールドのカラーとの区別を付けてコーディングします。他の各フィールドのカラーを同じ方法でコーディングします。

• 場合によっては、ユーザーがカラーを変更できるようにします。

• 状態または他の情報をやり取りする手段としては、カラーのみに依存しないで、音声または他のハイライトなどの代替方法を常に用意しておいてください。たとえば、否定的なメッセージについてはすべて赤色で表示する場合、カラーが使用されていなくてもメッセージが明確にわかるように、カッコを付けます。また、ユーザーがカラーを識別できない場合を考慮して、メッセージ内の特定のカラーが参照されないようにします。

• オブジェクト・ライブラリまたは可視属性を使用して、カラーの使用方法を標準化します。

• カラーを選択するときは、次のことに注意してください。
  • 赤と青の組合せは、目によくありません。

  • 青の文字は画面上では後退して見えるので、背景から見分けにくくなります。

  • 濃い青色の背景は、他の明るいカラーと同じように、長時間作業すると目によくありません。

  • 色（特に赤と緑）の区別が付けられない人が多数います。

  • カラーの持つ意味は、国によって違います。職業および状況などのニーズに注意し、ターゲット市場における文化的なカラーの区別に従ってコーディングしてください。たとえば、緑は、通常ほとんどの西欧諸国では肯定的なイメージが持たれていますが、化学関係の専門家の間では、緑色は「危険」を意味します。

    カラー	意味
    青	涼しい
    黒	利益（経済的）
    緑	進め、OK、危険（化学関係）
    赤	暑い、止まれ、危険、損失（経済的）
    黄	警告、注意

2.2.2.4 キャンバスの作成

次の表には、キャンバス作成のための推奨事項が示されています。

表2-2 キャンバス作成のための推奨事項

キャンバスのタイプ	推奨事項
一般	項目と領域の間には、十分な空白を入れます。 個々のキャンバスにオプション情報を入れます。 できるだけ、ウィンドウのスクロールは避けてください。調査の結果、ユーザーが作業を完了するためにウィンドウをスクロールしているときに、急激に生産性が低下することが判明しました。 同時に表示する必要のあるキャンバスごとにウィンドウを作成する計画を立てます。 レイアウトが計画どおりにSuper VGAモードのモニターに表示されても、VGAのように解像度の異なるモードでは、レイアウトが画面からはみ出してしまう場合があります。対象となるすべてのユーザーのモニターでレイアウトをテストしてください。
コンテント・キャンバス	コンテント・キャンバスを「即時表示」に設定します。 コンテント・キャンバスの表示サイズは、割り当てられたウィンドウの現行のサイズによって決まることに注意してください。 キャンバス上のオブジェクトの斜体文字修飾の効果を最大にするために、キャンバスを白色以外のカラーにすることを検討してください。また、白色のバックグラウンドは明るすぎて疲れることがよくあります。 ウィンドウごとに1つのコンテント・キャンバスを使用します。複数のコンテント・キャンバスを使用すると、ウィンドウ全体が切り替えられる理由をユーザーが理解していない場合に、混乱を生じます。やむをえず複数のコンテント・キャンバスを使用する場合には、すべてのコンテント・キャンバスを論理的に関係付けて、ユーザーが明示的にキャンバス間を移動できるようにする必要があります。複数のコンテント・キャンバスをインプリメントして成功するのは、ワード・プロセッサのアプリケーションでユーザーが同じ文書で印刷プレビュー、標準およびアウトラインなどの複数の表示を選択する場合です。
スタック・キャンバス	ボイラープレートを含むオブジェクトのグループを表示または非表示にするには、スタック・キャンバスを使用します。 スタック・キャンバスのサイズは、必要な項目を入れるのに十分な大きさに設定してください。 スタック・キャンバスをインプリメントする前に、スタック・キャンバスの動作方法を理解しておいてください。たとえば、スタック・キャンバスによってあいまいになったフィールドをナビゲートするために、ユーザーが「次のフィールド」または「次のレコードへ」を使用する場合、スタック・キャンバスがなくなったように見えます（つまり、自動的にコンテント・キャンバスの下に配置されます）。スタック・キャンバスを再表示させるには、ユーザーはスタック・キャンバス上の項目をナビゲートするか、またはスタック・キャンバスのナビゲートを止めて「Show Canvas」アクションを選択します。
タブ・キャンバス	タブの数は、4〜6に制限します。 1つのオブジェクトに関する関連情報を編成するには、タブを使用します。たとえば、給与、諸手当、職種などの従業員情報は、タブ設定されたダイアログとして動作します。

2.2.2.5 ウィンドウの作成

次の表には、ウィンドウ作成のための推奨事項が示されています。

表2-3 ウィンドウの推奨事項

属性	推奨事項
一般	ウィンドウの端で3Dの陰をつけた線を使用しないでください。 環境からカラー設定を継承します。 ボタンおよびデータ整合のチェックボックス用の線を除いて、ウィンドウのブランクの一番上と一番下の線は残しておいてください。 領域の線およびブロックの境界線を除いて、左端と右端の文字セルの列はブランクのままにしておきます。 モードレス（モーダルではない）ウィンドウを使用すると、スクロールが可能で、他のウィンドウとの間でのマウスのナビゲーションが可能です（標準オブジェクト・ライブラリ内のSTD_DIALOG_WINDOW_MODELESSオブジェクトを使用します）。 他の場所でマウス・ナビゲーションができないようにするには、モーダル・ウィンドウを使用します。また、プロシージャの一部である依存作業用に使用します（標準オブジェクト・ライブラリ内のSTD_DIALOG_WINDOW_MODALオブジェクトを使用します）。
タイトル	「ウィンドウ」メニュー内でアイコン化された名前とエントリが有効になるように、フォームの中の各ウィンドウに一意のタイトルを付けます。
位置	最初にオープンされたときに、各ウィンドウの全体が確実に表示されるようにします。 すべてのウィンドウを移動可能に設定します。 フォームが終了したときのウィンドウの位置を保持します。
スクロールバー	デフォルトでスクロールが不要になるように、ウィンドウを設計します。スクロールは、ユーザーがウィンドウのサイズを変更した場合にのみ認められます。
ツールバー	ツールバーは、コンテナ・ウィンドウ（Windows）またはルート・ウィンドウ（他のすべてのプラットフォーム）にのみ配置します。 マウスで上をなぞったときにのみ各ボタンの真下に表示される、ツールチップ・ヘルプ内のツールバー・ボタンにヒントを実装します(2.2.2.9.1項「ツールチップのインプリメント」を参照)。

2.2.2.5.1 モードレス・ウィンドウのタイトルの選択

標準オブジェクト・ライブラリ内のSTD_DIALOG_WINDOW_MODELESSオブジェクトでは、位置決め、クローズ、サイズ変更および配置に関するすべての問題が対処されますが、ウィンドウには独自のタイトルを選択しなければなりません。選択するには、次のようにします。

• ウィンドウで製品固有の作業を実行する場合は、「Transfer Items」、「Post Journals」および「AutoCreate Quotes」の場合と同じく、<Verb><Noun>という形式を使用します。

• ウィンドウ名は、ウィンドウがデータのシングル・インスタンスに関連している場合を除いて、複数作成します。 つまり、「Item」ではなく「Items」を使います。

• <ウィンドウ名> - <コンテキスト>のフォームで、子ウィンドウにコンテキストを付けます。コンテキストは、一番上のマスター・レコードにするか、または新規レコードの場合は[新規]にします。

  
  例: 	割当て（OR1） - [John Doe]
  
  	製品発注書（ABC） - [新規]
  

2.2.2.6 領域の作成

次の表には、領域作成のための推奨事項が示されています。

表2-4 領域の推奨事項

属性	推奨事項
一般	ユーザーにとって意義がある場合か、または画面を使いやすくする場合を除いて、グループ項目に領域を作成したり、ボイラープレートを追加しないでください。 枠の凹凸を使用して、領域ブロックを囲む線や四角形を作ります。 ブロック全体を含む領域に対しては、枠を使用します。枠には、枠と項目の間の空白（マージン）、間隔および可視属性など、中に含まれる項目のレイアウトを制御するプロパティがあります。標準の枠を使用することで、作成しているウィンドウのレイアウトの一貫性を維持できます（レイアウト・ウィザードで枠を作成しても、オブジェクト・ライブラリ内に格納された枠を適用すればいつでも上書きできます）。
タイトル	情報が書き込まれていなければ、領域にタイトルを追加できます。太字体を使用してください。 四角形または線の一番上にタイトルを位置付けます。タイトル・テキストの先行ブランクと後続ブランクはそのまま残しておきます。 タイトルを表示するには、次のいずれかのウィジェットを使用します。 ボイラープレート（静的な領域のタイトル用）。 枠タイトル（枠用）。 表示項目。 外観はボイラープレートと類似しています（動的な領域のタイトル用）。 ポップリスト（その他の領域用）。 チェックボックス（領域全体が適用可能か、または適用不可かを示す場合）

2.2.2.7 ブロックへの項目の追加

次の表は、ある項目の他に別のフォームの項目を選択する場合に役立ちます。また、標準オブジェクト・ライブラリ内のオブジェクトまたは標準を変更する場合に、使用できるガイドラインを示します。項目は、アルファベット順に示します。

表2-5 項目の推奨事項

項目	使用条件	推奨事項
ボイラープレート・テキスト	プロンプトでもタイトルでもないテキスト。	大文字および小文字を使用します。 イタリックと下線の多用を避けてください。 フォント・スタイルは、一貫して使用してください。たとえば、強調するために太字を使用する場合、他の目的には使用しないようにします。 フォント、サイズおよびカラーのバリエーションを使いすぎないようにしてください。
ボタン（アイコンではない）	ダイアログの応答（モーダル・ウィンドウ）として、項目関連のアクションに使用します。	標準オブジェクト・ライブラリ内の STD_BUTTON_typeオブジェクトのいずれかを使用します。 1つのウィンドウに6個まで使用します。できるだけ1つの行または1つの列に配置します。 ボタンとボタンの間を0.1インチの空白をとって整列します。ボタンの論理グループの間隔を0.5インチに設定します。 一番右のボタンの右端とウィンドウの右端の間隔を0.1インチに設定します。 たとえば、‘Print Invoice’のように、ラベル付けされた語句を大文字にします。 ボタン・ラベルの終わりに省略符号（...）を使用するのは、ボタンによってモーダル・ウィンドウがオープンされるか、またはアクションが完了する前に、ユーザーが別のウィンドウ（モーダルまたはモードレス）でアクションに関する情報をさらに入力するよう求められた場合です。 「OK」ボタンと「取消し」ボタンを一緒に配置します。 最初に肯定と取消しを意味するボタンを押し、最後に独自のボタンを押します。 ダイアログが拡張できることを示す場合には、山形（>>）を使用します。 ラベル付けされたボタン（「OK」および「取消し」を除く）には、必ずアクセラレータ・キー（下線が引かれた文字）を用意します。 ラベルの最初または2番目の語の最初の文字を使用します（「File」の場合は「F」、「Start Posting」では「P」）。それよりも強いリンクがある場合（「Exit」の「X」など）は、その文字を使用します。 できるだけ、母音ではなく子音を使用します。 ウィンドウ内のアクセス・キーは一意にします。その場合、メニューの最上位レベルで使用されるキーと競合しないようにしてください。
チェックボックス	チェックボックス上のラベルが「TRUE」（チェックあり）および「FALSE」（チェックなし）のいずれかの状態として想定できる場合にのみ使用します。それ以外の場合は、2つの項目の付いたラジオ・ボタンを使用します。	標準オブジェクト・ライブラリ内のSTD_CHECKBOXオブジェクトを使用します。 肯定的な文のラベルを使用します。 悪い例: 今後はこの警告が表示されません。 よい例: 今後はこの警告が表示されます。
表示項目	ユーザーが入力しない表示専用のフィールドに使用します。たとえば、財務系のアプリケーションの「合計」フィールドがこれに当たります。	標準オブジェクト・ライブラリ内のSTD_DISPLAY_ITEMオブジェクトを使用します。
アイコン	頻繁に使用されるアクションまたは重要なアクションのみに使用します。 作業または実社会の擬似オブジェクトを表すわかりやすい絵を使用します。	ツールバーに頻繁に使用するボタンを配置します。 関連したツールをグループ化し、他のグループとの間に空白を設けて区分けします。 利用できないボタンを使用禁止にします。 ユーザーがアイコンの意味を取り違えることが多いので、常にツールチップが利用できるように装備します。 アイコンは文化によって意味が異なります。ときには、アイコンを使用するユーザーがわかるように、別のものに置き換えて訳す必要があることに注意してください。 「Run」を示すのに、走っている人の絵を使用するなど、視覚的な語呂合わせはしないでください。アイコンの意味がわかりにくくなる上に、他国の言語では意味が通じません。
リスト（ポップリストおよびT listも参照）	ユーザーにとって、値を入力するよりも選択した方が早い場合に使用します。 選択できるリスト形式でデータ・エントリおよびテキスト値の表示に使用します。 表示された値エントリが比較的短い（各エントリにつき30文字まで）場合に使用します。 ユーザーが新規の値を入力する可能性がある場合には、コンボ・ボックス・スタイルを使用します。	エントリが15以下の場合は、ポップリストを使用します。エントリが15以上である場合、LOV（値リスト）を使用します。実際の資産が多数ある30以上のエントリには、T listを使用します。 関連したすべてのフィールドを同じ長さにします。 入力できないように設定されたテキスト項目には、キャンバスのバックグラウンドと同じカラーを使用します。
値リスト	ユーザーが15以上の行からなるリストから選択する、またはデータの複数の列を表示する必要がある場合に使用します。	値が1つしかないときに、ユーザーに対して1行が自動的に選択されます。 選択後、カーソルが次のフィールドに自動的に移動するようにします。 値リストに100以上の行がある場合、選択する前に、ユーザーに対して有効な値のリストを減らすように求めます。
ポップリスト	適用できる値が1つしかなく、リストの選択肢が15以下である場合に使用します。	ポップリストをインプリメントする前に、頻繁に利用するユーザーがリストから選択するよりも、直接入力した方が速いかどうかを考えます。
ポップアップ・メニュー	メニュー・オプションを、アプリケーション全体ではなく項目に関連付ける場合に使用します。 頻繁に使用するコマンドへのアクセスを提供する場合に使用します。	標準オブジェクト・ライブラリ内のSTD_POPUP_MENU_ITEMオブジェクトを使用します。
プロンプト	フィールド、チェックボックス、リストなどのラベルとして使用します。	記述する要素の一番上または左に位置付けます。 常に、シングル・レコード・ブロックのプロンプトはフィールドの左側に、マルチ・レコード・ブロックのプロンプトはフィールドの上側に位置付けます。 ある範囲のフィールドを指定するには、「から」および「まで」を使い、「開始」および「終了」、または「低」および「高」は使用しないでください。 パーセンテージを示す場合は、フィールドの後ろ側にパーセント記号（%）を付けます。プロンプトの中には、パーセント記号を入れないでください。
ラジオ・グループ	相互に排他的な選択を示す場合に使用します。 表示される情報のタイプなど、「モード」を設定する場合に使用します。	標準オブジェクト・ライブラリ内のSTD_RADIO_GROUPオブジェクトを使用します。 横方向ではなく、縦方向に使用します。 関連するボタンをラジオ・グループに入れて、タイトルを付けます。 選択肢が二者択一（ON/OFF、 YES/NO）の場合は、かわりにチェックボックスを使用します。 常にデフォルト値を表示します。
T List	適用できる値が1つしかなく、リストの選択肢が30を超えない場合に使用します。	常に、データの5行以上を表示します。 使用可能な実際の資産が多数あるフォームの中でのみ使用します。
テキスト項目	データ・エントリおよび文字値の表示用に使用します。 長い値、または実装されていない値（つまり、短い事前定義済みのリストにはない）に使用します。	入力できないように設定されたテキスト項目には、キャンバスのバックグラウンドと同じカラーを使用します。 ユーザーがフィールドに値を入力できる場合は、斜体を使用します。 標準オブジェクト・ライブラリ内のSTD_TEXT_ITEMまたはSTD_DATE_type オブジェクトのいずれかを使います。

2.2.2.8 メッセージの設計

メッセージは、ウィンドウのコンソール領域内または「警告」と呼ばれるポップアップ・ウィンドウ内に表示されます。メッセージの表示方法は、メッセージのタイプおよびユーザーから応答を求められるかどうかによって異なります。次に提案事項を説明します。

表2-6 メッセージの表示

メッセージのタイプ	推奨事項	例
エラー	エラー・メッセージを表示するには、標準オブジェクト・ライブラリ内の「Alerts」タブの下にあるSTD_ALERT_STOPオブジェクトを使用します。 エラーによって処理が中断する恐れがある場合に使用します。ダイアログ内に停止を示すアイコンを組み込みます。 なるべく使用を控えてください。	「この命令を承認する権限がありません」
警告	標準オブジェクト・ライブラリ内の「Alerts」タブの下にあるSTD_ALERT_CAUTION_1、 STD_ALERT_CAUTION_2、またはSTD_ALERT_CAUTION_3オブジェクトを使用します。メッセージ・テキストの説明を参照するには、ライブラリ内で該当するオブジェクトを1回クリックします。 処理を続行する前にユーザーの応答が必要な質問を提示するときに使用します。ダイアログで優先させる記号のアイコン（!）を組み込みます。 警告は短く簡潔にします。たとえば、「本当にこの命令を削除しますか?」というメッセージではなく、「この命令を削除しますか?」を使用します。 肯定的な表現で質問をしてください（「変更を保存しますか?」を使用して、「本当に変更内容を保存したくありませんか?」とはしないでください）。	「この請求書のすべての行をコピーしますか？」
情報	標準オブジェクト・ライブラリ内のSTD_ALERT_INFORMATIONオブジェクトを使用します。 選択が必要な箇所で何も選択されてないときに、ユーザーの注意を喚起するメッセージを提示するために使用します。情報アイコン（円の中に「i」の文字が表示される）と「OK」ボタンを組み込みます。	「現時点で、製品数と出荷数が合いません。」 「応答待ちをしている項目があります。」
ヒント	コンソール内のForm Builderのメッセージ行に表示されます。 かなり短いメッセージ、または応答する必要のないプロセス・インジケータを提示するために使用します。	「作業中...」 「最初のレコードで」 「処理命令12行/37行」

2.2.2.8.1 メッセージ・テキストの作成

できれば、エラー・メッセージも組み込みます。

• 行われた操作

• 原因（エラーになった理由）

• アクション（解決方法）

次に、メッセージ・テキストのよい例と悪い例を示します。

悪い例	よい例
日付が無効です。	「日付をDD-MON-YYとして入力し直してください。」
終了日付よりも後の日付を開始日付に入力しないでください。	「開始日付は、終了日付より前の日付に設定してください。」
エラー: 1623、制約違反です。	「このフィールドに一意の値を入力し直してください。」
このメッセージは受信しないでください。	このメッセージは表示しないでください。
誤ってツールが紛失しています。	適切なメッセージに置き換えるか、またはこのメッセージ自体を削除します。

メッセージ・テキストを書くときには、これらのガイドラインを遵守してください。

推奨事項	例
能動態を使用します。	「これが行われる必要があります」という表現は避けて、「ただちにこれを行ってください」にしてください。
命令法を使用します。	「コミッション計画を入力できます」ではなく、「コミッション計画を入力してください」とします。
「することがあります」または「〜できるでしょう」のような類推表現ではなく、「〜できます」を使用します。	「印刷されたリリースは削除できないことがあります」ではなく、「印刷されたリリースは削除できません」とします。
できるだけ、実際のフィールド名に任せます。	フィールドのラベルが「販売組合員」である場合、「異なる販売員名を入力してください」というメッセージは使用しないでください。
コマンドおよびキーワードには、大文字を使用してください。	ALTER CLUSTER文はサポートされていません。
ユーモアは使用しないでください。	しくじりました!
非難めいたメッセージを避けてください。ユーザー側に間違いがあったことを遠回しに言うような表現は使用しないようにします。問題の解決に関係がない場合には、ユーザーの間違いを指摘しないでください。	「値が選択されていません」ではなく、「値を選択してください」という表現を心がけてください。
指示が含まれたメッセージの場合は、「〜してください」などの丁寧語を使用します。	「値を選択しなさい」よりも、「値を選択してください」という表現を選びます。
ユーザーに対しては、「ユーザー」ではなく、「あなた」という呼び方をします。「わたし」、「彼」または「彼女」という呼称は使用しないでください。	「ユーザーは、モジュールをバックアップする必要があります」ではなく、「モジュールをバックアップしてください」という表現を心がけます。
エラーが発生したときに、状況判断ヘルプが利用できるように設定してください。	2.2.2.9.2項「オンライン・ヘルプのインプリメント」を参照してください。

2.2.2.9 オンライン・ヘルプのインプリメント

この項では、2種類のオンライン・ヘルプの使用方法を説明します。

ツールチップ	ポップアップ・ヒントは、またはミクロヘルプとも呼ばれています。ユーザーがマウスを動かして画面上の項目の上に移ったときに表示されます。
オンライン・ヘルプ	状況判断ヘルプと、ユーザーが関連項目にジャンプできるハイパーテキスト・リンクが含まれます。

2.2.2.9.1 ツールチップのインプリメント

項目には、「ツールチップ」と呼ばれるプロパティと「ツールチップ可視属性グループ」と呼ばれるものがあります。プロパティ・パレットの「ツールチップ」プロパティ・フィールドには、ポップアップで表示したいテキストを入力します。アプリケーション全体に一貫性を持たせるには、標準オブジェクト・ライブラリからSTD_TOOLTIP可視属性を適用します。可視属性を適用しない場合は、ツールチップにはプラットフォーム固有のデフォルトが使用されます。

2.2.2.9.2 オンライン・ヘルプのインプリメント

• ヘルプ・オーサリング・ツールを使用することを検討してください。

• 他のトピックにハイパーリンクされたスタンドアロン・トピックを作成します。

• テキストは短く簡潔にしてください。

• 各ダイアログに「ヘルプ」ボタン、メイン・メニューには「ヘルプ」オプション、ツールバーには「ヘルプ」ボタンをそれぞれ装備します。

2.2.2.10 効果的なメニューの作成

Form Builderでは、各フォームにデフォルト・メニューが用意されています。デフォルト・メニューには、問合せ、挿入および削除を含むすべての基本的なデータベース操作のコマンドが含まれています。アプリケーション固有の要件がデフォルト・メニューと合致しない場合、カスタム・メニューを手軽に作成できます（詳細は、Form Builderのオンライン・ヘルプの「メニューの作成」を参照してください）。メニューを作成するときは、次のことに注意してください。

• コマンドが属している作業に従って、コマンドを編成します。

• Forms Developerではスクロールできるメニューバーがサポートされていますが、ユーザーに見えるように、画面上に有効な項目をすべて表示するよう注意してください。

• 利用できない項目は使用禁止にします。

• サブメニューをできるだけ2つのレベルに制限します。

• ラベルを大文字にします。

2.3 効果的なレポートの作成

Report Builderを使用して効果的なレポートを作成する場合、最初のステップは、効果的なフォームまたは図表を設計する場合と同じです。この項の残りの部分に進む前に、まだお読みでなければ、2.1.2項「ユーザー要件の定義」をお読みください。

次に、作成するレポートのためのユーザー要件を決定する場合に役立つ問題点をいくつか示します。

• ユーザーがレポートでどんなデータを参照したいですか、参照するデータの優先順位をどうしますか?

• ユーザーが詳細を参照するためにデータで「ドリルダウン」することを希望していますか?希望する場合には、該当するボタンをレポートに組み込みます。各ボタンには対応したPL/SQLコードのブロックがあり、2次的なレポートを起動し、ビデオや音声などを出力できます。

• ユーザーが、レポートでデータをチャートの形で表示することを希望していますか?希望する場合、どんな種類のデータですか? Graphics Builderを使用してチャートを作成すれば、（2次的な問合せを実行しなくても）Report Builderからチャートにデータを渡すことができます。

• ユーザーがフォーム・アプリケーションを使用してデータを変更する場合、後にデータを印刷することを希望していますか?希望する場合は、フォームからレポートをコールし、データをレポートに渡します。

• ユーザーがフォームへのレポートの埋込みを希望していますか?希望する場合は、フォントおよびカラーの標準がフォームと同じテンプレートを設計します。

• ユーザーがレポートをHTML、PDFまたはハードコピーで表示することを希望していますか?（任意で）印刷する前に、ライブ・プレビューアでフォーマットを変更する必要がなるべくないようにしますか?希望する場合は、レポートの宛先パラメータ （DESTYPE）を指定するか、またはユーザーが同様の操作をできるようにする必要があります。

• 「ユーザーID SCOTTに対して、売り上げランキングの上位10位までを表示」のように、ユーザーがレポートのパラメータを指定しますか?指定する場合は、ユーザー・パラメータを作成し、フォームまたは「ランタイム・パラメータ・フォーム」内でユーザーに値を指定させるようにする必要があります。

• ネットワーク・トラフィックおよびマシンのパフォーマンスに基づいて、レポートをクライアント/サーバーまたは３層アーキテクチャで実行しますか?

• レポートを波及させたい会社の標準がありますか?ある場合は、標準のテンプレートを定義する必要があります。

• Webレポートの場合、いくつかのレポートを静的にしますか、またはWebサイトを動的に生成しますか?

2.3.1 レポートの理解

レポートの特定の検討事項を記述する前に、いくつかの基本的なレポートの概念を簡単に紹介します（Report Builderを使った事のある場合は、このセクションをとばしてください）。これらと他のレポートに関連したトピックの詳細は、Report Builderのオンライン・ヘルプまたはReports Developerクイック・ツアーの「Report Builder」の項、あるいはその両方を参照してください。

レポートを作成するときは、次の2つのアプリケーション・コンポーネントを使用して作業を行います。

モジュールのタイプ	説明
レポート・モジュール	オブジェクトおよびコード・ルーチンの収集。レポート・モジュールに定義できるオブジェクトには、繰返し枠、枠、フィールド、ボイラープレート、アンカーおよびトリガーと呼ばれるPL/SQLコードのブロックがあります。
PL/SQLライブラリ・モジュール	ユーザー命名プロシージャ、ファンクションおよびアプリケーション内の他のモジュールからコールできるパッケージの収集。

この項では、PL/SQLライブラリの使用方法は扱っていません。このトピックの詳細は、Report Builderのオンライン・ヘルプを参照してください。

レポートによっては、レポート・ウィザード（レポートのタイプを選択し、データ・モデルおよびデータのレイアウトを定義する）や、レポート・エディタのライブ・プレビューア（レポートの詳細をチューニングする）を使用します。他のレポートでは、レポート・エディタの他のビューを使用します。

表示	使用目的
データ・モデル・ビュー	2つ以上の問合せを使用してレポートを作成する。
レイアウト・モデル・ビュー	複数のセクションを使用してレポートを作成する（たとえば、表およびマトリックスのスタイルを使った1つのレポート）。 新規のレイアウト・オブジェクトを追加する（たとえば、ボタンなど）。 オブジェクトのサイズ設定または位置付けの方法を制御する。
パラメータ・フォーム・ビュー	ユーザーがレポートを実行する前にパラメータの値を指定できるダイアログを提示する。

この章では、視覚的効果の高いアプリケーションを作成する方法を説明するため、この項の残りの部分では、レイアウト・モデル・ビューで見られるテンプレート、オブジェクトおよび設定の使用方法を中心に説明します。

2.3.2 Report Builderでのテンプレートの使用

レポートの開発で使用できる最も重要な標準化の手段は、「テンプレート」でしょう。テンプレートは、レポート全体の外観を決めるボイラープレートおよびレイアウト設定の集合です。Report Builderにはいくつかのテンプレートが実装されていますが、独自のテンプレートを作成することもできます。会社またはグループのテンプレートを作成して、開発チーム全体でそれらを利用すれば、共通のルック&フィールを実現できます。テンプレートの作成方法の手順は、Report Builderのオンライン・ヘルプを参照してください。

2.3.3 レイアウト・オブジェクトの理解

レポート・エディタのレイアウト・ビューには、次のオブジェクトが含まれる場合があります。

オブジェクト	説明
枠	繰返し枠、フィールド、ボイラープレート、ボタンおよび子枠を制御するコンテナ。Form Builderの枠とは違って、Report Builderの枠には、子オブジェクトの位置を制御するフォーマットのプロパティがありません。
繰返し枠	次のものを制御するコンテナ。 レポート・データを入れるフィールド 繰返し枠に所有される他のオブジェクト
フィールド	レポートのデータ、日付、ページ番号などを表示するコンテナ。
ボイラープレート	オブジェクトを囲い込んでいるもの（レポート、枠または繰返し枠）、またはオブジェクトに連結されているものから要求されるたびに表示されるテキストまたはグラフィックス。
アンカー	レポート・レイアウト内の2つのオブジェクトを互いに関連付ける方法を判断するオブジェクト（つまり、親/子の関連および相対的な位置付けをされているオブジェクト）。
ボタン	ユーザーがクリックするたびにアクションが実行されるオブジェクト。

アンカーを除き、レイアウト・オブジェクトには、オブジェクトがアクティブにされるたびに起動するPL/SQLブロックのようなフォーマット・トリガーを持つ場合があります。

2.3.4 Report Builderでのレイアウト・オブジェクトの制御

レポートを設計するときには、レポート全体のサイズとその中に含まれる個々のオブジェクトのサイズがそれぞれ異なるために、印刷されたレポートのページ区切りに影響が出る場合があるので注意してください。次の問合せに基づいて作成されたレポートを検討します。

select ename, sal from emp
where sal > 2000

このレポートのサイズは、複数の要素を基にして設定されています。

• 問合せの条件を満たすデータの量。少数のレコードから数百、数千の範囲に及ぶことがあります。

• レポートを実行するとき。たとえば、昇給後の週に動的に変更された可能性のあるレコード数の配分（たとえば、給与が2000ドルを超えている人の数が増える可能性があります）。

• レポートからデータまたはオブジェクトを除外するグループ・フィルタまたはフォーマット・トリガーを使用するかどうか。

同じオブジェクトのインスタンスでも、サイズが異なる場合があります。たとえば、COMMENTSというデータベース内にVARCHAR2列があるとします。COMMENTSでは、1つのレコードに2つの文が含まれる場合があります。あるいは、10個の文が含まれることもあるでしょう。COMMENTS列に対応するレイアウト内のフィールドは、長さの異なる値を入れられるようにサイズ設定する必要があります。また、そのフィールドの周りにあるオブジェクトは、上書きされたり、レポート内に大きなギャップが生じないように、「プッシュ」または「プル」される必要があるでしょう。

Report Builderでは、レポート・エディタのレイアウト・ビューのさまざまなメカニズムによって、オブジェクトのサイズ設定および位置付けの方法を制御できます。これらのメカニズムの詳細は、次の項で説明します。

• 2.3.4.1項「アンカーの使用」

• 2.3.4.2項「「印刷オブジェクト・オン」プロパティおよび「基本印刷オン」プロパティの使用」

• 2.3.4.3項「水平拡張度および垂直拡張度の理解」

• 2.3.4.4項「「前で改ページ」プロパティおよび「後で改ページ」の使用」

• 2.3.4.5項「「ページ保護」プロパティの使用」

• 2.3.4.6項「「アンカー・オブジェクトと連動」プロパティの使用」

2.3.4.1 アンカーの使用

アンカーは、レポート・レイアウト内のオブジェクトを相互に関連付ける方法です。2つのオブジェクトをアンカーすると、一方のオブジェクトが親、他方のオブジェクトが子と見なされます。オブジェクト間で親子の関連を定義すると、アンカーによってレポート内のオブジェクトの階層が確立されます。Report Builderでは、このようなオブジェクトの階層に基づいて、相互に関連したオブジェクトの印刷方法、2つのオブジェクトを同じページに収めるかどうか、周囲のオブジェクトのサイズによってオブジェクトをプッシュまたはプルする方法が決定されます。

アンカーは、次の2通りの方法で作成できます。

• Report Builderで自動的に作成。これは、暗黙のアンカーと呼ばれます。ほとんどの場合、暗黙のアンカーのみです。

• レポート・エディタのレイアウト・ビューのアンカー・ツールを使用して、独自に作成。これは、明示的なアンカーと呼ばれます。明示的なアンカーは、何らかの理由で暗黙のアンカーを上書きする必要がある場合にのみ使用します。Report Builderのオンライン・ヘルプの「アンカーについて」を参照してください。

2.3.4.2 「印刷オブジェクト・オン」プロパティおよび「基本印刷オン」プロパティの使用

「印刷オブジェクト・オン」プロパティでは、レポートに表示されるオブジェクトの頻度が決定されます。「基本印刷オン」プロパティでは、「印刷オブジェクト・オン」プロパティを基盤とするオブジェクトを指定します。

たとえば、全ページの「印刷オブジェクト・オン」および「アンカー・オブジェクト」の「基本印刷オン」を指定すると、オブジェクトは、アンカーしているオブジェクト（親オブジェクト）が表示されるすべての論理ページに印刷されるようにトリガーされます。レポート・ウィザードによって作成されたオブジェクトには、それぞれ専用に設定されたプロパティがあります。ほとんどの場合、Report Builderで選択される値は、そのオブジェクトに最適の値です。これらのプロパティを独自に設定する必要があるのは、Report Builderで設定されたデフォルト値を上書きしたい場合のみです。

「印刷オブジェクト・オン」プロパティを適用すると、Report Builderでは、オブジェクトの一部が印刷されている最初の論理ページがオブジェクトの第1ページとなるように配慮されます。同様に、最終ページは、オブジェクトの一部が印刷されている最後の論理ページになるように配慮されます。たとえば、「第1ページ」の「印刷オブジェクト・オン」と、「インクローズ・オブジェクト」の「基本印刷オン」を指定すると、その囲みオブジェクトが表示される最初の論理ページにオブジェクトが印刷されるようにトリガーされます。

注意:

• オブジェクトが繰返し枠内にある場合、「基本印刷オン」によって繰返し枠の各インスタンスが参照されます。オブジェクトが繰返し枠の外側にあり、明示的に繰返し枠にアンカーされている場合は、「基本印刷オン」によって繰返し枠全体が参照されます。

• オブジェクトが論理ページに印刷されるようにトリガーされていても、論理ページにそのオブジェクトが印刷されるとは限りません。他の設定（たとえば、「前で改ページ」）や、ページで使用可能なスペースの量によって、Report Builderでは、最初に印刷するようにトリガーされたページ以外のページにオブジェクトが印刷される場合があります。

詳細は、Report Builderのオンライン・ヘルプで、索引項目の「水平拡張度」および「垂直拡張度」を参照してください。

2.3.4.3 水平拡張度および垂直拡張度の理解

水平拡張度および垂直拡張度の各プロパティでは、複数のオブジェクトまたはデータを収めるオブジェクトの水平サイズと垂直サイズを実行時に変更する方法を指定します。

• 枠および繰返し枠の場合、中に含まれるオブジェクトによって枠または繰返し枠のサイズを変えるかどうかを拡張度によって定義します。

• テキストを含むオブジェクトの場合、中に含まれたテキストのサイズによってフィールドまたはボイラープレートのサイズを変えるかどうかを拡張度によって定義します。サイズが固定しているテキストは、サイズが定義されたオブジェクト内でラップされ、空間的な余裕がない場合は切り捨てられます。数値または日付データでは、データが定義されたサイズ内に収まらない場合は、アスタリスクとして表示されます。

• イメージ、描画およびチャート・オブジェクトの場合、Report Builderでは、比例したスケール変更が行われます。イメージ、描画およびチャート・オブジェクトの拡張度オプションによってスケール変更係数が決まります。

レポート・ウィザードによって作成されたオブジェクトには、それぞれ専用に設定されたプロパティがあります。ほとんどの場合、Report Builderで選択される値は、そのオブジェクトに最適の値です。これらのプロパティを独自に設定する必要があるのは、Report Builderで設定されたデフォルト値を上書きしたい場合のみです。

拡張度の設定を変えると、出力が予期しない結果になることがあります。たとえば、水平拡張度を可変として設定したオブジェクトを縮小すると、右揃えされたすべてのオブジェクトは、可変オブジェクトに暗黙にアンカーされているため、左側に移動してしまいます。

詳細は、Report Builderのオンライン・ヘルプで、「水平拡張度」および「垂直拡張度」を参照してください。

2.3.4.4 「前で改ページ」プロパティおよび「後で改ページ」の使用

ワード・プロセッサで処理された文書とは違って、レポートとそれに含まれるオブジェクトは、実行時のサイズおよび位置が異なります。結果として、あるレポートの改ページは、予想しにくくなります。

• 最初に印刷するようにトリガーされたページの後のページにオブジェクトをフォーマットしたい場合には、「前で改ページ」プロパティを使用します。ただし、「前で改ページ」に設定されたオブジェクトの下のすべてのオブジェクトが次のページに移動するとは限らないので注意してください。下にあるオブジェクトのいずれかが「前で改ページ」に設定されておらず、ページ内に収まる場合は、「前で改ページ」に設定されているオブジェクトの上に印刷されることがあります。

• オブジェクトのすべての子を次のページに移動させたい場合には、「後で改ページ」プロパティを使用します。言い換えると、このオブジェクトに（暗黙または明示的に）アンカーされているあらゆる子オブジェクトは、「前で改ページ」に設定されているものと見なされます。ただし、「後で改ページ」に設定されたオブジェクトの下のすべてのオブジェクトが次のページに移動するとは限らないので注意してください。下にあるオブジェクトのいずれかが「後で改ページ」に設定されておらず、他のオブジェクトの子でもない場合は、「後で改ページ」に設定されているオブジェクトの上に印刷されることがあります。

詳細は、Report Builderのオンライン・ヘルプで、索引項目の「前で改ページ」および「後で改ページ」を参照してください。

2.3.4.5 「ページ保護」プロパティの使用

オブジェクト全体とその内容を同じ論理ページに収めるには、「ページ保護」プロパティを使用します。オブジェクトの内容がページに収まらない場合は、次の論理ページに移されます。ただし、「ページ保護」に設定されたオブジェクトの下のすべてのオブジェクトが次のページに移動するとは限らないので注意してください。下にあるオブジェクトのいずれかがページに収まる場合は、「ページ保護」に設定されているオブジェクトの上に印刷されることがあります。

詳細は、Report Builderのオンライン・ヘルプで、索引項目の「ページ保護」を参照してください。

2.3.4.6 「アンカー・オブジェクトと連動」プロパティの使用

あるオブジェクトと同じ論理ページにアンカーされているオブジェクトを連動させるには、「アンカー・オブジェクトと連動」プロパティを使用します。オブジェクトまたはそれがアンカーしているオブジェクト、あるいはその両方が同じ論理ページに収まらない場合は、次の論理ページに移されます。

繰返し枠に対して「アンカー・オブジェクトと連動」を設定する場合は、繰返し枠の最初のインスタンスがアンカーされているオブジェクトと同じ論理ページに収められなければなりません。そうでないと、「アンカー・オブジェクトと連動」の条件を満たせません。繰返し枠以外の任意のレイアウト・オブジェクトに対して「アンカー・オブジェクトと連動」を「はい」に設定すると、アンカーしているオブジェクトと同じページにオブジェクト全体をフォーマットできます。

2つのオブジェクト間のアンカーは、明示的または暗黙のいずれかになります。したがって、「アンカー・オブジェクトと連動」を設定すると、2つのオブジェクト間にアンカーを明示的に作成した場合と同じ効果が得られます。

2.4 効果的な図表の作成

Graphics Builderを使用すると、フォームおよびレポートの両方に組み込む図表を作成できます。図表は、それ自体で1つのアプリケーションとすることもできますが、フォームやレポートに組み込むこともできます。

次の場合に、図表を使用できます。

• 異なるカテゴリ間の関連を表示する場合（たとえば、テニス・シューズの販売数を婦人靴の販売数と比較する場合）

• 特定の値ではなく、傾向を示す場合

• ユーザーと、図形の領域および形状（マップおよびイメージのセクターなど）との対話を可能にする場合。Graphics Builderでは、レイアウト・エディタで作成した形状をマウスを使用して加工できます。不規則で透明なボタンは、ユーザーが効果的に絵を選択できるようにするため、ダイアグラムまたはビットマップ・イメージの領域の上に配置できます。

グラフィックスを作成するときには、次のガイドラインに従ってください。

• 簡潔に作成します。図表に入れる線、バー、スライスなどが多すぎると、ユーザーが圧倒されて、作成したグラフやチャートが使用されなくなります。大量のデータがある場合は、最上位レベルでデータを要約し、ドリルダウンを使用して、より詳細な情報を表示するようにします。あるいは、複雑なグラフをもっと小さい個々のグラフに分けてから、ユーザーが表示したいグラフを選択してフォームを作成できるように検討します。

• 3-D効果は、リソースを集約できるなど、情報をやり取りするのに便利な場合にのみ使用します。

• 作成したグラフィックスを利用環境内のすべての表示デバイスでテストし、解像度の最も低いモニターでも問題なく実行されることを確認します。

• 移行を示すにはカラーを、違いを示すには主要なカラーを使用します。カラーの使用の詳細は、2.2.2.3項「カラーの追加」を参照してください。

• 複雑なグラフには、凡例を使用します。

• フォームからグラフィックス・モジュールにマウス・イベントを渡せることに注意してください。たとえば、フォームのチャート項目に「When-Mouse-Click」トリガーを作成し、このトリガーからOG.MouseDownプロシージャをコールして、マウス情報を図表に渡せます。その後、図表からフォームへ、ユーザーがクリックした図表のセクターの詳細を含む情報が戻されます。

2.4.1 望ましいグラフの選択

次の表は、最もよく使用される図表をインプリメントするためのガイドラインです。

表2-7 図表の推奨事項

図表のタイプ	使用条件	推奨事項
棒グラフ	個別のオブジェクトと関連した値との間の関連を示す場合。	バーは20〜25本に制限します。
円グラフ	部分と全体の関連を示す場合。通常、パーセンテージの値を示すために使用されます。	スライスは10個までに制限します。
折れ線グラフ	連続したデータの累積効果を示す場合。	線は6〜8種類に制限します。
ダブル-Y軸グラフ	広い範囲に分布する値の中でデータを比較する場合。	プロットは4以下に制限します。
ガント・チヤート	期間データをスケジュールする場合。	バーは40〜50本に制限します。
株価チャート	毎日の平均値、株価市場の値、高値、安値および現行値を追跡するデータを表示する場合。	行は30行以下に制限します。
複合グラフ	実際の値（バー）と予測値（折れ線）を比較する場合。	行は30行以下に制限します。
散布図	X軸とY軸上の数値データの関連を示す場合。	行は、1インチ当り50行未満に制限します。