Eu me formei em Ciência da Computação pela Universidade da Virgínia em 1992. O motivo de ser menor e não maior é que, para se formar em CS na UVa, o senhor tinha que passar pela Escola de Engenharia, e eu não fui feito para esse tipo de matemática e física pesadas, para dizer o mínimo. A beleza de uma especialização é que eu podia escolher todas as aulas legais de CS e pular todo o resto.
Uma das minhas aulas favoritas, a que mais me lembro, foi Algoritmos. Eu sempre dizia às pessoas que a aula de Algoritmos era a parte da minha formação universitária que mais me influenciou como programador. Eu não sabia exatamente por quê, mas há alguns anos tive um palpite e procurei um determinado currículo e percebi que Randy Pausch – sim, o Última Palestra Randy Pausch – deu essa aula. O momento é perfeito: Universidade da Virgínia, outono de 1991, CS461 Analysis of Algorithms (Análise de Algoritmos), 50 alunos.
Eu era um deles.
Não é de se admirar que eu tenha ficado tão impressionado. Pausch era um professor incrível e carismático, um testemunho do velho ditado que diz que o senhor deve escolher seu professor primeiro e o material da aula depois, se é que se dá ao trabalho de escolher. Isso é tão verdadeiro.
Nesse caso, a combinação de um ótimo professor e um ótimo tópico foi ainda mais potente, pois os algoritmos são fundamentais para o trabalho dos programadores. Não que inventemos novos algoritmos, mas precisamos entender o código que existe, compreender por que ele tende a ser rápido ou lento devido às compensações escolhidas e escolher o correta algoritmos para o que estamos fazendo. Isso é essencial.
E uma das coisas mais legais que o Sr. Pausch me ensinou foi fazer essa pergunta:
Qual é o algoritmo de Deus para isso?
Bem, ao classificar uma lista, obviamente Deus não se incomodaria com um estúpido Bubble Sort ou Quick Sort ou Shell Sort como nós, meros mortais, Deus apenas colocaria imediatamente os itens na ordem correta. Pimba. Um passo. O limite inferior definitivo da computação, O(1). Não apenas em tempo fixo, mas literalmente em uma etapa instantânea, porque o senhor é Deus.
Na época, isso me surpreendeu.
Sempre suspeitei que os programadores se tornaram programadores porque eles podiam brincar de Deus com as pequenas caixas do universo em suas mesas. Randy Pausch pegou esse conceito e o transformou em uma maneira realmente útil de estabelecer limites e fazer perguntas difíceis sobre o que o senhor está fazendo e por quê.
Portanto, quando nos propusemos a criar uma caixa de diálogo de login para o DiscursoVoltei ao que aprendi em minha aula de Algoritmos e me perguntei:
Como Deus criaria essa caixa de diálogo de login?
E a resposta é, é claro, Deus não se daria ao trabalho de criar uma caixa de diálogo de login. Todos os usuários já estariam conectados ao GodApp no momento em que carregassem a página, porque Deus sabe quem eles são. Com autoridade, inclusive.
Isso é obviamente impossível para nós, porque Deus não é um de nossos investidores.
Mas… como o senhor podemos chegar perto? à experiência de login perfeita e divina no Discourse? Essa é uma meta nobre e digna.
Não foi Bill Gates que perguntou uma vez por que diabos todos os programadores estavam escrevendo sempre as mesmas caixas de diálogo File Open? Com certeza é isso que acontece com as caixas de diálogo de login. Há muito tempo venho dizendo que o o melhor login é não fazer nenhum login e eu sou um firme defensor do fazendo login com sua carteira de motorista da Internet sempre que possível. Portanto, apoiamos totalmente essa opção, se o senhor a tiver configurado.
Mas hoje quero me concentrar no experiência básica de login: usuário e senha. Esse é o padrão até que o senhor configure os outros métodos de login.
Um formulário de login com dois campos, dois botões e um link parece simples, certo? Padrão do pântano. E é, até que o senhor considere todas as maneiras pelas quais o simples ato de fazer login com esses dois campos pode dar errado para o usuário. Vamos pensar.
Permita que o usuário digite um e-mail para fazer login
A falha crítica do OpenID, tanto quanto eu tenha gostado como uma solução de login inicial, foi a suposição de que os usuários poderiam aceitar um URL como sua “identidade”. Isso é uma grande loucura e, a longo prazo, essa suposição central e falha do OpenID o quebrou como um padrão futuro.
A identidade do usuário é sempre o e-mail, pura e simplesmente. O que acontece quando o senhor esquece sua senha? O senhor recebe um e-mail, certo? Portanto, o e-mail é sua identidade. Algumas pessoas até propõem que o usar o e-mail como o único método de login.
É bom ter um nome de usuário, é claro, mas o sempre permita que os usuários façam login com seu nome de usuário ou seu endereço de e-mail. Porque posso dizer ao senhor com 100% de certeza que, quando esses usuários esquecerem a senha, e isso acontece o tempo todo, eles precisarão desse e-mail para redefinir a senha. E-mail e senha são conceitos fortemente relacionados e devem estar juntos. Sempre!
(E um adeus aos serviços que não permitem que eu use meu e-mail como nome de usuário ou login. Estou olhando para o senhor, Comixology).
Avise o usuário quando o e-mail dele não existir
OK, sabemos que o e-mail é a identidade de fato para a maioria das pessoas, e esse é um estado de coisas lógico e necessário. Mas o que dos meus 10 endereços de e-mail eu usei para entrar no seu site?
Essa foi a fonte de um longa discussão no Discourse sobre se fazia sentido revelar ao usuário, quando ele digita um endereço de e-mail no formulário “forgot password” (esqueci a senha), se temos esse endereço de e-mail em arquivo. Em muitos sites, este é o tipo de mensagem que o senhor verá depois de inserir um endereço de e-mail no formulário de esquecimento de senha:
Se uma conta corresponder a name@example.comO senhor deve receber um e-mail com instruções sobre como redefinir sua senha em breve.
Observe o tímido “se”, que é um que se protege contra todas as implicações de segurança de revelar se um determinado endereço de e-mail existe no site apenas digitando-o no formulário de esquecimento de senha.
Levamos muito a sério a escolha de padrões seguros para o Discourse, de modo que, imediatamente, o senhor não será explorado, abusado ou invadido por spammers. Mas depois de experimentar o estado de login do mundo real “qual e-mail usamos aqui de novo?” em dezenas de instâncias do Discourse, percebemos que, nesse caso específico, ser amigável é maneira mais importante do que estar seguro.
O novo padrão é informar às pessoas quando elas inserem um e-mail que não reconhecemos no formulário de esquecimento de senha. Isso salvará a sanidade delas e a sua. O senhor pode ativar a segurança extra de ser discreto em relação a isso, se necessário, por meio de uma configuração do site.
Permita que o usuário alterne entre Log In e Sign Up a qualquer momento
Muitos sites começaram a mostrar botões de login e de inscrição lado a lado. Isso me deixou perplexo; os atos de fazer login e de se inscrever não são coisas muito diferentes?
Bem, do ponto de vista do usuário, não parecem ser. Essa caixa de diálogo de login do Verge ilustra como os formulários de inscrição e de login estão realmente próximos. Veja este GIF animado em ação.
Reconhecemos essa semelhança fazendo com que ambos os formulários possam ser acessados a qualquer momento a partir dos dois botões na parte inferior do formulário, como uma alternância:
E ambos podem ser acionados diretamente de qualquer página por meio dos botões Sign Up e Log In no canto superior direito:
Escolha palavras comuns
Esse é o problema da linguagem, temos tantos palavras para esses conceitos:
- Entrar
- Fazer login
- Registrar-se
- Registre-se
- Registre-se no <site>
- Criar conta
- Começar a usar
- Assine
Quais são os “certos”? Os dados da pesquisa com usuários não são conclusivos.
Costumo preferir as versões mais curtas sempre que possível, principalmente porque sou fã de toda essa coisa de brevidade, mas há coisas válidas casos válidos a serem apresentados para cada um, dependendo das circunstâncias e das preferências do usuário.
Sign In pode ser um pouco mais comum, embora Log In tenha algumas base de computação náutica e histórica que o torna digno:
Há alguns anos, fiz uma pesquisa sobre os principais sites dos EUA e do Reino Unido e se eles usavam “sign in”, “log in”, “login”, “log on” ou alguma outra variante. Na época, a resposta parecia ser que, se o senhor combinasse “log in” e “login”, superava “sign in”, mas não muito. Também notei que a tendência de “entrar” está aumentando, especialmente nos serviços mais populares. O Facebook parece ser o único que não usa o “login”.
Trabalhe com gerenciadores de senhas de navegador
Toda caixa de diálogo de login que o senhor criar deve ser testada para funcionar com os gerenciadores de senhas padrão do …
No mínimo. Nos logins subsequentes nesse navegador, o nome de usuário e a senha devem ser preenchidos automaticamente.
Os usuários contam com esses gerenciadores de senhas padrão incorporados aos navegadores que usam, e qualquer formulário de login moderno e adequado deve respeitar isso e ser projetado de forma sensata, por exemplo, o campo de senha deve ter type="password" no HTML e um nome que possa ser facilmente identificado como um campo de entrada de senha.
Há também o LastPass e assim por diante, mas geralmente presumo que, se a caixa de diálogo de login funcionar com os gerenciadores de senhas embutidos no navegador, ela também funcionará com utilitários de terceiros.
Lidar com erros comuns dos usuários
Ops, o usuário está digitando a senha com a tecla caps lock ativada? O senhor deve informá-lo sobre isso.
Oops, o usuário digitou seu e-mail como name@gmal.com em vez de name@gmail.com? Ou name@hotmail.cm em vez de name@hotmail.com? O senhor deve corrigir erros de digitação em domínios de e-mail comuns para eles ou informá-los sobre isso.
(Também sou um grande fã do suporte nativo a “revelar senha” no navegador para o campo de senha, para que o usuário possa verificar se digitou ou preencheu automaticamente a senha esperada. Somente o Internet Explorer e o I pensam O Safari oferece isso, mas todos os navegadores deveriam).
Ajude os usuários a escolher senhas melhores
Há muitas escolas de pensamento sobre forçando ajudar os usuários a escolher senhas que não sejam indescritivelmente horríveis, por exemplo password123 e iloveyou e assim por diante.
Há o medidor de força da senha comum, que é atualizado em tempo real à medida que o usuário digita no campo de senha.
A ideia é inteligente, mas, em alguns sites, ela se torna muito pregativa para o meu gosto. A implementação também deixa muito a desejar, pois fica a critério do proprietário do site decidir o que significa a força da senha. O “bom” de um site é o “saia daqui com essa senha de brinquedo Fisher-Price” de outro. É frustrante.
Assim, com o Discourse, em vez de tudo isso, decidi que usaríamos como padrão um comprimento de senha mínimo absoluto e sólido de 8 caracteres e, em seguida, verificaríamos a senha para garantir que não seja uma das 10.000 senhas conhecidas mais comuns verificando seu hash.
Não se esqueça do teclado
Sinto que os usuários de teclado são uma raça em extinção neste momento, mas para aqueles de nós que, quando recebem uma caixa de diálogo de login, gostam de digitar rapidamente
name@example.com, guia, p4$$w0rd, entrar
… por favor verifique se isso funciona como deveria. Ordem das guias, enter para enviar, etc.
Limite de taxa para todos os itens
O senhor deve ser limitar a taxa de tudo o que os usuários podem fazer, em todos os lugarese isso se aplica especialmente à caixa de diálogo de login.
Se alguém esquecer sua senha e fizer três tentativas de login ou emitir três solicitações de esquecimento de senha, provavelmente não haverá problema. Mas se alguém faz mil tentativas de login ou emite mil solicitações de esquecimento de senha, isso é um pouco estranho. Eu até me atreveria a supor que o senhor está … não humano.
O senhor pode fazer coisas sofisticadas, como desativar temporariamente as contas ou começar a exibir um CAPTCHA se houver muitas tentativas de login com falha, mas isso pode facilmente se tornar um vetor de griefing, portanto, tenha cuidado.
Acho que um bom meio termo é inserir pausas padrão de tamanho moderadamente crescente após repetidas falhas sequenciais ou repetidas solicitações sequenciais de esquecimento de senha do mesmo endereço IP. Então é isso que fazemos.
Coisas que esqueci
Tentei me lembrar de tudo o que fizemos quando estávamos criando nossa caixa de diálogo de login ideal para o Discourse, mas tenho certeza de que esqueci algo ou poderia ter sido mais minucioso. Lembre-se, O Discourse é 100% de código aberto e, por definição, um trabalho em andamento – portanto, como meu amigo Miguel de Icaza gosta de dizer que, quando ele quebra, o senhor fica com as duas metades. Fique à vontade para testar nossa implementação e nos dar sua opinião nos comentários, ou indicar outros exemplos de experiências de login excelentes, ou citar outros conselhos úteis.
O login envolve um formulário simples com dois campos, um link e dois botões. E, no entanto, depois de ler tudo isso, tenho certeza de que o senhor concordará que é enganosamente complexo. A melhor maneira de agir é não criar uma caixa de diálogo de login e, em vez disso, confiar na autenticação de uma fonte externa sempre que possível.
Como, por exemplo, Deus.
| [advertisement] Como o(a) senhor(a) está exibindo o seu incrível? Crie um Perfil do Stack Overflow Careers e mostre todo o seu trabalho árduo no Stack Overflow, no Github e em praticamente todos os outros sites de codificação. Quem sabe, o senhor pode até ser recrutado para uma grande novo cargo! |