Formulários de registro de usuário - precisamos de um nome de usuário?


11

Digamos que estamos criando um novo formulário de registro de site.

Eu precisaria fornecer um espaço para um nome de usuário ou simplesmente exigiria um endereço de e-mail?

Existem problemas sérios com um desses métodos?

Respostas:


8

Dependendo do seu público-alvo ( 'normal', mais experiente muito tecnologia, ou originadas de redes sociais) quer :

  • endereço de e-mail e senha (o endereço de e-mail é o nome de usuário)

ou

Ambos têm seus problemas.

Em algumas audiências, os endereços de e-mail mudam bastante. Você precisa de um bom mecanismo de recuperação de conta, de preferência com a opção de adicionar vários endereços de email a cada conta. Ainda assim, os endereços de email como nomes de usuário são superiores aos nomes de usuário escolhidos porque as pessoas podem se lembrar deles, e usar apenas email + senha simplifica o processo de inscrição.

OpenID, Facebook Connect etc são ótimos. Mas o indireção de "Estou no site B e não consigo fazer login. Preciso ir ao site A para verificar minhas credenciais" ainda não é compreendido pelo mercado de massa. O OpenID funciona muito bem com públicos muito entendidos em tecnologia, como ilustrado pelos sites do Stack Exchange ...

Conclusão: você precisa considerar cuidadosamente seu público-alvo e, se possível, executar um teste de usabilidade de diferentes mecanismos de autenticação.


+1 público-alvo é fundamental, mas Facebook Connect parece duvidoso para qualquer coisa que se destina a permanecer vivo para os próximos 5 anos (lembre MySpace Friendster?)
danlefree

@danlefree: ponto muito válido, eu concordo. Pessoalmente, eu não ficaria feliz com o Facebook Connect, a menos que o público-alvo seja ~ 100% dos usuários do Facebook (talvez um jogo viral de rede social ou algo assim ..). Nem todo mundo está no Facebook, no entanto, e o modelo de login federado não é algo que o usuário médio é treinado no entanto, como mencionado ...
Jesper M

1
As pessoas mais velhas (bem, eu diria que alguém com mais de 18 anos) tendem a não mudar suas contas de e-mail com tanta frequência; portanto, se você estiver segmentando adultos, o endereço de e-mail pode ser um bom. Devido ao meu ódio pessoal a nomes de usuário, mudamos nosso modelo apenas para o endereço de email e funcionou muito bem. Porém, temos como alvo profissionais que tendem a usar seus endereços de e-mail de trabalho para se registrar. Um formulário de registro bem pensado é tão importante quanto escolher o mecanismo de login. Diminuímos o nosso de mais de 20 campos para apenas 5 (incluindo 'senha repetida') e nossos registros triplicaram da noite para o dia.
Mark Henderson

2

Há problemas com ambos, acredite ou não.

As pessoas mudam seus emails quase constantemente, ao que parece. Quanto mais jovens eles são, pior é. Por esse motivo, é difícil vincular contas a email. No entanto, os e-mails parecem muito mais fáceis de lembrar do que os nomes de usuário.

Os nomes de usuário são ótimos, pois muitas vezes não mudam, mas as pessoas geralmente os esquecem. Então você precisa lidar com um sistema de recuperação de senha E um sistema de recuperação de nome de usuário. Dobrar o trabalho, metade da diversão.

Eu pessoalmente faço as duas coisas quando estou criando um site sem algum tipo de sistema de identificação aberto. Eu coleciono os dois, armazeno os dois no banco de dados e procuro com base no valor de login inserido para ver qual eles pretendem usar. Obviamente, isso significa que não há símbolos @ nos nomes de usuários. No entanto, torna bastante fácil para meus usuários lembrar de pelo menos uma das duas opções. Para recuperação, uso um sistema de desafio, pois desconfio de emails para fins de validação. Os hackers podem receber e-mails ... talvez não saibam qual é o nome do primeiro cachorro ou o carro favorito de uma pessoa.

O OpenId parece tornar muito importante esse argumento. É uma coisa boa para conferir.


1

Também pode depender de como você armazena suas informações de usuário. Por exemplo, se você usar um banco de dados com a chave primária como nome de usuário, provavelmente não desejará usar o endereço de email como nome de usuário, pois se o usuário alterar o endereço de email, isso mudará a chave primária (e estrague tudo) referências de chave estrangeira).


1
Obrigado por contribuir. Respeitosamente, não concordo totalmente. Primeiro, os detalhes da implementação não devem 'brilhar' na interface do usuário. Segundo, se não houver uma chave natural (e-mail fx) que pareça perfeitamente adequada e imutável, uma chave substituta (INT com incremento automático de fx) sempre deve ser usada como chave primária. Esta regra de design de software é realmente importante e pode evitar muitos problemas. :-)
Jesper M

1
@ Jesper - eu concordo totalmente. Mas, às vezes, como desenvolvedor, você não tem controle sobre como os dados são armazenados (você pode estar interagindo com um provedor de dados externo). Por exemplo, se você estivesse usando o ASP.NET e o provedor de associação padrão, os nomes de usuário seriam a chave principal e você não conseguiria mudar isso. Só uma coisa a considerar ...
Dan Diplo

1

Você pode desejar ter um campo de nome de usuário se desejar que os usuários ocultem seu endereço de e-mail ou nome real de outros usuários / visitantes.

Geralmente, é chamado de apelido nesses casos, e às vezes pode ser alterado rapidamente, sem afetar o login do usuário.

Acho que a resposta depende do que você fará com as informações coletadas, por exemplo, não enviar e-mails do usuário - não peça um endereço de e-mail, não exiba informações do usuário, não colete um apelido etc.


1

Nome de usuário, endereços de email e OpenId têm seus prós e contras.

Mas nunca chame o nome de usuário e exija que seja um endereço de e-mail!

Ao registrar, insiro um dos meus nomes de usuário preferidos como nome de usuário. E fico com raiva quando - depois de clicar em OK - recebo uma mensagem informando que o nome de usuário não é um endereço de email válido.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.