Здравствуйте, 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 выглядят так, как выглядят
Здравствуйте, 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".
Вечная проблема — в документе получается не совсем то что ты ИМЕЛ В ВИДУ когда его задумывал :-)...
Здравствуйте, Glenn, Вы писали:
G>Спасибо за разбор
Оверквотинг!
G>Да, я перепишу статью, просто перечислив эти techniques как "набор приёмов", не претендуя на то что они будут "полным и завершённым usa case-ом рефакторинга некоего GUI".
Не стоит. Раньше у вас в статье было решение без постановки задачи, теперь будут только ответы без самой задачи и её решения
Что нужно добавить в статью — я написал выше, см. саммари.
Перед тем как использовать "набор приёмов", нужно знать:
1. Что UI должен уметь
2. Набор сценариев использования с ранжированием по приоритетам — что пользователь хочет от UI и как он собирается этого добиться (ни в коем случае не опускаемся до конкретной реализации — используем такие-то поля ввода, расположены там-то и там то). Повторюсь, п. 1-2 — это сама задача (Дано: ...
), не надо сюда писать решение.
Если постановки задачи нет — сами приёмы бесполезны.
Тут ровно та же ситуация, что и с паттернами: прочитал Фаулера/GoF — всё, уже архитектор
