本当にログインボタンが必要ですか？
私たちは、新しいWebアプリケーション用に開発しているログインページを取り巻くオフィスで話し合っています。 Webアプリケーションはイントラネットベースのアプリケーションであり、主にTelnetアプリケーションを毎日の仕事の80％として使用する必要があるユーザーによって使用されます。
Photoshopで最初のページデザインを作成しました。ただし、他の開発者の1人にビルドを開始するように依頼したところ、ページにログイン（またはその他の）ボタンがないことに気づきました。フィールドは2つだけです。 1つはユーザー名用、もう1つはパスワード用です。私に質問した後、私は必要性を理解しなかったので、それは意図的であると述べました-ほとんどの人はとにかくEnterキーを押すだけです。その後、議論が始まりました...
「ボタンがないと何をすべきかわからない」、「ボタンを期待していて、ページ上でサポートコールが機能しない」という点については、いくつかの点が指摘されました。ユーザーが何をすべきかわからないまま「そこに座る」だけであるという提案さえありました。
今..私の質問は：ユーザーは本当にログインボタンが必要ですか？
詳細を入力した後、続行するためにEnterキーを押すことを要求する単純なログインページにエンドユーザーのどの程度の割合で対処できるかについて、本当に興味があります。 Enterキーを押すための画面上のプロンプトは表示されないことに注意することが重要です-何をすべきかを示すパスワードの上にツールチップが表示されますが、それだけです！
（モバイルユーザーを争いから除外します-普通のデスクトップユーザーとラップトップユーザーをターゲットにします:)）
ログインボックスの例：
結局のところ、既存の規則に基づいたユーザーの期待のため、真剣なテストをせずにこのパスをたどることはおそらくお勧めできません。
これは重要なポイントです。私があなたの説明から取り除いているのは、これは現在テストされておらず、ユーザーが理解するという前提でこのUIを設計したことです。これは一般に悪い考えです：常に聴衆からフィードバックを得る、特に何か新しいことを試みているとき、特にログインのようなコア領域。
あなたのtelnet引数は考慮に入れるべきものですが、ここでWebアプリを構築していて、TelnetではなくWebアプリのユーザーの期待に対処していることも理解しています。脳はコンテキスト間でシフトします。Webアプリを使用する場合、アイテムをシングルクリックしてフォローするのに対し、デスクトップアプリではダブルクリックする必要があります。 ユーザーが持っているメンタルモデルを認識する Telnetのような別のスペースではなくWebアプリを使用しているときは、ユーザーインターフェイスを設計する上で重要な要素です。
ただし、標準の「ログインまたはサインアップ」の規則から少し逸脱し始めているいくつかのパターンが出現しています。これらはそれぞれ同じ課題に直面しています：ユーザーは何を期待し、どのようにして信頼、期待、発見可能性を構築しますかこれらの新しいアイデアの周りに？たとえば、StackExchangeはシングルサインオンを採用しているため、そのパターンに慣れていないユーザーは混乱する可能性があります。 Amazonは（正常に）登録とログインを1つのフォームに統合していますが、そのパターンが他のサイトでどれほど効果的であるかはまだわかっていません。
重要なのは、慣習を破ると、見慣れない領域に向かっていることであり、人々に及ぼす影響を理解する必要があるということです。これを行うことを検討している場合は、直接の環境（たとえば、オフィスマネージャーと道路の向こう側のオフィスの誰か）からいくつかの「工場のデスクトップユーザーとラップトップユーザー」を取得して、ログインするように依頼することをお勧めします。 。あなたはたくさん学ぶでしょう。あなたはあなたの最初の仮定が正しいことを学ぶかもしれません。しかし、少なくとも仮定ではなく、それを証明するためのデータがあります。 :-)
編集：プログラマーへの質問への回答のコメントで述べたように、「規約の有効性を問う」が良い出発点ですが、その質問への回答がデータにあることを確認する必要があります。誰もが慣習に疑問を投げかけることができますが、慣習は理由のための慣習になっています：それらは問題の効果的な解決策です。正当な理由がない場合（そしてUIの世界における正当な理由は、データまたは何らかの形のメトリックがあることを意味します）から離れることは、通常、良いことよりも害を及ぼします。
職場には、Firefoxで閲覧している場合にのみログインボタンを表示するスタッフ開発システムがあります。クラスが開催されるたびに、ヘルプデスクはログインできない人々からの電話を受けます。すべての電話は、ログインボタンが表示されないという事実に関係しています。次に、Enterキーを押してログインする必要があることをユーザーに通知する必要があります。
ユーザーはもう少しコンピュータに詳しいかもしれませんが、ボタンを省くと、それに関するサポートコールが多くなると思います。
私はラフルの反応が本当に好きですが、私は自分の2セントを追加します。デフォルトの機能がわからないため、WebフォームでEnterキーを使用するのを非常にためらっていました。どうなるかわからない！一部の人々は開発努力にそれほど注意深くなく、フォームのデフォルトボタンを適切に指定することに失敗し、doを押してEnterを押すユーザーを混乱させます習慣。
その結果、私はTabを押し、次にSpacebarを押すようにトレーニングしました。パスワードボックスの次のコントロールは[ログイン]ボタン（またはおそらく[パスワードを保存]）になると期待していますチェックボックス）。スペースバーは、キーボードから手を離してUI要素の上にマウスを置く手間をかけずに、ボタンをクリックしてマウスをクリックするのと同じ効果があるためです。
要点は、ボタンが含まれていると思いますが、それがフォームのデフォルトのアクションであることを確認してくださいおよび次のように正しく設定されていることパスワードボックスの後のタブオーダー。このようにして、両方のユーザーセットを満足させます。
目の不自由なユーザーがいる場合、期待はある種のボタンになります。それ以外の場合は、スクリーンリーダーを検出してこの特定のケースでボタンを許可しない限り、ログイン方法は示されません。
物理的なキーボードを持たないユーザーを検討しましたか？ iPadまたはタッチスクリーン付きの電話を使用している人は？
ユーザーがログイン情報を保存できるようにするオプションについてはどうですか？ログインボタンを省略しても問題ないでしょうか。このようにして、ユーザーはマウスからキーボードに手を移動してログインし、その後再びマウスに戻ってアプリケーションを操作する必要があります。
だから私は言うだろう：はいあなたはそれが必要です。
他のWebアプリケーションに存在する要素については、パターンリソースを見つけて、その内容を確認することができます： http://www.welie.com/patterns/showPattern.php?patternID=ログイン
「ユーザーは、Tabキーを使用してユーザー名フィールドからパスワードフィールドに移動し、「ログイン」ボタンを選択する代わりにEnterキーを押すことができます。」.
通常、アクションはボタン/リンクを介して表され、追加のキーボード操作は二次的なものであり、「上級」ユーザーと同様に見られます。
使いやすさやアクセシビリティの理由について懸念がある場合は、ボタンも用意する必要があります。これにより、ユーザーはマウス/ポインティングデバイス（エントリをコピー/貼り付け|ボタンを押す）だけで、またはキーボードでのみフォームを操作できます。
私が最初にあなたの質問を読んだとき、私は「検索ボックス」事件についてです。 http://www.welie.com/patterns/showPattern.php?patternID=search パターンにはボタンがあるはずだと言われていますが、やがて（本番用）ボタンは虫眼鏡アイコンになりました/入力の右隅にあるボタンをクリックし、その後、左揃えの識別アイコンに進みます。トレンド（Googleインスタント検索）の進歩に伴い、検索ボタンの使用が減っていきます（まだ存在しています）。
まず、検索とログインには違いがあります。ログインには2つの入力が必要なため、たとえばボタンの代わりに（検索の場合と同様に）ログインアイコンを追加しようとすると、どこに追加するのでしょうか。最初の入力、最後の入力、または両方ですか？
すべてのユーザーがユーザー名を入力し、次にパスワードを入力してEnterキーを押す必要があるため、開発者としての明確な答えは最後です。したがって、あなたの場合、最後の入力でEnterをリッスンしますが、ユーザーが最初の入力（ユーザー名1）でEnterを押した場合はどうなりますか？一貫性の理由から、両方の入力を聞く必要があります。また、ユーザーが間違いを見つけてユーザー名入力に戻る場合もあります。
あなたのタイプのユーザーはテストに合格してログインに成功すると思いますが、このタイプのフォームはすべての人に適しているわけではありません（モバイルユーザーにも言及しました）。
ログインフォームの例： http://www.smileycat.com/design_elements/login_forms/
まず、私はTwitterを介してこれにアクセスしました。プログラマーではありませんが、妥当なITリテラシーを持っています。
Webサイトを使用するときに長い間[ログイン]ボタンを放棄していたので、興味深い提案です。私が使用するもののほとんどは、Enterキーを押して満足しているようです。
いくつかのポイント：学校の子供たちのテストは興味深いものでしたが、Webフォームは大人のユーザー、特にコンピューター（ZX/C64/BBC）を使用していないユーザーよりもはるかに直感的だと思います。不足しているボタンを（少なくとも）しばらく考えていたはずの友人を何人か知っています。これらの人々は、毎日コンピューターを使用して仕事をしていますが、使用するアプリケーションの操作方法を知っています。
ボタンがない場合、ユーザー名フィールドでEnterキーを押したときのフォームのアクションは何ですか？または可能性は低いですが、最初にパスワードを入力してEnterキーを押した場合はどうなりますか？両方のフィールドが完了するまで、タブアクションを持つものが必要になる場合があります。
自分のWindows PC（作業マシン、選択の余地はありません）をロックして、再度ログインすると、パスワードフィールドの[ログイン]ボタンがわかりにくくなり、ラベルが付けられません。ここでもEnterを使用します。
ほら、numptyの視点です;）
このようなページを見つけた場合、Webサイトが完全に読み込まれていないか、サーバー側のスクリプトにバグがあると思うかもしれません。ユーザーがサイトから移動する可能性を危険にさらすのはなぜですか？
また、テストでは、サイトの稼働時に実際に得られる可能性よりも高い成功率が得られる可能性があると考えましたか？テストされていると感じたとき、ある種のIQテストであるかのように、ある種の課題（ログインボタンがないなど）を克服することを期待している可能性があります。ただし、自宅で独自のWebブラウザーを使用している場合、彼らはおそらくまったく異なる考え方を持ち、異なる動作をします（たとえば、彼らは課題を克服することを期待しておらず、実際にはまったく逆のことを期待している可能性があります。多くのユーザーが満足することをWebサイトが明らかに望んでいるため、Webサイトはすべてのユーザーに対応し、ログインを容易にするために可能なすべてのことを実行することを期待しています）。
基本的に、テストシナリオは、実際のユーザーが体験するもの（つまり、被験者がテストされていること、および/または何かをテストしていることを知っている）と100％似ているわけではありません。テスト）、不正確なテストに基づいて不正確な結論を導く可能性があります。
テストの実施方法は正確にはわかりませんが、テストの品質に影響を与える可能性のあるもう1つの問題は、他の生徒が他の誰も問題/質問をしていないことを確認し、問題なくログインできる場合です。これにより、同僚と同じ結果が得られるまで、さまざまなことを試すことができます（「戻る」ボタンを押すなど）。したがって、対象を分離することもできます。
テストする変数を除いて、すべての変数が完全に同じであることを確認する必要があるため、正確なテストは非常に困難な作業になる可能性があります。この問題について考えるのに費やした少しの時間から、テストの精度に影響を与える可能性のある追加の2つの変数をすでに特定しています。まだ考えていないものがあるかもしれません。
いくつかのユーザビリティテストを行い、ユーザーが何をしているかを調べます。私はそれがプロジェクトであることを理解していますが、問題があれば、テストするのに十分重要です。
両方実行
誰かがEnterキーを押すとすぐにフォームが送信されるようにし（両方のフィールドに入力します）、また愛する人のために押すボタンがありますマウスを使用して。
いずれにせよ、ユーザーは慣れ親しんだことを実行して満足しています。
最善の方法は次のようなものです。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
また、テキストフィールドの外側に小さな矢印を表示することもできます Windows 7のログイン画面で 。
おそらく、ボタンのスタイルを変更したいと思うでしょう...カーソルを合わせるまで、ボタンをテキストボックスにブレンドします。
insideというパスワードフィールドの唯一の欠点は、長いパスワードを持っている場合に編集するのが難しいことです。これを見落とさないように注意してください！
結局のところ、他の回答と同様に、あなたはあなたの聴衆が誰であるかを尋ねる必要があることを示唆しています。面白くはありますが、実際には「私のテストでは不要であることを証明した」と言うのに十分な価値はありませんが、学校の子供たちに対するテストはあなたに与えられます。
ログインボタンを削除する場合、これらはあなたが戦わなければならないもののいくつかです：
- アクセシビリティの問題
- ユーザーが期待すること
- 将来のタッチベースのデバイス（Windows 7およびタブレット）
私はFlash Builderで個人的にWebアプリケーションを使用しており、概念実証の一環として、ユーザビリティテストを行っています。デザイナー/開発者は、一部のユーザーの知能レベルを過小評価することはできません。経験則として、私は常にユーザーが期待することをユーザーに提供するように言います。例外的な状況でのみ、広く使用されるようになった規則から離れるべきです。
ユーザーが次に何をするかを決めるのに数秒かかる場合は、ユーザーインターフェイスの表示方法を再評価する必要があります。
タッチスクリーン技術がより広く使用されるようになると、この特定のパターンがすぐに変わるとは思えません。それは進化するかもしれませんが、コアはおそらく同じままです。
推奨事項として、私は個人的にログインボタンを保持し、ユーザーがEnterキーを押して続行できるようにし、マウスタブを使用してクリックできるログインボタンを含め、キーボードのみを使用してログインボタンを選択します。
次に、ログイン画面の標準設定を維持することで、上級ユーザー、アクセシビリティルール、ITの読み書きができないユーザーをカバーします。
余談ですが、Rahul称賛によるすばらしい回答です！
懸念事項の1つは、ボタンやデザインの変更がないことに関するサポートへの問い合わせが多すぎないようにし、ユーザーを混乱させないようにすることです。
それを解決するには、次のメッセージを追加します
Press Enter key to login
パスワードフィールドのすぐ下。
これにより、メッセージを読んだ後、Enterキーを押してログインできることをユーザー（ログインボタンがクリックしてログインすることを期待しているかもしれません）に知らせることができます。初めての人にとってはぎこちないかもしれませんが、少なくとも混乱してサポートを求める必要はなく、次にWebサイトにアクセスしたときに、何をすべきかがわかります。
パワーユーザーは、Enterキーを使用してログインしているため、メッセージは無視されます。
ボタンのないソリューションでは、ユーザーがパスワードをロックする前に5回ログオンを試行できません。
したがって、ハッカーはパスワードを無制限に推測できる可能性があるため、システムはブルートフォース攻撃に対して無防備です。
ログオンにロジックを追加して、このようなハッキングを防止することもできますが、これは考慮する必要があることです。
どれだけ関連があるのかはわかりませんが、とても興味をそそられ、スクリーンショットのようなページを作成して、妻に試してもらいました。
彼女は助けを求めることなく何とかログインに成功しましたが、私は彼女のパスワードを入力した後、マウスを使用することを選択し、ボタンを探し始めたことに気付きました。彼女がそれを見つけられなかったときだけ、彼女は少しの間一時停止し、それから彼女を入れてリターンを押してみました。
彼女は何を考えたのかと尋ねると、最初は大丈夫で普通だったと言いましたが、欠けているボタンについてどう思っているのかを尋ねたところ、少し混乱していると言いましたが、リターンを押すと、 Wordで新しいページが必要な場合と同様に、次の画面に移動します。
彼女が何を意味するのかは完全にはわかりませんが、ボタンを探すのに少し時間を費やしましたが、その結果、彼女は何の助けもなく手に入ることができました。
資格情報を確認するためにEnterキーを押す必要のない、ソフトウェアで同様の種類のアプローチを見てきました。資格情報を入力して入力をやめると、資格情報の有効性がすぐに確認されます。
資格情報が間違っている場合は、非常に目に見えるエラーメッセージが自動的にスローされ、何が問題かを通知します。新しい資格情報を再入力または再試行するだけで、ログインに成功するまでプロセスが繰り返されます。
いくつかの理由から、ログインボタンが必要だと思います。
私が使用したほとんどのアプリは、最後のフィールドにデータを入力し終えると、フォーカスを最初のフィールドに戻します。さて、これは新しい慣習に取って代わられた古い慣習かもしれませんが、確かに私がフォームの動作を期待する方法です。
アプリに他のフォームがあると仮定すると、それらはログインフォームよりも複雑で、SUBMITボタンの存在を必要とする可能性があります。これは実際にはすべてのログインボタンです。これらのフォームにはボタンが必要なので、混乱を避けるために、すべてのフォームにボタンを配置することは理にかなっています。
すべてのブラウザがEnterキーを同じ方法で処理するわけではありません。繰り返しになりますが、これは昔ながらの問題かもしれませんが、フィールドが1つしかなかったときにEnterキーの動作に問題があったことを覚えています。一部のブラウザではSUBMITと同じでしたが、他のブラウザではSUBMITボタンをクリックする必要がありました。彼らの重要な点は、それはあなたのアプリによって制御されなかった、それはブラウザによって制御されたということでした。そのため、私はずっと前に、ENTERキーについて何も想定せず、常にSUBMITに依存することを学びました。繰り返しになりますが、これはもはや問題ではないかもしれませんが、この原則に固執することで問題が発生したことは一度もないので、変更する理由はありません。
社内で使用するWebアプリには、自動ログイン機能を使用しました。
ユーザーは住所を入力するか、お気に入りのブックマークをクリックするだけで、自動的に認識されて許可されます。これをどのように行ったか、私は常駐のグラフィックデザイナーなのでわかりません。
これは、既知の従業員のプロファイル、セキュリティ、および権限を作成する管理者の一部として行われた可能性がありますか？おそらく彼らのIPから？
アプリを定期的に入力してデザインをチェックする人として、毎回ログインする必要がないのは素晴らしいことでした。
繰り返しますが、私はデザイナーですので、考慮していないことがかなりあるかもしれませんが、社内アプリで働いている既知の従業員にとっては、これはかなりいいことでした。
ここでの答えはスクリプトだと思います。ユーザーが所定の時間内にEnterキーを押さない場合は、ログインするにはEnterキーを押さなければならないことを通知してください。スクリプトを無効にしている少数の人にとっては、いくつかの方法でそれを検出し、ボタンを与えることができます。