アプリケーションはどの時点でカーソルを砂時計に変更するか、進行状況バーを表示しますか？
[〜＃〜] wpf [〜＃〜] デスクトップアプリケーションがさまざまなタスクを実行します。一般に、各タスクの平均時間は、基本的に瞬時から数秒以上（場合によっては数分）までの範囲です。
カーソルを砂時計に変更して処理を示し、より長いタスクの場合はインターフェイスに進行状況バーを表示するタイミングを決定するための標準を確立しようとしています。
これらのしきい値は秒単位でどこにありますか？ユーザーはどの時点で何も起こっていないと考え、進行状況が報告されないことに苛立ち始めます（これは避けたいものです）。
覚えている0.1、1.0、10秒...
約1秒somethingで、それが完成した結果であるか、コンピュータが動作していることを示すインジケータであるか（通常、何らかのタイプのスピナー）
ユーザーがアクションを開始してから1秒間何もしないと、アプリケーションの動作が遅くなる可能性があります（下記のコメントに記載されています）。スピナーをゆっくりとフェードインさせながらすぐに表示して、ユーザーに即座にフィードバックを提供したいです。
フェードインするスピナーのデモ
ただし、スピナーは非常に長い間しか機能せず、10秒以上かかる可能性のある操作には、開始したタスクが完了することをユーザーに知らせるためのより高度なメカニズムが必要です（進行状況バーなど）。
これを裏付けるデータは次のとおりです...
応答時間に関する基本的なアドバイスは、30年前とほぼ同じです[Miller 1968;カード他1991]：
- 0.1秒は、システムが瞬時に反応していることをユーザーに感じさせるための制限です。つまり、結果を表示する以外に特別なフィードバックは必要ありません。
- 1.0秒は、ユーザーが遅延に気づいたとしても、ユーザーの思考の流れが中断されないようにするための制限についてです。通常、0.1秒を超え1.0秒未満の遅延の間は特別なフィードバックは必要ありませんが、ユーザーはデータを直接操作する感覚を失います。
- 10秒は、ユーザーの注意をダイアログに集中させるための制限とほぼ同じです。より長い遅延の場合、ユーザーはコンピューターが完了するのを待っている間に他のタスクを実行する必要があるため、コンピューターがいつ完了するかを示すフィードバックをユーザーに提供する必要があります。遅延中のフィードバックは、応答時間が非常に変動する可能性が高い場合に特に重要です。ユーザーは何を期待するかわからなくなるためです。
ソース： Neilson Norman Group
DaveAlgerの答えは問題をほぼカバーしているようですが、プロセスがプログレスバーを表示するように接続されている場合は、すべての場合にすぐに表示することもできます。
砂時計は、「予期していなかった何かに時間がかかっている」と言います。プログレスバー-偽の理髪店の種類-でも、「これにはしばらく時間がかかりますが、それが起こる可能性があることはわかっていました」と言います。 0.5秒後にプログレスバーが消えれば、もちろんそれはさらに良いことです。
1秒は仕事で長い時間です。 400msの方が良いかもしれません。これよりも長いと、「遅延」として識別されることが多く、パフォーマンスに問題があります。約20年前に私が取り組んだアプリケーションの1つは、極端な場合に到着するまでに通常15〜25秒かかるサーバーからのトランザクションデータを待っていました（9600b/sマルチドロップライン）。関係するウィンドウでは、プログラマーは砂時計（アニメーションの文字盤）をまったく上げていませんでした。より長いトランザクションでは、PCがハングしたと想定して10秒待った後、一部のユーザーがrebootingであることがわかりました。すぐにそれを置くことはユーザーの不安をかなり減らしました。
それはもっと簡単な選択ではないでしょうか？
スピナーまたは回転砂時計。つまり、操作の長さが、制御外の要因、ネットワーク遅延などによって定義されていない操作用です。
定義された操作の進行状況バー。つまり、データベースから480レコードを読み取る必要があり、これを読み取り率のパーセンテージに簡単に変換できます。
スピナーはもう少しふんわりしているので、長い操作のフィードバックや予想よりも時間がかかった場合のキャンセル機能にフィードバックを提供せずに、その使用をお勧めします。
それはすべて相対的です。それが何百万ものレコードを持つデータベースアプリケーションである場合、ユーザーは異なる期待を抱くはずです（すべきです）。
私のアプローチは、1秒より長くかかる可能性があるものに対しては、1秒後に砂時計を表示することです。見た目をすっきりさせたい。
10秒以上かかる可能性のあるタスクであり、実際の進行状況（50％など）を表示できる場合は、実際の進行状況バーを表示します。
難しい（長い）と思われるいくつかの検索条件があり、ユーザーに前もって警告を与えます。これはより長い検索になると思います。
10秒以上かかるタスクの場合は、キャンセルする機会を与えてください。間違った検索を入力した可能性があり、奇妙な検索のために長い時間がかかります。 10秒以上かかる可能性が高く、キャンセルするオプションがない場合は、警告を出します。
X秒後に自動的にキャンセルするオプションをユーザーに提供します。私のアプリケーションでは、検索が困難になる場合、別の方向から検索を行うことがよくあります。
最初にカウントを返すようにタスクを分割できますか。いくつかの一括操作があり、最初にカウントを返し、それが1000を超える場合、Xレコードを処理してもよいかユーザーに伝えます。これにはしばらく時間がかかります。デモでは、人がめちゃくちゃになり、1,000,000レコードを超えるライブラリ全体のワークフローを作成するのを見て、10分で終了しました。これは、その数のレコードでは高速ですが、デモでは1時間のように感じました。
毎回2〜3秒かかる一般的な操作が1つあります。そのため、私は砂時計を表示しません。