ユーザーはクライアントレコードを作成しています。各レコードに対して、1つ以上の連絡先(人)を提供できます。多くの場合、これは1または2を追加しますが、最大5〜10になることもあります。
簡単に言うと、ユーザーは既知の各人物をリストに追加し、アカウント作成プロセスの次のステップに進みます。ページが送信されると、変更が保存されます(各行で技術的にこれを行う必要はありません)。
これが私が提案したものです。一番上はデフォルトのビューです。 2つ目は、連絡先が追加されたときです。注:行削除オプションがあります。
このアプローチには潜在的な問題がありますか?
これはかなり良い出発点のように見えます。質問に明示的に回答するには:
ユーザーは行の最後に「保存」オプションを期待しますか? (保存は、ページが送信されるときに技術的に行われます)。
実際にデータを保存しない限り、「保存」ボタンを表示しないでください。したがって、ページが完成したときにのみデータが保存される場合、1行ずつ保存ボタンを配置することはお勧めしません。
ただし、これにはいくつかの質問があります。
エラーはどのように表示されますか? 5〜10件の連絡先を入力したばかりの場合、一度にすべての行でエラーが発生しますか?これは、入力時に各フィールドをチェックするよりも処理がはるかに難しい場合があります。インライン検証の使用を検討し、アラートをOnChangeで表示することを検討する必要があります(たとえば、電子メールアドレスが有効ではないように見える場合(たとえば、「@」なし)。
OnChangeで各フィールドを自動保存できますか?これにより、ユーザーがいくつかの連絡先を入力した後、明示的な保存オプションをクリックしていないときに何かがクラッシュした場合に発生する可能性のあるエラーが少なくなります。
「追加」/「新しい行を追加」の配置は適切ですか?
リストの上部にある[連絡先を追加]ボタンの方が適切でしょうか?
現在の仕様を考えると、新しい行が表示されるボタンをリストの一番下に置くほうが私にはずっと理にかなっています。ただし、上の行が入力されたときに単に新しい空白行を追加するのではなく、ボタンが必要かどうかを検討することをお勧めします。これは、たとえばiOSの連絡先ページが採用しているアプローチであり、ユーザーのフローを中断させないようにするのが容易になるようです。
私は次のような流れを考えます。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
次に、このページに[保存]ボタンを追加して、それらの連絡先がすべて正常に追加されたことをユーザーに知らせることができます。ただし、これは絶対に必要なわけではなく、このページのコンテキストと、アプリケーション全体で[保存]ボタンを使用する方法によって異なります。
「連絡先を追加」の位置は大丈夫だと思います。それは示唆し、UIのフローに従います。このボタンを上部に配置することはお勧めしません。100件の連絡先レコードがある場合、別のレコードを追加するたびに、上部にスクロールして戻る必要があるためです。
いくつかの提案:
同様の作業をしていると、自動追加の方法で複数のフィールドセットを追加するよりも複雑になる可能性があります
以下の問題について、ご意見をお聞かせください。
初期状態では、ユーザーは複数のフィールドセットを追加できることを確認する必要がありますか?
追加された新しい行は、ユーザーが最初のフィールドに入力し始めたとき、または最後のフィールドからフォーカスを合わせたときに表示されますか?