UIをロックする必要がありますか？
従来、レスポンシブUIを設計するための経験則は、UIがロックしないようにすることです。ただし、一部のレコード編集パターンでは、レコードの保存中にユーザーが画面上の内容を編集できるようにしても意味がありません。
例：
ユーザーがレコードを編集
ユーザーヒットの保存
同時
- サーバーがサーバー側のレコードを変更します（ネットワークが非常に遅いため、保存に10秒かかります）
- ユーザーが画面でレコードを編集（保存をクリックした後）
サーバーからの返品の記録
- 画面上のレコードはサーバーからのレコードで上書きされます
上記のシナリオでは、ユーザーが何をしたとしても、画面上のレコードはサーバーから返されるレコードによって上書きされるため、レコードの編集は冗長です。したがって、サーバーが保存アクションを処理している間のみ、UIをロックすることは意味があります。
さらに、ユーザーが成功またはエラーの通知を受け取るまで画面から移動することを許可されないため、メニューレベルでナビゲーションを無効にする必要があります。レコードから移動した場合、エラーメッセージが失われ、変更が失われます。
私の質問はこれに対処するためのベストプラクティスは何ですか？アプリ全体を無効にする必要がありますか？アニメーション化された進行状況インジケーターで画面全体の上にビジーインジケーターを埋め込む必要がありますか？このエクスペリエンスを実現するためのその他のヒントユーザーの邪魔にならない？
ユーザーの入力が無駄になることはありません
サーバーからの応答後にコンポーネントのデータがオーバーライドされることを考慮すると、ユーザーの入力をオーバーライドすることは絶対に許可されていないため、コンポーネントをロックする必要があります。
ロックされた領域を絞り込む
保存要求を処理するプロセスでは、アプリケーション全体を無効にしないでください。ロックされたコンポーネントの数を減らして、ロックをできるだけ少なくするよう努力するのは正しいことです。
ロックの断片化を回避
ロック領域は責任がありますが、狭くする必要があります。断片化しすぎて混乱を招くことはないはずです。サーバーのレコードで上書きされるコントロールの単一の共通ブロックをロックするのが最善です。
ロックを回避できる場合は、それを行う
本物の節約のプロセスはロックを意味するものではありません。
操作後に新しいデータを書き込む必要がある場合、それは保存だけでなく、ある種の計算でもあります。この場合、リクエストの処理中にユーザーをデータ損失から救う方法は他にありません。
それ以外の場合、サーバーで実行される唯一の操作がユーザーの入力データの保存である場合、ユーザーコントロールを上書きするプロセスは冗長であり、ロックの導入の前に、その排除（技術的な制約と予算のために可能であれば）を最初に検討する必要があります。
関連するアクションを無効にするだけ
すべてを無効にする必要はありません。ユーザーが競合する保存を行うために使用する可能性があるコントロールのみです。
実際に最大で10秒かかる場合は、影響を受けるコントロールの近くに、サーバーが動作している間は一部のアクションが使用できないことを説明するツールチップを表示して、この無効化を行うこともできます。
もちろん、ユーザーと一緒にテストする必要がありますが、ほとんどの場合、一部のボタンの一時的な無効化（おそらく、ユーザーがUIをたどってさまざまな保存ボタンをすばやく押すだけではないため）はおそらく気付かれないでしょう。