Eu realmente preciso de um botão de login?
Tivemos uma discussão no escritório em torno de uma página de login que estamos desenvolvendo para um novo aplicativo da web. O aplicativo da Web é um aplicativo baseado na intranet e é usado principalmente por usuários que precisam usar aplicativos de telnet como 80% do trabalho diário.
Criei o design da página inicial no Photoshop, que discutimos e aprovamos. No entanto, agora que eu entreguei a um dos outros desenvolvedores para começar a construir, ele notou que não havia botão de login (ou outro) na página - ele simplesmente possui dois campos; um para nome de usuário e outro para senha. Depois de consultá-lo, afirmei que era intencional, pois não via necessidade - a maioria das pessoas pressionava enter de qualquer maneira, pois é isso que elas precisam fazer no aplicativo de telnet. Então a discussão começou ...
Houve vários comentários feitos até o momento em que "se não houver botão, eles não saberão o que fazer" e "eles esperam o botão e farão chamadas de suporte na página que não está funcionando". Havia até sugestões de que os usuários simplesmente "ficariam sentados" sem saber o que fazer.
Agora .. minha pergunta é: Os usuários realmente precisam de um botão de login?
Estou realmente interessado em saber que tipo de porcentagem de usuários finais seria capaz de lidar com uma simples página de login que exigia que eles pressionassem Enter depois de inserir seus detalhes para continuar. É importante observar que não haveria nenhum prompt na tela para pressionar enter - eles receberiam uma dica sobre a senha informando o que fazer, mas é isso!
(Exclua os usuários móveis da briga - basta segmentar usuários comuns de desktops e laptops :)
Um exemplo da caixa de login:
Por fim, provavelmente não é uma boa ideia seguir esse caminho sem testes sérios, devido à expectativa do usuário com base nas convenções existentes.
Esse é um ponto importante, porque o que estou tirando da sua descrição é que isso ainda não foi testado e você projetou essa interface do usuário com a premissa de que seus usuários entenderiam. Geralmente, é uma má idéia: sempre receba feedback do seu público-alvo, especialmente quando você está tentando algo novo, e , especialmente em uma área central como o login.
Seu argumento de telnet é algo a ser levado em consideração, mas também entenda que você está construindo um aplicativo Web aqui e provavelmente estará lidando com a expectativa do usuário de aplicativos Web, não com o Telnet. Seu cérebro muda entre os contextos: quando você usa um aplicativo da Web, espera clicar com um único item nos itens a seguir, enquanto nos aplicativos de desktop, você pode clicar duas vezes. Reconhecer o modelo mental que os usuários têm quando eles estão usando seu aplicativo Web em oposição a um espaço diferente como o telnet é um aspecto importante do design de uma interface do usuário.
No entanto, existem alguns padrões que estão começando a divergir um pouco da convenção padrão de "fazer login ou inscrever-se". Cada um deles enfrenta os mesmos desafios: o que os usuários esperam e como você cria confiança, expectativa e descoberta em torno de algumas dessas novas idéias? Por exemplo, o StackExchange emprega logon único, o que pode ser confuso para usuários que não estão familiarizados com esse padrão. A Amazon (com sucesso) integra o registro e o logon em um formulário, embora ainda seja necessário ver a eficácia desse padrão em outros sites.
O ponto é: quando você quebra a convenção, está entrando em território desconhecido e precisa perceber o efeito que isso pode ter sobre as pessoas. Se você está pensando em fazer isso, recomendo pegar alguns "usuários comuns de desktops e laptops" do seu ambiente imediato (por exemplo, o gerente do escritório e alguém do escritório do outro lado da rua) e pedir que eles façam login Você aprenderá muito. Você pode aprender que sua suposição inicial estava correta. Mas pelo menos você terá os dados para provar isso, em vez de apenas a suposição. :-)
Editar: como você mencionou em um comentário em uma resposta à sua pergunta sobre programadores, "questionar a validade da convenção" é um bom ponto de partida, mas você deve garantir que sua resposta a essa pergunta seja baseada em dados. Qualquer pessoa pode questionar convenções, mas as convenções se tornaram convenções por um motivo: são soluções eficazes para o problema. Afastar-se daqueles sem um bom motivo (e um bom motivo no mundo da interface do usuário significa ter dados ou alguma forma de métrica) geralmente fará mais mal do que bem.
No trabalho, temos um sistema de desenvolvimento de equipe que exibe apenas o botão de login se você estiver navegando no Firefox. Sempre que uma aula é realizada, nosso serviço de assistência recebe chamadas de pessoas que não conseguem fazer login. Toda chamada tem a ver com o fato de não ver um botão de login. Agora temos que fazer o possível para informar aos usuários que eles precisam pressionar Enter para fazer login.
Seus usuários podem ser um pouco mais experientes em computadores, mas meu palpite é que você terá muitas chamadas de suporte se deixar o botão de fora.
Eu realmente gosto da resposta de Rahul, mas adicionarei meus próprios 2 centavos. Fiquei extremamente hesitante em usar a tecla Enter em qualquer formulário da Web devido à incerteza sobre sua função padrão. Só não tenho certeza do que vai fazer! Algumas pessoas não são tão cuidadosas com seus esforços de desenvolvimento e não conseguem especificar os botões padrão de um formulário corretamente, confundindo os usuários que fazem pressionam enter hábito.
Como resultado, eu me treinei para pressionar Tab e depois barra de espaço, esperando que o próximo controle após a caixa de senha seja o botão Login (ou possivelmente o Save Password (barra de seleção), porque a barra de espaço é efetivamente o mesmo que clicar em um botão do mouse sem ter que tirar um tempo para levantar as mãos do teclado e posicionar o mouse sobre um elemento da interface do usuário.
O ponto é, suponho, incluir um botão, mas verifique se é a ação padrão do formulário, e , que ele esteja configurado corretamente para ser o próximo na ordem de tabulação após a caixa de senha. Dessa forma, você satisfaz os dois conjuntos de usuários.
Se você tiver usuários cegos, a expectativa será de algum tipo de botão. Caso contrário, não haverá indicação de como efetuar login, a menos que você detecte um leitor de tela e permita um botão nesse caso específico.
Você já considerou usuários que não possuem teclado físico? Pessoas que usam um iPad ou um telefone com uma tela de toque?
E a opção de permitir que os usuários salvem suas informações de login? Ainda seria razoável omitir o botão de login? Dessa forma, como usuário, eu teria que mover minha mão do mouse para o teclado para fazer login e depois voltar ao mouse novamente para interagir ainda mais com o aplicativo.
Então eu diria: sim, você precisa de um.
Quando se trata de elementos presentes nos outros aplicativos da web, você pode tentar encontrar um recurso padrão e ver o que eles dizem: http://www.welie.com/patterns/showPattern.php?patternID= login
"Os usuários podem usar a tecla TAB para ir do campo de nome de usuário para o campo de senha e pressionar ENTER em vez de selecionar o botão 'Login'".
Geralmente, as ações são representadas embora botões/links e a interação adicional do teclado seja secundária e vista como para usuários 'avançados'.
Se você está preocupado com os motivos de usabilidade/acessibilidade, também deve ter um botão: dessa forma, os usuários podem interagir com o formulário apenas com dispositivos apontadores/mouse (copie/cole as entradas | pressione o botão) ou apenas com o teclado.
Quando li sua pergunta pela primeira vez, pensei no caso "Caixa de pesquisa". http://www.welie.com/patterns/showPattern.php?patternID=search O padrão diz que deve ter um botão, mas com o tempo (uso da produção) esse botão se tornou um ícone de lupa/no canto direito da entrada e, depois disso, avançou para um ícone de identificação alinhado à esquerda. Com o avanço das tendências (Google Instant), o botão de pesquisa se torna cada vez menos usado (mas ainda presente).
Há uma diferença entre Pesquisa e Login, antes de mais nada, porque o Login requer duas entradas; portanto, se você tentar adicionar, por exemplo, um ícone de Login, em vez do botão (como no caso da Pesquisa), onde você o colocaria, no primeira entrada, na última ou em ambas?
Como desenvolvedor, a resposta óbvia está na última, porque todo usuário deve ter digitado o nome de usuário, a senha e depois pressione enter. Portanto, no seu caso, você ouve Enter para a última entrada, mas o que acontece se o usuário estiver pressionando Enter na primeira entrada (nome de usuário um)? Por motivos de consistência, você deve ouvir as duas entradas, também porque há casos em que o usuário vê um erro e retorna à entrada do nome de usuário.
Acho que seu tipo de usuário passará nos testes e efetuará login com êxito, mas esse tipo de formulário não é ótimo para todos (você também mencionou usuários de celulares).
Exemplos de formulários de login: http://www.smileycat.com/design_elements/login_forms/
Primeiro, cheguei a isso através do Twitter e não sou programador, mas tenho um conhecimento razoável de TI.
Proposta interessante, já que há muito tempo abandonei o botão Login ao usar sites - a maioria que uso parece feliz por pressionar Enter.
Alguns pontos: o teste dos alunos da escola foi interessante, embora eu suspeite que eles achem os formulários da Web muito mais intuitivos do que os usuários adultos, especialmente aqueles que não estavam usando computadores (ZX/C64/BBC) quando cresciam. Conheço alguns de meus amigos que teriam passado alguns momentos (pelo menos) refletindo sobre o botão que faltava - e são pessoas que usam computadores todos os dias para trabalhar, mas sabem como trabalhar os aplicativos que usam.
Como o botão não existe, qual é a ação do formulário ao pressionar Enter no campo nome de usuário? Ou, menos provavelmente, o que acontece se eles digitarem a senha primeiro e pressionarem enter? Você pode precisar de algo que tenha uma ação Tab até que ambos os campos estejam completos.
Acabei de bloquear meu PC com Windows (máquina de trabalho, não tenho escolha), entrando novamente, o botão "login" do campo de senha é menos óbvio e não está identificado. Mais uma vez eu apenas uso enter.
Lá vai você, a perspectiva de um insensato;)
Se me deparei com essa página, acho que o site não foi carregado completamente ou que há algum bug no script do servidor. Por que arriscar a chance de um usuário navegar para fora do site?
Além disso, em seus testes, você considerou que pode estar obtendo taxas de sucesso mais altas do que o que realmente pode obter quando o site for lançado? Quando as pessoas sentem que estão sendo testadas, podem esperar superar algum tipo de desafio (por exemplo, um botão de login ausente) como se fosse algum tipo de teste de QI. No entanto, se eles estiverem em seus próprios navegadores da Web em casa, provavelmente terão uma mentalidade completamente diferente e agirão de maneira diferente (por exemplo, não esperariam superar nenhum desafio e, de fato, poderiam esperar exatamente o oposto. esperamos que o site faça todo o possível para acomodar todos os usuários e facilite o login, já que obviamente deseja que muitos usuários sejam felizes).
Basicamente, seu cenário de teste não é 100% semelhante ao que os usuários reais experimentarão (ou seja, seus participantes sabem que estão sendo testados e/ou testam algo), a menos que você possa reproduzir as mesmas condições exatas (ou seja, não deixe que os participantes saibam que isso é um teste), você pode tirar conclusões imprecisas com base em testes imprecisos.
Não sei exatamente como você está conduzindo os testes, mas outra coisa que pode afetar a qualidade dos testes é se outros alunos perceberem que ninguém mais tem problemas/perguntas e conseguirem fazer o login com facilidade. Isso pode fazer com que eles tentem coisas diferentes (por exemplo, pressione o botão 'retornar') até obterem os mesmos resultados que seus pares. Assim, você pode querer isolar os assuntos também.
O teste preciso pode ser uma tarefa muito difícil, pois você precisa garantir que todas as variáveis sejam exatamente iguais, exceto a variável para a qual você está testando. Desde o pouco tempo que passei pensando sobre esse problema, já identifiquei duas variáveis adicionais que podem afetar a precisão do seu teste. Pode haver outros que eu não tenha pensado.
Faça alguns testes de usabilidade e descubra o que os usuários fazem. Entendo que é um projeto, mas se importa, é importante o suficiente para testar.
Faça os dois
Faça com que o formulário se submeta assim que alguém pressionar Enter (e ambos os campos foram preenchidos) e também tenha um botão para pressionar as pessoas que amam usando o mouse.
De qualquer forma, seu usuário está feliz em fazer o que está acostumado.
Eu diria que a melhor coisa a fazer seria algo como isto:
baixar fonte bmml - Wireframes criados com Balsamiq Mockups
Você também pode fazer uma pequena seta fora do campo de texto, como é feito na tela de login do Windows 7 .
Você provavelmente gostaria de mudar o estilo do botão ... talvez fazendo com que ele se misture à caixa de texto até passar o mouse sobre ele.
A única desvantagem de ser dentro do campo de senha é que é difícil editar se você tiver uma senha longa. Apenas certifique-se de não esquecer isso!
Por fim, outras respostas sugerem que você precisa perguntar quem é seu público. Seu teste em crianças da escola, embora interessante, na verdade não fornece valor suficiente para dizer "Meu teste provou que não é necessário".
Se você removesse o botão de login, estas são algumas das coisas que você precisaria combater:
- Problemas de acessibilidade
- O que o usuário esperaria
- Dispositivos baseados em toque no futuro (Windows 7 e tablets)
Pessoalmente, trabalho com aplicativos Web no Flash Builder e, como parte da prova de conceito, passamos por testes de usabilidade. Como designers/desenvolvedores, você não pode subestimar o nível de inteligência de alguns de seus usuários. Como regra geral, eu sempre diria para fornecer a seus usuários o que eles esperariam. Somente em circunstâncias excepcionais você deve se afastar de uma convenção que se tornou tão amplamente usada.
Se o usuário demorar alguns segundos para descobrir o que fazer a seguir, você precisará reavaliar como apresentou a Interface do Usuário.
Com a tecnologia da tela de toque se tornando mais amplamente usada, não vejo esse padrão específico mudando tão cedo. Pode evoluir, mas o núcleo provavelmente permanecerá o mesmo.
Como recomendação, eu pessoalmente manteria o botão de login e permitiria ao usuário pressionar a tecla Enter para continuar, incluir um botão de login que pode ser clicado usando a guia do mouse e selecionar o botão de login usando apenas o teclado.
Isso abrange seus usuários avançados, regras de acessibilidade e usuários analfabetos de TI, mantendo a configuração padrão para uma tela de login.
Como nota lateral - Excelente resposta por Rahul parabéns!
Uma das preocupações é garantir que não haja muitas solicitações de suporte sobre alterações de botões/design ausentes e não confundir os usuários.
Para resolver isso, eu adicionaria a seguinte mensagem
Press Enter key to login
logo abaixo do campo de senha.
Isso ajudará os usuários (que podem esperar que um botão de login clique para fazer login) a saber que podem pressionar a tecla Enter para fazer o login depois de ler a mensagem. Pode ser estranho para eles pela primeira vez, mas eles pelo menos não ficarão confusos e pedirão suporte e, da próxima vez que visitarem o site, saberão o que fazer.
Os olhos dos usuários avançados ignoram a mensagem porque eles já estão usando a tecla Enter para fazer login.
Uma solução sem botão não permitiria ao usuário 5 tentativas de logon antes de bloquear sua senha.
Portanto, seu sistema está aberto a um ataque de força bruta, pois um hacker pode ter tentativas ilimitadas de adivinhar a senha?
Você pode adicionar lógica ao logon para evitar esse tipo de invasão, mas é algo que você precisa considerar.
Não sei o quanto isso é relevante, mas fiquei bastante intrigado com isso, montei uma página muito parecida com a sua captura de tela e pedi à minha esposa para experimentá-la.
ela conseguiu fazer login ok sem precisar pedir ajuda, mas notei que, depois de digitar sua senha, ela optou por usar o mouse e começou a procurar um botão. Só quando ela não encontrou, ela parou por alguns momentos e depois tentou pressionar retorno, deixando-a entrar.
Perguntando a ela o que pensava, ela disse que estava tudo bem e normal, mas depois de perguntar o que achou do botão que faltava, ela disse que estava um pouco confusa, mas pensou que, se pressionasse retornar, talvez vá para a próxima tela, como acontece quando você deseja uma nova página no Word.
Não tenho muita certeza do que ela quer dizer, mas o resultado foi que ela conseguiu entrar sem ajuda, embora tenha passado um momento procurando por um botão.
Vi um tipo semelhante de abordagem no software em que eles não precisam de um enter para verificar as credenciais. Depois que suas credenciais são inseridas e você para de digitar, elas verificam a validade dessas credenciais instantaneamente.
Se suas credenciais estiverem erradas, ela exibirá automaticamente uma mensagem de erro muito visível, informando o que deu errado e você simplesmente reinsira ou tenta novas credenciais, e o processo se repete até que você faça login com êxito.
Eu diria que você precisa de um botão de login, por vários motivos:
A maioria dos aplicativos que usei retorna o foco para o primeiro campo quando você termina de inserir dados no último campo. Agora, isso pode muito bem ser uma prática antiga que foi substituída por novas preferências, mas certamente é como espero que um formulário se comporte.
Supondo que seu aplicativo tenha outros formulários, é provável que sejam mais complicados que o formulário de login e exija a presença de um botão ENVIAR, o que é realmente todo o seu botão de login. Dado que esses formulários precisarão do botão, faz sentido ter o botão em todos os formulários, para evitar confusão.
Nem todo navegador trata a tecla ENTER da mesma maneira. Novamente, isso pode muito bem ser um problema da velha escola, mas lembro-me de ter problemas com o comportamento da tecla ENTER quando havia apenas um campo. Em alguns navegadores, era o mesmo que SUBMIT, em outros navegadores, o botão SUBMIT ainda precisava ser clicado. O ponto principal foi que não era controlado pelo seu aplicativo, mas sim pelo navegador. Por isso, aprendi há muito tempo a nunca assumir nada sobre a tecla ENTER e a confiar sempre em SUBMIT. Novamente, isso pode não ser mais um problema, mas eu nunca tive um problema ao seguir este princípio, então não vejo razão para mudar.
Para nossos aplicativos da web usados internamente, usamos o recurso de login automático.
O usuário simplesmente digita o endereço ou clica no favorito/marcador favorito e é automaticamente reconhecido e autorizado a entrar. Como fizemos isso, não tenho certeza porque sou o designer gráfico residente.
Isso pode ter sido feito como parte do administrador, criando perfis, segurança e permissões para os funcionários conhecidos? Possivelmente de seu IP?
Como alguém que entrava rotineiramente no aplicativo para verificar o design, era bom não ter que fazer login todas as vezes.
Mais uma vez, sou designer e, por isso, há algumas coisas que não estou levando em consideração, mas para funcionários conhecidos que trabalham em aplicativos internos, isso foi bastante agradável.
Eu acho que a resposta aqui é scripts. Se um usuário não pressionar Enter dentro de um período de tempo predeterminado, notifique-o de que ele deve pressionar Enter para efetuar login, porque é possível que não tenha entendido. Para as poucas pessoas que têm scripts desativados, você pode detectá-lo de várias maneiras e pressionar um botão.