それで、私は多くのタスク項目のリストを実行する内部アプリケーションを開発している状況にあります。それらのいくつかは複数のステップを持っています。タスク項目ごとに、プログレスバーもあります。まあ、これらのステップがどれだけ速く発生するかを考えると、一部のプログレスバーは0%
から100%
すぐに。
さて、私の「明るい」アイデアは、バックグラウンドジョブを少しだけ遅くして、ユーザーが進行状況の滑らかなアニメーションを見ることができるようにすることですが、ジョブが大幅に長くかかることはあまりありませんでした。
質問:
これは許容できる方法ですか?または、これは商用アプリケーションで使用されるものですか?これを行う(または行わない)ことをお勧めしますか?
スレッドをスリープ状態にするだけでバックグラウンドジョブを遅くするつもりです...一度に50ミリ秒。
現時点では、進行状況のフィードバックUIを変更しても意味がありません。これにより、この問題を完全に回避できる可能性があります。したがって、この質問のために、各タスクにプログレスバーが関連付けられていると想定します。
UXエキスパートは、アニメーションをスムーズにするためにジョブを遅くすることについてどう思いますか?
これは非常によく似た質問です ですが、私の質問に完全に対応しているようには思えません。
Aadaamによる回答 は、私が何をしようとしているかを考えていました。私はこの方法が受け入れられるかどうか疑問に思っています(それを実装する方法ではありません)。ただし、実装してそれを許容する特定の方法がある場合は、共有してください!
編集:
質問を読み直すと、あらゆる種類のアプリケーションについて話しているように見えます。おそらく私はそれを明確にする必要があります:
- (全体として)ジョブは15分以上かかる可能性があります。
- ユーザーにとって、何が起こっているのかを正確に把握していることが重要です。表示される情報は、開発者だけでなく、ユーザーにとっても有用です。
@Yakoと同じように考えていました:
タスクを遅くするのではなく、Niceユーザーエクスペリエンスを個別に提供する方法について考えます。
私のおすすめ:
タスクを実行して進捗状況を測定するだけですが、更新された進捗状況をすぐに表示するのではなく、よりスムーズな処理を行います。たとえば、バーの最大速度を定義します。
したがって、バーが完了するのに1秒かかる場合に十分に滑らかに見えると思う場合は、実際の基本的な進行状況に関係なく、10ミリ秒ごとに最大で1%フィルアップするようにビルドできます。
補足:もちろん、これは、ユーザーが処理がいつ完了したかを示す一般的な指示が必要な場合にのみ有効です。ステップが完了したかどうかに基づいて決定/確認する必要がある場合、1秒の遅延は許容できない場合があります。
この方法は、独立したタスク、または1秒以上かかるタスクには特にいいと思います。それ以外の場合は、タスクごとに最大1秒の累積表示遅延が発生するため、混乱を招きます。
ルートレベルの進行
サブタスクが非常に速く完了する場合、より良いアプローチは、プログレスバーをルート要素に移動することだと思います。
または、完全にテーブルの外(オプションの場合)により、サブタスクが失敗した場合などに別のアイコンを使用することもできます。
進行状況バーは、何か時間がかかる可能性があることをユーザーに通知するため、進行状況バーを100%で非表示にして、WordをDONE
に変更することもできます。
すべてのタスクがDONE
で始まる場合、すごいです。友達全員にあなたの速さを伝えなければなりません。
いいえ、仕事を遅くしないでください。
何かを即座に100%完了させることに問題はありません。アプリは実際にはbetterのように見えますが、これは、進行状況バーのアニメーションが見えるように速度を落とす場合よりもです。
ユーザーは、すべてが即座に実行されること以外に何も望んでいません。
結局、知覚できる進歩は良い考えかもしれないと思う:
それが0から100に直接ジャンプする場合、それは本当に機能しましたか?バグじゃなかったの?
ただし、実際にジョブを遅くするのではなく、ユーザーによる認識だけを重要にすることが重要です。
そこで、その場合に実装すると思われるいくつかの機能を次に示します。
そうすることで、プロセス全体を100ミリ秒以上遅くすることなく、進行を感知できます。
遠くまで行って、ここですべてのユーザーに代わって話したいとは思いませんが、実行中のタスクよりもスムーズなプログレスバーアニメーションを選択するかどうかはわかりません。
私はタスクが基本的に時間をかけないのを見て完全に幸せだと思います。実際、インストールまたは他の段階的なプロセスを見ているとき、1つのアイテムが0%から100&に直接進んで完了するまで、私はそれを気に入っています。
プログレスバーは、タスクが1〜2秒以上かかり、UIの変更が表示されない場合に、実際に何かが起こっていることをユーザーに示すための単なるフィードバックツールであることを忘れないでください。
20年前、Macintoshシステム6.0.5以前の時代(またはWindows 3.1の反対側から来た場合)は、プロセッサが一般的に十分に高速でなかったため、今日では、subの単純なタスクと見なされます-二回目。したがって、ユーザーの快適さのために、(即時の)タスク完了のフィードバックがなく、実際にはシステムがタスクを完了しようとして混乱していたときに、システムがクラッシュしたという恐れを和らげるために、プログレスバーが生まれました。
今日、私たちはユビキタスプログレスバーに非常に慣れてきており、それがなくても裸で感じることができます。
進行中 UIフィードバックツールを表示するために、(ゲームプレイに有害な影響がある場合を除き)タスクをスローダウンしないでください。ユーザーは、UIを見ることなく、最終結果を望んでいます。それに直面して、それはタスクが十分に遅れている、彼らはおそらく紅茶/コーヒーのカップを作るために行ってきました(上司の悔しさにほとんど)。
要するに、タスクが完了するまでに1秒もかからない場合(そしてティック、または「DONE」メッセージは、タスクが完了したことを示している場合)、進行状況バーは廃止され、単にかなりのUI要素に降格されます。 UIにその標準的なルックアンドフィールを持たせます。
@ DaveAlgerのメソッドと同様に、行にも色を付けることができますを追加します。何が終了し、何が終了していないかが一目ですぐにわかります。
これに対する正しい答えは、ユーザーの期待に依存すると思います。
非常によく似たものがありました。実行するプロセスの数はさまざまでした。全体的な進行状況バーしかありませんでした。プログレスバーが表示される前に、すべてのジョブが完了します。ユーザーは「何度も実行したが何もしなかった」などのコメントを残した。
私の解決策は、個々のプロセスを遅くすることではなく、プロセス間にわずかな遅延を置き、プロセスがすべて完了したときに0.5秒の遅延を設けることでした。これでユーザーは進行状況を確認でき、遅延を含むすべてのプロセスが約1秒で実行されます。みんなが幸せだ。
これは、小さなステップが多いジョブのオーバーヘッドを軽減するための問題です。
問題は、多くの小さなファイルのそれぞれについて、プログレスバーが0〜100%点滅することです。 bootstrapローダー(とりわけbootstrapをロードする)ローダー)を持っている自分のSPAアプリの1つでも同様の問題があります。jquery-uiは巨大です、何十ものヘルパーとポリフィルはそうではありません。
進行状況バーのポイントは、進行状況を示すものではありません。それは、物事が計画通りに進んでいることをユーザーに安心させ、遅延から注意をそらすことによって遅延の知覚を緩和することです。進行状況の更新頻度を安定した1Hzにすることで、醜いちらつきや途方もない表示更新オーバーヘッドを課すことなく、これらの目標を達成できます。しかし、これを行う方法は?
Nagleのアルゴリズムは、Telnetセッションと基本的に同様の問題を解決するために発明されました。小さな更新が多すぎると、オーバーヘッドが大きくなります。キーが押されるたびにキーストロークメッセージを送信すると、すべてのネットワーク往復遅延とともに、1バイトメッセージの40バイトヘッダーが表示されます。小さなファイルごとにプログレスバーを更新すると、ちらつきやDOM更新の輻輳が発生します。
Nagleは、タイムアウトと最大バッチサイズの両方でバッチ処理することでこれを解決します。タイムアウトと最大バッチサイズのサイズを適切に設定することで、許容可能な最大遅延で安定した更新率を実現できます。詳細が必要な場合は、RFC896に完全に文書化されています。
単位時間あたりの平均アイテムを見つけるには、実際のパフォーマンスを測定する必要があります。うるさくなりすぎないでください。指標値のみが必要です。1つまたは2つの項目が実行を支配することによってそれを歪めている場合、それらを測定から除外することができます。たとえば、282アイテムで60秒かかるが、そのうち2つで40秒かかる場合、レートは280 / 20 = 14
1秒あたりのアイテム数。
したがって、この場合、タイムアウトが1000ミリ秒、最大バッチサイズが14の場合、1 Hzの進行状況の更新が安定して生成されます。ユーザーを心配するほど遅くない、ブラウザを心配するほど速くない。
スムーズなアニメーションのために仕事を遅くすることはありません。
これはどのように見えますか:
1)サークルローディングを試してみて、数字を一緒に避けてください。物事は非常に速く動くと思います。問題がある場合にのみフィードバックを表示できます。画面の乱雑さが少ない利点。
2)4つのローディングバーを作成する代わりに、メインタスク用に1つを作成できます。たぶん今度は(Sub task 1 completedなど)のようなテキストフィードバックと、ロードバーの視覚的な手掛かりを上部に表示します。これは、ジョブの速度を低下させながら、常にユーザーに通知するのに役立ちます。
言うまでもなく、進行状況バーのスムーズな移行を示すためだけにジョブをスリープ状態にしないでください。 UXはアプリのUIコンポーネントだけではなく、アプリがあらゆる観点から集合的に喜びを提供する方法であり、効率性はその1つです。開発者(またはあなた)は、より短い時間でタスクを完了するために素晴らしい仕事をしたので、UIコンポーネントがその作業に影響を与えないようにしてください。多くの優れたソリューションがUXの天才によってすでに提供されています。Outlookでアカウントを作成するときに、MS Outlookアプリのスクリーンショットを追加したいだけです。参考になると思います。
タスクがすぐに発生する場合は、迅速かつスムーズなアニメーションを提供します。一度にこれらのダースが発生した場合、すべてのバーが同時にスムーズにアニメーション化できます。スムーズなカーブを使用して、開始が遅く、スピードが上がり、終了が遅くなるようにすることをお勧めしますが、アニメーションの持続時間はせいぜい0.5秒程度にすることをお勧めします。このように、滑らかに見えますが、基礎となるアプリケーションの速度が低下することはありません。ユーザーに不必要に待機させることは非常に悪い考えですが、コンテキストで進行状況バーを表示する必要があると思われる場合は、アニメーション自体をスムーズにするだけの方が良いでしょう。
妥協しないでください。 独自の目的のために最適化された2つのアニメーションがあります:
このようにして、すべての世界で最高のものを手に入れます: