段階的な検証と開示
私はプログレッシブ検証の例を見つけようとしています。ビジュアルエディター用のUIがあり、ユーザーはピクセルまたはパーセントで寸法を示します。
エディターのプロパティは一連のタブにあるため、すべてのフィールドが同時に表示されるわけではありません。このUIで検証を実行する方法と方法については、すでに説明しています。
私は次のような見方をしています。a）検証は、ユーザーがソフトウェアの期待を学び、必要なものを「改善」できる通信チャネルを作成するため、有用です。 b）変更が必要なものをユーザーが視覚的に確認できるように、（要約が他の場所で使用されているかどうかにかかわらず）入力フィールドの検証エラーを直接示すことは常に優れています。
私の同僚は、私が最も尊敬していること以外は何も考えていません。彼のロジックは次のとおりです。a）特定のタイプのエントリを防止するか、または一部のエントリの場合は、無効な場合はより適切な値に変更する方が便利です。たとえば、誰かが100より大きいパーセンテージ値を使用した場合、UIはフォーカスが失われたイベントで値を100にリセットします。 b）タブ環境であるため、一部のエラーはユーザーには表示されません。 「多くの」検証エラーが発生する可能性があるため、要約を使用しても無駄です。
これを回避する解決策は、無効な値を徐々に開示することだと思いました。ユーザーが誤っている可能性のある値を入力すると、それらはある種の要約でフラグが付けられます。概要により、ユーザーは問題のフィールドを表示することなくナビゲートできます。
私は元々の人だったらよかったのですが、ここには前例があるはずです。私の質問は次のとおりです。
私または私の同僚の視点に追加するものはありますか？
プログレッシブ検証を行う複雑なエントリを持つこのようなUIの例はありますか？
現在、デスクトップベースのアプリでは同じ問題に取り組んでいますが、タブベースではありません。あなたはこのようなアプローチを試すことができます：
ユーザーの注意が必要な場合に小さなアイコンが表示されます。おそらく2色を使用することもできます。黄色は警告用、赤色はmustをユーザーが先に進む前に修正する必要がある場合に使用します。
この複雑な状況でできる最善のことは、できる限り多くのUIのプロトタイプを作成することと、ユーザーベースでテストして、何が起こるかを確認します。 HTMLをjQuery UIのようなものと組み合わせて使用すると、多くのインタラクティブなコントロールをすぐに利用でき、すばやくテストする準備ができます。
タブシステムは複雑に聞こえるので、簡略化するためにいくつかのことを提案する必要があります。
- 各タブ内に「適用」ボタンを作成して、ユーザーが現在表示できるプロパティについてのみ状態を保存できるようにします。その結果、アプリケーションの状態が無効になる場合は、タブを再設計して、ユーザーがグループ化されたプロパティを互いに独立して保存できるようにするようにします。
- それができない場合は、「無効な」アイコンと色でタブを強調表示して、そのタブのプロパティに注意が必要であることを示します。タブが無効である間、「適用」ボタンは無効になります。まだエラーがあることを示すメッセージが表示されるようにボタンをクリックした場合は、ボタンに通知を追加することを検討できます。何が問題なのかという要約は、包括的な要約ではなく、各タブ内に表示されます。
- グローバルサマリーは機能するかもしれませんが、すぐにわかりやすい場所がないので、そうでないとユーザーが気付くので、提案するのをためらっています。
- プロパティはどのようにグループ化されますか？おそらく機能的ですか？たとえば、使用の可能性など、別の角度から見てください。これは、MicrosoftがOffice 2007製品のリボンデザインに取り組んだ方法の一部です。おそらく、ほとんどのユーザーが最初の、またはすぐに表示されるタブのプロパティを変更するだけでよく、他のタブは「詳細」またはコンテキストと見なされるようにタブを設計できます。
結局、私はすでにこれを言った、あなたのデザインをテストしてください！ :-)
エラーの処理に関する限り、私の経験では、特定の入力を妨げるとユーザーが混乱することになります。たとえば、数字のみが許可されていることが入力フィールドから明らかではないが、とにかく他の文字を許可していない場合、それはユーザーを苛立たせることになります-彼らはそれらを助けようとしているインテリジェントなフォームとしてそれを経験しません。したがって、イベントと入力検出を使用して自動的に修正するという道を進むことにした場合は、全体を通して明確なマイクロコピーを使用することを推奨します。
しかし、これはすべて逸話的なものです。私はこの分野での調査を行っていません。私の言葉をそれに取って代わるのではなく、Luke Wroblewskiの本 Web Form Design：Filling in the Blanks と、このような状況に対処する方法に関するいくつかの有用な洞察のためのエラー処理に関する彼の研究（たとえば、これは Appleのチェックアウトフォームの再設計の投稿 がエラーの処理方法を詳しく説明しています）。
最近、同様の問題が発生したプロジェクトに取り組みました。昨年の「 Minimizing Complexity 」の記事で、それを解決した方法のスクリーンショットをご覧いただけます。
多くのエラーのまとめが使われているケースや作品のようなものかと思いました。
すべてのIDEのように、Visual Studioのように、コードの作成中に静的分析ツールを作成または使用する場合、無限のエラーが発生する可能性があります。通常、数十または数百のファイルがあり、それらの多くは常に1つまたは2つのタブが表示されているタブ
エラーは、メインUIの下に（デフォルトで）スライドして表示されるスクロール可能なサイズ変更可能なリストにリストされます。これは、エラーがトラップされるとすぐに実行できます。エラーをクリックまたはダブルクリックすると、適切な場所に移動してエラーを修正することができます。エラーが無効になると、リストからエラーが消えます。
（実際には、これらのエラーの多くは、ユーザーが開始したアクションを再評価する必要がありますが、これをバックグラウンドで実行し、実際にコードの編集中にエラーリストを動的に更新する多くの静的分析アドインがあります） 。
a）たとえば、誰かが100より大きいパーセンテージ値を使用した場合、UIはフォーカスが失われたイベントで値を100にリセットします。
良い点ですが、次のことを確認する必要があります。
- ユーザーは、自分の入力が修正されたことに気付きました。
たとえば、値を修正したら、フィールドを1秒間点滅させることができます。 - ユーザーが実際に何を意味しているかを合理的に推測できます。
たとえば、昨日取り組んだカラーピッカーを見てみましょう。いくつかの要素を別のサイトの要素と一致させたいので、16進数の値を取得し、小さなアドホックテキストボックスにコピーして貼り付けました。最初の値は#202040でしたが、何らかの理由で#20204のみを貼り付けましたが、これは#020204にすぐに「固定」されました。私が貼り付けた2番目の値は#BCD（#BBCCDDの省略形）で、これも「#000BCD」に「固定」されています。はぁ。