桐の釣魚大全のトップ > INF_Framework の話をしよう　―　Designing the User Interface
トップページに戻る

鋭意校正中です。
念のためにブラウザでＦ５キーを押してリロードしてからお読みください。

この小論は、【多遊】さんの［DOWN LOAD BBS］に掲載した内容を一部修正したものです　2024/09/13 〜 2024/10/01

　◇　◇　◇　◇　◇　◇　◇

INF_Framework の話をしよう　―　Designing the User Interface

ベン・シュナイダーマンの著書の

　Designing the User Interface: Strategies for Effective Human - Computer Interaction,
　※ユーザー インターフェイスの設計: 効果的な人間とコンピューターの対話のための戦略

　Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human ― Computer Interaction,
　1st edition. Addison-Wesley, 1986;
　2nd ed. 1992;
　3rd ed. 1998;
　4th ed. 2005;
　5th ed. 2010;
　6th ed. 2016

↑は、ユーザインタフェースに関するベストセラーです。

1986年の初版から、コンピュータの日進月歩に合わせて、第６版まで改訂され続けたスゴイ書籍です。

日本での翻訳は、

ユーザー・インタフェースの設計 　: 使いやすい対話型システムへの指針　日経BP社　1987
ユーザー・インタフェースの設計　 : やさしい対話型システムへの指針　　日経BP社　1993

↑のようにわずかに初版と第２版のみです。

しかも、このように古くて、古書ではバカ高い値段が付いています。

ユーザインタフェースに関する書籍って日本では売れないんでしょうね。これっきりで終わっています。

さて、ベン・シュナイダーマンのこの書籍の中で紹介されている

　・対話デザインの 8 つの黄金律( Eight Golden Rules of Dialogue Design )

と

　・ユーザーインターフェイスデザインの8つの黄金律( The 8 golden rules of user interface design )

は、Dialogue Design が、user interface design に置き換わっただけで同じ内容です。

日本でもｗｅｂで紹介されていますが、原文の雰囲気に忠実に訳したものは少ないように思います。

そこで、私( ONnoji )が、この「ユーザーインターフェイスデザインの8つの黄金律」を

拙作：INF_Framework と絡めてご紹介してゆこうと思います。

　◇　◇　◇　◇　◇

まずは、

１．Strive for consistency です。

訳すと「一貫性を保つよう努める」ですね。

　　１．一貫性をもたせる
　　　この原則はもっとも侵害されやすいが，修正したり避けるのも簡単である。
　　似たような状況では，一貫した一連の操作が要求され，プロンプト・メッセージやメニュー，ヘルプ画面では同じ用語を使い，
　　システム全体のコマンド形式は同じでなければならない。
　　パスワードは表示されない，DELETEコマンドは省略を許さないなどの例外はもちろんあるが，最小限にすべきである。
　　【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン 著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

桐的に思いっきり意訳すると次↓のようになります。

１．一貫性をもたせる( Strive for consistency )

　　この原則は守られ難いが、避けることは簡単です。
　よく似た状況では、メッセージボックスのメッセージや、フォーム上のメニューは同じ用語を使って、
　アプリケーション全体の操作方法は、同じでなければならない。

と、上のように意訳しました。(^^ゞ

これは誰にでも理解できますね。

でも、実際にそのようにしているか？は、クエスチョンな事が多いハズです。

　　４．３　タイトルバー
　　　MS Windows のような OS では、ウィンドウ操作がほぼ共通の操作（ルール）で扱えるからこそ価値があります。
　　つまり、最初に OS の基本操作を覚えてしまえば、はじめてのソフトでも大体の操作ができてしまうから便利なのです。
　　　ところが、桐ではタイトルバーを非表示にしたフォームを作ることも可能です。
　　しかしながら、このような行為はウィンドウ操作を共通の操作で扱えなくするので、「不親切なルール変更」と言わざるをえません。
　　従って、［フォーム＋イベント処理］のアプリケーションの場合には、タイトルバーを非表示にするのは厳禁です。

　　【引用】４．３　タイトルバー｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
　　　http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section4

上の引用のように、

MS Windows のような OS では、ウィンドウ操作がほぼ共通の操作（ルール）で扱えるからこそ価値があるのです。

これは、一貫性をもたせる( Strive for consistency )という命題そのものですよね。

最近でこそ見かけなくなりましたが、［フロー駆動型］の一括処理のアプリケーションでは、タイトルバーが表示されていないフォームが普通でした。

なぜならば、元々がＤＯＳ桐の画面にユーザが慣れていたこと、

もう一つ、［タイトルバー］の［×］ボタンをユーザに押させないという意思が働いているからです。

これは、［フロー駆動型］の一括処理のアプリケーションの特性なのですが、

一括処理の実行中に開いたウィンドウの［タイトルバー］の［×］ボタンを押すと、制御が一括処理に戻ってしまうのです。

もちろん、［イベント駆動型］の「フォーム＋イベント処理」では［タイトルバー］の［×］ボタンが押されても何の問題もありませんよね。

このように、［フロー駆動型］の一括処理のアプリケーションでは、［フォームのウィンドウ］の［タイトルバー］を非表示にすることが多く、

MS Windowsのウィンドウ操作の共通の操作（ルール）が適用出来なくなるワケです。

これは、「不親切なルール変更」と言わざるを得ません。キッパリ。
　　　　・・・・・・・・・・・

［フロー駆動型］の一括処理のアプリケーションというのは、そもそもＤＯＳ桐的なものであって、

キャラクタのスクリーンをグラフィカルなウィンドウに置き換えただけに過ぎないものなのですから、これは仕方ないのです。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

しかし、ＰＣのユーザは桐だけに接するワケではなくて、エクセルやｗｅｂブラウザやメーラ等も使っているワケです。

そのような使用環境において、Ｗｉｎ桐だけが旧態依然とした所作をしたままというのは、まるでガラパゴス状態ですね。
　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

桐だけがシーラカンスやカブトガニのようになってしまうのです。
・・・・・・・・・・・・・・・・・・・・・・・・・・

さて、［フロー駆動型］の一括処理のアプリケーションの話を終わりにして、［イベント駆動型］の「フォーム＋イベント処理」に眼を向けましょう。

「フォーム＋イベント処理」では、タイトルバーを非表示にすると、フォームウィンドウを閉じる・最大化・最小化が困難になります。

もしも、タイトルバーが無ければ、フォームウィンドウを移動させることもままならなくなります。

だから、まず殆どの人はフォームの［タイトルバー］は表示しているハズです。メデタシ。

一覧表形式（または伝票形式）のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［最小化］ボタンと［最大化］ボタンのチェックをオンにしてください。

カード形式のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［最小化］ボタンはオンですが、［最大化］ボタンのチェックはオフにしてください。

なぜならば、カード形式のフォームを最大化することはまずないからです。

　◇　◇　◇　◇　◇　◇

直前では、フォームの［タイトルバー］について考察しました。

今度は、フォームを閉じる時のボタンについて考えてみましょう。

またしても、［フロー駆動型］の一括処理アプリケーションの例を取り上げますが、・・・

桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。

その代わりに使われるボタンのキャプションは［終了］です。

これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。

また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、

実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。

ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。

さて、［フロー駆動型］の一括処理のアプリケーションの話を終わりにして、［イベント駆動型］の「フォーム＋イベント処理」に眼を向けましょう。

［イベント駆動型］の「フォーム＋イベント処理」では、フォームを閉じる操作として、

　・フォームの［タイトルバー］の［×］ボタン

　・フォームに配置した［閉じる］ボタン

　・フォームに配置した［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタン

を使います。

フォームの［タイトルバー］の［×］ボタンはオールマイティーですが、

［閉じる］ボタンと［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタンは使うフォームが限定されます。

これらのボタンは、［メニューとして使うフォーム］と主ウィンドウに対応する［補助ウィンドウのフォーム］で使用します。

［メニューとして使うフォーム］は、単なるランチャーなので、フォームフッタ部に［閉じる］を配置します。

［補助ウィンドウのフォーム］は、単なる［ダイアログボックス］なので、

同じくフォームフッタ部に［閉じる］ボタンや、［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタンを配置します。

この手の、フォームを閉じるボタンはフォーム明細部の下部に配置しても良いですが、やはりフォームフッタ部を表示してそこに配置するのが自然です。

ちなみに、フォームヘッダ部またはフォーム明細部の上部にこれらのボタンは配置しません。

これは見た目の悪さもありますが、まずウィンドウの上部にこれらのボタンを配置することは一般的ではないからです。

こういうのを［ルック・アンド・フィール］と言いますが、まず常識的な配置をするのが無難です。

　◇　◇　◇　◇　◇　◇

直前では、以下のオブジェクトについて考察しました。

　・フォームの［タイトルバー］の［×］ボタン

　・フォームに配置した［閉じる］ボタン

　・フォームに配置した［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタン

今度は、INF_Framework の標準ボタンについて考えてみましょう。

次のダイアグラムは、NO_FLD_EZW_Plus.wfx のオブジェクトのリストの一部分です。

トップページに戻る
桐の釣魚大全のトップ >  INF_Framework の話をしよう　―　Designing the User Interface