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

А>Можно подробней про вашу идею?
А>т.е. чтобы когда он ввел "ию" у него всплывало
А>"июнь 2011
А>июль 2011"?
Да, это было бы лучше всего.

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

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

А>Что посоветуете?
Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.
Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.

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

AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
C>Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.

Человек важнее любого ГОСТа. (Тем более, что ГОСТ — это не всегда хорошо.)
Пока вы думаете по другому — у вас не будет хороших продуктов.

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

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

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

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

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

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

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

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

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

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

textbox с форматом [yy]yy/[m]m

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

A>textbox с форматом [yy]yy/[m]m

+1, только формат должен быть YYYY-MM, согласно ISO 8601.

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

R3>>А квитанции существуют в бумажном виде?
А>да.

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

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

S>> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"
AN>Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.
Обоснования?
Для интересу попробуйте запустить Outlook, нажать "новая встреча" и попробовать ввести разную ерунду в поле даты. Окажется, что выбор из выпадающего календаря — не самый быстрый способ ввести "послезавтра".

Язык ввода, который я предлагаю, будет обладать гарантированно примитивной грамматикой, и реализовать его нет никаких проблем.
Зато появляется масса приятных последствий — в том числе и возможность просто Paste периода в поле ввода — вместо мучительного щёлкания мышкой в drop down fields.
Кстати, дроп-дауны в винде поддерживают и клавиатурный ввод, но для его корректной работы нужно полностью вводить префикс. То есть, чтобы ввести март 2011, придётся так и набирать м-а-р-т-Tab-2-0-1-1. Для февраля или сентября, понятно, попроще — ф-Tab-2-0-1-1. И невозможно сделать Paste сразу в два дроп-дауна.

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

S>> Обоснования?
AN>что введется при наборе "йцукен", например?
Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.

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

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

S>> Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.
AN>угу, а дата нужна будет уже при вводе следующего поля.
Зачем?
AN>И получаем умный контрол который автоматом правит ввод пользователя, уже проходили...
Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?

S>> Конфликт надуман.
AN>Что введется в результате ввода 05.07, 05/07, 29.02?
ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести месяц в принятом формате.
Поймите, задача не стоит в интерпретации произвольной строки. Задача стоит в разработке удобного текстового микроязыка, который был бы удобен пользователю. Всё, что не укладывается в этот язык — ошибка ввода.

AN>Дело не в удобстве разработчика, а в концепте.
Совершенно верно. Концепт "разделить объект ввода на несколько компонентов" — ужасен и неудобен.
Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.

Некоторые программисты (не буду показывать пальцем) разделяют на компоненты даже телефонный номер.

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

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

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

AN>>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

C>Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.
Сомневаюсь я в этом однако.
Как там Кибиты уже прижились?

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

AN>Привык я задачи обощать
Напрасно. Общее решение любой задачи ввода данных — PropertyGrid. Для реальных UI, ориентированных на людей, непригоден.

S>>Хотя здесь, в принципе, можно и цифрами.
AN>в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.
Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
S>>Попробуйте набрать в екселе "май 2011"
AN>получил "май 2011"
Посмотрите вовнутрь. Если там не 1.05.2011, то, скорее всего, у вас английская локаль. В ней можно попробовать набрать May 2011.

AN>Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","
Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.

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

Здравствуйте, 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, не должно быть их заботой.
Клещами вытягивать конечно нужно. Ну, кроме случая оффшора. Тогда можно и забить — проектирование выполняется не вами, от вас требуется только аккуратный кодинг. Тогда остаётся только читать источники, сравнивать реализации — в ожидании шанса перейти на более высокое место в пищевой цепочке.

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

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

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

А>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.

Может быть только за один месяц или больше?

А>Теоретически за один месяц может быть несколько квитанций.

Не понял, что именно эта форма вводит.

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

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

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

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

А>>Т.е. может быть квитанция на оплату ЖКХ за январь месяц.

R3>Может быть только за один месяц или больше?

да, может

А>>Теоретически за один месяц может быть несколько квитанций.

R3>Не понял, что именно эта форма вводит.

форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

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

А>форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

А квитанции существуют в бумажном виде?

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

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

А>>форма ввода квитанций и платежей по разным видам услуг (жкх, электр, инет, тв)

R3>А квитанции существуют в бумажном виде?

да.

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

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

R3>>>А квитанции существуют в бумажном виде?
А>>да.

R3>Тогда возможно:
R3>* печатать квитанции со штрих-кодом, который потом распознаётся и данные заносятся автоматически (почти никакого ручного труда, если использовать потоковый сканер);
R3>* печатать квитанции так, чтобы их можно было бы распознать (нужен человек, контролирующий качество распознавания).

Спасибо!

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

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

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

S> Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
S> Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.
S> Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
А что потом будет в базе?

Здравствуйте, AlexNek, Вы писали:
AN>А что потом будет в базе?
А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"

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

S> AN>А что потом будет в базе?

S> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"
Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.

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

S> S>> А это совершенно другой вопрос. В базе должно быть то, что требуется по ТЗ. Скорее всего — нормализованные периоды. То есть, например, "2011 05"

S> AN>Что то берут меня большие сомнения что при таком вводе удастся что то нормализовать.

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

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

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

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

т.е. вы предлагаете просто регэкспом получать месяц и если есть год?

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

S> S>> Обоснования?

S> AN>что введется при наборе "йцукен", например?

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

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

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

S> Конфликт надуман.
Что введется в результате ввода 05.07, 05/07, 29.02?
S> Ввод осуществляется интерактивно. Это означает, что можно взаимодействовать с пользователем массой нормальных способов, не заставляя его прогибаться под удобство разработчика.
Дело не в удобстве разработчика, а в концепте.

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

А>т.е. вы предлагаете просто регэкспом получать месяц и если есть год?
Я предлагаю
1. сначала продумать язык с полной грамматикой.
2. выбрать способ реализации парсера. Может быть — на регекспах; может быть — нет. Это вопрос частный.
3. реализовать автодополнение, чтобы оператор во время ввода видел, что получается в результате.

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

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

S>> S>> Обоснования?

S>> AN>что введется при наборе "йцукен", например?

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

Для какого следующего поля?

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

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

Ну и в чем проблема?

S>> Конфликт надуман.
AN>Что введется в результате ввода 05.07, 05/07, 29.02?
S>> Ввод осуществляется интерактивно. Это означает, что можно взаимодействовать с пользователем массой нормальных способов, не заставляя его прогибаться под удобство разработчика.
AN>Дело не в удобстве разработчика, а в концепте.

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

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

Время
9am
6:30pm

Дата
January 7
Oct 29
7/12

Дата и время
July 15 2pm
9/12 8pm

Range
August 3 — August 16
Jan 24 — Feb 6
8/10 — 8/25

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

В чем проблема?

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

S> S>> Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.

S> AN>угу, а дата нужна будет уже при вводе следующего поля.

S> Зачем?
потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...

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

S> Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?
Сорри, Outlook не имеемс.

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

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

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

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

S> Совершенно верно. Концепт "разделить объект ввода на несколько компонентов" — ужасен и неудобен.
Я имел в виду другой.
— Пользователь не имеет возможности ввести неправильные данные
— Поле ввода не имеет права изменять введенные данные.
S> Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.
Не всегда, например требуется расположить номер дома с выравниваем вправо или почтовый индекс нужно в другом месте напечатать.

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

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

> S>> S>> Обоснования?

> S>> AN>что введется при наборе "йцукен", например?

> S>> Ничего не введётся. При попытке сохранить документ получим ошибку валидации и просьбу ввести что-то осмысленное.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

S>3. реализовать автодополнение, чтобы оператор во время ввода видел, что получается в результате.

Можно подробней про вашу идею?
т.е. чтобы когда он ввел "ию" у него всплывало
"июнь 2011
июль 2011"?

Здравствуйте, AlexNek, Вы писали:
S>> Зачем?
AN>потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...
Поймите, для разных задач — разные решения. Вы сейчас пытаетесь придумать другую задачу.
Кстати, для этой другой задачи тоже может найтись очень хорошее полутекстовое или чисто текстовое решение.

S>> Проходили и проходим. Между прочим, Outlook является одним из самых популярных почтовых клиентов в мире. Вы его уже запустили?
AN>Сорри, Outlook не имеемс.
Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?

AN>почему ничего не введется? Это ведь вроде соответствует вашему "языку".
Вроде не соответствует.

AN>А что укладывается в язык, но является ошибкой ввода?
Тогда дайте определение "ошибки ввода". Я не понимаю, о чём вы говорите. Если вы об ошибках типа "июнь" вместо "июля" — тут ничего не поделаешь, и никакие дропдауны не спасут.

AN>Я имел в виду другой.
AN>- Пользователь не имеет возможности ввести неправильные данные
AN>- Поле ввода не имеет права изменять введенные данные.
Первый из этих постулатов при дословном следовании приводит к совершенно чудовищным интерфейсам. Например, контрол ввода даты, валидирующий ввод на каждом нажатии. Задача исправить 1.04.1977 на 31.03.1977 превращается в натуральный квест, сопровождаемый отвратительным писком. Потому, что "умный" контрол знает, что в апреле нет 31го числа, и не даёт его ввести. В итоге нужно сначала исправить месяц, потом вернуться в число. Зато да — пользователь не имеет возможности ввести неправильные данные.

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

S>> Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.
AN>Не всегда, например требуется расположить номер дома с выравниваем вправо или почтовый индекс нужно в другом месте напечатать.
Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться. Дом с выравниванием вправо вообще не так уж трудно реализовать.
Вообще, всегда можно добиться многого, если думать головой. К сожалению, многие программисты перекладывают решение своих задач на пользователя.

S>> Некоторые программисты (не буду показывать пальцем) разделяют на компоненты даже телефонный номер.
AN>все бывает, если нет ввода по маскам.
Ввод по маске тоже немногим лучше. Лакмусовая бумажка: если работает Paste, значит контрол работает правильно.

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

S>Здравствуйте, AlexNek, Вы писали:
S>>> Зачем?
AN>>потому как если введена пятница, нужно ответить будет ли кто в субботу работать, в остальных случаях поле реадонлу (невидимо). Чисто как пример...
S>Поймите, для разных задач — разные решения. Вы сейчас пытаетесь придумать другую задачу.
S>Кстати, для этой другой задачи тоже может найтись очень хорошее полутекстовое или чисто текстовое решение.
Вроде одна и таже задача — ввод данных в форму. Или?

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

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

AN>>А что укладывается в язык, но является ошибкой ввода?
S>Тогда дайте определение "ошибки ввода". Я не понимаю, о чём вы говорите. Если вы об ошибках типа "июнь" вместо "июля" — тут ничего не поделаешь, и никакие дропдауны не спасут.
ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

AN>>Я имел в виду другой.
AN>>- Пользователь не имеет возможности ввести неправильные данные
AN>>- Поле ввода не имеет права изменять введенные данные.
S>Первый из этих постулатов при дословном следовании приводит к совершенно чудовищным интерфейсам. Например, контрол ввода даты, валидирующий ввод на каждом нажатии. Задача исправить 1.04.1977 на 31.03.1977 превращается в натуральный квест, сопровождаемый отвратительным писком. Потому, что "умный" контрол знает, что в апреле нет 31го числа, и не даёт его ввести. В итоге нужно сначала исправить месяц, потом вернуться в число. Зато да — пользователь не имеет возможности ввести неправильные данные.
В случае дат решается специализированным редатором, в которым достаточно сложно опеспечить быстрый ввод (из-за этого и говорил о конфликте)

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

S>>> Аналогичная проблема с адресом. Причём в 99% приложений адрес нужен только для того, чтобы напечатать его на накладной — т.е. вообще плевать на то, где там дом, а где улица.
AN>>Не всегда, например требуется расположить номер дома с выравниваем вправо или почтовый индекс нужно в другом месте напечатать.
S>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
S>Дом с выравниванием вправо вообще не так уж трудно реализовать.
Да если он только цифра и стоит всегда в одном месте.
S>Вообще, всегда можно добиться многого, если думать головой. К сожалению, многие программисты перекладывают решение своих задач на пользователя.
Доволно часто программисты просто не знают что нужно пользователя.

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

AN>Вроде одна и таже задача — ввод данных в форму. Или?
Разные данные, разные формы. Разные требования к этим данным.

S>>Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?
AN>Для этого лучше смотреть что нравится. Да и нафига мне оутлук, когда другой клиент почты мне гораздо удобнее и приятней.
Аутлук — один из мировых передовиков юзабилити. Кстати, как и упомянутые рядом 37signals.
Впрочем, это не так важно. Посмотрите на другой близкий пример — google maps. Попробуйте представить, насколько "удобнее" бы он был, если бы требовал вводить адреса по компонентам.

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

AN>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
Ужас какой. А почему вы получаете 5е января? Может быть, потому, что у пользователя стоит US locale?
Если вас это сильно беспокоило, надо было обеспечить поддержку локали приложения, независимой от системной.
Вот, кстати, поставил я себе официальную программу Декларация 2010 от нашей налоговой. Её проектировали милые люди — требуется, чтобы в системной локали стояла запятая в качестве десятичного разделителя, и русский формат дат. И этим людям кто-то платит зарплату за мой счёт.

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


S>>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
AN>Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
А на что вам интерактивность? Если вы видите, что индекс не вполне корректный — подчеркните его красненьким, предложите варианты.

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

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

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

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

S>>>Ну и зря. Как же вы проектируете интерфейсы, не глядя в то, что разработано до вас?
AN>>Для этого лучше смотреть что нравится. Да и нафига мне оутлук, когда другой клиент почты мне гораздо удобнее и приятней.
S>Аутлук — один из мировых передовиков юзабилити. Кстати, как и упомянутые рядом 37signals.
S>Впрочем, это не так важно. Посмотрите на другой близкий пример — google maps. Попробуйте представить, насколько "удобнее" бы он был, если бы требовал вводить адреса по компонентам.

А где я агитировал разбивать ввод на компоненты?
А про гугл — см. "Разные данные, разные формы. Разные требования к этим данным."
AN>>А разве год не должен быть добавляться?
S>К чему добавляться? Язык, который я описал — текстовые месяцы, числовой год. Никаких точек и знаков деления в нём не предусмотрено.
Что то я видимо пропустил, никогда не приходила идея вводить месяцы буквами, обычно весь дополнительный ввод идет через цифровую клавиатуру
AN>>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.
S>Ужас какой. А почему вы получаете 5е января? Может быть, потому, что у пользователя стоит US locale?
S>Если вас это сильно беспокоило, надо было обеспечить поддержку локали приложения, независимой от системной.
Все было именно так, но затык все равно оставался.

S>Вот, кстати, поставил я себе официальную программу Декларация 2010 от нашей налоговой. Её проектировали милые люди — требуется, чтобы в системной локали стояла запятая в качестве десятичного разделителя, и русский формат дат. И этим людям кто-то платит зарплату за мой счёт.
Кстати excel от этого недалеко ушел.
И могу назвать программу хуже которой я еще не видел по юзабилити — SAP

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

S>>>Если индекс обрабатывается как-то очень отдельно, то можно и спросить его отдельно. Хотя не распознать индекс в строке адреса — это надо очень постараться.
AN>>Стараться вообще не нужно, достаточно набрать на один символ больше или меньше
S>А на что вам интерактивность? Если вы видите, что индекс не вполне корректный — подчеркните его красненьким, предложите варианты.
Интерактивный парсер совмещенный с редактором? А какой ввод формата адреса будет известно заранее? И разработаны все парсеры

AN>>Доволно часто программисты просто не знают что нужно пользователя.
S>Да, в этом, собственно, корень всех зол. Программисты искренне думают, что пользователю надо выбрать год рождения из списка вариантов. В то время, как пользователю надо всего лишь арендовать автомобиль, и в его системе ценностей выбор четырёхзначного числа из списка в 90 позиций занимает последнее место.
Лучше разрешить ввод всех данных, а потом заниматься перегрузкой только правильных с сообщением об ошибке?
Не помню уж где было. Вводишь данные, нажимаешь ок, получаешь назад сообщение — "пароль должен быть больше 6 символов" и пустую форму

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

AN>ничего не выдумывая, ошибка на которую в свое время затратили дофига времени.
AN>набираем 1.5.2010 (подразумевая 1-е мая) получаем 5-е января. Подробности уже забыл, но из-за этого пришлось убрать весь текствый ввод дат.

Вот с этой ошибкой надо адресно бороться, повсеместно насаждая ISO 8601 (также известный под псевдонимом ГОСТ ИСО 8601, ранее — ГОСТ 7.64-90). Год в начале, потом месяц, потом день. И чтобы у всех навсегда в мозгах отпечаталось, что старшие разряды — слева, младшие — справа.

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

AN>То бишь рассматриваем исключительно конкретную задачу? А именно ввод даты в форму все поля которой незавимы от состояния друг друга.
Рассматриваем задачу "ввод периода платежа". Цитирую:

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

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

(например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.

Хотя здесь, в принципе, можно и цифрами.

AN>Все было именно так, но затык все равно оставался.
Ужас.

AN>Кстати excel от этого недалеко ушел.
Кстати, у екселя как раз всё очень-очень хорошо. Более прогибающейся под настройки пользователя программы ещё поискать.
С угадыванием форматов у него, конечно же, лучше всего в локали US/English. Но и на русском работает вполне ничего себе.
Попробуйте набрать в екселе "май 2011"

S>>Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.
AN>Сейчас не нужно, но просто интересно, можно подробней?
Например 37signals. Для починки проблем 01/04 можно транслировать всё в формат с текстовым именем месяца.

AN>Интерактивный парсер совмещенный с редактором? А какой ввод формата адреса будет известно заранее? И разработаны все парсеры
Ну да. Прочитайте Хайнлайна, Астронавт Джонс. Там дяденька на полном серъёзе писал про то, как в компьютер космического корабля поправки курса надо было забивать в двоичном коде, переводя их по таблицам из десятичного кода.
Уже в семидесятых годах это было смешно читать. Ваше недоверие мне очень ту книжку напоминает. Да, компютер вполне способен распознать ввод. Язык SQL, скажем, посложнее языка описания современных почтовых адресов.
Посмотрите обратно на maps.google.com — там реализован тупейший вариант, но и он работает бесконечно лучше комбобоксов с названиями городов и отдельных полей для номера дома.

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

AN>Не помню уж где было. Вводишь данные, нажимаешь ок, получаешь назад сообщение — "пароль должен быть больше 6 символов" и пустую форму
Зачем вы приводите мне плохие примеры? Думайте о хороших.

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

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

AN>>То бишь рассматриваем исключительно конкретную задачу? А именно ввод даты в форму все поля которой незавимы от состояния друг друга.
S>Рассматриваем задачу "ввод периода платежа". Цитирую:

S>

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

Привык я задачи обощать
AN>>Что то я видимо пропустил, никогда не приходила идея вводить месяцы буквами, обычно весь дополнительный ввод идет через цифровую клавиатуру
S>

S>(например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
S>Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.

S>Хотя здесь, в принципе, можно и цифрами.
в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.

AN>>Все было именно так, но затык все равно оставался.
S>Ужас.

AN>>Кстати excel от этого недалеко ушел.
S>Кстати, у екселя как раз всё очень-очень хорошо. Более прогибающейся под настройки пользователя программы ещё поискать.
S>С угадыванием форматов у него, конечно же, лучше всего в локали US/English. Но и на русском работает вполне ничего себе.
S>Попробуйте набрать в екселе "май 2011"
получил "май 2011"
Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","

S>>>Для случая дат есть множество замечательных решений, которые прекрасно совместимы с быстрым вводом.
AN>>Сейчас не нужно, но просто интересно, можно подробней?
S>Например 37signals. Для починки проблем 01/04 можно транслировать всё в формат с текстовым именем месяца.
нельзя, все данные поступали в цифрах.

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

S> AN>Привык я задачи обощать

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

S> S>>Хотя здесь, в принципе, можно и цифрами.

S> AN>в апреле 2011 "апрель" = апрель 2011 — именно это я и имел ввиду, говоря о добавке года.

S> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)

S> S>>Попробуйте набрать в екселе "май 2011"

S> AN>получил "май 2011"

S> Посмотрите вовнутрь. Если там не 1.05.2011, то, скорее всего, у вас английская локаль. В ней можно попробовать набрать May 2011.
Именно это я и хотел сказать

S> AN>Наберите вначале цифры в локали с ".", а затем попробуйте исправить в локали с ","

S> Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.
ну значит я уже забыл как точно воспроизвести , но у меня проблемы были. А уж перевод функций это просто катастрофа. Я то помню все используемые имена на английском. (Вроде я делал в настройках локали с запятыми точки.)

S> AN>нельзя, все данные поступали в цифрах.

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

Здравствуйте, AlexNek, Вы писали:
AN>А про PropertyGrid действительно интересно мне лично он очень нравиться, а вот людям далеким от компа нет. Никак не дойдет где заблуждаюсь.
Вы просто работаете на другой работе.
Любой UI должен быть построен не вокруг данных, а вокруг действий.
Точнее, так: есть две задачи в UI:
1. Отображать что-то
2. Давать пользователю совершать действия
Хорошие UI cовмещают и то и другое.
Property Grid очень плохо отображают практически любые данные. Читать Tufte по поводу того, как и что нужно отображать.
Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.
Попробуйте представить себе несложный use-case — например "оплата сотового телефона", и оптимизируйте его до идеала.

S>> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".
AN>Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)
В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".
AN>Именно это я и хотел сказать
Надеюсь, вы поняли, что хотел сказать я.

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

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

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

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

S> Вы просто работаете на другой работе.
В смысле?
S> Любой UI должен быть построен не вокруг данных, а вокруг действий.
S> Точнее, так: есть две задачи в UI:
S> 1. Отображать что-то
S> 2. Давать пользователю совершать действия
S> Хорошие UI cовмещают и то и другое.
S> Property Grid очень плохо отображают практически любые данные. Читать Tufte по поводу того, как и что нужно отображать.
Нашел это, но про property grid там ничего нет
здесь
здесь
S> Кроме этого, он очень плохо подходит для практически любых задач, поскольку в нём реализован (и то не очень хорошо) только один глагол — "изменить один атрибут некоторого объекта". В жизни таких задач не бывает.
Пока не было ни одной задачи где бы он не подошел. И почему только один?
S> Попробуйте представить себе несложный use-case — например "оплата сотового телефона", и оптимизируйте его до идеала.
При чем здесь property grid?
— Идешь в магазин, покупаешь карточку, вводишь номер.
Или
— Заключаешь договор с оператором и он снимает денюжку прямо о счета.

S> S>> Но где вы нашли идею прибавлять год к произвольной строке? 05/07 — это совсем не то же самое, что "апрель".

S> AN>Это не произвольная строка. 05/07/2011 вполне легальная строка для даты и екзель так и делает. (Добавляет год)

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

S> AN>Именно это я и хотел сказать

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

S> S>> Регулярно редактирую документы Excel в разных локалях. Никаких проблем нет — точки волшебным образом превращаются в запятые, запятые в точку с запятой, а VLOOKUP — в ВПР.

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

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

S> S>> Всё можно, если не придумывать себе искусственных ограничений.
Их не нужно придумывать они есть.
S> AN>Клиенты бы загрызли, да и в ТЗ записано.

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

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

S>> Вы просто работаете на другой работе.
AN>В смысле?
Вы — программист. Другие люди — нет.

AN>Нашел это, но про property grid там ничего нет
Вот именно.
AN>здесь
AN>здесь
Ага, этот тот самый.
http://store.artlebedev.ru/books/lebedevs-choice/envisioning-information/
http://store.artlebedev.ru/books/lebedevs-choice/beautiful-evidence/
http://store.artlebedev.ru/books/lebedevs-choice/the-visual-display-of-quantitative-information/
http://store.artlebedev.ru/books/lebedevs-choice/visual-explanations/
Но можно заказать на Амазоне — выйдет сильно дешевле.

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

AN>При чем здесь property grid?
AN>- Идешь в магазин, покупаешь карточку, вводишь номер.
AN>Или
AN>- Заключаешь договор с оператором и он снимает денюжку прямо о счета.
Совершенно верно. Как видите, property grid здесь ни при чём. А вы говорите — нет ни одной задачи, где бы он не подошёл.

S>> В задаче речь про даты не шла. Речь шла о вводе периода платежа. Период — это, к примеру "март 2011". А не "пятое июля".
AN>Но период это и 1.3.2011-5.10.2011.
Вы опять уходите от решения задачи. Задачи вводить произвольный период не стояло. Если двигаться дальше по вашему пути, то мы получим просто проклятие для оператора: неудобный, замедляющий работу контрол, который требует вводить две даты там, где нужно просто выбрать месяц.

То, что ексель прекрасно парсит текст при вводе даты. Несмотря на то, что он даже не знает заранее — а дата ли там.
AN>Насколько я помню, у меня были большие проблемы с запятой и точкой. А также постоянно при попытке найти нужную функцию.
Надо полагать, вы пользуетесь екселем от случая к случаю, и постоянно в разных локалях. У регулярных пользователей локаль ровно одна, а user experience в пределах одной локали прекрасно воспроизводим.
Работать в нескольких локалях тоже можно, но это несколько сложнее.

S>> Вы слишком плохо думаете о клиентах, и слишком хорошо — о ТЗ. Ничего, это пройдёт
AN>И сколько еще нужно ждать?
Ждать ничего не нужно. Нужно работать над собой. Читать различные источники, смотреть на опыт передовиков, экспериментировать, много думать.

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

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

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

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

Здравствуйте, 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> А программисты потом жалуются на то, что клиент хочет странного.
И не только они.

Здравствуйте, 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. Выпадающий календарь никто не отменял. по мере ввода можно переходить на месяц, а потом на день, который ввел человек. Или показывать то, что ввел человек, в стандартизированном виде, например, под полем ввода. И таким образом дать человеку доп. подсказку

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

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

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

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

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

AN>Я пока заметил только это "Пишет, вроде бы, очевидные вещи", надо будет поискать остальное. Для меня подобное впечатление оставил Н.Вирт.
Я не могу заставить вас читать его.

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

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

AN>Ну так вся задача вроде уже есть (вы ее сами сформулировали) просто появляются дополнительные условия.
Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12?

AN>Так задача вроде уже есть, хотелось удобный способ изменения многих переменных или одной. (на примере таблицы)
На примере таблицы удобный способ реализован в Excel.
В жизни задача не формулируется в терминах формы и её полей. Подумайте о таком сценарии: управление автомобилем.
Трогание с места на машине с механикой требует согласованного управления тремя параметрами: усилием торможения, коэффициентом сцепления, и оборотами двигателя.
Трогание с места на машине с автоматом требует управления одним параметром: сначала усилием торможения, потом оборотами. В зависимости от модели машины "внутри" у неё есть ещё много "переменных". Если бы автокомпании проектировали UI в "data-driven" парадигме, то на приборной панели была бы куча ручек, а разработчики бы объясняли, что не могут найти удобный способ "выделения группы параметров, которые хочется согласованно изменить".

Очевидно, что решение, пригодное для управления Приусом, не будет подходить для "общего случая одиннадцати параметров".

S>> В сторону выяснения того, для чего и что пользователь делает.
AN>Только не понимаю что это может дать? Ну знаю я что число пять пользователь вводит для того чтобы указать число рабочих дней в неделе и что допустимые значения от 1 до 7 и что данная форма ему нужна для планирования работы персонала.
Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю.

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

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

Общее решение годится только для прототипа. Снова подумайте об автомобиле. Как вы полагаете, PropertyGrid хорошо бы подошёл для управления автомобилем? А ведь с точки зрения теории управления там как раз "какие-то данные" передаются в одну сторону, и какие-то — в другую.

AN>Еще ни разу в голову не пришло прокладывать авто маршрут по карте. Это же вначале нужно найти мухосранск, а затем и дорогу как туда добираться.
А, простите, как вы прокладываете маршрут?
Лично я вбиваю начальную и конечную точки (кстати, безо всяких отдельных полей для номера дома и индекса), и прошу построить мне маршрут.
Дальше я смотрю на него и исправляю на карте. Потому что я вижу на карте более-менее интересные места, которые стоит посетить по дороге, и перетаскиваю к ним фрагменты маршрута.
Кроме того, если у меня есть несколько промежуточных точек, то только по карте можно понять, в каком порядке имеет смысл их посещать. Вот вы, к примеру, наизусть помните, что идёт первым по дороге из Рима в Милан — Пиза или Генуя?

S>> Запустите контрольную панель в Win7. Запустите любой диалог настроек в Eclipse.
AN>Семерку можно будет глянуть на работе, а Eclipse я черти знает когда по нужде пользовался.
AN>Имеется в виду строка фильтр?
AN>
Да, вот это вот "type filter text" позволяет найти нужную настройку, не перелопачивая всё дерево.
AN>Хотя контрольная панель в виндах весьма сильно отличается от настроек стандартного приложения

Это от того, что проектировщики "настроек стандартного приложения" вдохновлялись контрольной панелью из win95.
Сейчас "стандартный UI" — это уже семёрка.

AN>А отчего в конфликте должны быть победители, как я помню, обычно конфликт решается на компромиссах.
Компромисс — это решение, при котором проигрывают обе стороны.

AN>Никто и не заставлял их трахаться с "тремя дроп-даунами". А вводили они действительно 1.5. но в некоторых случая система воспринимала это как 5.1 при этом никаким колдовством лечить не получалось (это не был обычный едит контрол в вин-форме)
Я вас не понимаю. Кто разрабатывал эту "заколдованную систему"? Сторонние люди?

AN>Есть задачи которые можно решать локально, а есть те которые обязаны быть решены глобально. Локализацию мы относим к глобальным. Если не будет всех требуемым механизмов для локализации, то может наступить момент когда потребуется довольно серьезная переделка кода, этого и хочется избежать. Допустим, если в концепте предусмотрена исключительно выдача локализованных строк, то добавить в него, что то еще может быть непростой задачей.
Ок, понял. Да, в этом смысле текстовые языки ввода могут оказаться труднее в локализации, чем набор тупых по-компонентных контролов. Хотя и там могут быть неожиданности. Скажем, контрол ввода даты, рассчитанный на григорианский календарь, встрянет для тайской локализации. Потому что вопрос не только в переводе, но и в культуре.

AN>Все равно не совсем понятно, есть допустим один и тот пользовательский юзкэйс реализованный скажем, в виде диалога(1) и проперти грид(2). Есть одна группа пользователей хорошо знакомая с использованием проперти грид, и есть другая которая его в глаза не видела. Одной нравится вариант 1 и абсолютно не нравится вариант 2, другой группе все в точности наоборот. Группы считаем 50 на 50 по численности. Какой вариант выбирать?
Нужно провести usability-тест и посмотреть success rate для каждого из UI. Пронаблюдать за тем, какие ошибки совершает каждая из групп в каждом из UI. Затем сложить результаты и посмотреть, кто победит.

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

R3>А на русском нет?
Нет и не будет. А зачем вам на русском? Это же не художественная литература. Там и так всё понятно.

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

AN>Спасибки.
AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?
Поиск делается не в окне, а во всём дереве настроек.

AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели
Ну, это вторичный сценарий. Большинство пользователей (99%) работают всю жизнь на одном языке.
Для покрытия ещё 0.99% случаев достаточно сделать так, чтобы поиск на английском работал всегда, независимо от локали.
Требовать от пользователя указывать язык — избыточно.

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

S> AN>Спасибки.
S> AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?

S> Поиск делается не в окне, а во всём дереве настроек.
Мне было интересно откуда берутся ключевые слова для одной "настройки".
Или забиваются "автоматом" или берутся "из окна".

S> AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели

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

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

S> AN>Я пока заметил только это "Пишет, вроде бы, очевидные вещи", надо будет поискать остальное. Для меня подобное впечатление оставил Н.Вирт.

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

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

S> Когнитивная психология — это не последний крик моды. Тафти приводит примеры удачных информационных дизайнов образца 18го века, и примеры неудачных 20го.
Возможно я несколько неудачно выразился, но скажем, допустим так: если нужно сделать страничку веб-сайта, то от меня не будут требовать результата сопоставимого с работой профессионального дизайнера

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

S> AN>Первичный просмотр этого не выявил

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

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

S> Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12?
Это был просто как пример дополнительных условий. Можно расширить >=0 и =< x

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

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

S> В жизни задача не формулируется в терминах формы и её полей.
Ну в жизни, с подружкой также не через дисплей и клавиатуру общаешься.
S> Подумайте о таком сценарии: управление автомобилем.
S> Трогание с места на машине с механикой требует согласованного управления тремя параметрами: усилием торможения, коэффициентом сцепления, и оборотами двигателя.
Первое вроде редко требуется.
S> Трогание с места на машине с автоматом требует управления одним параметром: сначала усилием торможения, потом оборотами. В зависимости от модели машины "внутри" у неё есть ещё много "переменных".
Могу даже сказать, что в сумме набегает весьма внушительное число и есть люди занимающиеся исключительно только ими. При этом часто в качестве интерфейса они имеют notepad (+ mathcad). (За все места конечно не могу сказать, только то что видел)
S> Если бы автокомпании проектировали UI в "data-driven" парадигме, то на приборной панели была бы куча ручек, а разработчики бы объясняли, что не могут найти удобный способ "выделения группы параметров, которые хочется согласованно изменить".
Вроде до сих пор хороший способ для "ручной коробки передач" и не не найден, хорошо еще помню первые часы занятий в автошколе.
Просто был сделан специализированный интерфейс. Для обычного пользователя то не так уж и много параметров доступно. И становление этого интерфейса заняло не пару тройку лет.
S> Очевидно, что решение, пригодное для управления Приусом, не будет подходить для "общего случая одиннадцати параметров".
Но не зная общего можно было вполне и не решить частную задачу.

S> S>> В сторону выяснения того, для чего и что пользователь делает.

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

S> Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю.
Часто подобная информация далеко не очевидна. Как и варианты выясняются тогда, когда нельзя сделать того что хочется.

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

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

S> Общее решение годится только для прототипа. Снова подумайте об автомобиле. Как вы полагаете, PropertyGrid хорошо бы подошёл для управления автомобилем? А ведь с точки зрения теории управления там как раз "какие-то данные" передаются в одну сторону, и какие-то — в другую.
Ну для автомобиля не думаю что вообще, что то подойдет из компьютерных интерфейсов.
Хотя примерно ход мыслей понятен.
S> AN>Еще ни разу в голову не пришло прокладывать авто маршрут по карте. Это же вначале нужно найти мухосранск, а затем и дорогу как туда добираться.

S> А, простите, как вы прокладываете маршрут?
Очень просто, беру нави и загоняюю адрес. Гоогле при этом весьма далеко.
"Обзорных маршрутов", практически нет. Если хочу чего глянуть, смотрю вначале имеет ли смысл ехать, затем также забиваю конечный адрес или координаты. Часто просто смотрю в нави, что есть в ближайших окрестностях.
S> Лично я вбиваю начальную и конечную точки (кстати, безо всяких отдельных полей для номера дома и индекса), и прошу построить мне маршрут.
S> Дальше я смотрю на него и исправляю на карте. Потому что я вижу на карте более-менее интересные места, которые стоит посетить по дороге, и перетаскиваю к ним фрагменты маршрута.
Не спорю, что это удобней, но что мне потом с этой картой делать? Выписать ключевые точки и занести их в навигационное устройство?
S> Кроме того, если у меня есть несколько промежуточных точек, то только по карте можно понять, в каком порядке имеет смысл их посещать. Вот вы, к примеру, наизусть помните, что идёт первым по дороге из Рима в Милан — Пиза или Генуя?
Не требуется, заношу милан в качестве конечного пункта и пизу, генуя как промежуточные + требование кратчайшего пути. Хотя конечно надо проверить.

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

S>
S> Это от того, что проектировщики "настроек стандартного приложения" вдохновлялись контрольной панелью из win95.
Вроде она также далека.
S> Сейчас "стандартный UI" — это уже семёрка.
возможно, но у нас она стоит только на тестовых машинах.

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

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

S> AN>Никто и не заставлял их трахаться с "тремя дроп-даунами". А вводили они действительно 1.5. но в некоторых случая система воспринимала это как 5.1 при этом никаким колдовством лечить не получалось (это не был обычный едит контрол в вин-форме)

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

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

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

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

S> Нужно провести usability-тест и посмотреть success rate для каждого из UI. Пронаблюдать за тем, какие ошибки совершает каждая из групп в каждом из UI. Затем сложить результаты и посмотреть, кто победит. Тогда это будет подкидывание монетки.
каждая группа будет "ненавидеть" то что не по душе. Да и откуда возьмется необходимое число людей для достоверной выборки?
То есть все то вроде правильно, но как это сделать на практике, пока идей нет.

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

S> Когнитивная психология — это не последний крик моды. Тафти приводит примеры удачных информационных дизайнов образца 18го века, и примеры неудачных 20го.

Вот интересное замечание, со ссылками на магазин

http://www.rekomenda.ru/recomendation/LebedevArtemy/#lebedev_tufte

Это как дополнительная информация. Хотя неофициальные переводы похоже есть.

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

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

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

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

S>> Эти условия не берутся с потолка. Почему только одна из границ не может быть больше 10? Почему 10, не 12?
AN>Это был просто как пример дополнительных условий. Можно расширить >=0 и =< x
Я выделил важное. Мне неинтересно решать задачу "а что, если у лошади будет пять ног".

S>> На примере таблицы удобный способ реализован в Excel.
AN>Видимо, мне не удалось его найти, то что вы написали у меня не работает.
То есть Ctrl-D у вас не копирует верхнюю строчку выделения во все ниже неё, а Ctrl-R не копирует первый столбец текущего выделения направо? У вас не получается сделать копию ячейки через Ctrl-C, а потом выделить целый диапазон (не обязательно сплошной — при помощи Ctrl-Click) и нажать Ctrl-V?

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

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

AN>Могу даже сказать, что в сумме набегает весьма внушительное число и есть люди занимающиеся исключительно только ими. При этом часто в качестве интерфейса они имеют notepad (+ mathcad). (За все места конечно не могу сказать, только то что видел)
В качестве интерфейса имеем руль и две педали. Никакими маткадами в машине даже и не пахнет. БМВ как-то попробовали запустить цифровую систему управления второстепенными настройками, вроде музыки и климата. В результате — слово из шести букв, вторая — "и".

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

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

S>> Этого мало. Надо знать, из чего вообще состоит "планирование работы персонала". Насколько часто выполняются различные действия. Если это число настраивается один раз в жизни на уровне всей системы, то не стоит заставлять вводить его для каждого сотрудника. Может быть, надо дать возможность использовать несколько календарей вместо количества дней в неделе (как в MS Project). Может быть, надо дать возможность вводить рабочие периоды, не кратные 7 дням (смены 2 дня через 3 дня), потому что без этого кадровичке приходится руками забивать разное количество дней каждую неделю.
AN>Часто подобная информация далеко не очевидна. Как и варианты выясняются тогда, когда нельзя сделать того что хочется.
Эта информация вообще никогда не бывает очевидной. Более того, мой опыт подсказывает, что именно то, что считается очевидным, чаще всего оказывается неверным. Если подумать, то этому есть причина — то, что неочевидно, мы проверяем. Очевидные же вещи остаются непроверенными, поэтому именно там и живут заблуждения.

AN>Ну для автомобиля не думаю что вообще, что то подойдет из компьютерных интерфейсов.
Конечно. Из компьютерных интерфейсов можете сравнить способ подключиться к WiFi в Windows XP и в MacOS.

AN>Очень просто, беру нави и загоняюю адрес. Гоогле при этом весьма далеко.
Ну, это когда вас интересует маршрут "отсюда и дотуда", и у вас под рукой нет гугла.

AN>Не спорю, что это удобней, но что мне потом с этой картой делать? Выписать ключевые точки и занести их в навигационное устройство?
Ну, мне так и придётся делать — потому, что навигационное устройство, которое я возьму напрокат, вряд ли умеет импортировать карту из Гугла. Но это проблема не гугла, а того устройства.
Точно так же, как отсутствие возможности закачать авиарейс в виде iCalendar-инвайта — это косяк авиакомпаний, а не протокола ActiveSync. Лично мне бы это сэкономило массу усилий по забиванию рейсов в Outlook. (В телефон бы я вообще не стал затрудняться). В свою очередь, забивание рейсов в Outlook избавляет меня от проблем типа "забыл в какой день вылет", с которыми сталкиваются мои коллеги, и от суеты по вытаскиванию распечатки билета из рюкзака на бегу, когда я пытаюсь найти гейт, из которого вылетает мой следующий рейс.

S>> Сейчас "стандартный UI" — это уже семёрка.
AN>возможно, но у нас она стоит только на тестовых машинах.
а, то есть вы всё же рассчитываете на неё как на target платформу. В таком случае крайне полезно изучить "территорию противника". Проектировать под win7 в стиле win95 — это как-то непопацански.

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

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

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

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

S>> AN>Спасибки.
S>> AN>То есть похоже список ключевых слов собирается автоматом из зависимого окна?

S>> Поиск делается не в окне, а во всём дереве настроек.
AN>Мне было интересно откуда берутся ключевые слова для одной "настройки".
AN>Или забиваются "автоматом" или берутся "из окна".

S>> AN>Сделать установку языка для поиска. А то знаешь какое то слово на одном языке а как его перевели

S>> Ну, это вторичный сценарий. Большинство пользователей (99%) работают всю жизнь на одном языке.
S>> Для покрытия ещё 0.99% случаев достаточно сделать так, чтобы поиск на английском работал всегда, независимо от локали.
AN>Правильнее было по количеству поддерживаемых и установленных для приложения языков
В принцие-да. Но реальная ситуация в современном IT-мире такова, что пользователь знает два языка — английский и родной. Ситуация, когда пользователь знает название настройки на немецком, но сел за французскую версию UI — крайняя экзотика.
AN>По умолчанию стоит локаль, но есть возможность выбора.
Непонятно, зачем. Неужели имеет физический смысл искать слово "width" в русской локали или "ширина" — в английской?
Лишний контрол — лишние сомнения.

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

C>+1, только формат должен быть YYYY-MM, согласно ISO 8601.

Кто б придумал ISO стандарт на юзабилити...

A>textbox с форматом [yy]yy/[m]m

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

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

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

Мышой по комбикам:

1. Открыть месяца
   
2. Выбрать месяц
   
3. Открыть года
   
4. Выбрать год

Если с клавиатуры и комбиками, то:

1. Встать на месяц
   
2. Начинать набирать имя (1-3 нажатия, пусть примерно два)
   
3. Встать на год
   
4. Начинать набирать год (примерно 2 нажатия)

Если с текстовым полем, то:

1. Встать на поле
   
2. Начинать набирать имя месяца (1-3 нажатия, пусть примерно два)
   
3. Набрать разделитель месяца и года
   
4. Начинать набирать год (примерно 2 нажатия)

То есть не видно, в чём выигрыш-то?

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

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

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

_FR>Мышой по комбикам:
_FR>

_FR>
1. Открыть месяца
   _FR>
2. Выбрать месяц
   _FR>
3. Открыть года
   _FR>
4. Выбрать год
   _FR>

У вас сколько годов будет в списке? Вообще, про работу мышкой можете забыть — ей удобно делать только одиночный клик и драг-н-дроп. Всё остальное удобнее делать с клавиатуры.

_FR>Если с клавиатуры и комбиками, то:
_FR>

_FR>
1. Встать на месяц
   _FR>
2. Начинать набирать имя (1-3 нажатия, пусть примерно два)
   _FR>
3. Встать на год
   _FR>
4. Начинать набирать год (примерно 2 нажатия)
   _FR>

Я думаю, что первые две цифры у всех годов будут одинаковыми

_FR>Если с текстовым полем, то:
_FR>

_FR>
1. Встать на поле
   _FR>
2. Начинать набирать имя месяца (1-3 нажатия, пусть примерно два)
   _FR>
3. Набрать разделитель месяца и года
   _FR>
4. Начинать набирать год (примерно 2 нажатия)
   _FR>

Неправильно
Правильно — вот так: я набираю "май", у меня автоподставляется "май 2011" — дальше сразу tab и поехали. Если надо заплатить с января, то я набираю "я" — дальше сразу таб и поехали.
_FR> То есть не видно, в чём выигрыш-то?
В тщательном подсчёте
В данном сценарии может оказаться, что один комбо с набором периодов платежа удобнее всего — просто потому, что самые частые периоды это текущий (уже выбран) и предыдущий (выбирается одним нажатием кнопки "вниз").

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

S>>>Ни в коем случае не делать комбобоксы … сделайте простой текстовый ввод …
S>>>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.
_FR>>Мышой по комбикам:
S>У вас сколько годов будет в списке?

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

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

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

_FR>>Если с клавиатуры и комбиками, то:
S>Я думаю, что первые две цифры у всех годов будут одинаковыми

Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры.

_FR>>Если с текстовым полем, то:
S>Неправильно
S>Правильно — вот так: я набираю "май", у меня автоподставляется "май 2011" — дальше сразу tab и поехали. Если надо заплатить с января, то я набираю "я" — дальше сразу таб и поехали.

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

_FR>> То есть не видно, в чём выигрыш-то?
S>В тщательном подсчёте
S>В данном сценарии может оказаться, что один комбо с набором периодов платежа удобнее всего — просто потому, что самые частые периоды это текущий (уже выбран) и предыдущий (выбирается одним нажатием кнопки "вниз").

Ага, поэтому несколько более общий случай интереснее.

Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца.

Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а).

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


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

_FR>Тут не согласен. Несомненно, "тётенькам", привыкшим вколачивать что либо в компьютер посредством старого досовского софта конечно сложно "понять" мышь :о) Но вообще в данном конкретном случае, речь именно об одиночных кликах вообще-то. Максимум: о скроле. Колдунств с мышью не требуется: как например при выборе дат в календаре семёрки — что бы переключиться на текущий же месяц но прошлого года требуется клика четыре или даже пять кликов сделать :о(
Выпадающие календари — вообще зло. Но в семёрке хотя бы сделали попадание в зоны кликов реалистичным. Вообще, не все клики одинаковы.
1. Когда не знаешь куда кликать — клик стоит в 10 раз дороже привычного клика.
2. Стоимость клика обратно пропорциональна диаметру зоны клика. (Вот эти вот "вверх-вниз" рядом с номером года в календаре XP — это ужос-ужос)
3. Стоимость клика снижается, если он — в одном из углов экрана. (Обратите внимание, что кнопка Start в семёрке работает даже если нажать левее и ниже неё — именно по этой причине)

_FR>Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры.
Это какая-то непонятная мне фантазия. Стандартный дроп-даун ожидает при вводе содержимое айтема слева направо. Поэтому для выбора 2010 года нужно набрать 2-0-1, а не 1-0. Комбобокс богаче по возможностям — там хотя бы можно показать пользователю текущее положение курсора. Тем не менее, я пока с трудом себе представляю вот такое вот автозаполнение "из середины налево".

Так что пока я вижу ровно 4 нажатия для заполнения года.


_FR>Тоже самое можно сделать и в случае коммбобоксов. Основной выигрышь, я смотрю, в том, что набрав только "с" можно сразу получить "сентябрь прошлого года"? так это и в случае комбобоксов можно реализовать, если выделять, например (тут подумать надо как лучше (*), но то, что в принципе возможно, сомнений нет).
Для нескольких контролов всё осложняется задачей придумать согласованное поведение. Да ещё и так, чтобы пользователь его понял.

_FR>Ага, поэтому несколько более общий случай интереснее.
В несколько более общем случае несколько контролов начнут сосать ещё сильнее.

_FR>Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца.
Проблема в том, что понятность повышается ровно для одного сценария, и нет кривой обучения — скорость не улучшается для опытного пользователя.

_FR>Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а).
Это — грамотное решение. Непонятно только, зачем тогда вообще все контролы. Ну, то есть я понимаю, что это от безысходности.
Если бы была возможность, лучше сделать всё в редакторе. Если не распарсилось — помидоры и подчёркивания рисуются прямо в тексте. Туда же можно ткнуть мышой/клавиатурой и уточнить то, что нужно уточнить. В качестве примера опять же посмотрите в любую современную IDE — paste кода тут же подвергается синтаксической раскраске, ошибки компиляции подсвечиваются, и в полную силу работает intellisence.

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

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

Вам часто приходится заполнять платёжки за последние сто лет? В таком ракурсе говорить что-либо об удобстве заполнения формы на текущий год как-то безсмысленно а ближайшие несколько лет (от текущего и ниже) — очень даже возможно.

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

Проблема-то в том (вы семёркой-то пользуетесь? попробовали сделать то, что я описал?) что в календаре нельзя (как было в XP) с самостоятельно ввести число/месяц/год с клавиатуры, только последовательным выбиранием, то есть вместо того что бы один раз кликнуть на стрелке ап-дауна нужно несколько раз кликнуть в календаре, но к текущей теме это никакого отношения не имеет.

S>1. Когда не знаешь куда кликать — клик стоит в 10 раз дороже привычного клика.

Куда кликакть в комбобоксе известно обычно всем. Объясните, если посчитаете возможным, куда вы клоните?

S>2. Стоимость клика обратно пропорциональна диаметру зоны клика. (Вот эти вот "вверх-вниз" рядом с номером года в календаре XP — это ужос-ужос)

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

S>3. Стоимость клика снижается, если он — в одном из углов экрана. (Обратите внимание, что кнопка Start в семёрке работает даже если нажать левее и ниже неё — именно по этой причине)

Если уж говорить о кнопке старт, то она работает несколько иначе: если вы двигаете мышь из центра экрана к кнопке, то клик сработает только когда мышь окажется внутри круга кнопки +- 1 пиксель (при этом кнопка "загорается"), а вот при убирании указателя из области кнопки наружу кликнуть можно где-то в пределах десяти уже пикселей. Что это объясняет я не знаю.

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

_FR>>Именно поэтому я сказал, что "Начинать набирать год (примерно 2 нажатия)", то есть в комбике с годом в точности две последние цифры.
S>Это какая-то непонятная мне фантазия. Стандартный дроп-даун ожидает при вводе содержимое айтема слева направо. Поэтому для выбора 2010 года нужно набрать 2-0-1, а не 1-0. Комбобокс богаче по возможностям — там хотя бы можно показать пользователю текущее положение курсора. Тем не менее, я пока с трудом себе представляю вот такое вот автозаполнение "из середины налево".

S>Так что пока я вижу ровно 4 нажатия для заполнения года.

Я вижу аж два объяснения того, что я сказал:
1. В комбобоксе написано не "2010", а просто "10"
2. Отлавливание нажатий в комбике и самостоятельное выделение.

_FR>>Тоже самое можно сделать и в случае коммбобоксов. Основной выигрышь, я смотрю, в том, что набрав только "с" можно сразу получить "сентябрь прошлого года"? так это и в случае комбобоксов можно реализовать, если выделять, например (тут подумать надо как лучше (*), но то, что в принципе возможно, сомнений нет).
S>Для нескольких контролов всё осложняется задачей придумать согласованное поведение. Да ещё и так, чтобы пользователь его понял.

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

_FR>>Ага, поэтому несколько более общий случай интереснее.
S>В несколько более общем случае несколько контролов начнут сосать ещё сильнее.

Вы слишком извратно поняли мои слова насчёт общности, было бы продуктивнее прежде чем выдать подобную ничего не объясняющую (ибо понять, что значит "сосут" и что именно "сосут" и у кого "сосут" не представляется возможным) ремарку всё-таки попросить уточнить, если вам интересно конечно же. Если не интересно, то можно от ремарки и воздержаться, оки?

_FR>>Комбики кажутся понятнее — сложно с выбором ошибиться + и комбобокс можно сделать редактируемым с суггестом. Тогда и (*) можно разрулить, оставив по-умолчанию комбик с годом пустым и, если он таковым и остался, высчитать самостоятельно или инициализировать при переходе табом от месяца.
S>Проблема в том, что понятность повышается ровно для одного сценария, и нет кривой обучения — скорость не улучшается для опытного пользователя.

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

_FR>>Другой несомненный плюс — возможность Paste сразу и месяца и года, но и это решаемо: видел как-то следующую примерно реализацию. Формочка с набором контролов, в которые оператору нужно ввести данные. Первым среди контролов идёт текстбокс, в котором в строковом виде пользователь может ввести содержимое почти всех контролов, например "+ле 34/105 с *1000" + Tab заносит в контролы адрес "ул. Ленина" (отыскивается like-ом в справочнике) дом 34 квартира 105 за сентябрь тыща рублёв. Это действительно "смарт", то есть для профи быстрый набор и для эстетов сразу видно во что распарсилось (если где не распарсилось, рядом с соответствующими контролами можно нарисовать "помидоры" — иконки DataErrorProvider-а).
S>Это — грамотное решение. Непонятно только, зачем тогда вообще все контролы. Ну, то есть я понимаю, что это от безысходности.

Это для того, что бы при просмотре и изменении, а не внесении новой информации было бы удобнее. Делать же различный интерфейс для добавления (в виде одного текстового поля) и редактирования с набором контролов мне кажется странным? Вы не согласны?

S>Если бы была возможность, лучше сделать всё в редакторе. Если не распарсилось — помидоры и подчёркивания рисуются прямо в тексте. Туда же можно ткнуть мышой/клавиатурой и уточнить то, что нужно уточнить. В качестве примера опять же посмотрите в любую современную IDE — paste кода тут же подвергается синтаксической раскраске, ошибки компиляции подсвечиваются, и в полную силу работает intellisence.

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

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


_FR>Проблема-то в том (вы семёркой-то пользуетесь? попробовали сделать то, что я описал?) что в календаре нельзя (как было в XP) с самостоятельно ввести число/месяц/год с клавиатуры, только последовательным выбиранием, то есть вместо того что бы один раз кликнуть на стрелке ап-дауна нужно несколько раз кликнуть в календаре, но к текущей теме это никакого отношения не имеет.
Я пользуюсь семёркой. Не очень понимаю, чего именно нельзя сделать с клавиатуры. Если вы про тот календарь, который всплывает при клике в часы, то там всё выбирается и клавиатурой в том числе. Особенной деградации с XP нету.

_FR>Куда кликакть в комбобоксе известно обычно всем. Объясните, если посчитаете возможным, куда вы клоните?
В семёрочном календаре совершенно неочевидно, что можно вообще кликать в месяц/год.

_FR>Это про ап-даун? Я эти стрелки воспринимал всегда как подсказка что можно стрелочками с клавы скролиться. в семёрке с клавиатуры нельзя переключить календарь на прошлый год.
В семёрке вообще убрали инпут с номера года. По поводу клавиатуры — Ctrl-Up нажмите.
_FR>К тому же, для корриктировки она значительно удобнее постановки фокуса внутрь текстового поля, позиционирования курсора, выделения, набирания.
Тем не менее, попасть в текстовое поле можно табом, а для попадания в up/down нужно быть опытным снайпером.

_FR>Если уж говорить о кнопке старт, то она работает несколько иначе: если вы двигаете мышь из центра экрана к кнопке, то клик сработает только когда мышь окажется внутри круга кнопки +- 1 пиксель (при этом кнопка "загорается"), а вот при убирании указателя из области кнопки наружу кликнуть можно где-то в пределах десяти уже пикселей. Что это объясняет я не знаю.
Это неправда. Активная зона кнопки никак не зависит от направляения движения. Её хорошо видно — при нахождении в зоне кнопка светится.
Форма этой зоны представляет собой неправильную фигуру: слева и снизу она прямоугольная и прижата к краям экрана, сверху справа — круглая.

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

_FR>Я вижу аж два объяснения того, что я сказал:
_FR>1. В комбобоксе написано не "2010", а просто "10"
Да, такое решение сработает.
_FR>2. Отлавливание нажатий в комбике и самостоятельное выделение.
Можно попробовать. Хотя есть очевидные проблемы типа неопределеннности: если я набрал 20, то что нужно дозаполнить — первые две и получить 2020, или последние две и получить 2000?
Если мы это разрешим, то в итоге мы приходим к чему-то типа того, что я предлагал — есть текстовый язык, распознающий всякие разные паттерны. Комбовость бокса является аналогом интеллисенса.

_FR>То есть вы отрицаете возможность придумать понятное согласованное поведение двух контролов?
Нет, почему. Просто разгадка поведения двух контролов сразу представляет собой квест (собственно, большинство загадок в квестах именно такие). Квест хорош во время отдыха, а не во время работы.

_FR>Вы слишком извратно поняли мои слова насчёт общности, было бы продуктивнее прежде чем выдать подобную ничего не объясняющую (ибо понять, что значит "сосут" и что именно "сосут" и у кого "сосут" не представляется возможным) ремарку всё-таки попросить уточнить, если вам интересно конечно же. Если не интересно, то можно от ремарки и воздержаться, оки?
Поясняю: чем больше контролов, которые ведут себя неочевидно согласованным образом, тем сложнее понять, что вообще происходит, что произойдёт, если я изменю один из контролов, и в каком порядке нужно их менять, чтобы получить нужный результат.
Самый простой пример — аутлук автоматически передвигает конец митинга, если передвинуть начало — так, чтобы сохранить длительность. При этом перемещение конца митинга на начало не влияет. Поэтому важно редактировать контролы митинга в правильном порядке. Каждый пользователь в начале карьеры наступает несколько раз на эти грабли. И это только два контрола, с очень простой связью между ними.

_FR>То есть по-вашему пустой текстбокс с лейблом "Дата" гораздо понятнее?
Почему же пустой?

_FR>Это для того, что бы при просмотре и изменении, а не внесении новой информации было бы удобнее. Делать же различный интерфейс для добавления (в виде одного текстового поля) и редактирования с набором контролов мне кажется странным? Вы не согласны?
Согласен. Удобнее иметь ровно один интерфейс.

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

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

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

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

А>>Что посоветуете?
S>Ни в коем случае не делать комбобоксы. Если нет возможности избежать ввода вообще (через сканирование квитанций, как тут уже посоветовали), сделайте простой текстовый ввод. Дайте возможность исправлять ошибки. Убедитесь, что легко вводятся самые частые вещи (например, "пр" = предыдущий месяц, "т" = текущий месяц). Что при неуказании года автоматом берётся месяц из последних 12 ти (в апреле 2011 "апрель" = апрель 2011, "янв" = январь 2011, "май" = май 2010.)
S>Аналогичная фигня с годами, чтобы можно было набрать "май 11" и всё сработало.
S>Просто посчитайте, сколько кликов нужно для выбора месяца и года в комбобоксах, и сравните с текстом. Операторы будут вам благодарны.

а как базе хранить период оплаты?
особенно если может быть несколько квитанций за месяц?
если в БД формат будет датой, то какой день месяца подставлять?

Здравствуйте, Аноним, Вы писали:
А>а как базе хранить период оплаты?
Откуда же я знаю. Всё зависит от задачи.
А>особенно если может быть несколько квитанций за месяц?
А>если в БД формат будет датой, то какой день месяца подставлять?
Всё зависит от задачи. Какие отчёты нужно строить по этой базе?

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

S>Здравствуйте, Аноним, Вы писали:
А>>а как базе хранить период оплаты?
S>Откуда же я знаю. Всё зависит от задачи.
А>>особенно если может быть несколько квитанций за месяц?
А>>если в БД формат будет датой, то какой день месяца подставлять?
S>Всё зависит от задачи. Какие отчёты нужно строить по этой базе?

очень простые — баланс(дебет-кредит) за месяц по типу квитанции

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

А>очень простые — баланс(дебет-кредит) за месяц по типу квитанции
Если за месяц, то в базе достаточно хранить год и месяц. Зачем вам дата в БД?

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

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

А>>очень простые — баланс(дебет-кредит) за месяц по типу квитанции
S>Если за месяц, то в базе достаточно хранить год и месяц. Зачем вам дата в БД?

вообще не нужна. а как отчеты строить?

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

А>вообще не нужна. а как отчеты строить?
Я не могу понять, какой отчёт вы хотите построить, причём с полной датой он получается, а с месяцем и годом — нет.

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

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

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

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

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

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

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

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

А>вы запутались
А>мне нужен отчет по месяцам доход\расход по источникам платежей.
А>у вас я спросил как хранить период платежа в базе.
А>я склоняюсь хранить 01/месяц/год.
Можете так, можете просто месяц/год. Можете строкой в формате YYYYMM.

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

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

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

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

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

А>>вы запутались
А>>мне нужен отчет по месяцам доход\расход по источникам платежей.
А>>у вас я спросил как хранить период платежа в базе.
А>>я склоняюсь хранить 01/месяц/год.
S>Можете так, можете просто месяц/год. Можете строкой в формате YYYYMM.

Спасибо вам большое!