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

G>На странице своего ЖЖ я собрал вместе несколько небольших приёмов по повышению usability десктопных приложений.

>1. Кнопка SEARCH сейчас появляется только после того как какое-то из полей "From:” или ‘To:’ изменено пользователем:
Лучше не прятать кнопку. Во-первых, это запутывает пользователя. Во-вторых, пользователь может захотеть обновить данные на тот же диапазон дат. В-третьих, не работает типовой сценарий: ввели дату, нажали enter.

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

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

>2. Когда поле "From:" или поле "To:" изменено (считая со времени предудущей операции поиска), его фон меняется на бледно-жёлтый:
Действие у вас связано не с самим полем ввода, а с кнопкой "search". Подсвечивать лучше её.

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

* В одном из проектов вместо подсветки мы анимировали кнопку — она чуть подёргивалась от нетерпения и радостно подпрыгивала под курсором Но это надо хорошего дизайнера в команду, иначе выглядеть будет кошмарно.

>3. Если пользователь изменил одно из полей, а другое поле ещё не трогал
Идея неплохая, но реализация запутывает пользователя. Заполнил дату, щёлкнул по гриду — фокус уехал в другой контрол.

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

>4. Если пользователь изменил одно из полей, а другое поле было (со времени предыдущего поиска) изменено ещё раньше — программа автоматически начинает поиск
Это _очень_ плохое решение.

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

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

>5. Восстановление выбранных строк после перезагрузки содержимого Grid-а
>6. Автоматическая прокрутка Grid-а после его перезагрузки

Одно но: выбираем два события за 25.03 и за 30.03. Ставим фильтр "по 28.03". Ищем записи. Ставим фильтр "по 28.04". Ищем записи. Событие за 30.03 остаётся невыбранным.

>7. Обработка ситуации “Дата FROM превышает дату TO”
См. комментарий к 4.

Саммари: вместо улучшения отдельных пунктов надо (временно) выкинуть существующее решение и оставить от него только:
1. Описание функционала с краткими примечаниями.
1.1. Основное UI отображает краткую информацию о нескольких событиях и предоставляет возможность распечатать эти события.
1.2. В 99% случаев пользователя интересуют события за определённый диапазон дат — имеет смысл спросить даты у пользователя до того, как отображать события.
1.3. Загрузка событий для отображения занимает неприлично долгое время (~1-5 сек). Типовая проблема с которой сталкивались в предыдущих версиях — пользователь теряет внимание и не всегда замечает, что данные уже обновились

2. Типовые сценарии использования:
2.1. Посмотреть события на ближайший месяц/неделю. *Уместно расширять интервал на несколько дней назад, чтобы пользователь не терял из виду только что прошедшие события. Вместо расширения интервала можно включать 1-2 прошедших события.
2.2. Выбрать и распечатать интересующие пользователя события.
2.3. Уточнить диапазон дат — увеличить (уменьшить) даты с и по, сместить интервал. * При ошибке ввода пользователь не должен терять события из виду.
...

На практике пунктов в 1 и 2 будет 7-10 штук, будет проще.

И тогда будет видно, что проблема у нас не с кнопкой search и даже не с подсветкой полей ввода, у нас UI плохо заточен под основные сценарии. Кнопка "печать" расположена чёрт знает где и незаметна на фоне самого грида. Половина пространства в гриде — пустое место. Для типовых сценариев использования нужно неприлично много кликов. Ну и тыды и тыпы, тут можно до посинения продолжать.

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

К каждому календарю можно добавить кнопки для быстрого изменения даты на день/неделю вперёд-назад. Выглядеть будет как-то так:

              <<  < [ календарь V] > >>
              |   |                |  `-----------\
На неделю назад   день назад       день вперёд    на неделю вперёд

Ну и дальше в том же духе. Главное — правильно определитесь с требуемым функционалом, сценариями использования и приоритетами по ним — тут слишком легко всё испортить, упустив что-то из виду или зациклившись на мелочи, нужной 1% пользователей.

Саммари 2: В дизайне UI рулят не отдельные фишки, а весь UI в целом и его заточенность под основные сценарии использования. С одной стороны это очевидно, с другой — 99% ui выглядят так, как выглядят