очень легко представить как удобную и простую абсолютно незащищенную систему, так и неудобную и сложную, но тоже незащищенную систему. Не так что-то с этой пропорциональностью, видимо.
Нет, вы путаете. Я не предлагаю запускать бизнес-процессы в условиях нехватки данных. Я предлагаю лишь возможность вносить эти данные в несколько присестов (прочитайте upd #2 к посту, я там пояснил).
В вашем случае за экспедитором никто не пошлет, пока накладная не будет заполнена полностью. А вот заполнить ее можно будет или сразу целиком, или по частям, в разное время (но обязательно до запуска бизнес-процесса).
Нееет. Петров принес документы, не все, ок, мы их приняли и сказали Петрову, чтобы приносил остальные. Пока он ходил, мы внесли то, что есть. Когда он принесет остальные, и мы ему скажем, что всё, более ничего не нужно, Петров может идти гулять спокойно.
Это и сейчас так работает, тут я ничего менять не предлагаю. Единственное, что уже принесенные документы не проваляются на полке, а будут частично занесены в базу, пока Петров ходит.
«продукт с обязательными полями и без таковых» — это именно все или ничего.
Я имел в виду, что чем меньше обязательных полей, тем лучше, не обязательно их количество строго до нуля доводить, удобство использования растет плавно с уменьшением количества обязательных полей.
Регистрацию в бложике я вообще не имел в виду, заметьте, вопросы важности и уместности тех или иных полей я не обсуждаю вовсе. Хотя, судя по комментариям, не вы один меня неправильно поняли — моя вина, наверное, я что-то недостаточно ясно изложил. Мои идеи скорее о переосмыслении самого концепта ввода данных с помощью форм, когда нужно ввести либо все сразу и правильно, либо ничего — вводить вместо этого в несколько этапов, частями, только то, что есть сейчас, корректировать при последующем вводе и т.п.
Примеры, да и топик весь взяты из жизни, из корпоративных систем, в разработке интерфейсов которых я принимал участие. Наболевшее все это. Везде возможность ввода неполных данных давала дополнительную гибкость, свободу в использовании. Я же не к анархии призываю, не к подделке фактов или еще чего-то. Просто систему можно научить хранить неполные и некорректные данные, явным образом помечая их как неполные и некорректные. И пускать в работу такие данные я не предлагаю. Пусть просто полежат до уточнения. Они и в вашем случае полежат, только в вашем — на бумажке на столе, которая может потеряться и все такое прочее, а в моем они полежат в информационной системе.
Так бы и делали — сначала давали скачать, а потом уже (пока скачивается) желающих форму заполнить опрашивали. На Vimeo.com похожим образом сделано — пока ты закачиваешь им видеофайл, тебе предлагают заполнить информацию всякую о нем. Я с удовольствием заполняю, все равно ждать.
Тут ведь нет такой альтернативы — либо все, либо ничего. Моя оценка основана на опыте адаптации существующих интерфейсов, в предыдущей компании и вот в текущей (системы класса АСУ ТП и АСУП соотв.). Собственно, сам топик — из наболевшего возник. В большинстве случаев мы обходимся малыми трудозатами, туда, где все сильно переплетено, пока не лезем, что не мешает получать более чем удовлетворительный результат в большинстве случаев.
На деле разнообразия не будет. Будет фильтр — достаточно имеющихся данных или нет. Везде, где недостаточно — сообщается, чего именно не хватает для данной конкретной операции.
Я, действительно, не разбираюсь, но два вопроса все же от дилетанта:
1. Если поле обязательное, а данных — нет?
2. Степень строгости проступка — разве не начальством определяется? И что мешает так же наказывать за незаполнение поля?
Про модели — в информационных системах появляется еще один фактор, несвойственный реальности как таковой — доступность информации в данный конкретный момент. Т.е. в мире у человека есть паспорт и у этого паспорта есть номер, просто речь о том, что в данный конкретный момент мы его не знаем. В этом отличие.
Необходимости обязательных полей для выполнения системой функций я не отрицаю не в коем случае. Я о требовании ввести все данные обязательно полностью и за раз — его надо убирать.
И я не предлагаю отказаться от обработки ошибок. Просто иногда (в угоду целей пользователей!) имеет смысл принимать в том числе и некорректные данные. Предположим, система видит, что счетчик не может иметь таких показаний, какие вносит Сергей Витальевич. Что она должна делать? Правильная система — а) предупредить, что не так (Сергей Витальевич проверит, тот ли вообще счетчик он осматривает, правильно ли он переписал и т.п.), б) позволить сохранить данные, если пользователь ее попросит — просто потому, что в тундре как-то несподручно разбираться, что там раньше, возможно, не так внесли, и в) по возвращении напомнить СВ или ответственному лицу, мол, у нас тут лежат некорректные данные, помнишь? — разберись, пожалуйста.
Слушайте, ну насчет стоимости, в 1,5 раза — это как-то чересчур. Речь о небольших, причем зачастую — психологических изменениях.
И вы натолкнули меня еще на одну мысль — ведь на самом деле, предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design.
Вот! Это я и пытался донести. Попробуйте встать на позицию пользователя, пожалеть его, помочь ему. Поверьте, они вам отплатят, косвенно, через успех вашего продукта. Программировать не так уж и сложно, генерировать идентификаторы — тем более.
А вы им говорите, что оно обязательное. Я как раз об этом писал в заблуждении №3, по-моему, делать поле обязательным — это не выход. Разве что считать, что женщины системы боятся больше, чем начальника, и их пугает сообщение о незаполненном поле. Сделаете вы поле обязательным, но ничто не помешает им вбивать туда пробел, точку или еще какую отписку.
Представьте себе, например, систему паспортного стола, в ней форма добавления человека и документов, и все поля — необязательные: фамилия, имя, отчество (особенно), дата рождения, номера паспорта, кем выдано и т.п.
Т.е. ничего выдающегося. Тут про смену парадигмы мышления больше — разработчику пересилить себя и позволить не заполнять часть информации. Т.е. знаешь ты, например, только, что паспорт выдан был в 2005 году и отчество человека — Евгеньевич, — прекрасно, система это сохранит и не будет парить тебе мозг, что фамилия — это очень важно. Придет через месяц этот Евгеньевич — заполнишь недостающие данные, нет — ну а что тут можно поделать?
Понял, о чем вы. Второй случай — это когда из-за нехватки информации нельзя выполнить какое-то действие. Тут ничего не поделаешь, действительно, нельзя.
Я же рассматриваю функцию хранения информации, что ли (наверное, есть какое-то название для такого класса систем), а именно тот нехороший случай, когда нехватка части информации мешает ввести в систему хотя бы ту ее часть, которая имеется в наличии.
«Пришел — проверили, отправили дозаполнять — исправил, вернулся — проверили, приняли, сказали жди паспорт»
и
«Пришел — проверили, приняли часть и отправили дозаполнять недостающее — исправил, вернулся — проверили, приняли, сказали жди паспорт»?
В вашем случае за экспедитором никто не пошлет, пока накладная не будет заполнена полностью. А вот заполнить ее можно будет или сразу целиком, или по частям, в разное время (но обязательно до запуска бизнес-процесса).
Это и сейчас так работает, тут я ничего менять не предлагаю. Единственное, что уже принесенные документы не проваляются на полке, а будут частично занесены в базу, пока Петров ходит.
Я имел в виду, что чем меньше обязательных полей, тем лучше, не обязательно их количество строго до нуля доводить, удобство использования растет плавно с уменьшением количества обязательных полей.
Примеры, да и топик весь взяты из жизни, из корпоративных систем, в разработке интерфейсов которых я принимал участие. Наболевшее все это. Везде возможность ввода неполных данных давала дополнительную гибкость, свободу в использовании. Я же не к анархии призываю, не к подделке фактов или еще чего-то. Просто систему можно научить хранить неполные и некорректные данные, явным образом помечая их как неполные и некорректные. И пускать в работу такие данные я не предлагаю. Пусть просто полежат до уточнения. Они и в вашем случае полежат, только в вашем — на бумажке на столе, которая может потеряться и все такое прочее, а в моем они полежат в информационной системе.
1. Если поле обязательное, а данных — нет?
2. Степень строгости проступка — разве не начальством определяется? И что мешает так же наказывать за незаполнение поля?
Необходимости обязательных полей для выполнения системой функций я не отрицаю не в коем случае. Я о требовании ввести все данные обязательно полностью и за раз — его надо убирать.
И я не предлагаю отказаться от обработки ошибок. Просто иногда (в угоду целей пользователей!) имеет смысл принимать в том числе и некорректные данные. Предположим, система видит, что счетчик не может иметь таких показаний, какие вносит Сергей Витальевич. Что она должна делать? Правильная система — а) предупредить, что не так (Сергей Витальевич проверит, тот ли вообще счетчик он осматривает, правильно ли он переписал и т.п.), б) позволить сохранить данные, если пользователь ее попросит — просто потому, что в тундре как-то несподручно разбираться, что там раньше, возможно, не так внесли, и в) по возвращении напомнить СВ или ответственному лицу, мол, у нас тут лежат некорректные данные, помнишь? — разберись, пожалуйста.
И вы натолкнули меня еще на одну мысль — ведь на самом деле, предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design.
Т.е. ничего выдающегося. Тут про смену парадигмы мышления больше — разработчику пересилить себя и позволить не заполнять часть информации. Т.е. знаешь ты, например, только, что паспорт выдан был в 2005 году и отчество человека — Евгеньевич, — прекрасно, система это сохранит и не будет парить тебе мозг, что фамилия — это очень важно. Придет через месяц этот Евгеньевич — заполнишь недостающие данные, нет — ну а что тут можно поделать?
Я же рассматриваю функцию хранения информации, что ли (наверное, есть какое-то название для такого класса систем), а именно тот нехороший случай, когда нехватка части информации мешает ввести в систему хотя бы ту ее часть, которая имеется в наличии.