Здравствуйте, 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. Доводы в основном базируются на некоторых заблуждениях (типа перечисленных в начале постинга).
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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Ш>у меня достаточно опыта общения и с пользователями и с заказчиками и есть опыт разработки, пусть небольшой, но все-таки чтобы судить о некоторых вещах, о которых как мне кажется я имею представление...так что не надо со мной общаться с пизиции преподавателя с глупым студентом, на которую ты к сожалению снизошел...
Меня раздражает то, что раз за разом ты продолжаешь вычитывать в моих сообщениях то, чего там нет, и игнорировать то, что там есть. Поэтому мне приходится переходить на такой тон.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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".
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DuШes, Вы писали:
DШ>вообщем, ты все равно не понял основную мысль которую я хотел донести: я как оператор, когда ввожу информацию, должен быть уверен что ввел именно то, что ввел именно я, а не то, что счел за меня парсер в лице разработавшего данный парсер программиста...ввод парсера подразумевает разрыв между действиями оператора и контролем оператора над своими же действиями...
ПОЧЕМУ?
Вот это место я не понимаю. Почему парсер не может сразу показать результат своей работы? Где разрыв? DШ>примеры я приводил даже и по outlook, когда у нас в адресной книге два человека с одинаковыми ФИО...
Угу. Лично у меня Outlook в таких случаях предлагает выбрать вручную.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Тогда можно сравнивать эффективность того или иного подхода. S>Варьируя а, б и в, можно попытаться построить некоторые далеко идущие выводы типа "для задачи XXX решение YYY применимо только в том случае, если потенциальные пользователи удовлетворяют требованию ZZZ. Иначе рулит решение AAA".
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DuШes, Вы писали:
DШ>>вообщем, ты все равно не понял основную мысль которую я хотел донести: я как оператор, когда ввожу информацию, должен быть уверен что ввел именно то, что ввел именно я, а не то, что счел за меня парсер в лице разработавшего данный парсер программиста...ввод парсера подразумевает разрыв между действиями оператора и контролем оператора над своими же действиями... S>ПОЧЕМУ? S>Вот это место я не понимаю. Почему парсер не может сразу показать результат своей работы? Где разрыв?
возращаясь к примерам с трубами здесь
раньше уже бы упомянут пример с трубой: диаметр х длина, ну и прочие характеристики, допустим, при вводе в текстовое поле осуществляется парсинг введенной строки, в базе есть трубы диаметром 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Ш>, но при вхождение в которое открывался бы режим расшифровки характеристик в виде списка отдельных полей...вопрос реализации, т.е. вначале ввод отдельных характеристик, а потом получение итоговой строки, но никак не наоборот.
Почему?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DuШes, Вы писали:
DШ>>в данном случае парсер проглотит строку 80х100, посчитав ее правильной, найдя в базе трубу D=80 и L=100... S>Почему он ее проглотит? Уволить нафиг автора такого парсера.
категорично ..
S>Правильный парсер увидит, что есть труба 80x100, и есть труба 100x80. После этого он попросит пользователя явно указать, какая из них имелась в виду. S>Кроме того, результат разбора виден тут же рядом в виде S>
это уже перегрузка диалога лишними контролами..
S>И пользователь сразу видит, как его понял парсер, и понял ли вообще.
как результат, вывод дополнительных диалогов...правильно ли понял???, разъясни формат???, научи как распарсить???, как следствие — лишняя нагрузка на оператора
DШ>>тот же диалог можно реализовать и в виде read-only текстсового поля, представляющего собой итоговую строку-характеристику наименования в определенном формате S>А почему read only?
я предложил как альтернативу использованию парсингу
DШ>>, но при вхождение в которое открывался бы режим расшифровки характеристик в виде списка отдельных полей...вопрос реализации, т.е. вначале ввод отдельных характеристик, а потом получение итоговой строки, но никак не наоборот. S>Почему?
во избежание двоякого толкования и появления ошибок в случае неправильного парсинга строки
Антон, как итог, есть две точки зрения на использование контролов с ненавязчивой валидацией ... как и раньше высказывался, нельзя вопринимать такой подход (с использованием парсера) как ману небесную,согласен, что есть случаи, когда стоит использовать (в случае очевидных вещей типа ввода даты и цифровых величин), но есть случаи, где использовать такой подход лично я опять-таки не стал бы, ты вправе соглашаться и не соглашаться. Ты оговорился, что попробуешь написать парсер ввода адреса — на сайтах ПФР и налогоплательщика выложены классификаторы КЛАДР и требования, если ты найдешь время и реализуешь ввод адреса и парсинг строки адреса — снимаю шляпу, хотя сначала оцени затраты, которые повлечет разработка такого парсера и время на валидацию и саму операцию парсинга такого рода строки...стоит ли овчинка выделки???
я привык дату, если использую маски, вводить в формате ddmmyy, вот результат работы Excel:
Определил формат:
Ввожу данные:
Результат:
еще раз оговорюсь, парсинг даты, если присуствуют любые сепараторы, достаточно тривиальная задача, но никакой парсер не предусмотрит всех вариантов, какие есть у конечного пользователя в голове...
Здравствуйте, Sinclair, Вы писали:
S>то есть вместо простого м очевидного нажатия на кнопку, ты предлагаешь догадаться, что на серую кнопку надо навести мышку и подождать? Ни один пользователь этот квест не решит. Кроме того, даже знающий фишку пользователь вместо молниеносного появления поясняющей надписи вынужден тормозиться на hint pause, затаив мышку... Имхо — отвратительное решение.
Еще сильнее бесит вываливающееся окошко с ошибкой. На самом деле все достаточно просто и тултипс по большому счету не нужен
1. Задизейбленная кнопка ОК наглядно говорит о том, что форма заполнена с ошибками или не до конца. Когда она становится доступной для нажатия, значит все в порядке и форма заполнена. Это стандартное и ожидаемое поведение.
2. Незаполненные или поля с ошибками, как уже говорилось помечаются цветом. Так их намного проще распознать, чем в случае с вывалившимся окошком. Особый случай, если форма содержит табы, тогда незаполненные или табы с ошибками надо как-то помечать, например цветным квадратиком аля решарпер.
3. Если есть нарушение каких-то неочевидных правил, например "если дата больше 2010 года, то поле ХХХ не может содержать значение УУУ", оба поля подсвечиваются красным, и в идеальном случае, еше пишут в статусном поле описание проблемы.
Итак. Есть индикация правильности заполнения формы — кнопка ОК, плюс есть индикация неправильно заполненных полей — подсветка и в сложных случаях статусное поле. Таким образом получается, что единственный случай, когда после нажатия кнопки ОК имеет смысл вываливать ошибки — ошибки валидации, занимающей продолжительное время.
Здравствуйте, Sinclair, Вы писали:
S>Вот это как бы вообще бред. Имхо, только в России могли придумать пользователя, который не понимает, чего он хочет. Прогрессивное человечество изобретает usability для того, чтобы помочь пользователям делать то, чего они хотят. А у нас, как всегда, главное — заставить их не косячить...
Лирическрое отступлене
Вообще, usability как раз направлено на то, чтобы челвоек делел свою работу быстро и без ошибок. Поэтому "заставить их не косячить" — это неотъемлемая часть usability. А вот как это будет сделано — это уже другой вопрос. Здесь уже зависит от ситуации. Нужно или действительно запрещеть ввод неверных данных (решение "в лоб"), или же приложение спроектировать так, чтобы юзер просто не до шел до совершения ошибки.
Иногда действительно проще ограничить свободу, не давать вводить неверные данные — проще и всё.
Чаще же действительно лучше сделать так, чтобы сценарий работы юзера по возможности не включал в себя ввод чего-то потенциально неверного или опасного.
Здравствуйте, olegkr, Вы писали:
O>еше пишут в статусном поле описание проблемы.
Как раз тут тултип гораздо более употребим, чем статусная строка.
Дело в том, что пользователь должен сначала ПОНЯТЬ, что произошла ошибка. Статусная строка как сигнализация не очень хороша.
Во-первых, не всегда можно заметить, что тест на ней изменился. Т.к. строка уже может содержать текст. если длина старого сообщения примерно равна длине нового сообщения, то заметить изменения трудно. А что делать, если ошибка повторилась второй раз подряд и сообщение совсем не изменилось? Вводить новое сообщение?
Во-вторых, мониторы все растут и растут, частенько статусная строка занимает так мало места на мониторе, что ее практически не видно.
В-третьих, несмотря на рост разрешения мониторов размер статусной строки все еще ограничен и не позволяет ввести два-три полноценных предложения. К томуже в строке может быть несколько панелей, поэтому длина сообщения очень ограничена.
Тултип тоже плохой вариант — он пропадает. А сообщения об ошибках часто содержат конкретные указания на конкретные ошибочные данные.
Поэтому, ИМХО, элемент управления для показа сообщений должен поддерживать следущие фичи:
— закрываться по требованию пользователя (и, конечно, должен закрываться приложением, когда ошибка исправлена)
— поддерживать копирование в клипборд
Я пытаюсь использовать полупрозрачное окно.
Это пробный вариант, так что прошу не пинать Тут еще работать и работать.
Думаю, что на это окно можно повесить, кроме всего прочего, дополнтельные контролы для более точной реакции пользователя на ошибки.
P.S. Для уведомления пользователя об ошибке лучше всего сопровождать сообщение звуком. Я так и делаю, и пользователи одобряют
хотя вроде и примеров и доводов было предостаточно
для задачи парсинга вводимой пользователем строки, когда туже задачу можно решить проще и удобнее для пользователя, дав ему контроль над своими же действиями...
Тут еще работать и работать.
