質問: フォーム上の削除ボタンの配置 フライトを編集するフォームがありますが、削除できるようになっているはずです。すべてのフライトを一覧表示するインデックスページに削除ボタンを配置することを検討しましたが、テーブル行自体がクリック可能であり、クリック可能な要素を別のクリック可能な要素に配置したくありませんでした。削除ボタンの位置がフォーム上でどのようになるかを示す簡単なモックアップを作成しました。削除ボタンの可能な位置を2つ確認しました。1)ヘッダーを右に引っ張ります。ユーザーが気付かないかもしれませんが、保存ボタンから離れた場所に配置されているので、誤ってクリックするのを防ぐことができます。2)保存ボタンの横。ユーザーはきっとそれに気づくでしょうが、誤ってそれをクリックすることによる重大なリスクがあります。削除ボタンはどこに配置するとよいでしょうか?
回答: 現在のモックアップの問題は、「削除」ボタンが最も目立つことです。私があなたのモックアップを見たときに私がすぐに思ったのは、「削除」ボタンが主要なアクションだということでした。最初のビューでは[保存]ボタンが無効になっているように見えるほど平坦ではありません。 「削除」ボタンのように飛び出すことはありません。主なアクションが最も目立つアクションであることを確認してください。「保存」ボタンに緑色を適用して、目的のアクションであることをユーザーに明確に示すことができます。「削除」ボタンについて。 これは2次アクションですは、大きな結果をもたらす可能性があり、すべての画面ビューで操作されないことに注意してください(削除アクションの使用頻度が保存アクションよりもはるかに少ない場合)。これらの理由により、ボタンはまったく使用しませんただしリンクではなく。ボタンの代わりにリンクを使用すると、アクションが実行可能であることをユーザーに明確に示しますが、同時に、望ましい(および期待される)アクションは削除ではなく保存であると説明します。削除の処理方法ユーザーが誤ってクリックしたり、意図したものとは異なるレコードを削除したりすることにより、ユーザーが誤ってレコードを削除する可能性があることに注意してください。そのためndo機能を含めるようにしてください、またはそれが何らかの理由で可能でない場合は、明確な確認を求めてください。これをやりすぎないでください。ライトボックスや類似のモーダルユーザーのメンタルフローを壊すであり、影響がどれほど小さいかを問わず、すべての削除アクションを確認する必要があるのは本当に面倒です。 レコードを簡単に復元できない場合にのみ削除確認を要求する(および元に戻す機能を実装できない場合)確認を使用する場合は、削除の影響も考慮してください。レコードを誤って削除した結果が簡単に復元されない場合は、レコードを削除しようとするときにユーザーにパスワードまたは確認文字列の入力を求めることで「スピードバンプ」を実装します。mailchimpがこれを行う方法を見てみましょう: