какое поле необязательно заполнять при создании нового пользователя
Миф об обязательном поле
В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».
Считается также, что некорректные (неполные) данные настолько страшны, что даже хранить их в базе данных уже некорректно. Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Что на это имеет сказать современная наука проектирования взаимодействия с пользователем? Во-первых, стало ясно (уж не знаю, кому и когда, но достаточно давно точно, см. [1] и [2]), что все-таки программы разрабатываются для пользователей. В этом смысле программист уже не диктует условия, а скромно создает сугубо утилитарный продукт, инструмент, которым будут пользоваться люди для решения своих задач и достижения своих целей. Как утюг — если тебе нужно что-то погладить, ты его включаешь. Если он будет вместо того, чтобы гладить, модально предлагать скачать обновления из интернета, понятно, куда такой утюг полетит. Алан Купер [1] рекомендует представлять пользователей вашего продукта как очень умных, но очень занятых людей. Они, мол, не тупые и поймут, как вашим продуктом пользоваться, главное, вы только не вставайте у них на пути.
Я вообще считаю, что каждому программисту (дизайнеру, менеджеру, аналитику) следует проделать медитацию, упомянутую Сергеем Бодровым-мл.:
Ты становишься на углу оживленной улицы и представляешь, что тебя здесь нет. Вернее, тебя нет вообще. Пешеходы идут, сигналят машины, открываются двери магазинов, сменяются пассажиры на остановке. То есть в принципе мир продолжает жить и без тебя. Понимать это больно. Но важно.
Я, конечно, вовсе не хочу сказать, что программист — профессия ненужная, я сам программист и совсем так не считаю. Просто это неблагодарная профессия. Никто не придет и не похвалит за хорошо реализованный алгоритм. Если программа хороша, ей будут пользоваться без дополнительных вопросов. Так и должно быть, просто, чтобы быть программистом, надо к этому привыкнуть. А эти вот люди, которые идут по улице и сменяются на остановке — это ваши пользователи. Они используют вещи так, как они им нужны. В том числе и ваш продукт. Без вас. Они ничего о вас не знают, не хотят знать и никогда не узнают. Сергею Витальевичу, когда он в полярной тундре пытается вбить в систему снятые со счетчика показания, совершенно не интересно, почему система говорит ему, что сперва требуется указать какой-то там тип тарификации, даже если в момент проектирования вам казалось, что без типа тарификации ну уж никак не обойтись. А что касается примера про утюг, скачивающий обновления, то он взят совсем не из пальца — обратите внимание, как ведет себя при включении браузер Файерфокс.
Тут вообще будет что-нибудь про обязательные поля, спросит хабраюзер? Как раз сейчас начнется.
Штука в том, что реальный наш мир — это не математическая модель, параметры которой известны в любой момент времени. Для реальной жизни характерна скорее нехватка информации, чем ее наличие. У человека, заполняющего форму, требуемых данных может не быть — и не быть их может во всех обозримых пределах досягаемости, то есть не быть ваще. Эту проблему нельзя решить, просто сделав поле обязательным — значение из воздуха не возьмется. Вводя на формах обязательные поля в угоду целостности и полноте данных, мы на самом деле мешаем пользоваться системой. Столкнувшись с такой ситуацией, пользователь либо не станет заполнять форму (и не сможет работать с системой вовсе), либо заполнит недостающие данные рыбой — выдуманными или бессмысленными данными. И это свидетельствует не о том, что пользователь плохой или плохо старался, а лишь о том, что разработанная система недостаточно гибка для использования в условиях реального мира. То, что произошло во втором случае (ввод рыбы) — это вообще обман. Разработчик системы может сколько угодно делать вид, что все в порядке, но на самом деле в этом обмане виноват именно он. Причем непонятно, кто и что вообще выиграл — пользователь поимел головную боль, а в систему попали некорректные данные. Да попали так, что обнаружить, отфильтровать или подчистить их автоматически уже невозможно — в отличие от случая, если бы пользователь просто указал, что информация отсутствует.
Что же делать? Делать нужно хорошие программы. А именно, да, таки не ставить целостность схемы БД во главу угла, а ставить туда цели и задачи пользователей. Другими словами, принимать у пользователя неполные, а в некоторых случаях и некорректные данные, естественно, с возможностью исправить их в будущем. Вопреки заблуждению (да, еще одному) это возможно, это не так сложно и это даже работает. Кроме этого, нужно еще каким-то образом помогать, подсказывать пользователю, где, каких данных и для чего ему не хватает. Чтобы он видел и контролировал ситуацию.
Сколько обязательных полей должно быть на форме? В идеале, ноль. Всегда ли такое возможно? Для меня одним из примеров высшего пилотажа является операция создания папки в Виндоус. Казалось бы, уж меньше одного поля тут не сделаешь, однако нет, они умудрились реализовать создание так, что система не спрашивает ничего — даже несмотря на то, что технические ограничения не позволяют системе создать папку без имени. Это идеал, к которому нужно стремиться.
Естественно, система должна быть минимально умной, спрашивая у пользователя только то, что имеет отношение к задачам пользователя, а не к потребностям самой системы. Система как инструмент, помните? Как раз про пример с Файерфоксом — Гугл Хром, например, решил проблему Файерфокса, обновляясь тихонько в тот момент, когда пользователь его перезагружает. Пользователю об этом знать совсем не нужно — он и не знает. Достойный пример для подражания. Я, признаться, даже сперва не понял, чегой-то он меня ни разу не спрашивал, когда ему обновляться?
Еще был миф о важных полях (это те, которые необязательны, но желательны к заполнению). Здесь все еще проще — принудительно заставить заполнить поле нельзя. Следовательно, хоть помечай поле как обязательное, хоть не помечай — все равно напишут рыбу, чушь, отписку, если не захотят заполнять. Интерфейсного решения у этой проблемы нет. Важность полей нужно доносить до сотрудников на местах. А разработчику пометить поле как необязательное. И позволить редактировать.
UPD: В комментариях trijin и zhindetz понятнее сформулировали основную мораль топика: речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво. То есть да, делать необязательными даже те поля, без которых система не будет работать. Естественно, она и не будет работать, но пусть хотя бы данные похранит.
UPD #2: Уточню еще одну вещь, которую я сам не осозновал ясно, когда писал топик. Я не обсуждаю здесь вопросов уместности тех или иных полей на форме (это важная, но все-таки немного другая тема, чем та, которую мне хочется донести). Я скорее предлагаю переосмыслить саму концепцию ввода информации с помощью форм, тот традиционный подход, когда нужно заполнить всю форму сразу и корректно. Вместо этого я предлагаю промежуточное состояние (неполное, некорректное, противоречивое) тоже позволять сохранять в БД, явным образом помечая такое состояние как неполное/некорректное/противоречивое. Таким образом все ситуации «я сейчас знаю не все, но завтра, может быть, узнаю», которые традиционно решаются записыванием на бумажку, можно обрабатывать с помощью информационной системы. Естественно, такие данные не нужно пускать в бизнес-процесс в силу их некорректности — тут все остается как раньше. Они просто полежат в БД до лучших времен — не пригодятся, ну и бог с ними.
Как добавить пользователя в 1С: пошаговая инструкция по созданию новой учетной записи в программе
Системы учета, используемые на предприятиях, как правило, обеспечивают возможность одновременной или последовательной работы сразу нескольких сотрудников. Ввиду того что каждый из них выполняет собственные функциональные задачи и вносит определенные изменения в существующую базу, одним из обязательных требований становится персональная идентификация. С этой целью для всех лиц, имеющих допуск к программному обеспечению, создается личный профиль, защищенный от стороннего использования логином и паролем. Пользователи 1С наделяются перечнем прав, соответствующих статусу их учетной записи, а также получают доступ к отдельной форме интерфейса, ограниченной только необходимыми им функциями. При этом первый аккаунт, зарегистрированный в системе, по умолчанию обладает полномочиями на администрирование.
В ситуациях, когда штат организации пополняется новым сотрудником, возникает необходимость внесения его в список субъектов, которые могут пользоваться программой. Как именно это сделать, чтобы не допустить ошибок и применить корректные настройки? Давайте разбираться.
Как добавлять пользователей в 1С
Рассматриваемая учетная платформа предлагает два способа решения поставленной задачи — в пользовательском режиме, а также через функции Конфигуратора. В первом случае используются базовый перечень предопределенных ролей, изначально определяющих возможности и интерфейс для каждого статуса, что заметно упрощает процесс. Второй вариант отличается более гибкими инструментами для настройки полномочий. При этом выбор между указанными методиками, как правило, зависит от двух факторов: навыков администратора и распоряжений руководящего состава.
Как завести нового пользователя в «1С: Предприятие»
Алгоритм, реализованный в рамках базового функционала системы, позволяет вносить необходимые корректировки в онлайн-режиме, без выхода из программы. Порядок действий выглядит следующим образом:
Завершающий этап — определение профиля, от которого зависит перечень функциональных возможностей, доступных новому сотруднику. Отметьте соответствующий должностной роли пункт и сохраните карточку.
Добавление с помощью Конфигуратора
Учетные записи пользователей 1С также можно создавать и редактировать через вспомогательный режим, предусмотренный для специалистов технической группы или IT-отдела. В данном случае речь идет о более точных и тонких настройках, расширяющих или сужающих спектр полномочий и степень доступа к системе. Алгоритм выполнения задачи предусматривает следующую цепочку действий, позволяющих оперативно внести необходимые корректировки:
Перед тем как изменить или добавить нового пользователя в 1C 8 («1С: Предприятие», «Управление торговлей» и т.д.), нужно установить в Конфигураторе его личные данные — как и в предыдущем случае, указываются входное и полное имя, метод аутентификации, а также пароль для авторизации.
Отдельного внимания заслуживает профильная настройка. Перейдите к разделу «Прочие», где отражается перечень базовых ролей, которые можно присвоить. В ситуациях, когда точечная активация или отключение отдельных опций не требуются, достаточно ограничиться установкой Полных, а также в случае необходимости, Администраторских прав.
В целом, весь функционал при работе с базой определяется на усмотрение руководства, определяющего перечень требований и критериев. Важно учесть, что, при недостаточности тех или иных полномочий, субъект будет вынужден сталкиваться с периодическими уведомлениями об ошибках. В связи с этим рекомендуется уделить внимание изучению статуса нового сотрудника и положенных ему по умолчанию (и по распоряжению ответственного руководителя) прав, чтобы не замедлять цикл реализации рабочих бизнес-процессов.
Как оформляются дополнительные пользователи в 1С Бухгалтерия 8.3
Настройка пользовательских возможностей исключает вероятность несанкционированной корректировки учетной информации, а также позволяет сосредоточить внимание абонента на конкретных задачах, реализуемых через доступные ему функции интерфейса. Однако перед тем, как раздать полномочия, нужно включить в базу всех активных участников.
Процесс добавления в программу
В теории функционал системы допускает работу без назначения определенного клиента. Однако есть ряд регламентированных операций, реализация которых возможна только при наличии у исполнителя полных правомочий.
Перед началом процедуры следует понять, кто из субъектов, присутствующих в БД, и каким именно статусом должен быть наделен, поскольку перечень варьируется от администрирования до точечных ограничений. Как правило, настройка прав доступа пользователей в 1С начинается с сотрудников, которым планируется предоставление самого широкого спектра функций.
Хранение и изменение информации
Пользовательские данные о каждом действующем абоненте находятся в соответствующем разделе. Встроенные фильтры позволяют также включить в реестр весь бывший персонал, имеющий на момент просмотра «Недействительный» статус. Для корректировки информационной карточки достаточно дважды кликнуть по имени. Чтобы ограничить возможность использования программы на неопределенный срок, следует убрать маркер с пункта, подтверждающего разрешение.
Изменение полномочий не требует обязательного раскрытия полных данных работника. Выделите нужную позицию и используйте кнопку «Права доступа».
Создание учетной записи и добавление к базе 1C нового пользователя в Конфигураторе «1С: Предприятие» предусматривает опцию дублирования на основе уже существующего субъекта. При копировании можно обойтись изменением ключевых значений формы, то есть имени, логина и пароля, тогда как остальные позиции не требуют обязательного обновления.
Зачем нужна профильная настройка
Конечно, в теории намного проще использовать единый аккаунт, обладающий полным функциональным спектром и свободным доступом к интерфейсу. Однако практика показывает, что подобный подход, как правило, оборачивается проблемами, разобраться с которыми организации бывает не так просто.
Так, к примеру, неосторожное обращение с базой может стать причиной повреждения системных данных, восстановление которых требует времени и денег. Однако определить ответственного в ситуации, когда фактическая возможность была у всех, крайне проблематично. Концепция разделения полномочий не только позволяет отслеживать, кто и когда конкретно вносил те или иные изменения, но и предотвращает нежелательное взаимодействие между персоналом, не имеющим достаточную подготовку, и областями учета, требующими особого внимания и аккуратности.
Роли и права доступа
Как уже было сказано, перед тем, как создать учетную запись пользователя и добавить в 1с 8 3 («1C:Бухгалтерия», «УТ», «Розница» и т.д.), нужно определиться с тем, каким статусом наделяется новый сотрудник. В рассматриваемой системе имеется несколько шаблонных вариантов, заметно облегчающих настройку работы в организациях с расширенным штатом:
Отчет по имеющимся локальным ограничениям доступа формируется в разделе настройки, и отражает сведения по выбранному абоненту.
Группа пользователей
Еще одна опция, предусматриваемая функционалом платформы — групповое распределение прав и применение ограничений. В данном случае следует проанализировать перечень критериев, на основе которых сотрудники могут быть объединены в отдельные категории (бухгалтера, маркетологи, категорийные менеджеры и т.д.).
После этого достаточно перейти в меню «Администрирование» и отметить маркером пункт о запрете доступа на уровне записей. С помощью надстройки вы можете гибко изменять возможности получения данных из справочников, а также взаимодействия с иными программными элементами.
Профили групп настраиваются с помощью соответствующей гиперссылки. При этом один абонент может принадлежать сразу к нескольким категориям, и, как следствие, получать максимум полномочий от каждой из них. Перечень прав указывается на вкладке с описанием, и может включать в себя как чтение и просмотр, так и редактирование отдельных видов документов в учетной системе.
После создания нужного кластера выберите опцию «Записать и закрыть», чтобы подтвердить операцию.
Ограничения на уровне записей
Эта надстройка, уже упомянутая в предыдущем пункте, позволяет оперативно управлять групповыми и персональными полномочиями. Разберем ее более подробно.
К примеру, у вас возник производственный вопрос — как в 1С поменять статус пользователя, относящегося к кластеру «Менеджеры по закупкам», выставив ему определенные запреты на взаимодействие с программой. В данном случае алгоритм будет следующим:
Обязательные поля при регистрации
Разрабатывая интерфейс для очередного сайта, основной аудиторией которого будут люди не очень продвинутые технически, я задумался над вопросом об обязательных для регистрации полях и минимизации их количества.
В голову пришли следующие варианты:
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
— А ведь есть вариант, где полей меньше в четыре раза.
Ну и как дополнительное поле идет неизбежная капча, либо ее аналог.
Некоторые специалисты по юзабилити рассматривали вариант открытого ввода пароля, либо перевод режима его ввода в закрытый режим с подтверждением по активации чекбокса, но мне это кажется экзотикой.
Быть может, есть какие-то оригинальные решения проблемы минимизации количества полей при регистрации и я буду очень признателен, если вы ими поделитесь.
Обязательные поля в формах — отмечать или нет?
Популярный вопрос, часто задаваемый на наших занятиях UX Conference: следует ли отмечать обязательные поля в форме? Как быть, если большинство полей в форме являются обязательными, следует ли их все отметить? (Это же так много отметок, в конце концов.) Короткий ответ — да. И в этой статье я дам объяснение, почему.
Искушение не отмечать обязательные поля
Часто дизайнеры чувствуют, что наличие отметки для каждого отдельного элемента — уродливое повторение, которое занимает слишком много места и, с более длинными формами, даже может выглядеть угнетающе (форма требует от пользователя очень много!). Таким образом, они обычно принимают одну или обе из следующих стратегий:
1. Они дают инструкцию в верхней части формы, говоря, что все поля обязательны для заполнения или все поля обязательны для заполнения, если не указано иное.
2. Они отмечают необязательные поля, так как их обычно меньше.
(В некоторых редких ситуациях они вообще ничего не делают: они просто полагают, что пользователи сами волшебным образом догадаются, какие поля обязательны. Ну а если они этого не сделают, им просто придется иметь дело с возникающей ошибкой.)
Что не так с этими подходами? Тут есть несколько проблем:
• Люди не читают инструкции в верхней части формы.
Это общеизвестный факт, что пользователи не читают инструкции, и наименее вероятнее всего они станут читать инструкции в верхней части формы. В конце концов, поля формы выглядят самодостаточно, каждое поле имеет собственную специфическую «инструкцию» — своё название, зачем вам нужно читать что-то еще, чтобы заполнять поля формы?
Вы можете подумать: если пользователи прочитают инструкцию перед заполнением формы, они не смогут ее забыть — это же так просто? Однако, они забывают — особенно если форма длинная или если они прерываются при заполнении (ситуация, которая часто встречается на мобильных устройствах). И даже если люди не забывают инструкции, вы увеличиваете их когнитивную нагрузку, заставляя хранить прочитанное в своей рабочей памяти. Другими словами, вы усложняете им задачу. Заполнение формы само по себе вызов для ваших пользователей — зачем вы хотите усложнить этот процесс?
Мы выяснили, что независимо от того, предоставили вы инструкции пользователю в шапке формы или нет, результат, скорее всего, будет одинаковым: их будут игнорировать или забывать. Итак, что происходит, когда пользователь заполняет форму? Как они понимают, что поле обязательно для заполнения? Наиболее прилежные пользователи будут присматриваться внимательно, пытаясь выяснить это — они просмотрят всю форму и найдут поле, отмеченное как необязательное (иногда для этого необходимо проскроллить страницу, как в примере с AmericanExpressвыше, где первое необязательное поле появляется ниже, за пределами экрана; если они найдут одно такое поле, они будут считать, что все не отмеченные поля — обязательные. Но это взаимодействие потребует времени и усилий — и опять же, зачем вам усложнять для пользователей заполнение формы?
Однако большинство пользователей не будут осматриваться по сторонам — они просто будут строить предположения. Они скажут: «Ну, номер телефона — им же реально не нужен мой номер телефона, не так ли? Оставлю это поле пустым». И даже если они не оставляют это поле пустым, необходимость сделать паузу, чтобы принять решение, нужно ли заполнять поле, замедляет взаимодействие и делает процесс более долгим и утомительным. (Помните, как бы вам ни хотелось думать иначе, никто не хочет заполнять форму — ни на маленьком, ни на большом экране.) Результатом будет ошибка отправки формы, которая будет означать еще больше потраченного времени на решение этой задачи.
Решение простое: отметьте все обязательные поля. Будьте настолько очевидными и прозрачными, насколько это возможно: для каждого обязательного поля, которое необходимо заполнить, поставьте отметку.
Как пометить обязательные поля?
Здесь есть как минимум два варианта: звездочка (красная или нет) и слово «обязательно».
Должна ли звездочка предшествовать или следовать за названием поля? Вряд ли это будет иметь практическое значение, но одна из причин, по которой его нужно поместить непосредственно перед описанием поля, состоит в том, чтобы помочь глазам легко распознать, какие поля требуются, просмотрев только самый первый символ названия полей.
Должна ли звездочка быть красной? Необязательно, но красный цвет стал ожидаемым требуемым цветом маркера в web, что само по себе является причиной для того, чтобы придерживаться этого выбора (согласно Jakob’s Law). В любом случае, есть некоторая ценность использования разных цветов для звездочки и для текстового названия поля: это позволяет пользователям быстро отделить их и сфокусироваться на названии поля, пытаясь осмыслить, что означает это поле. В то время как красный предпочтителен, мы настоятельно рекомендуем избегать бледно-серых или низко контрастных цветов для звездочки. В некоторых случаях приглушенные цвета могут иметь эстетические преимущества, но в реальности низко контрастные символы создадут проблемы доступности для слабовидящих или пожилых пользователей и замедляют визуальную обработку формы для всех.
Можно ли отмечать необязательные поля?
Хотя это и не обязательно, отметка опциональных полей снижает когнитивную нагрузку пользователя: при отсутствии этого обозначения пользователь должен осмотреть поля и сделать вывод, какие именно из них являются необязательными, если часть из них помечена как обязательные. Если слово «необязательно/опционально» находится рядом с названием поля, эта задача становится немного легче.
Не указать, что поле является необязательным, не является ошибкой, но, если его также отметить — это будет очевидным плюсом.
Как насчет форм авторизации?
Формы авторизации короткие и обычно состоят из двух полей: имени пользователя и пароля, оба из которых всегда обязательны для заполнения. Если вы используете звездочку, возможно необходимость пометки этих полей будет минимальной, однако это не будет ошибкой. Тем не менее, большинство пользователей сталкиваются со множеством форм авторизации, и они знают, что для входа в систему обязательно нужно ввести адрес электронной почты или имя пользователя и пароль. Так что, если вы категорически против звездочки, то можно совсем отказаться от неё в этих формах.
Однако опасно не отмечать обязательные поля в форме регистрации. Формы регистрации сильно различаются на разных сайтах — разные компании требуют разные типы информации при создании учетной записи. Если ваша регистрационная форма похожа на форму входа в систему, то можно безопасно пропустить необходимую информацию. Но если оно включает в себя больше полей, чем имя пользователя и пароль, отметьте все обязательные поля (включая поля имени пользователя и пароля).
Заключение
Формы — отнюдь не забава. Они требуют от пользователей достаточно работы. В реальности, многие формы оказываются брошенными, потому что заполнять их слишком сложно или утомительно. Чтобы повысить шансы того, что ваша форма будет до конца заполнена, минимизируйте усилия, которые придется приложить пользователям, и информацию, которую они должны запомнить. Есть много аспектов, которые способствуют этому, но отметить обязательные поля (и, опционально поля необязательные) — легкое и простое решение.