サブスクリプションフォームパターン、パート2

これは、人気のあるSmashing Magazine Webサイトの著者が実施した興味深い研究の翻訳の第2部です。 ここで最初の部分を読むことができます 。 今回は、著者はCAPTCHAの質問、「登録していただきありがとうございます」メッセージ、フォームの「キャンセル」ボタン、およびその他の興味深い質問に触れます。

3.フォームの機能

調査の最初の部分では、サブスクリプションリンクと登録フォームの場所、およびそれらの外観を調べました。 ただし、デザインがどれほど魅力的かは関係ありません。フォームが正常に機能しない場合、完成したフォームの数は少なくなります。 ここで、サブスクリプションフォームの機能と、それらに関連する典型的な問題、そのようなフォームの設計で使用されるパターンとソリューションの両方について考えてみましょう。

3.1。 ホバー、アクティブ、フォーカス-使用による影響？

明らかに、記入するフォームの数を改善するために、デザイナーはすべてのフォームで注意散漫を避け、きれいで明確に定義されたシンプルなWebフォームを提供しようとしています。 本質的に、これが視覚効果が非常にまれにしか使用されない理由です。

• 確認したWebフォームの84％には、ホバー、アクティブ、フォーカスのいずれの効果もありませんでした。
• 16％は非常に弱いホバー効果を使用しました。

3.2。 ヘルプ、サポート、ヒント：静的または動的？

入力フィールドへのキャプションだけでは不十分な場合もありますが、ユーザーは提供する必要のある情報を知る必要があります。 ユーザー名に使用できる文字は何ですか？ パスワードには何文字入力する必要がありますか？ ウィルまたは指定された電子メールが自動的にサービスへのログインになります。



ヒントとツールチップは、情報の再入力の量を最小限に抑えるためのユーザーサポートを提供します。 また、ユーザーデータは正しく表示されますが、ユーザーデータを受け入れない入力フィールドほど煩わしいものはありません。 これを避けるために、デザイナーは控えめで明確なヒントを（ほとんどの場合）使用します。











レビューされたWebフォームの57％は静的ヘルプを提供します。これは、ユーザー入力から何が期待されるかをユーザーに説明するヒントです。 これらのヒントは、入力フィールドの隣に明確に配置されています。 ヒントの10％はオンデマンドで表示されます-ほとんどの場合、ヘルプアイコンをクリックした後、またはユーザーが入力フィールドに情報を入力したときに表示されます。

3.3。 ヘルプ、サポート、ヒント：どこにありますか？

ユーザーにサポートが提供される場合、ヘルプが提供されるだけでなく、ユーザーが簡単に見つけて理解できるようにすることが重要です。 ユーザーがプロンプトと入力フィールドを比較して間違いを犯さないようにすることが非常に重要です。 これを実現するには、ユーザーがプロンプトを表示する場所を知る必要があります。 それでは、フォームに最もよくあるヒントとヘルプはどのようになっていますか？











ヒントとヘルプが存在する場合、それらは次の場所にあります。

• 入力フィールドの下（57％）;
• 入力フィールドの右側（26％）;
• 入力フィールドの上（13％）;
• 入力フィールドの左側（4％）。

入力フィールドのすぐ下にツールチップを配置する明確な傾向が見つかりました。 通常、これらのヒントの色はわずかに変化し、ほとんどの場合、メインコンテンツよりも明るくなります。

3.4。 入力検証：静的またはAjax？

近年、Ajaxは文字通りWebサイトに豊富なユーザーインタラクションを殺到しているという事実にもかかわらず、人気のあるWebサービスの間で依然として重要な集団に達しています。 驚くべきことに、Ajaxを使用する着実な傾向は見当たりませんでした。 ユーザーが送信ボタンをクリックした後に入力を検証する「クラシック」検証手法は、Javascriptを使用したリアルタイム検証よりも人気があります。



調査によると、

• すべてのフォームの30％は、フォームの上部にエラーメッセージのみを表示します（入力フィールドは強調表示されません）。
• 29％は、入力フィールドの直後の対応するメッセージで入力フィールドを強調表示します（ページの上部にエラーメッセージは表示されません）。
• 25％は両方の方法を使用します。エラーメッセージと入力フィールドのメッセージ。
• 22％はAjaxを介したリアルタイム検証を使用しています。
• 14％はJavascriptを介してエラー警告を使用します。
• 1％は「戻る」リンクのあるシステムメッセージを使用します。

3.5。 エラーメッセージの設計

お気づきかもしれませんが、6種類のエラーチェックを特定しました。 興味深いことに、フォームの14％は引き続きJavascript（Javascript-error-windows）を介してメッセージボックスを使用して問題を報告しています（たとえば、 YouSendIt 、 Mail.ru 、 Newsvine 、 Clipmarks 、 Yandex 、下のスクリーンショットを参照）、少なくとも22％ Ajaxベースの部分検証（主に利用可能なユーザー名を検証するため）。 さらに興味深いことに、検証がまったく行われない単一のサイトはありません。









NewsvineはJavaScriptメッセージを使用してエラー情報を表示します。



通常、設計者は次を使用してエラーを報告する傾向があります。a）送信ボタンをクリックした後のエラーメッセージ、および/またはb）「誤った」入力フィールドを視覚的に強調表示する。 最初のケースでは、エラーは通常、フォームの前にページの上部に箇条書き（箇条書き）が付いたリストの形式で表示されます。 2番目の場合、通常、「間違った」入力フィールドは、フィールドの署名と共に境界線の色を変更します（ほとんどの場合、赤いテキストと赤い背景）。



設計者が両方の手法を組み合わせて、エラーメッセージと強調表示入力フィールドの両方を使用する場合があります。 たとえば、両方の手法を組み合わせて、Ningにサブスクライブする形式（下の画像を参照）を検討してください。











通常、赤はエラーを示すために使用されますが、常にそうであるとは限りません。 Tickspot 、 Mixx.com、およびFurlは黄色を使用して、フォームの入力に関する問題を報告します。











ただし、登録の成功を報告するために使用される色は緑だけです。 97％のWebサイトで、この色は成功したアクションを視覚的に強調するために使用されました。

3.6。 電子メールを確認する必要はありますか？

18％の場合にのみ、電子メールを確認する必要があります（たとえば、 Odeo 、 Ning ）。 正直に言うと、電子メールの入力フィールドはアスタリスクで覆われていない（星印は付いていない）ため、ユーザーに電子メールの再入力を求める正当な理由はありません。 同意しますか

3.7。 パスワードを確認する必要はありますか？

ユーザーが入力した情報が表示されない場合（代わりに、アスタリスクが表示された場合）、入力の確認を求めるのは理にかなっています。 ただし、多くのサイトでは、フォームの入力に必要な時間を最小限に抑えるために、1つの入力フィールドを削除することにしました。











72％のケースでは、パスワードの確認が重要であると考えられています。 ただし、Facebook、Friendster、LinkedIn、Stumbleupon、Pownce、Twitterなどの多くの大規模サイトでは、パスワードの確認は必要ありません。

3.8。 キャプチャが使用されていますか？

ユーザーはcaptchaが消えることに非常に満足していますが、実際にはWebサイトは複数のアカウントをスパムボットに登録できないようにする必要があるため、サイトはデータベース内のスパマーアカウントをフィルタリングする必要があるため、実際には必要です。



調査によると、

• 52％のサイトはキャプチャを使用していません。
• 39％の場合、ウェブフォームを更新せずにcaptchaを更新することは不可能です。 これは、使いやすさの点で非常に悲しいです。

ただし、サイトがcaptchaを使用するか使用しないかの明確な傾向は見つかりませんでした。 いずれにしても、captchaを使用している場合は、読みやすいか、読み取りできない場合はユーザーがcaptchaを更新できることを確認してください。 一部のサイトにはcaptchaを更新する機能がありませんが、Digg、AOL、Slashdot、Google、Last.fmは、captchaが判読できない場合にユーザーがcaptchaを聞くことを提供します。

3.9。 キャンセルボタンが使用されていますか（キャンセルボタン）？

Webフォームの設計のための設計ソリューションを定義することにしたとき、実際にはすべてのフィールドが入力された後にユーザーがフォームへの入力をキャンセルする必要がないため、サブスクリプションフォームに「キャンセル」ボタンが含まれないことが予想されました。 そして、私たちは部分的に間違っていました。



キャンセルボタンは、8％の場合にのみ使用されます。 これらのケースのいくつかでは、「キャンセル」ボタンは「契約条件」セクションの直後にあります（例： Zoho Writer ）。 したがって、ユーザーがサービスの要件に同意したくない場合は、プロセスを中断できます。 一方、登録する前に支払いプランを選択することを提案するサービスもあります（例： Crazyegg ）。 この場合、間違ったプランを選択すると、「キャンセル」ボタンをクリックして元に戻り、必要と思われるプランを選択できます。











これとは別に：サブスクリプションフォームの左側にDzoneが「キャンセル」ボタンを配置した理由はまだわかりません。



キャンセルボタンを使用する場合、送信ボタンの右側にあります（4％）。 この記事で説明したサイトでは、「キャンセル」ボタンと送信ボタンは互いに違いはなく、近くにありました。 使いやすさの観点から、基本的なアクションを持つボタンと追加のアクションを持つボタンを明確に視覚的に分離し、それらを明確に分離するためにそれらの間を大きく離すことは理にかなっています。

3.10。 送信ボタンの配置（送信ボタン）

フォームのレイアウトに応じて、送信ボタンを左、右、または中央に配置するのが適切です。 デザイナーは左揃え（56％）を好み、その後に中央にボタンが並んでいます（26％）。











右揃えの送信ボタンは引き続き人気があり（17％）、次の登録手順を示すためにデザイナーが最もよく使用します。 このような場合、送信ボタンはほとんどの場合、続行または次へと呼ばれます。 理由：通常のアプリケーションでは、多くの場合、[次へ]ボタンも右側にあります。

3.11。 ありがとうメッセージ

ほんの数年前、ほとんどのサービスは、登録に成功した後（通常はログインページへのリンクを使用）、簡単な「ありがとう」メッセージを提供しました。

• フォームの45％は、新規登録ユーザーに、詳細情報の入力、ネットワーク上の友人の検索、友人へのサイトの推奨、またはプロファイルの入力を求めます。
• フォームの33％は、魅力的でフレンドリーな方法で「訪問する場所」の研究と機能を提供します。
• 4％は、簡単な「ありがとう」メッセージを提供しています。
• 2％がメインページにリダイレクトします。

追加の研究結果：

• タブ切り替えの順序は99％のケースで正しいものでした（habrahabr.ruを除く）[約 perev。 -翻訳のヒントをくれたKalanとkurokikazeに感謝します];
• フォームの24％は会話形式を使用しており、署名を通じてユーザーのニーズに対応しようとしています。 「あなたの名前は何ですか？」、「メールでお問い合わせください」、または「希望します...」などの情報フレーズは、おおよそのオプションです。
• 38％のサイトは、フォーマルのままで、ビジネススタイルの使いやすいユーザー（たとえば、「あなたの名前」、「パスワードの確認」など）を使用することを好みます。
• 38％のサイトはシステムスタイルを使用しており、ユーザーは「ログイン」、「ユーザーパスワード」、「場所」などのフレーズで質問されます。

おわりに

調査の結果をまとめて簡単に確認しましょう。 これはサブスクリプションフォームにのみ適用されることに注意してください。

• サブスクリプションフォームには、ホバー効果、アクティブ効果、フォーカス効果は含まれていません（84％）。
• ヒントとヘルプはほとんどの場合静的（57％）または動的（33％）で、入力フィールドの下（57％）または入力フィールドの右側（26％）にあります。
• 静的検証は動的よりも一般的です-Ajaxを使用する傾向はありません。
• 電子メールの確認は使用されません（82％）。
• パスワード確認が使用されます（72％）。
• captchaは使用される場合と使用されない場合があります（48％対52％）。
• キャンセルボタンは使用されません（92％）。
• 送信ボタンは左側（56％）または中央（26％）にあります。
• 「ありがとう」というメッセージは、ユーザーがサイト上のサービスの調査を継続するよう動機付けます（45％）。