Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…


Проблема: диалоги и валидация. Диалоги, или точнее, диалоговые окна, в настоящее время используются в интерфейсе большинства программ. С диалогами связана одна проблема, имеющая отношение к тому что называют ненашим словом «юзабилити».
Пользователь вводит несколько параметров и подтверждает выполнение команды нажатием кнопки (обычно — кнопки ОК). На вводимые значения накладываются ограничения. В простейшем случае одно из полей должно быть непустым, в других случаях правильность (валидность) значения определяется по сложной формуле или зависит от значений других полей. Процесс проверки введенных значений на правильность будем называть валидацией.

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

Итак, существующий способ валидации по крайней мере неудобен.

Неудачное решение: ограничение ввода. Иногда данную проблему решают за счет более жестких ограничений при вводе. Например, если в поле вводится число, то все неподходящие символы вообще не вводятся. Для жестко форматированных значений (телефонные номера, почтовые индексы, номера счетов) используется MaskEditControl, который не позволит ввести текст никак иначе кроме как по заданной маске.

Такой подход мне не совсем не нравится — по той причине, что он по сути «замалчивает» проблему — вместо сообщения об ошибке пользователь теперь получает неприятный звук при нажатии «не той» клавиши. А это означает, что снижается само-описательность системы, и как следствие — возможность само-обучения для пользователя.
Единственное что я приемлю в качестве ограничения — ограничение по длине в текстовых полях: ввел текст максимальной длины — не можешь больше вводить. И то только потому что другие решения были бы еще хуже — например, сообщение «вы ввели на 17 символов больше чем допустимо в этом поле»…

Решение: ненавязчивая валидация. Работая над очередным приложением (под VB.NET, несколько лет назад), я пришел к мысли, что с валидацией нужно что-то менять. Основная идея заключалась в том, чтобы отказаться от окон сообщений. Но чем их заменить? Можно было бы снабдить каждый диалог строкой подсказки (status bar), но это изменит стандартный облик диалога и не решит всех проблем.

Другая мысль была в том, чтобы подсвечивать поля, содержащие неправильные значения — например, сменой фона контролов со стандартного на какой-либо другой. Оставалось решить как показывать сообщения. Рассмотрев несколько вариантов, в конце концов я остановился на тултипах (tooltips).

В общем, последние несколько лет я придерживаюсь такой идеологии валидации:
1. Пользователь может вводить в поля все что хочет.
2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения в поле. Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений.
5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.

Здравствуйте, nzeemin, Вы писали:

N>1. Пользователь может вводить в поля все что хочет.

Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

Здравствуйте, nzeemin, Вы писали:

N>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Здравствуйте, olegkr, Вы писали:

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".
Задисабленная кнопка ОК создаёт впечатление неряшливого разработчика — как будто он взял шаблон другого диалога, а функцию ОК отключил.

Здравствуйте, olegkr, Вы писали:

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Да-да, сначала я тоже так думал. И запрещал эту кнопку, пока пользователь не заполнит все поля как надо. Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается. Действительно, здесь нужно установить связь между кнопкой ОК и подсвеченными полями. Если кнопка разрешена — пользователь нажимает ее и видит поясняющее сообщение — после этого ему становится легче установить эту связь. Программа становится более "self-described"...

Здравствуйте, yoriсk.kiev.ua, Вы писали:

N>>1. Пользователь может вводить в поля все что хочет.

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

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

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

Здравствуйте, Кодт, Вы писали:

O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

К>Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".
К>Задисабленная кнопка ОК создаёт впечатление неряшливого разработчика — как будто он взял шаблон другого диалога, а функцию ОК отключил.

Вообще — мысль неплохая...
Есть еще некоторая проблема с TabControl — когда невалидные контролы находятся на других вкладках. В этом случае неплохо было бы подсвечивать соответствующие заголовки вкладок.

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, nzeemin, Вы писали:

N>>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.


1) Вы заменили "неприятный звук при нажатии «не той» клавиши" на ее подсвечивание. Не клавиши, разумеется, поля 8))
2) Вы заменили MaskEdit(большим достоинством которого я считаю возможность сразу понять требуемый формат ввода(для пользователя, который редко пользхуется формой) и ненужность вручную писать сепараторы и пр. служебные символы — для оператора — ну зачем ему, к примеру, вставлять слеши в дате?) на что-то, что неопытному пользователю расскажет об ошибке когда-нибуть потом(а до этого он, что, догадываться должен, что в нашей форме год надо обозначать двумя цифрами?) а от оператора требует дополнительного ввода(что увеличивает возможность ошибки да и просто снижает его производительность).


В чем выигрыш?

Кроме того, ошибки ввода неопытному пользователю не всегда видны. Маскедит не даст поставить лишний пробел, не позволит написать сумму прописью, написать копейки через запятую. А вы сообщите типом, "Ошибка во вводе цены", а несчастный юзер никогда не догадается, что гривны и копейки надо разделять точкой.

Вообще, ИМХО чем меньше "Пользователь может вводить в поля все что хочет", тем лучше.


Под "оператором" я понимаю пользователя, который профессионально исспользует программу.

Здравствуйте, nzeemin, Вы писали:

N>Мне нравится, когда приложение (в ненавязчивой форме) само дает мне понять как с ним работать, но при этом не держит меня в жестких рамках. Например, дату можно вводить (а также — копировать из других приложений) в форматах ДД.ММ.ГГГГ или ДД.ММ.ГГ или ДД.ММ (сокращение для даты текущего года). В моем подходе это легко реализуется, в вашем — вы ограничены только одним форматом.

Вот этого вообще не понимаю. Получаем "01.02.03". И что мы будем делать с этой датой? Опять же, проверять, не вписал ли он 01-10-01 или 01/01/01 и рассказывать, что это ошибка?

А ведь пользователи — люди крейне изобретательный. Они вам и О1.О3.2ОО5 напишут... А потом прийдет невразумительній багрепорт "Неправильно вводдится дата" :super: :maniac:

Не, я за то, чтоб чем меньше свободы во вводе, тем лучше.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Здравствуйте, nzeemin, Вы писали:

N>>1. Пользователь может вводить в поля все что хочет.

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, nzeemin, Вы писали:

N>>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.
На то есть пару причин. Первая -- неоправданная сложность кода --- необходимо обрабатывать сообщения об изменении полей пользователем, то есть нажатия enter, смену фокуса и пр...
ВО-вторых, иногда процесс проверки валидности поля очень длительный, например ввод хоста и проверки его доступности или какие нибудь сложные математические расчеты. Поэтому иногда удобнее делать валидацию только по нажатию кноки ОК.
Есть еще один случай когда рантаймовскую валидацию использовать не следует. А имеено, когда диапазон вводимых значений зависит от значения введенного в другое поле. В этом случае, пользователь может увидеть знаки что все плохо, когда он еще не польностью ввел значения, что в свою очередь может пользователя заканфузить.

Здравствуйте, nzeemin, Вы писали:

N>6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

Небольшое дополнение — иллюстрация того как выглядит выбор даты (здесь показан ввод неверного значения, нажатие пикера и выбор даты из пикера):



Конечно, надпись на тултипе надо сделать подробнее. Например: "Неверная дата. Используйте формат ДД.ММ.ГГГГ или ДД.ММ.ГГ."

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

Более того! Если это правильный maskEdit, то разделители и вводить не надо! Юзер вводит только цифирки и все. Экономия времени и нервов пользователя.

Здравствуйте, nzeemin, Вы писали:

Спасибо за поднятую тему

N>В общем, последние несколько лет я придерживаюсь такой идеологии валидации:
N>1. Пользователь может вводить в поля все что хочет.
N>2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения в поле. Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
N>3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
N>4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений.
N>5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
N>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
N>6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

N>До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.

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

Я бы добавил к вашему набору правил следующее:
1. В сообщении по кнопке OK можно выдавать список невалидных полей с указаниями, что нужно исправить. Если пользователю это не нужно — он просто проигнорирует текст и пойдёт сразу на форму исправлять ошибки. Если нужно — внимательно посмотрит и разберётся в чём дело.
2. Я не совсем понял, в какой момент у вас возникает тултип, но ИМХО лучше, если он возникает либо на mouseover, либо на setfocus на контрол. Иначе висящие тултипы могут загораживать часть других полей ввода. Кстати, по поводу информации в тултипе: при его всплывании, а не постоянном висении, в него можно поместить достаточно много информации, необходимой и достаточной для исправления некорректно введённых данных в этом конкретном контроле, вплоть до предоставления списка валидных значений и т.п.
3. Дату лучше вводить в формате текущей локали. Это универсальнее и однозначнее. Пользователи привыкают очень быстро. Кстати, для ввода даты можно использовать и маску (к сожалению на вебе сделать это получается довольно накладно). На вопрос "а что делать,если один пользователь русский, а второй — датчанин" ответ простой — датчанину — датскую локаль, русскому — русскую.
4. Использование масок отвергать не стоит. Например, при инсталляции Windows запрашивает код в 5 (!) полях ввода, вместо того, чтобы сделать одно поле с маской. Я частенько нехорошо выражался, когда делал ошибку в середине ввода и пытался клавигами вернуться в нужное место. А могло бы быть так легко... Мне кажется, что ввод по маске не удобен в том случае, когда они плохо реализован. Вот, например, в Delphi очень неплохой ввод по маске.
5. Ну и последнее — при поточном вводе тормозить пользователя и не пускать его на следующие контролы, если есть ошибки в редактируемом, ИМХО не очень хорошо, поскольку быстрые операторы вводят данные на автомате и торможение на одном контроле оператор замечает далеко не сразу. К тому же это сильно сбивает. Достаточно подсветки. Насколько я понимаю — у вас именно так предусмотрено поведение контрола при потере фокуса?

Кстати, не могли бы вы прояснить следующую фразу:

Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.

Имеется ввиду специальное место на форме, одновременно всплывающие тултипы или ещё что-то?

Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):

Здравствуйте, CiViLiS, Вы писали:

CVL>Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>>Здравствуйте, nzeemin, Вы писали:

N>>>1. Пользователь может вводить в поля все что хочет.

YKU>>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
CVL>Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

Вам попался плохой вариант ввода по маске... Хороший MaskEdit должен уметь нормально делать вставку из буфера, правильно размазывая вставляемое значение по маске, позволяет достаточно свободно редактировать поле и уж точно должен позволять делать Overwrite вместо Insert... Вот в Delphi компонент TMaskEdit всё это нормально умеет...

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, CiViLiS, Вы писали:

CVL>>Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>>>Здравствуйте, nzeemin, Вы писали:

N>>>>1. Пользователь может вводить в поля все что хочет.

YKU>>>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
CVL>>Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

S>Вот в Delphi компонент TMaskEdit всё это нормально умеет...
Вот он меня больше всего и раздражал. Хотя может со времен пятой дельфи что и изменилось. Я привык вводить все необходимые точки, запятые и прочее. Любое ограничение при вводе для меня зло. Хотя, если не сложно, сделайте и расшарте тестовый пример с различными типами ввода (дата, шестнадцатиричное число, вещественное число с ограничением дробной части и без, ввод числа из диапозона не кратного 10 и т.д.) Я попытаюсь найти случаии когда само редактирование поля может вызваться затруднения с моей стороны

ЗЫ Я за то, чтобы формат текста был в описании поля.
ЗЗЫ А где у нас Зверек, что то он молчит по этому поводу. Желаю знать мнение эксперта

Здравствуйте, CiViLiS, Вы писали:

O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.
CVL>На то есть пару причин. Первая -- неоправданная сложность кода --- необходимо обрабатывать сообщения об изменении полей пользователем, то есть нажатия enter, смену фокуса и пр...

Неверно. Для способа валидации, который я описал, достаточно ловить события изменения значений валидируемых полей (TextChanged или ValueChanged). Изменилось значение — пересчитывается валидация диалога. Нажатия Enter, смену фокуса — ловить совершенно не нужно.

CVL>ВО-вторых, иногда процесс проверки валидности поля очень длительный, например ввод хоста и проверки его доступности или какие нибудь сложные математические расчеты. Поэтому иногда удобнее делать валидацию только по нажатию кноки ОК.

Да, вопрос с длительной валидацией иногда возникает. В этом плане придерживаюсь правила: быстрая валидация (в том числе — зависимость полей) делается по изменениям значений, медленная валидация (а это обычно обращения к БД) — по нажатию ОК, и только после удачной проверки валидности быстрой валидации.

CVL>Есть еще один случай когда рантаймовскую валидацию использовать не следует. А имеено, когда диапазон вводимых значений зависит от значения введенного в другое поле. В этом случае, пользователь может увидеть знаки что все плохо, когда он еще не польностью ввел значения, что в свою очередь может пользователя заканфузить.

Не согласен. Когда возникает вопрос — "почему неверно?" — пользователь наводить мышь на поле, читает тултип и понимает в чем зависимость между полями. Сложные/неочевидные зависимости лучше еще описать в виде отдельного Label справа/снизу от поля.

Здравствуйте, Spidola, Вы писали:

S>1. В сообщении по кнопке OK можно выдавать список невалидных полей с указаниями, что нужно исправить. Если пользователю это не нужно — он просто проигнорирует текст и пойдёт сразу на форму исправлять ошибки. Если нужно — внимательно посмотрит и разберётся в чём дело.

Для этого нужно сопоставить всем полям их читабельные наименования. Если это не проблема — согласен, можно и так.
Как вариант — можно выдавать по ОК просто текст, где внятно описаны зависимости между полями в этом диалоге.

S>2. Я не совсем понял, в какой момент у вас возникает тултип, но ИМХО лучше, если он возникает либо на mouseover, либо на setfocus на контрол.
Это обычный tooltip, родной контрол Windows. Он возникает при наведении мышью на поле, исчезает сам через некоторое время.

S>3. Дату лучше вводить в формате текущей локали. Это универсальнее и однозначнее.
Полностью согласен. В каком-то ответе выше я уже говорил про даты...

S>4. Использование масок отвергать не стоит.
Использовать/не использовать маски — вопрос религиозный. Мне маски не нравятся в принципе, причины я вроде бы уже описывал...

S>5. Ну и последнее — при поточном вводе тормозить пользователя и не пускать его на следующие контролы, если есть ошибки в редактируемом, ИМХО не очень хорошо, поскольку быстрые операторы вводят данные на автомате и торможение на одном контроле оператор замечает далеко не сразу. К тому же это сильно сбивает. Достаточно подсветки. Насколько я понимаю — у вас именно так предусмотрено поведение контрола при потере фокуса?

Состояние контролов валидный/невалидный может измениться только при изменении значения в каком-то из контролов.
При получении/потере фокуса ничего не происходит, уходить с контрола я пользователю не мешаю.

S>Кстати, не могли бы вы прояснить следующую фразу:
S>

S>Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.

S>Имеется ввиду специальное место на форме, одновременно всплывающие тултипы или ещё что-то?

Имеется в виду, что все правила валидации описываются одной функцией в исходном файле диалога.

S>Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):
S>
Ну... в общем, да — подход действительно близкий...

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
Ну, на самом деле, вводить дату вполне удобно. Человек, привыкший к данному UI, набивает 7/5 почти с той же скоростью, что и 0705. Обрати внимание на то, что ведущие нули при таком вводе не нужны. Формат даты бывает разным только у плохо сломанных пиратских программ — в штатах, я тебя уверяю, обо всех этих вариантах и не слышали никогда. Для них просто 5 — это пятое число текущего месяца. 5/7 — это седьмое мая текущего года. 5/7/6 — это седьмое мая 2006. Все. Контрол должен это понимать — и все будет в порядке. Именно так ведет себя Excel.
Пользователь-новичок, скорее всего, вообще не будет пытаться тайпать в это поле. Он воспользуется календариком. И сразу же увидит, в каком формате привыкла представлять даты система.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате.

Так в чем проблема — переведи дату в другой формат самостоятельно, т.е. программным путем. Я так и делаю.
Другой вариант — при получении фокуса ввода поле показвает подстказку о формате. Порльзователь не совсем дурак — может и прислушаться

YKU>ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

ИМХО, он действительно не очень удобен.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Они вам и О1.О3.2ОО5 напишут... А потом прийдет невразумительній багрепорт "Неправильно вводдится дата"

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

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

Здравствуйте, Кодт, Вы писали:

O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

К>Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".

А я категорически против подстветки кнопок красным цветом.
По моим наблюдениям пользователей это бесит.
Смену цвета поля ввода они понимают, а вот смену цвета кнопок почему-то нет.

Зато многим пользователям понравилась другая вешь:
+ валидация "на лету"
+ анимированный признак успешной валидации всех полей окна
+ (иногда для сложно проверяемых данных) кнопка "Проверить".

Анимашку можно разместить и на кнопке ОК, кстати.
Вырабатывается рефлекс не нажимать на ОК пока анимация не появится, и, юзеры перестают бояться появления ошибок после нажатия.
Т.е. пользователь чувствует комфорт

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>А вы сообщите типом, "Ошибка во вводе цены", а несчастный юзер никогда не догадается, что гривны и копейки надо разделять точкой.

Да неправда!!! Надо тщательнее проверять.

YKU>Вообще, ИМХО чем меньше "Пользователь может вводить в поля все что хочет", тем лучше.

Зависит от типа софта. Для авиадиспетчера это скорее всего так, а для писателя или журналиста с текстовым редактором — сомневаюсь.

YKU>Под "оператором" я понимаю пользователя, который профессионально исспользует программу.

Какую программу? Вот в чем вопрос. Для профи (который вбивает постоянно большие объемы информации) ИМХО лучше дать горячие клавиши и ппрочие клавиатурные фичи. Кстати, как показал опыт, для такого профи "хитрая" валидация гораздо больше подходит, чем простой заперт.

Здравствуйте, nzeemin, Вы писали:

[...]

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

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

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

На практике же часто видим такое, бабушка или только еще девочка села за мощный такой компьютер с плоским монитором ну там все дела, видит диалог к примеру для ввода наименования адреса, причем в формате для пенсионного фонда, т.е. страна, область, город, улица, дом, корпус, квартира, литеры там всякие ну и так далее с соотвествующими требованиями, т.е. префикс Г, УЛ, ОБЛ и пр.
Короче, есть вариант использования единого текствого поля, где П собственно и будет вводить адрес, сами понимаете, формат записи, сама последовательность ввода, должен быть у П в голове, в принципе на практике, набрав ...цать раз, пользователь запомнит порядок ну и будет вводить, каждый раз с диким ужасом попадания курсора в такое поле...

Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр., возникает необходимость перемещения по 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 справа/снизу от поля.
Вот мой пример. Есть такие параметры: диаметр трубы, тип диафрагмы, размер диафрагмы, тип среды,... и максимальное давление. Так вот, разрешенный диапазон последнего параметра зависит от предыдущих. Когда параметры вводятся впервый раз все хорошо, но вот когда их меняют (это делается как минимум два раза в год (переход лето-зима), а иногда могут меняться каждый день, когда пьянные техники то гайку не довернут, то не ту систему сделают) не в логическом порядке, а в алфавитном или еще каком (как техники запишут их на бумагу, так пользователь и вводят). А проверки тут нужны поскольку техники параметры пишут в удобных для них единицах, то напишут в сантиметрах, то в милиметрах, то испльзуют кило(мега)паскали, а иногда атмосферы. А глупый юзер разницу знает, то не всегда вводит правильно.
Как прикажете кратко описать зависимоть между полями? Вот поэтому я делаю проверку только когда пользователь нажимает ОК и сообщаю что при остальных парметрах этот должен быть в таком диапазоне.

ЗЫ Я приветствую рантаймовскую валидацию, но иногда существуют исключения.

Здравствуйте, nzeemin, Вы писали:

N>Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается.

Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.

Здравствуйте, olegkr, Вы писали:

O>Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.

Это лишние шевеления, которые сбивают с текущих действий, отвлекают.
Лучше показать сомостоятельно какое-либо сообщение, тот же тултип, но без вмешательства пользователя.
Только очень тяжело, а часто и невозможно, предсказать момент для такого автоматического показа.
Поэтому еще раз укажу на свой вариант решения — Re[3]: Ненавязчивая валидация

Автор: kavlad
Дата: 01.07.05

Здравствуйте, kavlad, Вы писали:

K>Это лишние шевеления, которые сбивают с текущих действий, отвлекают.

Это для того случая, если пользователю непонятно почему кнопку нажать нельзя, вместо вываливающегося окошка по нажатию кнопки.

K>Поэтому еще раз укажу на свой вариант решения — Re[3]: Ненавязчивая валидация

Автор: kavlad
Дата: 01.07.05

Не люблю ни подсвеченные, ни анимированные кнопки. А для индикации того, что все данные правильно введены, больше склоняюсь к вываливающемуся balloon-у.

Здравствуйте, olegkr, Вы писали:

O>А для индикации того, что все данные правильно введены, больше склоняюсь к вываливающемуся 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>Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…

По мотивам, как уже упоминалось, .NET Error Provider
http://www.rsdn.ru/Forum/Message.aspx?mid=866088

Автор: Нахлобуч
Дата: 24.10.04

N>Единственное замечание к ErrorProvider — при его использовании придется учитывать возможность его появления в дизайне диалога. Например, тот способ ввода даты что я предлагал — придется кнопку пикера относить дальше от TextBox — по той причине что сразу за текстбоксом может появиться ярлычок ошибки.

Дык надо одним контролом просто делать поле ввода и кнопку.

Здравствуйте, Mamut, Вы писали:
M>Это относится в первую очередь к специализированным приложениям — скажем, к бухгалтерским программам, где пользователь (он же — оператор) вводит большое количество однотипных или связанных друг с дргом данных. В приложениях общего пользования с такими мелочами уже проблемы. Про дату не скажу, но я до сих пор не знаю, что я вляется разделителем дробей в MS Word и Photoshop'е — точка, запятая, или эти данные берутся из локали?
Еще раз — это твое незнание — не твоя проблема. Это проблема криворуких русификаторов и пиратов, которые не читали рекомендаций. Я тебя уверяю — для американского пользователя Photoshop таких вопросов даже не возникает.
А нормальное приложение, спроектированное с учетом особенностей Российского рынка IT, должно вообще понимать в качестве десятичного разделителя и точку, и запятую. Благо обычно понять, где целое, а где дробное — особого ума не надо.

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, nzeemin, Вы писали:

N>>Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается.

O>Можно попробовать использовать tooltips для кнопки ок. Навел и тебе выдается причина, по которой кнопка не может быть нажата.
то есть вместо простого м очевидного нажатия на кнопку, ты предлагаешь догадаться, что на серую кнопку надо навести мышку и подождать? Ни один пользователь этот квест не решит. Кроме того, даже знающий фишку пользователь вместо молниеносного появления поясняющей надписи вынужден тормозиться на hint pause, затаив мышку... Имхо — отвратительное решение.

Здравствуйте, DuШes, Вы писали:
DШ>Сразу же скажу, что со всеми принципами согласен, более того, сам использовал такой подход в последнем проекте (кроме использования тултипов, не довел до ума )...

DШ>Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр.,
DШ>Как мне кажется, второй вариант очевиднее, есть нагрузка на перемещение между контролами, но зато нет необходимости П помнить о формате строки, порядке, прексах, некоторых служебных записях и пр.
Все это, конечно, хорошо. Но вот, допустим, у пользователя есть другое какое-то место, где этот адрес написан одним блоком текста. Причем разделителями частей адреса могут быть пробелы, табы, запятые, точки с запятой, и даже переводы строки. И все вперемешку. Если бы у нас было текстовое поле "полный адрес", то пользователь бы тупо нажал "Ctrl+C", встал бы в него, и адрес оказался бы в системе. Три нажатия клавиш! Для твоего варианта надо как минимум 15.
Вот, к примеру Outlook не требует вводить имя контакта по частям. Он более-менее режет его на части самостоятельно. Проблемы в русской локали, конечно, есть, т.к. у нас немного другие правила образования имен. А локализацию, похоже, делали намного менее компетентные люди, чем оригинал. Но идея сохраняется. Та же фигня с номером телефона. Outlook при вводе успешно выделяет код страны; таблицы кодов городов у него нет (а зря), но скобки в номере он трактует правильно.

DШ>Можно привезти некие другие примеры, например, из области машиностроения, к примеру, ввода метизов, технических характеристик — еще раз поясню, я рассматриваю ту ситуацию, когда вводом самой информации занимается оператор, не имеющий представления о таких характеристиках, для которого название метиза и формат записи [Тип метиза диаметрХдлинаХПрочее Материал] неизвестны, а типов такого рода информации для ввода может быть очень много даже в пределах одного документа и зачастую оператор даже представления не имеет, что он заносит...(почему и солидарен с yorick-ом насчет необходимости использования в некоторых случаю маски ввода, например, денежные суммы, запретив П к примеру вводить баснословные ссумы для переводов уже на этапе самого ввода, еще до проведения валидации...)
Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...

DШ>pps: вообщем, я за то, чтобы не использовать некие идеи как нечто такое, от чего нельзя отступаться, при реализации конкретной задачи нужно использовать различные подходы...
Это, конечно, хорошо. Тут ты прав. Но я все чаще убеждаюсь в том, что если мне непонятно, как применить некий устоявшийся принцип к решению моей задачи — это исключительно от моей же некомпетентности. Спустя какое-то время я понимаю, что ломился не в ту дверь

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-компрессоры

Здравствуйте, Sinclair, Вы писали:

S>Еще раз — это твое незнание — не твоя проблема. Это проблема криворуких русификаторов и пиратов, которые не читали рекомендаций. Я тебя уверяю — для американского пользователя Photoshop таких вопросов даже не возникает.

Это не проблема криворуких русификаторов, а их заслуга (носорог близорук, но при его массе это не его проблема).

S>А нормальное приложение, спроектированное с учетом особенностей Российского рынка IT, должно вообще понимать в качестве десятичного разделителя и точку, и запятую. Благо обычно понять, где целое, а где дробное — особого ума не надо.

Дак его же надо ещё спроектировать!... У американского пользователя фотошопа нет вопросов, потому что дефолтная локаль совпадает с американской.

Здравствуйте, Sinclair, Вы писали:

[...]

DШ>>Можно привезти некие другие примеры, например, из области машиностроения, к примеру, ввода метизов, технических характеристик — еще раз поясню, я рассматриваю ту ситуацию, когда вводом самой информации занимается оператор, не имеющий представления о таких характеристиках, для которого название метиза и формат записи [Тип метиза диаметрХдлинаХПрочее Материал] неизвестны, а типов такого рода информации для ввода может быть очень много даже в пределах одного документа и зачастую оператор даже представления не имеет, что он заносит...(почему и солидарен с yorick-ом насчет необходимости использования в некоторых случаю маски ввода, например, денежные суммы, запретив П к примеру вводить баснословные ссумы для переводов уже на этапе самого ввода, еще до проведения валидации...)
S>Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...

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

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

pps: как и раньше, еще раз оговорюсь, не надо воспринимать умные контролы как ману небесную, в любой задаче надо видеть свои риски, в том числе и наличие абсолютно безграмотного пользователя/оператора...

Здравствуйте, Spidola, Вы писали:
[....]
S>Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):

S>

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

Здравствуйте, DuШes, Вы писали:

DШ>ну вот таким образом лично я часто видел такие вот умные программы, оставляющие целиком и полностью контроль и ответственность на пользователя
Нет, наоборот. Это ты предлагаешь возложить контроль и ответственность на пользователя. Чтобы он вручную порезал комплексное данное на части. При этом ты вместо того, чтобы помогать ему делать правильно, пытаешься мешать делать неправильно.
DШ>(самое интересное, пользователи умудрялись вводить информацию таким образом, что никие парсеры уже не понимали что же хотел оператор ...хотя множеством вариантов ввода был предусмотрен ввод чуть ли даже не сокращениями и даже в латинице)...
Можно более конкретный пример в студию? Давайте пообсуждаем возможные решения.

DШ>ps: я рад за вас, что не приходилось сталкиваться с такими пользователями, пример с датами хороший, но выше я оговорился, что это очень тривиальная задача, она не один раз решена, простые контролы я не рассматривал, а рассматривал пример, когда оператор выполняет к примеру задачи заполнения справочников или вводом первичных документов, причем различных типов информации в пределах одного документа может быть n-множество (достаточно посмотреть на справочники машиностроения, скажем, процесс сборки, и его технологические карты)...
Хм. Вот чего я хоть убей не понимаю — зачем садить пользователя за такую работу. На OCR денег жалко? А исправлять ошибки пользователя — денег не жалко... Парадокс.
DШ>pps: как и раньше, еще раз оговорюсь, не надо воспринимать умные контролы как ману небесную, в любой задаче надо видеть свои риски, в том числе и наличие абсолютно безграмотного пользователя/оператора...
У контролов никакого ума нет. Ум должен быть у архитектора.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>ну вот таким образом лично я часто видел такие вот умные программы, оставляющие целиком и полностью контроль и ответственность на пользователя
S>Нет, наоборот. Это ты предлагаешь возложить контроль и ответственность на пользователя. Чтобы он вручную порезал комплексное данное на части. При этом ты вместо того, чтобы помогать ему делать правильно, пытаешься мешать делать неправильно
.
на самом деле, я помогаю делать ему так как нужно и как правильно, и не заставляю в голове держать ненужную для него информацию о форматах ввода, которые в твоем случае он обязан помнить..

DШ>>(самое интересное, пользователи умудрялись вводить информацию таким образом, что никие парсеры уже не понимали что же хотел оператор ...хотя множеством вариантов ввода был предусмотрен ввод чуть ли даже не сокращениями и даже в латинице)...
S>Можно более конкретный пример в студию? Давайте пообсуждаем возможные решения.

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

а вообще за примером ходить недолго, возьмем пример с метизами:
исходная информация:
1.Оператор, девочка, поступившая работать как дочка главного инженера в технологический отдел, по образованию бухгалтер, но в бухгалтерии места не нашлось, определили оператором по вводу.
2.Вводимая информация: метиз, формат записи согласно тех процессу, тип метиза, характеристики, материал, стандарт, технические требования, соотвествие ISO 9000 ...что-то там еще (формат точно не помню, в машиностроении не работаю уже 5 лет, но принцип тот же), характеристики и стандарты могут отличаться от типа метиза, марка материала может быть необязательна, в определенных случаях ее вообще вводить ненужно
3.Первичный документ, видим, текстовый отчет о изготовлении партии метизов из стали, болты с шестигранной головкой, 6x20, далее количество и подписи...для оператора это пустые фразы, единственно о чем она имеет представление, что такое болт...,





DШ>>ps: я рад за вас, что не приходилось сталкиваться с такими пользователями, пример с датами хороший, но выше я оговорился, что это очень тривиальная задача, она не один раз решена, простые контролы я не рассматривал, а рассматривал пример, когда оператор выполняет к примеру задачи заполнения справочников или вводом первичных документов, причем различных типов информации в пределах одного документа может быть n-множество (достаточно посмотреть на справочники машиностроения, скажем, процесс сборки, и его технологические карты)...
S>Хм. Вот чего я хоть убей не понимаю — зачем садить пользователя за такую работу. На OCR денег жалко? А исправлять ошибки пользователя — денег не жалко... Парадокс.
Сажают, будь уверен, ты как работник софтовой компании возможно и представления не имеешь о категриях операторов, часто бывает так, что внедряют 1с, бабушки, которым до пенсии пару лет а то и меньше, вообще все в штыки воспринимают, зачем им учться правильному вводу, когда они на счетах все посчитают и ручкой шариковой в журнал проводок забьют
Поэтому и требуется исключить наличе ошибок уже на стадии ввода...

DШ>>pps: как и раньше, еще раз оговорюсь, не надо воспринимать умные контролы как ману небесную, в любой задаче надо видеть свои риски, в том числе и наличие абсолютно безграмотного пользователя/оператора...
S>У контролов никакого ума нет. Ум должен быть у архитектора.
не придирайся к выражению, под "умным" контролом я и понимаю логику архитектора/дизайнера приложения/мысли программиста, не буду спорить что в логику парсинга можно многое вложить, но...стоит ли овчинка выделки..???

Здравствуйте, Sinclair, Вы писали:
[...]

в продолжение темы:

раньше уже бы упомянут пример с трубой: диаметр х длина, ну и прочие характеристики, допустим, при вводе в текстовое поле осуществляется парсинг введенной строки, в базе есть трубы диаметром 80, 100, значение длины не ограничено (в разумных пределах), оператор заводит может завести 80 Х 100, а может и 100 Х 80, что в данном случае ввел оператор??? Подразумеваем наличие неопытного, неряшливого оператора, что он ввел, толи трубу диаметром 80 и длиной 100, толи диаметром 100 и длиной 80...ошибка оператора в таком случае может привести к произвосдтву брака, материальным потерям и т.д....

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

Здравствуйте, DuШes, Вы писали:

DШ>а вообще за примером ходить недолго, возьмем пример с метизами:
DШ>исходная информация:
DШ>1.Оператор, девочка, поступившая работать как дочка главного инженера в технологический отдел, по образованию бухгалтер, но в бухгалтерии места не нашлось, определили оператором по вводу.
DШ>2.Вводимая информация: метиз, формат записи согласно тех процессу, тип метиза, характеристики, материал, стандарт, технические требования, соотвествие ISO 9000 ...что-то там еще (формат точно не помню, в машиностроении не работаю уже 5 лет, но принцип тот же), характеристики и стандарты могут отличаться от типа метиза, марка материала может быть необязательна, в определенных случаях ее вообще вводить ненужно
DШ>3.Первичный документ, видим, текстовый отчет о изготовлении партии метизов из стали, болты с шестигранной головкой, 6x20, далее количество и подписи...для оператора это пустые фразы, единственно о чем она имеет представление, что такое болт...,

И что? Каким образом интерфейс с кучей полей поможет этой умственно отсталой девочке заполнить информацию о тех.процессу правильнее, чем единый текстбокс?

DШ>Сажают, будь уверен, ты как работник софтовой компании возможно и представления не имеешь о категриях операторов, часто бывает так, что внедряют 1с, бабушки, которым до пенсии пару лет а то и меньше, вообще все в штыки воспринимают, зачем им учться правильному вводу, когда они на счетах все посчитают и ручкой шариковой в журнал проводок забьют
DШ>Поэтому и требуется исключить наличе ошибок уже на стадии ввода...
Еще раз: я не предлагаю учить правильному вводу. Я предлагаю сделать парсинг автоматическим, а не ручным.
S>>У контролов никакого ума нет. Ум должен быть у архитектора.
DШ>не придирайся к выражению, под "умным" контролом я и понимаю логику архитектора/дизайнера приложения/мысли программиста, не буду спорить что в логику парсинга можно многое вложить, но...стоит ли овчинка выделки..???
Конечно стоит. Ты в курсе, что MS Money угадывает категорию платежа по имени получателя? Я вот в свое время написал там Lion Gym — мне сразу подставился Health and Fitness. Вот он парсер во всей красе. При этом он никак не мешает мне выбрать категорию руками, а также добавить новую категорию.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>а вообще за примером ходить недолго, возьмем пример с метизами:
DШ>>исходная информация:
DШ>>1.Оператор, девочка, поступившая работать как дочка главного инженера в технологический отдел, по образованию бухгалтер, но в бухгалтерии места не нашлось, определили оператором по вводу.
DШ>>2.Вводимая информация: метиз, формат записи согласно тех процессу, тип метиза, характеристики, материал, стандарт, технические требования, соотвествие ISO 9000 ...что-то там еще (формат точно не помню, в машиностроении не работаю уже 5 лет, но принцип тот же), характеристики и стандарты могут отличаться от типа метиза, марка материала может быть необязательна, в определенных случаях ее вообще вводить ненужно
DШ>>3.Первичный документ, видим, текстовый отчет о изготовлении партии метизов из стали, болты с шестигранной головкой, 6x20, далее количество и подписи...для оператора это пустые фразы, единственно о чем она имеет представление, что такое болт...,

S>И что? Каким образом интерфейс с кучей полей поможет этой умственно отсталой девочке заполнить информацию о тех.процессу правильнее, чем единый текстбокс?

пожалуйста:

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

длина: |______________| — тоже самое, могу список ограничить выпадающим комбобоксом, построенным на основании данных из справочника, тогда даже умать ручками вводить не нужно, другой диаметр/длину просто даже не введу...

стандарт: |______________| — в зависимости от типа метиза свой стандарт поставлю автоматически, если есть выбор, выдам комбобокс...опять таки не нужно вводить ручками лишнее и проводить анализ на соотвествие введенному вручную госту...

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

S>Еще раз: я не предлагаю учить правильному вводу. Я предлагаю сделать парсинг автоматическим, а не ручным.

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

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



S>Конечно стоит. Ты в курсе, что MS Money угадывает категорию платежа по имени получателя? Я вот в свое время написал там Lion Gym — мне сразу подставился Health and Fitness. Вот он парсер во всей красе. При этом он никак не мешает мне выбрать категорию руками, а также добавить новую категорию.

это не парсер...это поиск соотвествия, если бы ты ввел Gym Lion и такой получатель был бы, ты получил бы неожиданный результат, заставивший тебя забуматься минимум на минуту...

Здравствуйте, DuШes, Вы писали:
DШ>раньше уже бы упомянут пример с трубой: диаметр х длина, ну и прочие характеристики, допустим, при вводе в текстовое поле осуществляется парсинг введенной строки, в базе есть трубы диаметром 80, 100, значение длины не ограничено (в разумных пределах), оператор заводит может завести 80 Х 100, а может и 100 Х 80, что в данном случае ввел оператор??? Подразумеваем наличие неопытного, неряшливого оператора, что он ввел, толи трубу диаметром 80 и длиной 100, толи диаметром 100 и длиной 80...ошибка оператора в таком случае может привести к произвосдтву брака, материальным потерям и т.д....
Во-первых, трубы как правило маркируются совершенно определенным образом. И порядок никогда не нарушается, именно для того, чтобы в прайс листе не было неопределенности.
Во-вторых, если оператор не знает, что из этого диаметр, а что длина, то он и в раздельные поля это не введет.
В третьих, для визуальной проверки делается три поля:

Маркировка: [ ]
Длина: [ ]
Диаметр: [ ]

При вводе в первое поле выполняется попытка парсинга, и отпарсенные значения заносятся во второе и третье. Оператор все еще может исправить введенные значения вручную, но не обязан это делать.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:
DШ>>раньше уже бы упомянут пример с трубой: диаметр х длина, ну и прочие характеристики, допустим, при вводе в текстовое поле осуществляется парсинг введенной строки, в базе есть трубы диаметром 80, 100, значение длины не ограничено (в разумных пределах), оператор заводит может завести 80 Х 100, а может и 100 Х 80, что в данном случае ввел оператор??? Подразумеваем наличие неопытного, неряшливого оператора, что он ввел, толи трубу диаметром 80 и длиной 100, толи диаметром 100 и длиной 80...ошибка оператора в таком случае может привести к произвосдтву брака, материальным потерям и т.д....
S>Во-первых, трубы как правило маркируются совершенно определенным образом. И порядок никогда не нарушается, именно для того, чтобы в прайс листе не было неопределенности.
это ты знаешь и...я

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

S>В третьих, для визуальной проверки делается три поля:
S>

Маркировка: [ ]
S>Длина: [ ]
S>Диаметр: [ ]

S>При вводе в первое поле выполняется попытка парсинга, и отпарсенные значения заносятся во второе и третье. Оператор все еще может исправить введенные значения вручную, но не обязан это делать.

ого...это забудем, суть тогда парсинг в чем???

Здравствуйте, DuШes, Вы писали:

DШ>это не парсер...это поиск соотвествия, если бы ты ввел Gym Lion и такой получатель был бы, ты получил бы неожиданный результат, заставивший тебя забуматься минимум на минуту...
Щас прямо. При вводе Gym Lion он все равно подставит то что надо. Да, для существующих получателей он берет последний введенный тип. Но для несуществующих он выполняет парсинг!

Здравствуйте, DuШes, Вы писали:

DШ>ого...это забудем, суть тогда парсинг в чем???
Опять 25. В том, чтобы минимизировать клики. Читать Re[2]: Ненавязчивая валидация

Автор: Sinclair
Дата: 03.07.05

.

Здравствуйте, nzeemin, Вы писали:

[skip]

N> Например, тот способ ввода даты что я предлагал — придется кнопку пикера относить дальше от TextBox — по той причине что сразу за текстбоксом может появиться ярлычок ошибки.

Вовсе не обязательно, ErrorPrivider позволяет выбирать место отображения иконки.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>это не парсер...это поиск соотвествия, если бы ты ввел Gym Lion и такой получатель был бы, ты получил бы неожиданный результат, заставивший тебя забуматься минимум на минуту...
S>Щас прямо. При вводе Gym Lion он все равно подставит то что надо. Да, для существующих получателей он берет последний введенный тип. Но для несуществующих он выполняет парсинг!
ты не понял, я подразумевал наличие как получателя Gym Lion, так и Lion Gym, хотел показать аналогию с примером с трубой..., в записи Gym Lion лично я не знаю, где имя и где фамилия и что это вообще, а ты хочешь доверить это на лексический|синтаксический анализ???? Одна ошибка чревата материальными потерями...для таких случаев оператор должен быть уверен что же он все таки ввел, я надеюсь в платежной системе хоть описание имени получателя есть, подсказка кака-нибудь???

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

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

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

Вообщем, спорить дальше наверно ни к чему...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>ого...это забудем, суть тогда парсинг в чем???
S>Опять 25. В том, чтобы минимизировать клики. Читать Re[2]: Ненавязчивая валидация

Автор: Sinclair
Дата: 03.07.05

.

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

Здравствуйте, DuШes, Вы писали:
[...]

вообщем, как суть той мысли, которую я пытался довести: когда пользователь вводит информацию, особенно ту, которая представляет ценность, он должен быть уверен на 100%, что именно ОН ввел информацию правильно (что диаметр это диаметр и длина это длина и что Смирнов А.В. это тот который из ОИТ), а не парсер за него сделал эту работу...в наличии парсера лично я вижу потенциальную вожможность возникновения ошибок...

Здравствуйте, DuШes, Вы писали:

DШ>Здравствуйте, Spidola, Вы писали:
DШ>[....]
S>>Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):

DШ>имхо...текстовое поле с комбиком снижу не очень удачное решение, создает впечатление перегруженности ...
Согласен... Лень было на JS реализовывать полноценный комбобокс (а не листбокс, как сделано)... Хотя можно.

Здравствуйте, Sinclair, Вы писали:

[skip]

S>Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...

Я так понимаю, имеется ввиду, что отечественные IT-шники придумали этого пользователя? Не могу согласиться.
Пользователь не знает, чего он хочет, потому что:
1) отсутствует инструкция (неформальная в точ числе), регламентирующая порядок регистрации данных: каждый новый сотруднки придумывает что-то свое;
2) руководитель подразделения не может описать в каком виде могут поступать данные;
3) компьютерная грамотность непосредственно операторов, регистрирующих данные (а также их руководителей), находится на уровне "не владения" терминогией;
4) существует множество припятствий (в т.ч. имеющих политические корни), не дающих провести полноценные исследования.

Все это проблемы менеджмента, причем не IT-шного.
ИМХО "запретить как можно больше" — это отличный компромис в условиях сильной нехватки данных о сложившихся стереотипах в работе пользователя. Кроме того, осознание того, что "пользователь не знает что хочет", позволяет фильтровать поток требований и превращать систему в хлам.

Здравствуйте, DuШes, Вы писали:
S>>Щас прямо. При вводе Gym Lion он все равно подставит то что надо. Да, для существующих получателей он берет последний введенный тип. Но для несуществующих он выполняет парсинг!
DШ>ты не понял, я подразумевал наличие как получателя Gym Lion, так и Lion Gym, хотел показать аналогию с примером с трубой...,
Ты похоже просто не видел примеров нормального софта. Попробуй поставить себе MS Money, триал бесплатен. Хоть посмотришь, как настоящий ГУИ выглядит. Он, кстати, на идиотов рассчитан. Не то что на операторов, которые как ни тупы, но каждый день одно и то же долбят. А на людей, которые вообще ничего не знают.
DШ>в записи Gym Lion лично я не знаю, где имя и где фамилия и что это вообще, а ты хочешь доверить это на лексический|синтаксический анализ???? Одна ошибка чревата материальными потерями...для таких случаев оператор должен быть уверен что же он все таки ввел, я надеюсь в платежной системе хоть описание имени получателя есть, подсказка кака-нибудь???

DШ> — минимизации кликов не увидел, так как появляется лишний анализ причин ошибок, который можно было бы избежать еще на самой стадии ввода
Ты специально не читаешь то, что я пишу? Если у пользователя уже есть строка типа Болт 16x27 (в письме, в Excel, в OCR-ном документе), то он тупо делает Ctrl+Ins Alt+Tab Shift-Ins.
Минусов никаких нет, т.к. режим парсинга предоставляется как дополнение к твоему любимому многополевому режиму.

Здравствуйте, Sinclair, Вы писали:
[]
DШ>> — минимизации кликов не увидел, так как появляется лишний анализ причин ошибок, который можно было бы избежать еще на самой стадии ввода
S>Ты специально не читаешь то, что я пишу? Если у пользователя уже есть строка типа Болт 16x27 (в письме, в Excel, в OCR-ном документе), то он тупо делает Ctrl+Ins Alt+Tab Shift-Ins.

ты кинул ссылку, я прочитал...следующий раз указывай мысль, которую ты хотел донести...по той ссылке я увидел про парсинг строки ФИО, в контексте той темы про парсинг я думал что ты именно про это хотел рассказать, на что я ответил в ветке

Автор: DuШes
Дата: 04.07.05

и здесь

Автор: DuШes
Дата: 04.07.05

....

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

Он не столько любимый, сколько обеспечивает контроль за действиями пользователя, от которого вы пытаетесь отказаться за счет ввода всякого рода парсеров, синтаксического|лексического анализа и пр., подразумевая при этом наличие грамотного и аккуратного пользователя/оператора (что является к сожалению редкостью)

ps: что касается внимательности чтения...еще раз внимательно прочитай приведенные ссылки...основная мысль в том, что сам пользователь должен быть уверен в том, что информацию он записал именно в том виде и именно ввиде тех составляющих, которые согласно вашему варианту пришлось бы ему вводить в одном текстовом поле и отдать затем на распоряжение парсеру, т.е. лично я вижу явный разрыв между логикой оператора и логикой по обработке действий оператора (парсер) — имхо, вы получаете такой же контроль, что и в случае использования всякого рода mask-editoв, использования "многополевого режима", пусть он неявный, но то что сам пользователь теряет контроль над своими же действиями — это имхо не есть хорошо...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Sinclair, Вы писали:

А>[skip]

S>>Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...

А>Я так понимаю, имеется ввиду, что отечественные IT-шники придумали этого пользователя? Не могу согласиться.
А>Пользователь не знает, чего он хочет, потому что:
А>1) отсутствует инструкция (неформальная в точ числе), регламентирующая порядок регистрации данных: каждый новый сотруднки придумывает что-то свое;
А>2) руководитель подразделения не может описать в каком виде могут поступать данные;
А>3) компьютерная грамотность непосредственно операторов, регистрирующих данные (а также их руководителей), находится на уровне "не владения" терминогией;
А>4) существует множество припятствий (в т.ч. имеющих политические корни), не дающих провести полноценные исследования.

с 1,2,3 согласен на 100%...

Здравствуйте, Sinclair, Вы писали:

DШ>>Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр.,

А в каждом поле справочник с возможностью подстановки...

DШ>>Как мне кажется, второй вариант очевиднее, есть нагрузка на перемещение между контролами, но зато нет необходимости П помнить о формате строки, порядке, прексах, некоторых служебных записях и пр.
S>Все это, конечно, хорошо. Но вот, допустим, у пользователя есть другое какое-то место, где этот адрес написан одним блоком текста. Причем разделителями частей адреса могут быть пробелы, табы, запятые, точки с запятой, и даже переводы строки. И все вперемешку. Если бы у нас было текстовое поле "полный адрес", то пользователь бы тупо нажал "Ctrl+C", встал бы в него, и адрес оказался бы в системе. Три нажатия клавиш! Для твоего варианта надо как минимум 15.

Два момента на мой взгляд сводят на нет преимущества "Ctrl+C".
Первый — пользователь просто устанет каждый раз писАть адрес со всеми необходимыми знаками препинания и сокращениями — "127000 г. Москва, ул. Академика Королёва, д. 150, корп. 5, стр. 2, кв. 20" — превратится в "Королева 150/5/2-20". Другой оператор не всегда мыслит также как и его предшественник, например. Не говоря уж про то, что этот адрес тяжело использовать в рассылке или официальных письмах.
Второй — А как же поиск? В одном адресе "ул. 26 Бакинских Комисаров", в другом "ул. 26-и Бакинских Комиссаров", в третьем "улица Двадцати шести Бакинских Комисаров", а в четвертом вообще оператор опечатался.

Валерий.

Здравствуйте, ValeriySP, Вы писали:

VSP>Здравствуйте, Sinclair, Вы писали:

DШ>>>Попробуем решить задачу несколько другим образом, формат записи разобьем на несколько текствых полей, конкретно, страна, область, город, улица и пр.,

VSP>А в каждом поле справочник с возможностью подстановки...
естественно...


DШ>>>Как мне кажется, второй вариант очевиднее, есть нагрузка на перемещение между контролами, но зато нет необходимости П помнить о формате строки, порядке, прексах, некоторых служебных записях и пр.
S>>Все это, конечно, хорошо. Но вот, допустим, у пользователя есть другое какое-то место, где этот адрес написан одним блоком текста. Причем разделителями частей адреса могут быть пробелы, табы, запятые, точки с запятой, и даже переводы строки. И все вперемешку. Если бы у нас было текстовое поле "полный адрес", то пользователь бы тупо нажал "Ctrl+C", встал бы в него, и адрес оказался бы в системе. Три нажатия клавиш! Для твоего варианта надо как минимум 15.

VSP>Два момента на мой взгляд сводят на нет преимущества "Ctrl+C".
VSP>Первый — пользователь просто устанет каждый раз писАть адрес со всеми необходимыми знаками препинания и сокращениями — "127000 г. Москва, ул. Академика Королёва, д. 150, корп. 5, стр. 2, кв. 20" — превратится в "Королева 150/5/2-20". Другой оператор не всегда мыслит также как и его предшественник, например. Не говоря уж про то, что этот адрес тяжело использовать в рассылке или официальных письмах.
VSP>Второй — А как же поиск? В одном адресе "ул. 26 Бакинских Комисаров", в другом "ул. 26-и Бакинских Комиссаров", в третьем "улица Двадцати шести Бакинских Комисаров", а в четвертом вообще оператор опечатался.

VSP>Валерий.


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

Здравствуйте, DuШes, Вы писали:

DШ>ну к сожалению, в данной ветке присутствует упор на то, что пользователь не делает опечаток, в идеале он аккуратен и грамотен
нет такого упора. Это ты себе в голову вбил, что парсер должен быть жестким, как в с++, и шаг вправо/влево — уже неверный результат.
Также ты почему-то вбил себе в голову, что парсер будет делать свою работу молча, ничего не говоря пользователю.
Тем более тебе не приходит в голову, что парсер может явно попросить помощи пользователя для разрешения немногих неопределенностей.
Будет у меня свободное время — напишу демку для ввода адресов.
DШ>, и что его нужно очень любить
А вот это — правда. Конечно, с парсером есть обратный эффект — злонамеренный пользователь сможет таки забить адрес "улица 26 дом Бакинских". Но юзабилити рассчитывается не на злыдней, а на нормальных людей. У нормального человека не возникнет желания наедурить систему. Ненормальных надо увольнять — они и в самой параноидальной среде найдут выход своей злобе.
DШ>, в правоте своей точки зрения я похоже не смог убедить некоторых оппонентов хотя вроде и примеров и доводов было предостаточно
1. Примеры высосаны из пальца.
2. Доводы в основном базируются на некоторых заблуждениях (типа перечисленных в начале постинга).

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>ну к сожалению, в данной ветке присутствует упор на то, что пользователь не делает опечаток, в идеале он аккуратен и грамотен
S>нет такого упора. Это ты себе в голову вбил, что парсер должен быть жестким, как в с++, и шаг вправо/влево — уже неверный результат.
ну да, конечно, меняются условия парсинга, меняем парсер, компилим приложение, интересно, продолжай

S>Также ты почему-то вбил себе в голову, что парсер будет делать свою работу молча, ничего не говоря пользователю.
S>Тем более тебе не приходит в голову, что парсер может явно попросить помощи пользователя для разрешения немногих неопределенностей.
Представляю, еще больше запутывая интерфейс на каждом поле ввода предъявляя оператору список требований или требующий научить его распарсить введенную строку

S>Будет у меня свободное время — напишу демку для ввода адресов.
DШ>>, и что его нужно очень любить
S>А вот это — правда. Конечно, с парсером есть обратный эффект — злонамеренный пользователь сможет таки забить адрес "улица 26 дом Бакинских". Но юзабилити рассчитывается не на злыдней, а на нормальных людей. У нормального человека не возникнет желания наедурить систему. Ненормальных надо увольнять — они и в самой параноидальной среде найдут выход своей злобе.
Да пользователь добрый, и нормальный, и люблю я его, но к сожалению, ты видно не читал моих ответов, часто то что ввел оператор может быть растолковано по разному, и довольно часто в тойже самой строке ввода адреса ты полушь неодназночсти, благодаря которому любой парсер загнется...пользователь, вводивший улицу двадцати шести коммиссаров считает что он вводаит правильно, а вот парсер никогда не докагадается, что это, улица коммиссаров 26, или 26-улица коммиссаров...

DШ>>, в правоте своей точки зрения я похоже не смог убедить некоторых оппонентов хотя вроде и примеров и доводов было предостаточно

S>1. Примеры высосаны из пальца.
Да вроде они реальные, твоих доводов в пользу кроме как использования ctrl+c я лично не увидел

S>2. Доводы в основном базируются на некоторых заблуждениях (типа перечисленных в начале постинга).
доводы базируются на реальном опыте разработки и общении с операторами/конечными пользователями.


ps: Антон, прочитав, я удивляюсь как меняется твоя манера общения...ты переходишь на личности, у меня достаточно опыта общения и с пользователями и с заказчиками и есть опыт разработки, пусть небольшой, но все-таки чтобы судить о некоторых вещах, о которых как мне кажется я имею представление...так что не надо со мной общаться с пизиции преподавателя с глупым студентом, на которую ты к сожалению снизошел...

Здравствуйте, Sinclair, Вы писали:

DШ>>, и что его нужно очень любить
S>А вот это — правда. Конечно, с парсером есть обратный эффект — злонамеренный пользователь сможет таки забить адрес "улица 26 дом Бакинских". Но юзабилити рассчитывается не на злыдней, а на нормальных людей.

Разговор не про злыдней, а просто про разницу в подходе и восприятии, а также про опечатки.

Я не против парсера для адресов или для чего-либо другого. Даже более того, я за! Но для меня, как для человека которому тоже приходится иногда выполнять работу оператора, удобнее работать со справочниками. А уж для свободного полета разумно сделать отдельное поле в котором творишь что хочешь (хоть руками, хоть "Ctrl+C"), затем "Распарсить" и смотришь чего получилось и при необходимости правишь. Кстати, тут кто-то поминал Outlook — уж лучше отдельные поля чем такой парсинг.

DШ>>, в правоте своей точки зрения я похоже не смог убедить некоторых оппонентов хотя вроде и примеров и доводов было предостаточно
S>1. Примеры высосаны из пальца.
Вполне жизненные.

Валерий.

Здравствуйте, DuШes, Вы писали:

S>>нет такого упора. Это ты себе в голову вбил, что парсер должен быть жестким, как в с++, и шаг вправо/влево — уже неверный результат.
DШ>ну да, конечно, меняются условия парсинга, меняем парсер, компилим приложение, интересно, продолжай
Ну, в общем-то да Это же и есть идеальный случай.
S>>Также ты почему-то вбил себе в голову, что парсер будет делать свою работу молча, ничего не говоря пользователю.
S>>Тем более тебе не приходит в голову, что парсер может явно попросить помощи пользователя для разрешения немногих неопределенностей.
DШ>Представляю, еще больше запутывая интерфейс на каждом поле ввода предъявляя оператору список требований или требующий научить его распарсить введенную строку
Не надо ничего представлять:
1. Запусти аутлук и попробуй создать контакт. Введи номер телефона. По умолчанию он попросит тебя дозаполнить код страны и города; для строк вида +7(383)2177708 он сам все отпарсит.
2. Создай новое письмо. Начни писать в поле To фрагменты адресов/имен/фамилий из твоей адресной книги. Посмотри, как он предлагает тебе варианты в стиле code completion.
3. Нажми на кнопку "проверить адрес". Посмотри, как он попросит твоей помощи в тех случаях, когда не смог найти подходящего адреса.

DШ>Да пользователь добрый, и нормальный, и люблю я его, но к сожалению, ты видно не читал моих ответов, часто то что ввел оператор может быть растолковано по разному, и довольно часто в тойже самой строке ввода адреса ты полушь неодназночсти, благодаря которому любой парсер загнется...
В тех случаях, когда парсер загибается, можно потребовать ручного указания.
DШ>пользователь, вводивший улицу двадцати шести коммиссаров считает что он вводаит правильно, а вот парсер никогда не докагадается, что это, улица коммиссаров 26, или 26-улица коммиссаров...
Почему не догадается? Ну вот почему мой аутлук догадывается о том, какой е-мейл я имел в виду, а парсер улиц не допрет? Если есть и та и та улица, парсер просто покажет дроп-даун с вариантами, и пользователь выберет из них.

DШ>Да вроде они реальные, твоих доводов в пользу кроме как использования ctrl+c я лично не увидел
Даже без буфера тайпинг для опытного пользователя всегда быстрее. Я никогда не пользуюсь диалогом выбора адресов в аутлуке — потому, что там надо мышкой и много, а тайпать — на клавиатуре и мало.
DШ>доводы базируются на реальном опыте разработки и общении с операторами/конечными пользователями.
Гм. Нет. Ты критикуешь парсер за те свойства, которые не были предложены. Опыт разработки и общения тут ни при чем.
DШ>ps: Антон, прочитав, я удивляюсь как меняется твоя манера общения...ты переходишь на личности,
Нет. Не перехожу.
DШ>у меня достаточно опыта общения и с пользователями и с заказчиками и есть опыт разработки, пусть небольшой, но все-таки чтобы судить о некоторых вещах, о которых как мне кажется я имею представление...так что не надо со мной общаться с пизиции преподавателя с глупым студентом, на которую ты к сожалению снизошел...
Меня раздражает то, что раз за разом ты продолжаешь вычитывать в моих сообщениях то, чего там нет, и игнорировать то, что там есть. Поэтому мне приходится переходить на такой тон.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

S>>>нет такого упора. Это ты себе в голову вбил, что парсер должен быть жестким, как в с++, и шаг вправо/влево — уже неверный результат.
DШ>>ну да, конечно, меняются условия парсинга, меняем парсер, компилим приложение, интересно, продолжай
S>Ну, в общем-то да Это же и есть идеальный случай.
S>>>Также ты почему-то вбил себе в голову, что парсер будет делать свою работу молча, ничего не говоря пользователю.
S>>>Тем более тебе не приходит в голову, что парсер может явно попросить помощи пользователя для разрешения немногих неопределенностей.
DШ>>Представляю, еще больше запутывая интерфейс на каждом поле ввода предъявляя оператору список требований или требующий научить его распарсить введенную строку
S>Не надо ничего представлять:
S>1. Запусти аутлук и попробуй создать контакт. Введи номер телефона. По умолчанию он попросит тебя дозаполнить код страны и города; для строк вида +7(383)2177708 он сам все отпарсит.
S>2. Создай новое письмо. Начни писать в поле To фрагменты адресов/имен/фамилий из твоей адресной книги. Посмотри, как он предлагает тебе варианты в стиле code completion.
S>3. Нажми на кнопку "проверить адрес". Посмотри, как он попросит твоей помощи в тех случаях, когда не смог найти подходящего адреса.
Аутлук у меня всегда под рукой я как пользователь оутлука недоволен им, твои же рассуждения с позиции разработчика, я не знаю чем тебя убедить что разработка парсера для различных случаев не тривиальная ситуация, писать реализацию исскуственного интеллекта для задачи парсинга вводимой пользователем строки, когда туже задачу можно решить проще и удобнее для пользователя, дав ему контроль над своими же действиями...
вот твой outlook, который ты приводишь в качестве идеального примера для подражания:



DШ>>Да пользователь добрый, и нормальный, и люблю я его, но к сожалению, ты видно не читал моих ответов, часто то что ввел оператор может быть растолковано по разному, и довольно часто в тойже самой строке ввода адреса ты полушь неодназночсти, благодаря которому любой парсер загнется...
S>В тех случаях, когда парсер загибается, можно потребовать ручного указания.
и как ты себе это представляешь, ты уже перегружаешь и без того тривиальную задачу дополнительными диалогами..

DШ>>пользователь, вводивший улицу двадцати шести коммиссаров считает что он вводаит правильно, а вот парсер никогда не докагадается, что это, улица коммиссаров 26, или 26-улица коммиссаров...
S>Почему не догадается? Ну вот почему мой аутлук догадывается о том, какой е-мейл я имел в виду, а парсер улиц не допрет? Если есть и та и та улица, парсер просто покажет дроп-даун с вариантами, и пользователь выберет из них.
не догадается, твой пример с ctrl+c


вообщем, ты все равно не понял основную мысль которую я хотел донести: я как оператор, когда ввожу информацию, должен быть уверен что ввел именно то, что ввел именно я, а не то, что счел за меня парсер в лице разработавшего данный парсер программиста...ввод парсера подразумевает разрыв между действиями оператора и контролем оператора над своими же действиями...примеры я приводил даже и по outlook, когда у нас в адресной книге два человека с одинаковыми ФИО...

DШ>>Да вроде они реальные, твоих доводов в пользу кроме как использования ctrl+c я лично не увидел
S>Даже без буфера тайпинг для опытного пользователя всегда быстрее. Я никогда не пользуюсь диалогом выбора адресов в аутлуке — потому, что там надо мышкой и много, а тайпать — на клавиатуре и мало.
DШ>>доводы базируются на реальном опыте разработки и общении с операторами/конечными пользователями.
S>Гм. Нет. Ты критикуешь парсер за те свойства, которые не были предложены. Опыт разработки и общения тут ни при чем.
DШ>>ps: Антон, прочитав, я удивляюсь как меняется твоя манера общения...ты переходишь на личности,
S>Нет. Не перехожу.
DШ>>у меня достаточно опыта общения и с пользователями и с заказчиками и есть опыт разработки, пусть небольшой, но все-таки чтобы судить о некоторых вещах, о которых как мне кажется я имею представление...так что не надо со мной общаться с пизиции преподавателя с глупым студентом, на которую ты к сожалению снизошел...
S>Меня раздражает то, что раз за разом ты продолжаешь вычитывать в моих сообщениях то, чего там нет, и игнорировать то, что там есть. Поэтому мне приходится переходить на такой тон.
я выделил в предыдущем посте насчет вдалбливания себе в голову ...ты как модератор должен иметь объективную точку зренияи не спускаться на уровнеь эмоций, меня тоже уже раздражает то, что не увидел проблемы, которую как мне кажется я достаточно продемонстрировал

Здравствуйте, ValeriySP, Вы писали:
Ок, возможно я неправ. По уму, надо брать
а) задачу
б) решение
в) набор тестовых пользователей
и
г) гонять usability measurements
Тогда можно сравнивать эффективность того или иного подхода.
Варьируя а, б и в, можно попытаться построить некоторые далеко идущие выводы типа "для задачи XXX решение YYY применимо только в том случае, если потенциальные пользователи удовлетворяют требованию ZZZ. Иначе рулит решение AAA".

Здравствуйте, DuШes, Вы писали:

DШ>вообщем, ты все равно не понял основную мысль которую я хотел донести: я как оператор, когда ввожу информацию, должен быть уверен что ввел именно то, что ввел именно я, а не то, что счел за меня парсер в лице разработавшего данный парсер программиста...ввод парсера подразумевает разрыв между действиями оператора и контролем оператора над своими же действиями...
ПОЧЕМУ?
Вот это место я не понимаю. Почему парсер не может сразу показать результат своей работы? Где разрыв?
DШ>примеры я приводил даже и по outlook, когда у нас в адресной книге два человека с одинаковыми ФИО...
Угу. Лично у меня Outlook в таких случаях предлагает выбрать вручную.

Здравствуйте, Sinclair, Вы писали:

S>Тогда можно сравнивать эффективность того или иного подхода.
S>Варьируя а, б и в, можно попытаться построить некоторые далеко идущие выводы типа "для задачи XXX решение YYY применимо только в том случае, если потенциальные пользователи удовлетворяют требованию ZZZ. Иначе рулит решение AAA".

Согласен.

Валерий.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>вообщем, ты все равно не понял основную мысль которую я хотел донести: я как оператор, когда ввожу информацию, должен быть уверен что ввел именно то, что ввел именно я, а не то, что счел за меня парсер в лице разработавшего данный парсер программиста...ввод парсера подразумевает разрыв между действиями оператора и контролем оператора над своими же действиями...
S>ПОЧЕМУ?
S>Вот это место я не понимаю. Почему парсер не может сразу показать результат своей работы? Где разрыв?
возращаясь к примерам с трубами здесь

Автор: DuШes
Дата: 04.07.05

в продолжение темы:

раньше уже бы упомянут пример с трубой: диаметр х длина, ну и прочие характеристики, допустим, при вводе в текстовое поле осуществляется парсинг введенной строки, в базе есть трубы диаметром 80, 100, значение длины не ограничено (в разумных пределах), оператор заводит может завести 80 Х 100, а может и 100 Х 80, что в данном случае ввел оператор??? Подразумеваем наличие неопытного, неряшливого оператора, что он ввел, толи трубу диаметром 80 и длиной 100, толи диаметром 100 и длиной 80...ошибка оператора в таком случае может привести к произвосдтву брака, материальным потерям и т.д....

в данном случае парсер проглотит строку 80х100, посчитав ее правильной, найдя в базе трубу D=80 и L=100...хотя пользователь имел в виду длина 80 и диаметр 100,
если бы он вводил скажем:

диаметр |_____________| 100
длина   |_____________|  80

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

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, ValeriySP, Вы писали:
S>Ок, возможно я неправ. По уму, надо брать
S>а) задачу
S>б) решение
S>в) набор тестовых пользователей
S>и
S>г) гонять usability measurements
S>Тогда можно сравнивать эффективность того или иного подхода.
S>Варьируя а, б и в, можно попытаться построить некоторые далеко идущие выводы типа "для задачи XXX решение YYY применимо только в том случае, если потенциальные пользователи удовлетворяют требованию ZZZ. Иначе рулит решение AAA".

S>в) набор тестовых пользователей
величина очень непредсказуемая, чтобы на нее опираться при построении выводов типа если потенциальные пользователи удовлетворяют требованию ZZZ — если конечно данное решение не рассчитано именно для данного набора тестовых пользователей..

со всем остальным согласен..

Здравствуйте, DuШes, Вы писали:

DШ>в данном случае парсер проглотит строку 80х100, посчитав ее правильной, найдя в базе трубу D=80 и L=100...
Почему он ее проглотит? Уволить нафиг автора такого парсера. Правильный парсер увидит, что есть труба 80x100, и есть труба 100x80. После этого он попросит пользователя явно указать, какая из них имелась в виду.
Кроме того, результат разбора виден тут же рядом в виде

диаметр |_____________| 100
длина   |_____________|  80

И пользователь сразу видит, как его понял парсер, и понял ли вообще.
DШ>тот же диалог можно реализовать и в виде read-only текстсового поля, представляющего собой итоговую строку-характеристику наименования в определенном формате
А почему read only?
DШ>, но при вхождение в которое открывался бы режим расшифровки характеристик в виде списка отдельных полей...вопрос реализации, т.е. вначале ввод отдельных характеристик, а потом получение итоговой строки, но никак не наоборот.
Почему?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, DuШes, Вы писали:

DШ>>в данном случае парсер проглотит строку 80х100, посчитав ее правильной, найдя в базе трубу D=80 и L=100...
S>Почему он ее проглотит? Уволить нафиг автора такого парсера.
категорично ..

S>Правильный парсер увидит, что есть труба 80x100, и есть труба 100x80. После этого он попросит пользователя явно указать, какая из них имелась в виду.
S>Кроме того, результат разбора виден тут же рядом в виде
S>

S>диаметр |_____________| 100
S>длина   |_____________|  80
S>

это уже перегрузка диалога лишними контролами..

S>И пользователь сразу видит, как его понял парсер, и понял ли вообще.
как результат, вывод дополнительных диалогов...правильно ли понял???, разъясни формат???, научи как распарсить???, как следствие — лишняя нагрузка на оператора

DШ>>тот же диалог можно реализовать и в виде read-only текстсового поля, представляющего собой итоговую строку-характеристику наименования в определенном формате
S>А почему read only?
я предложил как альтернативу использованию парсингу

DШ>>, но при вхождение в которое открывался бы режим расшифровки характеристик в виде списка отдельных полей...вопрос реализации, т.е. вначале ввод отдельных характеристик, а потом получение итоговой строки, но никак не наоборот.
S>Почему?
во избежание двоякого толкования и появления ошибок в случае неправильного парсинга строки

Антон, как итог, есть две точки зрения на использование контролов с ненавязчивой валидацией ... как и раньше высказывался, нельзя вопринимать такой подход (с использованием парсера) как ману небесную,согласен, что есть случаи, когда стоит использовать (в случае очевидных вещей типа ввода даты и цифровых величин), но есть случаи, где использовать такой подход лично я опять-таки не стал бы, ты вправе соглашаться и не соглашаться. Ты оговорился, что попробуешь написать парсер ввода адреса — на сайтах ПФР и налогоплательщика выложены классификаторы КЛАДР и требования, если ты найдешь время и реализуешь ввод адреса и парсинг строки адреса — снимаю шляпу, хотя сначала оцени затраты, которые повлечет разработка такого парсера и время на валидацию и саму операцию парсинга такого рода строки...стоит ли овчинка выделки???

Здравствуйте, Sinclair, Вы писали:

[...]

выше ты приводил пример с Excel здесь

Автор: Sinclair
Дата: 01.07.05

:

я привык дату, если использую маски, вводить в формате ddmmyy, вот результат работы Excel:

Определил формат:

Ввожу данные:

Результат:

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

Здравствуйте, Sinclair, Вы писали:

S>то есть вместо простого м очевидного нажатия на кнопку, ты предлагаешь догадаться, что на серую кнопку надо навести мышку и подождать? Ни один пользователь этот квест не решит. Кроме того, даже знающий фишку пользователь вместо молниеносного появления поясняющей надписи вынужден тормозиться на hint pause, затаив мышку... Имхо — отвратительное решение.

Еще сильнее бесит вываливающееся окошко с ошибкой. На самом деле все достаточно просто и тултипс по большому счету не нужен
1. Задизейбленная кнопка ОК наглядно говорит о том, что форма заполнена с ошибками или не до конца. Когда она становится доступной для нажатия, значит все в порядке и форма заполнена. Это стандартное и ожидаемое поведение.
2. Незаполненные или поля с ошибками, как уже говорилось помечаются цветом. Так их намного проще распознать, чем в случае с вывалившимся окошком. Особый случай, если форма содержит табы, тогда незаполненные или табы с ошибками надо как-то помечать, например цветным квадратиком аля решарпер.
3. Если есть нарушение каких-то неочевидных правил, например "если дата больше 2010 года, то поле ХХХ не может содержать значение УУУ", оба поля подсвечиваются красным, и в идеальном случае, еше пишут в статусном поле описание проблемы.

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

Здравствуйте, Sinclair, Вы писали:

S>Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...

Лирическрое отступлене
Вообще, usability как раз направлено на то, чтобы челвоек делел свою работу быстро и без ошибок. Поэтому "заставить их не косячить" — это неотъемлемая часть usability. А вот как это будет сделано — это уже другой вопрос. Здесь уже зависит от ситуации. Нужно или действительно запрещеть ввод неверных данных (решение "в лоб"), или же приложение спроектировать так, чтобы юзер просто не до шел до совершения ошибки.
Иногда действительно проще ограничить свободу, не давать вводить неверные данные — проще и всё.
Чаще же действительно лучше сделать так, чтобы сценарий работы юзера по возможности не включал в себя ввод чего-то потенциально неверного или опасного.

Здравствуйте, olegkr, Вы писали:

O>еше пишут в статусном поле описание проблемы.

Как раз тут тултип гораздо более употребим, чем статусная строка.
Дело в том, что пользователь должен сначала ПОНЯТЬ, что произошла ошибка. Статусная строка как сигнализация не очень хороша.
Во-первых, не всегда можно заметить, что тест на ней изменился. Т.к. строка уже может содержать текст. если длина старого сообщения примерно равна длине нового сообщения, то заметить изменения трудно. А что делать, если ошибка повторилась второй раз подряд и сообщение совсем не изменилось? Вводить новое сообщение?
Во-вторых, мониторы все растут и растут, частенько статусная строка занимает так мало места на мониторе, что ее практически не видно.
В-третьих, несмотря на рост разрешения мониторов размер статусной строки все еще ограничен и не позволяет ввести два-три полноценных предложения. К томуже в строке может быть несколько панелей, поэтому длина сообщения очень ограничена.

Тултип тоже плохой вариант — он пропадает. А сообщения об ошибках часто содержат конкретные указания на конкретные ошибочные данные.
Поэтому, ИМХО, элемент управления для показа сообщений должен поддерживать следущие фичи:
— закрываться по требованию пользователя (и, конечно, должен закрываться приложением, когда ошибка исправлена)
— поддерживать копирование в клипборд

Я пытаюсь использовать полупрозрачное окно.



Это пробный вариант, так что прошу не пинать Тут еще работать и работать.
Думаю, что на это окно можно повесить, кроме всего прочего, дополнтельные контролы для более точной реакции пользователя на ошибки.

P.S. Для уведомления пользователя об ошибке лучше всего сопровождать сообщение звуком. Я так и делаю, и пользователи одобряют

Здравствуйте, kavlad, Вы писали:

[...]

неужелли отпуск кончился ???
а где обещанный результат в виде скриншота по теме Хочу улучшить окно сравнения параметров

Автор: kavlad
Дата: 27.06.05

???

[...]

to nzeemin — ты хоть сначала объясни с чем несогласный хотя бы в данном случае или хотя бы по данной теме

Автор: DuШes
Дата: 04.07.05

....

Здравствуйте, DuШes, Вы писали:

DШ>to nzeemin — ты хоть сначала объясни с чем несогласный хотя бы в данном случае или хотя бы по данной теме

Автор: DuШes
Дата: 04.07.05

....

В данном случае я не согласен с сообщениями не по теме. Форум usability и без того замусорен донельзя. Мне думается, это одна из причин по которым в этот форум так и не пришли настоящие юзабилисты.

В той ветке я не согласен с вашими доводами.
В частности, вы сами утверждали что не понимаете что такое "Lion Gym", однако вы беретесь делать утверждения по поводу анализа этого названия. "обязатальность знания многих форматов ввода, нагрузка на оператора и лишние требования к компетентности" — с этим также несогласен. Все необходимые доводы Sinclair уже привел, смысла их повторять не вижу.

Здравствуйте, nzeemin, Вы писали:

N>Здравствуйте, DuШes, Вы писали:

DШ>>to nzeemin — ты хоть сначала объясни с чем несогласный хотя бы в данном случае или хотя бы по данной теме

Автор: DuШes
Дата: 04.07.05

....

N>В данном случае я не согласен с сообщениями не по теме. Форум usability и без того замусорен донельзя. Мне думается, это одна из причин по которым в этот форум так и не пришли настоящие юзабилисты.

N>В той ветке я не согласен с вашими доводами.
N>В частности, вы сами утверждали что не понимаете что такое "Lion Gym", однако вы беретесь делать утверждения по поводу анализа этого названия. "

обязатальность знания многих форматов ввода, нагрузка на оператора и лишние требования к компетентности" — с этим также несогласен

ну попробуйте объяснить, как опрератор, первый раз увидевший ваше ПО, поймет как вводить к примеру строку адреса...???


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

флеймить ну буду /// расслабился

Здравствуйте, DuШes, Вы писали:

DШ>неужелли отпуск кончился ???

Почти
Отозвали из отпуска на пару часов

DШ>а где обещанный результат в виде скриншота ???

Как и обещал через пару месяцев
Пока занимаюсь другой не менее интересной темой — юзабилити в графических приложения типа Corel'а, AutoCAD'а и т.п.

K>Поэтому, ИМХО, элемент управления для показа сообщений должен поддерживать следущие фичи:
K>- закрываться по требованию пользователя (и, конечно, должен закрываться приложением, когда ошибка исправлена)
K>- поддерживать копирование в клипборд

Сегодня получил такое сообщение:



Очень хотелось скопировать адрес (подчеркнуто красным) в буфер или просто кликнуть по нему. Но пришлось набирать руками.

Здравствуйте, kavlad, Вы писали:

K>Очень хотелось скопировать адрес (подчеркнуто красным) в буфер или просто кликнуть по нему. Но пришлось набирать руками.

Ctrl — C на окне с сообщением не помогло? ОС какая?

Здравствуйте, Odi$$ey, Вы писали:

OE>Ctrl — C на окне с сообщением не помогло?

Не знаю можно ли назвать это помощью Мне ведь нужен только URL, не весь текст сообщения.
причем хотелось бы сразу открыть страничку в браузере. Это я к тому, что гиперссылка была бы гораздо удобнее.

OE>ОС какая?

Win2k SP4

Здравствуйте, nzeemin, Вы писали:

Продаю идею:

Эта идея была мной имплементирована на заре перестройки
когда мной писалась система BankMaster (клиент/сервер с dbVista на
сервере, NetBIOS в качестве протокола )

Ввод банковских документов оператором как правило осуществляется
в слепую — поэтому никаких тултипов само собой нет.

Было сделано следующее: ввод денежных сум завершался проигрыванием
музыкальной фразы — каждой цифре соответствовала своя нота.

Рекомендую.
Операторы примерно через неделю забывают про UI в принципе.

Здравствуйте, c-smile, Вы писали:

CS>Было сделано следующее: ввод денежных сум завершался проигрыванием
CS>музыкальной фразы — каждой цифре соответствовала своя нота.

CS>Рекомендую.
CS>Операторы примерно через неделю забывают про UI в принципе.

У операторов должен быть идеальный слух и познания в сольфеджио

Может лучше пойти телефонным путем и проигрывать ноту при нажатии цифровых клавиш?

Здравствуйте, nzeemin, Вы писали:

N>Давно хотел написать — про валидацию пользовательского ввода.

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

Здравствуйте, Sinclair, Вы писали:

S>должно вообще понимать в качестве десятичного разделителя и точку, и запятую.

Абсолютно верно!

Здравствуйте, DuШes, Вы писали:

А мне кажется, что несколько некорректно сравнивать два таких разных программных продукта
Особенно, на предмет одного из аспектов юзабилити — простоты ввода данных.
Простота ввода зависит в первую очередь от самих данных. Или я не правильно думаю?

Другой вопрос — категории софта. MS Money принадлежит скорее к программам, которые пользователь выбирает сам.
А софт DuШes'а — к программам, от которых пользователю никуда не деться

И не факт, что оператор сможет воспользоваться буфером обмена. Скажем, если данные вводятся с бумаги или с показаний другого человека

Здравствуйте, kavlad, Вы писали:

K>Здравствуйте, c-smile, Вы писали:

CS>>Было сделано следующее: ввод денежных сум завершался проигрыванием
CS>>музыкальной фразы — каждой цифре соответствовала своя нота.

CS>>Рекомендую.
CS>>Операторы примерно через неделю забывают про UI в принципе.

K>У операторов должен быть идеальный слух и познания в сольфеджио

Как оказалось вполне достаточно и среднего бытового слуха.
А уж сольфеджио никому не надо точно.

Динамик в PC должен быть нормальный — это да

K>Может лучше пойти телефонным путем и проигрывать ноту при нажатии цифровых клавиш?

"Мелодия" завершала набор документа — после всех проверок — контрольная сумма счетов и пр.

Здравствуйте, c-smile, Вы писали:

CS>"Мелодия" завершала набор документа — после всех проверок — контрольная сумма счетов и пр.

Тогда не очень понятен принцип определения ошибки на слух.

Здравствуйте, nzeemin, Вы писали:

N>Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…
N>[skipped]
N>До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.

Выложил реализацию под VB6: Ненавязчивая валидация &mdash; пример реализации

Автор: nzeemin
Дата: 28.07.05

S>Любить пользователей — тяжелая и неприятная работа. Если ты не можешь ее выполнять — доверь другому. А сам пиши процедурки на SQL, веб сервисы и MPEG-компрессоры

Ахтунг, извращенцы... сначала заманивают невчем не подозревающего пользователя своей программой, а потом начинают любить его!

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

После нажатия на "OK" и показа окна с сообщением об ошибочном вводе, оч. приятно бросить фокус на верхний в Tab order'е контрол с ошибкой.

Переделка в IEEE'шный формат даты строк типа "01 02"/"01/2"/"1.2"/т.п. должен зависеть от настроек системы. Т.е. если формат даты в настройках "DD/MM/YY", тогда "1 2" считается 1 февраля, а "1 30" должно вызывать ошибку; а при формате "MM/DD/YY" наоборот: "1 2" есть 2 января, "1 30" есть 30 января, а "30 1" ошибка.

В остальном, оч. сильно согласен, приятно видеть в столице такого бошковитого "гасторбайтера". ;)

PS: сорры что так поздно -- в отпуску был.
PPS: если кто-то про это тут уже сказал, ещё больше сорры -- я правда тут почти всю ветку просмотрел, не нашёл. Старею... :(

Здравствуйте, ZAMUNDA, Вы писали:

ZAM>Мнооооооогие пользователи (и не только) печатают не "слепым" методом и крайне неприятно, когда, вписав всю информацию во все поля, вдруг обнаруживаешь, что где-то ошибся, потом ищеш "нехорошие" поля, потом стираешь "нехорошие" символы. бррр...
ZAM>А звук, тем и хорош, что его в "пц шпукере" завсегда слышно!
Спорно...

ZAM>После нажатия на "OK" и показа окна с сообщением об ошибочном вводе, оч. приятно бросить фокус на верхний в Tab order'е контрол с ошибкой.
Согласен, приятно.

ZAM>Переделка в IEEE'шный формат даты строк типа "01 02"/"01/2"/"1.2"/т.п. должен зависеть от настроек системы. Т.е. если формат даты в настройках "DD/MM/YY", тогда "1 2" считается 1 февраля, а "1 30" должно вызывать ошибку; а при формате "MM/DD/YY" наоборот: "1 2" есть 2 января, "1 30" есть 30 января, а "30 1" ошибка.

Да как сказать...
Привязывать ли программу к настройкам системы — это совсем другой вопрос и к валидации ввода он прямого отношения не имеет. Эта тема называется — "internationalization"...

ZAM>В остальном, оч. сильно согласен,
В свете вышенаписанного и темы вашего сообщения — непонятно с чем же вы согласны, ну да ладно...

ZAM>приятно видеть в столице такого бошковитого "гасторбайтера".
Вот это совсем не понял. Ни про столицу, ни про гестарбайтера, ни про кавычки.

P.S. Если так пользоваться великим и могучим, то довольно скоро он станет небольшим и висящим...

Здравствуйте, nzeemin, Вы писали:

ZAM>>Мнооооооогие пользователи (и не только) печатают не "слепым" методом и крайне неприятно, когда, вписав всю информацию во все поля, вдруг обнаруживаешь, что где-то ошибся, потом ищеш "нехорошие" поля, потом стираешь "нехорошие" символы. бррр...
ZAM>>А звук, тем и хорош, что его в "пц шпукере" завсегда слышно!
N>Спорно...
ОК! Тогда это надо выносить в настройки. Хотите -- будем Beep делать, хотите -- красным выделять.

ZAM>>Переделка в IEEE'шный формат даты строк типа "01 02"/"01/2"/"1.2"/т.п. должен зависеть от настроек системы.
N>Да как сказать...
Так SYSTEM_LOCALE для того и придумано, чтоб человек мог под себя настроить... ну не знаю как сказать. Мне например нравиться Digital Separator точка и если я ставлю программулину, которая требует, чтоб ей запятую вводили -- нервы напрягаются слегонца. Я уже "не задумываясь" точку ставлю, а тут мне говорят, что я "чёта неверно ввёл". Работа от таких вещей жутко тормозиться.
Возможно, я черезчур радикален в этом вопросе, но простите, тот же Office исправно пишет "Янв" в русском мастдае и "Jan" в английском, разделители разрядов он тож системные использует. И представьте себе человек привык в отчётах в Excell "66,88 р." писать, а тут ему прогу ставят и она выкаблучивается и на это ему ошибку выдаёт. А на мольбу "девочек" и "мальчиков" о том что им хочется чтоб месяцы по русски были я ношу с собой болванку с русским виндозом на борту.

N>Привязывать ли программу к настройкам системы — это совсем другой вопрос и к валидации ввода он прямого отношения не имеет. Эта тема называется — "internationalization"...
Согласен, просто раз уж тему тут эту подняли, я и взял на себя смелость высказаться.

ZAM>>В остальном, оч. сильно согласен,
N>В свете вышенаписанного и темы вашего сообщения — непонятно с чем же вы согласны, ну да ладно...
Я согласен с тем, что в корне написано (в первом сообщении ветви). Что тут, простите, непонятного?

ZAM>>приятно видеть в столице такого бошковитого "гасторбайтера". ;)
N>Вот это совсем не понял. Ни про столицу, ни про гестарбайтера, ни про кавычки.
Ой, тут просто, с одним Грузинский программистом из Москвы общались -- был под впечатлением... сам не знаю, наверное шиза пришла, от недосыпа. :) Приношу свои извинения.

N>P.S. Если так пользоваться великим и могучим, то довольно скоро он станет небольшим и висящим...
Главное, чтоб "длинна" языка не превышала "длинну" ног.