Comments 38
3. Если есть информация, которая может вам понадобиться о пользователе — выясните ее в самом приложении, а не во время регистрации;
Этому как раз очень многие стартапы следуют, не спрашивая вообще ничего, кроме мыла и пароля.
Сложно сказать, насколько это эффективно, я бы добавлял еще пару полей во избежание множества аккаунтов-зомби...
Вообще, довольно грамотно и многим было бы полезно, особенно подходить к регистрации как к процессу.
Даже пароль при регистрации можно не спрашивать :) Нужен только email или телефончег :)
Серьезно! Это, конечно, может привести к множеству мусорных регистраций, зато конверсия из посетителей в регистрации будет бешенная.
Серьезно! Это, конечно, может привести к множеству мусорных регистраций, зато конверсия из посетителей в регистрации будет бешенная.
UFO just landed and posted this here
Конверсия, в данном случае, это отношение количества посетителей сайта к количеству регистраций на сайте.
UFO just landed and posted this here
Очень подробно не смогу, сил на лекцию сейчас не хватит. Думаю, Вы найдете без труда много текстов в сети.
Есть предположение, подтверждаемое статистикой, что чем больше полей в форме регистрации, тем меньше вероятность, что человек зарегистрируется.
Это похоже на эксперименты с крысами: чтобы добраться до сыра (приманки) крыса может стерпеть удар электрического тока (определенной силы) от прутьев клетки, по которым лежит путь к сыру. Сила удара, который крыса готова стерпеть, зависит от привлекательности сыра и от степени голода, который она испытывает.
Бывают сложные формы, с множеством требований (иногда неочевидных) по её заполнению. Если привлекательность сервиса высока, то изголодавшийся пользователь пройдет через испытание регистрационной формы. Если же назначение сервиса неочевидно, т.е. ценность непонятна, то и небольшая форма может стать непреодолимым препятствием.
Разрабатывая популярные сервисы, следует стремиться к тому, чтобы снять лишние препятствия на пути пользователя. Если же сервис секретный, и допуск ограничен, то можно и поглумиться над пользователем, чтобы потешить службу безопасности :)
Есть предположение, подтверждаемое статистикой, что чем больше полей в форме регистрации, тем меньше вероятность, что человек зарегистрируется.
Это похоже на эксперименты с крысами: чтобы добраться до сыра (приманки) крыса может стерпеть удар электрического тока (определенной силы) от прутьев клетки, по которым лежит путь к сыру. Сила удара, который крыса готова стерпеть, зависит от привлекательности сыра и от степени голода, который она испытывает.
Бывают сложные формы, с множеством требований (иногда неочевидных) по её заполнению. Если привлекательность сервиса высока, то изголодавшийся пользователь пройдет через испытание регистрационной формы. Если же назначение сервиса неочевидно, т.е. ценность непонятна, то и небольшая форма может стать непреодолимым препятствием.
Разрабатывая популярные сервисы, следует стремиться к тому, чтобы снять лишние препятствия на пути пользователя. Если же сервис секретный, и допуск ограничен, то можно и поглумиться над пользователем, чтобы потешить службу безопасности :)
UFO just landed and posted this here
с аккаунтами-зомби лучше стараться бороться самим, а не перекладывать это на плечи пользователей, если задача стоит в привлечении посетителей. Но это отдельная большая проблема.
А всегда ли нужна регистрация? И зачем она нужна?
Кажется этот вопрос недавно поднимался на хабре, когда речь шла о социальных сетях без необходимости регистрации в оных (в качестве примера - 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
UFO just landed and posted this here
Для вас это баг, так как вы понимаете какое поле к чему. А представим себе, что кому-то непонятно значение какого-то поля и он хочет посмотреть подсказку. Ему нужно будет щелкать по табу непредвиденное кол-во раз причем без какой-либо логики.
Ну можно еще добавить привязывание лейбла к полю ввода (forLabel кажется, я не верстальщик). А так да.
да, все лежит на поверхности, но как показывает практика большинство сайтов обустроены ужасной регистрационной формой и очень бесят ошибки типа "такой ник уже есть" после того как ты ввел 15 полей инфы и она после этого еще и обнулилась
Sign up to leave a comment.
Ryan Singer: 10 советов по дизайну форм регистрации