Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Думаю автор всё же имел ввиду однократный ввод пароля именно при регистрации. Если где-то ещё и при ауентификации просят ввести его дважды, то, возможно владельцы сайта просто пытаются снизить конверсию, чтобы бизнес не развивался слишком быстро. И я согласен с автором — однократного ввода пароля при регистрации достаточно для подавляющего количества сайтов. Большинство юзеров до сих пор используют единый пароль и ошибиться в нём могут разве что в раскладке, но от этого повтор пароля не спасает.
Да, имел ввиду именно при реге.
А что делать если я при регистрации перепутал порядок букв в своей парольной фразе? Я очень часто пишу «fi» вместо «if» например. Когда меня не просят повторить пароль, то у меня возникает смутное подозрение, что пароль, а не его солёный хэш, хранится на данном сайте и скорее всего будет прислан прямо по почте. Для некоторых сайтов это наверное приемлемо, но точно не для всех.
Т.е вас смущает не то что ваш пароль храниться в открытом виде на сайте, а то что он будет прислан на почту при восстановлении пароля? Потому что на первое(хранение на сайте) введение его хоть трижды при регистрации никак не повлияет. И то, что кто-то до сих пор таким образом восстанавливает пароли(а не заданием нового) должно вас немного насторожить.
Нет, меня смущает именно хранение в открытом виде, а отправка по почте — это лишь следствие и верный признак такого хранения. Я не достаточно точно сформулировал мысль. И количество ввода паролей при регистрации — то же всего лишь эвристика на такое хранение.
P.S. Вообще мне только сейчас пригла в голову мысль, что даже если ошибусь при первичном вводе пароля, то вход будет точно таким же, как если я его забуду — через восстановление пароля.
P.S. Вообще мне только сейчас пригла в голову мысль, что даже если ошибусь при первичном вводе пароля, то вход будет точно таким же, как если я его забуду — через восстановление пароля.
Понимаю, что опечатка, но сильно забавно:
ауентификация – это когда при аутентификации отправляешь заголовок «Вечер в хату»
ауентификация – это когда при аутентификации отправляешь заголовок «Вечер в хату»
Про кнопки «ок» и «отправить». Есть мнение что это разработчикам очевидно что что-то куда-то отправляется. Простому пользователю может быть не понятно зачем отправлять что-то куда-то отправлять ведь он только войти на сайт хотел. Так что, по-моему, понятней была бы кнопка «войти».
Яндекс.Почта ставит кнопку сверху.
Она снизу дублируется вместе с остальными.
2. Не дизейблите кнопку
При табе мы переходим не на кнопку а в поле ввода. С другой стороны при активности поля она должно выделяться как то. Так ведь?
А серая кнопка, интуитивно может подсказать, что отправлять нечего — лишняя проверка перед отправкой это лучше чем перезаполнять вссю форму ввода.
-Попробовал тут «потабать». ХЗ куда я попадаю. Нажал «Ввод» — ушёл не туда.
Почему все формы гребут под «конверсию» и забывают о служебных формах (допустим, CRM, SaaS), где эта конверсия никому не снилась? А требуется удобство и простота, точность ввода данных (значений) и уменьшение кликов (к примеру, вместо селекта из 3 пунктов — радиокнопки/селекты; объединение полей, типа адрес и прочее).
Почему не уделяется должное внимание биг-формам (прошу прощения за название), которые хранят значения в стандартизированных справочниках (банковские, страховые и медицинские отрасли). И полей в форме может быть более полусотни. Я работаю в настоящее время с подобными формами, это ад и интересная практика одновременно.
Мне уже начинает надоедать такой вечный перепост уже очевидных вещей, публикующихся с 2011 года.
Почему не уделяется должное внимание биг-формам (прошу прощения за название), которые хранят значения в стандартизированных справочниках (банковские, страховые и медицинские отрасли). И полей в форме может быть более полусотни. Я работаю в настоящее время с подобными формами, это ад и интересная практика одновременно.
Мне уже начинает надоедать такой вечный перепост уже очевидных вещей, публикующихся с 2011 года.
Я тоже работаю с такими формами при проектировании интерфейсов для внутреннего пользования сотрудниками Леруа Мерлен. Там реально есть адский ад, который ты описал и, да, наверное было бы не плохо про это когда-то написать.
Ну может когда-нибудь соберёмся и напишем.
Очень было бы интересно почитать про формы 30+ полей для различных прикладных систем. Вечные споры про выравнивание лейблов, поля столбцами или строчками и т д.
Проблема в том что такие формы уж очень сильно зависят от контекста. Формы регистрации везде примерно одно и тоже делают, а вот какими должны быть формы с специфической внутренней SaaS системы? Какова вероятность того что то что работает в одной сложной форме, будет работать в другой? Тут не обойтись книгой/статьей где просто показывают два примера и говорят «делай так, а не так». Это больше про подход к дизайну в целом, про проведение исследований (о том как и зачем вводиться информация в эти формы) и тд.
10. Говори сразу, где ошибка
Ни в коем случае нельзя так делать с логином-паролем, т.к. информация, что конкретный пользователь зарегистрирован на сервисе, может запросто быть критичной утечкой данных сама по себе, без доступа к аккаунту. Это особенно плохо, если логин это адрес эл. почты.
За примерами далеко ходить не надо: Ashley Madison, OnlyFans и другие сайты. Данные о том, что человек зарегистрирован на сайте, уже приводили к увольнениям, разводам и даже самоубийствам. Не гипотетически, реальные люди лишились работы и иногда жизни из-за утечки информации.
Еще один «хороший» вектор это фишинг. Если я могу точно установить, что пользователь зарегистрирован на определенном сайте, то таргетированный фишинг будет во много раз успешнее, нежели просто присылать письма «Вы получили сообщение в Одноклассниках», а у пассажира там и аккаунта-то нет.
В общем, слушайте сначала секьюрити-специалистов, а только потом дизайнеров.
Дельное замечание. Могу тогда предположить, что стоит подумать, где можно говорить в каком поле ошибка, а где нет. Например, на порнхабе лучше не говорить.
Да, некоторые сайты более критичны к этому, безусловно.
Еще один вектор, который не указал выше: пользователи часто ставят одинаковые или схожие пароли на разных сайтах, поэтому когда утекла БД сайта Bookmate, у людей взломались почты и прочие вконтакты.
Тут валидация напрямую вроде бы не влияет, ведь если логин-пароль одинаковые, то взломщик просто войдет в аккаунт. Но когда мы атакуем конкретного человека, а не брутфорсим всю утекшую БД, то переменных становится больше: у нас может быть несколько вариантов почты (всякие username+spam@gmail.com), несколько утекших паролей этого пассажира от разных сайтов, и тут UX формы нам снова начинает активно помогать это ломать.
Еще один вектор, который не указал выше: пользователи часто ставят одинаковые или схожие пароли на разных сайтах, поэтому когда утекла БД сайта Bookmate, у людей взломались почты и прочие вконтакты.
Тут валидация напрямую вроде бы не влияет, ведь если логин-пароль одинаковые, то взломщик просто войдет в аккаунт. Но когда мы атакуем конкретного человека, а не брутфорсим всю утекшую БД, то переменных становится больше: у нас может быть несколько вариантов почты (всякие username+spam@gmail.com), несколько утекших паролей этого пассажира от разных сайтов, и тут UX формы нам снова начинает активно помогать это ломать.
А что секьюрити-специалисты говорят про форму восстановления пароля? Только что сходил на onlyfans и habr — они честно сказали, что такого юзера нет и кажется это поведение большинства подобных форм. Если таким нехитрым образом мы уже получаем информацию о почте, то и смысла не говорить что именно неправильно на форме входа тоже мало.
P.S. Наверное на чувствительных сайтах стоит делать вход по имени пользователя, а не почте.
P.S. Наверное на чувствительных сайтах стоит делать вход по имени пользователя, а не почте.
Тот же принцип — правильно спроектированная система скажет, мол, отправляю ссылку для восстановления на почту. Как в случае успеха, так и в случае ошибки.
Вообще сообщения об ошибках в чувствительном к безопасности контексте — потенциальный вектор атаки. На этом построены целые классы уязвимостей, например padding oracle.
Вообще сообщения об ошибках в чувствительном к безопасности контексте — потенциальный вектор атаки. На этом построены целые классы уязвимостей, например padding oracle.
т.к. информация, что конкретный пользователь зарегистрирован на сервисе
Да? А тогда при регистрации не будем говорить, что адрес уже используется? Тогда пути два, при вводе уже зарег. эл. почты:
- не делать ничего
- слать сброс пароля на этот адрес
Иначе будет утечка информации через форму регистрации, и для целевой атаки — это раз плюнуть. И я пока не разу не видел предложенного мною концепта. Если какой-то сайт и заморачивался с «Неверный пароль ИЛИ логин», то при регистрации можно было легко перепробывать существующие аккаунты (а верх идиотизма это endpoint для AJAX для проверки логина на коллизию, когда не надо даже триггерить саму регистрацию)
Ну да, это тоже проблема. Решается обычно тем, что «мы прислали вам на почту ссылку-подтверждение, нажмите на неё чтобы войти на сайт».
Алсо я же не спорю что вы правы, и комментарий выше тоже прав. Да, очень мало компаний заморачиваются вообще что-либо проектировать, просто слепили из веточек и желудей какой-то сайт и айда в продакшен. Поэтому безопасность в интернете в такой жопе, и все время утекают какие-то БД, и 2FA оказывается можно обойти. В этой ситуации утечка базы пользователей через форму логина или регистрации — так, пустячок.
То, что большинство делает неправильно — это мотивация, а не оправдание, на мой взгляд.
Алсо я же не спорю что вы правы, и комментарий выше тоже прав. Да, очень мало компаний заморачиваются вообще что-либо проектировать, просто слепили из веточек и желудей какой-то сайт и айда в продакшен. Поэтому безопасность в интернете в такой жопе, и все время утекают какие-то БД, и 2FA оказывается можно обойти. В этой ситуации утечка базы пользователей через форму логина или регистрации — так, пустячок.
То, что большинство делает неправильно — это мотивация, а не оправдание, на мой взгляд.
А может, пользователю стоит самому побеспокоиться о своей приватности? Например, не регистрироваться с рабочего емайла на порнхабе.
А может, пациенту стоит самому побеспокоиться о своем здоровье? Например, не болеть.
Правильный ответ — конечно. Пользователь делает свою часть, сайт — свою, разработчики браузера тоже чего-то там делают.
Это не состязание же, we're in this together.
Правильный ответ — конечно. Пользователь делает свою часть, сайт — свою, разработчики браузера тоже чего-то там делают.
Это не состязание же, we're in this together.
А может, пациенту стоит самому побеспокоиться о своем здоровье? Например, не болеть.Представьте себе — да. Альтернатива — за нас побеспокоится государство, запрет всех по домам и будет штрафовать за выход на улицу чаще двух раз в неделю, заодно создавая огромные толпы в местах проверок пропусков.
И да, я видел, как о моей безопасности заботятся разработчики сайтов. «Пароль должен состоять не менее чем из 12 символов, не менее одной прописной буквы одной строчной буквы, одной цифры, одного специального знака, одного пробела, двух раскладок клавиатуры, трех иероглифов и одного заклинания вызова сатаны. Ах да, не забудьте менять пароль каждую неделю». Нет, спасибо, я лучше сам о себе позабочуть.
Представьте себе — да.
Я так и написал. И государство побеспокоится, например, предоставит медицинскую помощь, если все же заболели, а не оставит на лавке умирать. (Разные государства делают это по-разному, и в некоторых случаях таки оставят умирать на лавке — наслаждайтесь, именно так выглядит «я сам о себе позабочусь» для среднего пользователя.)
Спасибо за статью, хотелось бы покритиковать некоторые пункты из книги.
, он настолько мелкий, что неудобен, да, зато прокрутка мыши в нем работает. А у вас? :) На Андроиде — хорошие нативные селекты есть, тем более для выбора времени.
Тем не менее, порядок кнопок «Да, Нет/Отмена» — должны быть выполнены именно в таком порядке. Менять их местами допустимо только в случае, когда меняется очень важная настройка и есть цель — сбить пользователя от рефлекторной привычки нажать на левую кнопку («Да» по-умолчанию).
3. Не просите повторить парольЛадно, не будем. Допустим, пользователь тогда ошибается адресом почты и аккаунт/имя уходят в Тартар. Имхо, надо оставлять два поля под почту, но не мешать автозаполнению полей (помню, в некоторых местах второе поле всегда препятсвовало автозаполнению — вот это мракобесие).
Мнение: Я стараюсь не использовать селекты если пунктов меньше или равно 3-м. Если так, то проще сделать теги или радио-группу. Возможно именно факт, что некоторые люди считают, что это поле ввода, а не селектА это уже проблемы вашего (или не вашего) дизайна, когда невозможно распознать поле интерактивное (с вводом) или нет. Вот пример с системной темы Win7:
6. Когда не нужен календарик для указания датСогласен и не согласен. Сколько форматов дат будете поддерживать? А если британский формат где косые черты, но месяц и день не перепутаны как в американском? Не затрагивает? А что если интернациональная команда? Ну тогда понадеямся на локаль браузера — это уже будет лучше захардкоженого формата. А если рукопись не распознаем — календарик очень даже не помешает (и неплохо было бы отослать такой случай себе в лог).
8. Юзайте «– / +» вместо селектовЮзайте нативные селекты. Да на винде
, он настолько мелкий, что неудобен, да, зато прокрутка мыши в нем работает. А у вас? :) На Андроиде — хорошие нативные селекты есть, тем более для выбора времени.9. Размер поля должен быть под контентСогласен. И нефиг разбивать ввод 4-х значного пин-кода на 4 разных поля, одно удобнее и привычнее и авто-ввод с copy-paste будет гарантированно работать.
10. Говори сразу, где ошибкаНе так смертельно, имхо (только в контексте логина и пароля, см. комментарии по поводу секурности). Но надо избегать ресета полей после отправки на сервер — вот это действительно бесит.
1. Выравнивайте кнопки по левому краюЯ считаю, что в качестве заключительного действия выравнивание кнопки «отправить» по правому краю оправданно. Слева-направо заполнили последнее поле и заканчиваем, нажимая кнопку справа. Ещё дело привычки: поля «Ок, Отмена, Применить» в Windows были выровнены справа внизу.
Тем не менее, порядок кнопок «Да, Нет/Отмена» — должны быть выполнены именно в таком порядке. Менять их местами допустимо только в случае, когда меняется очень важная настройка и есть цель — сбить пользователя от рефлекторной привычки нажать на левую кнопку («Да» по-умолчанию).
2. Не дизейблите кнопкуСогласен, стоит при нажатии на кнопку отбросить пользователя к месту, где что-то неправильно заполнено.
3. Писать на кнопках глаголПричем на русском этому легче следовать, чем на английском: «Login» против «Войти»
Не фильтровать без нажатия на кнопку «Фильтр».Туда же. «Фильтровать», а по-английски в лучшем случае будет «Apply»
5. При длинной форме не стыдно ставить кнопку сверхуУже ответили, что у Яндекса стоит сверху и снизу. Вторая кнопка снизу ничего не стоит, это вам не вторую ручку прикручивать :)
1. Разносить поля Логин и Пароль на разные страницы — не стыдноСтыдно. Параграфом выше пишется про браузеры и автоматизацию, и тут же их ломаем. Как минимум авто-ввод менеджера паролей, а ещё «сбрасываем» концентрацию человека тем, что меняем что-то на экране.
2. Показывать шаги не обязательноПо-моему именно Амазон улучшил конвертацию тем, что лучше обозначил финальный шаг, где будет производиться оплата (надо поискать не изменяет ли память). Да и пользователю удобнее, тем более если полей много и вдруг понадобится вернуться куда-то назад.
А что на счёт «Писать ошибку» между Лейблом и полем думаете? Меня в книге этот паттерн довольно сильно смутил.
«Да, Нет/Отмена» — должны быть выполнены именно в таком порядке
Я сомневаюсь в такой однозначности. Там, где принято «Слева-направо», «Вправо» тождественно «Вперед», но в этом случае «Отмена» в конце, не ведет вперед, к следующему действию/странице, а возвращает назад, соот. логичнее поменять кнопки местами.
Разносить поля Логин и Пароль на разные страницы — не стыдно
Очень напрягает такое, когда логин и пароль вводишь автоматом (клавиатурной командой) из KeePass.
Британское правительство удалило такой бар и конверсия ничего не изменилась.
А у пользователей ресурсов британского правительства был выбор?
Большинство правительственных ресурсов жуткие, но ты всегда пробираешься через все препятствия, потому что другого выхода у тебя просто нет.
Взгляд идёт слева направо
Неверно для тех наций, которые читают справа налево. Лучше сказать "движение глаз совпадает с направлением чтения текста". Для конкретной графической системы, как правило, это настраивается свойством RTL, значение которого можно запросить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Form design patterns. Обзор книги