ユーザーアクションによってトリガーされる同期プロセスがあり、プロセスに10分以上かかる場合があります。
処理中は、ユーザーがトリガーした以前のUIと表示された以前のデータはブロックされ、ユーザーはそれにアクセスできません。
このような動作をするシステムのリファレンスを知っていますか?
ユーザーインターフェイス設計の主な理念の1つは、ユーザーがコントロールしていると感じる必要があること、そしてほとんどの場合、ユーザーが自分の時間をコントロールしていることです。
システムの遅延に対処するには、基本的に次の方法があります。
通常、1つ目は約10秒未満で実行されるタスクに使用され、2つ目は最大で1〜2分実行されるタスクに使用され、最後は1分以上実行されるタスクに使用されます。
アクティブな待機時間とパッシブな待機時間を区別する傾向があり、アクティブなユーザーは他の何かを実行する権限を与えられます。
長時間実行されるタスクの例は、急流のクライアント、またはYouTubeビデオのアップロードにあります。これらのほとんどは進行状況を示しますが、タスクが終了したときにも通知します。
タスクの実行量がわからない場合があるため、他の方法で進捗状況を示します。これは、ウイルス対策ソフトウェアの場合で、残りの量ではなく、すでに実行されている量を示します。一部のソフトウェアでは、各要素の処理時間が均一でなくても、要素の総数から既に処理された要素の数がわかります。多くのアプリケーションは必要な時間を推測しようとしますが、実際にはさらに時間が必要な場合にユーザーを失望させることがよくあります(通常:YouTubeのアップロードは95%に達するのにかかった時間の2倍の時間で95%のままです)。
それにもかかわらず、次のことをお勧めします。
これを行う方法は、モーダルレイヤーを使用してウィンドウを無効にし、処理が行われていることを通知することです。これには少なくとも10分かかるため、午後8時43分に開始した場合、結果は予期しないものであると伝えます。午後8時53分より前。また、このウィンドウを閉じて、ユーザーインターフェイスのさまざまな部分にフォーカスする方法を提供します。
このウィンドウにつながるUI要素は、処理が行われていることと、それがいつ期待されるかを伝えます。
何らかの形式の通知(少なくとも、可聴の「Ding」)は、UI要素が変更されたプロセスの終了時に送信され、指定された画面領域またはメソッドに何らかの形式の通知が表示されます。
「パフォーマンスが重要な理由」と呼ばれるアプリケーションでの時間管理に関するDenys Mishunovによる一連のすばらしい記事があり、最後の部分はここにあります。
https://www.smashingmagazine.com/2015/12/performance-matters-part-3-tolerance-management/