Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Они вам и О1.О3.2ОО5 напишут... А потом прийдет невразумительній багрепорт "Неправильно вводдится дата"
Это можно проконтролировать программно, причем это не сложно.
Я во всех полях с произвольным вводом делю проверки на допустимостимые символы. Пользователь получит сообщение об ошибке, в котором четко будет указано, какие символы недопустимые + они выделятся или подстветятся в поле ввода. Соответсвенно баг-репорт никогда не придет
Это конечно требует некоторых усилий, но окупается комфортом пользователей.
Здравствуйте, Кодт, Вы писали:
O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.
К>Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".
А я категорически против подстветки кнопок красным цветом.
По моим наблюдениям пользователей это бесит.
Смену цвета поля ввода они понимают, а вот смену цвета кнопок почему-то нет.
Зато многим пользователям понравилась другая вешь:
+ валидация "на лету"
+ анимированный признак успешной валидации всех полей окна
+ (иногда для сложно проверяемых данных) кнопка "Проверить".
Анимашку можно разместить и на кнопке ОК, кстати.
Вырабатывается рефлекс не нажимать на ОК пока анимация не появится, и, юзеры перестают бояться появления ошибок после нажатия.
Т.е. пользователь чувствует комфорт
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>А вы сообщите типом, "Ошибка во вводе цены", а несчастный юзер никогда не догадается, что гривны и копейки надо разделять точкой.
Да неправда!!! Надо тщательнее проверять.
YKU>Вообще, ИМХО чем меньше "Пользователь может вводить в поля все что хочет", тем лучше.
Зависит от типа софта. Для авиадиспетчера это скорее всего так, а для писателя или журналиста с текстовым редактором — сомневаюсь.
YKU>Под "оператором" я понимаю пользователя, который профессионально исспользует программу.
Какую программу? Вот в чем вопрос. Для профи (который вбивает постоянно большие объемы информации) ИМХО лучше дать горячие клавиши и ппрочие клавиатурные фичи. Кстати, как показал опыт, для такого профи "хитрая" валидация гораздо больше подходит, чем простой заперт.
Сразу же скажу, что со всеми принципами согласен, более того, сам использовал такой подход в последнем проекте (кроме использования тултипов, не довел до ума )...
теперь по делу: поправочка к основным принипам: если идет речь об умном пользователе и именно о том, для кого собственно и создавался диалог, то да, вся идеология верна, пользователь умный и знает в каком формате вводить даты и что в рубле сто копеек, и что некоторые поля обязательны для ввода, который вводит в элементы ввода информации уже просто вслепую, короче, идеальный случай, к сожалению, мало встречающийся в наший природных условиях, не приспособленных для проживания таких индивидуумов..
Сразу же оговорюсь, речь не идет об использовании очевидных контролов для ввода даты, согласен с тем, что имея локаль, я могу программно проконтролировать ввод даты еще даже на этапе ввода цифр, это все тривиально и давно пережевано, имеется куча прекрасных контролов, библиотек, речь же пойдет об использовании уникальных текстовых выражений, обработать которую требуется нашему уважаемому пользователю П.
На практике же часто видим такое, бабушка или только еще девочка села за мощный такой компьютер с плоским монитором ну там все дела, видит диалог к примеру для ввода наименования адреса, причем в формате для пенсионного фонда, т.е. страна, область, город, улица, дом, корпус, квартира, литеры там всякие ну и так далее с соотвествующими требованиями, т.е. префикс Г, УЛ, ОБЛ и пр.
Короче, есть вариант использования единого текствого поля, где П собственно и будет вводить адрес, сами понимаете, формат записи, сама последовательность ввода, должен быть у П в голове, в принципе на практике, набрав ...цать раз, пользователь запомнит порядок ну и будет вводить, каждый раз с диким ужасом попадания курсора в такое поле...
Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр., возникает необходимость перемещения по tab по данным текстовым полям, зато отпадает необходимость при формировании полной строки адреса вводить вручную префиксы и запятые, опять таки последовательность формирования строго проконтролирована программным средством... В данном случае пользователь уже не обязан помнить формат записи, контроль мы отдали целиком программе...Более того, разделив формат записи, я могу повесить контекстные меню для выбора страны, области, города и пр., соответственно , получу префиксы из справочников и пр.служебную информацию, опять таки дальнейшее сообщение о результатах валидации ввода будет относится к конретному полю и будет четко указывать, что ошибка произошла конкретно на этапе ввода скажем наименования города...
Как мне кажется, второй вариант очевиднее, есть нагрузка на перемещение между контролами, но зато нет необходимости П помнить о формате строки, порядке, прексах, некоторых служебных записях и пр.
Вообщем, данный пример с такой строкой определенного формата был приведен с целью продемонстрировать некую аналогию между использованием масок, контролов с ненавязчивой валидацией, что надо искать некую золотую середину, нельзя всю ответственность за ввод возлагать на П...Можно привезти некие другие примеры, например, из области машиностроения, к примеру, ввода метизов, технических характеристик — еще раз поясню, я рассматриваю ту ситуацию, когда вводом самой информации занимается оператор, не имеющий представления о таких характеристиках, для которого название метиза и формат записи [Тип метиза диаметрХдлинаХПрочее Материал] неизвестны, а типов такого рода информации для ввода может быть очень много даже в пределах одного документа и зачастую оператор даже представления не имеет, что он заносит...(почему и солидарен с yorick-ом насчет необходимости использования в некоторых случаю маски ввода, например, денежные суммы, запретив П к примеру вводить баснословные ссумы для переводов уже на этапе самого ввода, еще до проведения валидации...)
ps: в предыдущем проекте использовал контролы, базовым контролом для всех текстовых полей имел следующие свойства:
DataType — D|C|N|L — тип вводимой информации
FirstUpper — true|false — как бы не ввел пользователь информацию, например, "смиРнОв", на выходе будет "Смирнов"
AllUpper — true|false — аналогично...
AllLower — true|false —
NotNull — true|false — Значение должно быть не пустым
Check — true|false — проверять сразу при вводе или же при сохранении формы...
CheckNow — true|false — проверять контрол???
ну и некоторые другие, сейчас даже и не припомню, как там реализовано...вообщем, если контрол помечен Check = true — то проверка ввода будет осущесвляться,
если CheckNow = true, то проверка будет осущесвлятиься при выходе из контрола, иначе при обработке события Click у кнопки Ok|Сохранить...
Соотвественно, при размещении контролов на диалоге я разделял контролы на те, которые необходимо проверять, а также на те, правильный ввод в которые обеспечивал дальнейший правильный ввод в другие контролы, т.е. не разрешал выходить из такого контрола (CheckNow) — так как видел прямую зависимость в поведении валидации в других контролах, например, из предыдущего примера, дата счета к примеру введена в текущем месяц, период, за который проведена оплата, не может быть позже чем два месяца назад ну и не позднее текущего...
pps: вообщем, я за то, чтобы не использовать некие идеи как нечто такое, от чего нельзя отступаться, при реализации конкретной задачи нужно использовать различные подходы...
Здравствуйте, nzeemin, Вы писали:
N>Неверно. Для способа валидации, который я описал, достаточно ловить события изменения значений валидируемых полей (TextChanged или ValueChanged).
Я тут имел в виду что надо делать проверку только тогда когда значение поля введено польность, а не частично. Например допустимое значени для поля от 50 до 150. Пользователь ввел цифру 6 и в Вашем случае поле подсветится красным (ибо прийдет сообщение и будет сделана процедура валидации), хотя юзер еще не закончил ввод. ИМХО это может сконфузить юзера, хотя у более продвинутого юзера это осложнений не вызовет.
Вторая проблема этого подхода, это то, что анализ ввода может быть сложнее, чем просто проверка на диапазон. Например проверка валидности урла или емейла с помощью регекспов. В этом случае будет слишком затратно при вводе каждого символа проверять валидность. Поэтому нужно отслеживать когда ввод закончен, то есть нажат ентер, произошла смена фокуса и т.д. В некоторых случаях это сделать просто --- например когда используются гриды, но обычно это совсем не тривиальная задача.
N>Да, вопрос с длительной валидацией иногда возникает. В этом плане придерживаюсь правила: быстрая валидация (в том числе — зависимость полей) делается по изменениям значений, медленная валидация (а это обычно обращения к БД) — по нажатию ОК, и только после удачной проверки валидности быстрой валидации. Только одно маленькое но. Когда есть быстрая валидация и она успешно прошла, пользователь будет очень разочарован когда получит бяку при нажатии ОК. Ну не люблю я мешать разные стили поведения. Хотя допускаю, что в большинстве случаев все будет хорошо. Видимо мне просто тупые пользователи попадались.
CVL>>Есть еще один случай когда рантаймовскую валидацию использовать не следует. А имеено, когда диапазон вводимых значений зависит от значения введенного в другое поле. В этом случае, пользователь может увидеть знаки что все плохо, когда он еще не польностью ввел значения, что в свою очередь может пользователя заканфузить.
N>Не согласен. Когда возникает вопрос — "почему неверно?" — пользователь наводить мышь на поле, читает тултип и понимает в чем зависимость между полями. Сложные/неочевидные зависимости лучше еще описать в виде отдельного Label справа/снизу от поля.
Вот мой пример. Есть такие параметры: диаметр трубы, тип диафрагмы, размер диафрагмы, тип среды,... и максимальное давление. Так вот, разрешенный диапазон последнего параметра зависит от предыдущих. Когда параметры вводятся впервый раз все хорошо, но вот когда их меняют (это делается как минимум два раза в год (переход лето-зима), а иногда могут меняться каждый день, когда пьянные техники то гайку не довернут, то не ту систему сделают) не в логическом порядке, а в алфавитном или еще каком (как техники запишут их на бумагу, так пользователь и вводят). А проверки тут нужны поскольку техники параметры пишут в удобных для них единицах, то напишут в сантиметрах, то в милиметрах, то испльзуют кило(мега)паскали, а иногда атмосферы. А глупый юзер разницу знает, то не всегда вводит правильно.
Как прикажете кратко описать зависимоть между полями? Вот поэтому я делаю проверку только когда пользователь нажимает ОК и сообщаю что при остальных парметрах этот должен быть в таком диапазоне.
ЗЫ Я приветствую рантаймовскую валидацию, но иногда существуют исключения.
... << RSDN@Home 1.1.4 beta 7 rev. 501>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, nzeemin, Вы писали:
N>Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается.
Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.
Здравствуйте, olegkr, Вы писали:
O>Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.
Это лишние шевеления, которые сбивают с текущих действий, отвлекают.
Лучше показать сомостоятельно какое-либо сообщение, тот же тултип, но без вмешательства пользователя.
Только очень тяжело, а часто и невозможно, предсказать момент для такого автоматического показа.
Поэтому еще раз укажу на свой вариант решения — Re[3]: Ненавязчивая валидация
Здравствуйте, kavlad, Вы писали:
K>Это лишние шевеления, которые сбивают с текущих действий, отвлекают.
Это для того случая, если пользователю непонятно почему кнопку нажать нельзя, вместо вываливающегося окошка по нажатию кнопки.
K>Поэтому еще раз укажу на свой вариант решения — Re[3]: Ненавязчивая валидация
Не люблю ни подсвеченные, ни анимированные кнопки. А для индикации того, что все данные правильно введены, больше склоняюсь к вываливающемуся balloon-у.
S>Ну, на самом деле, вводить дату вполне удобно. Человек, привыкший к данному UI, набивает 7/5 почти с той же скоростью, что и 0705. Обрати внимание на то, что ведущие нули при таком вводе не нужны. Формат даты бывает разным только у плохо сломанных пиратских программ — в штатах, я тебя уверяю, обо всех этих вариантах и не слышали никогда. Для них просто 5 — это пятое число текущего месяца. 5/7 — это седьмое мая текущего года. 5/7/6 — это седьмое мая 2006. Все. Контрол должен это понимать — и все будет в порядке. Именно так ведет себя Excel.
Это относится в первую очередь к специализированным приложениям — скажем, к бухгалтерским программам, где пользователь (он же — оператор) вводит большое количество однотипных или связанных друг с дргом данных. В приложениях общего пользования с такими мелочами уже проблемы. Про дату не скажу, но я до сих пор не знаю, что я вляется разделителем дробей в MS Word и Photoshop'е — точка, запятая, или эти данные берутся из локали?
Здравствуйте, nzeemin, Вы писали:
N>Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…
[skip]
По прочтении сразу вспомнил .NET-овский ErrorProvider. Как ты к нему относишься?
ИМХО изменение цвета контрола — не лучшее решение. Хотя бы потому, что совсем неочевидно, что подсвеченный контрол что-то скажет при наведении мышки. К тому же при наведение на контрол я получу tooltip независимо от того, нужен он мне или нет. Наличие какого-то специального контрола, ассоцированного (и ассоцируемого) с валидируемым контролом было бы лучшим решением. Так, например, сделаны примечания в Excel (по крайней мере в версии 2003). Другой пример — иконка ErrorProvider'а. Единственное что бы я изменил, это сделал бы контрол, показывющий подсказку, в виде кнопки, что бы было сразу понятно, что оно нажимаемо Я думаю это поможет сократить время обучения персонала, что к стати критично в связи с большой текучестью кадров среди всякого рода операторов.
Здравствуйте, <Аноним>, Вы писали:
А>По прочтении сразу вспомнил .NET-овский ErrorProvider. Как ты к нему относишься?
Нормально отношусь. Хороший способ подсветки. Но сам его не использовал — по той причине что дотнетовый способ валидации "в целом" мне не понравился... Единственное замечание к ErrorProvider — при его использовании придется учитывать возможность его появления в дизайне диалога. Например, тот способ ввода даты что я предлагал — придется кнопку пикера относить дальше от TextBox — по той причине что сразу за текстбоксом может появиться ярлычок ошибки.
Здравствуйте, nzeemin, Вы писали:
N>Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…
N>Единственное замечание к ErrorProvider — при его использовании придется учитывать возможность его появления в дизайне диалога. Например, тот способ ввода даты что я предлагал — придется кнопку пикера относить дальше от TextBox — по той причине что сразу за текстбоксом может появиться ярлычок ошибки.
Дык надо одним контролом просто делать поле ввода и кнопку.
Здравствуйте, Mamut, Вы писали: M>Это относится в первую очередь к специализированным приложениям — скажем, к бухгалтерским программам, где пользователь (он же — оператор) вводит большое количество однотипных или связанных друг с дргом данных. В приложениях общего пользования с такими мелочами уже проблемы. Про дату не скажу, но я до сих пор не знаю, что я вляется разделителем дробей в MS Word и Photoshop'е — точка, запятая, или эти данные берутся из локали?
Еще раз — это твое незнание — не твоя проблема. Это проблема криворуких русификаторов и пиратов, которые не читали рекомендаций. Я тебя уверяю — для американского пользователя Photoshop таких вопросов даже не возникает.
А нормальное приложение, спроектированное с учетом особенностей Российского рынка IT, должно вообще понимать в качестве десятичного разделителя и точку, и запятую. Благо обычно понять, где целое, а где дробное — особого ума не надо.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, nzeemin, Вы писали:
N>>Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается.
O>Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.
то есть вместо простого м очевидного нажатия на кнопку, ты предлагаешь догадаться, что на серую кнопку надо навести мышку и подождать? Ни один пользователь этот квест не решит. Кроме того, даже знающий фишку пользователь вместо молниеносного появления поясняющей надписи вынужден тормозиться на hint pause, затаив мышку... Имхо — отвратительное решение.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DuШes, Вы писали: DШ>Сразу же скажу, что со всеми принципами согласен, более того, сам использовал такой подход в последнем проекте (кроме использования тултипов, не довел до ума )...
DШ>Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр., DШ>Как мне кажется, второй вариант очевиднее, есть нагрузка на перемещение между контролами, но зато нет необходимости П помнить о формате строки, порядке, прексах, некоторых служебных записях и пр.
Все это, конечно, хорошо. Но вот, допустим, у пользователя есть другое какое-то место, где этот адрес написан одним блоком текста. Причем разделителями частей адреса могут быть пробелы, табы, запятые, точки с запятой, и даже переводы строки. И все вперемешку. Если бы у нас было текстовое поле "полный адрес", то пользователь бы тупо нажал "Ctrl+C", встал бы в него, и адрес оказался бы в системе. Три нажатия клавиш! Для твоего варианта надо как минимум 15.
Вот, к примеру Outlook не требует вводить имя контакта по частям. Он более-менее режет его на части самостоятельно. Проблемы в русской локали, конечно, есть, т.к. у нас немного другие правила образования имен. А локализацию, похоже, делали намного менее компетентные люди, чем оригинал. Но идея сохраняется. Та же фигня с номером телефона. Outlook при вводе успешно выделяет код страны; таблицы кодов городов у него нет (а зря), но скобки в номере он трактует правильно.
DШ>Можно привезти некие другие примеры, например, из области машиностроения, к примеру, ввода метизов, технических характеристик — еще раз поясню, я рассматриваю ту ситуацию, когда вводом самой информации занимается оператор, не имеющий представления о таких характеристиках, для которого название метиза и формат записи [Тип метиза диаметрХдлинаХПрочее Материал] неизвестны, а типов такого рода информации для ввода может быть очень много даже в пределах одного документа и зачастую оператор даже представления не имеет, что он заносит...(почему и солидарен с yorick-ом насчет необходимости использования в некоторых случаю маски ввода, например, денежные суммы, запретив П к примеру вводить баснословные ссумы для переводов уже на этапе самого ввода, еще до проведения валидации...)
Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...
DШ>pps: вообщем, я за то, чтобы не использовать некие идеи как нечто такое, от чего нельзя отступаться, при реализации конкретной задачи нужно использовать различные подходы...
Это, конечно, хорошо. Тут ты прав. Но я все чаще убеждаюсь в том, что если мне непонятно, как применить некий устоявшийся принцип к решению моей задачи — это исключительно от моей же некомпетентности. Спустя какое-то время я понимаю, что ломился не в ту дверь
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>А нормальное приложение, спроектированное с учетом особенностей Российского рынка IT, должно вообще понимать в качестве десятичного разделителя и точку, и запятую.
Как это делает, если я не ошибаюсь, 1C. Вообще, ИМХО, у них в этом плане есть чему поучиться.
Здравствуйте, yoriсk.kiev.ua, Вы писали: YKU>Вот этого вообще не понимаю. Получаем "01.02.03". И что мы будем делать с этой датой? Опять же, проверять, не вписал ли он 01-10-01 или 01/01/01 и рассказывать, что это ошибка?
Поэкспериментируй в этом плане с Excel. Будешь приятно удивлен. Только поставь формат "дата", чтоб было видно, когда он может, а когда не может отпарсить ввод. YKU>А ведь пользователи — люди крейне изобретательный. Они вам и О1.О3.2ОО5 напишут...
Не надо считать пользователей врагами. Пиши нормальный софт, и они будут тебя любить. В конце концов, если такие ситуации часто встречаются, то я не вижу проблемы трактовать в поле даты буквы О в латинице и кириллице как нули. А буквы I и l — как единицы. Даже букву B можно считать восьмеркой. Почему? Да потому, что в это поле может писать не пользователь — вредитель, а, к примеру, OCR программа. Так что вместо 01.03.2005 может и ОЮЗ.2ООS получиться. Тем не менее, зная, что это именно дата, можно сделать много полезного. YKU>Не, я за то, чтоб чем меньше свободы во вводе, тем лучше.
Любить пользователей — тяжелая и неприятная работа. Если ты не можешь ее выполнять — доверь другому. А сам пиши процедурки на SQL, веб сервисы и MPEG-компрессоры
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Еще раз — это твое незнание — не твоя проблема. Это проблема криворуких русификаторов и пиратов, которые не читали рекомендаций. Я тебя уверяю — для американского пользователя Photoshop таких вопросов даже не возникает.
Это не проблема криворуких русификаторов, а их заслуга (носорог близорук, но при его массе это не его проблема).
S>А нормальное приложение, спроектированное с учетом особенностей Российского рынка IT, должно вообще понимать в качестве десятичного разделителя и точку, и запятую. Благо обычно понять, где целое, а где дробное — особого ума не надо.
Дак его же надо ещё спроектировать!... У американского пользователя фотошопа нет вопросов, потому что дефолтная локаль совпадает с американской.
)...
Только одно маленькое но. Когда есть быстрая валидация и она успешно прошла, пользователь будет очень разочарован когда получит бяку при нажатии ОК. Ну не люблю я мешать разные стили поведения. Хотя допускаю, что в большинстве случаев все будет хорошо. Видимо мне просто тупые пользователи попадались.
Перекуём баги на фичи!
