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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>5. Восстановление выбранных строк после перезагрузки содержимого Grid-а
>>6. Автоматическая прокрутка Grid-а после его перезагрузки
S> :up:
S>Одно но: выбираем два события за 25.03 и за 30.03. Ставим фильтр "по 28.03". Ищем записи. Ставим фильтр "по 28.04". Ищем записи. Событие за 30.03 остаётся невыбранным.

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

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

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

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

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

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

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

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

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

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


Спасибо за разбор

Сейчас я вижу мне стоило написать свою статью по=другому, "не замахиваясь" на "рефакторинг GUI" вообще. Пример сам со себе — действительно "искусственный"; главной целью было — показать вот эти "приёмы" (techniques). Которые в реальности лежали в нескольких разных продуктах. ТАМ были и кнопка "На неделю назад", и кнопка "день вперёд" которые Вы совершенно верно предложили...

Да, я перепишу статью, просто перечислив эти techniques как "набор приёмов", не претендуя на то что они будут "полным и завершённым usa case-ом рефакторинга некоего GUI".

Вечная проблема — в документе получается не совсем то что ты ИМЕЛ В ВИДУ когда его задумывал :-)...