Comments 88
KISSMetrics не назвал бы идеальной формой. Обозначение полей без введенной информации, до нажатия кнопки подтверждения, как ошибочных раздражает. Некоторые сайты этим грешат.
Я бы ещё добавил про tab index'ы — они должны соответствовать последовательности заполнения формы, ну и все поля должны быть доступны (иногда встречаются хитрые механизмы выбора даты, которые меняются только мышкой).
Там, на самом деле, эти поля подсвечиваются как ошбочные только после отправки. Но из скриншота первое впечатление складывается именно такое как Вы описали))
«Используйте проверку формата данных на стороне клиента (JavaScript)»
Обратная сторона — чрезмерное увязание в JavaScript'е, это не все любят. Когда делаем валидацию, всегда мучительно колебаемся между альтернативами: полностью на JavaScript'е делать, или с использованием Ajax'а, и у коллег разные мнения на то, что лучше… Самому больше первый вариант по душе.
Обратная сторона — чрезмерное увязание в JavaScript'е, это не все любят. Когда делаем валидацию, всегда мучительно колебаемся между альтернативами: полностью на JavaScript'е делать, или с использованием Ajax'а, и у коллег разные мнения на то, что лучше… Самому больше первый вариант по душе.
А в чем собственно проблема? Двойная валидация (сначала JavaScript, так как в отличии от AJAX не требуется обмен данными с сервером), а потом повторная валидация на сервере (пользователю нельзя доверять). Чрезмерное увязание — повод почитать Unobtrusive JavaScript и готовые библиотеки для валидации.
UFO just landed and posted this here
я бы даже сказал «не делайте проверку емейла на стороне клиента». Уже много раз сталкивался с тем, что кто-то по-быстрому набросал регэксп для такой проверки, и она не пропускает мой совершенно рабочий емейл me@arty.name
Куда попадает пользователь после регистрации? © Воронежский
> 3. Используйте проверку формата данных на стороне клиента (JavaScript)
> Использование JavaScript проверки данных экономит время пользователя, а также снижает нагрузку на веб-сервер, освобождая его от обработки входящих значений полей формы.
т.е. если я заполню такую форму с отключённым js, то сервер может успешно получить и обработать неправильные данные? И в любом случае всевозможные кулхацкеры обязательно воспользуются отсутствием проверки входящих данных на сервере. Помните, на месте вашего клиентского кода может оказаться что угодно.
> 9. Показывайте пользователям поля в правильном формате
Совет хороший, но только не надо как в примере разделять семантически одно поле на несколько textbox'ов. Поле называется «Дата», почему за ним следует *три* текстбокса?
И от себя добавлю — не забывайте проверить удобство формы для пользователей, не желающих пользоваться мышью. Т.е. доступность всех полей с клавиатуры и правильный порядок перехода при нажатии tab.
> Использование JavaScript проверки данных экономит время пользователя, а также снижает нагрузку на веб-сервер, освобождая его от обработки входящих значений полей формы.
т.е. если я заполню такую форму с отключённым js, то сервер может успешно получить и обработать неправильные данные? И в любом случае всевозможные кулхацкеры обязательно воспользуются отсутствием проверки входящих данных на сервере. Помните, на месте вашего клиентского кода может оказаться что угодно.
> 9. Показывайте пользователям поля в правильном формате
Совет хороший, но только не надо как в примере разделять семантически одно поле на несколько textbox'ов. Поле называется «Дата», почему за ним следует *три* текстбокса?
И от себя добавлю — не забывайте проверить удобство формы для пользователей, не желающих пользоваться мышью. Т.е. доступность всех полей с клавиатуры и правильный порядок перехода при нажатии tab.
Здесь, вроде, не говорится, что не нужно потом перепроверять данные на сервере. Просто использование js снимет ощутимый процент обращений к серверу и останется только финальная валидация и, собственно, само исполнение кода.
снижает нагрузку на веб-сервер, _освобождая_ его от обработки входящих значений полей формы.
неявно, но говорится
неявно, но говорится
Я думаю автор/переводчик имел ввиду «освобождая от лишней обработки»
От какой вообще обработки можно избавить сервер, если клиент может *никакой* обработки не выполнить?
Если у пользователя включен js, то показать сообщение об ошибке можно не отправляя данные серверу. Вместо n+m обработок данных формы, выполнится только m, где n — к-во допущенных ошибок, которые можно отловить в js, a m — к-во допущенных ошибок, которым обязательно нужен запрос к серверу (например проверка на то что логин свободен). Вот собственно от этих n обработок можно избавится.
:-[
И правда.
С точки зрения кода на сервере всё-равно нужно все обработки реализовывать, потому что не у всех пользователей есть js, но с точки зрения нагрузки часть работы можно переложить на клиентов.
И правда.
С точки зрения кода на сервере всё-равно нужно все обработки реализовывать, потому что не у всех пользователей есть js, но с точки зрения нагрузки часть работы можно переложить на клиентов.
Серверная валидация нужна в любом случае. Просто реализация js-валидации избавит от некоторых лишних запросов. Да и со стороны пользователя не нужно ждать обработки еще одного реквеста, для того чтобы узнать что дата не в том формате или в никнейме недопустимые символы.
Конечно такая разгрузка сервера — сомнительная оптимизация, но как говорится, с миру по нитке…
Конечно такая разгрузка сервера — сомнительная оптимизация, но как говорится, с миру по нитке…
т.е. если я заполню такую форму с отключённым js, то сервер может успешно получить и обработать неправильные данные?
Проверку на стороне сервера никто не отменял, хотя форма должна работать и выдавать предупреждения даже при отключенном JS (хотя бы после отправки) — это правильный совет.
Совет хороший, но только не надо как в примере разделять семантически одно поле на несколько textbox'ов. Поле называется «Дата», почему за ним следует *три* текстбокса?
Либо фоном в самом поле (см. Mobile Me), либо простым текстом (как на eBay).
> Совет хороший, но только не надо как в примере разделять семантически одно поле на несколько textbox'ов. Поле называется «Дата», почему за ним следует *три* текстбокса?
Не соглашусь. Мне приходилось заполнять разные формы — с разделением и без него. С разделением даты на три текстбокса просто — 13 — Tab — 01 — Tab — 2010; а вот без него (с одним текстбоксом) сиди да гадай методом тыка — как же туда дату-то писать: 01.01.2000, 01.01.00, 01/01/2000, 2000/01/01, 01-01-2000, 12-31-2010…
Не соглашусь. Мне приходилось заполнять разные формы — с разделением и без него. С разделением даты на три текстбокса просто — 13 — Tab — 01 — Tab — 2010; а вот без него (с одним текстбоксом) сиди да гадай методом тыка — как же туда дату-то писать: 01.01.2000, 01.01.00, 01/01/2000, 2000/01/01, 01-01-2000, 12-31-2010…
Если следовать совету (который хороший), то гадать методом тыка не придётся.
Зато у трёх текст боксов есть очевидный недостаток. Дату в таком виде не получится скопировать целиком, или вставить, только за три операции.
Зато у трёх текст боксов есть очевидный недостаток. Дату в таком виде не получится скопировать целиком, или вставить, только за три операции.
С разделением даты на три текстбокса просто — 13 — Tab — 01 — Tab — 2010; а вот без него (с одним текстбоксом) сиди да гадай методом тыка...
С таким же успехом можно нарваться на гадание и с тремя боксами:
01 — Tab — 13 — Tab — 2010
01 — Tab — 13 — Tab — 10
13 — Tab — 01 — Tab — 10
2010 — Tab — 01 — Tab — 13
И я встречал все эти комбинации. Вариантов, может, немного меньше, чем с одним полем, но все равно, если разработчики не подумали о наглядности и очевидности, то гемора юзерам хватит, особенно, если юзеры из разных стран со своими привычками и традициями.
Обычно поле для ГГГГ делается больше, что уж тут говорить о предполагаемых выпадающих меню. Выбор сводится к 2 вариантам.
Терпеть не могу выпадающие меню, когда, например, дату рождения надо вводить. Нередко встречаются «умные» разработчики, которые норовят в список лет диапазон побольше запихнуть, напр., от 1900 года до нонешнего.
А что касается до «обычно», то статья как раз о том, что нужно делать, чтоб юзер не думал, как делается обычно, а сразу наглядно видел, что же от него требуется.
А что касается до «обычно», то статья как раз о том, что нужно делать, чтоб юзер не думал, как делается обычно, а сразу наглядно видел, что же от него требуется.
> Терпеть не могу выпадающие меню, когда, например, дату рождения надо вводить. Нередко встречаются «умные» разработчики, которые норовят в список лет диапазон побольше запихнуть, напр., от 1900 года до нонешнего.
Плохо помню, но _вроде_ писал в каком-то комментарии об этом. И там я _вроде_ упомянул про то, что выпадающие меню следует делать для ДД.ММ, а ГГГГ писать самому, т.к. дней и месяцев всегда одинаковое кол-во, а год всегда меняется.
Плохо помню, но _вроде_ писал в каком-то комментарии об этом. И там я _вроде_ упомянул про то, что выпадающие меню следует делать для ДД.ММ, а ГГГГ писать самому, т.к. дней и месяцев всегда одинаковое кол-во, а год всегда меняется.
Спасибо за перевод, очень актуально и полезно.
70% приведённых форм неудобны и нарушают гайды по юзабилити, да и просто отпугивают пользователей.
1. Многоэтапные формы? Кэшировать? Камрад, а мы точно в одном и том же интернете? Амазон себе может это позволить потому что он амазон. Сегодня рулят формы из трёх полей — email, и password два раза. Уже потом, в профиле сайт может ненавязчиво поинтересоваться — какого цвета носки я ношу и хочу ли я загрузить себе крутецкую новую аватарку.
2. Маленькая серенькая звёздочка — удачный вариант индикатора важного поля? Я таки повторю вам. Все необязательные поля не нужны. Их можно заполнить после непосредственного знакомства с сайтом. Если же (внезапно) мы с вами говорим не о форме регистрации, то важные поля нужно выделять явно — окружать жирной рамочкой, выделять отдельным блоком, сделать бросающимися в глаза. Вариант — пользователь тыркнет, а форма ругнётся — не вариант.
3. К проверкам, скажем, поля email нужно относиться очень осторожно. Я не раз сталкивался с ситуацией, когда какая-нибдь особо «умная» регулярка не пускала адрес, содержащий точку или unicode-домен.
4. KISSMetrics… Я даже не знаю, что тут сказать. Конечно это идеально — в лицо сказать пользователю, что он идиот. Это как клерк в банке, который скажет тебе после просмотра заполненной формы — «Поле фамилии не заполнено. Запишите туда вашу фамилию. Поле домашнего телефона тоже — впишите туда домашний телефон. А вот ещё строчка — номер паспорта. Впишите туда… Ну вы понимаете — номер паспорта.». Инфографика, иконки, цветовые и стилевые индикаторы придуманы не просто так, а для улучшения восприятия информации — без раздражения и вникания. Как вы считаете — дорожные знаки так насыщены текстом из-за того, что люди сплошь неграмотные? Может всё-таки из-за того, что информация должна восприниматься и осознаваться за секунды на скорости 60 в час и выше?
Резюмирую. Не учите людей плохому. Лучше вообще не писать статью, чем подзуживать к созданию ещё 100500 говноформ.
1. Многоэтапные формы? Кэшировать? Камрад, а мы точно в одном и том же интернете? Амазон себе может это позволить потому что он амазон. Сегодня рулят формы из трёх полей — email, и password два раза. Уже потом, в профиле сайт может ненавязчиво поинтересоваться — какого цвета носки я ношу и хочу ли я загрузить себе крутецкую новую аватарку.
2. Маленькая серенькая звёздочка — удачный вариант индикатора важного поля? Я таки повторю вам. Все необязательные поля не нужны. Их можно заполнить после непосредственного знакомства с сайтом. Если же (внезапно) мы с вами говорим не о форме регистрации, то важные поля нужно выделять явно — окружать жирной рамочкой, выделять отдельным блоком, сделать бросающимися в глаза. Вариант — пользователь тыркнет, а форма ругнётся — не вариант.
3. К проверкам, скажем, поля email нужно относиться очень осторожно. Я не раз сталкивался с ситуацией, когда какая-нибдь особо «умная» регулярка не пускала адрес, содержащий точку или unicode-домен.
4. KISSMetrics… Я даже не знаю, что тут сказать. Конечно это идеально — в лицо сказать пользователю, что он идиот. Это как клерк в банке, который скажет тебе после просмотра заполненной формы — «Поле фамилии не заполнено. Запишите туда вашу фамилию. Поле домашнего телефона тоже — впишите туда домашний телефон. А вот ещё строчка — номер паспорта. Впишите туда… Ну вы понимаете — номер паспорта.». Инфографика, иконки, цветовые и стилевые индикаторы придуманы не просто так, а для улучшения восприятия информации — без раздражения и вникания. Как вы считаете — дорожные знаки так насыщены текстом из-за того, что люди сплошь неграмотные? Может всё-таки из-за того, что информация должна восприниматься и осознаваться за секунды на скорости 60 в час и выше?
Резюмирую. Не учите людей плохому. Лучше вообще не писать статью, чем подзуживать к созданию ещё 100500 говноформ.
И не просите у пользователя почту, если это не необходимо. Скажите, зачем вам (например, на форуме) моя почта, если я не хочу получать письма ни от администрации, ни от других пользователей?
вы может и не хотите, это ваше право — но пускать на форум человека и не иметь с ним контакта — это неправильно и противоречит даже просто удобству. Это значит, что как минимум, не восстановите пароль, а значит написав что-то, вас нельзя определить и, скажем, забанить :)
Затем, что:
1. если ваш ник naryl занят, то вам прийдётся для этого конкретного форума помнить новый логин
2. если вы потеряете пароль, вы никак не сможете его восстановить
3. унификация. Ваш email — это как паспорт. Он достаточно уникален и позволяет однозначно вас определить, что удобно и сервису и вам.
1. если ваш ник naryl занят, то вам прийдётся для этого конкретного форума помнить новый логин
2. если вы потеряете пароль, вы никак не сможете его восстановить
3. унификация. Ваш email — это как паспорт. Он достаточно уникален и позволяет однозначно вас определить, что удобно и сервису и вам.
OpenID успешно решает все вопросы. Почту достаточно ввести только при регистрации оного, и открывать её никто не заставляет, кроме Гугла ЕМНИП.
Хотя для админа выше назвали хорошую причину — по почте удобно банить, но и эту проблему OpenID решает.
Так что почта имеет смысл только в трёх случаях:
1. Человек не хочет иметь OpenID. ССЗБ
2. Разработчик ленивый и не хочет делать OpenID.
3. Ресурсу *требуется* связь с пользователем — единственная адекватная причина требовать почту.
Хотя для админа выше назвали хорошую причину — по почте удобно банить, но и эту проблему OpenID решает.
Так что почта имеет смысл только в трёх случаях:
1. Человек не хочет иметь OpenID. ССЗБ
2. Разработчик ленивый и не хочет делать OpenID.
3. Ресурсу *требуется* связь с пользователем — единственная адекватная причина требовать почту.
На планктоносоциалках миллионы пользователей. Думаю, OpenID есть у… 3-4%
OpenID хорошая штука и должна дополнять имеющуюся процедуру регистрации (тут вы правы). Т.е. ссылка «регистрация» и кнопочки «войти через вконтакте, gmail, facebook, twitter и т.д.» — это хороший тон. В то же время «Иди и зарегистрируй себе OpenId» — эпик фейл.
OpenID хорошая штука и должна дополнять имеющуюся процедуру регистрации (тут вы правы). Т.е. ссылка «регистрация» и кнопочки «войти через вконтакте, gmail, facebook, twitter и т.д.» — это хороший тон. В то же время «Иди и зарегистрируй себе OpenId» — эпик фейл.
>> 1. Человек не хочет иметь OpenID. ССЗБ
> В то же время «Иди и зарегистрируй себе OpenId» — эпик фейл.
Я хотел сказать, что если человек не хочет иметь OpenID — пусть оставлет почту. Если не хочет оставлять почту — пусть регистрирует OpenID.
Вы правы. Необходимо и достаточно предусмотреть регистрацию по почте и по OpenID.
> В то же время «Иди и зарегистрируй себе OpenId» — эпик фейл.
Я хотел сказать, что если человек не хочет иметь OpenID — пусть оставлет почту. Если не хочет оставлять почту — пусть регистрирует OpenID.
Вы правы. Необходимо и достаточно предусмотреть регистрацию по почте и по OpenID.
А что за «гайды по юзабилити» такие?
Можете почитать:
1. Prioritizing Web Usability, Jakob Nielsen, Hoa Loranger
2. Forms that Work: Designing Web Forms for Usability (Interactive Technologies) — неплохая книжка. Есть нюансы конечно, но в целом очень неплохая.
3. Как ни странно — Apple Guidelines. У них есть и для веба, и в целом про дизайн приложений, и применительно к нативным макосным приложениям.
4. Круга можете почитать — Don't Make Me Think: A Common Sense Approach to Web Usability, Steve Krug
Из наших неплохая книжка — Искусство мыть слона В. Головача. В ководстве Лебедева есть много хороших положений.
В общем Лурк моар и обрящете.
Update: Вот, кстати, и полный список www.inwebwetrust.org/trust/55_knig_otlichayushih_veb-dizajnera_ot_amatora.html
1. Prioritizing Web Usability, Jakob Nielsen, Hoa Loranger
2. Forms that Work: Designing Web Forms for Usability (Interactive Technologies) — неплохая книжка. Есть нюансы конечно, но в целом очень неплохая.
3. Как ни странно — Apple Guidelines. У них есть и для веба, и в целом про дизайн приложений, и применительно к нативным макосным приложениям.
4. Круга можете почитать — Don't Make Me Think: A Common Sense Approach to Web Usability, Steve Krug
Из наших неплохая книжка — Искусство мыть слона В. Головача. В ководстве Лебедева есть много хороших положений.
В общем Лурк моар и обрящете.
Update: Вот, кстати, и полный список www.inwebwetrust.org/trust/55_knig_otlichayushih_veb-dizajnera_ot_amatora.html
Сегодня рулят формы из трёх полей — email, и password два раза
А мне вот всегда интересно было — а нафига пассворд два раза? За все время своей «онлайн-жизни» я не припомню случая, чтоб я разные пароли ввел. Бывало, конечно, что капс был включен или раскладка была не та, но я в этих случаях оба пароля вводил не так, как задумывал, и два поля меня никак не спасали.
Почему-то мне кажется, что эта практика имеет глубокие какие-то корни в прошлом, и когда-то это было вполне объяснимо. Но сейчас зачем? Особенно, если учесть, что процедура восстановления пароля сейчас — это обязательный элемент правильно построенного онлайн-ресурса.
Мне еще вот это понравилось, с юмором:
habrastorage.org/storage/0b54061b/ed0b02ee/b58811e6/9d0326b2.jpg
ну, и дальше: theoatmeal.com/comics/shopping_cart
(пардон за формат ссылки/картинки, как могу)
habrastorage.org/storage/0b54061b/ed0b02ee/b58811e6/9d0326b2.jpg
ну, и дальше: theoatmeal.com/comics/shopping_cart
(пардон за формат ссылки/картинки, как могу)
С одной стороны — всем это известно и ничего нового автор не представил, но с другой, упорядочил знания и дал их в удобной форме — это плюс.
Я бы добавил — используйте label для полей формы, особенно для чекбоксов и радиобаттонов
11. Не используйте исчезающие подписи (плейсхолдеры) для формы из более чем одного поля
Когда пользователь заполняет вашу форму и использует кнопку Tab для перехода к следующему полю, а затем хочет посмотреть, что ему нужно ввести, он остается один на один с пустым полем без подписи.
Когда пользователь заполняет вашу форму и использует кнопку Tab для перехода к следующему полю, а затем хочет посмотреть, что ему нужно ввести, он остается один на один с пустым полем без подписи.
Когда-то почти 2 года назад писал «подобную» отсебятину — Формы для людей. Если кому интересно.
это шутка такая? приведённые примеры не отличны, а ужасны.
Alexandru Cohaniuc: конвертик уже приелся (хорошо, что тут хоть не на «марку» надо нажимать для отправки). но в чем смысл полей First Name и Last Name в этой форме? в этой форме нужно лишь одно поле «Comment» и ниже Email с комментарием, что если хотите чтобы я ответил — не забудьте указать свой email.
а подпись я (да и не только я, а много людей), привыкли писать _после_ сообщения.
KissMetrics: это полнейшая глупость добавлять у полю «Ваше имя» комментарий «Введите ваше имя» и так для всех полей.
Groupon: это какой-же гений догадался разбить форму на несколько шагов, да так, чтобы на каждом шаге было только одно поле ввода?
Alexandru Cohaniuc: конвертик уже приелся (хорошо, что тут хоть не на «марку» надо нажимать для отправки). но в чем смысл полей First Name и Last Name в этой форме? в этой форме нужно лишь одно поле «Comment» и ниже Email с комментарием, что если хотите чтобы я ответил — не забудьте указать свой email.
а подпись я (да и не только я, а много людей), привыкли писать _после_ сообщения.
KissMetrics: это полнейшая глупость добавлять у полю «Ваше имя» комментарий «Введите ваше имя» и так для всех полей.
Groupon: это какой-же гений догадался разбить форму на несколько шагов, да так, чтобы на каждом шаге было только одно поле ввода?
согласен, приведенные примеры как минимум странно называть отличными. Особенно позабавило попадание в этот список интерфейса, где обязательные поля обозначены тем же значком, что выше обозначал ошибку.
Полностью с Вами согласен на счет Alexandru Cohaniuc.
А вот Groupon для определенного круга пользователей очень даже приятна.
1. Красиво и привлекательно. (Большинство обычных пользователей! не гиков обажают такие штуки)
2. Все просто работает отлично и очень понятно.
А вот Groupon для определенного круга пользователей очень даже приятна.
1. Красиво и привлекательно. (Большинство обычных пользователей! не гиков обажают такие штуки)
2. Все просто работает отлично и очень понятно.
про Groupon: я не против, когда кто-то желает выпендриться с формой.
но я не считаю, что чей-то выпендрёж (который иногда может даже получиться), стоит приводить в примерах к статье «10 советов по улучшению юзабилити веб-форм», которую читают в основном новички.
тот, кто использует такие выкрутасы обычно прекрасно разбирается в юзабилити форм и знает зачем, почему и как можно нарушать какие-то базовые принципы.
но я не считаю, что чей-то выпендрёж (который иногда может даже получиться), стоит приводить в примерах к статье «10 советов по улучшению юзабилити веб-форм», которую читают в основном новички.
тот, кто использует такие выкрутасы обычно прекрасно разбирается в юзабилити форм и знает зачем, почему и как можно нарушать какие-то базовые принципы.
Посмотрите доклад Ильи Бирмана
Люди, предупреждайте людей как им набирать капчу. Нигде, никогда я не видел надписи «Если на картинке буква строчная, то и набирайте строчной, если прописная, то и набирайте прописную» или «Набирайте буквы в любом регистре». Люди сидят и корячатся с шифтом.
А также путают 0 и О, 1 и l и I — неужели так трудно вообще не использовать эти знаки в капче, если символы в ней сильно искажаются и по обычным признакам отличить невозможно?
Я где-то видел. Один раз в в жизни:)
Лучше так: люди, не вставляйте в формы капчу!
1. Четко выделяйте обязательные для заполнения поля
Согласен. Если в форме более двух-трех полей и все обязательный — необходимо обозначить это явным образом.
Даже если это не вдохновит пользователя на заполнение, то по крайней мере сэкономит ему несколько минут и сохранит его нервную систему.
9. Показывайте пользователям поля в правильном формате
О да! Если поле имеет набор правил, желательно их обьяснить одной фразой. А то как-то создавал аккаунт на одном из сайтов, и пришлось перебивать пароль несколько раз примерно в следующем порядке:
1 — забиваем пароль: набор букв и символов.
Ошибка: пароль должен содержать минимум две буквы в верхнем регистре.
2 — окейно. Придумываю другой пароль, с двумя литерами в верхнем регистре.
Ошибка: пароль должен содержать минимум две цифры.
3 — зубовный скрежет. Ладно! Пароль добивается двумя цифрами.
Ошибка: пароль не должен содержать спецсимволы "&()[] и т.д."
4 попытка оказалась удачной.
Это же неприлично, в конце концов.
Посмотрел на первую картинку и подумал, моя мама ввела бы name@example.com в первую форму. А знающие итак без подсказки справятся.
Спасибо! Обязательно учтем в нашем конструкторе форм mytaskhelper.ru/form-builder
Может немного не в тему, но хотел бы добавить лучик негодования относительно длины Логина/Ника.
Почему-то подавляющее большинство сайтов не дают зарегистрировать логин/ник в 2-3 символа.
Почему-то подавляющее большинство сайтов не дают зарегистрировать логин/ник в 2-3 символа.
Почему этих советов всегда именно 10?
Потому, что маркетологи решили, что так будет лучше. Они же придумали 8-ой совет.
Да, я тоже был удивлен такой малой цифрой.
Дабы не мутить воду, отвечу про «количественную/качественную», ссылкой —
artgorbunov.ru/bb/soviet/
Дабы не мутить воду, отвечу про «количественную/качественную», ссылкой —
artgorbunov.ru/bb/soviet/
требуется больше движений глаз
Это на каком таком языке написано? :)
Что-то мне думается, что как угодно подпиши поля для ввода даты, явно или не очень, но дейтпикер справится с этим в сто раз лучше.
Да и по остальным примерам много вопросов и непоняток, выше описали уже все практически.
Про каптчу нет никаких упоминаний, хотя в идеальной форме ее и не должно быть (что реально и достаточно просто делается)
Да и по остальным примерам много вопросов и непоняток, выше описали уже все практически.
Про каптчу нет никаких упоминаний, хотя в идеальной форме ее и не должно быть (что реально и достаточно просто делается)
Отличная статья! Спасибо :)
Хочу сделать на сайте возможность регистрации/входа с динамическим определениям наличия введенного e-mail в базе.
Т.е.
1. Изначально пользователь видит на сайте только форму ввода e-mail:
2. После ввода e-mail система на лету проверяет его наличие в базе и:
а) Если находит соответствие в базе, то снизу всплывает форма для ввода пароля:
б) Если не находит, то после нажатия кнопки «Вход», происходит регистрация и вход и выводится сообщение: «Можете работать в системе! Ваш пароль отправлен на введенный e-mail»
При использовании данной схемы получаем:
• Облегчение дизайна, т.к. форма ввода пароля отсутствует.
• Больше зарегистрированных пользователей, т.к. изначально пользователь думает, что для входа достаточно ввести e-mail и для регистрации ему не нужно ничего больше вводить, она автоматическая.
Но я не видел такого нигде. Почему?
Т.е.
1. Изначально пользователь видит на сайте только форму ввода e-mail:
2. После ввода e-mail система на лету проверяет его наличие в базе и:
а) Если находит соответствие в базе, то снизу всплывает форма для ввода пароля:
б) Если не находит, то после нажатия кнопки «Вход», происходит регистрация и вход и выводится сообщение: «Можете работать в системе! Ваш пароль отправлен на введенный e-mail»
При использовании данной схемы получаем:
• Облегчение дизайна, т.к. форма ввода пароля отсутствует.
• Больше зарегистрированных пользователей, т.к. изначально пользователь думает, что для входа достаточно ввести e-mail и для регистрации ему не нужно ничего больше вводить, она автоматическая.
Но я не видел такого нигде. Почему?
Потому что это неинтуитивно и запутанно. Я пришёл первый раз на ваш сайт первый раз — а он мне сразу предлагает войти, как будто знает меня сто лет. Это неинтуитивно. Или я регистрировался на вашем сайте, вернулся на него — поле e-mail вижу, а где пароль вводить — не вижу. Это тоже неинтуитивно.
Потому-что непонятно. В поле, рядом с которым есть кнопка [вход] (если только это не кнопка на заставке, которая ведёт на сам сайт), я не буду ничего вбивать, зная, что я там незарегистрированный. Я буду искать ссылку [регистрация], где-то рядом… Потому-что я так привык. Идея, безусловно, хорошая. Но проблемы с непониманием будут.
10. Одноколоночная форма — лучшее решение
Лучшее решение для единоразово заполняемых форм. Для форм, которые требуют ежедневного многократного заполнения, такой вид может превратиться в пытку скроллером.
UFO just landed and posted this here
Перезалейте фото, плиз.
Для создания форм обратной связи, есть удобный сайт — Testograf.ru Отличный функционал, юзабилити на высоте, всем рекомендуем)
Sign up to leave a comment.
10 советов по улучшению юзабилити веб-форм