web-dev-qa-db-ja.com

「保存しています...」という通知でフォームをカバーするのは間違っていますか？

一部のフォームは保存に時間がかかる可能性があり（インターネット速度、データ検証の速度が遅い...）、フォームをさらに編集できないようにロックしている間、システムがデータを保存していることを示す必要があります。

  1. 次の2つのアイデアの間に、より良いパターンはありますか？
  2. これについてモバイルとデスクトップの違いはありますか？

オプション1-フォーム上の通知

enter image description here

  • フォーム全体をカバーする「Saving」（スピナー付き）などの通知を表示します。 （これにより、保存中にフォームをさらに編集できないようにロックします。また、ボタンが無効になります）
  • 次に、通知は "Saved"（大きな緑色のチェックマーク付き）に変わります。
  • モーダルを閉じる/ページを閉じる

オプション2-ボタンに沿った小さな通知

enter image description here

  • 「Saving」メッセージを保存ボタンとインラインで使用します（フォームとボタンを無効にします）
  • 通知が「Saved」に置き換えられてフォームが保存されたことを確認します
  • モーダルを閉じる/ページを閉じる
formsinteraction-designbest-practice
36
Andrea Avesani

オプション2は、変更されたコンテンツをそのまま残して表示します。これは、ユーザーが送信/変更したばかりのデータを思い出す必要がないことを意味します。

インライン通知（オプション2）：

  • ユーザーにデータをリコール/記憶させません。
  • 変更されたデータを表示したままにし、ユーザーが間違いを見つけられるようにします
  • 状態インジケーター（「保存済み」）を無効なボタンの近くに保持します 近接 選択したときに私の目がある場所 Save

オプション1は、何かが保存されたことを明らかにしますが、保存したばかりのwhatをリコールする負荷をユーザーに課します。

質問2に関しては、これはレイアウトの質問に近いかもしれません。

51
Mike M

オプション2の方が優れています。マイクMが話しました。オプション2と同様に、実際には3番目のオプションをお勧めします。「送信」ボタンと「キャンセル」ボタンを「保存」メッセージとスピナーに置き換えます。これにより、ユーザーに最初に表示されるのは「保存中」のメッセージです。ユーザーがボタンを押すと、他の何かが注意を引くまで、ユーザーの目がそこに残ります。そのため、変更はすぐに発生します。ボタンをグレー表示するだけで、ユーザーが見回して「保存中」のメッセージが表示されるまで、フォームが「壊れている可能性があります」ように見えます。

オプション1の利点は、ユーザーが回答を変更できないことをユーザーが知っていることです。ユーザーが編集できないことを明確にするために、テキスト入力フィールドの後ろに灰色の背景を置くことをお勧めします。 （ユーザーがそれらを編集できないことも確認します）。

25
user7868

@ Hugo-Viallonが示唆するように、私がユースケースで最も効果的に機能するのは、スピナーを保存ボタンに配置し、他のすべてのボタンを無効にすることです。完了後、ユーザーがリダイレクトされない場合はトーストを表示します。
トーストなしでは、ユーザーにそれが機能することを確認するためだけに何度も保存してもらいましたが、小さな確認でそれを防ぐことができました。

preview

jsfiddle

10
GammaGames

オプション2のバリアントを使用できます。

読み込みは、テキストを置き換えるスピナーとして「保存」ボタンに配置できます。ボタンも無効にします。

このようにして、何かが起こっていることを示し、「保存」ボタンの上にあるスピナーがユーザーに何かが起こっていることを知らせます。他のボタンがグレー表示されているため、[保存]をクリックするとアクションが実行されたことがさらに明確になります。

最後に、これにより、ボタンの削除や既存のレイアウトの変更が回避されます。

4
Hugo-Viallon

テキストフィールドに含まれる単語が非常に少ない場合は、非表示にせず、選択不可にしないでください。

大きなテキスト/コメントフィールドに入力し、[送信]をクリックすると、保存アイコンがアニメーション化され、アニメーション化され、アニメーション化され、接続が切断されるか、その他のエラーが発生するのは非常に煩わしいです。画面が非表示になっていない場合は、少なくとも書き込んだ内容を選択してクリップボードにコピーし、ページを再読み込みして貼り付けてから、もう一度試すことができます。

このオプションを削除すると、保存プロセスで何か問題が発生したときに、ユーザーが作業を失うことになります。

3
vsz

私は別のアプローチをとります（基本的に、質問1に答えます）：送信をクリックすると、フォーム+ボタンの両方を非表示にし、ユーザーが実際にデータを投稿する前にユーザーが送信したデータのテキストによる概要を表示します。プロセスに関するフィードバック（多分スピナーかもしれませんが、何が起こっているか、何が起こったかを説明する、無限でなく、色分けされたラベルを希望します（例：「送信/送信/エラー」）。

なぜ私はそのようなアプローチを支持します：

-投稿は非表示になってからのみ発生するため、ユーザーがClick Eastwoodであっても、重複するリクエストを送信する可能性は低くなります。複数のクリックを簡単にキャッチして、リクエストする前に対処できます。

-フォームが投稿され、変更できないことが非常に明確になった

-ユーザーは、レイアウトの大幅な変更により、自分のアクションに対して報酬を受け取ります

-ほとんどのユーザーは待機中に概要を読むため、待機を和らげ、後でエラーを見つけて修正する時間を与える

0
NotImplementedException