Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 322
Ага, и предположим это программа по переписи населения. В стране «БезНазвания1» проживает 150млн Ивановых Иванов Ивановичей 01.01.1970 года рождения.
Бывает я регистрирую email для конкретного проекта (где пользователем ящика будет организация/филиал или рабочая группа или некий робот), тем не менее от меня неизменно требуют заполнить имя, фамилию и дату рождения.
Моё имя нужно только для осуществления платежа с помощью кредитной карточки. Всё. Даже для адреса оно не нужно — доставят с любым именем. А в остальных случаях и подавно.
Сыпать ошибками она будет только если вы такие неумелые, что не смогли с этим справится и спроектировать нормальную систему, а не невесть чего. А доброта тут не при чём.
Это значит, что на этапе проектирования сознательно не учли, что данные можно вводить неполностью. Подчеркиваю — сознательно. Потому что если несознательно, то проектировщику нужно менять работу вследствие профнепригодности. =)
Соглашусь с автором, порой реально напрягает неслабое количество «обязательных» полей на некоторых сайтах и в программах.
P.S.: FF кстати, тоже давно обновляется «втихую».
P.S.: FF кстати, тоже давно обновляется «втихую».
да я же не FF поругать, просто пример показательный — одна функция и два подхода к реализации.
Меня больше всего напрягает обязательная регистрация на многих ресурсов, для того чтобы посмотреть «скрытый текст», скачать картинку и т.д. Абсолютно неясно, для чего авторам ресурса копить «мертвые души»: мне-то не лень зарегаться если там что-то важное для меня, но я ведь туда никогда не вернусь
Причина на мой взгляд очесидна: письками рейтингом померится. мол у меня на форуме 500 рарегистрировавшихся, а у меня 501!..
Для рекламодателя.
Если это на сайте автора софта — то на мой взгляд это нормально. Любому автору интересно я думаю сколько скачало и хотя бы в двух словах кто эти люди.
Так бы и делали — сначала давали скачать, а потом уже (пока скачивается) желающих форму заполнить опрашивали. На Vimeo.com похожим образом сделано — пока ты закачиваешь им видеофайл, тебе предлагают заполнить информацию всякую о нем. Я с удовольствием заполняю, все равно ждать.
Для того, чтобы узнать, сколько людей скачало файл, достаточно при отдаче файка цвеличивать счетчик ) думаю, не очень много найдется людей, которые буду закачивать повторно.
Тыканье по ссылку != скачивание, равно как неизвестно вообще кто тыкал: бот или человек. Вообще, говоря что это нормально, я имел ввиду что заполнение данных о себе — это безобидная «оплата» немалого труда разработчика. Подумайте, человек сделавший софт который вы себе бесплатно скачаете потратил месяцы, а то и годы времени, а вам жалко пару минут написать о себе?
ох, за больное прямо задели. У меня часто бывает такое — из поиска гугла попадаю на какой-то сайт, требуется регистрация на скачивание, пытаюсь зарегистрироваться — занят логин! Лезу в архив почты — точно, 2 года назад уже регался на этом ресурсе.
Я на таких ресурсах сразу пробую аккаунты вида
логин:1234567890
пароль:1234567890
в 7 случаях из 10 подходит! Если же такого нету акка, регаю сам. Ну бесит же просто! Если ресурс хороший, я и так нормально зарегистрируюсь, а ради одного действия(скачать/посмотреть/etc) нормально региться… Да ну нафиг.
логин:1234567890
пароль:1234567890
в 7 случаях из 10 подходит! Если же такого нету акка, регаю сам. Ну бесит же просто! Если ресурс хороший, я и так нормально зарегистрируюсь, а ради одного действия(скачать/посмотреть/etc) нормально региться… Да ну нафиг.
Есть ещё www.bugmenot.com — тоже помогает.
Слушайте, отличная идея! Надо придумать какую-то публичную пару «имя/пароль» для таких вот идиотов-админов с их манией обязательной регистрации для каждого чиха их «крутых» форумах. Предлагаю самый простой вариант: habr/habr Кому надо что-то скачать, логинится под ним. Если его нет — регистрирует (для себя, а в последствии для других)
Для полного счастью можно попотеть и написать авторегалку с этими данными =) причем все остальные поля заполняет произвольно, но правдоподобно (большинство таких полей можно ведь и угадать: фамилия там, mail...)
И потом все, кто будут юзать эту программу, будут ходить под одним и тем же юзверем ) может быть, тогда создатели подобных сайтов задумаются?
И потом все, кто будут юзать эту программу, будут ходить под одним и тем же юзверем ) может быть, тогда создатели подобных сайтов задумаются?
Попробуйте bugmenot.com. Существует и как отдельный сайт, и как плагины к FF и Chrome. Позволяет решить проблему с «хочу посмотреть, но регистрироваться не хочу».
А у меня постоянно чето спрашивает, просит перезапустится и показывает окошки что какой-то плагин проапдейтился. Это где-то настраивается? Вообще не понятно как такое возможно, он то ставится в Program Files, а туда запись запрещена.
У вас какая версия ФФ? А вторую часть вопроса я не понял )
3.6.3 — последняя…
А во второй части вопроса, я преживаю по поводу как ФФ будет реализовывать авто-апдейт без вопросов. Они просто инсталятся в Program Files. Туда запись запрещена. Соотвевенно, каждый раз когда они захотят обновиться, как минимум UAC сработает. Гугль это обошл тем что Хром ставится в юзерскую директорию. А туда запись разрешена.
А во второй части вопроса, я преживаю по поводу как ФФ будет реализовывать авто-апдейт без вопросов. Они просто инсталятся в Program Files. Туда запись запрещена. Соотвевенно, каждый раз когда они захотят обновиться, как минимум UAC сработает. Гугль это обошл тем что Хром ставится в юзерскую директорию. А туда запись разрешена.
я с семеркой только недавно толкнулся — на работе обновили хрюшу. Но UAC я быстро и решительно выключил в первый день, ФФ с тех пор еще не обновлялся, не знаю как там будет чего, на хрюше фокс просто при очередном запуске говорил «идет установка обновления, подождите...» где-то секунд 15-20 и запускался обновленным. А дома на линуксе ФФ из репо обновляется, никаких вопросов, если настроить автоапдейт (но я подтверждаю ручками по старой привычке)
Некоторые программы пишут в пользовательскую папку, или Appliction Data, например )
Плагины FF ставятся в домашнюю папку пользователя. А под ограниченной учёткой FF уже не может самостоятельно обновиться.
С какой версии? У меня 3.x (не помню точно), и она спрашивает при запуске обновление дополнений. Хотя и не самого FF, но все равно надоедает.
По-моему вы смешали в кашу две совершенно разные вещи:
1. Когда в интерфейсе присутствуют обязательные поля, которые по логике никак не должны влиять на функционирование системы (например, требование ввести ФИО при регистрации на форуме). Тут я с вами согласен.
2. Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения).
2. Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения).
Я бы сказал, что автор не осветил случаев, когда программа не является БД-клиентом, и на форму кроме корректного сохранения записи наложены другие обязанности.
Нет тут каши =) просто о другом.
То про что говорите вы, по сути является больше диалогом, когда от пользователя нужно не полное описание сущности, должной сохраниться в системе, а всего лишь один-два параметра, без которых дальнейшая работа алгоритма бессмысленна.
Нет тут каши =) просто о другом.
То про что говорите вы, по сути является больше диалогом, когда от пользователя нужно не полное описание сущности, должной сохраниться в системе, а всего лишь один-два параметра, без которых дальнейшая работа алгоритма бессмысленна.
Понял, о чем вы. Второй случай — это когда из-за нехватки информации нельзя выполнить какое-то действие. Тут ничего не поделаешь, действительно, нельзя.
Я же рассматриваю функцию хранения информации, что ли (наверное, есть какое-то название для такого класса систем), а именно тот нехороший случай, когда нехватка части информации мешает ввести в систему хотя бы ту ее часть, которая имеется в наличии.
Я же рассматриваю функцию хранения информации, что ли (наверное, есть какое-то название для такого класса систем), а именно тот нехороший случай, когда нехватка части информации мешает ввести в систему хотя бы ту ее часть, которая имеется в наличии.
Я возможно сейчас процитирую Кэпа, но в целом, нормально спроэктированная программа кроме как во втором случае не должна отмечать поле как обязательное. Обязательные поля они не предполагают мучения пользователя на предмет извлечения информации, которую ему трудно добыть, их смысл как раз в том чтобы закрыть пробелы информации в критических по функционалу местах… не понимаю о чем вообще речь в посте? о том что не надо вытягивать из пользователя информацию которая никак и нигде не применяется? так такую и хранить вообще не надо и поля надо такие из структур БД выкидвать…
«Если функционал не критичен к полю, то поле не обязательно. Иначе поле обязательно» — вроде формула простая и понятная, ну мне по крайней мере.
Все это решается на стадии проектирования, зачем столько размусоливать не понял…
«Если функционал не критичен к полю, то поле не обязательно. Иначе поле обязательно» — вроде формула простая и понятная, ну мне по крайней мере.
Все это решается на стадии проектирования, зачем столько размусоливать не понял…
Письмо без отправителя замечательно может полежать на полочке в виде черновика.
Обратите внимание:
От того, что оно полежит на полочке изначальная цель (отправка сообщения) выполнена не будет. Да, это дополнительное удобство для пользователя, что он может сохранить промежуточный результат. Но когда он захочет отправить сообщение от обязательности поля «получатель» никуда не деться. Следуя вашей логике можно, например, при регистрации сделать поля ФИО обязательным, а промежуточные даннные записывать в сессию пользователю. Например, пользователь вбил только фамилию (разумеется этого не достаточно чтобы закончить регистрацию) и ушел со страницы, на следующей день зашел опять в регистрацию, а там значение поля «фамилия» сохранилось с прошлого раза, он вбил недостающие «имя» и «отчество» и закончил регистрацию. Только, как ни крути, эти поля все равно обязательны к заполнению для завершения действия, потому как пока он не введет все необходимые данные он не выполнит необходимое ему действие, в данном случае — регистрацию.
например, поле «получатель» при отправке email-сообщения
От того, что оно полежит на полочке изначальная цель (отправка сообщения) выполнена не будет. Да, это дополнительное удобство для пользователя, что он может сохранить промежуточный результат. Но когда он захочет отправить сообщение от обязательности поля «получатель» никуда не деться. Следуя вашей логике можно, например, при регистрации сделать поля ФИО обязательным, а промежуточные даннные записывать в сессию пользователю. Например, пользователь вбил только фамилию (разумеется этого не достаточно чтобы закончить регистрацию) и ушел со страницы, на следующей день зашел опять в регистрацию, а там значение поля «фамилия» сохранилось с прошлого раза, он вбил недостающие «имя» и «отчество» и закончил регистрацию. Только, как ни крути, эти поля все равно обязательны к заполнению для завершения действия, потому как пока он не введет все необходимые данные он не выполнит необходимое ему действие, в данном случае — регистрацию.
>> Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения).
Хороший пример.
Поле «получатель» при отправке email-а как раз, таки, опциональное. И я не хочу, чтобы почтовая программа проверяла его на валидность вынудив меня что-нибудь в него ввести. И приходится забивать там рыбу — собственный адрес.
Хороший пример.
Поле «получатель» при отправке email-а как раз, таки, опциональное. И я не хочу, чтобы почтовая программа проверяла его на валидность вынудив меня что-нибудь в него ввести. И приходится забивать там рыбу — собственный адрес.
«Поля, без которых вводимая информация не имеет смысла (например, поле «получатель» при отправке email-сообщения)»
Почему же не имеет? Я, к примеру, вечером написал письмо поставщику сувениров с новым заказом для своего магазина, но забыл контактные данные (email) поставщика в магазине. Письмо написал, сохранил, с намерением отправить утром с мобильного, как только узнаю email.
Вот и пример реального Use-Case. Если бы не было возможность сохранить черновик письма, мне пришлось бы либо, взяв email-адрес, найти где бы написать письмо, либо, написав, сохранить его в файл, потом при отправке вытащить оттуда итд. Необязательность поля «Кому» в почте — предполагает удобное использование почтового интерфейса в реальном мире.
Думаю, автор топика имел в виду именно это.
Почему же не имеет? Я, к примеру, вечером написал письмо поставщику сувениров с новым заказом для своего магазина, но забыл контактные данные (email) поставщика в магазине. Письмо написал, сохранил, с намерением отправить утром с мобильного, как только узнаю email.
Вот и пример реального Use-Case. Если бы не было возможность сохранить черновик письма, мне пришлось бы либо, взяв email-адрес, найти где бы написать письмо, либо, написав, сохранить его в файл, потом при отправке вытащить оттуда итд. Необязательность поля «Кому» в почте — предполагает удобное использование почтового интерфейса в реальном мире.
Думаю, автор топика имел в виду именно это.
2. Я бы другой пример привел. Например, поле «комментарий» при добавлении комментария.
Соглашусь с автором. Такие вот обязательные поля недавно послужили одной из причин отказа от покупки одной софтины, которая нужна была для работы, пришлось писать самому.
Например, было поле ввода «IMEI», которое обязательно должно было состоять из 12 цифр, ни больше и не меньше. В теории так, но на практике не всегда можно было причитать этот IMEI с телефона целиком, или можно было прочитать только часть цифр. И приходилось считать нажатия клавиши «0» на клавиатуре, лишь бы программа это проглотила.
Например, было поле ввода «IMEI», которое обязательно должно было состоять из 12 цифр, ни больше и не меньше. В теории так, но на практике не всегда можно было причитать этот IMEI с телефона целиком, или можно было прочитать только часть цифр. И приходилось считать нажатия клавиши «0» на клавиатуре, лишь бы программа это проглотила.
Не в тему, но *#06# могло помочь
для этого нужно расспаковать и включить. При оптовых покупках/продажах это проблематично.
Ну вообще то тут прием телефонов на ремонт… Если телефон не включается, то никакие комбинации не помогут. А под батарейкой цифры могут быть банально затерты.
Я привел реальный пример, который постоянно бесил в работе, а не выдуманный из головы.
Я привел реальный пример, который постоянно бесил в работе, а не выдуманный из головы.
А я развел оффтоп. Сорри.
Я в сервисе искал блок питания для видеокамеры домой. Так из система не могла мне выписать мне бланк без указания данных по оборудованию для которого он приобретался. Сама камера была за 1,5 тыс. км от меня. Так в результате работникам сервиса пришлось указать монитор Samsung, а блок питания для видеокамеры стал его запасной частью.
Представьте себе, например, систему паспортного стола, в ней форма добавления человека и документов, и все поля — необязательные: фамилия, имя, отчество (особенно), дата рождения, номера паспорта, кем выдано и т.п.
Т.е. ничего выдающегося. Тут про смену парадигмы мышления больше — разработчику пересилить себя и позволить не заполнять часть информации. Т.е. знаешь ты, например, только, что паспорт выдан был в 2005 году и отчество человека — Евгеньевич, — прекрасно, система это сохранит и не будет парить тебе мозг, что фамилия — это очень важно. Придет через месяц этот Евгеньевич — заполнишь недостающие данные, нет — ну а что тут можно поделать?
Т.е. ничего выдающегося. Тут про смену парадигмы мышления больше — разработчику пересилить себя и позволить не заполнять часть информации. Т.е. знаешь ты, например, только, что паспорт выдан был в 2005 году и отчество человека — Евгеньевич, — прекрасно, система это сохранит и не будет парить тебе мозг, что фамилия — это очень важно. Придет через месяц этот Евгеньевич — заполнишь недостающие данные, нет — ну а что тут можно поделать?
Внести все данные при выдаче паспорта, а не «блин, народу много, завтра заполню, а пока только номер впишу» — и запись так и останется номером. потмоу что умными являются в основном только пользователи вбивающие информацию _для себя_, наемные же рабочие составляющие картотечные данные — отключают мозг, лишь бы поменьше утруждаться.
А вы им говорите, что оно обязательное. Я как раз об этом писал в заблуждении №3, по-моему, делать поле обязательным — это не выход. Разве что считать, что женщины системы боятся больше, чем начальника, и их пугает сообщение о незаполненном поле. Сделаете вы поле обязательным, но ничто не помешает им вбивать туда пробел, точку или еще какую отписку.
Я, действительно, не разбираюсь, но два вопроса все же от дилетанта:
1. Если поле обязательное, а данных — нет?
2. Степень строгости проступка — разве не начальством определяется? И что мешает так же наказывать за незаполнение поля?
1. Если поле обязательное, а данных — нет?
2. Степень строгости проступка — разве не начальством определяется? И что мешает так же наказывать за незаполнение поля?
Регистрацию в бложике я вообще не имел в виду, заметьте, вопросы важности и уместности тех или иных полей я не обсуждаю вовсе. Хотя, судя по комментариям, не вы один меня неправильно поняли — моя вина, наверное, я что-то недостаточно ясно изложил. Мои идеи скорее о переосмыслении самого концепта ввода данных с помощью форм, когда нужно ввести либо все сразу и правильно, либо ничего — вводить вместо этого в несколько этапов, частями, только то, что есть сейчас, корректировать при последующем вводе и т.п.
Примеры, да и топик весь взяты из жизни, из корпоративных систем, в разработке интерфейсов которых я принимал участие. Наболевшее все это. Везде возможность ввода неполных данных давала дополнительную гибкость, свободу в использовании. Я же не к анархии призываю, не к подделке фактов или еще чего-то. Просто систему можно научить хранить неполные и некорректные данные, явным образом помечая их как неполные и некорректные. И пускать в работу такие данные я не предлагаю. Пусть просто полежат до уточнения. Они и в вашем случае полежат, только в вашем — на бумажке на столе, которая может потеряться и все такое прочее, а в моем они полежат в информационной системе.
Примеры, да и топик весь взяты из жизни, из корпоративных систем, в разработке интерфейсов которых я принимал участие. Наболевшее все это. Везде возможность ввода неполных данных давала дополнительную гибкость, свободу в использовании. Я же не к анархии призываю, не к подделке фактов или еще чего-то. Просто систему можно научить хранить неполные и некорректные данные, явным образом помечая их как неполные и некорректные. И пускать в работу такие данные я не предлагаю. Пусть просто полежат до уточнения. Они и в вашем случае полежат, только в вашем — на бумажке на столе, которая может потеряться и все такое прочее, а в моем они полежат в информационной системе.
Мммм. А сколько человеко-часов придется потратить дополнительно, что бы проконтролировать, проверить, и при необходимости исправить данные? (Я опять же — про «промышленные приложения»)
Ведь каждый день операторы, менеджеры и пр. могут вбивать в базу сотни и тысячи новых записей.
Ведь каждый день операторы, менеджеры и пр. могут вбивать в базу сотни и тысячи новых записей.
ну да, сделаем все поля обязательными и они их сразу все и правильно заполнят. Вы сами-то в это верите?
Честно говоря — через раз.
Ведь если я на сайте интернет магазина не укажу (или неправильно укажу) адрес доставки, или хотя бы телефон. Думаю нет смысла говорить что свой заказ я буду ждать очень долго.
А в пром системах у людей нет выбора. Каждая ошибка это время и деньги. Примеры: бухгалтерия, всевозможные программы для управления финансами.
Ведь если я на сайте интернет магазина не укажу (или неправильно укажу) адрес доставки, или хотя бы телефон. Думаю нет смысла говорить что свой заказ я буду ждать очень долго.
А в пром системах у людей нет выбора. Каждая ошибка это время и деньги. Примеры: бухгалтерия, всевозможные программы для управления финансами.
1) зачем хранить данные на бумажке, когда их можно хранить в системе???
2) Как обязательные поля защищают от ввода невалидных данных?
2) Как обязательные поля защищают от ввода невалидных данных?
внесение отсебятины кстати, не ограничивается не на какой стадии, и на каждом уровне требет проверок ) так в рамках того о чем говорится в посте я думаю про валидность данных говорить бесполезно. если рассматривать в рамках пасспортного стола то валидация должна производится на основе сразу нескольких систем:
распознавание графического образа
сверение данных о рождении(с последующими проверками в ЗАГС на смену ФИО)
сверение данных о проживании и старых пасспортах.
Суммарные проверки выносят вердикт о верности заполнения полей.
ИМХО валидацию приписывать к тому о чем говорится в посте неверно…
распознавание графического образа
сверение данных о рождении(с последующими проверками в ЗАГС на смену ФИО)
сверение данных о проживании и старых пасспортах.
Суммарные проверки выносят вердикт о верности заполнения полей.
ИМХО валидацию приписывать к тому о чем говорится в посте неверно…
Эх, паспортному столу давно пора открыть сервис а ля Google Account, Facebook Connect и Live ID, с идентификацией при подтверждении владельца паспорта. Чтобы нигде и никогда не нужно было заново вбивать все данные, а аккаунт создается при выдаче паспорта.
И главное — подача заявки на паспорт онлайн :)
И главное — подача заявки на паспорт онлайн :)
В итоге как я вижу имеем кучу паразитных записей таких вот Евгеньевичей, которые чисто гипотетически могут быть заполнены, но на деле так и останутся в таком вот состоянии. через год придет Евгенич и скажет, а я вот забыл, я заполнял или нет заполню ка я еще разок. Нецелесообразно. С другой стороны можно выбрать из кучи таких вот Евгеничей любую не заполненую и подходяющую под степень заполнения и вместо создания новой завести старую, только вот если Евгенич заполнит какое-либо полу-уникальное поле (пускай фамилию) получаем, запись попросту потеряется и возможно при высоком уровне заполнения без возможность вторичного использования. В общем в принципе труд человека переложить на программиста можно, но целесообразность этого труда несколько озадачивает…
Пример — afisha.ru. Не знаю, пользуетесь ли Вы или ТС вконтактом, Афиша сделала для него приложение, которое позволяет из вконтакта голосовать за фильмы, смотреть рекомендации и т.п. Приложение де-факто создаёт мне пользователя на сайте, под которым я потом могу спокойно зайти на сайт, авторизоваться, нагадить в комментариях оставить рецензию или ещё что-нибудь. Даже логин они мне генерируют — от меня не требуется вообще ничего. При этом любую информацию о себе я, естественно потом могу изменить.
Разрабатывали систему для ЗАГС. Первый вариант ыбл по закону — почти все полоя в Актовых Записях обязательные. Когда начали внедрять, то выяснилось, что практика сильно расходиться с законом, и реально нужно было вводить а/з в практическими всеми неизвестными полями (анприме умер какой-нить бомж, о котором ничего не известно, но а/з составить нужно). В результате переделывали почти всю систему чтоб она корректно работало пустыми данными. Если б изначально следовали логике описанной в посте, проблем бы не было.
Новая Папка (5)\Новая Папка (2)\Новая Папка\Новая Папка (2)\Документ Microsoft Word (3).doc
Годовой отчёт ОАО с оборотом в NNN миллионов рублей.
Годовой отчёт ОАО с оборотом в NNN миллионов рублей.
Аха, мне вот вспоминается та свинья, которую нам подложили разработчики Rambler ICQ и QIP, они видите ли заботясь о пользователе не сообщали, что максимальная длина пароля — 8 символов и спокойно позволяли вводить хоть 20 символьные пароли. А тут уже к нам на форум приходит чудо и начинает права качать мол «как же так, я пытаюсь ввести пароль, а мне не дают ввести больше 8 символов». Причем после указания на то, что это протокол такой нехороший, это чудо начало ссылаться на несчастную Рамблеровскую аську, которая дает ввести больше 8 символов, а на деле молча обрезает пароль до 8 символов.
Ошибки должны быть выявлены как можно раньше и пользователь должен быть с ними ознакомлен, иначе он и дальше продолжить жить, находясь в счастливом неведении, пока что-то плохое не случится.
Ошибки должны быть выявлены как можно раньше и пользователь должен быть с ними ознакомлен, иначе он и дальше продолжить жить, находясь в счастливом неведении, пока что-то плохое не случится.
Про ошибки согласен, просто я несколько раз сталкивался со мнением, что нехватка информации — это ошибка. Что мягко говоря странно.
Ну если человек не вводит поле, которое является уникальным идентификатором в БД, то его нужно возращать и заставлять ввести это поле, в противном случае исправить ошибку будет уже чертовски сложно. А всякие там поля, которые не являются ключами, можно безболезненно делать необязательными.
а почему бы программе самой не сгенерировать это поле?
Потому, что если программа сгенерирует это поле неправильно с точки зрения юзера, то придется развлекаться с обеспечением целостности базы данных. Это не сложно, но неприятно и затрачивает куда больше ресурсов, чем просьба ввести это значение правильно.
— Здравствуйте! Я бы хотел назвать сына Сергеем.
— Извините, но это имя уже занято, попробуйте другое. Свободны, например, Сергей2050, _Сергей_, Сер-Гей или Сергей-19.
Это я к тому, что пользователь вообще не должен (за редким исключением) придумывать уникальный идентификатор.
— Извините, но это имя уже занято, попробуйте другое. Свободны, например, Сергей2050, _Сергей_, Сер-Гей или Сергей-19.
Это я к тому, что пользователь вообще не должен (за редким исключением) придумывать уникальный идентификатор.
Логику пользователя вы только не учли) Ему будет удобнее иметь свой собственный уникальный идентификатор в нативном для него виде. Потому что если иметь 500 идентификторов из разных под систем в виде набора символов, да еще из разных словарей то пользователю поплохеет. тут приходим к системе единого идентификатора, но это о другом )
Вот! Это я и пытался донести. Попробуйте встать на позицию пользователя, пожалеть его, помочь ему. Поверьте, они вам отплатят, косвенно, через успех вашего продукта. Программировать не так уж и сложно, генерировать идентификаторы — тем более.
Проблема высосана из пальца ИМХО. Пока читал пример с перекрестком пришла такая аналогия: автор данного топика предлагает убрать светофоры с улиц города, как же — они мешают людям и задерживают их на пути к цели, люди не дебилы и как нибудь сами разберутся когда и как им переходить дорогу. Автор не задумывается над тем, что без некоторых обязательных полей обойтись никак нельзя — иначе появятся записи-призраки и множество других побочных багов, которые даже при хорошем изначальном проектировании будут появляться.
Вторая крайность — это стремление программистов сделать универсальную систему, максимально близкую в реальной жизни. Стоит ли говорить что такие разработки растягиваются на годы и потом тихо умирают.
Вторая крайность — это стремление программистов сделать универсальную систему, максимально близкую в реальной жизни. Стоит ли говорить что такие разработки растягиваются на годы и потом тихо умирают.
… иначе появятся записи-призраки и ...
а так они появятся на бумаге или в других системах ;-)
Цитата:
Аккуратные голландцы убрали с улиц все светофоры
… Удаление светофоров с улиц Драхтена (Drachten) началось семь лет назад, и последние три светофора будут демонтированы в течение двух лет.
— В «светофорные» времена ДТП со смертельным исходом в Драхтене имели место каждые три года, а вот после начала эксперимента на дорогах не погиб ни один человек.
— Главный городской перекрёсток пропускает примерно 22 тысячи автомобилей в день, не считая нескольких тысяч велосипедистов и пешеходов. В «дни светофора» движение здесь было затруднено: водители стояли в пробках и без конца сигналили.
…
Типичная ошибка дорожных инженеров состоит в том, что когда с дорогой начинаются проблемы, они всегда пытаются что-нибудь добавить, — поясняет Мондерман. — На мой взгляд, в таких ситуациях гораздо лучше что-нибудь убрать
То есть я думаю, что «светофоры» нужны, но к месту, — как крайняя необходимость. Если делать город для людей и их удобства, а не потому как проще и надежнее для проектировщиков.
Любая система служит человеку, а не ради своей целостности и надежности. Систему «для человека» сделать сложно или даже очень сложно. Но ведь надо стремиться. Если пользователь понимает, что более полное описание дает более качественный результат, то при заинтересованности в последнем он сам будет стараться.
Но поскольку делать такие системы сложно и долго, мы мучаемся с «тупыми» программами и стоим в бесконечных пробках.
А делать можно. Конечно, всему есть предел и крайностей надо избегать.
Аккуратные голландцы убрали с улиц все светофоры
… Удаление светофоров с улиц Драхтена (Drachten) началось семь лет назад, и последние три светофора будут демонтированы в течение двух лет.
— В «светофорные» времена ДТП со смертельным исходом в Драхтене имели место каждые три года, а вот после начала эксперимента на дорогах не погиб ни один человек.
— Главный городской перекрёсток пропускает примерно 22 тысячи автомобилей в день, не считая нескольких тысяч велосипедистов и пешеходов. В «дни светофора» движение здесь было затруднено: водители стояли в пробках и без конца сигналили.
…
Типичная ошибка дорожных инженеров состоит в том, что когда с дорогой начинаются проблемы, они всегда пытаются что-нибудь добавить, — поясняет Мондерман. — На мой взгляд, в таких ситуациях гораздо лучше что-нибудь убрать
То есть я думаю, что «светофоры» нужны, но к месту, — как крайняя необходимость. Если делать город для людей и их удобства, а не потому как проще и надежнее для проектировщиков.
Любая система служит человеку, а не ради своей целостности и надежности. Систему «для человека» сделать сложно или даже очень сложно. Но ведь надо стремиться. Если пользователь понимает, что более полное описание дает более качественный результат, то при заинтересованности в последнем он сам будет стараться.
Но поскольку делать такие системы сложно и долго, мы мучаемся с «тупыми» программами и стоим в бесконечных пробках.
А делать можно. Конечно, всему есть предел и крайностей надо избегать.
Ага, заодно давайте глянем на этот город. Эдакая большая деревня переросток, с одной главной улицей. Я бы не считал удаление светофоров там большим достижением.
ИМХО конечно, но по моему почти каждый светофор, каждый положенный на асфальт лежачий полицейский (особенно в нашей стране) спровоцировала чья то смерть или большое количество аварий. Приведу обратный пример в Новогиреево (в Москве) пару лет назад поставили светофоры на круговом движении, до этого, практически всегда, когда я проезжал это место (было это правда не часто) там кто то стоял с аварийкой и была пробка. Сейчас, со светофорами ситуация гораздо лучше. Так что, вопрос со светофорами довольно спорный и мне кажется это отдельная тема для беседы.
ИМХО конечно, но по моему почти каждый светофор, каждый положенный на асфальт лежачий полицейский (особенно в нашей стране) спровоцировала чья то смерть или большое количество аварий. Приведу обратный пример в Новогиреево (в Москве) пару лет назад поставили светофоры на круговом движении, до этого, практически всегда, когда я проезжал это место (было это правда не часто) там кто то стоял с аварийкой и была пробка. Сейчас, со светофорами ситуация гораздо лучше. Так что, вопрос со светофорами довольно спорный и мне кажется это отдельная тема для беседы.
Абсолютно согласен насчет светофоров. Действительно, они у нас обычно появляются реально по крайней необходимости. Плюс национальные особенности… Не факт, что аналогичный эксперимент в российском городке был бы успешен, когда некоторых даже светофоры не останавливают. У нас люди не готовы к такому. А уж Москва вообще особый случай. Забавно — я знаю этот круг в районе Новогиреево — сам нередко им пользовался, так что понимаю о чем речь.
Однако, это не отменяет мнения, что хотелось бы иметь город в первую очередь для жителей, а не для гаишников, коммунальных служб, и т.д. В общем это действительно отдельная тема.
Пример просто показывает, что даже такая красивая аналогия не оказывается железным доказательством того, что «Проблема высосана из пальца».
Возможно она даже глубже, чем представлял себе автор топика.
Обязательные поля могут быть злом не обязательно потому, что доставляют неудобство пользователю. Часто это признак слабости и низкого качества системы с точки зрения ее назначения. Поля формы — это описание ситуации, требующей решения (классификации). Нетривиальные задачи действительно отличаются тем, что описываемый объект «не виден» полностью. В то же время, обычно есть множество альтернативных способов решения, в зависимости от того, какая часть данных доступна. Хорошая система — компромисс между идеальной, и той, которую можно создать за разумные (поставленные) сроки разумными (имеющимися) силами.
Другое дело, что для бизнеса, создающего системы, первостепенная задача не в том, чтобы лучше решить проблемы клиента, а в том, чтобы заработать побольше денег. И тут вариантов немало.
Однако, это не отменяет мнения, что хотелось бы иметь город в первую очередь для жителей, а не для гаишников, коммунальных служб, и т.д. В общем это действительно отдельная тема.
Пример просто показывает, что даже такая красивая аналогия не оказывается железным доказательством того, что «Проблема высосана из пальца».
Возможно она даже глубже, чем представлял себе автор топика.
Обязательные поля могут быть злом не обязательно потому, что доставляют неудобство пользователю. Часто это признак слабости и низкого качества системы с точки зрения ее назначения. Поля формы — это описание ситуации, требующей решения (классификации). Нетривиальные задачи действительно отличаются тем, что описываемый объект «не виден» полностью. В то же время, обычно есть множество альтернативных способов решения, в зависимости от того, какая часть данных доступна. Хорошая система — компромисс между идеальной, и той, которую можно создать за разумные (поставленные) сроки разумными (имеющимися) силами.
Другое дело, что для бизнеса, создающего системы, первостепенная задача не в том, чтобы лучше решить проблемы клиента, а в том, чтобы заработать побольше денег. И тут вариантов немало.
Если говорить про обязательные поля, то я, в принципе, согласен — бесит, когда 100500 сайт хочет обязательно знать, где я живу, при этом, например, проверяет на сервере существование почтового индекса (особенно когда еще и проверка с багами для других стран...). Но пост мне просто показался этаким анархичным призывом отменить все обязательные поля вообще :) Тут у меня просто случился разрыв шаблона :)
А вот с апдейтами в конце статья выглядит уже более логичной, есть над чем подумать.
А вот с апдейтами в конце статья выглядит уже более логичной, есть над чем подумать.
Ето верно. Кстати, очень хорошая аналогия проводится с бумажным бланком — на бумаге мы не обязаны вписывать все поля. И это чертовски удобно.
ЗЫ вообще много хорошего для разработки UI можно почерпнуть из реального мира.
ЗЫ вообще много хорошего для разработки UI можно почерпнуть из реального мира.
Да счас, не обязаны, у вас в противном случае бланк не примут. Просто нужно точно отдавать себе отчет в том, какие поля обязательны, а какие нет. Но вот давать пользователям возможность ошибочные данные вводить это делать им медвежью услугу
Как вариант в форме можно добавить кнопку типа «Сохранить как есть». Данные сохранятся, но использоваться по дальнейшему назначению не будут. Пользователь сможет вернуться, дополнить данные и тогда уже их запустить в оборот.
Ну так на многих форумах есть кнопка «сохранить как черновик». Такой вариант годится и используется. В принципе я видел подобного рода расширения для Лисы, которые автозаполняли формы и могли сохранять черновики
Это использование черновика. И пока они не используются — это и данными-то сложно назвать.
Как я понимаю, tonsky и призывает почаще пользоваться черновиками, но делать это незаметно для пользователя.
Что-то не похоже. Как я понял, автор предлагает оставить как есть. А потом если что — разбираться.
Пример из жизни: Пришли на почту, отправили письмо, но не заполнили получателя. Через месяц приходите, и спрашиваете «почему не дошло». И так далее…
А в электронном мере можно вообще следов не найти. Стерли «куку» и никто вас без пароля и не опознает.
Пример из жизни: Пришли на почту, отправили письмо, но не заполнили получателя. Через месяц приходите, и спрашиваете «почему не дошло». И так далее…
А в электронном мере можно вообще следов не найти. Стерли «куку» и никто вас без пароля и не опознает.
Более того, форма бланка не фиксирована, в одном банке выдадут один, в другом — другой, а налоговая не примет ни тот, ни этот. Лепота )
Искусство программирования как раз в том и состоит, чтобы найти компромисс между целостностью системы, ее удобством, затратами на разработку и много чем еще. А придерживаться какой-либо догмы неправильно.
Я бы сказал, что искусство программирования состоит в том, чтобы максимально быстро, качественно и дешево получить результат от разрабатываемой программы.
А не просто создать программу, пусть быстро, дешево и с качественным кодом, — но ей никто не будет пользоваться.
А не просто создать программу, пусть быстро, дешево и с качественным кодом, — но ей никто не будет пользоваться.
Это все прекрасно и очень верно, однако отсутствие обязательных полей усложняет систему, что в конечном итоге очень сильно сказывается на ее стоимости.
И если предложить заказчику продукт с обязательными полями и без таковых, но примерно в 1,5 раза дороже (представляете, во сколько раз увеличивается количество точек входа и разнообразие исходных данных?) — то, скорее всего, он выберет первый вариант.
Хотя, второй будет гораздо более для людей.
И если предложить заказчику продукт с обязательными полями и без таковых, но примерно в 1,5 раза дороже (представляете, во сколько раз увеличивается количество точек входа и разнообразие исходных данных?) — то, скорее всего, он выберет первый вариант.
Хотя, второй будет гораздо более для людей.
Слушайте, ну насчет стоимости, в 1,5 раза — это как-то чересчур. Речь о небольших, причем зачастую — психологических изменениях.
И вы натолкнули меня еще на одну мысль — ведь на самом деле, предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design.
И вы натолкнули меня еще на одну мысль — ведь на самом деле, предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design.
1.5 — это действительно явно неверная оценка. Я бы оценил примерно в 8-10. Основываясь на своем опыте разработки систем.
Ваше мнение об избыточности 1.5 основано на опыте разработки и внедрения или на представлениях о том, как должен быть устроен мир?
Ваше мнение об избыточности 1.5 основано на опыте разработки и внедрения или на представлениях о том, как должен быть устроен мир?
Тут ведь нет такой альтернативы — либо все, либо ничего. Моя оценка основана на опыте адаптации существующих интерфейсов, в предыдущей компании и вот в текущей (системы класса АСУ ТП и АСУП соотв.). Собственно, сам топик — из наболевшего возник. В большинстве случаев мы обходимся малыми трудозатами, туда, где все сильно переплетено, пока не лезем, что не мешает получать более чем удовлетворительный результат в большинстве случаев.
«продукт с обязательными полями и без таковых» — это именно все или ничего.
не, ну их количество же до нуля относительно гладко опускается.
Простите, я не понял смысла этой фразы.
Кстати, в свете некоторых Ваших комментариев у меня возник конкретный вопрос: как именно Вы документируете в модели данных тот факт, что данное поле обязательно для бизнес-процесса X, но необязательно для бизнес-процесса Y? И как в дальнейшем управляете изменениями? В частности, как именно проверяете, что не возникает ситуации, когда на шаге N уже не осталось акторов, которые могут ввести данные, обязательные для шага N+1?
Я понимаю, что возможен ответ «а само как-нибудь срастется», но верю в лучшее.
Я понимаю, что возможен ответ «а само как-нибудь срастется», но верю в лучшее.
Ну это не в модели данных документируется, к счастью, иначе действительно было бы потом не разобрать, что зачем.
Эта беседа становится все интереснее.
Т.е. в модели данных у Вас НЕ документируется обязательность полей? А где документируется? В описании каждого отдельного бизнес-процесса?
И дизайнер базы данных изучает каждый из них в отдельности при проектировании структуры БД?
Я правильно понял Вашу концепцию проектирования?
Т.е. в модели данных у Вас НЕ документируется обязательность полей? А где документируется? В описании каждого отдельного бизнес-процесса?
И дизайнер базы данных изучает каждый из них в отдельности при проектировании структуры БД?
Я правильно понял Вашу концепцию проектирования?
В модели данных документируются обязательные для схемы данных поля. Обязательность поля для бизнес-процесса документируется в описании бизнес-процесса, потому как только там и используется.
Т.е. у Вас обязательность для схемы не определяется обязательностью для бизнеса, а формулируется по некоторым другим причинам? И Вы не используете средства обеспечения целостности БД, обрабатывая целостность на уровне приложения? Если не секрет — каков объем данных?
Или все же зависит? Если да, то как эта информация попадает из документации на бизнес-процессы в документацию на схему БД и кто обеспечивает управление изменениями?
Или все же зависит? Если да, то как эта информация попадает из документации на бизнес-процессы в документацию на схему БД и кто обеспечивает управление изменениями?
Ну да, не определяется. Ведь поле, обязательное для одного бизнес-процесса, может быть (и часто является) необязательным для другого. И на всякий случай повторю, что мы не доводим ничего до абсурда. Обязательные поля в схеме БД есть, и их обязательность определяется многими факторами, в т.ч. и бизнес-процессами. Но мы стараемся такие места минимизировать. Объемы — 105—106 учетных единиц.
Т.е. Вы НЕ используете средства БД по контролю целостности и никто конкретно не отвечает за то, чтобы информация по обязательности полей попала в структуру БД?
Я правильно понял ту часть, на которую Вы не стали отвечать?
Я правильно понял ту часть, на которую Вы не стали отвечать?
Средства по контролю целостности БД используем. Там, где поле на форме соответствует 1:1 полю в БД, иногда это ограничение заносится в схему, иногда нет, зависит от. Проверка обязательности на уровне приложения есть в обоих случаях.
Не уверен, что понял Вас правильно.
Вашу фразу несколько выше я понял так: большинство полей в схеме Вы описываете как необязательные и контроль выполняете в конкретном компоненте бизнес-процесса на уровне приложения. Контроль на уровне базы — только в небольшом числе полей.
Так ли это?
Означает ли это также, что бОльшая часть проверок, соответственно, производится на уровне приложения?
Вашу фразу несколько выше я понял так: большинство полей в схеме Вы описываете как необязательные и контроль выполняете в конкретном компоненте бизнес-процесса на уровне приложения. Контроль на уровне базы — только в небольшом числе полей.
Так ли это?
Означает ли это также, что бОльшая часть проверок, соответственно, производится на уровне приложения?
предположение о том, что данных может не быть, заставляет писать более «стрессоустойчивый», надежный код, поскольку обработку ошибок/нехватки информации придется писать сразу, by design
Как ни странно, для того, чтобы система работала с неполными данными, вовсе нет нужды повышать ее «стрессоустойчивость».
Принцип здесь гораздо более простой: поток данных делится на сегменты различной полноты. Переход в следующий сегмент — только по достижению нужного уровня наполненности и непротиворечивости. При этом в полный рост сохраняется возможность использовать ограничения баз данных.
BTW, работа с противоречивыми данными гораздо важнее и сложнее, чем работа с неполными данными. Проблема обязательных полей — только верхушка айсберга «data cleansing».
Проблема не в обработке ошибок, а в факториальном увеличении разнообразия входных данных.
Если у меня есть обязательные поля «имя, дата рождения, серияномерпаспорта», то для операции «выдача кредита» я должен запросить их у базы, выполнить мат. рассчет и записать информацию в базу, попутно выдав сообщение пользователю.
Если у меня обязательных полей нет, то я должен проверять наличие данных этого типа и обрабатывать ситуации отсутствия входных данных. То есть одно недозаполненное поле сегодня обернется десятком всплывающих окон завтра (или вы намерены писать динамическую форму, которая будет дозапрашивать недостающие данные в любых комбинациях?).
Если у меня есть обязательные поля «имя, дата рождения, серияномерпаспорта», то для операции «выдача кредита» я должен запросить их у базы, выполнить мат. рассчет и записать информацию в базу, попутно выдав сообщение пользователю.
Если у меня обязательных полей нет, то я должен проверять наличие данных этого типа и обрабатывать ситуации отсутствия входных данных. То есть одно недозаполненное поле сегодня обернется десятком всплывающих окон завтра (или вы намерены писать динамическую форму, которая будет дозапрашивать недостающие данные в любых комбинациях?).
На деле разнообразия не будет. Будет фильтр — достаточно имеющихся данных или нет. Везде, где недостаточно — сообщается, чего именно не хватает для данной конкретной операции.
И что делать дальше человеку, который увидел это сообщение?
В воображаемом мире — дозаполнить данные. А реальном — лапу сосать.
«Оформляем паспорт… Петров не заполнил адрес и телефон… напомним Петрову… эээ… как? Выйдем на улицу и на всю страну закричим: ПЕ-Е-ЕТРОВ! Заполни адрес и телефон!»
«Оформляем паспорт… Петров не заполнил адрес и телефон… напомним Петрову… эээ… как? Выйдем на улицу и на всю страну закричим: ПЕ-Е-ЕТРОВ! Заполни адрес и телефон!»
Нееет. Петров принес документы, не все, ок, мы их приняли и сказали Петрову, чтобы приносил остальные. Пока он ходил, мы внесли то, что есть. Когда он принесет остальные, и мы ему скажем, что всё, более ничего не нужно, Петров может идти гулять спокойно.
Это и сейчас так работает, тут я ничего менять не предлагаю. Единственное, что уже принесенные документы не проваляются на полке, а будут частично занесены в базу, пока Петров ходит.
Это и сейчас так работает, тут я ничего менять не предлагаю. Единственное, что уже принесенные документы не проваляются на полке, а будут частично занесены в базу, пока Петров ходит.
Петрову сказали, а он не пришел. Петров забыл, что это нужно. Вы навязываете клиенту обязанность понимать ваши бизнес-процессы, а это куда хуже заполнения обязательных полей.
Сейчас, кстати, это работает не так. Анкету у Петрова вообще не примут, пока он не заполнит ее корректно.
Да, реализовать ввод неполной анкеты можно. Но нам придется ввести уже ТРИ типа полей: «совсем обязательные», «обязательные для приема анкеты и отпускания клиента» и «необязательные».
И процедуру приема посетителей придется доработать, организовав отдельную очередь для тех, кто пришел только доввести данные.
В очередной раз обращаю внимание: заполнение форм — только часть реальной жизни, а не ее суть. Петров пришел не для заполнения анкеты, он пришел паспорт получить.
Сейчас, кстати, это работает не так. Анкету у Петрова вообще не примут, пока он не заполнит ее корректно.
Да, реализовать ввод неполной анкеты можно. Но нам придется ввести уже ТРИ типа полей: «совсем обязательные», «обязательные для приема анкеты и отпускания клиента» и «необязательные».
И процедуру приема посетителей придется доработать, организовав отдельную очередь для тех, кто пришел только доввести данные.
В очередной раз обращаю внимание: заполнение форм — только часть реальной жизни, а не ее суть. Петров пришел не для заполнения анкеты, он пришел паспорт получить.
Вы правда видите разницу между
«Пришел — проверили, отправили дозаполнять — исправил, вернулся — проверили, приняли, сказали жди паспорт»
и
«Пришел — проверили, приняли часть и отправили дозаполнять недостающее — исправил, вернулся — проверили, приняли, сказали жди паспорт»?
«Пришел — проверили, отправили дозаполнять — исправил, вернулся — проверили, приняли, сказали жди паспорт»
и
«Пришел — проверили, приняли часть и отправили дозаполнять недостающее — исправил, вернулся — проверили, приняли, сказали жди паспорт»?
Для комьютерной программы разница действительно колоссальная. Для реального бизнес-процесса ее фактически нет.
Если Петров может быстро предоставить эти данные — его незачем гнать из кабинета, достаточно переспросить. И поля вполне срабатывает как обязательное.
Если мы выгнали Петрова — мы обязаны добавить отдельный шаг в бизнес-процесса.
Компьютерные программы и бизнес, который они обеспечивают — не одно и то же.
Если Петров может быстро предоставить эти данные — его незачем гнать из кабинета, достаточно переспросить. И поля вполне срабатывает как обязательное.
Если мы выгнали Петрова — мы обязаны добавить отдельный шаг в бизнес-процесса.
Компьютерные программы и бизнес, который они обеспечивают — не одно и то же.
В реальном бумажном мире такая система не встречается.
Она выросла не из плохих разработчиков, а из реальных бизнес-процессов.
А в бизнес-процессах есть обязательные поля.
Она выросла не из плохих разработчиков, а из реальных бизнес-процессов.
А в бизнес-процессах есть обязательные поля.
Отлично. Экспедитор приехал за товаром, кладовщик встал к терминалу — и радостно сообщил, что в накладной забыли ввести список закупленных товаров.
Никаких проблем — нужно лишь дождаться, пока в родном для экспедитора Петропавловске наступит новый рабочий день и там дозаполнят форму.А машина пока постоит на улице, экспедитор поспит в кабине.
«Данная конкретная операция» — не «нажать кнопку получения товара», а «получить товар, загрузить в машину и отправить». И банальное «донабрать недостающее» легко выливается в реальные потери.
Так что будьте ближе к реальной жизни.
Никаких проблем — нужно лишь дождаться, пока в родном для экспедитора Петропавловске наступит новый рабочий день и там дозаполнят форму.А машина пока постоит на улице, экспедитор поспит в кабине.
«Данная конкретная операция» — не «нажать кнопку получения товара», а «получить товар, загрузить в машину и отправить». И банальное «донабрать недостающее» легко выливается в реальные потери.
Так что будьте ближе к реальной жизни.
Как же люди жили до появления этой прекрасной информационной системы?
Нет, вы путаете. Я не предлагаю запускать бизнес-процессы в условиях нехватки данных. Я предлагаю лишь возможность вносить эти данные в несколько присестов (прочитайте upd #2 к посту, я там пояснил).
В вашем случае за экспедитором никто не пошлет, пока накладная не будет заполнена полностью. А вот заполнить ее можно будет или сразу целиком, или по частям, в разное время (но обязательно до запуска бизнес-процесса).
В вашем случае за экспедитором никто не пошлет, пока накладная не будет заполнена полностью. А вот заполнить ее можно будет или сразу целиком, или по частям, в разное время (но обязательно до запуска бизнес-процесса).
Идеал не вылепишь, все люди разные, у каждого свои «тараканы» в голове. Кто-то является идеальным пользователем — вводит данные во все формы ввода, кто-то заполняет лишь поля с пометкой, кто-то «левые» данные вводит, а кто-то вообще при виде такого просто отказывается от затеи. И пример, достойный подражания, про FF и Google Chrome не совсем корректен, потому как на моей памяти есть пример, как человек однажды отказался от использования этого самого «хрома» из-за того что тот его не оповещает о том, что обновляется. Так что тут надо стремиться к чему-то оптимальному, а не идеальному.
Из мерфологии «Сделай программу которой сможет пользоваться даже дурак, и только дурак станет ей пользоваться».
Так что вся статья — ерунда. Программы и есть имитации и модели мира. И обладать ограничениями, не свойственными реальному миру — их нормальное состояние.
Обязательные поля очень часто необходимы, очень часто целостность данных гораздо важнее удобства пользователя, потому что бывает программа создана не для пользователя, а для данных, и пользователь работает с ней не для своего удобства, а для данных. Пример — банковский работник, он забивает данные, которые гораздо важнее его самого.
И таких примеров куча.
Тот же Сергей Витальевич в своей тундре должен забивать правильные показания, а не «бла-бла-бла», если вдруг ему взбредет в голову. Он работает для данных, наравне с программой.
Так что вся статья — ерунда. Программы и есть имитации и модели мира. И обладать ограничениями, не свойственными реальному миру — их нормальное состояние.
Обязательные поля очень часто необходимы, очень часто целостность данных гораздо важнее удобства пользователя, потому что бывает программа создана не для пользователя, а для данных, и пользователь работает с ней не для своего удобства, а для данных. Пример — банковский работник, он забивает данные, которые гораздо важнее его самого.
И таких примеров куча.
Тот же Сергей Витальевич в своей тундре должен забивать правильные показания, а не «бла-бла-бла», если вдруг ему взбредет в голову. Он работает для данных, наравне с программой.
Про модели — в информационных системах появляется еще один фактор, несвойственный реальности как таковой — доступность информации в данный конкретный момент. Т.е. в мире у человека есть паспорт и у этого паспорта есть номер, просто речь о том, что в данный конкретный момент мы его не знаем. В этом отличие.
Необходимости обязательных полей для выполнения системой функций я не отрицаю не в коем случае. Я о требовании ввести все данные обязательно полностью и за раз — его надо убирать.
И я не предлагаю отказаться от обработки ошибок. Просто иногда (в угоду целей пользователей!) имеет смысл принимать в том числе и некорректные данные. Предположим, система видит, что счетчик не может иметь таких показаний, какие вносит Сергей Витальевич. Что она должна делать? Правильная система — а) предупредить, что не так (Сергей Витальевич проверит, тот ли вообще счетчик он осматривает, правильно ли он переписал и т.п.), б) позволить сохранить данные, если пользователь ее попросит — просто потому, что в тундре как-то несподручно разбираться, что там раньше, возможно, не так внесли, и в) по возвращении напомнить СВ или ответственному лицу, мол, у нас тут лежат некорректные данные, помнишь? — разберись, пожалуйста.
Необходимости обязательных полей для выполнения системой функций я не отрицаю не в коем случае. Я о требовании ввести все данные обязательно полностью и за раз — его надо убирать.
И я не предлагаю отказаться от обработки ошибок. Просто иногда (в угоду целей пользователей!) имеет смысл принимать в том числе и некорректные данные. Предположим, система видит, что счетчик не может иметь таких показаний, какие вносит Сергей Витальевич. Что она должна делать? Правильная система — а) предупредить, что не так (Сергей Витальевич проверит, тот ли вообще счетчик он осматривает, правильно ли он переписал и т.п.), б) позволить сохранить данные, если пользователь ее попросит — просто потому, что в тундре как-то несподручно разбираться, что там раньше, возможно, не так внесли, и в) по возвращении напомнить СВ или ответственному лицу, мол, у нас тут лежат некорректные данные, помнишь? — разберись, пожалуйста.
Нужны ли обязательные поля — зависит от следующих моментов:
1) А нужны ли вообще эти самые пользовательские данные системе?
2) Проверяются ли в дальнейшем пользовательские данные вручную?
Если на первый вопрос ответ «преимущественно нет», а на второй — «да, всегда», то обязательных полей будет столько, сколько нужно владельцу системы (именно владельцу, а не разработчику). Лучше не получить 100500 форм с ненужными данными, на проверку которых придется тратить драгоценное время.
По-моему, следует все-таки различать интерфейсные формы и формы сбора данных. Если для первых обязательные поля зло (наверное? ИМХО, все-таки далеко не всегда), то для вторых — однозначно добро. Не располагаешь полными данными — не предлагай их для обработки. Пример форм сбора данных — формы добавления сайтов в каталоги. Кому будет тепло от того, что в каталог добавлен голый URL, без заголовка и описания? Уж точно не конечным пользователям каталога.
1) А нужны ли вообще эти самые пользовательские данные системе?
2) Проверяются ли в дальнейшем пользовательские данные вручную?
Если на первый вопрос ответ «преимущественно нет», а на второй — «да, всегда», то обязательных полей будет столько, сколько нужно владельцу системы (именно владельцу, а не разработчику). Лучше не получить 100500 форм с ненужными данными, на проверку которых придется тратить драгоценное время.
По-моему, следует все-таки различать интерфейсные формы и формы сбора данных. Если для первых обязательные поля зло (наверное? ИМХО, все-таки далеко не всегда), то для вторых — однозначно добро. Не располагаешь полными данными — не предлагай их для обработки. Пример форм сбора данных — формы добавления сайтов в каталоги. Кому будет тепло от того, что в каталог добавлен голый URL, без заголовка и описания? Уж точно не конечным пользователям каталога.
На моей памяти, самым лучшим примером регистрации по-человечески был сайт Аймобилко. Не зарегестрированы или забыли как это было, попробуйте зарегестрироваться снова — у вас появится фейковый аватар, имя, фамилия и ещё какой-то набор данных, которые, по сути, не так важны для работы системы.
Автору поста — спасибо.
Автору поста — спасибо.
> Для реальной жизни характерна скорее нехватка информации, чем ее наличие.
Это вы немного лишнего взяли. Понимаю, что хотели сказать, но вышло не совсем верно.
Для реальной современной жизни как раз характерен избыток информации, это вам любой историк в контексте работы с т.н. «историческими источниками» скажет.
Это вы немного лишнего взяли. Понимаю, что хотели сказать, но вышло не совсем верно.
Для реальной современной жизни как раз характерен избыток информации, это вам любой историк в контексте работы с т.н. «историческими источниками» скажет.
Словоблудие какое-то. И так понятно что без необходимости обязательные поля лучше не делать.
5 баллов! Но, по моему скромному мнению, основная проблема предложенного подхода — это сложность изменения стереотипов Заказчика. Особенно, когда этот заказчик — государство.
Но уж если мы свободны в выборе — то только так и нужно делать!
Но уж если мы свободны в выборе — то только так и нужно делать!
Поделюсь своим опытом отказа от обязательных полей (и регистрации в целом) на упомянутом уже сайте Аймобилко.
Раньше была регистрация с фэйковыми данными, но сейчас ещё круче: регистрация не требуется вообще. Если пользователь хочет что-то купить, то мы автоматически создаём временную учётную запись и пишем «вечную» куку пользователю. В эту учётную запись складываются все покупки пользователя и остаток денег. При следующем заходе пользователь автоматом логинится и продолжает пользоваться сервисом. Причём, временные данные мы стараемся автоматически отправить пользователю: ответный СМС (при оплате СМС), детали платежа (Яндекс.Деньги), выписка на эл. почту (PayPal и пластиковые карты), показываем в явном виде при оплате через терминалы.
Тем не менее, мы хотим достучаться до наших пользователей, поэтому ненавязчиво просим их зарегистрироваться (ввести эл. адрес и пароль). Зарегистрированные пользователи получают различные спец.предложения и подарки. При регистрации просто меняется статус учётной записи (временная→постоянная), сохраняя все оставшиеся деньги и покупки.
Да, работы было очень много, да, были ошибки поначалу. Но всё это мелочи по сравнению с тем, что количество продаж на следующий день после открытия «моментальной регистрации» перманентно выросло в 2 раза (специально замеряли) и продолжает расти.
Раньше была регистрация с фэйковыми данными, но сейчас ещё круче: регистрация не требуется вообще. Если пользователь хочет что-то купить, то мы автоматически создаём временную учётную запись и пишем «вечную» куку пользователю. В эту учётную запись складываются все покупки пользователя и остаток денег. При следующем заходе пользователь автоматом логинится и продолжает пользоваться сервисом. Причём, временные данные мы стараемся автоматически отправить пользователю: ответный СМС (при оплате СМС), детали платежа (Яндекс.Деньги), выписка на эл. почту (PayPal и пластиковые карты), показываем в явном виде при оплате через терминалы.
Тем не менее, мы хотим достучаться до наших пользователей, поэтому ненавязчиво просим их зарегистрироваться (ввести эл. адрес и пароль). Зарегистрированные пользователи получают различные спец.предложения и подарки. При регистрации просто меняется статус учётной записи (временная→постоянная), сохраняя все оставшиеся деньги и покупки.
Да, работы было очень много, да, были ошибки поначалу. Но всё это мелочи по сравнению с тем, что количество продаж на следующий день после открытия «моментальной регистрации» перманентно выросло в 2 раза (специально замеряли) и продолжает расти.
как правильно заметили выше — каша.
есть поля, для которых можно забить данные по умолчанию. (город на основании geoip при регитрации, аватарка с сереньким человеком).
есть поля которые можно заполнить позже и без этого данные можно сохранить. (без заголовка статьи, статью можно сохранить, но не публиковать)
есть поля которые необходимы, а форму нельзя заполнить позже (номер кошелька куда перевести деньги).
есть поля, для которых можно забить данные по умолчанию. (город на основании geoip при регитрации, аватарка с сереньким человеком).
есть поля которые можно заполнить позже и без этого данные можно сохранить. (без заголовка статьи, статью можно сохранить, но не публиковать)
есть поля которые необходимы, а форму нельзя заполнить позже (номер кошелька куда перевести деньги).
Автор поста пишет что реальная жизнь не предсказуема и что программист не должен считать себя самым умным. Соглашаюсь на все сто. Однако, дальше в посте вы делаете как раз то, чего делать не следует: причесываете всех под одну гребенку, считая что поведение пользователей таки можно предсказать и именно вам виднее как лучше для ВСЕХ пользователей.
Меня, к примеру, раздражает имя по умолчанию в виндовс. Потому что иногда задеваешь кнопку «новая папка» в диалогах Save / Open и периодически я помогаю искать данные на компе, в котором папки на 90% имеют имена «новая папка X» :-) Я не раз пытался объяснить пользователям что «новая папка» — это дефолт, и его нужно изменить. Также как и «текстовый документ». Но народ реагирует на это по-разному: кто-то считает что это вообще единственно возможное имя для объекта, кто-то просто опасается переименовывать (мало ли что). То есть выходит, что никто не выигрывает от имени по умолчанию: малоопытный пользователь (или ленивый) оставит именно его, а опытный — в любом случае подумает и определит имя в момент создания. И какой же выигрыш пользователю от иерархии с ничего не говорящими именами?
Фоновое обновление — вот мне тоже не нравится. Мало ли по каким причинам я хочу именно текущую версию. Да и просто я привык думать за ПО, а не наоборот. Хотя бы потому, что не могу привести примера, когда выбор робота, хоть в какой-то мере был лучше (для меня) чем мой собственный. И таких пользователей довольно много, как мне кажется.
Статья в целом правильная. Думаю что по дефолту любой интерфейс должен быть заточен под чайника, а где-то в настройках иметь кнопочку «экспертный режим». Тогда всем будет счастье.
Меня, к примеру, раздражает имя по умолчанию в виндовс. Потому что иногда задеваешь кнопку «новая папка» в диалогах Save / Open и периодически я помогаю искать данные на компе, в котором папки на 90% имеют имена «новая папка X» :-) Я не раз пытался объяснить пользователям что «новая папка» — это дефолт, и его нужно изменить. Также как и «текстовый документ». Но народ реагирует на это по-разному: кто-то считает что это вообще единственно возможное имя для объекта, кто-то просто опасается переименовывать (мало ли что). То есть выходит, что никто не выигрывает от имени по умолчанию: малоопытный пользователь (или ленивый) оставит именно его, а опытный — в любом случае подумает и определит имя в момент создания. И какой же выигрыш пользователю от иерархии с ничего не говорящими именами?
Фоновое обновление — вот мне тоже не нравится. Мало ли по каким причинам я хочу именно текущую версию. Да и просто я привык думать за ПО, а не наоборот. Хотя бы потому, что не могу привести примера, когда выбор робота, хоть в какой-то мере был лучше (для меня) чем мой собственный. И таких пользователей довольно много, как мне кажется.
Статья в целом правильная. Думаю что по дефолту любой интерфейс должен быть заточен под чайника, а где-то в настройках иметь кнопочку «экспертный режим». Тогда всем будет счастье.
Основная мысль кажись у вас такая: требуйте от пользователей те и только те данные, которые вам действительно необходимы для функционирования системы.
Иначе получается, что юзеры будут давать неполные данные, из-за которых продукт не сможет нормально работать, потом скажут, что нифига не работает и продукт сырой.
Иначе получается, что юзеры будут давать неполные данные, из-за которых продукт не сможет нормально работать, потом скажут, что нифига не работает и продукт сырой.
По мнению автора следует сохранять всю информацию, которую пользователь может предоставить на данный момент, даже если не хватает чего-то крайне важного. При этом компенсировать нехватку или некорректность данных дополнительными обработками. Т.е. это не повлечет за собой появление мнений о сырости продукта. Пользователь получит информацию, по какой причине что-либо работает не так как хотелось бы и варианты решения данной проблемы.
Неплохо это сделано в ВордПрессе (который в плане кода к слову мерзок и отвратителен, а также в нем куча ненудного СЕО-хлама типа меток): можно комментировать без рег-и, введя только имя, а можно —с регистрацией.
А недовольны те, кто начал прикидывать сколько кода им придется ради такого переписать :)
Кстати, в винде создание папок все же сделано неудобно, все время случайно попадаешь по кнопке и создаются эти дурацкие папки, а вот удалить ее так просто не получится.
А недовольны те, кто начал прикидывать сколько кода им придется ради такого переписать :)
Кстати, в винде создание папок все же сделано неудобно, все время случайно попадаешь по кнопке и создаются эти дурацкие папки, а вот удалить ее так просто не получится.
Как это близко для меня! На этом же принципе строю свою CMS — внешне довольно минимальна и никаких технических терминов, а если начать рассказывать о внутреннем устройстве и скрытых фишках — и двух часов не хватит. К примеру резервное копирование всей базы данных (которая содержит не только содержание сайта, но и все шаблоны и css) каждый раз, когда заходит в админку админ (легкий юмор нечаянно получился...). Или возможность быстрого отката после редактирования страниц…
Не стоит забывать о тех случаях, когда обязательность ввода информации диктуется спецификой бизнес-процесса. Например, часто требуется обязательное комментирование вводимых фактов, и необходимость заполнения поля в данном случае не позволит свалить на программу свое нежелание думать/искать/печатать. Самой системе все равно, написал ли человек что-то или нет — эта информация исключительно описательная, но для пользователей крайне важна. Причем подойдет ведь любой человеческий комментарий. Если возникнут вопросы всегда можно попросить конкретизировать что именно там написано или объяснить причину ввода «рыбной» информации.
При этом схема с черновиками мне тоже кажется весьма удобной. Стараюсь использовать, если есть возможность.
При этом схема с черновиками мне тоже кажется весьма удобной. Стараюсь использовать, если есть возможность.
Реальность такова что пользователь обычно стоит на месте далеким от первого.
Возьмем обычный сайт. Для кого он делается? В первую очередь для себя, потом для друзей — себя показать, потом для себя в какой-то ипостаси — программиста или дизайнера. Зачастую тут появляется мотив PROFIT — а значить раскрутка и прочее. Я вообще не уверен что забота о пользователе для обычного сайта когда-нибудь появляется в списке приоритетов в обозримом месте.
Возьмем стартап. Он делается в первую очередь для продажи. То есть для инвесторов. Он конечно нуждается в абонентской базе, но не настолько что бы думать об удобствах пользователя.
И даже если взять удобство пользователя. То стабильность в работе важнее сиюминутного шока что вставить в очередное обязательное поле. И если гипотетически представить что время разработчиков фиксировано, то сайт где оно потрачено на работу с произвольными (не)введенными данными, будет заведомо хуже чем сайт где зафиксировав формат и количество данных, сделали корректную для эти форматов обработку и верстку, и дальше пошли реализовывать другие фичи.
Да и если бесит очередная форма нужно просто отдохнуть…
Возьмем обычный сайт. Для кого он делается? В первую очередь для себя, потом для друзей — себя показать, потом для себя в какой-то ипостаси — программиста или дизайнера. Зачастую тут появляется мотив PROFIT — а значить раскрутка и прочее. Я вообще не уверен что забота о пользователе для обычного сайта когда-нибудь появляется в списке приоритетов в обозримом месте.
Возьмем стартап. Он делается в первую очередь для продажи. То есть для инвесторов. Он конечно нуждается в абонентской базе, но не настолько что бы думать об удобствах пользователя.
И даже если взять удобство пользователя. То стабильность в работе важнее сиюминутного шока что вставить в очередное обязательное поле. И если гипотетически представить что время разработчиков фиксировано, то сайт где оно потрачено на работу с произвольными (не)введенными данными, будет заведомо хуже чем сайт где зафиксировав формат и количество данных, сделали корректную для эти форматов обработку и верстку, и дальше пошли реализовывать другие фичи.
Да и если бесит очередная форма нужно просто отдохнуть…
Это просто хамство ставить пользователя не на первое место.
Стабильные неудобства, ппц.
Стабильность важна лишь в той степени, в которой она не мешает выполнять задачи пользователей.
А если стабильность постоянно мешает решать эти задачи, усложняет их, то от вашей программы или сайта для друзей быстренько откажутся.
Стабильные неудобства, ппц.
Стабильность важна лишь в той степени, в которой она не мешает выполнять задачи пользователей.
А если стабильность постоянно мешает решать эти задачи, усложняет их, то от вашей программы или сайта для друзей быстренько откажутся.
Может быть. Но отрицать реальность — инфантильность :)
Нестабильный, разваливающийся от данных пользователей сайт вообще не будет иметь посетителей.
Нестабильный, разваливающийся от данных пользователей сайт вообще не будет иметь посетителей.
Я не отрицаю реальность, я говорю что это хамство. Да, программисты ставят свои интересы выше всего, в то время как интересы пользователей никто не защищает.
Но надо понимать, что для успеха нужно учитывать интересы пользователей больше, чем свои.
Стабильность и обязательность ввода никак не связаны.
Обязательный ввод — не самое удачное решение ленивого программера, пытающегося свалить вину за будущие ошибки на пользователя, которое, в силу легкости, стандарт де-факто.
Но надо понимать, что для успеха нужно учитывать интересы пользователей больше, чем свои.
Стабильность и обязательность ввода никак не связаны.
Обязательный ввод — не самое удачное решение ленивого программера, пытающегося свалить вину за будущие ошибки на пользователя, которое, в силу легкости, стандарт де-факто.
При чем тут интересы? Есть деньги на разработку и исходя из бюджета и пляшут.
Иногда связаны напрямую.
«В общем» тут говорить не о чем — я могу представлять себе каталог в котором есть куча полей, которые просто обязательны — имя для поиска, описание для релевантности, мейл для обратной связи, адрес для гео-локации. А кто-то может представить себе сайт знакомств в котором все поля — лишь форматированные метаданные.
Иногда связаны напрямую.
«В общем» тут говорить не о чем — я могу представлять себе каталог в котором есть куча полей, которые просто обязательны — имя для поиска, описание для релевантности, мейл для обратной связи, адрес для гео-локации. А кто-то может представить себе сайт знакомств в котором все поля — лишь форматированные метаданные.
В случае вашего каталога достаточно предупреждать, что эти поля нужно заполнить, но не отказываться создавать запись.
Вы говорите в общем нельзя и сами берете какой-то абстрактный каталог.
Если вы имели ввиду каталог магазинов города в программе-справочнике, представьте секретаршу, которая забивает эти магазины из какого-то распечатанного ею списка. Если у каких-то магазинов не будет указан мейл — ей придется ставить галочки на листе у себя.
Хотя она могла бы вбивать то, что есть, и затем, через время, когда она узнает эти мейлы, открыв таблицу, она бы увидела помеченные записи с недостающими данными.
Естественно, если этот каталог как-то представлялся в вебе, то неполные записи не выводились-бы.
Если вы имели ввиду каталог магазинов города в программе-справочнике, представьте секретаршу, которая забивает эти магазины из какого-то распечатанного ею списка. Если у каких-то магазинов не будет указан мейл — ей придется ставить галочки на листе у себя.
Хотя она могла бы вбивать то, что есть, и затем, через время, когда она узнает эти мейлы, открыв таблицу, она бы увидела помеченные записи с недостающими данными.
Естественно, если этот каталог как-то представлялся в вебе, то неполные записи не выводились-бы.
А платить ей зарплату кто будет?
Но я вообще-то имел в виду каталог дизайнеров интерьера. Который ищет подходящего по стилю и ближайшего по месту. Для него незаполненные поля описания и адреса являются пустым местом, то есть игнорируются и поэтому дизайнер без введенных этих полей каталогу не нужен и поэтому эти поля обязательные.
Но я вообще-то имел в виду каталог дизайнеров интерьера. Который ищет подходящего по стилю и ближайшего по месту. Для него незаполненные поля описания и адреса являются пустым местом, то есть игнорируются и поэтому дизайнер без введенных этих полей каталогу не нужен и поэтому эти поля обязательные.
Ну можно либо не выводить наполовину введенные, либо выводить с пометкой, что вскоре будут появится полная инфа.
Ведь узнать адрес без мейла лучше, чем вообще не узнать
Ведь узнать адрес без мейла лучше, чем вообще не узнать
как не выводить адрес если без него нет местоположения и нет расстояния до пользователя?
как не выводить данные о стиле, если они в основе поиска?
собственно ответ очень простой — нет записи — нет проблемы. пустая запись абсолютно эквивалентно тому что нет записи. И это надо знать вводящему данные и это делается через обязательные поля.
как не выводить данные о стиле, если они в основе поиска?
собственно ответ очень простой — нет записи — нет проблемы. пустая запись абсолютно эквивалентно тому что нет записи. И это надо знать вводящему данные и это делается через обязательные поля.
Точно так, как фри-ланс.ру выводит проекты с неуказанной ценой
В данном случае аналогия — с неуказанным описанием и скилами. Которую никто не увидит когда «проект» уйдет с ленты.
Если учесть что в каталоге нет просто списка то пустая анкета просто нигде не появиться. Ну ни нафиг страдать фигней и давать возможность делать пустую анкету?
Если учесть что в каталоге нет просто списка то пустая анкета просто нигде не появиться. Ну ни нафиг страдать фигней и давать возможность делать пустую анкету?
Ну если у вас каталог без списка, то нафиг конечно
Ну вот и пришли к консенсусу. Теперь распространяем этот «нафиг» на все остальное и получается ляпота.
На самом деле юзеру невдомек как и где нужны данные и нефиг со своим самоваром ходить по сайтам. Написано — «требуется» значить требуется.
На самом деле я встречал только один сайт где требовались ну совершенно не нужные мне и сайту, на первый взгляд, данные. Как оказалось — они потом вежливый спам шлют.
На самом деле юзеру невдомек как и где нужны данные и нефиг со своим самоваром ходить по сайтам. Написано — «требуется» значить требуется.
На самом деле я встречал только один сайт где требовались ну совершенно не нужные мне и сайту, на первый взгляд, данные. Как оказалось — они потом вежливый спам шлют.
Вот вы сами пришли к тому, что без каких-то данных какие-то функции не будут работать. Но ведь какие-то будут! Напишите прям на форме об этом, пользователь поймет, он же не тупой, пусть сам принимает решение, в конце концов он в этом лично заинтересован (иначе бы и знать не знал о вашей программе).
Ну во-первых пользователь тупой. Точнее он разный, но умный сам догадается и все сделает, а тупому сколько не говори — сделает по своему. И для таких и пишется защита от дурака. Одной из вариантов которой — требуемые поля.
Во-вторых зачастую писать что-то еще просто негде. Сообщения ужимаются до минимума, описания до слова в меню. Типс заполнены описанием формата принимаемого. Городит еще что-то всплывающее — будет совсем плохо. И все ради контента.
В-третьих конечно лень. Всем. И этим страдает куча сайтов — просто не понятно что в нем есть и чем он отличается, а подробно описать создателям лень. Но это совершенно другая история.
Во-вторых зачастую писать что-то еще просто негде. Сообщения ужимаются до минимума, описания до слова в меню. Типс заполнены описанием формата принимаемого. Городит еще что-то всплывающее — будет совсем плохо. И все ради контента.
В-третьих конечно лень. Всем. И этим страдает куча сайтов — просто не понятно что в нем есть и чем он отличается, а подробно описать создателям лень. Но это совершенно другая история.
Возьмем обычный сайт. Для кого он делается? В первую очередь для себя, потом для друзей
Ну во-первых пользователь тупой
Так чем же вы руководствуетесь?
Практикой и здравым смыслом.
А чем не нравятся две отквоченных предложения?
А чем не нравятся две отквоченных предложения?
Абсурдностью
В чем абсурдность-то?
Сайт делается для себя. Пользователь тупой. Очень логичные высказывания. Я бы даже сказал взаимодополняющие.
Сайт делается для себя. Пользователь тупой. Очень логичные высказывания. Я бы даже сказал взаимодополняющие.
Когда тебе (или ему),
Когда (ну, всё равно кому — только не мне!)
Так вы себя пользователем не считаете? Вы типа создатель?
На чужом сервисе я пользователь и легко делаю распространенные ошибки и бывает ломаю стройное представление о мире создателей сайта.
Так вы создаете под себя, считая себя тупым, или как? Разве это не странно?
Потрясающая логика! Можно еще? Чувствуете разницу между свой и чужой?
ЗЫ. Был бы я тупым пользователем я бы горы золотые имел написав кучку скриптов для сайтов…
ЗЫ. Был бы я тупым пользователем я бы горы золотые имел написав кучку скриптов для сайтов…
Как упоительно вы наслаждаетесь своей логикой.
Только не могли бы повнятнее объяснить её другим?
Все ваше объяснение пока что свелось к «нет, это не так».
Вы делаете сайт для себя, это значит что вы пользователь сайта. Но пользователь тупой. Значит вы делаете, представляя себя тупым пользователем? Или делая для себя, вы считаете себя умным, а всех, кто будет этим пользоваться тупыми? Но если вы делаете для себя, в дальнейшем вы будете это использовать, вы себя будете считать тупым, или вы-исключение? Поконкретнее, вы делаете сайты для тупых или для умных? Вероятно для умных, но все пользователи тупые, но поскольку вы будущий пользователь, вы так-же войдете в их ряды.
Простая дедукция:
Люди — смертны. Сократ — человек. Значит сократ — смертен.
Пользователи — тупые.
Вы делаете — для себя, значит вы -пользователь.…
Только не могли бы повнятнее объяснить её другим?
Все ваше объяснение пока что свелось к «нет, это не так».
Вы делаете сайт для себя, это значит что вы пользователь сайта. Но пользователь тупой. Значит вы делаете, представляя себя тупым пользователем? Или делая для себя, вы считаете себя умным, а всех, кто будет этим пользоваться тупыми? Но если вы делаете для себя, в дальнейшем вы будете это использовать, вы себя будете считать тупым, или вы-исключение? Поконкретнее, вы делаете сайты для тупых или для умных? Вероятно для умных, но все пользователи тупые, но поскольку вы будущий пользователь, вы так-же войдете в их ряды.
Простая дедукция:
Люди — смертны. Сократ — человек. Значит сократ — смертен.
Пользователи — тупые.
Вы делаете — для себя, значит вы -пользователь.…
Вы делаете банальную терминологическую ошибку. При классификации класс рангом ниже не включает вышестоящие.
Например admin — он формально и user тоже, но только в общечеловеческом смысле.
А пользователи — они все тупые, потому что не врубаются в недосказанности, очевидные создателю, но упущенные в силу банальности этих материй для создателя.
Очевидно что для своего сайта я создатель, для чужого — тупой пользователь.
Где тут место умным?
Например admin — он формально и user тоже, но только в общечеловеческом смысле.
А пользователи — они все тупые, потому что не врубаются в недосказанности, очевидные создателю, но упущенные в силу банальности этих материй для создателя.
Очевидно что для своего сайта я создатель, для чужого — тупой пользователь.
Где тут место умным?
Да никакой ошибки тут нет. Сначала вы создатель, потом пользователь, это разные сущности. «Делаю для себя» — сейчас создатель, а когда сделаю, стану пользователем.
Или под «делаю для себя» вы имеете ввиду не дальнейшее использование, а саморазвитие, получение бабла и т.п.?
Или под «делаю для себя» вы имеете ввиду не дальнейшее использование, а саморазвитие, получение бабла и т.п.?
И чего? Считать юзера тупой собачкой Павлова?
Я же говорю, есть поля, которые обязательны в силу того, что без них невозможно вообще что-либо сделать.
Меня вот поражают некоторые юзверы, а точнее потребляди, они почему-то вбили себе в голову, что мир должен крутится вокруг них, причем еще и нахаляву. И если интересы отдельных узверов идут вразрез со здравым смыслом, с принципом KISS, то такие юзверы идут куда подальше или сами реализовывать свои хотелки или платить тому, кто может их сделать.
Кстати иногда регистрацию и заполнение некоторого количества полей можно рассматривать как фильтр от всякого сброда.
Я же говорю, есть поля, которые обязательны в силу того, что без них невозможно вообще что-либо сделать.
Меня вот поражают некоторые юзверы, а точнее потребляди, они почему-то вбили себе в голову, что мир должен крутится вокруг них, причем еще и нахаляву. И если интересы отдельных узверов идут вразрез со здравым смыслом, с принципом KISS, то такие юзверы идут куда подальше или сами реализовывать свои хотелки или платить тому, кто может их сделать.
Кстати иногда регистрацию и заполнение некоторого количества полей можно рассматривать как фильтр от всякого сброда.
Вы поспокойнее, не нервничайте так.
Да, такие есть, и это не значит, что надо плясать под их дудку.
Просто есть пользователи, которые считают точно так о программистах, и таких пользователей больше. И все из-за того, что программа отражает модель её реализации, а не модель задач пользователя. Потому, что программистам удобнее создавать такую программу. Просто программистам не хватает нормальной документации, как и что должно быть. Поэтому они и делают так, как считают сами, а это часто противоречит интересам пользователей.
Да, такие есть, и это не значит, что надо плясать под их дудку.
Просто есть пользователи, которые считают точно так о программистах, и таких пользователей больше. И все из-за того, что программа отражает модель её реализации, а не модель задач пользователя. Потому, что программистам удобнее создавать такую программу. Просто программистам не хватает нормальной документации, как и что должно быть. Поэтому они и делают так, как считают сами, а это часто противоречит интересам пользователей.
А юзера не надо считать собачкой павлова. Просто делайте для своей мамы.
Естественно, когда речь о простых приложениях и сайтах.
Ну нет, мы же тут общий случай перетираем.
Ваша мама считает что развалившаяся верстка важнее произвольного ввода?
Или если требую 10 цифр телефона это нарушает какие-то гражданские свободы?
Ваша мама считает что развалившаяся верстка важнее произвольного ввода?
Или если требую 10 цифр телефона это нарушает какие-то гражданские свободы?
Развалившаяся верстка это халатность программера, а не мамина ошибка. Откуда она могла знать, что у программиста верстка на соплях.
Верстка тоже имеет свои ограничения. Так что пусть мама выбирает либо что попало вводить либо видеть нормальный сайт.
Не такие ограничения, чтобы сломаться из-за пустого/слишком большого ввода. Косячная верстка — проблема либо браузера, либо верстальщика, но никак не мамы.
Какие не такие? Я жду от пользователя 10 полей — он в ответ фиг.
И вместо красивой открытки пользователя — пустое место.
И вместо красивой открытки пользователя — пустое место.
Ой. И что?
Фразы типа «Рекомендуется написать о себе» сломают к чертям верстку, или раздражат эстетический рецептор пользователя?
Программисту вот и правда придется нелегко.
Зато если я вошел в фейсбук так просто, найти профиль человека, то за такой гостевой акк. я буду очень признателен фейсбуку.
А если вы боитесь, что спамеры и прочие будут этим злоупотреблять, то можно злоупотреблять и забивая поля фейком.
Фразы типа «Рекомендуется написать о себе» сломают к чертям верстку, или раздражат эстетический рецептор пользователя?
Программисту вот и правда придется нелегко.
Зато если я вошел в фейсбук так просто, найти профиль человека, то за такой гостевой акк. я буду очень признателен фейсбуку.
А если вы боитесь, что спамеры и прочие будут этим злоупотреблять, то можно злоупотреблять и забивая поля фейком.
Фразы типа «Рекомендуется написать о себе» сломают к чертям верстку, или раздражат эстетический рецептор пользователя?
Ну типа такого и стоит рядом с полями и маркером required. Потому и не ломается.
А фейсбук думает о пользователях и знает что ему никак без аккаунта в нем не обойтись :)
Спамеры идут лесом.
Нет. required — это требуется, а не рекомендуется.
Рекомендуется — это значит мы вам сделаем, но будем вас допекать с просьбой, а требуется — значит идите нах*й без этого, и мы даже не вспомним о вас (часто).
А по поводу фейсбука — представьте, ну нафиг там аккаунт вам/мне, если там друзей нет, к примеру. Просто проверить.
Рекомендуется — это значит мы вам сделаем, но будем вас допекать с просьбой, а требуется — значит идите нах*й без этого, и мы даже не вспомним о вас (часто).
А по поводу фейсбука — представьте, ну нафиг там аккаунт вам/мне, если там друзей нет, к примеру. Просто проверить.
То есть таки только те избранные, кому выпала честь пользоваться вашей чистейшей программой, достойны… Подумайте на секунду не о себе. Представьте себе врача, который посылает больных лесом, потому что они «неправильно заболели». Представьте себе архитектора, который сделал дверные проемы высотой в 1,5 метра, потому что «так композиция обретает красоту», и проход в из комнаты в кухню через ванную комнату, потому что сам он любит поесть, когда моется. Что было бы, а?
Будто пользователь обязан разбираться в структуре БД, где там что как должно работать, что обязательно, что нет.
Это программа должна позволять пользователю решать операции так, как ему удобно. Если она совсем не может сделать важную операцию без каких-то данных, то только в этом случае стоит об этом сообщить.
А целостность БД это не задача пользователя. Это задача программиста, который не должен эту задачу сваливать на пользователя.
Это программа должна позволять пользователю решать операции так, как ему удобно. Если она совсем не может сделать важную операцию без каких-то данных, то только в этом случае стоит об этом сообщить.
А целостность БД это не задача пользователя. Это задача программиста, который не должен эту задачу сваливать на пользователя.
как-то слишком общё что бы имело смысл
Эта фраза рушит все предыдущие рассуждения :)
Если она совсем не может сделать важную операцию без каких-то данных, то только в этом случае стоит об этом сообщить.
Эта фраза рушит все предыдущие рассуждения :)
Вам бы разрушить рассуждения.
Уведомлять о невозможности проведения операции без каких-то данных — это не значит требовать обязательный ввод. Не улавливаете разницы?
Можно предлагать взамен альтернативные варианты, но не отказываться проводить операцию. Например, запомнить о такой попытке, и восстановить её, когда недостающие данные появятся.
Уведомлять о невозможности проведения операции без каких-то данных — это не значит требовать обязательный ввод. Не улавливаете разницы?
Можно предлагать взамен альтернативные варианты, но не отказываться проводить операцию. Например, запомнить о такой попытке, и восстановить её, когда недостающие данные появятся.
Например, запомнить о такой попытке, и восстановить её, когда недостающие данные появятся.
lol
ну да, и наиболее общий случай — сказать:
— приходи как будешь готов заполнить все обязательные поля
Слишком общий, чтобы имел смысл.
В данном случае как раз наоборот :)
Нет)
Что «нет»?
Инверсия вашего утверждения
В данном случае как раз наоборот :)
инверсия будет
В общем случае именно так :(
что для вашего утверждения
Слишком общий, чтобы имел смысл.
верно, но в данном случае как раз наоборот :)
Вы инвертировали поэлементно, а не общий смысл фразы, надо инвертировать смысл:
В данном случае как раз наоборот -> В данном случае именно так.
В данном случае как раз наоборот -> В данном случае именно так.
Ну тогда неверно, так как раз в данном случае наоборот.
уже представил ваш код
может напишете и пришлете, а то лень самому писать?
Скопируйте свой предыдущий комент
не компилируется
Видимо баги :)
Видимо ваше представление не верно. Ибо такое состояние кода не типично.
В конкретных случаях как раз иногда бывает удобнее провести «неполную» операцию
Это вы маме скажите :) когда она не захочет посолить пирог
Поэтому вы требуете исчерпывающие данные при знакомстве :)
конечно. исчерпывающие данные — имя.
Вот видите, вам временно не требуется знать, чем человек занимается.
И еще стопицот его параметров, но имя — обязательно. А вы говорите что нет — мол типа потом скажет. Можно же и без имени общаться? но почему-то требуется. :)
Ну так уж и быть, разумная формальность, у образов должны быть айди.
Хотя вы всегда можете описать параметры роста, цвета глаз и пр., если не знаете имени, но видели человека. И кто-то может его узнать по вашему описанию.
Хотя вы всегда можете описать параметры роста, цвета глаз и пр., если не знаете имени, но видели человека. И кто-то может его узнать по вашему описанию.
как-то слишком общё что бы имело смысл
То, что пользователь не обязан разбираться в структуре БД — слишком общо?
Ваши аргументы уровня «и чо»
Тут должно делаться различие между типами систем и пользователей. Система ведения блогов должна быть очень простой и интуитивной. Система администрирования критических вещей (крупных узлов важных сетей, медицинского оборудования, военных систем, и много другого) должна быть надежной и стабильной. Она не обязана быть заточена под то, чтобы оператору было приятно с ней работать. ИМХО.
Я всё время делал проэкты с кучей обязательных полей и форм, но в последнем отказался от регистрации как таковой. Просто человек получает регистрацию путём наведения (да-да, именно наведения) мышкой на кнопку и всё. Всё, он получает свой ID и много данных по дэфолту, которые сможет потом изменить. Или если у кого другой подход — используем OpenID, OAuth и другие возможности современного интернета :)
Ну что, вам плюс) В общем краткое содержание главы «Психбольницы в руках пациента»)
Это способ программ быть покладистыми.
Так же будь программы более проницательными, они могли бы заполнять многие поля и автоматически.
Это способ программ быть покладистыми.
Так же будь программы более проницательными, они могли бы заполнять многие поля и автоматически.
Отличная статья. Кстати подобный подход, если можно конечно называть это подходом, я не раз встречал в разных чатах. Там имя пользователся по умолчанию вида — guest123, и ни разу не видел подобного на обычных сайтах. А что мешает сделать при регистрации всего два поля — имя (ужезаполнено) — guest123 и почта (не заполнено). Кому лень вводить имя, пусть будет «гостем». Так, кстати сделано в админке WordPress, только там имя пользователя не заполнено, пожалуй единственный минус (и то, скорее просто упущение)
И еще напоследок
> Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Это не лень. Это следование принципу KISS, который в вольном переводе звучит, как «не усложняй». А этот принцип один из основополагающих в программировании (по крайней мере в настоящем). Отход от этого принципа создает фееричные нагромождения костылей, которые потом рождают куда больше проблем, чем необходимость юзера хоть иногда отдавать отчет о своих действиях
> Ну и лень, разумеется — с точки зрения разработчика легче проверить корректность данных на этапе ввода и послать пользователя перепроверять свои данные, чем писать обработку ошибок там, где в системе эти данные будут реально использоваться.
Это не лень. Это следование принципу KISS, который в вольном переводе звучит, как «не усложняй». А этот принцип один из основополагающих в программировании (по крайней мере в настоящем). Отход от этого принципа создает фееричные нагромождения костылей, которые потом рождают куда больше проблем, чем необходимость юзера хоть иногда отдавать отчет о своих действиях
Вы какой-то странный. Вы с чем спорите? С тем, что при вводе данных часть из них может быть неизвестна? Какой отчет должен себе отдавать оператор, вбивающий список проживающих в доме, где дата рождения указана хорошо если у каждого десятого, а умный программист, следуя принципу KISS, отметил это поле на форме как обязательное?
Допустим надо сделать небольшую анкету-опрос. Чтобы отказаться от принуждения ввода здесь и сейчас надо:
1. добавить ещё как минимум одно поле состояние (на все данные в целом или на каждое обязательное).
2. сделать систему оповещения (мигать флажками на сайте) пользователю о том, что заполнено не все. 3. сделать систему напоминания (слать на почту письма, звонить в конце концов), что заполнено не всё (при этом пользователь может быть навсегда утерян, потому что он не ввёл поле с контактами).
4. привязку к пользователю (куки, регистрация или что-нить в этом духе), чтобы он мог отредактировать данные.
Таким образом вместо анкеты типа «здесь и сейчас», которая должна выполнять две с половиной функции: вывод полей для ввода (+ проверка данных) и сохранения в БД, получаем небольшого монстра.
П.С. Всегда есть обязательное поле: это кнопка (или что-нить ещё), которую нужно нажать, чтобы отправить данные.
1. добавить ещё как минимум одно поле состояние (на все данные в целом или на каждое обязательное).
2. сделать систему оповещения (мигать флажками на сайте) пользователю о том, что заполнено не все. 3. сделать систему напоминания (слать на почту письма, звонить в конце концов), что заполнено не всё (при этом пользователь может быть навсегда утерян, потому что он не ввёл поле с контактами).
4. привязку к пользователю (куки, регистрация или что-нить в этом духе), чтобы он мог отредактировать данные.
Таким образом вместо анкеты типа «здесь и сейчас», которая должна выполнять две с половиной функции: вывод полей для ввода (+ проверка данных) и сохранения в БД, получаем небольшого монстра.
П.С. Всегда есть обязательное поле: это кнопка (или что-нить ещё), которую нужно нажать, чтобы отправить данные.
Вы тут смешали немного. Зависит от того, кому заполнение этой анкеты нужно.
1. Если пользователю, то он и придет, и дозаполнит, и зарегистрируется ради такого дела. Единственное, что надо делать, это моргнуть, мол, помни, ты не все заполнил!
2. Если организации, проводящей опрос, то она должна сделать заполнение максимально простым. Меня лично в формах соцопроса больше всего раздражает (ну, может, после случая, когда спрашивают адрес и телефон), когда вопросов много и надо обязательно ответить на все. Сколько людей бросает заполнять такую, заполнив половину, хотя могли бы хотя бы эту половину отослать? То есть, опять же, все вопросы сделать необязательными.
1. Если пользователю, то он и придет, и дозаполнит, и зарегистрируется ради такого дела. Единственное, что надо делать, это моргнуть, мол, помни, ты не все заполнил!
2. Если организации, проводящей опрос, то она должна сделать заполнение максимально простым. Меня лично в формах соцопроса больше всего раздражает (ну, может, после случая, когда спрашивают адрес и телефон), когда вопросов много и надо обязательно ответить на все. Сколько людей бросает заполнять такую, заполнив половину, хотя могли бы хотя бы эту половину отослать? То есть, опять же, все вопросы сделать необязательными.
Хорошо. Есть социальный опрос. Надо узнать: пол, возраст, стаж курения. Как сделать эту анкету не по типу «здесь и сейчас»?
Вы не поняли, пусть будет по типу «здесь и сейчас», но только чтобы все три поля не требовалось заполнить обязательно. Например, не хочу я указывать возраст. Если без возраста анкета гарантировано полетит в корзину, его нужно делать обязательным. С другой стороны, такая анкета вполне сгодится для графика «стаж курения в зависимости от пола». Т.е. зависит от того, какие закономерности вы ищете. Если вы этого заранее не знаете, нужно принимать любые анкеты, в которых ну хотя бы на два вопроса отвечено.
Если в исследовании стоит задача: выяснить влияние этих трёх параметров, то мне нужны эти три параметра. Без хотя бы одного мне смысла эта анкета не предстваляет.
Все поля обязательные. И должны быть заполнены быть сразу. И чтобы реализовать ввод этих полей не за раз, то надо приложить очень много усилий. И эти усилия явно того не будут стоить.
Все поля обязательные. И должны быть заполнены быть сразу. И чтобы реализовать ввод этих полей не за раз, то надо приложить очень много усилий. И эти усилия явно того не будут стоить.
А вот ещё вопрос. Чтобы зайти на этот сайт надо ввести три обязательных поля: логин, пароль, каптча. Как по мнению собравшихся должна выглядеть эта форма, чтобы в ней не было обязательных полей?
Вход на сайт — это действие, совершенно нормально, что для действия нужны какие-то данные. Речь о формах ввода/редактирования предметной информации. В рамках этого сайта такая форма, например — это профиль, и с ним все ок, можно заполнять в любой последовательности и в любом составе.
В посте нет деления форм на какие-то категории. А там как раз говорится о
И даже наоборот делается упор на
Для удобства пользователя для входа на сайт должно быть достаточно как раз только имени. Но есть же ещё и безопасность, для этого и сделан пароль. А ещё есть каптча, которая как раз и усложняет ввод информации пользователя и без неё вход не будет выполнен. И по идее без каптчи пользователь должен прекрасно обходиться.
Как, кстати, Вы относитесь к каптче?
У меня напрашивается вывод: нельзя сделать все формы совсем без обязательных полей.
… о практически любых системах, использующих для ввода информации формы. Обязательное поле — это поле формы, без заполнения которого система не примет у вас информацию.
И даже наоборот делается упор на
Все необходимые для функционирования системы поля...
Для удобства пользователя для входа на сайт должно быть достаточно как раз только имени. Но есть же ещё и безопасность, для этого и сделан пароль. А ещё есть каптча, которая как раз и усложняет ввод информации пользователя и без неё вход не будет выполнен. И по идее без каптчи пользователь должен прекрасно обходиться.
Как, кстати, Вы относитесь к каптче?
У меня напрашивается вывод: нельзя сделать все формы совсем без обязательных полей.
Да, я там в UPD #2 уточнял потом, что именно я пытался сказать. Там речь не о вообще любых формах, а о формах ввода/редактирования/сбора информации в системе. Не могу подобрать термина адекватного, но суть в том, что логин — это немного другое, это форма запуска действия, а не сбора (что бы это ни значило) информации.
К каптче отношусь плохо, это как раз тот случай, когда часть работы (отсеивать ботов) программист переложил на пользователя. С другой стороны, при логине еще терпимо, логинимся мы редко; слава богу, что она не выскакивает при каждом комментарии.
К каптче отношусь плохо, это как раз тот случай, когда часть работы (отсеивать ботов) программист переложил на пользователя. С другой стороны, при логине еще терпимо, логинимся мы редко; слава богу, что она не выскакивает при каждом комментарии.
Как тут уже многие сказали, обязательные поля часто встречаются в ситуациях, когда они либо нужны все сразу, либо не надо вообще беспокоиться, смысл теряется. Проблема не в обязательных полях, а в их использовании. Можно сделать многоходовое заполнение, поделив его на куски. Как в платежных системах, например. Сперва регистрируешься (логин, пароль, email необходимы), затем, когда захочешь, редактируешь профиль (фио, адрес, телефон), потом привязываешь карту (номер и т.п.). Вывалить это все в кучу и сделать все поля необязательными? Мне это будет неудобно как пользователю, ибо бардак.
Развеем мифы: пол — не должен быть обязательным.
Особенно на сайте знакомств.
Ты мальчик или девочка? А я еще не определился. (с)Братва и кольцо
Ты мальчик или девочка? А я еще не определился. (с)Братва и кольцо
Из псевдонима это не понять?
13i, goodnews, fox,ASN,sasha, yahaha, номер аськи продолжать?
Хорошо. Из фамилии?
А ее же не обязательно заполнять? Или я не понял смысла этого топика.
Имхо, в зависимости от сайта есть наборы обязательных полей, и хомячек — пользователь интернет магазина может до позеленения возмущаться обязательным полем метро, но зато когда экспедиторы поедут, то доставка будет быстрее из-за удобной группировки заказов.
Не надо забывать, что администраторы сайтов — те же пользователи.
Имхо, в зависимости от сайта есть наборы обязательных полей, и хомячек — пользователь интернет магазина может до позеленения возмущаться обязательным полем метро, но зато когда экспедиторы поедут, то доставка будет быстрее из-за удобной группировки заказов.
Не надо забывать, что администраторы сайтов — те же пользователи.
да уж, откровение 21-го века
Немного не согласен с автором поста. Первым делом нужно думать о предназначении системы. Если это форум или блог — это одно. Если это промышленная система — обязательные поля имеют место быть.
Выше в сообщениях фигурировала база данных паспортного стола. Там как раз многие поля должны быть обязательными! Собственно эта база и создаётся для учёта населения! Только наличие достоверных данных позволит разобраться кто есть кто. Простой пример. Ну не было данных, записали только моё имя и фамилию. Только вот проблема, ген. директора РАО так же зовут. А если отчество ещё записали, так советского геофизика так зовут.
Ещё один пример — база данных оператора связи. Наличие в карточке клиента паспортных данных является обязательным. Конечно операторам неудобно кучу данных вводить. Только вот договор заключается с конкретным человеком и в случае проблем нужны будут паспортные данные человека. А как иначе можно будет доказать, что именно вы заключили договор, как оператор будет доказывать, что именно с вами договор был заключен? Сделали поле необязательным -> оператор забыл ввести данные. А потом попробуй доказать, что вот те самые 50 тыяч за звонок в австралию сделал именно тот человек «А я ничего не знаю, и вообще ничего никаких договоров я не заключал». Что характерно, системе абсолютно по барану есть ли эти данные или их нет. Максимум где они будут использованы — при печати договора.
Обязательные поля нужны. Главное не перебарщивать. Делайте обязательными только те поля, которые действительно необходимы либо непосредственно для системы, либо для тех, кто будет работать с системой.
Выше в сообщениях фигурировала база данных паспортного стола. Там как раз многие поля должны быть обязательными! Собственно эта база и создаётся для учёта населения! Только наличие достоверных данных позволит разобраться кто есть кто. Простой пример. Ну не было данных, записали только моё имя и фамилию. Только вот проблема, ген. директора РАО так же зовут. А если отчество ещё записали, так советского геофизика так зовут.
Ещё один пример — база данных оператора связи. Наличие в карточке клиента паспортных данных является обязательным. Конечно операторам неудобно кучу данных вводить. Только вот договор заключается с конкретным человеком и в случае проблем нужны будут паспортные данные человека. А как иначе можно будет доказать, что именно вы заключили договор, как оператор будет доказывать, что именно с вами договор был заключен? Сделали поле необязательным -> оператор забыл ввести данные. А потом попробуй доказать, что вот те самые 50 тыяч за звонок в австралию сделал именно тот человек «А я ничего не знаю, и вообще ничего никаких договоров я не заключал». Что характерно, системе абсолютно по барану есть ли эти данные или их нет. Максимум где они будут использованы — при печати договора.
Обязательные поля нужны. Главное не перебарщивать. Делайте обязательными только те поля, которые действительно необходимы либо непосредственно для системы, либо для тех, кто будет работать с системой.
Повторю то, что я написал в upd2. То, что некоторые данные нужны для выполнения некоторой бизнес-функции/операции, это естественно, это я даже не обсуждаю. Я обсуждаю способ ввода, при котором обычно требуется ввести эти данные сразу и полностью, вместо этого предлагая вводить по частям по мере доступности и промежуточные (неполные) результаты тоже хранить в БД.
Ничего, вот скоро google сделает идентификацию человека в сети по его поведению, и проблема логинов/паролей будет решена )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миф об обязательном поле