プレースホルダーはデフォルト値に適していますか？
私は読んで（そして信じて） this article thatHTMLプレースホルダーのデータ入力のヒントは一般的に有害であり、回避する必要があります。
コンテキスト内の説明またはヒントは、各フォームフィールド内の内容を明確にするのに役立ち、完了率と変換率を向上させます。ヒントを提供する方法はたくさんあります...残念ながら、ユーザーテストでは、フォームフィールドのプレースホルダーが使いやすさを損なうことが多いということを絶えず示しています。
私はデフォルト値にプレースホルダーが使用されているのを見始めており、これはそれらのためのより良い使用であるようです。これらは、値が入力されなかった場合にフィールドが「何をする」かを表すため、値のない文字のプレースホルダーです。
アイデアは、ユーザーが最も必要なときに（ユーザーがフィールドを操作しているときに）プレースホルダーのヒントが消えるのに対し、プレースホルダーのデフォルト値は、ユーザーがそれを望まないと決定したときに消えるというものです。
例：
品種フィールドを空のままにすると、このフォームは品種に関係なく利用可能なすべての犬を返します。 「Any」プレースホルダーはそれを示します。
注：「品種」にこだわらないでください-「郵便番号」または自由形式を受け入れる他のものと同じくらい簡単にできますエントリ。この質問はプレースホルダーに関するものであり、さまざまな種類の入力要素をいつ使用するかに関するものではありません。
これが良い実践であるかどうかを支持/反駁する分析はありますか？誰かがこれを試した経験がありますか？
私は英語のネイティブスピーカーではないため、Webデザイン/開発に入ったときにプレースホルダーという用語しか知りませんでした。それで、私は単語の意味についてウィキペディアを検索して、 これは興味深い （私にとって）情報（強調は私のものです）を読みました：
これらのプレースホルダーは通常、文法的に名詞として機能し、人（例：John Doe、Jane Doe）、オブジェクト（例：ウィジェット）、場所（「メインストリート」）、または場所（例：アメリカ、エニータウン）に使用できます。彼らの指示対象は文脈によって供給されなければならないので、彼らは代名詞と財産を共有します。ただし、代名詞とは異なり、リファレントなしで使用できます—コミュニケーションの重要な部分は、プレースホルダーによって名目的に参照されるものではなく、プレースホルダーが発生するコンテキストです。
一般的な例としてのプレースホルダー：
私が正しく理解していれば、プレースホルダーは特定のコンテキストにおける一般的な例です。彼らは実際のケースかもしれませんが、私はそれが例であると理解する方が一般的であると思います。
そのため、プレースホルダーはラベルを置き換えたり、入力を完了するために必要な追加情報を置き換えたりしてはなりません。
あなたの例では、品種として一般的な例を使用するのは難しいかもしれません。具体的なケースが機能する可能性がありますが、プレースホルダーがより具体的であるほど、それがジェネリックであると想定されていることを理解するのがより困難です。
デフォルト値としてのプレースホルダー：
相互作用の量を減らしたい場合に便利ですが、理解するのが少し複雑です。また、「すべて」の品種はないため、一般的な例としては機能していません。
このケースは以下の簡略化されたバージョンであるため、トリッキーです。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
（画像では、「すべて」と「ポメラニアン」のテキストの不透明度を低くする必要があります）
結論：
一般的に私はプレースホルダーを一般的な例として使用します（ちなみに1つの例）。
- 入力する期待値を理解するのに役立ちます
- 一度読んでフォーカスすればもう必要ありません
- チェックボックス機能は入力に割り当てられません（ "Any"はそうです）
- これは空のままにしないでください。これにより、ユーザーは入力することが期待される値が何であるか、またはどのように質問される可能性があります。
- ラベルが100％明確でないか、あいまいな場合があるため、一般的な例が役立ちます
値として機能する場合は、値として使用しないのはなぜですか？
プレースホルダーテキストは、必要なエントリのタイプを示すために使用する必要があります。特定のシナリオでは、placeholder属性ではなく、value属性をAnyに設定します。次に、ユーザーが変更可能な値を変更したい場合は、Anyのままにして、[選択]をタップします。
より良い
さらに、プレースホルダー属性をe.g. Pomeranianなどのように設定して、必要なエントリのタイプをより適切に示します。次に、ユーザーが空白のままにした場合、またはユーザーがAnyと入力した場合は、すべてを返します。入力の近くにLeave blank to return allのようなヘルパーテキストも役立ちます。
すぐにAnyはそこに残せる値ではないと想定しましたが、フォームはAnyの値を入力するように要求していました。私の意見では少し誤解を招きます。
これらの値に選択またはフィルタリング選択を使用して、代わりにAnyをデフォルト値として使用するのはどうですか？
犬の品種はたくさんあると思いますが、これでもうまくいかないかもしれません。
おそらく、このフィールドの上に「品種を示すには空白のままにしてください」というラベルだけを付けます。たぶん？
私は実際にはTimの提案に同意し、デフォルト値にプレースホルダーを使用することは完全に理にかなっていると思います。
1）Timの提案を使用することにより、ユーザーは、アプリケーションで計算された値から、ユーザーが入力したフィールドを区別できます。いくつかのシナリオでは、デフォルト値を入力として機能させることができますが、大量の入力があるテクニカルフォームの場合、ユーザーは実際に何が入力され、アプリによって提供されるデフォルト値が何であるかを知りたいと考えます。
2）プレースホルダーを使用することにより、値が提供されるとデフォルト値は消え、デフォルト値が何であるかを示すメタファーになります（ユーザーまたはプログラマーによって代替が指定されていない場合、コンピュータープログラムまたは他のメカニズムによって採用される事前選択オプション）。
3）いくつかの入力フィールドを持つフォームが想定できるすべてのデフォルト値をUIに簡単に表示する方法がないため、ユーザーが知らないうちにデフォルト値が内部で想定されることがよくあります。これは、フォームの実際の状態をとらない一貫したアプローチを提供することにより、この問題を修正します。
プレースホルダーのアクセシビリティ
あなたが参照した記事を読んだ後 フォームフィールドのプレースホルダーは有害です 、プレースホルダーは積極的に有害ではないかもしれませんが、少なくともあなたが考えるほど有用ではありません。そしてそれが役に立たないのなら、なぜそれをするのですか？
アクセシビリティ（および「訴訟の回避」）の観点から、プレースホルダーはスクリーンリーダーで省略されることがよくあります W3.orgチュートリアル：フォームのアクセシビリティ 。スキップされる可能性が高い要素である場合は、そこに本質的/有用な情報を提供する必要はありません。そして、それが本質的で有用な目的を果たさないのであれば、なぜそれがUIをすっきりさせているのでしょうか？フィルタリングフィールドで何も選択しなかった場合、結果にはすべてが含まれるはずです。ブランドを指定していない家電店のサイトで「洗濯機」を検索すると、ブランドに関係なく、販売している洗濯機が表示されます。 。 「これですべてだ」と言うプレースホルダーは必要ありません。