ユーザーが分析レポートをダウンロードするフォームを作成しています。送信に技術的に必要な複数のフィールドがありますが、ユーザーの負担を軽減するために特定のフィールドを事前に入力しています。ここにスケッチがあります:
その他の例:
レポート名:[月次レポート]
^入力に名前を事前に入力しますが、ユーザーはその名前を編集することもできます
送信日:[01/01/15]
^レポートのスケジュールを設定し、今日の日付を事前入力することができますが、編集することもできます。
これらのフィールドはまだ必要とマークされている必要がありますか?
編集:
以下のコメントをありがとう。入力の定義が少しわかりにくいことに気づきました。これは、入力に配置する必要があるものの例ではありません。使用されるのは実際のコンテンツです。デフォルトのように: http://designinginterfaces.com/firstedition/index.php?page=Good_Defaults
その記事の例はローカルアプリケーションからのものですが、同じルールがWebアプリに適用されるかどうか疑問に思いましたか?
別の編集:
他の例/バリエーションをいくつか見つけました。多分誰かがそれらに話すか、少なくとも私にこれらのシナリオの用語が何であるかを私に知らせることができました。または、これがより良いルートであるとしても?
編集可能なフィールド:
JIRAでは、コンテンツにカーソルを合わせると編集可能になりますが、それ以外の場合、デフォルトは編集できません。しかし、それらの領域が編集可能であることをどのように人々に教えますか? Squarespaceもこれを行うと思います。 http://screencast.com/t/Z2EvPiAN
事前選択された入力を編集不可として表示しますが、確認を求めます:
これらはまだ必須フィールドです。
編集内容に基づいて、watermarkingが実際のデータを使用しているため、必要なフィールドを示す必要があります。
Fromフィールドには入力する必要があるので、デフォルトを受け入れることはできません。
レポート名、件名、および日付範囲フィールドですが、それはあなたの呼び出しです。これらは、ユーザーがそのまま残したい有効なデフォルトです。それはあなた次第か、おそらくA/Bテストの一部だと思います。
私はまだそれらを必須フィールドとしてマークします(要件が満たされているだけです)。
それはフォームとデータに依存しますが、あなたの特定のケースでは私はそれをしません。フィールドを事前に入力すると、ほとんどのユーザーは「現状のまま」のままにします。これは、フィールドを変更できるかどうか、または気にしないためです。いずれにしても、あなたもユーザーも期待した結果を得られないので、悪い振る舞いです。
事前入力されたフォームは、入力が優先される場合(たとえば、ユーザーが選択する事前選択された価格オプションなど)またはフォームが非常に長い場合に役立つことがあります。そしていずれにしても、彼らが情報を変更できることは非常に明確であるべきです。フォームの一部として常にnon-modifiableデータを持つことができますが、それでもフォーム入力としては見えないことに注意してください
ここにいくつかの本当に良い答えがあり、それらは状況をかなり明らかにします。私の2セントを投入するには、あいまいさを減らすためにできることが多いほど良いと思います。フィールドを事前に入力することはユーザーにとって非常に便利ですが、データを操作することを決定した場合、フィールドに何が期待されるかを明確に示す必要があると私は思います。上記のフィールドの説明のメモのアイデアは好きですが、小さな赤い星はそれだけで大きな意味を持ちます。私のリトマステストは、フォームが事前入力されていなかった場合にユーザーが期待するものだと思います。フォームにデータを取り込むメカニズムが何らかの理由で壊れた場合。彼らは間違いなくある種の追加の指標を必要とするでしょう。