Форми реєстрації користувача - чи потрібно нам ім’я користувача?


11

Скажімо, ми розробляємо нову реєстраційну форму веб-сайту.

Чи потрібно мені вказати простір для імені користувача чи мені просто потрібна адреса електронної пошти?

Чи є якісь серйозні проблеми з будь-яким із цих методів?

Відповіді:


8

В залежності від вашої цільової аудиторії ( «нормальні», дуже розбираються в технологіях, або походить з соціальних мереж) або :

  • електронна адреса та пароль (адреса електронної пошти - це ім’я користувача)

або

У обох є свої проблеми.

У деяких аудиторіях адреси електронної пошти сильно змінюються. Вам потрібен хороший механізм відновлення облікового запису, бажано з можливістю додавання декількох адрес електронної пошти до кожного облікового запису. Але все-таки адреси електронної пошти як імена користувачів перевершують власні обрані імена користувачів, оскільки люди можуть запам'ятати їх, а використання просто електронної пошти + пароля спрощує процес реєстрації.

OpenID, Facebook Connect тощо чудові. Але посередництво "Я на сайті B , і я не можу увійти. Мені потрібно зайти на сайт А, щоб перевірити свої облікові дані", на масовому ринку поки що не зрозуміла. OpenID чудово працює з аудиторіями, які користуються технологіями, як показано на сайтах Stack Exchange ...

Висновок: Вам потрібно ретельно розглянути цільову аудиторію та, якщо можливо, провести тест на корисність передпокою різних механізмів аутентифікації.


+1 Цільова аудиторія є ключовою, але Facebook Connect здається непростим для всього, що має намір жити протягом наступних 5 років (пам'ятаєте MySpace? Friendster?)
danlefree

@danlefree: Дуже вірний пункт, я згоден. Особисто я не був би задоволений Facebook Connect, якщо цільова аудиторія не становить ~ 100% користувачів Facebook (можливо, вірусна гра в соціальних мережах чи щось ..). Ще не всі є у Facebook, і федеративна модель входу ще не те, на чому перешкоджає пересічний користувач, як згадувалося ...
Jesper M

1
Люди похилого віку (ну, я б сказав, кому хтось старше 18 років) прагнуть не змінювати свої облікові записи електронної пошти так часто, тому якщо ви орієнтуєтесь на дорослих, то адресу електронної пошти може бути корисним. Через мою особисту ненависть до імен користувачів ми переключили нашу модель тільки на адресу електронної пошти, і це спрацювало дуже добре. Хоча ми орієнтуємось на професіоналів, які, як правило, використовують свої робочі адреси електронної пошти для реєстрації. Добре продумана реєстраційна форма настільки ж важлива, як і вибір механізму входу. Ми знизили наше поле з 20+ полів лише до 5 (включаючи "повторити пароль"), і наші реєстрації втричі зросли втричі.
Марк Хендерсон

2

З обома проблемами, вірите чи ні.

Здається, люди змінюють електронну пошту майже постійно. Чим вони молодші, тим гірше. З цієї причини важко пов’язати облікові записи електронною поштою. Однак електронні листи здаються людям набагато легшими, ніж імена користувачів.

Імена користувачів чудові тим, що вони часто не змінюються, але люди часто їх забувають. Тоді вам доведеться мати справу і з системою пошуку паролів, і з системою пошуку імені користувача. Подвоїти роботу, половину задоволення.

Я особисто роблю обидва, коли я роблю сайт без якоїсь відкритої системи ідентифікації. Я збираю обидва, зберігаю обидва в БД, потім шукаю на основі введеного значення входу, щоб побачити, який з них вони мали намір використовувати. Очевидно, це означає відсутність символів @ в іменах користувачів. Однак моїм користувачам досить легко запам'ятати принаймні один із двох варіантів. Для пошуку я використовую систему викликів, оскільки я насторожено пишу електронну пошту для цілей перевірки. Хакери можуть отримувати електронні листи ... вони можуть не знати, що ім'я першої собаки або улюблений автомобіль людини.

Здається, OpenId робить цей аргумент менш важливим. Це добре перевірити.


1

Це також може залежати від того, як ви зберігаєте свою інформацію користувача. Наприклад, якщо ви використовуєте базу даних, яка має основний ключ як ім'я користувача, ви, ймовірно, не хочете використовувати адресу електронної пошти як ім'я користувача, оскільки якщо користувач змінить свою адресу електронної пошти, то це змінить первинний ключ (і викрутить будь-які закордонні ключові посилання).


1
Дякуємо за ваш внесок. З повагою я не зовсім згоден. По-перше, деталі реалізації, як правило, не повинні «просвічуватись» в інтерфейсі користувача. По-друге, якщо немає природного ключа (електронної пошти fx), який здається ідеально підходящим та незмінним, то сурогатний ключ (автоматичний приріст fx INT) завжди повинен використовуватися як первинний ключ. Це правило розробки програмного забезпечення дійсно важливе і може уникнути безлічі проблем. :-)
Jesper M

1
@ Jesper - я повністю згоден. Але іноді як розробник у вас немає контролю над тим, як зберігаються дані (можливо, ви взаємодієте із зовнішнім постачальником даних). Наприклад, якщо ви використовували ASP.NET і використовували постачальника членства за замовчуванням, то імена користувачів будуть основним ключем, і ви не зможете це змінити. Тільки, що варто врахувати ...
Dan Diplo

1

Ви можете мати поле для імені користувача, якщо бажаєте, щоб користувачі приховували свою електронну адресу або справжнє ім’я від інших користувачів / відвідувачів.

У цих випадках його часто називають псевдонімом, а іноді його можна змінити під час руху, не впливаючи на логін користувача.

Я думаю, що відповідь залежить від того, що ви збираєтеся робити зі зібраною інформацією, наприклад, не надсилаючи електронні листи користувача - не вимагайте електронної адреси, не показуйте інформацію про користувача, не збирайте прізвисько тощо.


1

Ім'я користувача, електронні адреси та OpenId мають свої плюси і мінуси.

Але ніколи не називайте це ім'ям імені і не вимагайте, щоб це була електронна адреса!

Під час реєстрації я ввожу одне із своїх бажаних імен користувачів як ім’я користувача. І мене це злить, коли після натискання кнопки ОК я отримую повідомлення про те, що ім’я користувача не є дійсною адресою електронної пошти.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.