web-dev-qa-db-ja.com

精査できない重要な入力をどのように検証しますか?

入力を精査する実用的な方法がない場合、ユーザーが誤った入力セットを作成するのをどのように防ぐのですか?

シーン

VisualFoxProで記述された小さなERPパッケージを変更します。パッケージの一部は、配達ルートでドライバーと一緒に送信されるトラックのマニフェストと請求書の印刷に関係しています。入力として何もない場合は、すべてを印刷しようとするため、高速プリンターで無駄になる大量のプリンター用紙が発生します。

私はGUIインターフェース要素を書き直す立場になく、この状況で使用されるフレームワーク、ツールキット、またはその他の外部コードを適応させることもできません。理由はオフィスの政治に関連しています。既存のERPフレームワークをオーバーライドできるとは言わないでください。これは私には選択肢がないためです。

問題

ユーザーは、高圧でタイムクリティカルな環境にいます。各プロセスは数分または数秒で測定されます。つまり、処理時間をできるだけ最小限に抑える必要があります。この環境と気が散る可能性があるため、ユーザーは頻繁にダイアログを無視し、[Enter]キーを押すと、フォーカスがフォーム内をすばやく移動し、最終的に入力ダイアログのアクションボタンに到達します。その結果、自動印刷がトリガーされます。

入力は、日付範囲、ルート範囲、および受注範囲で構成されます。

頻繁なバックプリントが必要なため、日付範囲の入力を「今日の日付」に自動設定することはできません。また、エンドユーザーは真夜中に作業します。つまり、日付のロールオーバーにより、変更を自動検出するルーチンを不正に操作することなくこれを非現実的にすることができます。

ルートの入力はハードコードできません。また、再印刷が必要なため(上記を参照)、すでに出荷されているルートからそれを推定することはできません。

販売注文の入力は、単一の注文または特定の範囲を印刷する場合にのみ意味があります。

したがって、率直に言って、入力を検証する実用的な方法はありません

印刷をトリガーするアクションボタンはブロックできません。ブロッキングダイアログをユーザーの前に配置するという提案はすべて無視されます。私はこれがオプションではない理由を議論する自由はありません。ただし、コンセプトはサイトの別の場所で(別の視点から)すでに議論されており、拒否されました。

すべての入力が空のときにプリントアウトをブロックすることは、ソフトウェアがこれを機能として受け入れるため、設計上の決定として拒否されました必須

ユーザー

ユーザーはこれをしないように繰り返し求められてきました。彼らはしばしばこのアドバイスを無視します。この不幸な出来事を引き起こすことは彼らの職長/マネージャーが対処するものではないので、行動を終わらせる圧力はありません。

組織

関係するワークフローには発言権はなく、そのワークフローによって影響を受ける既存のソフトウェアコンポーネントの変更のみです。

提供事業者

ベンダーは、元のソフトウェアベンダーからカスタムインストールとしてパッケージをセカンドソースします。ベンダーは、コードベースに統合するために、すべてのコード変更をベンダーに返送することを要求しています。アーキテクチャに大幅な変更を加えると、広範なカスタマイズが行われるため、バージョンの移行中に将来のコストが増加します。場合によっては、プログラマーは、そのような大きな変更を完全に無視し、好きなように行うと私に言ったことさえあります。

ソフトウェア

ソフトウェアの選択やインストールについては何も言えないので、プラットフォームを変更することは問題外です。

ソフトウェアの環境に関しては、印刷される各請求書は1回の呼び出しです。バッチ印刷機能はありません。また、印刷機能がシステムに統合されているため(および一部の言語の癖も)、そのAPIの周りにバッチラッパーを作成することはできません。これに加えて、プログラムのこの部分は、請求書の印刷を行う別のプログラムを呼び出します。このプログラムは、単一の請求書を印刷するレポート印刷APIを呼び出します。恐ろしいデザインですね。

入力フォームは、入力ボックスがないフォームヘッダーの奇妙な組み合わせですが、他のGUI要素を含めることができます。入力ボックスは実行時に定義されます。

目的

ソフトウェアは、ユーザーが誤ってすべての書類を印刷することを防ぎます。

この問題をどのように解決しますか?

8
Avery Payne

これは簡単です。すべてを空白のままにすると、すべてを印刷するように求められますが、そのプロンプトでのデフォルトの選択はキャンセルする必要があります。

値を入力した場合は、要求したものをすべて印刷します。

このようにして、フォームを誤って燃やしてすべてを印刷することはありません。彼らは燃え上がり、何も印刷しません。すべてを印刷するには、一時停止して印刷し、プロンプトでの選択を[キャンセル]から[OK]に変更する必要があります。

25
CaffGeek

何かを修正する必要があるように思えますが、解決策を提案するたびに(そしてリストに良いアイデアがたくさんあると)、それは打ちのめされます。

これは、プッシュバックする必要があるポイントです。 「これは間違っています。修正してください」という漠然とした考えは必要ありません。必要なのはスペックです。 doしたいことを正確に修正したい人に尋ねてください。これまでのところ、あなたが持っているのはdo n'tしたいことだけです。それだけ簡単です。何もしないでください。そうすれば、あなたはしません彼らが望まないことをします。変更を加えたい場合は、前向きで具体的なルールを考え出す必要があり、実装することを伝えます。

27
Mason Wheeler

もっと一般的な質問に答えようと思います:ユーザーが災害やキャンセルや元に戻せない何かにつながるミスを避ける方法(ユーザーが印刷することを予期していなかったいくつかのページを印刷して紙を無駄にするようなものです)。

元の質問で述べたように:

ユーザーは、高圧でタイムクリティカルな環境にいます。各プロセスは数分または数秒で測定されます。つまり、処理時間をできるだけ最小限に抑える必要があります。

この意味は:

  • ソフトウェア製品は、従業員の生産性を向上させるために最善を尽くす必要があります。1秒ごとに数えるとき、ユーザーエクスペリエンスと生産性は一般的な製品よりもさらに重要です、一部の機能で数秒の損失が発生しても、あまり頻繁に使用しない場合は許容されます。

  • ユーザーは忙しすぎてソフトウェア製品に注意を払うことができません。穏やかな環境で、前回使用したMicrosoftWordの機能を使用する場合1年前、Microsoft Wordが質問をし、私の選択の結果がどうなるかを説明する場合、質問を読んだり、ドキュメントを読んだりすることもできます。あなたの場合、あなたはそれを買う余裕がありません。ユーザーには読む時間がない。

メッセージボックス:いいえ、いいえ、...いいえ!

すでに説明したように 他の回答では の場合、メッセージボックスはほとんどの場合、2つの理由で悪です(詳細については、Alan CooperによるFace 3についてを参照してください)。

  • 「オオカミ!」と叫んだセリフ原則として、アプリケーションが同じダイアログを頻繁に表示する場合は、ユーザーに注意を払わずにダイアログを繰り返し閉じるように促します。

  • ダイアログはワークフローを妨害します。ダイアログはこのフォーカスを奪い、ダイアログが閉じるまでアプリケーションとの対話が中断されるため、ユーザーはアプリケーションに集中できません。

これは、ダイアログボックスが絶対的な悪であることを意味しますあなたの場合 UXの観点から:それらは却下され、毎秒が重要な環境で生産性を低下させます。

他の意味

質問によると:

  • "入力は、日付範囲、ルート範囲、および販売注文範囲で構成されます。"

  • 間違った値はないため(たとえば、ユーザーは最初のフィールドに前の日付、将来の日付、または今日を入力できます)、検証はできません。

  • "入力として何も入力されていない場合、印刷ルーチンはすべてを印刷しようとするため、高速プリンターで無駄になる大量のプリンター用紙が発生します。"

  • デフォルトのデータを使用して印刷するように依頼することは完全に可能です。

より一般的な用語では、それは次のことを意味します。

  • デフォルト値がありますが、これは実際に有効ですが、

  • ユーザーが変更しようとしているときに、誤ってデフォルト値を保持したまま「印刷」ボタンを押してほしくない。

試すことができるいくつかのテクニックは次のとおりです。

1。魔法の元に戻す

はい、ユーザーはタイムクリティカルな環境にいます。はい、プリンタが印刷を開始すると、停止することはできません。しかし、まだできることがあります。

タイムクリティカルな環境であっても、たった今印刷しても5秒で印刷しても何も変わらない可能性があります。

ユーザーが[印刷]をクリックすると、小さな[元に戻す]ボタンが表示されます。これは、Gmailが誤ってすべてのメールを削除するように要求したときと同じです。 。 5秒間待ちます²。 「元に戻す」を非表示にしてから、印刷します。

これで、ユーザーは間違いに気づき、実際に害が及ぶ前にキャンセルすることができますが、印刷されるのはわずか5秒の遅れです。

2。個別の「デフォルト値」の背景

デフォルト値が疑わしいですか?³1つの値で、疑わしいことはほとんどありません。 3つを使用すると、ユーザーがデフォルトで3つすべての値を保持する必要がある場合は非常にまれです。

この場合、次のことができます。

  • デフォルト値のある値を強調表示します。赤ではない:赤は無効な値を示します。黄橙色に設定し、ユーザーがデフォルト値を変更すると白に戻ります。

  • または値が変更されるまで[印刷]ボタンを無効にします。近くにチェックボックスを追加します。ユーザーは、チェックボックスを使用して印刷することを確認できます。デフォルト値。

3。コントロールのUIを強化します

私たちは金曜日です、6番目 今日の2012年1月の。次の木曜日の日付はいつですか?すばやく、すばやく、プレッシャーにさらされています。答えは1秒しかありません。また、あなたは疲れていて、周りにはたくさんの騒音があります。答えにくいですね。

_1/8/1012_と書かれていると、人々は日付を簡単に操作できません。 Saturday, 7th of January (tomorrow)は少し簡単です。土曜日と日曜日を強調するグラフィカルビューは今日を示し、オフセットはさらに優れています。

「場所:ニューヨーク」ほど醜いものはありません。これらの3文字は、疲れてストレスの多い環境で作業しているときは意味がありません。間違いは簡単です。代わりに、ニューヨーク市の赤い点を示すアメリカ合衆国のグラフィカルマップのほうがはるかに魅力的であり、ユーザーはそれに気づく可能性がはるかに高く、彼はサンフランシスコを選びたかったのですが、赤い点が間違った場所に表示されているようです。

enter image description here

GPSで38.90403、-77.04878から38.90568、-77.04665に移動し、次に右に曲がって38.90565、-77.04345に移動し、次に90°左に曲がって38.90660、-77.04345に移動する必要があると通知されたら、楽しんでいただけますか?あなたは自分の仕事(道路)に集中することができますか?忙しいユーザーに1/8/2012とNYCを表示することは、色の完全なマップの3Dビューの代わりに生の座標をスローするGPSと同じくらい親しみやすいです。

より豊富なコントロールとデータの豊富な視覚化を提供することで、ストレスの多い環境でのユーザーのミスのレベルを減らすことができます。


¹ところで、これはダイアログボックスの他のバリアントにも当てはまります。以前、ボタンがランダムになり、閉じるのが困難になるダイアログボックスについて質問しました。悲しいことに、そのようなアプローチは役に立ちませんが、害を及ぼすだけです。ユーザーはダイアログの発言を却下しますが、ダイアログを閉じて作業に戻るのに時間を費やします。

²例として5秒と言います。ユーザーが[元に戻す]をクリックする速度を確認するには、数か月間のユーザーのアクティビティを監視する必要があります。 1秒未満になる可能性があります。遅延が0.6〜1.8秒であることがわかります。平均1.1秒で、「元に戻す」を2秒間表示してから、印刷することができます。

³お願いします、お願いします、ノーと言ってください!もしそうなら、それはあなたのデフォルト値に何か問題があることを意味するからです。たとえば、日付のデフォルト値が今日である場合、75%の場合、ユーザーはそれを明日、10%は昨日、10%は明後日を設定する必要がありますが、デフォルトを設定する必要があります。明日への価値。

10

印刷する前に何ページ印刷するかを決定したり、他の方法で出力のサイズを測定したりできますか?その場合、通常の使用の最大サイズを決定し、それよりも大きい場合は、出力サイズを示す確認ダイアログを使用します。読み取りなしで閉じることができないため、ユーザーは出力サイズを入力して確認する必要があります。

3
JGWeissman

問題の説明をさせてください。

現状:やみくもに押す Enter 一連の用紙が印刷されます。

望ましい状態:盲目的に押す Enter 一連の用紙は印刷されません。

解決策:やみくもに押すようにソフトウェアを変更します Enter 何かをします、何か、紙の連を印刷させる以外に。

その代わりに、代わりに何をすべきかという問題が残ります。個人的には、オペレーターに何が欲しいか聞いてみます。私の推測では、まだ印刷されていない最も緊急の請求書を印刷するようなものです。すべてを印刷する機能はそのままにしますが、そうするためには意識的な決定が必要です。

2
Karl Bielefeldt