Регистрация
5 мая 2020 в 19:32

Form design patterns. Обзор книги

image

Введение от автора обзора


Книга раскрывает, порой не очевидные для дизайнеров и фронтендеров, темы оформления полей, концепции работы с типами данных и юзабилити. Книга будет полезна и новичкам и разбирающимся в теме проектировщикам интерфейсов, т. к. первым даст понимание основ, а вторым пищу для размышлений над, порой спорными, паттернами проектирования. Обзор будет представлен в виде коротких тезисов из книги и краткими комментариями обзорщика.

Часть первая. Про поля


1. Лейбл сверху лучше лейбла слева


image

Почему: Тезис ставший классикой жанра. На эту тему написано куча статей, например вот эта и сотни ей подобных. Также, располагая лейбл сверху мы получаем больше места если лейбл длинный. Казалось бы это очевидно, но многие дизайнеры упорно ставят лейблы слева.

2. Плейсхолдеры не для описания правил заполнения


image
Почему: Плейсхолдеры исчезают при клике + обрезаются в поле.

3. Не просите повторить пароль


image
Почему: Бесит вводить по два раза.

4. Текст ошибки писать между лейблом и полем


image
Почему: Не закроется автокомплитом или клавиатурой на мобилке.

Мнение: Вроде бы тезис понятен, но выглядит это уж супер не привычно. За всё время проектирования интерфейсов (9+ лет) я такое встречал только однажды и только в макетах одного дизайнера. Но, возможно, стоит взять этот паттерн на вооружение.

5. Селекты лучше не использовать


image
Почему: Скрывают варианты, не зумятся на некоторых устройствах, лишний клик, кто-то пытается в них писать.

Мнение: Я стараюсь не использовать селекты если пунктов меньше или равно 3-м. Если так, то проще сделать теги или радио-группу. Возможно именно факт, что некоторые люди считают, что это поле ввода, а не селект и пытаются туда писать, породил гибрид инпута и селекта в виде выпадающего меню, но первым пунктом которого идёт поле ввода (чаще всего поиск). Это и решение и костыль одновременно.

6. Когда не нужен календарик для указания дат


image

Календарь не нужен для:

  • Даты рождения, т. к. эту дату все помнят наизусть и её проще ввести руками;
  • Даты окончания действия карты;
  • Дат, которые написаны в документах и их надо просто перепечатать не задумываясь.

7. Придумайте «парольную фразу»


image
Почему: Есть мнение, что фразу проще запомнить.
Мнение: ¯\_(ツ)_/¯

8. Юзайте «– / +» вместо селектов


image
Правило: Юзайте плюс и минус если числа не большие. Хороший пример — выбор количества пассажиров на рейс. В книге написано, что были тестирования на этот счёт и плюс / минус себя показали лучше.

9. Размер поля должен быть под контент


image

Почему: Да потому что это логично! И не важно что так поля получаются не ровненькими. Зато с полсекунды понятно какого типа контент там должен быть.

10. Говори сразу, где ошибка


image

Почему обычно не так: Считается, что это не секьюрно ведь говоря, что пароль не правильный мы намекаем, что логин верен. Но по факту хакеры не будут проверять все существующие в мире пароли если узнают, что Логин, который чаще всего адрес эл. почты и является открытой информацией, подходит.

Часть вторая. Про кнопки


1. Выравнивайте кнопки по левому краю


image

Почему: Взгляд идёт слева направо. Исключением может являться модальное окно в котором нет полей ввода. Например, в Гугловом матириал дизайне кнопки в модалках справа.

2. Не дизейблите кнопку


image

Почему: На неё нельзя будет перейти нажав Tab, она не прочитается некоторыми скрин-ридерами и её плохо видно из-за серости.

Мнение: Я до недавней поры предпочитал дизайблить кнопку чтобы дать понять юзерам, что они что-то недозаполнили в форме. И как-то даже не ставил под сомнение, что это может быть не очевидно. Тесты на юзерах показали, что пользователи видят серый цвет, но далеко не все понимают, что он означает, что что-то не так. Это как если бы вы впервые увидели светофор и были способны различить его цвета, но просто не знали, что значит каждый цвет. Вам было бы без разницы какой сейчас горит.

3. Писать на кнопках глагол


image

Почему: Так понятнее, что произойдёт.

4. Не ставить ссылку «Не помню пароль» перед кнопкой


image
Почему: Для тех кто переходит по полям через Таб это может сработать, как переход на ссылку вместо кнопки и он по привычке нажмёт на Ентер, запустив ненужный сценарий восстановления пароля.

5. При длинной форме не стыдно ставить кнопку сверху


image

Мнение: Ерунда какая-то. Уж лучше кнопку зафиксировать снизу чтоб всегда была видна при скроле. Но, например, Яндекс.Почта ставит кнопку сверху.

image

Часть третья. Браузеры и автоматизация


  • Не делать автопереходы с одного поля на другое при вводе нужного количества символов. Это может путать юзеров
  • Браузеры с поддержкой HTML5 имеют встроенные валидаторы форм и в каждом браузере своя логика. Есть смысл отключить валидацию по умолчанию
  • Стоит отключать авто исправление ошибок и авто-увеличения первой буквы. Иначе юзерам кажется, что это была ошибка и данные были бы не приняты
  • По статистике автозаполнение в Хроме используется 9 миллиардов раз в месяц. Это, в среднем, экономит юзеру 12 секунд, что даёт 1 250 000 дней в месяц. Забавный факт
  • Не фильтровать без нажатия на кнопку «Фильтр». Кнопка нужна, например если есть не только радио и чекбоксы, но и поля ввода (стоимость, какие-то интервалы и пр.). Но сами же дальше пишут про тесты, где юзеры считали, что фильтр не работает не понимая, что надо нажать на кнопку «Фильтр». ¯\_(ツ)_/¯

Часть четвёртая. Про всё подряд


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

1. Разносить поля Логин и Пароль на разные страницы — не стыдно


На сайте GOV.UK в форме авторизации сделали Логин на одной странице, а Пароль на другой (сейчас уже не так) и юзеры ничего странного не заметили.

Мнение: Сейчас всё чаще замечаю такой подход. От Гугла, до разных сервисов типа Abstract.

image

2. Показывать шаги не обязательно


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

image

3. Тема с запоминанием 7 ±2 элемента больше не актуальна


Почему: Т. к. на сайтах никто ничего и не запоминает. Можно просто скролить наверх если что-то забыл.

4. Ставьте поля адреса в порядке принятом в конкретном регионе


Это уже не из книги, а из моего ресёрча. В международной почтовой ассоциации написаны правила. Например в России принят такой порядок:

  • Иванов Иван
  • ул. Лесная, дом 5, кв. 11
  • г. Москва
  • Россия
  • Почтовый индекс
Теги:
Хабы:
Ой, у вас баннер убежал!

Ну. И что?
Реклама

Похожие публикации

Вакансии

Больше вакансий на Хабр Карьере
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 36

    +1
    Отлично написаная статья. С формами так и надо.

    Кое какие моменты хотелось бы добавить:

    3. Не просите повторить пароль
    При регистрации или восстановлении лучше, все-таки повторить. А при обычном входе конечно два раза ни к чему.

    Нет смысла показывать прогресс-бары с шагами. Они занимают много места. Британское правительство удалило такой бар и конверсия ничего не изменилась.
    Сколько раз встречал прогрес-бар с шагами — всегда это добавляло уверенности и ясности. Может не стоит только на конверсию ориентироваться? И размер поменять, чтобы много не занимали места.

    3. Тема с запоминанием 7 ±2 элемента больше не актуальна
    Почему: Т. к. на сайтах никто ничего и не запоминает. Можно просто скролить наверх если что-то забыл.
    Никто действительно ничего не запоминает. Просто в маленьком списке легче находить одним взглядом.

      0
      Думаю автор всё же имел ввиду однократный ввод пароля именно при регистрации. Если где-то ещё и при ауентификации просят ввести его дважды, то, возможно владельцы сайта просто пытаются снизить конверсию, чтобы бизнес не развивался слишком быстро. И я согласен с автором — однократного ввода пароля при регистрации достаточно для подавляющего количества сайтов. Большинство юзеров до сих пор используют единый пароль и ошибиться в нём могут разве что в раскладке, но от этого повтор пароля не спасает.
        0
        Да, имел ввиду именно при реге.
          0
          А что делать если я при регистрации перепутал порядок букв в своей парольной фразе? Я очень часто пишу «fi» вместо «if» например. Когда меня не просят повторить пароль, то у меня возникает смутное подозрение, что пароль, а не его солёный хэш, хранится на данном сайте и скорее всего будет прислан прямо по почте. Для некоторых сайтов это наверное приемлемо, но точно не для всех.
            0
            Т.е вас смущает не то что ваш пароль храниться в открытом виде на сайте, а то что он будет прислан на почту при восстановлении пароля? Потому что на первое(хранение на сайте) введение его хоть трижды при регистрации никак не повлияет. И то, что кто-то до сих пор таким образом восстанавливает пароли(а не заданием нового) должно вас немного насторожить.
              0
              Нет, меня смущает именно хранение в открытом виде, а отправка по почте — это лишь следствие и верный признак такого хранения. Я не достаточно точно сформулировал мысль. И количество ввода паролей при регистрации — то же всего лишь эвристика на такое хранение.

              P.S. Вообще мне только сейчас пригла в голову мысль, что даже если ошибусь при первичном вводе пароля, то вход будет точно таким же, как если я его забуду — через восстановление пароля.
          +1
          Понимаю, что опечатка, но сильно забавно:
          ауентификация – это когда при аутентификации отправляешь заголовок «Вечер в хату»
        0
        Про кнопки «ок» и «отправить». Есть мнение что это разработчикам очевидно что что-то куда-то отправляется. Простому пользователю может быть не понятно зачем отправлять что-то куда-то отправлять ведь он только войти на сайт хотел. Так что, по-моему, понятней была бы кнопка «войти».
          0
          Так вы как раз последовали тому пункту. Там смысл в использовании как раз глаголов.

          Т.е. на форме входа очевидно лучше кнопку назвать «Войти» нежели «ОК».
            0
            Это ещё со времён «Отправить данные».
            0
            Яндекс.Почта ставит кнопку сверху.

            Она снизу дублируется вместе с остальными.
            2. Не дизейблите кнопку

            При табе мы переходим не на кнопку а в поле ввода. С другой стороны при активности поля она должно выделяться как то. Так ведь?
            А серая кнопка, интуитивно может подсказать, что отправлять нечего — лишняя проверка перед отправкой это лучше чем перезаполнять вссю форму ввода.

            -Попробовал тут «потабать». ХЗ куда я попадаю. Нажал «Ввод» — ушёл не туда.
              +1
              Я там как раз пишу, что серая кнопка может подсказать, что отправлять нечего, но судя по моим исследованиям, не подсказывает ). Да, люди видят, что она серая, но серый цвет не всем однозначно говорит, что «Нет, ты не пройдёшь». Для многих это просто цвет.
                0
                Ну, суть то в том, что кнопку надо сделать неактивной (можно текст на ней под фон. Или затемнить как-то). Ну, в смысле, чтобы пользователь однозначно определил её неактивность. И, вроде бы привычно уже — кнопочка засветилась, значит я ничего не забыл ввести. Первичная проверка корректности ввода.
              +1
              Почему все формы гребут под «конверсию» и забывают о служебных формах (допустим, CRM, SaaS), где эта конверсия никому не снилась? А требуется удобство и простота, точность ввода данных (значений) и уменьшение кликов (к примеру, вместо селекта из 3 пунктов — радиокнопки/селекты; объединение полей, типа адрес и прочее).

              Почему не уделяется должное внимание биг-формам (прошу прощения за название), которые хранят значения в стандартизированных справочниках (банковские, страховые и медицинские отрасли). И полей в форме может быть более полусотни. Я работаю в настоящее время с подобными формами, это ад и интересная практика одновременно.

              Мне уже начинает надоедать такой вечный перепост уже очевидных вещей, публикующихся с 2011 года.
                0
                Я тоже работаю с такими формами при проектировании интерфейсов для внутреннего пользования сотрудниками Леруа Мерлен. Там реально есть адский ад, который ты описал и, да, наверное было бы не плохо про это когда-то написать.
                  0
                  Ну может когда-нибудь соберёмся и напишем.
                    0
                    Очень было бы интересно почитать про формы 30+ полей для различных прикладных систем. Вечные споры про выравнивание лейблов, поля столбцами или строчками и т д.
                      0
                      Проблема в том что такие формы уж очень сильно зависят от контекста. Формы регистрации везде примерно одно и тоже делают, а вот какими должны быть формы с специфической внутренней SaaS системы? Какова вероятность того что то что работает в одной сложной форме, будет работать в другой? Тут не обойтись книгой/статьей где просто показывают два примера и говорят «делай так, а не так». Это больше про подход к дизайну в целом, про проведение исследований (о том как и зачем вводиться информация в эти формы) и тд.
                0
                10. Говори сразу, где ошибка

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

                За примерами далеко ходить не надо: Ashley Madison, OnlyFans и другие сайты. Данные о том, что человек зарегистрирован на сайте, уже приводили к увольнениям, разводам и даже самоубийствам. Не гипотетически, реальные люди лишились работы и иногда жизни из-за утечки информации.

                Еще один «хороший» вектор это фишинг. Если я могу точно установить, что пользователь зарегистрирован на определенном сайте, то таргетированный фишинг будет во много раз успешнее, нежели просто присылать письма «Вы получили сообщение в Одноклассниках», а у пассажира там и аккаунта-то нет.

                В общем, слушайте сначала секьюрити-специалистов, а только потом дизайнеров.
                  0
                  Дельное замечание. Могу тогда предположить, что стоит подумать, где можно говорить в каком поле ошибка, а где нет. Например, на порнхабе лучше не говорить.
                    0
                    Да, некоторые сайты более критичны к этому, безусловно.

                    Еще один вектор, который не указал выше: пользователи часто ставят одинаковые или схожие пароли на разных сайтах, поэтому когда утекла БД сайта Bookmate, у людей взломались почты и прочие вконтакты.

                    Тут валидация напрямую вроде бы не влияет, ведь если логин-пароль одинаковые, то взломщик просто войдет в аккаунт. Но когда мы атакуем конкретного человека, а не брутфорсим всю утекшую БД, то переменных становится больше: у нас может быть несколько вариантов почты (всякие [email protected]), несколько утекших паролей этого пассажира от разных сайтов, и тут UX формы нам снова начинает активно помогать это ломать.
                    0
                    А что секьюрити-специалисты говорят про форму восстановления пароля? Только что сходил на onlyfans и habr — они честно сказали, что такого юзера нет и кажется это поведение большинства подобных форм. Если таким нехитрым образом мы уже получаем информацию о почте, то и смысла не говорить что именно неправильно на форме входа тоже мало.

                    P.S. Наверное на чувствительных сайтах стоит делать вход по имени пользователя, а не почте.
                      0
                      Тот же принцип — правильно спроектированная система скажет, мол, отправляю ссылку для восстановления на почту. Как в случае успеха, так и в случае ошибки.

                      Вообще сообщения об ошибках в чувствительном к безопасности контексте — потенциальный вектор атаки. На этом построены целые классы уязвимостей, например padding oracle.
                      0
                      т.к. информация, что конкретный пользователь зарегистрирован на сервисе

                      Да? А тогда при регистрации не будем говорить, что адрес уже используется? Тогда пути два, при вводе уже зарег. эл. почты:
                      • не делать ничего
                      • слать сброс пароля на этот адрес

                      Иначе будет утечка информации через форму регистрации, и для целевой атаки — это раз плюнуть. И я пока не разу не видел предложенного мною концепта. Если какой-то сайт и заморачивался с «Неверный пароль ИЛИ логин», то при регистрации можно было легко перепробывать существующие аккаунты (а верх идиотизма это endpoint для AJAX для проверки логина на коллизию, когда не надо даже триггерить саму регистрацию)
                        +1
                        Ну да, это тоже проблема. Решается обычно тем, что «мы прислали вам на почту ссылку-подтверждение, нажмите на неё чтобы войти на сайт».

                        Алсо я же не спорю что вы правы, и комментарий выше тоже прав. Да, очень мало компаний заморачиваются вообще что-либо проектировать, просто слепили из веточек и желудей какой-то сайт и айда в продакшен. Поэтому безопасность в интернете в такой жопе, и все время утекают какие-то БД, и 2FA оказывается можно обойти. В этой ситуации утечка базы пользователей через форму логина или регистрации — так, пустячок.

                        То, что большинство делает неправильно — это мотивация, а не оправдание, на мой взгляд.
                        0
                        А может, пользователю стоит самому побеспокоиться о своей приватности? Например, не регистрироваться с рабочего емайла на порнхабе.
                          +1
                          А может, пациенту стоит самому побеспокоиться о своем здоровье? Например, не болеть.

                          Правильный ответ — конечно. Пользователь делает свою часть, сайт — свою, разработчики браузера тоже чего-то там делают.

                          Это не состязание же, we're in this together.
                            0
                            А может, пациенту стоит самому побеспокоиться о своем здоровье? Например, не болеть.
                            Представьте себе — да. Альтернатива — за нас побеспокоится государство, запрет всех по домам и будет штрафовать за выход на улицу чаще двух раз в неделю, заодно создавая огромные толпы в местах проверок пропусков.

                            И да, я видел, как о моей безопасности заботятся разработчики сайтов. «Пароль должен состоять не менее чем из 12 символов, не менее одной прописной буквы одной строчной буквы, одной цифры, одного специального знака, одного пробела, двух раскладок клавиатуры, трех иероглифов и одного заклинания вызова сатаны. Ах да, не забудьте менять пароль каждую неделю». Нет, спасибо, я лучше сам о себе позабочуть.
                              0
                              Представьте себе — да.

                              Я так и написал. И государство побеспокоится, например, предоставит медицинскую помощь, если все же заболели, а не оставит на лавке умирать. (Разные государства делают это по-разному, и в некоторых случаях таки оставят умирать на лавке — наслаждайтесь, именно так выглядит «я сам о себе позабочусь» для среднего пользователя.)
                        0
                        Спасибо за статью, хотелось бы покритиковать некоторые пункты из книги.
                        3. Не просите повторить пароль
                        Ладно, не будем. Допустим, пользователь тогда ошибается адресом почты и аккаунт/имя уходят в Тартар. Имхо, надо оставлять два поля под почту, но не мешать автозаполнению полей (помню, в некоторых местах второе поле всегда препятсвовало автозаполнению — вот это мракобесие).

                        Мнение: Я стараюсь не использовать селекты если пунктов меньше или равно 3-м. Если так, то проще сделать теги или радио-группу. Возможно именно факт, что некоторые люди считают, что это поле ввода, а не селект
                        А это уже проблемы вашего (или не вашего) дизайна, когда невозможно распознать поле интерактивное (с вводом) или нет. Вот пример с системной темы Win7: win7 native drop down menu vs number input

                        6. Когда не нужен календарик для указания дат
                        Согласен и не согласен. Сколько форматов дат будете поддерживать? А если британский формат где косые черты, но месяц и день не перепутаны как в американском? Не затрагивает? А что если интернациональная команда? Ну тогда понадеямся на локаль браузера — это уже будет лучше захардкоженого формата. А если рукопись не распознаем — календарик очень даже не помешает (и неплохо было бы отослать такой случай себе в лог).

                        8. Юзайте «– / +» вместо селектов
                        Юзайте нативные селекты. Да на винде win7 native number input field, он настолько мелкий, что неудобен, да, зато прокрутка мыши в нем работает. А у вас? :) На Андроиде — хорошие нативные селекты есть, тем более для выбора времени.

                        9. Размер поля должен быть под контент
                        Согласен. И нефиг разбивать ввод 4-х значного пин-кода на 4 разных поля, одно удобнее и привычнее и авто-ввод с copy-paste будет гарантированно работать.

                        10. Говори сразу, где ошибка
                        Не так смертельно, имхо (только в контексте логина и пароля, см. комментарии по поводу секурности). Но надо избегать ресета полей после отправки на сервер — вот это действительно бесит.

                        1. Выравнивайте кнопки по левому краю
                        Я считаю, что в качестве заключительного действия выравнивание кнопки «отправить» по правому краю оправданно. Слева-направо заполнили последнее поле и заканчиваем, нажимая кнопку справа. Ещё дело привычки: поля «Ок, Отмена, Применить» в Windows были выровнены справа внизу.
                        Тем не менее, порядок кнопок «Да, Нет/Отмена» — должны быть выполнены именно в таком порядке. Менять их местами допустимо только в случае, когда меняется очень важная настройка и есть цель — сбить пользователя от рефлекторной привычки нажать на левую кнопку («Да» по-умолчанию).

                        2. Не дизейблите кнопку
                        Согласен, стоит при нажатии на кнопку отбросить пользователя к месту, где что-то неправильно заполнено.

                        3. Писать на кнопках глагол
                        Причем на русском этому легче следовать, чем на английском: «Login» против «Войти»
                        Не фильтровать без нажатия на кнопку «Фильтр».
                        Туда же. «Фильтровать», а по-английски в лучшем случае будет «Apply»

                        5. При длинной форме не стыдно ставить кнопку сверху
                        Уже ответили, что у Яндекса стоит сверху и снизу. Вторая кнопка снизу ничего не стоит, это вам не вторую ручку прикручивать :)

                        1. Разносить поля Логин и Пароль на разные страницы — не стыдно
                        Стыдно. Параграфом выше пишется про браузеры и автоматизацию, и тут же их ломаем. Как минимум авто-ввод менеджера паролей, а ещё «сбрасываем» концентрацию человека тем, что меняем что-то на экране.

                        2. Показывать шаги не обязательно
                        По-моему именно Амазон улучшил конвертацию тем, что лучше обозначил финальный шаг, где будет производиться оплата (надо поискать не изменяет ли память). Да и пользователю удобнее, тем более если полей много и вдруг понадобится вернуться куда-то назад.
                          0
                          А что на счёт «Писать ошибку» между Лейблом и полем думаете? Меня в книге этот паттерн довольно сильно смутил.
                            0
                            Вот меня тоже, в случае мобильной клавиатуры это может и оправдано, но если форма на большом экране, при появлении ошибки, все нижележащие поля начнут скакать, это очень раздражает.
                            Если резервировать место под ошибку, тогда лейбл в обычном состоянии визуально отрывается от поля.
                            0
                            «Да, Нет/Отмена» — должны быть выполнены именно в таком порядке


                            Я сомневаюсь в такой однозначности. Там, где принято «Слева-направо», «Вправо» тождественно «Вперед», но в этом случае «Отмена» в конце, не ведет вперед, к следующему действию/странице, а возвращает назад, соот. логичнее поменять кнопки местами.
                            +1
                            Разносить поля Логин и Пароль на разные страницы — не стыдно

                            Очень напрягает такое, когда логин и пароль вводишь автоматом (клавиатурной командой) из KeePass.
                              +2
                              Британское правительство удалило такой бар и конверсия ничего не изменилась.


                              А у пользователей ресурсов британского правительства был выбор?

                              Большинство правительственных ресурсов жуткие, но ты всегда пробираешься через все препятствия, потому что другого выхода у тебя просто нет.
                                0
                                Взгляд идёт слева направо

                                Неверно для тех наций, которые читают справа налево. Лучше сказать "движение глаз совпадает с направлением чтения текста". Для конкретной графической системы, как правило, это настраивается свойством RTL, значение которого можно запросить.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Что обсуждают

                                Самое читаемое

                                Минуточку внимания

                                Разместить

                                Ваш аккаунт

                                Разделы

                                Информация

                                Услуги

                                © 2006 – 2020 «Habr»
                                Настройка языка
                                О сайте
                                Служба поддержки
                                Мобильная версия