Несколько небольших приёмчиков по повышению usability.
От: Glenn  
Дата: 26.03.13 14:46
Оценка: 21 (2) :)
На странице своего ЖЖ я собрал вместе несколько небольших приёмов по повышению usability десктопных приложений.

Сам приведённый в той статье пример – несколько ‘искусственный' (не мог же я разместить скриншоты своего защищённого NDA продукта :-) ); но приёмы эти я взял из реальных приложений...
Glen
usability
Re: Несколько небольших приёмчиков по повышению usability.
От: Sinix  
Дата: 27.03.13 06:17
Оценка: 5 (2) +3
Здравствуйте, 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 выглядят так, как выглядят
Re[2]: Несколько небольших приёмчиков по повышению usability.
От: Glenn  
Дата: 27.03.13 08:04
Оценка:
Здравствуйте, 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".

Вечная проблема — в документе получается не совсем то что ты ИМЕЛ В ВИДУ когда его задумывал :-)...
Glen
Re[3]: Несколько небольших приёмчиков по повышению usability.
От: Glenn  
Дата: 27.03.13 08:14
Оценка: +1
>>5. Восстановление выбранных строк после перезагрузки содержимого Grid-а
>>6. Автоматическая прокрутка Grid-а после его перезагрузки

Вот ЭТИ вещи (в том реальном продукте, из которого они и взяты) как раз и были сделаны по запросу конечного Пользователя.
Ему часто приходилось "перескакивать" с одного временнОго диапазона на другой — частично перекрывающийся. При этому у него (в исходном, "простом" варианте) каждый раз "уезжало из вида" то конкретное место в массиве Событий с которым он работал — "простой" Грид просто терял текущую позицию прокрутки при пере-загрузке контента.

Также Пользователю часто приходилось выделять несколько интересующих его строк Грида. А потом — после того как он менял временнОй диапазон — всё что он "накликал", пропадало при пере-загрузке контента Грида.

Когда Пользователь попросил меня сделать это, я в свою очередь вспомнил своё личный опыт при работе с разного рода диалоговыми окнами Open File: такое окно при открытии, естсественно, показывает содержимое текущей Папки "с самого начала". А если приходится просматривать файл за файлом по схеме —
— загрузил Файл100 в Приложение;
— увидел что Файл100 — это "не то что нужно";
— загрузил Файл101 в Приложение;
— увидел что Файл101 — это "не то что нужно";
и тд

и если эти Файл100, Файл101 и тд находятся далеко от начала списка файлов? Каждый раз после открытия Open File тебе тогда приходится "проматывать" список файлов в нужное тебе место....
Glen
Re[3]: Несколько небольших приёмчиков по повышению usability.
От: Sinix  
Дата: 27.03.13 08:51
Оценка:
Здравствуйте, Glenn, Вы писали:

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


Оверквотинг!

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


Не стоит. Раньше у вас в статье было решение без постановки задачи, теперь будут только ответы без самой задачи и её решения

Что нужно добавить в статью — я написал выше, см. саммари.
Перед тем как использовать "набор приёмов", нужно знать:
1. Что UI должен уметь
2. Набор сценариев использования с ранжированием по приоритетам — что пользователь хочет от UI и как он собирается этого добиться (ни в коем случае не опускаемся до конкретной реализации — используем такие-то поля ввода, расположены там-то и там то). Повторюсь, п. 1-2 — это сама задача (Дано: ... ), не надо сюда писать решение.

Если постановки задачи нет — сами приёмы бесполезны.
Тут ровно та же ситуация, что и с паттернами: прочитал Фаулера/GoF — всё, уже архитектор
Re[4]: Несколько небольших приёмчиков по повышению usability.
От: Sinix  
Дата: 27.03.13 08:54
Оценка:
Здравствуйте, Glenn, Вы писали:

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

>>>6. Автоматическая прокрутка Grid-а после его перезагрузки

G>Вот ЭТИ вещи (в том реальном продукте, из которого они и взяты) как раз и были сделаны по запросу конечного Пользователя.


Угу, как только "фишки" в дизайн добавляются не по велению левой пятки, а на основе реальных сценариев использования — они сразу становятся полезны, удобны и не вызывают никаких вопросов. Остальные пункты, на мой взгляд, скорее запутают пользователя, чем помогут ему разобраться в UI.
Re[4]: Несколько небольших приёмчиков по повышению usability.
От: Glenn  
Дата: 27.03.13 09:05
Оценка:
S>Не стоит.

...

Ленин в этот скулеж недужный
врезал голос бодрый и зычный:
— Нет, за оружие браться нужно,
только более решительно и энергично!


...

:-)
Glen
Re[2]: Несколько небольших приёмчиков по повышению usability.
От: Glenn  
Дата: 28.03.13 19:35
Оценка: +1
Здравствуйте, Sinix, Вы писали:

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

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


Хм... а я здесь и хотел иметь именно такую логику, да. Я имел в виду: "по завершении операции SEARCH мы select-нем те (которые доступны) строки, которые были selected перед нажатием кнопки SEARCH". Мне именно это поведение казалось "естсественным".
А из Вашего коммента вижу что Вам "есественным" показалось несколько другое поведение: "запоминать факт того что некая строка selected; после чего делать её selected (когда она доступна) после любой операции SEARCH — пока Пользователь не сбросит ей selected state".

Хм....жаль что под рукой нет "фокус-группы Пользователей" за которой мы могли бы наблюдать через односторонне стекло :-)
Glen
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.