Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
3. Если есть информация, которая может вам понадобиться о пользователе — выясните ее в самом приложении, а не во время регистрации;
Этому как раз очень многие стартапы следуют, не спрашивая вообще ничего, кроме мыла и пароля.
Сложно сказать, насколько это эффективно, я бы добавлял еще пару полей во избежание множества аккаунтов-зомби...
Вообще, довольно грамотно и многим было бы полезно, особенно подходить к регистрации как к процессу.
Даже пароль при регистрации можно не спрашивать :) Нужен только email или телефончег :)
Серьезно! Это, конечно, может привести к множеству мусорных регистраций, зато конверсия из посетителей в регистрации будет бешенная.
Серьезно! Это, конечно, может привести к множеству мусорных регистраций, зато конверсия из посетителей в регистрации будет бешенная.
Конверсия, в данном случае, это отношение количества посетителей сайта к количеству регистраций на сайте.
Очень подробно не смогу, сил на лекцию сейчас не хватит. Думаю, Вы найдете без труда много текстов в сети.
Есть предположение, подтверждаемое статистикой, что чем больше полей в форме регистрации, тем меньше вероятность, что человек зарегистрируется.
Это похоже на эксперименты с крысами: чтобы добраться до сыра (приманки) крыса может стерпеть удар электрического тока (определенной силы) от прутьев клетки, по которым лежит путь к сыру. Сила удара, который крыса готова стерпеть, зависит от привлекательности сыра и от степени голода, который она испытывает.
Бывают сложные формы, с множеством требований (иногда неочевидных) по её заполнению. Если привлекательность сервиса высока, то изголодавшийся пользователь пройдет через испытание регистрационной формы. Если же назначение сервиса неочевидно, т.е. ценность непонятна, то и небольшая форма может стать непреодолимым препятствием.
Разрабатывая популярные сервисы, следует стремиться к тому, чтобы снять лишние препятствия на пути пользователя. Если же сервис секретный, и допуск ограничен, то можно и поглумиться над пользователем, чтобы потешить службу безопасности :)
Есть предположение, подтверждаемое статистикой, что чем больше полей в форме регистрации, тем меньше вероятность, что человек зарегистрируется.
Это похоже на эксперименты с крысами: чтобы добраться до сыра (приманки) крыса может стерпеть удар электрического тока (определенной силы) от прутьев клетки, по которым лежит путь к сыру. Сила удара, который крыса готова стерпеть, зависит от привлекательности сыра и от степени голода, который она испытывает.
Бывают сложные формы, с множеством требований (иногда неочевидных) по её заполнению. Если привлекательность сервиса высока, то изголодавшийся пользователь пройдет через испытание регистрационной формы. Если же назначение сервиса неочевидно, т.е. ценность непонятна, то и небольшая форма может стать непреодолимым препятствием.
Разрабатывая популярные сервисы, следует стремиться к тому, чтобы снять лишние препятствия на пути пользователя. Если же сервис секретный, и допуск ограничен, то можно и поглумиться над пользователем, чтобы потешить службу безопасности :)
с аккаунтами-зомби лучше стараться бороться самим, а не перекладывать это на плечи пользователей, если задача стоит в привлечении посетителей. Но это отдельная большая проблема.
А всегда ли нужна регистрация? И зачем она нужна?
Кажется этот вопрос недавно поднимался на хабре, когда речь шла о социальных сетях без необходимости регистрации в оных (в качестве примера - Wordstream на баше). Ну, и как оказалось, со временем сайты подобные ресурсы превращаются в помойку. Выводы делайте сами. :)
Отсутствие регистрации еще не означает анонимность - можно аутентифицироваться через сторонние сайты или openid. Например, я сейчас работаю над сервисом, который аутентифицируется через фейсбук, потому что моя целевая аудитория на 99%, если не на 100%, на фейсбуке. Бардака не будет, регистраций тоже.
Задавайте простые вопросы и перегружайте форму текстом;
может таки не перегружайте? :)
может таки не перегружайте? :)
согласна с автором на 100%.
Спасибо за полезную заметку ;)
Спасибо за полезную заметку ;)
Читая вот этого товарища Luke Wroblewski узнал несколько не плохих фич для формы. Хотя думал, что о дизайнах форм знаю всё
еще было бы здорово, если бы рядом с полем ввода пароля была галочка "Показать пароль". Потому что чаще всего около компьютера находишься в одиночку, никто пароль подсмотреть не может, но ошибиться при вводе пароля и подтверждения пароля очень легко (не убрав CapsLock, или находясь не в той раскладке).
А когда пароль никто не может посмотреть, кроме тебя, то почему бы мне не отобразить его? ТОгда ошибок будет значительно меньше..
А вы как думаете? ;)
А когда пароль никто не может посмотреть, кроме тебя, то почему бы мне не отобразить его? ТОгда ошибок будет значительно меньше..
А вы как думаете? ;)
ход хороший, но не во всех случаях. Ход лучший (на мой взгляд) - первый вход без пароля вообще. С последующей высылкой его на почту и/или настойчивой просьюой установить его.
Уже ответили на ваш вопрос. Но когда я впервые увидел ответ на свой комментарий,то мысли были следующие:
- Неплохая фича, имеющая право на существование
- Я не соглашусь с aremath о беспаролевом входе. Зато классическое подтверждение на e-mail содержащее информацию о аккаунте (логин и пароль) поможет напомнить пароль в случае если вы его забудете. При этом в хороших системах должна быть возможность поменять пароль + запоминать пароль. Я считаю, что пароль пользователю надо "почувствовать" при вводе (хи-хи), но один раз!
- Неплохая фича, имеющая право на существование
- Я не соглашусь с aremath о беспаролевом входе. Зато классическое подтверждение на e-mail содержащее информацию о аккаунте (логин и пароль) поможет напомнить пароль в случае если вы его забудете. При этом в хороших системах должна быть возможность поменять пароль + запоминать пароль. Я считаю, что пароль пользователю надо "почувствовать" при вводе (хи-хи), но один раз!
На счёт "показать пароль"... сомнительная фича. Ещё ни разу не видел, чтобы человек набирал пароль и смотрел на окно ввода. Начиная от секретарш, заканчивая программистами.
Самая лучшая реализация, это JS проверка совпадения паролей и, в случае несовпадения, показывать это. (понравилась фишка с затуханием цвета фона от красного до белого + input#passwd {border: 2px solid #f00;}
Самая лучшая реализация, это JS проверка совпадения паролей и, в случае несовпадения, показывать это. (понравилась фишка с затуханием цвета фона от красного до белого + input#passwd {border: 2px solid #f00;}
ну не знаю ;)
миллион раз встречалась с тем, как пользователи не правильно вводят пароль, либо не в той раскладке, либо капслоком, либо буквы перепутают.
А уж когда просят их ввести пароль, а потом подтверждение пароля, то каждый третий-четвертый делает ошибку ))) доказано тестированиями ;)
вспомните, разве Вы никогда не ошибались?
А потому пользователи и не смотрят на экран при вводе пароля, потому что смотреть то не на что, там одни ****** ;)))))
миллион раз встречалась с тем, как пользователи не правильно вводят пароль, либо не в той раскладке, либо капслоком, либо буквы перепутают.
А уж когда просят их ввести пароль, а потом подтверждение пароля, то каждый третий-четвертый делает ошибку ))) доказано тестированиями ;)
вспомните, разве Вы никогда не ошибались?
А потому пользователи и не смотрят на экран при вводе пароля, потому что смотреть то не на что, там одни ****** ;)))))
Всё просто и понятно, но не могу согласиться только со (2) пунктом. Это создаёт ряд проблем для пользователей (не стоит забывать, что мы в районе СНГ, а не Европа/Америка):
1) частые запросы могут нагрузить машинку пользователя (далеко не у всех стоят Коры Дуба)
2) частые запросы при большой нагрузке на сервере (если форма ждёт ожидания валидации введённого ника) могут очень негативно влиять на скорость ввода в форму.
1) частые запросы могут нагрузить машинку пользователя (далеко не у всех стоят Коры Дуба)
2) частые запросы при большой нагрузке на сервере (если форма ждёт ожидания валидации введённого ника) могут очень негативно влиять на скорость ввода в форму.
1) частые запросы могут нагрузить машинку пользователя (далеко не у всех стоят Коры Дуба)
Частые в данном случае - это какие? Если взять среднюю длину имени символов за 10, то это максимум - 10 запросов. При быстром вводе, несомненно, нужно выдавать запрос не после каждого символа, а после паузы - итого получаем ещё меньше. Если менее 10 js-запросов нагрузят пусть даже самую слабую машинку пользователя - полагаю, стоит серьёзно задуматься о переписывании соответствующего кода.
Здесь дело не в общем количестве символов, а скорости набора. Надо полагать, что пользователь (среднестатистический) вводит от 1 до 3 символов в секунду. При условии большой нагрузки на сервер, это может создать проблемы.
конечно, но как я уже написал - нет смысла выдавать по запросу на каждое нажание, всё равно пользователь все результаты не увидит. См. Submission Throttling Pattern
Для вас это баг, так как вы понимаете какое поле к чему. А представим себе, что кому-то непонятно значение какого-то поля и он хочет посмотреть подсказку. Ему нужно будет щелкать по табу непредвиденное кол-во раз причем без какой-либо логики.
Ну можно еще добавить привязывание лейбла к полю ввода (forLabel кажется, я не верстальщик). А так да.
да, все лежит на поверхности, но как показывает практика большинство сайтов обустроены ужасной регистрационной формой и очень бесят ошибки типа "такой ник уже есть" после того как ты ввел 15 полей инфы и она после этого еще и обнулилась
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ryan Singer: 10 советов по дизайну форм регистрации