данное поле обязательно для заполнения
Миф об обязательном поле
В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».
Считается также, что некорректные (неполные) данные настолько страшны, что даже хранить их в базе данных уже некорректно. Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Что на это имеет сказать современная наука проектирования взаимодействия с пользователем? Во-первых, стало ясно (уж не знаю, кому и когда, но достаточно давно точно, см. [1] и [2]), что все-таки программы разрабатываются для пользователей. В этом смысле программист уже не диктует условия, а скромно создает сугубо утилитарный продукт, инструмент, которым будут пользоваться люди для решения своих задач и достижения своих целей. Как утюг — если тебе нужно что-то погладить, ты его включаешь. Если он будет вместо того, чтобы гладить, модально предлагать скачать обновления из интернета, понятно, куда такой утюг полетит. Алан Купер [1] рекомендует представлять пользователей вашего продукта как очень умных, но очень занятых людей. Они, мол, не тупые и поймут, как вашим продуктом пользоваться, главное, вы только не вставайте у них на пути.
Я вообще считаю, что каждому программисту (дизайнеру, менеджеру, аналитику) следует проделать медитацию, упомянутую Сергеем Бодровым-мл.:
Ты становишься на углу оживленной улицы и представляешь, что тебя здесь нет. Вернее, тебя нет вообще. Пешеходы идут, сигналят машины, открываются двери магазинов, сменяются пассажиры на остановке. То есть в принципе мир продолжает жить и без тебя. Понимать это больно. Но важно.
Я, конечно, вовсе не хочу сказать, что программист — профессия ненужная, я сам программист и совсем так не считаю. Просто это неблагодарная профессия. Никто не придет и не похвалит за хорошо реализованный алгоритм. Если программа хороша, ей будут пользоваться без дополнительных вопросов. Так и должно быть, просто, чтобы быть программистом, надо к этому привыкнуть. А эти вот люди, которые идут по улице и сменяются на остановке — это ваши пользователи. Они используют вещи так, как они им нужны. В том числе и ваш продукт. Без вас. Они ничего о вас не знают, не хотят знать и никогда не узнают. Сергею Витальевичу, когда он в полярной тундре пытается вбить в систему снятые со счетчика показания, совершенно не интересно, почему система говорит ему, что сперва требуется указать какой-то там тип тарификации, даже если в момент проектирования вам казалось, что без типа тарификации ну уж никак не обойтись. А что касается примера про утюг, скачивающий обновления, то он взят совсем не из пальца — обратите внимание, как ведет себя при включении браузер Файерфокс.
Тут вообще будет что-нибудь про обязательные поля, спросит хабраюзер? Как раз сейчас начнется.
Штука в том, что реальный наш мир — это не математическая модель, параметры которой известны в любой момент времени. Для реальной жизни характерна скорее нехватка информации, чем ее наличие. У человека, заполняющего форму, требуемых данных может не быть — и не быть их может во всех обозримых пределах досягаемости, то есть не быть ваще. Эту проблему нельзя решить, просто сделав поле обязательным — значение из воздуха не возьмется. Вводя на формах обязательные поля в угоду целостности и полноте данных, мы на самом деле мешаем пользоваться системой. Столкнувшись с такой ситуацией, пользователь либо не станет заполнять форму (и не сможет работать с системой вовсе), либо заполнит недостающие данные рыбой — выдуманными или бессмысленными данными. И это свидетельствует не о том, что пользователь плохой или плохо старался, а лишь о том, что разработанная система недостаточно гибка для использования в условиях реального мира. То, что произошло во втором случае (ввод рыбы) — это вообще обман. Разработчик системы может сколько угодно делать вид, что все в порядке, но на самом деле в этом обмане виноват именно он. Причем непонятно, кто и что вообще выиграл — пользователь поимел головную боль, а в систему попали некорректные данные. Да попали так, что обнаружить, отфильтровать или подчистить их автоматически уже невозможно — в отличие от случая, если бы пользователь просто указал, что информация отсутствует.
Что же делать? Делать нужно хорошие программы. А именно, да, таки не ставить целостность схемы БД во главу угла, а ставить туда цели и задачи пользователей. Другими словами, принимать у пользователя неполные, а в некоторых случаях и некорректные данные, естественно, с возможностью исправить их в будущем. Вопреки заблуждению (да, еще одному) это возможно, это не так сложно и это даже работает. Кроме этого, нужно еще каким-то образом помогать, подсказывать пользователю, где, каких данных и для чего ему не хватает. Чтобы он видел и контролировал ситуацию.
Сколько обязательных полей должно быть на форме? В идеале, ноль. Всегда ли такое возможно? Для меня одним из примеров высшего пилотажа является операция создания папки в Виндоус. Казалось бы, уж меньше одного поля тут не сделаешь, однако нет, они умудрились реализовать создание так, что система не спрашивает ничего — даже несмотря на то, что технические ограничения не позволяют системе создать папку без имени. Это идеал, к которому нужно стремиться.
Естественно, система должна быть минимально умной, спрашивая у пользователя только то, что имеет отношение к задачам пользователя, а не к потребностям самой системы. Система как инструмент, помните? Как раз про пример с Файерфоксом — Гугл Хром, например, решил проблему Файерфокса, обновляясь тихонько в тот момент, когда пользователь его перезагружает. Пользователю об этом знать совсем не нужно — он и не знает. Достойный пример для подражания. Я, признаться, даже сперва не понял, чегой-то он меня ни разу не спрашивал, когда ему обновляться?
Еще был миф о важных полях (это те, которые необязательны, но желательны к заполнению). Здесь все еще проще — принудительно заставить заполнить поле нельзя. Следовательно, хоть помечай поле как обязательное, хоть не помечай — все равно напишут рыбу, чушь, отписку, если не захотят заполнять. Интерфейсного решения у этой проблемы нет. Важность полей нужно доносить до сотрудников на местах. А разработчику пометить поле как необязательное. И позволить редактировать.
UPD: В комментариях trijin и zhindetz понятнее сформулировали основную мораль топика: речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво. То есть да, делать необязательными даже те поля, без которых система не будет работать. Естественно, она и не будет работать, но пусть хотя бы данные похранит.
UPD #2: Уточню еще одну вещь, которую я сам не осозновал ясно, когда писал топик. Я не обсуждаю здесь вопросов уместности тех или иных полей на форме (это важная, но все-таки немного другая тема, чем та, которую мне хочется донести). Я скорее предлагаю переосмыслить саму концепцию ввода информации с помощью форм, тот традиционный подход, когда нужно заполнить всю форму сразу и корректно. Вместо этого я предлагаю промежуточное состояние (неполное, некорректное, противоречивое) тоже позволять сохранять в БД, явным образом помечая такое состояние как неполное/некорректное/противоречивое. Таким образом все ситуации «я сейчас знаю не все, но завтра, может быть, узнаю», которые традиционно решаются записыванием на бумажку, можно обрабатывать с помощью информационной системы. Естественно, такие данные не нужно пускать в бизнес-процесс в силу их некорректности — тут все остается как раньше. Они просто полежат в БД до лучших времен — не пригодятся, ну и бог с ними.
Обязательные поля формы
Дата публикации: 2016-10-03
От автора: приветствую вас, друзья. В этой статье мы с вами поговорим о валидации форм. Мы узнаем, как проверить форму перед отправкой на заполнение обязательных полей формы. Начнем?
Исходные файлы текущей статьи вы можете скачать по ссылке.
Итак, перед нами есть простейшая форма с полями, каждое из которых мы хотим сделать обязательным к заполнению. Каждое поле формы имеет тип text и примерно следующий код:
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Перед отправкой формы мы должны проверить каждое поле на предмет того, заполнено ли оно и, если какое-то из полей оказалось не заполнено, тогда мы должны уведомить об этом пользователя и не отправлять форму на сервер. В общем, нам необходима валидация формы в части проверки заполнения обязательных полей.
Ранее для валидации формы на клиенте нельзя было обойтись без возможностей JavaScript. Есть множество плагинов, позволяющих гибко провести валидацию формы и, в частности, проверить, заполнены ли обязательные поля. Однако в HTML5 можно вовсе обойтись без JavaScript и провести валидацию только средствами HTML5. Давайте посмотрим, как это сделать.
Итак, мы договорились, что все поля формы обязательны. Для того, чтобы это было так, нам достаточно использовать всего один атрибут, который необходимо добавить к обязательному полю, это атрибут required. Добавим его:
А теперь попробуем отправить форму, не заполняя ее.
Как видим браузер не дает отправить форму, подсказывая, что поле не заполнено. Чтобы помочь и подсказать пользователю, какие поля являются обязательными, принято рядом ставить красную звездочку, примерно так:
Вот теперь пользователь должен понять, какие поля являются обязательными к заполнению. Ну а атрибут required не даст отправить на сервер форму с незаполненными обязательными полями. Ну и, конечно же, не забывайте о том, что проверки формы только на клиенте отнюдь недостаточно. Эта проверка необходима, скорее, для удобства пользователей, не более того. Вы же возьмите себе за правило и не забывайте: валидация всегда необходима на сервере, в противном случае вы рискуете получить пустую форму или совсем не те данные, которые ожидаете, поскольку пользователь при желании легко может убрать атрибут required и отправить на сервер пустую форму. Это называется подделать форму.
Также стоит упомянуть о том, что кроме атрибута required, HTML5 предлагает нам и другие средства, позволяющие произвести простейшую валидацию и проверку формы на клиенте. Например, мы может проверить введен ли именно email в поле email, а не просто некая строка. Как это сделать — мы узнаем уже в следующей статье. Также не забывайте о том, что гибкая валидация формы возможно с помощью JavaScript. По этой теме вы можете посмотреть данный урок. На этом все. Удачи!
Практический курс по верстке адаптивного сайта с нуля!
Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3
Обязательные поля при регистрации
Разрабатывая интерфейс для очередного сайта, основной аудиторией которого будут люди не очень продвинутые технически, я задумался над вопросом об обязательных для регистрации полях и минимизации их количества.
В голову пришли следующие варианты:
0 полей: при загрузке страницы незалогиненный пользователь получает сгенеренный аккаунт, который ему предлагают использовать, вот еще один пример такого подхода.
— удобно для узкоспециализированных задач и мне не подходит. По функционалу уже недалеко от куки, если бы не привязанность последних к конкретному хранилищу в браузере или по 🙂
1 поле: email
Пользователь оставляет email, id создается автоматически, на email он получает пароль, авторизация либо по ID либо по email, username задается пользователем уже в профиле
+ Черт, это все таки одно поле! По умолчанию может быть сгенерен устойчивый к перебору пароль.
± username свободно меняются, и могут оставаться пустыми. Учитывать пользователей по айдишникам мне не хочется
— ЧПУ приобретают вид ufosite.nl/users/18567, скорее всего пользователь захочет сменить свой пароль. При ЧПУ вида ufosite.nl/users/customusername наступает ад для поисковиков. Строить ЧПУ на основе email, который, к тому же, далеко не все захотят публиковать — это подарок спамерам и ЧПУ становятся не совсем ЧПУ.
3 поля: email, пароль с подтверждением
Наследует все от предыдущего подхода, кроме устойчивого пароля и лишних операций по смене его после регистрации.
4 поля: email, username и пароль с подтверждением
+юзернейм фиксирован, нет проблем с ЧПУ вида ufosite.nl/users/username, авторизация по username, email или id
— А ведь есть вариант, где полей меньше в четыре раза.
Ну и как дополнительное поле идет неизбежная капча, либо ее аналог.
Некоторые специалисты по юзабилити рассматривали вариант открытого ввода пароля, либо перевод режима его ввода в закрытый режим с подтверждением по активации чекбокса, но мне это кажется экзотикой.
Быть может, есть какие-то оригинальные решения проблемы минимизации количества полей при регистрации и я буду очень признателен, если вы ими поделитесь.
Пометка обязательных полей в формах
Перевод статьи Nielsen Norman Group.
Аннотация: Использование звездочки для пометки обязательных полей — это простой способ улучшить удобство использования ваших форм. Отметка только необязательных полей затрудняет заполнение формы.
Общий вопрос на многих наших UX Conference: следует ли помечать обязательные поля в форме? Если большинство полей в форме являются обязательными, должны ли мы пометить их? (Это много пометок,в конце концов.) Краткий ответ — да. И оставшуюся часть статьи я объясню, почему.
Часто дизайнеры считают, что наличие пометок для каждого обязательного поля это уродливо, повторяющееся, занимает слишком много места, а с более длинными формами, может даже показаться деспотичным (форма требует от пользователя так много!). Таким образом, они обычно принимают одну или обе из следующих стратегий:
(Редко, в некоторых ситуациях дизайнеры ничего не делают: они просто предполагают, что пользователи будут волшебным образом знать, какие поля требуется обязательно заполнить; если пользователи этого не делают, им просто придется иметь дело с возникающей ошибкой.)
Приложение для кредитных карт Citicards (слева) содержит инструкции, написанные маленьким шрифтом и курсивом. Все поля обязательны для заполнения, если не указано иное в верхней части формы; Форма American Express (справа) вообще не содержала инструкций. В обеих формах были отмечены только необязательные поля: в случае Ситибанка с несколько неясной аббревиатурой опт.
Что не так с этими “стратегиями”? Есть несколько проблем:
Люди не читают инструкции в верхней части форм
Известно, что пользователи не читают инструкции, и еще реже они читают инструкции в верхней части формы. Поля формы кажутся самодостаточными — в конце концов, каждое поле имеет определенную инструкцию — свою метку, зачем нужно читать что-то еще, чтобы заполнить ее?
Даже если люди прочитали инструкции, они могут забыть их.
Вы можете подумать: если пользователи прочитали инструкцию сверху, то как они смогут так быстро забыть? Но они забывают — особенно если форма длинная или если они отвлекаются при заполнении (ситуация, которая часто встречается на мобильных устройствах). И даже если люди не забывают инструкции, вы увеличиваете их когнитивную нагрузку, заставляя помнить ненужную информацию. Другими словами, вы усложняете им задачу. Заполнение формы — это итак задача не из легких для пользователей, почему вы хотите усложнить это еще?
Люди должны анализировать форму, чтобы определить, является ли поле обязательным
Мы увидели, что независимо от того, указали ли вы инструкции в верхней части формы или нет, результат, скорее всего, будет одинаковым — люди будут их игнорировать или забывать. Итак, что происходит, когда пользователь заполняет форму? Как они узнают, обязательно ли поле для заполнения?
Что ж, более прилежные пользователи будут оглядываться, пытаясь выяснить — они анализируют форму и находят поле, помеченное как необязательное (иногда прокручивая страницу выше, как в примере с American Express, где первое необязательное поле появляется ниже мобильного сгиба); если пользователи найдут такое поле, они будут считать, что все, что не отмечено, обязательно для заполнения. Но это требует времени и затрат на взаимодействие — и опять же, зачем вам усложнять заполнение формы для ваших пользователей?
Однако большинство пользователей не будут искать примеров и анализировать форму, они просто сделают предположения. Например, они скажут: «Ну, номер телефона — им действительно не нужен мой номер телефона, не так ли? Может быть, я оставлю это поле пустым ». И даже если они заполняют это поле, необходимость сделать паузу, чтобы решить, нужно ли заполнение, замедляет взаимодействие и делает процесс более длительным и утомительным.(Помните, как бы вам ни хотелось думать иначе, никто не хочет заполнять форму — ни на маленьком, ни на большом экране.) Результатом будет ошибка отправки формы, которая означает, что потребуется еще больше времени на решение проблемы.
Решение простое: отметьте все обязательные поля. Будьте максимально честными и прозрачными: каждое поле, которое необходимо заполнить, отметьте как обязательное.
Здесь есть как минимум два варианта: звездочка (красная или нет) и слово «обязательно».
Обязательно или нет? Как отмечать поля в формах
Привет, я Антон, UX-дизайнер в eLama — платформе для автоматизации интернет-рекламы. Мы довольно часто работаем с формами. Раньше мы выделяли обязательные поля, но увидели мнение, что этот подход не самый правильный. Мы решили разобраться, а как правильно, но быстро поняли, что единых правил нет: кто-то делает акцент на обязательных полях, кто-то, наоборот, говорит, что некоторые поля можно пропустить. Попробуем сравнить самые распространенные подходы.
Все делают по-разному
Самые распространенные способы
1. Отмечать обязательные поля звездочкой
➕ Занимает мало места.
➖ Обычно обязательных полей больше, чем необязательных, поэтому визуального шума тоже больше.
➖ Требуют расшифровки в коде для скринридера.
2. Подписывать необязательные поля
➕ Скорее всего, таких отметок будет немного, а значит, визуального шума будет меньше, чем от звездочек.
➕ Мы не давим на пользователя и не принуждаем его заполнять поля. Наоборот, мы экономим его время, показывая ему, что некоторые поля можно пропустить.
➖ Отметка может потеряться на фоне заголовка, и пользователь может ее не увидеть.
➖ Неочевидно, что поля в верхней части формы нужно заполнить обязательно. Пользователь может понять это, только когда увидит необязательные поля.
3. Вообще не отмечать поля, а показывать ошибки при отправке формы
➕ Отсутствие визуального шума. Особенно это важно в больших формах.
➖ Не всем понравится заполнять форму повторно после того, как она загорится красным.
➖ Не сразу понятно, какие поля можно пропустить, а какие нет.
4. Отмечать обязательные поля звездочкой, а необязательные —подписывать
➕ Согласно этому исследованию, такие формы самые удобные: пользователь сразу видит, какое поле пропустить можно, а какое нет.
➖ В больших формах такие отметки создают визуальный шум.
➖ Требуют расшифровки в коде для скринридера.
Важно: ставить обязательные поля выше необязательных
Если пользователь не заметит отметки, он скорее заполнит верхние поля. Если форма разбита на смысловые группы, в каждой из них обязательные поля должны быть выше, чем необязательные.
Как делаем в eLama
Мы решили использовать четвертый способ, потому что удобство пользователя важнее, и это преимущество перевешивает недостатки подхода.
Так обязательное поле не теряется даже в большой форме
Но в некоторых случаях мы используем и третий способ.
Когда не ставим отметки
1. Если поле одно
Чтобы разблокировать кнопку, можно сделать только одно: заполнить поле
2. Если можно заполнить любое поле
Кнопка разблокируется, если заполнить любое из полей
Вместо заключения
Кроме этих способов наверняка есть и другие. Важно выбрать один-два подхода, которые подходят вашему продукту.
Спасибо Сергею Токареву и Елене Отроковой за помощь в подготовке материала и редактуру.