Никита Прокопов tonsky

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

Да, все правильно. За одним исключением — речь о большинстве полей из тех, что маппятся 1:1 в пользовательский интерфейс. В схеме БД еще много всяких чисто технических полей, которых не видно в интерфейсе, и их целостность обычно на уровне БД обеспечивается.

Средства по контролю целостности БД используем. Там, где поле на форме соответствует 1:1 полю в БД, иногда это ограничение заносится в схему, иногда нет, зависит от. Проверка обязательности на уровне приложения есть в обоих случаях.

ну да, сделаем все поля обязательными и они их сразу все и правильно заполнят. Вы сами-то в это верите?

Ну да, не определяется. Ведь поле, обязательное для одного бизнес-процесса, может быть (и часто является) необязательным для другого. И на всякий случай повторю, что мы не доводим ничего до абсурда. Обязательные поля в схеме БД есть, и их обязательность определяется многими факторами, в т.ч. и бизнес-процессами. Но мы стараемся такие места минимизировать. Объемы — 10⁵—10⁶ учетных единиц.

Да, я там в UPD #2 уточнял потом, что именно я пытался сказать. Там речь не о вообще любых формах, а о формах ввода/редактирования/сбора информации в системе. Не могу подобрать термина адекватного, но суть в том, что логин — это немного другое, это форма запуска действия, а не сбора (что бы это ни значило) информации.

К каптче отношусь плохо, это как раз тот случай, когда часть работы (отсеивать ботов) программист переложил на пользователя. С другой стороны, при логине еще терпимо, логинимся мы редко; слава богу, что она не выскакивает при каждом комментарии.

В модели данных документируются обязательные для схемы данных поля. Обязательность поля для бизнес-процесса документируется в описании бизнес-процесса, потому как только там и используется.

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

То есть таки только те избранные, кому выпала честь пользоваться вашей чистейшей программой, достойны… Подумайте на секунду не о себе. Представьте себе врача, который посылает больных лесом, потому что они «неправильно заболели». Представьте себе архитектора, который сделал дверные проемы высотой в 1,5 метра, потому что «так композиция обретает красоту», и проход в из комнаты в кухню через ванную комнату, потому что сам он любит поесть, когда моется. Что было бы, а?

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

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

Вы тут смешали немного. Зависит от того, кому заполнение этой анкеты нужно.

1. Если пользователю, то он и придет, и дозаполнит, и зарегистрируется ради такого дела. Единственное, что надо делать, это моргнуть, мол, помни, ты не все заполнил!
2. Если организации, проводящей опрос, то она должна сделать заполнение максимально простым. Меня лично в формах соцопроса больше всего раздражает (ну, может, после случая, когда спрашивают адрес и телефон), когда вопросов много и надо обязательно ответить на все. Сколько людей бросает заполнять такую, заполнив половину, хотя могли бы хотя бы эту половину отослать? То есть, опять же, все вопросы сделать необязательными.

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

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

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

Ну это не в модели данных документируется, к счастью, иначе действительно было бы потом не разобрать, что зачем.

Вы правда видите разницу между

«Пришел — проверили, отправили дозаполнять — исправил, вернулся — проверили, приняли, сказали жди паспорт»

и

«Пришел — проверили, приняли часть и отправили дозаполнять недостающее — исправил, вернулся — проверили, приняли, сказали жди паспорт»?

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

В вашем случае за экспедитором никто не пошлет, пока накладная не будет заполнена полностью. А вот заполнить ее можно будет или сразу целиком, или по частям, в разное время (но обязательно до запуска бизнес-процесса).

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

Это и сейчас так работает, тут я ничего менять не предлагаю. Единственное, что уже принесенные документы не проваляются на полке, а будут частично занесены в базу, пока Петров ходит.

«продукт с обязательными полями и без таковых» — это именно все или ничего.

Я имел в виду, что чем меньше обязательных полей, тем лучше, не обязательно их количество строго до нуля доводить, удобство использования растет плавно с уменьшением количества обязательных полей.

не, ну их количество же до нуля относительно гладко опускается.

Регистрацию в бложике я вообще не имел в виду, заметьте, вопросы важности и уместности тех или иных полей я не обсуждаю вовсе. Хотя, судя по комментариям, не вы один меня неправильно поняли — моя вина, наверное, я что-то недостаточно ясно изложил. Мои идеи скорее о переосмыслении самого концепта ввода данных с помощью форм, когда нужно ввести либо все сразу и правильно, либо ничего — вводить вместо этого в несколько этапов, частями, только то, что есть сейчас, корректировать при последующем вводе и т.п.

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

Так бы и делали — сначала давали скачать, а потом уже (пока скачивается) желающих форму заполнить опрашивали. На Vimeo.com похожим образом сделано — пока ты закачиваешь им видеофайл, тебе предлагают заполнить информацию всякую о нем. Я с удовольствием заполняю, все равно ждать.

Тут ведь нет такой альтернативы — либо все, либо ничего. Моя оценка основана на опыте адаптации существующих интерфейсов, в предыдущей компании и вот в текущей (системы класса АСУ ТП и АСУП соотв.). Собственно, сам топик — из наболевшего возник. В большинстве случаев мы обходимся малыми трудозатами, туда, где все сильно переплетено, пока не лезем, что не мешает получать более чем удовлетворительный результат в большинстве случаев.

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

Я, действительно, не разбираюсь, но два вопроса все же от дилетанта:
1. Если поле обязательное, а данных — нет?
2. Степень строгости проступка — разве не начальством определяется? И что мешает так же наказывать за незаполнение поля?

Тут ниже trijin и zhindetz понятнее сформулировали мысль — речь о системе черновиков, о снятии требования ввести все данные сразу и непротиворечиво.

Про модели — в информационных системах появляется еще один фактор, несвойственный реальности как таковой — доступность информации в данный конкретный момент. Т.е. в мире у человека есть паспорт и у этого паспорта есть номер, просто речь о том, что в данный конкретный момент мы его не знаем. В этом отличие.

Необходимости обязательных полей для выполнения системой функций я не отрицаю не в коем случае. Я о требовании ввести все данные обязательно полностью и за раз — его надо убирать.

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

Слушайте, ну насчет стоимости, в 1,5 раза — это как-то чересчур. Речь о небольших, причем зачастую — психологических изменениях.

И вы натолкнули меня еще на одну мысль — ведь на самом деле, предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design.

Вот! Это я и пытался донести. Попробуйте встать на позицию пользователя, пожалеть его, помочь ему. Поверьте, они вам отплатят, косвенно, через успех вашего продукта. Программировать не так уж и сложно, генерировать идентификаторы — тем более.

А вы им говорите, что оно обязательное. Я как раз об этом писал в заблуждении №3, по-моему, делать поле обязательным — это не выход. Разве что считать, что женщины системы боятся больше, чем начальника, и их пугает сообщение о незаполненном поле. Сделаете вы поле обязательным, но ничто не помешает им вбивать туда пробел, точку или еще какую отписку.

Про ошибки согласен, просто я несколько раз сталкивался со мнением, что нехватка информации — это ошибка. Что мягко говоря странно.

Представьте себе, например, систему паспортного стола, в ней форма добавления человека и документов, и все поля — необязательные: фамилия, имя, отчество (особенно), дата рождения, номера паспорта, кем выдано и т.п.

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

Понял, о чем вы. Второй случай — это когда из-за нехватки информации нельзя выполнить какое-то действие. Тут ничего не поделаешь, действительно, нельзя.

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

да я же не FF поругать, просто пример показательный — одна функция и два подхода к реализации.