Здравствуйте, 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%...