Ryan Singer: 10 советов по дизайну форм регистрации

[@hlomzik]

3. Если есть информация, которая может вам понадобиться о пользователе — выясните ее в самом приложении, а не во время регистрации;

Этому как раз очень многие стартапы следуют, не спрашивая вообще ничего, кроме мыла и пароля.
Сложно сказать, насколько это эффективно, я бы добавлял еще пару полей во избежание множества аккаунтов-зомби...

Вообще, довольно грамотно и многим было бы полезно, особенно подходить к регистрации как к процессу.

[@dmitrysatin]

Даже пароль при регистрации можно не спрашивать :) Нужен только email или телефончег :)
Серьезно! Это, конечно, может привести к множеству мусорных регистраций, зато конверсия из посетителей в регистрации будет бешенная.

[@dmitrysatin]

Конверсия, в данном случае, это отношение количества посетителей сайта к количеству регистраций на сайте.

[@dmitrysatin]

Очень подробно не смогу, сил на лекцию сейчас не хватит. Думаю, Вы найдете без труда много текстов в сети.

Есть предположение, подтверждаемое статистикой, что чем больше полей в форме регистрации, тем меньше вероятность, что человек зарегистрируется.

Это похоже на эксперименты с крысами: чтобы добраться до сыра (приманки) крыса может стерпеть удар электрического тока (определенной силы) от прутьев клетки, по которым лежит путь к сыру. Сила удара, который крыса готова стерпеть, зависит от привлекательности сыра и от степени голода, который она испытывает.

Бывают сложные формы, с множеством требований (иногда неочевидных) по её заполнению. Если привлекательность сервиса высока, то изголодавшийся пользователь пройдет через испытание регистрационной формы. Если же назначение сервиса неочевидно, т.е. ценность непонятна, то и небольшая форма может стать непреодолимым препятствием.

Разрабатывая популярные сервисы, следует стремиться к тому, чтобы снять лишние препятствия на пути пользователя. Если же сервис секретный, и допуск ограничен, то можно и поглумиться над пользователем, чтобы потешить службу безопасности :)

[@atermath]

с аккаунтами-зомби лучше стараться бороться самим, а не перекладывать это на плечи пользователей, если задача стоит в привлечении посетителей. Но это отдельная большая проблема.

[@HEm]

это можно сделать и после регистрации

[@iamAnton]

А всегда ли нужна регистрация? И зачем она нужна?

[@killerdesign]

Кажется этот вопрос недавно поднимался на хабре, когда речь шла о социальных сетях без необходимости регистрации в оных (в качестве примера - Wordstream на баше). Ну, и как оказалось, со временем сайты подобные ресурсы превращаются в помойку. Выводы делайте сами. :)

[@shadchnev]

Отсутствие регистрации еще не означает анонимность - можно аутентифицироваться через сторонние сайты или openid. Например, я сейчас работаю над сервисом, который аутентифицируется через фейсбук, потому что моя целевая аудитория на 99%, если не на 100%, на фейсбуке. Бардака не будет, регистраций тоже.

[@btf]

Задавайте простые вопросы и перегружайте форму текстом;

может таки не перегружайте? :)

[@atermath]

Спасибо большое - проглядел. Поправил :-)

[@fayona]

согласна с автором на 100%.
Спасибо за полезную заметку ;)

[@badlittleduck]

Читая вот этого товарища Luke Wroblewski узнал несколько не плохих фич для формы. Хотя думал, что о дизайнах форм знаю всё

[@fayona]

еще было бы здорово, если бы рядом с полем ввода пароля была галочка "Показать пароль". Потому что чаще всего около компьютера находишься в одиночку, никто пароль подсмотреть не может, но ошибиться при вводе пароля и подтверждения пароля очень легко (не убрав CapsLock, или находясь не в той раскладке).
А когда пароль никто не может посмотреть, кроме тебя, то почему бы мне не отобразить его? ТОгда ошибок будет значительно меньше..
А вы как думаете? ;)

[@atermath]

ход хороший, но не во всех случаях. Ход лучший (на мой взгляд) - первый вход без пароля вообще. С последующей высылкой его на почту и/или настойчивой просьюой установить его.

[@atermath]

*просьбой (простите)

[@badlittleduck]

Уже ответили на ваш вопрос. Но когда я впервые увидел ответ на свой комментарий,то мысли были следующие:

- Неплохая фича, имеющая право на существование
- Я не соглашусь с aremath о беспаролевом входе. Зато классическое подтверждение на e-mail содержащее информацию о аккаунте (логин и пароль) поможет напомнить пароль в случае если вы его забудете. При этом в хороших системах должна быть возможность поменять пароль + запоминать пароль. Я считаю, что пароль пользователю надо "почувствовать" при вводе (хи-хи), но один раз!

[@atermath]

на мой вкус — зависит от сервиса. Иногда пароль надо почувствовать, иногда — нет.

[@m151]

На счёт "показать пароль"... сомнительная фича. Ещё ни разу не видел, чтобы человек набирал пароль и смотрел на окно ввода. Начиная от секретарш, заканчивая программистами.

Самая лучшая реализация, это JS проверка совпадения паролей и, в случае несовпадения, показывать это. (понравилась фишка с затуханием цвета фона от красного до белого + input#passwd {border: 2px solid #f00;}

[@fayona]

ну не знаю ;)
миллион раз встречалась с тем, как пользователи не правильно вводят пароль, либо не в той раскладке, либо капслоком, либо буквы перепутают.
А уж когда просят их ввести пароль, а потом подтверждение пароля, то каждый третий-четвертый делает ошибку ))) доказано тестированиями ;)
вспомните, разве Вы никогда не ошибались?
А потому пользователи и не смотрят на экран при вводе пароля, потому что смотреть то не на что, там одни ****** ;)))))

[@romy4]

Всё просто и понятно, но не могу согласиться только со (2) пунктом. Это создаёт ряд проблем для пользователей (не стоит забывать, что мы в районе СНГ, а не Европа/Америка):
1) частые запросы могут нагрузить машинку пользователя (далеко не у всех стоят Коры Дуба)
2) частые запросы при большой нагрузке на сервере (если форма ждёт ожидания валидации введённого ника) могут очень негативно влиять на скорость ввода в форму.

[@morhekil]

1) частые запросы могут нагрузить машинку пользователя (далеко не у всех стоят Коры Дуба)

Частые в данном случае - это какие? Если взять среднюю длину имени символов за 10, то это максимум - 10 запросов. При быстром вводе, несомненно, нужно выдавать запрос не после каждого символа, а после паузы - итого получаем ещё меньше. Если менее 10 js-запросов нагрузят пусть даже самую слабую машинку пользователя - полагаю, стоит серьёзно задуматься о переписывании соответствующего кода.

[@romy4]

Здесь дело не в общем количестве символов, а скорости набора. Надо полагать, что пользователь (среднестатистический) вводит от 1 до 3 символов в секунду. При условии большой нагрузки на сервер, это может создать проблемы.

[@morhekil]

конечно, но как я уже написал - нет смысла выдавать по запросу на каждое нажание, всё равно пользователь все результаты не увидит. См. Submission Throttling Pattern

[@dmx]

Для вас это баг, так как вы понимаете какое поле к чему. А представим себе, что кому-то непонятно значение какого-то поля и он хочет посмотреть подсказку. Ему нужно будет щелкать по табу непредвиденное кол-во раз причем без какой-либо логики.

[@atermath]

Ну можно еще добавить привязывание лейбла к полю ввода (forLabel кажется, я не верстальщик). А так да.

[@sashock]

да, все лежит на поверхности, но как показывает практика большинство сайтов обустроены ужасной регистрационной формой и очень бесят ошибки типа "такой ник уже есть" после того как ты ввел 15 полей инфы и она после этого еще и обнулилась

[@fayona]

согласна ;)
это ужасно раздражает