| Меню сайта |
|
 |
| Категории раздела |
|
|
| Мини-чат |
|
|
|
| Наш опрос |
|
|
| Статистика |
Онлайн всего: 5 Гостей: 5 Пользователей: 0 |
|
| Форма входа |
|
|
|
 |  |  |  |
 | Главная » 2009 » Октябрь » 20 » Миф об обязательном поле
03:54 Миф об обязательном поле |
Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);В мире разработки программных продуктов бытует немало мифов и заблуждений. Чтобы двигаться вперед, а не топтаться на месте, их совершенно необходимо разрушить. Сегодня об одном из самых закоренелых заблуждений, которое к тому же достаточно вредное — называется «Миф об обязательном поле».
Речь пойдет о практически любых системах, использующих для ввода информации формы. Обязательное поле — это поле формы, без заполнения которого система не примет у вас информацию. Среди подавляющего большинства разработчиков ПО бытует мнение, что обязательными полями должны быть:
Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);
Все необходимые для функционирования системы поля (те, без которых не будут работать алгоритмы — например, дата, с которой начинается предоставление услуг, чтобы делать по ним начисления);
Важные поля — такие, которые не необходимо, но желательно заполнить (например, обоснование вносимого изменения) — с той мотивацией, что пусть лучше пользователь попотеет, когда не нужно, чем забудет ввести значение, когда будет нужно.
Как видите, тут целый комплекс мифов, развеивать которые нужно скрупулезно и планомерно. Поэтому начнем с двух других заблуждений.
Традиционно программисты считают, что делают одолжение всему остальному миру, создавая для них такой замечательный продукт, как «подставьте любое название продукта». Их программа — это чуть ли не платоновский эйдос, чистейшая абстракция, математическая формула, вычислимая, естественно, строго на наборе параметров из своей области определения. С этой точки зрения обязательные поля — та досадная мелочь, которую приходится вставлять, чтобы обучить глупых и неотесанных пользователей, как правильно вводить информацию в систему, с которой они получили честь работать.
Считается также, что некорректные (неполные) данные настолько страшны, что даже хранить их в базе данных уже некорректно. Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Что на это имеет сказать современная наука проектирования взаимодействия с пользователем? Во-первых, стало ясно (уж не знаю, кому и когда, но достаточно давно точно, см. [1] и [2]), что все-таки программы разрабатываются для пользователей. В этом смысле программист уже не диктует условия, а скромно создает сугубо утилитарный продукт, инструмент, которым будут пользоваться люди для решения своих задач и достижения своих целей. Как утюг — если тебе нужно что-то погладить, ты его включаешь. Если он будет вместо того, чтобы гладить, модально предлагать скачать обновления из интернета, понятно, куда такой утюг полетит. Алан Купер [1] рекомендует представлять пользователей вашего продукта как очень умных, но очень занятых людей. Они, мол, не тупые и поймут, как вашим продуктом пользоваться, главное, вы только не вставайте у них на пути.
Я вообще считаю, что каждому программисту (дизайнеру, менеджеру, аналитику) следует проделать медитацию, упомянутую Сергеем Бодровым-мл.:
Ты становишься на углу оживленной улицы и представляешь, что тебя здесь нет. Вернее, тебя нет вообще. Пешеходы идут, сигналят машины, открываются двери магазинов, сменяются пассажиры на остановке. То есть в принципе мир продолжает жить и без тебя. Понимать это больно. Но важно...Я, конечно, вовсе не хочу сказать, что программист — профессия ненужная, я сам программист и совсем так не считаю. Просто это неблагодарная профессия. Никто не придет и не похвалит за хорошо реализованный алгоритм. Если программа хороша, ей будут пользоваться без дополнительных вопросов. Так и должно быть, просто, чтобы быть программистом, надо к этому привыкнуть. А эти вот люди, которые идут по улице и сменяются на остановке — это ваши пользователи. Они используют вещи так, как они им нужны. В том числе и ваш продукт. Без вас. Они ничего о вас не знают, не хотят знать и никогда не узнают. Сергею Витальевичу, когда он в полярной тундре пытается вбить в систему снятые со счетчика показания, совершенно не интересно, почему система говорит ему, что сперва требуется указать какой-то там тип тарификации, даже если в момент проектирования вам казалось, что без типа тарификации ну уж никак не обойтись. А что касается примера про утюг, скачивающий обновления, то он взят совсем не из пальца — обратите внимание, как ведет себя при включении браузер Файерфокс.
Тут вообще будет что-нибудь про обязательные поля, спросит читатель? Как раз сейчас начнется.
Штука в том, что реальный наш мир — это не математическая модель, параметры которой известны в любой момент времени. Для реальной жизни характерна скорее нехватка информации, чем ее наличие. У человека, заполняющего форму, требуемых данных может не быть — и не быть их может во всех обозримых пределах досягаемости, то есть не быть ваще. Эту проблему нельзя решить, просто сделав поле обязательным — значение из воздуха не возьмется. Вводя на формах обязательные поля в угоду целостности и полноте данных, мы на самом деле мешаем пользоваться системой. Столкнувшись с такой ситуацией, пользователь либо не станет заполнять форму (и не сможет работать с системой вовсе), либо заполнит недостающие данные рыбой — выдуманными или бессмысленными данными. И это свидетельствует не о том, что пользователь плохой или плохо старался, а лишь о том, что разработанная система недостаточно гибка для использования в условиях реального мира. То, что произошло во втором случае (ввод рыбы) — это вообще обман. Разработчик системы может сколько угодно делать вид, что все в порядке, но на самом деле в этом обмане виноват именно он. Причем непонятно, кто и что вообще выиграл — пользователь поимел головную боль, а в систему попали некорректные данные. Да попали так, что обнаружить, отфильтровать или подчистить их автоматически уже невозможно — в отличие от случая, если бы пользователь просто указал, что информация отсутствует.
Что же делать? Делать нужно хорошие программы. А именно, да, таки не ставить целостность схемы БД во главу угла, а ставить туда цели и задачи пользователей. Другими словами, принимать у пользователя неполные, а в некоторых случаях и некорректные данные, естественно, с возможностью исправить их в будущем. Вопреки заблуждению (да, еще одному) это возможно, это не так сложно и это даже работает. Кроме этого, нужно еще каким-то образом помогать, подсказывать пользователю, где, каких данных и для чего ему не хватает. Чтобы он видел и контролировал ситуацию.
Сколько обязательных полей должно быть на форме? В идеале, ноль. Всегда ли такое возможно? Для меня одним из примеров высшего пилотажа является операция создания папки в Виндоус. Казалось бы, уж меньше одного поля тут не сделаешь, однако нет, они умудрились реализовать создание так, что система не спрашивает ничего — даже несмотря на то, что технические ограничения не позволяют системе создать папку без имени. Это идеал, к которому нужно стремиться.
Естественно, система должна быть минимально умной, спрашивая у пользователя только то, что имеет отношение к задачам пользователя, а не к потребностям самой системы. Система как инструмент, помните? Как раз про пример с Файерфоксом — Гугл Хром, например, решил проблему Файерфокса, обновляясь тихонько в тот момент, когда пользователь его перезагружает. Пользователю об этом знать совсем не нужно — он и не знает. Достойный пример для подражания. Я, признаться, даже сперва не понял, чегой-то он меня ни разу не спрашивал, когда ему обновляться?
Еще был миф о важных полях (это те, которые необязательны, но желательны к заполнению). Здесь все еще проще — принудительно заставить заполнить поле нельзя. Следовательно, хоть помечай поле как обязательное, хоть не помечай — все равно напишут рыбу, чушь, отписку, если не захотят заполнять. Интерфейсного решения у этой проблемы нет. Важность полей нужно доносить до сотрудников на местах. А разработчику пометить поле как необязательное. И позволить редактировать.
Литература:
Алан Купер об интерфейсе. Основы проектирования взаимодействия. Символ-Плюс, 2009 г.
Джеф Раскин. Интерфейс: новые направления в проектировании компьютерных систем. Символ-Плюс, 2005 г.
Дополнение 1: В комментариях на хабрахабре понятнее сформулировали основную мораль поста: речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво. То есть да, делать необязательными даже те поля, без которых система не будет работать. Естественно, она и не будет работать, но пусть хотя бы данные похранит.
Дополнение 2: Уточню еще одну вещь, которую я сам не осозновал ясно, когда писал пост. Я не обсуждаю здесь вопросов уместности тех или иных полей на форме (это важная, но все-таки немного другая тема, чем та, которую мне хочется донести). Я скорее предлагаю переосмыслить саму концепцию ввода информации с помощью форм, тот традиционный подход, когда нужно заполнить всю форму сразу и корректно. Вместо этого я предлагаю промежуточное состояние (неполное, некорректное, противоречивое) тоже позволять сохранять в БД, явным образом помечая такое состояние как неполное/некорректное/про>тиворечивое. Таким образом все ситуации «я сейчас знаю не все, но завтра, может быть, узнаю», которые традиционно решаются записыванием на бумажку, можно обрабатывать с помощью информационной системы. Естественно, такие данные не нужно пускать в бизнес-процесс в силу их некорректности — тут все остается как раньше. Они просто полежат в БД до лучших времен — не пригодятся, ну и бог с ними.
Предыдущий пост почти на эту же тему
|
|
Категория: Новости |
Просмотров: 472 |
Добавил: andest
| Рейтинг: 0.0/0 |
|  |
 |  |
 |  |  |  |
|
| Поиск |
|
|
| Календарь |
|
|
| Архив записей |
|
|
|
