レポート生成の進行状況を示すプログレスバーを実装する必要があります。問題は、生成によって生成されたイベントに基づいてレポートの進行状況のパーセンテージを表す必要があることですが、最初にイベントの合計量を知る必要がないため、たとえばレポートの生成により、次のイベント (フェーズ) が送信されます。
- Starting Report generation
- Start Query execution
- End Query execution
- Start Report Rendering
- End Report Rendering
- End Report Generation
この例では、合計 3 つのタスクと 6 つのイベントがあります。タスクの総数はわかりませんが、イベントの総数がタスクの数の 2 倍であることはわかっています。
どのイベントが存在し、いくつあるかはわかりませんが、進行状況をプログレス バーで表す必要があるため、0 から 100 までの数値を使用します。
どのように計算できますか？進行を表す最良の方法は何ですか?
おそらく、あなたができる最善の方法は、実際の進行状況バーのアイデアを完全に放棄し、代わりに不確定な進行状況インジケーターを訴えることです。デスクトップ システムでは、このシナリオでは通常、「マーキー」または「跳ねる」プログレス バーが使用されます。
もう 1 つのオプション - 進行状況のようなものを本当に表示したい場合 - は、いくつかのヒューリスティックを使用して、(部分的に) 偽造することです。ここには実際には多くの情報がないため、かなり賢く、実際のケースで多くのテストを行う必要があります。以下にいくつかの提案を示します。
現在処理中のタスクのネスティング レベルに基づいて進行状況を増やします。基本的には、タスクの粒度が細かいほど、全体的な進捗への貢献度が低くなるという考え方です。タスクのネストとは、もちろん、あなたStartとEndメッセージの括弧から暗示される階層を意味します。
期待できるタスクの最大数を合理的に見積もって、完了にどれだけ近づいているかに基づいて、進行速度の増加を調整します。たとえば、予想されるタスク数が 500 以下で、300 タスクを処理したにもかかわらず、すでに 80% の進行状況を表示している場合は、それ以上の増加を真剣に遅らせる必要があります。同様に、遅れをとっている場合は、適切にスケールアップし、進行状況を増分する必要があります。
大きなジャンプは避けてください。前のポイントで説明したように、すぐに追いつく必要がある場合でも、徐々に時間をかけて追いつくようにしてください。具体的な例を挙げると、10% ずつ増加してから 10 秒間静止するのではなく、10 秒間で 1% ずつ 10 回ずつ増加します。
おそらく、他にも試してみることができるテクニックがたくさんあります。全体として、これは非常に興味深い UX と数学に関連する問題ですが、それに認知的な労力を費やす価値があるかどうかを検討する必要があります。ほとんどの場合、不確定な進行状況はまったく問題ないと思います。
基本的に、追跡しようとしている進行状況の手がかりがないため、通常の進行状況バーでは必要なことは不可能です。あなたができることは、マーキー プログレス バー (無期限に進行し続けるプログレス バー) を使用して、アプリケーションがまだ進行中であり、その上または下にあることをユーザーに示すことです。 .