DOWN LOAD BBS [One Topic All View / INF_Framework の話をしよう / Page: 0]

DOWN LOAD BBS

[ 最新記事及び返信フォームをトピックトップへ ]

■506 / inTopicNo.1)

　INF_Framework の話をしよう

□投稿者/ ONnoji -(2024/09/13(Fri) 14:29:26)

2024/09/13(Fri) 17:36:23 編集(投稿者)

INF_Framework の話をしよう

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

　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 )

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

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

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■507 / inTopicNo.2)

　Re[1]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/13(Fri) 15:22:19)

2024/09/15(Sun) 15:49:34 編集(投稿者)

【再掲載】

１．一貫性をもたせる( 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のウィンドウ操作の共通の操作（ルール）が適用出来なくなるワケです。

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

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

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

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

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

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

　◇　◇　◇　◇　◇　◇　◇

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

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

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

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

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

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

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

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■508 / inTopicNo.3)

　Re[2]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/13(Fri) 17:22:50)

2024/09/14(Sat) 17:57:13 編集(投稿者)

【再掲載】

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

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

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

　◇　◇　◇　◇　◇　◇

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

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

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

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

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

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

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

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

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

　◇　◇　◇　◇　◇　◇　◇

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

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

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

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

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

を使います。

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

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

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

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

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

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

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

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

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

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

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■509 / inTopicNo.4)

　Re[3]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/14(Sat) 18:53:37)

2024/09/15(Sun) 15:38:52 編集(投稿者)

【再掲載】

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

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

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

　◇　◇　◇　◇　◇　◇

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

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

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

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

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

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

　　├ フォームヘッダ部
　　│　：
　　│　├ EZWcmdズームイン　　　┐
　　│　├ EZWcmdズームアウト　　│
　　│　├ EZWtxtMagnification 　│　
　　│　├ INFcmdWhoAreYou 　　　├─ 標準のコマンドボタン　※ヘッダ部左上に配置することを推奨します
　　│　├ HDLVARcmdWhoAreYou　　│
　　│　├ cmdAlt_I_ズームイン　│　※ cmdAlt_I_ズームインと cmdAlt_O_ズームアウトは［画面表示］= しない
　　│　├ cmdAlt_O_ズームアウト ┘
　　│　└ ONEcmdUI変換　　　　　 ← オプションのオブジェクト

これらの［標準のコマンドボタン］と呼んでいるコマンドボタンの内、

［(＋)］［(－)］［100%］［？］［？（桃色）］のオブジェクトはフォームヘッダ部の左上に配置することを推奨します。

これらのオブジェクトは、フォームヘッダ部の｛始点X = 3, 始点Y = 3 ｝ポイントの位置に［(＋)］を配置して、［(－)］［100%］［？］［？（桃色）］を２ポイント間隔で配置します。

もっとも簡単な方法は、NO_FLD_EZW_Plus.wfx の［標準のコマンドボタン］オブジェクトをコピーして、フォームヘッダ部にペーストすればＯＫです。

ちなみに、始点Y の位置を揃えて、２ポイントの間隔で並べるには、

あらかじめ［(＋)］［(－)］［100%］［？］［？（桃色）］のオブジェクトを選択してハンドル（黒い■）を表示させてから、

［(＋)］のオブジェクトを［ Ctrl + マウス左］でを選択してハンドル（白い□）を表示させて、

［書式］メニュー→［レイアウトの変更］を選び、［レイアウトの変更］ダイアログの［配置］タブで、

｛行数 = 1, 始点X = 3, 始点Y = 3, 水平 = 2, 垂直 = 0 ｝にセットして［ＯＫ］ボタンを実行します。

［レイアウトの変更］ダイアログを使わないと、［複数のオブジェクト］を等間隔に並べるのは大変ですので、是非覚えておいてください。(^^ok

ちなみに、［100%］つまり、［オブジェクト：EZWtxtMagnification］はテキストオブジェクトですが、［EZWcmdズームイン / EZWcmdズームアウト］とセット販売しているオブジェクトです。

ということで、テキストオブジェクトですが［標準のコマンドボタン］に加えています。

［コマンドボタン：cmdAlt_I_ズームイン］と［コマンドボタン：cmdAlt_O_ズームアウト］は、［(＋)］［(－)］と同じ機能ですが、

アクセスキーの［Alt + I］と［Alt + O］で動作する非表示の隠しコマンドボタンです。

非表示の隠しコマンドボタン［Ｉ］［Ｏ］は、当然見えませんのでフォームヘッダ部に配置する必要はありません。

フォームヘッダ部でも、フォーム明細部でも、フォームフッタ部のどこに配置してもＯＫです。

ただし、ワークスペースに配置するとアクセスキーの［Alt + I］と［Alt + O］は動作しなくなりますので注意してください。

　◇　◇　◇　◇　◇　◇

INF_Framework が組み込まれているすべてのフォームのフォームヘッダ部の｛始点X = 3, 始点Y = 3 ｝ポイントの位置を起点にして、

［(＋)］［(－)］［100%］［？］［？（桃色）］のオブジェクトが配置されている場合、

どのフォームも同じスタイルなので、フォームの倍率を変える・フォームの情報を見るといった操作をする時に迷子になりません。

これは、［一貫性をもたせる( Strive for consistency )］という要請に応える事にほかなりません。

なお、［100%］で表示されている倍率は、INF_Framework が組み込まれているフォームを閉じて再び開いた時に［フォームの倍率］が再現されます。

また、フォームを閉じる時に［フォームのウィンドウ］が最大化されている場合、フォームを閉じて再び開いた時に［ウィンドウの最大化］が再現されます。

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

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

また、カード形式のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［フォームスクロールバー］のチェックはオフにしてください。

そうすると、［(＋)］［(－)］を実行した時に、フォーム全体が拡大または縮小するようになります。

　〔INF_Framework ヒントとコツ〕

　・フォームを閉じて再び開いた時に、フォームの［フォームの倍率］　　が再現されます。
　・フォームを閉じて再び開いた時に、フォームの［ウィンドウの最大化］が再現されます。
　・カード形式のフォームでは、［最大化］ボタンのチェックをオフにします。
　・カード形式のフォームでは、［フォームスクロールバー］ボタンのチェックをオフにします。

　◇　◇　◇　◇　◇　◇

INF_Framework を組み込んだ一覧表形式（または伝票形式）のフォームでは、

フォームの［オブジェクトの属性］の［フォーム］タブの［ウィンドウのサイズ］を"自動"にしてください。

そうすると、フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］が再現されます。

そして、［水平位置の調整］［垂直位置の調整］の両方を"自動"にしてください。

そうすると、フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

一方、カード形式のフォームの場合には、フォームの［オブジェクトの属性］の［フォーム］タブの［ウィンドウのサイズ］を"フォームのサイズ"にしてください。

そうすると、フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］は同じままです。※100%以外の倍率では倍率の比例したサイズになります。

また、［水平位置の調整］［垂直位置の調整］の両方を"自動"にしてください。

そうすると、フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

　〔INF_Framework ヒントとコツ〕

　・一覧表形式（または伝票形式）のフォームでは、［ウィンドウのサイズ］を"自動"にします。
　　⇒フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］が再現されます。　　　　　　　　

　・フォームの［水平位置の調整］［垂直位置の調整］の両方を"自動"にます。
　　⇒フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

以上のように、INF_Framework は自動的に［フォームのウィンドウ］を閉じた時と同じ大きさで［フォームのウィンドウ］を開きます。

なおかつ、自動的に［フォームのウィンドウ］を閉じた時と同じ位置に［フォームのウィンドウ］を開きます。

この作業は INF_Framework が自動的に行うので、利用者は何も意識する必要はありません。

INF_Framework は、この作業のために［フォームの編集対象表］と同じフォルダに

　・フォームの位置
　・ウィンドウのサイズ
　・ウィンドウの最大化の有無
　・フォームの倍率
　・フォームの背景色

を記録したテキストファイルを出力します。

なお、［フォームの編集対象表］が無い［NULLフォーム］ではフォームと同じフォルダにテキストファイルを出力します。

テキストファイルの名前は、フォームファイル名_編集対象表ファイル名_info.txt です。［NULLフォーム］ではフォームファイル名_info.txt になります。

この INF_Framework が自動的に出力するファイルを、私( ONnoji )は［*_info］と呼んでいます。

この［*_info］は削除しても構いませんが、［フォームのウィンドウ］を閉じる度に生成されます。

もしも、［*_info］の内容をリセットしたい場合には、［フォームのウィンドウ］が閉じている時に、［フォームのウィンドウ］に対応する［*_info］を削除してください。

（重要）［*_info］の内容をメモ帳でご覧になってもＯＫですが、エラーの元になるので内容は変更しないでください。

　〔INF_Framework ヒントとコツ〕

　・フォームを閉じると、［*_info］が生成されます。※次回フォームを開く時に自動的に内容が読み込まれます。
　・［*_info］は、フォームファイル名_編集対象表ファイル名_info.txt またはフォームファイル名_info.txt です。
　・［*_info］は、［フォームの編集対象表］と同じフォルダ、または［NULLフォーム］では［フォーム］と同じフォルダに出力されます。
　・［*_info］は、削除してもＯＫです。

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■510 / inTopicNo.5)

　Re[4]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/15(Sun) 14:58:18)

2024/09/15(Sun) 19:02:50 編集(投稿者)

オプションの［コマンドボタン：ONEcmdUI変換］は、［立体的なＵＩ］と［フラットなＵＩ］を切り替えます。

［フラットなＵＩ］は、桐10ｓ以降の桐で作るフォームの標準です。

INF_Framework では、［立体的なＵＩ］を［クラシックＵＩ］、［フラットなＵＩ］を［モダンＵＩ］と呼んでいます。

この機能を利用する場合には、"famModernUI" という名前のファミリを作ってください。

この［ファミリ：famModernUI］は作るだけでＯＫです。

［ラベルオブジェクト：lblFlatButtonBorder_1］は、フォームヘッダ部専用です。

このオブジェクトは、［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにしてください。

　　├ ファミリ
　　│　└ famModernUI　　　← オプションのオブジェクト
　　：
　　├ フォームヘッダ部
　　│　：
　　│　├ lblFlatButtonBorder_1　← オプションのオブジェクト　※同じセクションの他のコマンドボタンよりも上位になるようにしてください
　　│　├ EZWcmdズームイン
　　│　├ EZWcmdズームアウト
　　│　├ EZWtxtMagnification
　　│　├ INFcmdWhoAreYou
　　│　├ HDLVARcmdWhoAreYou
　　│　├ cmdAlt_I_ズームイン
　　│　├ cmdAlt_O_ズームアウト
　　│　└ ONEcmdUI変換　　　　　 ← オプションのオブジェクト

同様に、［フォーム明細部］専用には［ラベルオブジェクト：lblFlatButtonBorder_2］、［フォームフッタ］専用には［ラベルオブジェクト：lblFlatButtonBorder_3］を使います。

このオブジェクトも、［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにしてください。

これらのオブジェクトは、［ラベルオブジェクト：lblFlatButtonBorder_1］をコピー＆ペーストすれば簡単に作れます。

［ラベルオブジェクト：lblFlatButtonBorder_1 ～ 3 ］が有ると、コマンドボタンの上にマウスがホバーした時に［ラベルを領した縁取りが］表示されます。

なお、当然ですがこの機能が利用できるのは、フラットなＵＩが利用できる桐10ｓ以降の桐です。

　〔INF_Framework ヒントとコツ〕

　・［コマンドボタン：ONEcmdUI変換］は、［立体的なＵＩ⇔フラットなＵＩ］を切り替えます。
　・この機能を利用するためには［ファミリ：famModernUI］を作ってください。ファミリは作るだけでＯＫです。
　・［ラベルオブジェクト：lblFlatButtonBorder_1 ～ 3 ］が有ると、コマンドボタンの上にマウスがホバーした時に［ラベルを利用した縁取りが］表示されます。
　・［ラベルオブジェクト：lblFlatButtonBorder_1 ～ 3 ］は［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにします。
　・この機能が利用できるのは、フラットなＵＩが利用できる桐10ｓ以降の桐です。

桐10ｓ以降の桐のフォームの［スタイル名：フラットスタイル1 ］では、コマンドボタンのスタイルは"フラット（縁有り）"が標準です。

しかし、"フラット（縁有り）"では、マウスポインタがコマンドボタンの上をホバーしてもスタイルに変化がありません。

これでは、［コマンドボタン］なのか？、［テキスト］なのか？、はたまた［ラベル］なのかサッパリ分かりません。

従って、どうしてこのようなスタイルが標準になっているのか理解に苦しむところです。

そのために、INF_Framework では、マウスポインタがコマンドボタンの上をホバーした際に、

コマンドボタンの背後に［ラベルオブジェクト：lblFlatButtonBorder_1 ～ 3 ］を表示して、背景色を"RGB(229,243,255)" にセットします。

そうすることで、マウスポインタがホバーしているコマンドボタンを分かり易く表示しています。

　　INF_Framework なし　　　　　　　　あり　　　　　　　あり　　　　　　　あり
　　スタイル名　　フラットスタイル1　　モダンＵＩ　　　　モダンＵＩ　　　　クラシックＵＩ
　　状態　　　　　マウスアウト／イン　マウスアウト　　　マウスイン　　　　マウスアウト／イン
　　背景色　　　　RGB(207,216,220) 　　RGB(225,225,225)　RGB(229,243,255)　RGB(225,225,225)
　　立体色モード　フラット（縁有り）　フラット　　　　　フラット　　　　　Windowsの立体色

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■511 / inTopicNo.6)

　Re[1]: INF_Framework の話をしよう

▲▼■

□投稿者/ ジェダイの桐 -(2024/09/18(Wed) 10:12:09)

ONnojiさん

おはようございます！

スレッドを興味深く読ませて頂いています。

> 桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。
>
> その代わりに使われるボタンのキャプションは［終了］です。
>
> これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。
>
> また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、
>
> 実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。
>
> ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。

こちらの解説を読むことで、出来るかどうかは別として

>ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。

この考え方は、「フォーム + イベント」　では不自然だと言う事が、より理解出来ました(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■520 / inTopicNo.7)

　Re[5]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/24(Tue) 09:31:07)

2024/09/24(Tue) 09:38:17 編集(投稿者)

INF_Framework の｛ウィンドウのサイズ、位置、倍率、最大化｝の自動再現について

■｛ウィンドウのサイズ、位置、倍率、最大化｝の自動再現

　一覧表形式（または伝票形式）のフォームの場合に推奨します。

　　　属性名　　　　　　：値
　　　タイトルバー　　　：あり
　　　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　　：水平/垂直
［≡］ｺﾝﾄﾛｰﾙﾒﾆｭｰﾎﾞｯｸｽ　：いる
［小］最小化ボタン　　　：いる
［大］最大化ボタン　　　：いる
　　　ウィンドウのサイズ：自動
　　　垂直位置の調整　　：自動
　　　水平位置の調整　　：自動
　　　↓
　　　└→┌─┬───────┬─┬─┬─┐
　　　　　│≡│　　　　　　　│小│大│×│
　　　　　├─┴───────┴─┴─┴─┤
　　　　　│[+][-]100%[?][?]　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　編集時の表示倍率：標準　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　：水平/垂直 │
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　└───────────────┘
　　　　　│←　ウィンドウのサイズ：　　→│
　　　　　│　　　自動　　　　　　　　　　│

■｛位置、倍率｝の自動再現

　カード形式のフォームの場合に推奨します。

　　　属性名　　　　　　：値
　　　タイトルバー　　　：あり
　　　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　　：なし
［≡］ｺﾝﾄﾛｰﾙﾒﾆｭｰﾎﾞｯｸｽ　：いる
［小］最小化ボタン　　　：いる
［Ｍ］最大化ボタン　　　：いらない
　　　ウィンドウのサイズ：フォームのサイズ
　　　垂直位置の調整　　：自動
　　　水平位置の調整　　：自動
　　　↓
　　　└→┌─┬───────┬─┬─┬─┐
　　　　　│≡│　　　　　　　│小│Ｍ│×│
　　　　　├─┴───────┴─┴─┴─┤
　　　　　│[+][-]100%[?][?]　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　編集時の表示倍率：標準　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　：なし　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　│　　　　　　　　　　　　　　　│
　　　　　└───────────────┘
　　　　　│←　ウィンドウのサイズ：　　→│
　　　　　│　　　フォームのサイズ　　　　│

引用返信 [メール受信/OFF] 削除キー/

■521 / inTopicNo.8)

　Re[2]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/25(Wed) 14:09:26)

2024/09/25(Wed) 14:33:44 編集(投稿者)

ジェダイの桐さん

>>桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。
>>その代わりに使われるボタンのキャプションは［終了］です。
>>これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。
>>また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、
>>実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。
>>ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。
>
> こちらの解説を読むことで、出来るかどうかは別として
> >ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。
> この考え方は、「フォーム + イベント」　では不自然だと言う事が、より理解出来ました(^^ゞ

Ｗｉｎ桐の一括処理には、

Ａ．ＤＯＳ桐で動作する一括処理を［一括処理ウィンドウ］で実行する

Ｂ．桐のウィンドウハンドル番号を使わないでアプリケーションを作る

Ｃ．桐のウィンドウハンドル番号を使ってアプリケーションを作る

の３通りあります。

Ａは論外として、一括処理を知らない人にとって、ＢとＣの違いは分かり難いです。

■桐のウィンドウハンドル番号を使わないアプリケーション

これは、

・［フォーム形式編集］コマンド
・［表形式編集］コマンド

を使うやり方です。

この場合には、ＤＯＳ桐とほぼ同じなので桐のウィンドウハンドル番号の出番はありません。

このタイプは簡易的なアプリケーションに多くみられます。

■桐のウィンドウハンドル番号を使うアプリケーション

これは、

・［ウィンドウ作成］コマンド
・［ウィンドウ会話］コマンド
・［ウィンドウ終了］コマンド

を使うやり方です。

このタイプは複雑なアプリケーションに多くみられます。

これは、フォームや表のウィンドウを［舞台の書割］のように使い一括処理側ですべて制御しようとするアプローチです。

つまり、表示されている［フォームや表のウィンドウ］は、単なる舞台背景と同じ扱いです。
　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

つまり、銭湯の富士山のペンキ絵と同じなんですよ。
　　　　・・・・・・・・・・・・・・

ということで、私( ONnoji )は強烈な違和感を感じて、すぐに一括処理というアプローチを放棄しましたっけ。

しかし、ＤＯＳ桐時代のアプリケーションを沢山所有している企業・団体では、

桐ver.7の時に［桐のウィンドウハンドル番号を使うアプリケーション］を大量生産したと思います。

Windows は 95 → 98 → Me / NT 4.0 → 2000 と急速にバージョンアップして、ＤＯＳ桐を使い続けることが難しくなったことも理由のひとつでしょう。

遅まきながら、桐ver.8で［フォーム＋イベント処理］というアプローチが可能になりましたが、

それまでに「桐＝一括処理」というステレオタイプ（多くの人に浸透している先入観や思い込み）が生まれてしまったんですね。
　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

だから、桐ver.8の当時には、［フォーム＋イベント処理］でアプリケーションが作れると思った人は少数派でした。

一括処理を読めばすべて処理が書いてあるので「一括処理の方が見通しが良い」と思っている人が圧倒的だったんですね。

［プロセス（処理）中心］のアプローチが普通に当たり前と思われていたのですから仕方ないですね。アハハハha

ｐ．ｓ．

桐には長い歴史があります。

ということで、コマンドにも

・座標指定を伴うＤＯＳ桐由来のコマンド
・簡易一括処理（［表形式編集］／［フォーム形式編集］系）のコマンド
・拡張一括処理（［ウィンドウ作成］／［ウィンドウ会話］／［ウィンドウ終了］系）のコマンド
・それ以外

とさまざまです。

だから、［イベント処理］でも使えるからといっても、使わない方がよいコマンドもあるのです。

それが［ウィンドウ終了］コマンドなのですよ。

迷ったら拙作ｗｅｂページを参考にしてください。

こちら
　↓
１５　コマンド｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section15

　桐のコマンドにも、Ｗｉｎ桐がコンプレックス( 英:complex 複合の )であることが大きく影響しています。
すなわち、ＤＯＳ桐と互換の［古典一括処理］と、ウィンドウハンドル番号を用いた［拡張一括処理］と、
そしてWindowsらしい［フォーム＋イベント］で使えるコマンドが重層的に積み重なっています。

引用返信 [メール受信/OFF] 削除キー/

■522 / inTopicNo.9)

　Re[6]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/25(Wed) 15:15:56)

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

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

・対話デザインの 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 と絡めてご紹介してゆこうと思います。

２番めの黄金律は、

２．Enable frequent users to use shortcuts です。

訳すと「頻繁に使うユーザーには近道を用意する」ですね。

　２．頻繁に使うユーザーには近道を用意する

　　使用頻度が高くなると，ユーザーは対話の回数やキー入力の数を少なくしたくなる。
　知識のあるユーサーには省略形，特殊キー，隠しコマンド，マクロ機能などが歓迎される。
　頻繁に使用するユーザーには応答時間の短縮や表示速度の向上が魅力的である。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　２．頻繁に使うユーザーには近道を用意する（Enable frequent users to use shortcuts）

　　使用頻度が高くなると、ユーザはなるべく少ない手順でそうしたいと感じる。
　初級者よりも上級者の方が、アクセスキーや特殊キー、マクロ機能を歓迎します。
　頻繁に使用するユーザには、応答時間の短縮と表示速度の向上が魅力的である。

これは、具体的には、桐のコマンドボタンのアクセスキーでしょうかね。

しかし、マウスを使う事が多いので、コマンドボタンのアクセスキーを知らない人だって居ますよね。

この 8つの黄金律が書かれた当時には、ＧＵＩが普及していなかったのでキー操作に多くの関心が注がれています。

［フォーム＋イベント処理］で応答時間を短縮するには、

・編集対象表を多重化して作業する

のが効果的ですね。

＜続く＞

引用返信 [メール受信/OFF] 削除キー/

■523 / inTopicNo.10)

　Re[3]: INF_Framework の話をしよう

▲▼■

□投稿者/ ジェダイの桐 -(2024/09/26(Thu) 11:34:26)

ONnojiさん

おはようございます。

dos桐　でインターネット検索をして画像を見てみました。
余り画像は有りませんが、何となく当時の雰囲気を感じました。

それでも、メニュー画面らしき物しかヒットしませんでした。
なので、［一括処理実行］ウィンドウ　がどんな画面なのか分かりませんでした。

例えば、

月末処理.cmd
月初処理.cmd
仕入処理.cmd

みたいに、それぞれの処理毎に　○○.cmd　ファイルがあった感じなのですかね？？

だとしたら、

やりたい事を実行するきっかけが、　○○.cmd　ファイル　で　設計者の想定内処理が順番に行われて終了するという感じなのでしょうね。

桐ver.8　からは［フォーム＋イベント処理］が可能となり

やりたい事を実行するきっかけが、　オブジェクト　になった
やりたい事は　○○.kex　ファイルに　プロシージャ　を記述する

上記の通り　アプローチが　プロセス中心　から　イベント駆動型　となり
プロセス中心になじみ深い人ほどアプローチの切り替えが難しいと言う事なのだと現状理解しています。

ｐ.ｓ.

> 迷ったら拙作ｗｅｂページを参考にしてください。

基本的に毎日1回は何かしら読んでいるのですが、
最近読んだ中で、心に響いた章が　8　プロシージャ　です。

イベントハンドラ　一般手続き　と表現を　プロシージャ　と統一して記載して頂いているので分かりやすいです(^^ゞ　

引用返信 [メール受信/OFF] 削除キー/

■524 / inTopicNo.11)

　Re[4]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/26(Thu) 14:46:15)

2024/09/27(Fri) 11:23:28 編集(投稿者)
2024/09/26(Thu) 14:49:57 編集(投稿者)

ジェダイの桐さん

> それでも、メニュー画面らしき物しかヒットしませんでした。
> なので、［一括処理実行］ウィンドウ　がどんな画面なのか分かりませんでした。
> 例えば、
> 月末処理.cmd
> 月初処理.cmd
> 仕入処理.cmd
> みたいに、それぞれの処理毎に　○○.cmd　ファイルがあった感じなのですかね？？
> だとしたら、
> やりたい事を実行するきっかけが、　○○.cmd　ファイル　で　設計者の想定内処理が順番に行われて終了するという感じなのでしょうね。

メニューに相当する一括処理があって、そこからケース文で月末処理.cmd 月初処理.cmd 仕入処理.cmd に分岐する感じですね。

ほぼ、バッチ処理や、ＮＥＣのBASICと同じです。

このころの一括処理は、全体の行の内、半分かそれ以上を画面を描くためのコマンドに使っているんですよ。

ＤＯＳ時代にはインターネットが現在より普及していませんでしたから、ネット上にはＤＯＳ桐関係の情報は少ないですね。

ネット上にＰＣソフトの情報が多くなるのは、Windows 95が普及してからになりますね。

> 桐ver.8　からは［フォーム＋イベント処理］が可能となり
> やりたい事を実行するきっかけが、　オブジェクト　になった
> やりたい事は　○○.kex　ファイルに　プロシージャ　を記述する
> 上記の通り　アプローチが　プロセス中心　から　イベント駆動型　となり
> プロセス中心になじみ深い人ほどアプローチの切り替えが難しいと言う事なのだと現状理解しています。

「キッカケがオブジェクトになった」と表現してもワカラナイでもないですが・・・

「ユーザの操作がキッカケになり、手続きが呼び出されて」と表現する方が間違えがないでしょう。

なにしろ、オブジェクトという言葉だけで、オブジェクト指向プログラミングだと早合点してしまう人がそこら中に居ますから。
　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

だから、オブジェクト！オブジェクト！！と連呼しないで、

［コマンドボタン］を実行するとか、「この時○○イベントが発生して」とかに言い換えた方がよろしいですよ。

　◇　◇　◇　◇　◇　◇

なお、対応する言葉・概念は、

［フロー駆動型］　　　⇔［イベント駆動型］　　※プログラムを駆動する方式の違い

［プロセス中心の設計］⇔［データ中心の設計］　※プログラムを設計する時のアプローチの違い

です。

コンピュータが使われるようになった初期のころには、プログラムは小規模なものが多かったので［プロセス中心の設計］で間に合ったのですね。

ちなみに、プロセスとは「入力－処理－出力」のことなんですね。

だから、ある時期まではコンピュータ関連の書籍は［プロセス中心の設計］のオンパレードだったのです。

しかし、その後［データ中心の設計］の方が主流になっています。

ネットにたくさん情報がありますよ。

例えば、こちら
　　　　　↓
データ中心設計（データ中心アプローチ）｜基本情報技術者試験
https://ameblo.jp/fegetter/entry-11811109025.html

引用返信 [メール受信/OFF] 削除キー/

■525 / inTopicNo.12)

　Re[7]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/26(Thu) 15:22:32)

2024/09/26(Thu) 17:46:16 編集(投稿者)

３番めの黄金律は、

３．Offer informative feedback です。

訳すと「有益なフィードバックを提供する」ですね。

　３．有益なフィードバックを提供する

　　どんな操作に対しても，システムは常に何らかのフィードバックを与えるべきである。
　しばしば発生し，しかも副次的な操作に対する応答は簡潔に，たまに実行され大事な操作への応答は情報量を多くすべきである。
　操作している対象を視覚的に表現すると，ユーザーは変化を常に把握できるので操作しやすい(第５章の直接操作を参照)。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　３．有益なフィードバックを提供する(Offer informative feedback)

　　すべての操作に対して、アプリケーションは何らかのフィードバックを返すべきです。
　副次的な操作に対するメッセージは簡潔にして、重大な操作へのメッセージは情報量を多くするべきである。
　操作対象を視覚的に表現すると、ユーザは変化を常に把握できるので操作し易い。

これは案外と難しいかもしれませんね。

なぜならば、オペレータさんの心理を気にしているアプリケーションの開発者は案外と少ないです。

初級者ならば作るのに精一杯で、そこまで手が回らないでしょう。

でもね、使うのはオペレータさんの方なのですから、オペレータさんの反応をよく観察するようにしたいものです。

残念ながら、多くのオペレータさんは、アプリケーションの開発者は全知全能だろうと勝手に思っていますから、

開発者が質問しても、期待通りの返事をしてくれないでしょう。

でも、アプリケーションをリリースする前と後にオペレータさんと打合せをするべきです。

「全部あなたにお任せ！」と言うオペレータさんが殆どでしょうけれど、コミュニケーションは大事です。

ｐ．ｓ．

ＰＣ作業をしていると、さまざまなソフトウェアから意味不明のメッセージボックスが表示されることがあるでしょう。

技術者にしか通じない用語が並んでいるメッセージボックスや、脅迫めいたエラーメッセージ・・・

こんな稚拙なメッセージボックスばかりを見せられているから、

ついつい、マネしちゃうかもしれませんね。

でもね、こういうのは真似しないでください。(^^ok

引用返信 [メール受信/OFF] 削除キー/

■526 / inTopicNo.13)

　Re[8]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/27(Fri) 13:36:12)

４番めの黄金律は、

４．Design dialogues to yield closure です。

訳すと「段階的な達成感を与える対話を実現する」ですね。

　４．段階的な達成感を与える対話を実現する

　　仕事の流れにも起承転結が必要である。
　一連の操作を完遂したときに操作者にそれを知らせるフィードバックは，
　１つの事をやり遂げたという満足感，安心感を与え，不測の事態を起こす可能性を少なくするとともに，次の動作への準備をうながす。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　４．段階的な達成感を与える対話を実現する( Design dialogues to yield closure )

　　作業の流れにも起承転結が必要である。
　一連の作業をやり遂げた時にオペレータにその事をを知らせるフィードバックは、
　仕事をやり遂げたという満足感、安心感を与え、不測の事態を起こす可能性を少なくするとともに、次への作業の準備を促す。

上手にデザインされたアプリケーションであれば、オペレータさんは集中力が高まり「いわゆるゾーン入る」状態になります。

作業の区切り区切りで、現在の作業の状態を示すフィードバックがあるとオペレータさんは安心します。

引用返信 [メール受信/OFF] 削除キー/

■527 / inTopicNo.14)

　Re[9]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/29(Sun) 11:48:14)

2024/09/29(Sun) 11:49:53 編集(投稿者)

５番めの黄金律は、

５．Offer Simple Error Handling です。

訳すと「エラーの処理を簡単にさせる」ですね。

　５．エラーの処理を簡単にさせる

　　できる限りユーザーが致命的なエラーを起こさないように設計しなければならない。
　しかし，もし工ラーが起きてしまったら，システムがその原因を見つけ出し，単純でわかりやすいエラーの処理方法を提供するように心がける。
　たとえば，コマンド全部を再入力するのではなく，間違えた箇所だけを訂正すればよいようにすべきである。
　または，間違ったコマンドを入力してもシステムの状態が変化しないようにするか，元の状態に戻す方法を提示しなければならない。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　５．エラーの処理を簡単にさせる( Offer Simple Error Handling )

　　出来るだけユーザが致命的なエラーを起こさないように設計しなければならない。
　しかし、もしもエラーが起きてしまったならば、アプリケーションがその原因を見つけ出して、単純で分かり易い対処方法を提供するように心がける。

　※「たとえば」以降の文言はコマンド入力型のアプリケーションで、入力したコマンドが間違っていた場合の例を挙げているので翻案しません。

「エラー」と言っても実はさまざまな種類があります。

例えば、

［予期せぬエラー］ ⇔ ［予期されたエラー］

という区分けでは、［予期せぬエラー］は回避しようがありませんが、［予期されたエラー］の場合には適切なフィードバックをするべきです。

例えば、［一覧表印刷条件開始］コマンドで指定した［給紙方法］・［用紙サイズ］がプリンタドライバに適合しない場合にはエラーになります。

この場合には、メッセージボックスでエラーの【原因】と【対処方法】をユーザに示すことが出来ます。

以下は［拙作：ガントチャート］の手続き：prcPrintListCreateCommandAlert( ) の例です。

　&msg = "＜アラート（警告）＞"
　&msg = &msg + "\n\n一覧表印刷条件の作成に失敗しました"
　&msg = &msg + "\n\nエラー番号："　　　 + #cond( &mErrorRefErrno > 0, "KU", 1, "KD" ) + #str( &mErrorRefErrno )
　&msg = &msg + "\n\nエラーメッセージ：" + &mErrorRefErrmsg
　&msg = &msg + "\n\nエラーの詳細："　　 + &mErrorRefDetail
　&msg = &msg + "\n\nイベント処理："　　 + &mErrorRefCmdname
　&msg = &msg + "\n\n行番号："　　　　　 + #str( &mErrorRefLineno )
　&msg = &msg + "\n\n＜対処方法＞"
　&msg = &msg + "\n\n一覧表印刷条件開始 &mPrintListName,用紙サイズ=&用紙サイズ,給紙方法=&給紙方法,用紙の向き=横,上余白=1000,…"
　&msg = &msg + "\n\n↑このコマンドで使用している変数名：" + &variableName + " の値を"
　&msg = &msg + "\n\nプリンタ：" + #桐プリンタ名 + " の【" + #文字置換( &variableName, &ampersand, #u ) + "】に適した値に変更してください"
　&icon = "!"
　手続き実行　INFprcMsgPause( &icon, &title, &msg )

［予期されたエラー］というのは、ＰＣの周辺装置（ネットワークを含む）に関するエラーです。

一方、［予期せぬエラー］はアプリケーションをリリースする前に十分なテストを行う事でエラーの発生を予防できます。

ただし、十分なテストを行ったとしても、テストから漏れた潜在虫が残る可能性はゼロにはなりません。

しかし、十分なテストを行った場合には、プログラムは安定していて、潜在虫が見つかる可能性は非常に低くなります。

引用返信 [メール受信/OFF] 削除キー/

■528 / inTopicNo.15)

　Re[10]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/09/30(Mon) 18:07:17)

2024/10/01(Tue) 15:04:26 編集(投稿者)

６番めの黄金律は、

６．Permit easy reversal of actions です。

訳すと「逆操作を許す」ですね。

　６．逆操作を許す

　　できる限り操作は可逆にすべきである。
　操作を誤ったとしても，それを取り消せることを知っていれば不安にならないし，
　よく知らない機能でも試してみる気にさせる。
　逆戻しの単位としては，１回の操作やデータ入力，または完結する一連の操作であることも考えられる。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　６．逆操作を許す( Permit easy reversal of actions )

　　出来る限り操作は可逆的にするべきである。
　誤った操作をしても、それを取り消せることを知っていれば不安にならないし、
　よく知らない機能でもそれを試してみる気にさせます。
　逆戻しの単位は、１回の操作やデータの入力、または一連の操作であることも考えられる。

桐では、アンドゥ【undo】機能があるので、戻るのは簡単です。

でも、リドゥ【redo】がありませんから変なの。アハハハハ

しかし、可逆的というものではありませんが、［最初からやり直し］という事は考慮した方がいいでしょう。

その為には、作業用の表(.tbx)で処理をすることです。

作業用の表(.tbx)ですから、結果を反映する前に破棄することも可能です。

月次の作業などは、作業用の表(.tbx)で処理を進めるのがよいと思いますよ。

引用返信 [メール受信/OFF] 削除キー/

■529 / inTopicNo.16)

　Re[11]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/10/01(Tue) 15:22:08)

2024/10/01(Tue) 16:58:30 編集(投稿者)

７番めの黄金律は、

７．Support internal locus of control( Keep the User in Control ) です。

訳すと「主体的な制御権を与える」ですね。

　７．主体的な制御権を与える

　　経験の豊富な操作者は，自分がシステムを制御し，システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
　ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力，
　あるいは欲しい情報を得ることが不可能または困難であったり，期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
　Gaines(1981)はこの原理を，「不条理を避ける」という彼の原則と，ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

　７．主体的な制御権を与える( Support internal locus of control / Keep the User in Control )

　　経験豊富なＰＣユーザは、自分がシステムを制御し、システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
　ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力，
　あるいは欲しい情報を得ることが不可能または困難であったり、期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
　Gaines(1981)はこの原理を，「不条理を避ける」という彼の原則と、ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。

例えば、複数のテキストボックスに文字を入力していくフォームの場合、

ひとつのテキストボックスの入力が確定する度にエラーチェックをしても良いが、

エラーしたテキストボックスの文字色を赤色にする程度にして、

その都度メッセージボックスでエラーを通知するのは避けるべきです。

何故ならば、キーをミスタッチするのは普通の事ですから。

エラーのチェックは、すべての入力が終わってから、まとめてチェックをするのが望ましいです。

もしも、エラーが見つかったならば、その時にメッセージボックスを表示するだけで十分です。

引用返信 [メール受信/OFF] 削除キー/

■530 / inTopicNo.17)

　Re[12]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/10/01(Tue) 17:28:15)

８番めの黄金律は、

８．Reduce Short-Term Memory Load です。

訳すと「短期記憶領域の負担を少なくする」ですね。

８．短期記憶領域の負担を少なくする

　　人間の短期記憶領域には限度( ７土２のかたまり)があるので，
　表示は簡潔にし，何べージにもわたるような表示は統合しウインドウの移動を少なくし，
　コードや記号，一連の操作を学習するために十分な時間を用意する必要がある。
　必要に応じて，コマンドの構文形式，省略形，コードなどの情報をオンライン検索できるとよい。
【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X

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

８．短期記憶領域の負担を少なくする( Reduce Short-Term Memory Load )

　　人間の短期記憶領域には限度( ７土２のかたまり)があるので、
　表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし、
　コードや記号、一連の操作を学習するために十分な時間を用意する必要がある。

　※「必要に応じて」以降の文言はコマンド入力型のアプリケーション対象にしているので翻案しません。

人間の短期記憶領域という言葉を聞いたことが無い人もあるかと思います。

例えば、一度に長い電話番号は覚えにくいけれど、いくつかの数字に区切ると覚えやすい。

この時の単位が、［７土２のかたまり］だという主張です。

この［かたまり］のことを［チャンク］と言います。

［チャンク］は７土２ではなく、４土２だという最近の研究結果もあるようですが、

人によって、また体調によってｎ土２のｎは変わるでしょう。

いずれにしても、この人間の短期記憶の［チャンク］を超えると短期記憶の負担が多くなります。

つまり、疲れます。(^^ゞ

なので、「表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし」となります。

迷子になるアプリケーションやｗｅｂページは、この黄金律を守っていない事が多いですね。

引用返信 [メール受信/OFF] 削除キー/

■531 / inTopicNo.18)

　Re[13]: INF_Framework の話をしよう

▲▼■

□投稿者/ ONnoji -(2024/10/01(Tue) 17:40:41)

2024/10/01(Tue) 17:51:51 編集(投稿者)

以上、ベン・シュナイダーマンの

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

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

をご紹介しました。

この８つの黄金律は、非常に有名なものなので是非一読をお勧めいたします。

以下は ONnoji が多少アレンジした８つの黄金律です。

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

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

　２．頻繁に使うユーザーには近道を用意する（ Enable frequent users to use shortcuts ）

　　使用頻度が高くなると、ユーザはなるべく少ない手順でそうしたいと感じる。
　初級者よりも上級者の方が、アクセスキーや特殊キー、マクロ機能を歓迎します。
　頻繁に使用するユーザには、応答時間の短縮と表示速度の向上が魅力的である。

　３．有益なフィードバックを提供する( Offer informative feedback )

　　すべての操作に対して、アプリケーションは何らかのフィードバックを返すべきです。
　副次的な操作に対するメッセージは簡潔にして、重大な操作へのメッセージは情報量を多くするべきである。
　操作対象を視覚的に表現すると、ユーザは変化を常に把握できるので操作し易い。

　４．段階的な達成感を与える対話を実現する( Design dialogues to yield closure )

　　作業の流れにも起承転結が必要である。
　一連の作業をやり遂げた時にオペレータにその事をを知らせるフィードバックは、
　仕事をやり遂げたという満足感、安心感を与え、不測の事態を起こす可能性を少なくするとともに、次への作業の準備を促す。

　５．エラーの処理を簡単にさせる( Offer Simple Error Handling )

　　出来るだけユーザが致命的なエラーを起こさないように設計しなければならない。
　しかし、もしもエラーが起きてしまったならば、アプリケーションがその原因を見つけ出して、単純で分かり易い対処方法を提供するように心がける。

　６．逆操作を許す( Permit easy reversal of actions )

　　出来る限り操作は可逆的にするべきである。
　誤った操作をしても、それを取り消せることを知っていれば不安にならないし、
　よく知らない機能でもそれを試してみる気にさせます。
　逆戻しの単位は、１回の操作やデータの入力、または一連の操作であることも考えられる。

　７．主体的な制御権を与える( Support internal locus of control / Keep the User in Control )

　　経験豊富なＰＣユーザは、自分がシステムを制御し、システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
　ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力，
　あるいは欲しい情報を得ることが不可能または困難であったり、期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
　Gaines(1981)はこの原理を，「不条理を避ける」という彼の原則と、ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。

　８．短期記憶領域の負担を少なくする( Reduce Short-Term Memory Load )

　　人間の短期記憶領域には限度( ７土２のかたまり)があるので、
　表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし、
　コードや記号、一連の操作を学習するために十分な時間を用意する必要がある。

　◇　◇　◇　◇　◇　◇　◇　◇

　フォームアプリケーションを作る際に、ユーザインタフェースで悩むことがあったら、

是非ベン・シュナイダーマンの８つの黄金律を思い出してください。

そうすれば、問題解決の糸口が必ず見つかるはずです。

384×512 => 187×250

1727772661.jpg/42KB

引用返信 [メール受信/OFF] 削除キー/

■532 / inTopicNo.19)

　Re[1]: INF_Framework の話をしよう

▲▼■

□投稿者/ ジェダイの桐 -(2024/10/02(Wed) 09:36:52)

ONnojiさん

おはようございます！

記事全て読ませて頂きました。

8つの黄金律解説を読んで、身の回りでは

　Amazon
　ユニクロ

の登録画面、がこの黄金律の条件を達成しているのかな？
と感じました。

私自身が桐で即対応出来そうな事は

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

こちらです。
これは、作成する時に気を付ける事が出来れば達成出来そうだからです。

２～８は今の私の力量では、真似事　.or　対応不可　かなと感じました。

但し、設計する上での8つの黄金律を基本概念として開発するだけでも
今までより、使用者にとって使いやすい物が作れると思います。

引用返信 [メール受信/OFF] 削除キー/

■533 / inTopicNo.20)

　Re[2]: INF_Framework の話をしよう

▲　■

□投稿者/ ONnoji -(2024/10/02(Wed) 11:10:00)

ジェダイの桐さん

> 記事全て読ませて頂きました。

ありがとうございます。

> 8つの黄金律解説を読んで、身の回りでは
> 　Amazon
> 　ユニクロ
> の登録画面、がこの黄金律の条件を達成しているのかな？
> と感じました。

ｗｅｂページのデザイナーならば、ベン・シュナイダーマンの［８つの黄金律］は常識だと思いますよ。

しかし、もはやこれは古典となっているので、敢えて［８つの黄金律］と呼ばないことも多いと思います。

> 私自身が桐で即対応出来そうな事は
>>　１．一貫性をもたせる( Strive for consistency )
> こちらです。
> これは、作成する時に気を付ける事が出来れば達成出来そうだからです。

そうですね。

一貫性が大事ですね。難しい事ではありませんよ。

> ２～８は今の私の力量では、真似事　.or　対応不可　かなと感じました。
> 但し、設計する上での8つの黄金律を基本概念として開発するだけでも
> 今までより、使用者にとって使いやすい物が作れると思います。

プログラミングというと理数系と思う人が案外と多いですが、

桐やエクセルのプログラミングは、

純粋なコンピュータサイエンス（計算機科学）ではありませんので、

基本制御構造を知っていれば足ります。

そして、最も足らないのがユーザインタフェースの部分です。

だから、「プログラミングは心理学である」と言っても言い過ぎではありませんよ。アハハハハha

引用返信 [メール受信/OFF] 削除キー/

このトピックをツリーで一括表示

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

入力内容にタグは利用できません。

他人を中傷する記事は管理者の判断で予告無く削除されます。
半角カナは使用しないでください。文字化けの原因になります。
名前、コメントは必須記入項目です。記入漏れはエラーになります。
入力内容の一部は、次回投稿時の手間を省くためブラウザに記録されます。
削除キーを覚えておくと、自分の記事の編集・削除ができます。
URLは自動的にリンクされます。
記事中に No*** のように書くとその記事にリンクされます(No は半角英字/*** は半角数字)。
- No123 → 記事No123の記事リンクになります(指定表示)。
- No123,130,134 → 記事No123/130/134 の記事リンクになります(複数表示)。
- No123-130 → 記事No123～130 の記事リンクになります(連続表示)。

Name	/
E-Mail	/
└> 関連するレス記事をメールで受信しますか? / アドレス
Title	/
メッセージ中には下記URLと同じURLを書き込まないで下さい
URL	/
Comment/ 通常モード->　図表モード-> (適当に改行して下さい/半角10000文字以内) ■No533に返信(ONnojiさんの記事) > ジェダイの桐さん > >>記事全て読ませて頂きました。 > > ありがとうございます。 > >>8つの黄金律解説を読んで、身の回りでは >>　Amazon >>　ユニクロ >>の登録画面、がこの黄金律の条件を達成しているのかな？ >>と感じました。 > > ｗｅｂページのデザイナーならば、ベン・シュナイダーマンの［８つの黄金律］は常識だと思いますよ。 > > しかし、もはやこれは古典となっているので、敢えて［８つの黄金律］と呼ばないことも多いと思います。 > >>私自身が桐で即対応出来そうな事は > >>　１．一貫性をもたせる( Strive for consistency ) >>こちらです。 >>これは、作成する時に気を付ける事が出来れば達成出来そうだからです。 > > そうですね。 > > 一貫性が大事ですね。難しい事ではありませんよ。 > >>２～８は今の私の力量では、真似事　.or　対応不可　かなと感じました。 >>但し、設計する上での8つの黄金律を基本概念として開発するだけでも >>今までより、使用者にとって使いやすい物が作れると思います。 > > プログラミングというと理数系と思う人が案外と多いですが、 > > 桐やエクセルのプログラミングは、 > > 純粋なコンピュータサイエンス（計算機科学）ではありませんので、 > > 基本制御構造を知っていれば足ります。 > > そして、最も足らないのがユーザインタフェースの部分です。 > > だから、「プログラミングは心理学である」と言っても言い過ぎではありませんよ。アハハハハha > >
File	/ アップ可能拡張子=> /.gif/.jpg/.jpeg/.png/.txt/.lzh/.zip/.mid 圧縮ファイル[lzh,zip]は、事前に解凍してご利用下さい。 1) 太字の拡張子は画像として認識されます。 2) 画像は初期状態で縮小サイズ250×250ピクセル以下で表示されます。 3) 同名ファイルがある、またはファイル名が不適切な場合、　　ファイル名が自動変更されます。 4) アップ可能ファイルサイズは1回200KB(1KB=1024Bytes)までです。 5) ファイルアップ時はプレビューは利用できません。 6) スレッド内の合計ファイルサイズ:[42/500KB] 残り:[458KB]
パスワード	/ 半角小文字で「ケイ・アイ・アール・アイ」を入力
削除キー	/ (半角8文字以内)
解決済み! BOX/ 解決したらチェックしてください!
プレビュー/

- Child Tree -
- Antispam Version -