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

А>Что посоветуете?

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

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

S> AN>Нашел это, но про property grid там ничего нет

S> Вот именно.
Да я там вообще про компъютеры нечего не нашел.
Просмотрел Visual Display of Quantitative Information и не нашел ничего нового.
Может на то время это и было новым.

S> S>> Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.

S> AN>Пока не было ни одной задачи где бы он не подошел. И почему только один?

S> Потому что в нём нет никаких средств по согласованному изменению нескольких атрибутов.
А примерчик задачи можно? Зависимости, да попадались. Но изменяя в одном месте на 5 мне совсем не хочется чтобы в другом месте стало автоматом 10.
И что, кстати хорошо справляется с данной задачей?

S> AN>При чем здесь property grid?
S> AN>- Идешь в магазин, покупаешь карточку, вводишь номер.
S> AN>Или
S> AN>- Заключаешь договор с оператором и он снимает денюжку прямо о счета.

S> Совершенно верно. Как видите, property grid здесь ни при чём. А вы говорите — нет ни одной задачи, где бы он не подошёл.
Ну к словам можно до бесконечности цепляться. Давайте тогда порассуждаем почему при варке кофе также не требуется проперти грид.

S> S>> В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".

S> AN>Но период это и 1.3.2011-5.10.2011.

S> Вы опять уходите от решения задачи. Задачи вводить произвольный период не стояло. Если двигаться дальше по вашему пути, то мы получим просто проклятие для оператора: неудобный, замедляющий работу контрол, который требует вводить две даты там, где нужно просто выбрать месяц.
Не ухожу, а пытаюсь представить, что может быть. А если человек хочет за полмесяца заплатить?

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

S> S>> Вы слишком плохо думаете о клиентах, и слишком хорошо — о ТЗ. Ничего, это пройдёт

S> AN>И сколько еще нужно ждать?

S> Ждать ничего не нужно. Нужно работать над собой. Читать различные источники, смотреть на опыт передовиков, экспериментировать, много думать.
А что если год думать о клиенте, он похорошеет?
Есть ясно выраженное желание пользователя, хочу вводить дату только цифрами.
Можно прочитать тонну источников, пересмотреть опыт сотни передовиков, проделать тысячу экспериментов, но от этого его желание никак не изменится.

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

AN>Да я там вообще про компъютеры нечего не нашел.
А про компьютеры всё то же самое применимо. Включая visual clutter, которого в проперти гриде изрядный запас.
AN>Просмотрел Visual Display of Quantitative Information и не нашел ничего нового.
А где это ты сумел его просмотреть?

S>> Потому что в нём нет никаких средств по согласованному изменению нескольких атрибутов.
AN>А примерчик задачи можно? Зависимости, да попадались. Но изменяя в одном месте на 5 мне совсем не хочется чтобы в другом месте стало автоматом 10.
Ну почему же не хочется? Очень много есть задач, где сие имеет великий смысл. Элементарная штука — когда я меняю толщину бордера у ячейки, я как правило хочу поменять её у всех четырёх границ. Но иногда я хочу изменять её по отдельности для каждой стороны.

AN>И что, кстати хорошо справляется с данной задачей?
Конечно же, с данной задачей хорошо справляется специализированный UI.

AN>Ну к словам можно до бесконечности цепляться. Давайте тогда порассуждаем почему при варке кофе также не требуется проперти грид.
Это вы цепляетесь к словам. Ну попробуйте представить интерфейс отправки электронного письма в виде проперти грида.
Или интерфейс планирования встречи с несколькими участниками. Или интерфейс бронирования авиабилета.
Технически — никаких проблем. Вот только пользоваться таким UI будет крайне неудобно.

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

S>> Ждать ничего не нужно. Нужно работать над собой. Читать различные источники, смотреть на опыт передовиков, экспериментировать, много думать.
AN>А что если год думать о клиенте, он похорошеет?
Нет — есть шанс начать понимать мотивацию клиента. Он перестанет быть плохим и станет понятным.
AN>Есть ясно выраженное желание пользователя, хочу вводить дату только цифрами.
AN>Можно прочитать тонну источников, пересмотреть опыт сотни передовиков, проделать тысячу экспериментов, но от этого его желание никак не изменится.
То есть вы пробовали — прочли тонну источников, пересмотрели опыт сотни передовиков, проделали тысячу экспериментов, показали всё это клиенту, выяснили у него, зачем ему именно цифры, какую проблему он решает, и он всё ещё не согласен?

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

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

C>+1, только формат должен быть YYYY-MM, согласно ISO 8601.
Итого имеем требование вводить 6 символов там, где хватило бы 2х?
В 99% случаев год не меняется от ввода к вводу.

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

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

C>>+1, только формат должен быть YYYY-MM, согласно ISO 8601.
S>Итого имеем требование вводить 6 символов там, где хватило бы 2х?
S>В 99% случаев год не меняется от ввода к вводу.

Ну так пусть последнее введённое значение подставляется по умолчанию, и, может быть, выделяются две последние цифры. А то и вообще — пусть по умолчанию предлагается период от первого неоплаченного месяца до предыдущего включительно. Пользователь не должен помнить, когда он последний раз платил, и сколько будет 2011-03 + P1M.

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

S> AN>Да я там вообще про компъютеры нечего не нашел.

S> А про компьютеры всё то же самое применимо. Включая visual clutter, которого в проперти гриде изрядный запас.
Это?
Сложно как то мне представить, что это конкретно в гриде.

S> AN>Просмотрел Visual Display of Quantitative Information и не нашел ничего нового.

S> А где это ты сумел его просмотреть?
Книги можно не только читать, но и просматривать , а где — гугла сказала.

S> S>> Потому что в нём нет никаких средств по согласованному изменению нескольких атрибутов.

S> AN>А примерчик задачи можно? Зависимости, да попадались. Но изменяя в одном месте на 5 мне совсем не хочется чтобы в другом месте стало автоматом 10.

S> Ну почему же не хочется? Очень много есть задач, где сие имеет великий смысл. Элементарная штука — когда я меняю толщину бордера у ячейки, я как правило хочу поменять её у всех четырёх границ. Но иногда я хочу изменять её по отдельности для каждой стороны.
И как оно будет угадывать желания? 5 полей довольно неплохое решение

S> AN>И что, кстати хорошо справляется с данной задачей?

S> Конечно же, с данной задачей хорошо справляется специализированный UI.
А что мешает сделать специализированый редактор?

S> AN>Ну к словам можно до бесконечности цепляться. Давайте тогда порассуждаем почему при варке кофе также не требуется проперти грид.

S> Это вы цепляетесь к словам.
Ну тогда вы неправильно истолковали мое предложение, а я Ваше.

S> Ну попробуйте представить интерфейс отправки электронного письма в виде проперти грида.
S> Или интерфейс планирования встречи с несколькими участниками. Или интерфейс бронирования авиабилета.
S> Технически — никаких проблем. Вот только пользоваться таким UI будет крайне неудобно.
Я не имел в виду его использовать абсолютно везде.
Вот например какой контрол будет удобен в данном случае?
Есть набор некоторых данных, их нужно отображать и редактировать. Какие именно будут данные можно узнать только перед отображением всего набора. При этом высота экрана ограничена гораздо больше чем ширина. Данные должны быть сгруппированы в группы. Все данные желательно увидеть на одном экране. Ну и там по мелочам, типа нужно показывать статус данных (правильные/ неправильные, ошибка записи, изменение невозможно) пределы ввода и описание каждого поля.

S> AN>Не ухожу, а пытаюсь представить, что может быть. А если человек хочет за полмесяца заплатить?

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

S> Вот вам пример ответа на ваш вопрос: за полмесяца заплатить невозможно. Можно провести частичный платёж за один месяц.
Вот как раз на эту тему и можно побеседовать с заказчиком. А если клиент хочет заплатить за год вперед?

S> S>> Ждать ничего не нужно. Нужно работать над собой. Читать различные источники, смотреть на опыт передовиков, экспериментировать, много думать.

S> AN>А что если год думать о клиенте, он похорошеет?

S> Нет — есть шанс начать понимать мотивацию клиента. Он перестанет быть плохим и станет понятным.

S> AN>Есть ясно выраженное желание пользователя, хочу вводить дату только цифрами.
S> AN>Можно прочитать тонну источников, пересмотреть опыт сотни передовиков, проделать тысячу экспериментов, но от этого его желание никак не изменится.

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

S> В моём опыте так бывает очень-очень-очень редко.
У нас с Вами разный опыт...
S> Чаще бывает как раз наоборот: программисты приносят клиенту настолько дурацкие и непродуманные решения, что он волей-неволей начинает проектировать сам.
В данном случае клиент просто позвонит в другую фирму. Ничего они сами не делают, наоборот нужно клещами вытягивать, а что же нужно на самом то деле.

S> А программисты потом жалуются на то, что клиент хочет странного.
И не только они.

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

S>> А про компьютеры всё то же самое применимо. Включая visual clutter, которого в проперти гриде изрядный запас.
AN>Это?
AN>Сложно как то мне представить, что это конкретно в гриде.
Это сам грид. Все эти разделительные линии и заливки фона только отвлекают от данных.

S>> А где это ты сумел его просмотреть?
AN>Книги можно не только читать, но и просматривать , а где — гугла сказала.
Удивительно. Обычно прочтение книги Tufte в первый раз занимает месяца полтора. Простите, я как-то не верю в то, что вы её прочитали. Если вы просмотрели только оглавление — поверьте, этого недостаточно.
К тому же ваши вопросы про visual clutter как бы намекают, что у Tufte для вас ещё очень много нового.

S>> Ну почему же не хочется? Очень много есть задач, где сие имеет великий смысл. Элементарная штука — когда я меняю толщину бордера у ячейки, я как правило хочу поменять её у всех четырёх границ. Но иногда я хочу изменять её по отдельности для каждой стороны.
AN>И как оно будет угадывать желания? 5 полей довольно неплохое решение
5 полей — отвратительное решение. Нормальное решение — это как в CSS набор значений для border-width. Почитайте, очень познавательно. Нормальное решение — как в Excel, где у меня есть фишки типа Ctrl-D для быстрого заполнения значениями группы ячеек. Проперти грид — это нищета и убогость. Всё равно как защищать преимущества водоразборной колонки перед водопроводом.

AN>А что мешает сделать специализированый редактор?
Ничего не мешает. Кроме уверенности в том, что Property Grid уже и так достаточно хорош.

AN>Я не имел в виду его использовать абсолютно везде.
AN>Вот например какой контрол будет удобен в данном случае?
AN>Есть набор некоторых данных, их нужно отображать и редактировать. Какие именно будут данные можно узнать только перед отображением всего набора. При этом высота экрана ограничена гораздо больше чем ширина. Данные должны быть сгруппированы в группы. Все данные желательно увидеть на одном экране. Ну и там по мелочам, типа нужно показывать статус данных (правильные/ неправильные, ошибка записи, изменение невозможно) пределы ввода и описание каждого поля.
В таком случае любой контрол будет неудобен. Потому, что мы не знаем ничего о природе действий, которые хочет выполнять пользователь. Мы не знаем ничего о том, что именно понимается под "отображать".

Главное — понять, что таких случаев бывает бесконечно мало. Естественное желание программиста — свести задачу к уже решённой. Поэтому кажется, что для Property Grid подходит всё. Надо это инстинктивное желание подавлять, воспитывая в себе желание делать удобные интерфейсы. Программ типа ADSI Edit или Regedit — единицы. В реальности почти всегда заранее известно, какой набор данных будет показываться и что именно хочет делать с ним пользователь. Или, по крайней мере, надо стараться об этом узнавать.
AN>Если есть у кого выяснять.
А у вас что, клиент уже умер?

AN>Вот как раз на эту тему и можно побеседовать с заказчиком. А если клиент хочет заплатить за год вперед?
Значит нужно предусмотреть такой use-case. Не обязательно делать его прямо в форме. Может быть, имеет смысл сделать кнопку "Повторить N раз" для уже забитой платёжки, которая размножит её, автоматически расставляя месяцы.
Нужно понимать соотношение частот этих use-cases. Вот вы ради редчайшего случая оплаты за полмесяца уже готовы увеличить втрое объём вводимых данных для всех случаев вообще. А должно быть строго наоборот: можно пожертвовать удобством редкого случая, если это приведёт к оптимизации доминирующего сценария. Потому, что средние затраты времени складываются из произведений времён каждого сценария на частоту его использования.

AN>У нас желания клиента закон. Можно до подписания договора, сказать что это не сможем реализовать и указать отдельным пунктом, при согласии. Можно еще предложить, что то более лучшее. (но при этом столько бумажной волокиты). Но когда у клиента по всем бумагам проходит дата в виде цифр, то здесь и смысла нет переубеждать.
Ну, с таким подходом я рекомендую вам забить на вопросы usability. Если нет смысла переубеждать клиента, то обобщённый интерфейс а-ля Regedit прекрасно подойдёт.

AN>В данном случае клиент просто позвонит в другую фирму. Ничего они сами не делают, наоборот нужно клещами вытягивать, а что же нужно на самом то деле.
Ну как же не делают — вот вы сами говорите, что клиент в куче бумаг за вас решает, в каком формате контрол будет принимать данные. Что на мой взгляд крайне подозрительно. Было бы нормально, если бы они требовали определённый формат в выходных документах. А вот то, как устроен UI, не должно быть их заботой.
Клещами вытягивать конечно нужно. Ну, кроме случая оффшора. Тогда можно и забить — проектирование выполняется не вами, от вас требуется только аккуратный кодинг. Тогда остаётся только читать источники, сравнивать реализации — в ожидании шанса перейти на более высокое место в пищевой цепочке.

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

S> S>> А про компьютеры всё то же самое применимо. Включая visual clutter, которого в проперти гриде изрядный запас.

S> AN>Это?
S> AN>Сложно как то мне представить, что это конкретно в гриде.

S> Это сам грид. Все эти разделительные линии и заливки фона только отвлекают от данных.
А мне они очень нравятся, можно даже все убрать нафиг и что тогда получится?

S> S>> А где это ты сумел его просмотреть?

S> AN>Книги можно не только читать, но и просматривать , а где — гугла сказала.

S> Удивительно. Обычно прочтение книги Tufte в первый раз занимает месяца полтора. Простите, я как-то не верю в то, что вы её прочитали. Если вы просмотрели только оглавление — поверьте, этого недостаточно.
Так я и не говорил что прочитал, я ее просмотрел. Вроде об этом и вопрос был.
S> К тому же ваши вопросы про visual clutter как бы намекают, что у Tufte для вас ещё очень много нового.
Может быть, но читать что матрицу лучше представлять в виде графиков как то совсем неинтересно, как и то что было на картах 1686 года. Я уж лучше Кнута почитаю....

S> S>> Ну почему же не хочется? Очень много есть задач, где сие имеет великий смысл. Элементарная штука — когда я меняю толщину бордера у ячейки, я как правило хочу поменять её у всех четырёх границ. Но иногда я хочу изменять её по отдельности для каждой стороны.

S> AN>И как оно будет угадывать желания? 5 полей довольно неплохое решение

S> 5 полей — отвратительное решение. Нормальное решение — это как в CSS набор значений для border-width. Почитайте, очень познавательно.
Как понимаю это
А как мне проверить и сказать пользователю, что 10 пикселей слева нельзя вводить (точнее даже не позволить ему это сделать) и какую к этому нужно еще писать документацию, что бы все описать.

Нормальное решение — как в Excel, где у меня есть фишки типа Ctrl-D для быстрого заполнения значениями группы ячеек.
Хотел бы я глянуть как этим пользоваться при готовой форме, при том что пользователь хочет назначить всем 10 а этого нельзя делать.

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

S> AN>А что мешает сделать специализированый редактор?

S> Ничего не мешает. Кроме уверенности в том, что Property Grid уже и так достаточно хорош.
Оригинальный от микрософта без переделок использовать не удалось.

S> AN>Я не имел в виду его использовать абсолютно везде.
S> AN>Вот например какой контрол будет удобен в данном случае?
S> AN>Есть набор некоторых данных, их нужно отображать и редактировать. Какие именно будут данные можно узнать только перед отображением всего набора. При этом высота экрана ограничена гораздо больше чем ширина. Данные должны быть сгруппированы в группы. Все данные желательно увидеть на одном экране. Ну и там по мелочам, типа нужно показывать статус данных (правильные/ неправильные, ошибка записи, изменение невозможно) пределы ввода и описание каждого поля.

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

S> Главное — понять, что таких случаев бывает бесконечно мало. Естественное желание программиста — свести задачу к уже решённой. Поэтому кажется, что для Property Grid подходит всё. Надо это инстинктивное желание подавлять, воспитывая в себе желание делать удобные интерфейсы. Программ типа ADSI Edit или Regedit — единицы. В реальности почти всегда заранее известно, какой набор данных будет показываться и что именно хочет делать с ним пользователь. Или, по крайней мере, надо стараться об этом узнавать.
Все что можно узнать это то что пользователь хочет изменять данные, в дополнение можно статистику узнать какие поля будут изменятся с большей вероятностью.
Ну возьмем допустим "настройки программы". Да, на данный момент времени известен набор данных,но вот что с ними захочет сделать пользователь кроме как изменить?

S> AN>Если есть у кого выяснять.

S> А у вас что, клиент уже умер?
Имелся в виду конкретный ответ в форум.

S> AN>Вот как раз на эту тему и можно побеседовать с заказчиком. А если клиент хочет заплатить за год вперед?

S> Значит нужно предусмотреть такой use-case. Не обязательно делать его прямо в форме. Может быть, имеет смысл сделать кнопку "Повторить N раз" для уже забитой платёжки, которая размножит её, автоматически расставляя месяцы.
А если таких use-case-ов будет вагон и маленькая тележка и к тому же даже и заказчик не знает их всех.
S> Нужно понимать соотношение частот этих use-cases. Вот вы ради редчайшего случая оплаты за полмесяца уже готовы увеличить втрое объём вводимых данных для всех случаев вообще.
S> А должно быть строго наоборот: можно пожертвовать удобством редкого случая, если это приведёт к оптимизации доминирующего сценария.
Можно тогда только один доминирующий сценарий сделать, а все остальное низзя. И кому это будет тогда нужно? Тем более, что заказчик написал в договоре что он это хочет.

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

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

S> Ну, с таким подходом я рекомендую вам забить на вопросы usability. Если нет смысла переубеждать клиента, то обобщённый интерфейс а-ля Regedit прекрасно подойдёт.
А как вы себе представляете сказать клиенту с более тысячи сотрудников и годами отработанным документооборотом, что давайте мы ваши документы изменим и переучим всех сотрудников делать по другому?

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

S> Ну как же не делают — вот вы сами говорите, что клиент в куче бумаг за вас решает, в каком формате контрол будет принимать данные.
Это у него в бумагах везде стоит дата в числовом формате. Соотвественно в этом же формате нужно и вводить.

S> Что на мой взгляд крайне подозрительно. Было бы нормально, если бы они требовали определённый формат в выходных документах. А вот то, как устроен UI, не должно быть их заботой.
Он им должен нравится.
S> Клещами вытягивать конечно нужно. Ну, кроме случая оффшора. Тогда можно и забить — проектирование выполняется не вами, от вас требуется только аккуратный кодинг. Тогда остаётся только читать источники, сравнивать реализации — в ожидании шанса перейти на более высокое место в пищевой цепочке.
На пищу пока не жалуемся

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

AN>А мне они очень нравятся, можно даже все убрать нафиг и что тогда получится?
Читайте Tufte.

AN>Может быть, но читать что матрицу лучше представлять в виде графиков как то совсем неинтересно, как и то что было на картах 1686 года. Я уж лучше Кнута почитаю....
Очень зря. Tufte — это лучшее, что написано на тему информационного дизайна. Если вам не нравится UI — не занимайтесь им. Кнут хорош в некоторых отдельных частных вопросах программирования на C++. К сожалению, в UI он далеко не эксперт.

AN>Как понимаю это
AN>А как мне проверить и сказать пользователю, что 10 пикселей слева нельзя вводить (точнее даже не позволить ему это сделать) и какую к этому нужно еще писать документацию, что бы все описать.
Где там нельзя слева вводить 10 пикселей?

AN>Хотел бы я глянуть как этим пользоваться при готовой форме, при том что пользователь хочет назначить всем 10 а этого нельзя делать.
Почему нельзя? Что вы называете "готовой формой"? Я говорю о проектировании UI, ориентированного на сценарии.
У вас почему-то в голове всё время один и тот же сценарий "мы хотим показать неизвестно какие данные, с которыми пользователь хочет сделать неизвестно что".
S>> Ничего не мешает. Кроме уверенности в том, что Property Grid уже и так достаточно хорош.
AN>Оригинальный от микрософта без переделок использовать не удалось.
Переделки пропертигрида обычно сводятся к поддержке локализации. Парадигму интерфейса это никак не исправляет.

S>> В таком случае любой контрол будет неудобен. Потому, что мы не знаем ничего о природе действий, которые хочет выполнять пользователь. Мы не знаем ничего о том, что именно понимается под "отображать".
AN>Для каждого элемента данных известно как его отображать обычно это или цифры или текст. Пользователю нужно изменить эти данные.
Хохотался. Вот, к примеру, возьмем автомобильный маршрут. Там внутри вполне себе цифры — координаты пунктов назначения. И текст — названия этиъ пунктов. Вы что, серъёзно полагаете, что показ пунктов назначения в таблице, с кнопкой Add New и редактором через Property Grid хоть как-то сопоставим по удобству с UI типа maps.google.com?

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

S>> А должно быть строго наоборот: можно пожертвовать удобством редкого случая, если это приведёт к оптимизации доминирующего сценария.
AN>Можно тогда только один доминирующий сценарий сделать, а все остальное низзя. И кому это будет тогда нужно? Тем более, что заказчик написал в договоре что он это хочет.
Иногда можно. Потому, что среднее время выполнения редкого сценария = срокам выпуска версии с его поддержкой.
И иногда получается так, что заказчику выгоднее запуститься сейчас без редкого сценария, чем задерживать выпуск.
Но в большинстве случаев вы можете считать, что так нельзя — потому что как бы мала ни была частота использования редкого сценария, умноженная на бесконечность (время выполнения нереализованной задачи) она порвёт среднее время.
Логика понятна?
AN>Если выявляется такое узкое место, его можно выделить в дополнительный сценарий.
Вы под узким местом имеете в виду "самый частый сценарий"? Интересный подход: вы хотите начинать с самых редких краевых случаев, а потом вводить "дополнительный сценарий". Это всё равно как зарезервировать главный вход в Лужники для инвалидов и оборудовать подъемными платформами, а всех остальных пускать через заднюю дверцу.

AN>А как вы себе представляете сказать клиенту с более тысячи сотрудников и годами отработанным документооборотом, что давайте мы ваши документы изменим и переучим всех сотрудников делать по другому?
Не понимаю вашей проблемы. У клиента годами отработанный документооборот электронный? UI уже спроектирован? Тогда не парьте мне и себе мозг и делайте так, как было. Потому что удобно == привычно.
Если документооборот был бумажный, а вы разрабатываете его автоматизацию, то, простите, разговоры про "переучивание" — ерунда. Всё равно всех придётся учить новой системе. Умение системы распознавать "5 мая" вместо 5.5 — такая мелочь по сравнению с обучением пользованию вашей программой вообще, что его даже обсуждать не стоит.

AN>Это у него в бумагах везде стоит дата в числовом формате. Соотвественно в этом же формате нужно и вводить.
Вот это утверждение — это вы сами придумали, или вам клиент в договоре прописал "всё вводится строго в том же формате, что и выводится"?

AN>Он им должен нравится.
Нравиться будет удобный UI. Чтобы научиться делать удобный UI, нужно читать источники, смотреть образцы, много думать.

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

S> AN>А мне они очень нравятся, можно даже все убрать нафиг и что тогда получится?

S> Читайте Tufte.
Видел пока только пример с гистограммой, с точки зрения дизайна довольно неплохо, но таких графиком мне бы не очень хотелось иметь (как пользователю).

S> AN>Может быть, но читать что матрицу лучше представлять в виде графиков как то совсем неинтересно, как и то что было на картах 1686 года. Я уж лучше Кнута почитаю....

S> Очень зря. Tufte — это лучшее, что написано на тему информационного дизайна.
То бишь нет практически ничего.
S> Если вам не нравится UI — не занимайтесь им.
Я не занимаюсь исключительно дизайном, но иногда нужно делать формы ввода.
Может я просто не понял как нужно читать Tufte (тяжело представить, что делать с 200 страницами месяц)
S> Кнут хорош в некоторых отдельных частных вопросах программирования на C++. К сожалению, в UI он далеко не эксперт.
Я этого и не утверждал что он эксперт UI, но там для меня можно найти гораздо больше полезного и не только применительно к плюсам.

S> AN>Как понимаю это
S> AN>А как мне проверить и сказать пользователю, что 10 пикселей слева нельзя вводить (точнее даже не позволить ему это сделать) и какую к этому нужно еще писать документацию, что бы все описать.

S> Где там нельзя слева вводить 10 пикселей?
Совсем наоборот, "у меня есть" ограничение на входные данные.

S> AN>Хотел бы я глянуть как этим пользоваться при готовой форме, при том что пользователь хочет назначить всем 10 а этого нельзя делать.

S> Почему нельзя? Что вы называете "готовой формой"? Я говорю о проектировании UI, ориентированного на сценарии.
Готовая форма, та что видит пользователь и может использовать.
Вот у нас есть 10 полей для ввода данных, как минимум нужен способ их выделения.

S> У вас почему-то в голове всё время один и тот же сценарий "мы хотим показать неизвестно какие данные, с которыми пользователь хочет сделать неизвестно что".
Ну так, в основном и получается. Есть данные и есть пользователь.

S> S>> Ничего не мешает. Кроме уверенности в том, что Property Grid уже и так достаточно хорош.

S> AN>Оригинальный от микрософта без переделок использовать не удалось.

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

S> Парадигму интерфейса это никак не исправляет.
Безусловно нет. Но я получаю контрол управляемый данными.

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

S> AN>Для каждого элемента данных известно как его отображать обычно это или цифры или текст. Пользователю нужно изменить эти данные.

S> Хохотался. Вот, к примеру, возьмем автомобильный маршрут. Там внутри вполне себе цифры — координаты пунктов назначения. И текст — названия этиъ пунктов. Вы что, серъёзно полагаете, что показ пунктов назначения в таблице, с кнопкой Add New и редактором через Property Grid хоть как-то сопоставим по удобству с UI типа maps.google.com?
Если использовать обычный грид не вижу отличий, а даже плюс, не нужно нажимать кнопку добавить.

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

S> Вы делаете очень категоричное утверждение. У него нет шансов оказаться истинным в сколь-нибудь широкой области определения.
Пока что обратного, я не встречал, вполне возможно у Вас другой опыт.

S> AN>Ну возьмем допустим "настройки программы". Да, на данный момент времени известен набор данных,но вот что с ними захочет сделать пользователь кроме как изменить?

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

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

S> AN>Можно тогда только один доминирующий сценарий сделать, а все остальное низзя. И кому это будет тогда нужно? Тем более, что заказчик написал в договоре что он это хочет.

S> Иногда можно. Потому, что среднее время выполнения редкого сценария = срокам выпуска версии с его поддержкой.
S> И иногда получается так, что заказчику выгоднее запуститься сейчас без редкого сценария, чем задерживать выпуск.
Иногда это возможно, но не учитывая проблемы редкого сценария можно нарваться на полную переделку продукта.
S> Но в большинстве случаев вы можете считать, что так нельзя — потому что как бы мала ни была частота использования редкого сценария, умноженная на бесконечность (время выполнения нереализованной задачи) она порвёт среднее время.
S> Логика понятна?
Не совсем.
S> AN>Если выявляется такое узкое место, его можно выделить в дополнительный сценарий.

S> Вы под узким местом имеете в виду "самый частый сценарий"? Интересный подход: вы хотите начинать с самых редких краевых случаев, а потом вводить "дополнительный сценарий". Это всё равно как зарезервировать главный вход в Лужники для инвалидов и оборудовать подъемными платформами, а всех остальных пускать через заднюю дверцу.
Довольно часто "самый любимый" сценарий неизвестен, либо он "конфликтует" с обычным вводом. Типа для обычного ввода требуется изменять от 5 до 10 параметров для одной "единицы" ввода. А для самого любимого нужно менять один параметр, но уже для сотни "единиц" ввода. Под единицей ввода можно подразумевать документ, либо устройство, либо еще что имеет пользователь.

S> AN>А как вы себе представляете сказать клиенту с более тысячи сотрудников и годами отработанным документооборотом, что давайте мы ваши документы изменим и переучим всех сотрудников делать по другому?

S> Не понимаю вашей проблемы. У клиента годами отработанный документооборот электронный? UI уже спроектирован? Тогда не парьте мне и себе мозг и делайте так, как было.
UI уже спроектирован в екзеле
S> Потому что удобно == привычно.
Ну вот именно от этого я отталкиваюсь, если все вводили годами дату цифрами, а мы говорим, послушайте, но ведь на порядок удобнее вводить дату буквами, поэтому мы вам сделаем ввод буквами.
S> Если документооборот был бумажный, а вы разрабатываете его автоматизацию, то, простите, разговоры про "переучивание" — ерунда. Всё равно всех придётся учить новой системе.
Дело не только в обучении. Человек при вводе видит дату "цифрами", значит ему это надо "переводит" в "буквы", как и тому кто видит буквы обратно переводить в цифры.
S> Умение системы распознавать "5 мая" вместо 5.5 — такая мелочь по сравнению с обучением пользованию вашей программой вообще, что его даже обсуждать не стоит.
А вы уверены, что на китайском данный алгоритм также будет работать?

S> AN>Это у него в бумагах везде стоит дата в числовом формате. Соотвественно в этом же формате нужно и вводить.

S> Вот это утверждение — это вы сами придумали, или вам клиент в договоре прописал "всё вводится строго в том же формате, что и выводится"?
Это вроде как само собой разумеется. Исходный формат документов должен отображаться на систему ввода. Иначе оператор нифига не сможет ввести и сравнить.

S> AN>Он им должен нравится.

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

S>> Читайте Tufte.
AN>Видел пока только пример с гистограммой, с точки зрения дизайна довольно неплохо, но таких графиком мне бы не очень хотелось иметь (как пользователю).
Нда. Одного примера маловато.

AN>То бишь нет практически ничего.
В каком смысле практически ничего? Я привёл ссылки на четыре книги. Каждая — на месяц чтения.
Помимо этого, читайте Стивена Круга.

AN>Я не занимаюсь исключительно дизайном, но иногда нужно делать формы ввода.
Если вы вдохновение для форм ввода черпаете в Страуструпе, то результат предсказуем.

AN>Может я просто не понял как нужно читать Tufte (тяжело представить, что делать с 200 страницами месяц)
Читать, пытаться понять. Я до сих пор не могу понять, каким образом вы ухитрились не найти там ничего нового, и при этом не знать ничего из того, о чём он пишет.

S>> Где там нельзя слева вводить 10 пикселей?
AN>Совсем наоборот, "у меня есть" ограничение на входные данные.
Какое ограничение, на какие данные? У меня нет телепатических способностей.

AN>Готовая форма, та что видит пользователь и может использовать.
AN>Вот у нас есть 10 полей для ввода данных, как минимум нужен способ их выделения.
Ничего не понимаю. Для чего вам нужен способ их выделения?

AN>Ну так, в основном и получается. Есть данные и есть пользователь.
Это получается не случайно. Это результат ваших действий (или бездействий).
AN>Безусловно нет. Но я получаю контрол управляемый данными.
Это практически полная гарантия плохой usability.

S>> Хохотался. Вот, к примеру, возьмем автомобильный маршрут. Там внутри вполне себе цифры — координаты пунктов назначения. И текст — названия этиъ пунктов. Вы что, серъёзно полагаете, что показ пунктов назначения в таблице, с кнопкой Add New и редактором через Property Grid хоть как-то сопоставим по удобству с UI типа maps.google.com?
AN>Если использовать обычный грид не вижу отличий, а даже плюс, не нужно нажимать кнопку добавить.
Если вы не видите отличий между таблицей с координатами и маршрутом на карте, то мне жаль ваших пользователей.
Попробуйте по табличному представлению узнать, проходит ли проложенный маршрут по побережью.

S>> Например, пользователь может захотеть найти настройку, которая его интересует. При этом он не знает точно, как именно она называется, и в какой группе она зарыта.
AN>Это как принеси "мне то не знаю что" и как он будет это искать. Если достаточно большой процент пользователей это хотят, то об этом можно каким то образом узнать и сделать. Если же это случайно захотел один, то об этом часто не узнать, да и делать никто не будет.
Я вам открою тайну: в 2011 году почти все развитые "настройки" оборудовали возможностями поиска. Началось это с Маков, сейчас то же самое имеем в Винде.

AN>Не совсем.
В таком случае просто примите как данность, что из утверждения "вы обязаны оптимизировать UI для частых случаев" утверждение "для редких случаев UI можно не делать вообще" логически не выводится, и делайте UI для всех случаев.

AN>Довольно часто "самый любимый" сценарий неизвестен, либо он "конфликтует" с обычным вводом. Типа для обычного ввода требуется изменять от 5 до 10 параметров для одной "единицы" ввода. А для самого любимого нужно менять один параметр, но уже для сотни "единиц" ввода. Под единицей ввода можно подразумевать документ, либо устройство, либо еще что имеет пользователь.
Не вижу никакого конфликта. Главное — не пытаться запихнуть два этих совершенно разных сценария в один и тот же UI.

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

AN>Дело не только в обучении. Человек при вводе видит дату "цифрами", значит ему это надо "переводит" в "буквы", как и тому кто видит буквы обратно переводить в цифры.
Не надо никому ничего переводить.

AN>А вы уверены, что на китайском данный алгоритм также будет работать?
1. Вы разрабатываете систему для китайского рынка?
2. Поставьте китайскую локаль и проверьте в Excel.

AN>Это вроде как само собой разумеется. Исходный формат документов должен отображаться на систему ввода. Иначе оператор нифига не сможет ввести и сравнить.
Ну, как принцип это годится. Как догма — нет.

S>> Нравиться будет удобный UI. Чтобы научиться делать удобный UI, нужно читать источники, смотреть образцы, много думать.
AN>Обычно, в дополнение, это процесс интерактивный, сделали, проверили, сделали еще раз...
Это если есть такая возможность. У вас, я так понял, такой возможности нету.

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

S> S>> Читайте Tufte.

S> AN>Видел пока только пример с гистограммой, с точки зрения дизайна довольно неплохо, но таких графиком мне бы не очень хотелось иметь (как пользователю).

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

S> AN>То бишь нет практически ничего.

S> В каком смысле практически ничего? Я привёл ссылки на четыре книги. Каждая — на месяц чтения.
Может в остальных трех получше.
S> Помимо этого, читайте Стивена Круга.

S> AN>Я не занимаюсь исключительно дизайном, но иногда нужно делать формы ввода.

S> Если вы вдохновение для форм ввода черпаете в Страуструпе, то результат предсказуем.
Вполне согласен. Но как аналогия, я научился ездить на велосипеде только из за того, что так удобнее ездить на работу, в "тур де франс", я не собираюсь участвовать.
Хотя было бы иногда интересно узнать подробности.

S> AN>Может я просто не понял как нужно читать Tufte (тяжело представить, что делать с 200 страницами месяц)

S> Читать, пытаться понять. Я до сих пор не могу понять, каким образом вы ухитрились не найти там ничего нового, и при этом не знать ничего из того, о чём он пишет.
Я же говорю "просмотрел одну книгу", не нашел ничего интересного. Можно попытаться еще. Ну например, вроде и школьнику известно, что табличные данные удобнее представлять в виде графиков. Более того как то даже пытались и ввод сделать посредством графика — нееее, пользователь захотел цифры в таблице менять.
Вероятно, вы как дизайнер, знаете Дэна Маргулиса, так было достаточно маленькой статейки, чтобы захотелось прочесть его книгу. (Только не спрашивайте нафига он мне нужен )

S> S>> Где там нельзя слева вводить 10 пикселей?

S> AN>Совсем наоборот, "у меня есть" ограничение на входные данные.

S> Какое ограничение, на какие данные? У меня нет телепатических способностей.
Скажем так, пользователю не позволено иметь линию справа больше 10 пикселей.

S> AN>Готовая форма, та что видит пользователь и может использовать.
S> AN>Вот у нас есть 10 полей для ввода данных, как минимум нужен способ их выделения.

S> Ничего не понимаю. Для чего вам нужен способ их выделения?
А каким образом заполнить требуемое количество полей.

S> AN>Ну так, в основном и получается. Есть данные и есть пользователь.

S> Это получается не случайно. Это результат ваших действий (или бездействий).
То бишь нужно смотреть в другую сторону. А в какую?

S> AN>Безусловно нет. Но я получаю контрол управляемый данными.

S> Это практически полная гарантия плохой usability.
Скорее всего и так, но что тогда делать когда именно данные являются определяющими? Иначе говоря количество различных комбинаций настолько велико, что не имеет смысл под каждую делать что то свое, да и пользователь будет теряться видя что то новое.

S> S>> Хохотался. Вот, к примеру, возьмем автомобильный маршрут. Там внутри вполне себе цифры — координаты пунктов назначения. И текст — названия этиъ пунктов. Вы что, серъёзно полагаете, что показ пунктов назначения в таблице, с кнопкой Add New и редактором через Property Grid хоть как-то сопоставим по удобству с UI типа maps.google.com?

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

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

S> S>> Например, пользователь может захотеть найти настройку, которая его интересует. При этом он не знает точно, как именно она называется, и в какой группе она зарыта.

S> AN>Это как принеси "мне то не знаю что" и как он будет это искать. Если достаточно большой процент пользователей это хотят, то об этом можно каким то образом узнать и сделать. Если же это случайно захотел один, то об этом часто не узнать, да и делать никто не будет.

S> Я вам открою тайну: в 2011 году почти все развитые "настройки" оборудовали возможностями поиска. Началось это с Маков, сейчас то же самое имеем в Винде.

Для меня это пока действительно тайна
S> AN>Не совсем.

S> В таком случае просто примите как данность, что из утверждения "вы обязаны оптимизировать UI для частых случаев" утверждение "для редких случаев UI можно не делать вообще" логически не выводится, и делайте UI для всех случаев.
Не всегда это возможно, по самым различным причинам.

S> AN>Довольно часто "самый любимый" сценарий неизвестен, либо он "конфликтует" с обычным вводом. Типа для обычного ввода требуется изменять от 5 до 10 параметров для одной "единицы" ввода. А для самого любимого нужно менять один параметр, но уже для сотни "единиц" ввода. Под единицей ввода можно подразумевать документ, либо устройство, либо еще что имеет пользователь.

S> Не вижу никакого конфликта. Главное — не пытаться запихнуть два этих совершенно разных сценария в один и тот же UI.
А вот почему нельзя запихнуть в один и тот же UI? Как раз из за "конфликта".

S> AN>Ну вот именно от этого я отталкиваюсь, если все вводили годами дату цифрами, а мы говорим, послушайте, но ведь на порядок удобнее вводить дату буквами, поэтому мы вам сделаем ввод буквами.

S> Откуда вы знаете, как вводили дату в екселе? Я вам только что показал, что ексель прекрасно читает и буквы тоже.
А что если везде написано/напечатано 1.5.2011 вы будете вводить "первое мая две тысячи одиннадцатого года"?

S> AN>Дело не только в обучении. Человек при вводе видит дату "цифрами", значит ему это надо "переводит" в "буквы", как и тому кто видит буквы обратно переводить в цифры.

S> Не надо никому ничего переводить.
А как тогда назвать процесс если я вижу "5", а пишу "май" или наоборот?

S> AN>А вы уверены, что на китайском данный алгоритм также будет работать?

S> 1. Вы разрабатываете систему для китайского рынка?
Нет, но вопросы локализации стоят не на последнем месте.
S> 2. Поставьте китайскую локаль и проверьте в Excel.
Почти уверен, что там это будет работать, но неизвестно что это им стоило.

S> AN>Это вроде как само собой разумеется. Исходный формат документов должен отображаться на систему ввода. Иначе оператор нифига не сможет ввести и сравнить.

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

S> S>> Нравиться будет удобный UI. Чтобы научиться делать удобный UI, нужно читать источники, смотреть образцы, много думать.

S> AN>Обычно, в дополнение, это процесс интерактивный, сделали, проверили, сделали еще раз...

S> Это если есть такая возможность. У вас, я так понял, такой возможности нету.
Именно этим и занимаемся
Например, заметили дофига пространства справа и что пользователю неудобно делать прокрутку, докрутили грид до нескольких динамических колонок. Но во время доработки с прогой уже можно было работать. Скоро запустим тестеров в "боевые условия", по их замечаниям можно будет решать нужно ли еще что изменять.

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


S>> Нда. Одного примера маловато.
AN>Не спорю, но если один не завлек, тяжело заставить искать другие.
Не знаю. Меня Тафти вставил буквально с первых нескольких страниц. Пишет, вроде бы, очевидные вещи, но впечатление — на всю жизнь.

S>> Если вы вдохновение для форм ввода черпаете в Страуструпе, то результат предсказуем.
AN>Вполне согласен. Но как аналогия, я научился ездить на велосипеде только из за того, что так удобнее ездить на работу, в "тур де франс", я не собираюсь участвовать.
Эмм. Тут аналогия скорее такая: вас интересует, как правильно плавать с маской. Но вы предпочитаете езду на велосипеде бассейну.

AN>Я же говорю "просмотрел одну книгу", не нашел ничего интересного. Можно попытаться еще. Ну например, вроде и школьнику известно, что табличные данные удобнее представлять в виде графиков. Более того как то даже пытались и ввод сделать посредством графика — нееее, пользователь захотел цифры в таблице менять.
Дело не в том, что можно представлять данные в виде графиков. Там очень много того, как именно нужно представлять табличные данные в таблицах. Или как представлять графики.

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

AN>Скажем так, пользователю не позволено иметь линию справа больше 10 пикселей.
Невозможно решить фрагмент задачи. Нужно решать всю задачу. Понимаете, вы всё время пляшете от каких-то атомарных данных, вместо попытки понять весь сценарий. Это то же самое, как готовить блюдо исходя из "в нём должна быть морская соль".

S>> Ничего не понимаю. Для чего вам нужен способ их выделения?
AN>А каким образом заполнить требуемое количество полей.
Забудьте про поля. Зачем пользователь это делает? Почему именно эти поля? Можно ли избежать ввода вообще? Может быть, задачу пользователя можно переформулировать, и выделять поля вовсе не понадобится?

S>> Это получается не случайно. Это результат ваших действий (или бездействий).
AN>То бишь нужно смотреть в другую сторону. А в какую?
В сторону выяснения того, для чего и что пользователь делает.

S>> Это практически полная гарантия плохой usability.
AN>Скорее всего и так, но что тогда делать когда именно данные являются определяющими? Иначе говоря количество различных комбинаций настолько велико, что не имеет смысл под каждую делать что то свое, да и пользователь будет теряться видя что то новое.
Таких случаев исчезающе мало, но если они у вас встречаются — проперти грид может быть хорошим ответом.
Расскажите про задачу — где именно данные являются определяющими?


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

AN>Для меня это пока действительно тайна
Запустите контрольную панель в Win7. Запустите любой диалог настроек в Eclipse.
AN>Не всегда это возможно, по самым различным причинам.
Вот видите, как мы быстро перешли от "я ещё не встречал случая, где PropertyGrid бы не подошёл" до "не всегда возможно делать удобный UI".


AN>А вот почему нельзя запихнуть в один и тот же UI? Как раз из за "конфликта".
Ну хорошо, называйте это конфликтом. Хотя в отличие от конфликта, здесь не должно быть одного победителя.

S>> AN>Ну вот именно от этого я отталкиваюсь, если все вводили годами дату цифрами, а мы говорим, послушайте, но ведь на порядок удобнее вводить дату буквами, поэтому мы вам сделаем ввод буквами.
Ладно, согласен. Тогда откуда взялась проблема с порядком месяцев/дней? Если они годами вводили даты, то наверное уже инстинктивно помнят, как правильно — 1.5.2011 или 5.1.2011. А вы меня уверяете, что это источник ошибок, и вместо того, что они имели в екселе, надо непременно заставить их трахаться с тремя дроп-даунами.

S>> 1. Вы разрабатываете систему для китайского рынка?
AN>Нет, но вопросы локализации стоят не на последнем месте.
Локализация в Китай и локализация для Украины, мягко говоря, отличаются по сложности. Вы опять пытаетесь придумать одно решение для абстрактно-теоретической всеобъемлющей проблемы?


S>> Это если есть такая возможность. У вас, я так понял, такой возможности нету.
AN>Именно этим и занимаемся
AN>Например, заметили дофига пространства справа и что пользователю неудобно делать прокрутку, докрутили грид до нескольких динамических колонок. Но во время доработки с прогой уже можно было работать. Скоро запустим тестеров в "боевые условия", по их замечаниям можно будет решать нужно ли еще что изменять.
Ну и отлично. Главное — не останавливаться на достигнутом, и помнить, что лучший ui — это user-driven. Data-driven UI — не достижение в удобстве, а дань экономии средств.

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

S> S>> Нда. Одного примера маловато.

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

S> Не знаю. Меня Тафти вставил буквально с первых нескольких страниц. Пишет, вроде бы, очевидные вещи, но впечатление — на всю жизнь.
Я пока заметил только это "Пишет, вроде бы, очевидные вещи", надо будет поискать остальное. Для меня подобное впечатление оставил Н.Вирт.

S> S>> Если вы вдохновение для форм ввода черпаете в Страуструпе, то результат предсказуем.

S> AN>Вполне согласен. Но как аналогия, я научился ездить на велосипеде только из за того, что так удобнее ездить на работу, в "тур де франс", я не собираюсь участвовать.

S> Эмм. Тут аналогия скорее такая: вас интересует, как правильно плавать с маской. Но вы предпочитаете езду на велосипеде бассейну.
Только исключительно, по цитируемому тексту. Но имелось в виду несколько другое.
Разрабатывать дизайн интерфейса это не моя работа за которую мне платят деньги.
И последнего крика моды от меня никто не требует. Мне просто это интересно в некоторой степени, так как хочется узнать, что то новое.

S> AN>Я же говорю "просмотрел одну книгу", не нашел ничего интересного. Можно попытаться еще. Ну например, вроде и школьнику известно, что табличные данные удобнее представлять в виде графиков. Более того как то даже пытались и ввод сделать посредством графика — нееее, пользователь захотел цифры в таблице менять.

S> Дело не в том, что можно представлять данные в виде графиков. Там очень много того, как именно нужно представлять табличные данные в таблицах. Или как представлять графики.
Первичный просмотр этого не выявил

S> AN>Скажем так, пользователю не позволено иметь линию справа больше 10 пикселей.

S> Невозможно решить фрагмент задачи. Нужно решать всю задачу. Понимаете, вы всё время пляшете от каких-то атомарных данных, вместо попытки понять весь сценарий. Это то же самое, как готовить блюдо исходя из "в нём должна быть морская соль".
Ну так вся задача вроде уже есть (вы ее сами сформулировали) просто появляются дополнительные условия.

S> S>> Ничего не понимаю. Для чего вам нужен способ их выделения?

S> AN>А каким образом заполнить требуемое количество полей.

S> Забудьте про поля. Зачем пользователь это делает? Почему именно эти поля? Можно ли избежать ввода вообще? Может быть, задачу пользователя можно переформулировать, и выделять поля вовсе не понадобится?
Так задача вроде уже есть, хотелось удобный способ изменения многих переменных или одной. (на примере таблицы)

S> S>> Это получается не случайно. Это результат ваших действий (или бездействий).

S> AN>То бишь нужно смотреть в другую сторону. А в какую?

S> В сторону выяснения того, для чего и что пользователь делает.
Только не понимаю что это может дать? Ну знаю я что число пять пользователь вводит для того чтобы указать число рабочих дней в неделе и что допустимые значения от 1 до 7 и что данная форма ему нужна для планирования работы персонала.

S> S>> Это практически полная гарантия плохой usability.

S> AN>Скорее всего и так, но что тогда делать когда именно данные являются определяющими? Иначе говоря количество различных комбинаций настолько велико, что не имеет смысл под каждую делать что то свое, да и пользователь будет теряться видя что то новое.

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

Хотя решение конкретной задачи меня не очень интересует, больше интересует решение в "общем виде".

S> S>> Если вы не видите отличий между таблицей с координатами и маршрутом на карте, то мне жаль ваших пользователей.

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

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

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

S> AN>Для меня это пока действительно тайна

S> Запустите контрольную панель в Win7. Запустите любой диалог настроек в Eclipse.
Семерку можно будет глянуть на работе, а Eclipse я черти знает когда по нужде пользовался.
Имеется в виду строка фильтр?

Хотя контрольная панель в виндах весьма сильно отличается от настроек стандартного приложения

S> AN>А вот почему нельзя запихнуть в один и тот же UI? Как раз из за "конфликта".

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

S> S>> AN>Ну вот именно от этого я отталкиваюсь, если все вводили годами дату цифрами, а мы говорим, послушайте, но ведь на порядок удобнее вводить дату буквами, поэтому мы вам сделаем ввод буквами.

S> Ладно, согласен. Тогда откуда взялась проблема с порядком месяцев/дней? Если они годами вводили даты, то наверное уже инстинктивно помнят, как правильно — 1.5.2011 или 5.1.2011. А вы меня уверяете, что это источник ошибок, и вместо того, что они имели в екселе, надо непременно заставить их трахаться с тремя дроп-даунами.
Никто и не заставлял их трахаться с "тремя дроп-даунами". А вводили они действительно 1.5. но в некоторых случая система воспринимала это как 5.1 при этом никаким колдовством лечить не получалось (это не был обычный едит контрол в вин-форме)

S> S>> 1. Вы разрабатываете систему для китайского рынка?

S> AN>Нет, но вопросы локализации стоят не на последнем месте.

S> Локализация в Китай и локализация для Украины, мягко говоря, отличаются по сложности. Вы опять пытаетесь придумать одно решение для абстрактно-теоретической всеобъемлющей проблемы?
Есть задачи которые можно решать локально, а есть те которые обязаны быть решены глобально. Локализацию мы относим к глобальным. Если не будет всех требуемым механизмов для локализации, то может наступить момент когда потребуется довольно серьезная переделка кода, этого и хочется избежать. Допустим, если в концепте предусмотрена исключительно выдача локализованных строк, то добавить в него, что то еще может быть непростой задачей.

S> S>> Это если есть такая возможность. У вас, я так понял, такой возможности нету.

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

S> Ну и отлично. Главное — не останавливаться на достигнутом, и помнить, что лучший ui — это user-driven. Data-driven UI — не достижение в удобстве, а дань экономии средств.
Все равно не совсем понятно, есть допустим один и тот пользовательский юзкэйс реализованный скажем, в виде диалога(1) и проперти грид(2). Есть одна группа пользователей хорошо знакомая с использованием проперти грид, и есть другая которая его в глаза не видела. Одной нравится вариант 1 и абсолютно не нравится вариант 2, другой группе все в точности наоборот. Группы считаем 50 на 50 по численности. Какой вариант выбирать?

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

AN>Имеется в виду строка фильтр?
AN>http://www.testcocoon.org/pictures/eclipse_settings_fig.png

Поле-фильтр в левом верхнем углу: type filter text

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

S>> Запустите контрольную панель в Win7. Запустите любой диалог настроек в Eclipse.
AN>Семерку можно будет глянуть на работе, а Eclipse я черти знает когда по нужде пользовался.

До кучи windows7

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

r> AN>Имеется в виду строка фильтр?
r> AN>http://www.testcocoon.org/pictures/eclipse_settings_fig.png

r> Поле-фильтр в левом верхнем углу: type filter text

http://sites.secure.force.com/success/servlet/rtaImage?eid=08730000000HpBM&amp;feoid=Body&amp;refid=0EM30000000GrMj


Спасибки.
То есть похоже список ключевых слов собирается автоматом из зависимого окна?
Сразу есть желание
Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели
Пожалуй надо записать "поиск в настройках" в список моих заданий для добавки в янус

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

S>Читайте Tufte.

А на русском нет?

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

>> S>> AN>Дело в том что возникает конфликт между скоростью и требованием не давать пользователю вводить неправильные данные

>> Ну и в чем проблема?
AN>Скорость обычно подразумевает исключительно ввод с клавиатуры, при этом не всегда возможно запретить ввод неправильных данных. (ну типа 29.02 можно ввести при этом подходе)


Ну пусть вводят

>> S>> Конфликт надуман.

>> AN>Что введется в результате ввода 05.07, 05/07, 29.02?

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

>> AN>Дело не в удобстве разработчика, а в концепте.

>> Читать, например, тут: http://productblog.37signals.com/products/2007/06/the_quickest_wa.html

>> Их календарь позволяет вводить даты в следующем виде:

>> Это все сложно распарсить и положить в базу? Нет. Сложно показать пользователю, как надо вводить даты? Нет. Сложно выводить подсказки в процессе набора даты? Нет.

>> В чем проблема?
AN>В том, что это красиво выглядит на бумаге и в отдельно взятом регионе.

Почему-то у 37signals этопрекрасно работает и в реальной жизни

AN>Простой пример. Что введется после набора 7/12?

Выделенное. В Штатах — 12 июля. В России — 7 декабря

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

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

А>Есть форма ввода квитанций.
А>На форме есть поле период платежа.
А>Не могу придумать формат данных.
А>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.
А>тогда вроде напрашивается комбобокс со списком месяцов и комбобокс с годами. но это как то неюзабельно, имхо.
А>Теоретически за один месяц может быть несколько квитанций.

А>Что посоветуете?

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