kellylynch (kellylynch) wrote,
kellylynch
kellylynch

GUI: несколько приёмов для улучения usability

Ниже приведены несколько приёмов (techniques) для улучшения usability в GUI.

Приведённые здесь Приложения не являются “реальными”; это несколько "искусственные" примеры. Но сами рассматриваемые приёмы встречались в реальных продуктах, которые я разрабатывал.

DISCLAIMER: эта статья НЕ является "законченным use-case-ом показывающим как надо перерабатывать GUI с целью повышения usability"; это просто набор отдельных приёмов, собранных вместе в одном примере.


Эти Приложения написаны на  Silverlight, но данные приёмы можно применить к любому desktop-приложению, на чём бы оно не было написано. Silverlight здесь был выбран просто как пример.

ИСХОДНАЯ ПРОГРАММА

На  http://files.rsdn.ru/44022/LoreenRawDemoPage.html размещено браузерное Silverlight-приложение со следующей простой (пусть и несколько "надуманной") функциональностью:

Screen1

Здесь отображаются (с использованием grid control-а) некие События,у кждого из которых есть текстовое описание и дата. Пользователь имеет возможность выбрать события в интересующем его временном диапазоне (“From:” и “To:”), а потом распечатать некий (не реализованный в данном demo) Report по ним:

Screen1

Предполагается, что выборка Событий [из Базы данных, в которой они хранятся] по указанному временному диапазону занимает некоторое время, что и отражено в интерфейсе:

Screen1

Упомянутая выборка начинается по нажатию кнопки SEARCH (см выше).

Отметим что извлекаемые из Базы данные - статические. То есть они не будут кем-то изменяться пока открыто данное Приложение (предположим что эти данные - некий сгенерированный для анализа snapshot с каких-данных).

В типичном сценарии Пользователь Приложения работает с ним достаточно часто. Находясь в вышеописанной форме, типичный Пользователь поиск (по разным временным диапазонам) несколько раз прежде чем покинуть форму. Пользователь также часто будет прокручивать список Событий и выделять одну либо несколько строк в нём.






НЕСКОЛЬКО ПРИЁМОВ ПО УЛУЧШЕНИЮ USABILITY НА ПРИМЕРЕ ИСХОДНОЙ ПРОГРАММЫ

На http://files.rsdn.ru/44022/LoreenDemoPage.html размещено браузерное Silverlight-приложение, где собраны вместе приведённые ниже "приёмы". Приложение http://files.rsdn.ru/44022/LoreenDemoPage.html получилось из исходного путём применений к ней этих приёмов.

1. Кнопка SEARCH теперь запрещена изначально.
Screen1
Она становится разрешённой только после того как Пользователь поменял нечто в одном из полей From или To. После того как на неё нажали и запустили поиск - кнопка опять становится запрещённой, до следующего изменения полей From или To.

Так как выше мы сказали что "
извлекаемые из Базы данные - статические. они не будут кем-то изменяться пока открыто данное Приложение" - то у Пользователя не возникнет необходимости нажимать SEARCH если диапазон From-To не менялся со времени предыдущего поиска.

Таким образом, мы разрешаем кнопку SEARCH только на то время когда она действительно необходима; и запрещаем её в остальное время. Факт разрешения кнопки SEARCH служит для Пользователя своего рода "напоминанием": что-то поменялось (в связке полей From-To), но это изменение ещё не применено к отображаемым Событиям.
2. Если пользователь изменил одно из полей, а другое поле ещё не трогал - фокус ввода автоматически переходит на другое поле.

Это - приём своего рода "предсказания действий пользователя". Действительно - если пользователь поменял значение одного из этих двух полей, то {скорее всего} в этом поле ему больше делать нечего. Он либо нажмёт на SEARCH, либо перейдёт в другое поле - чтобы вести другую границу диапазона. Раз так, то мы "заранее" переводим фокус ввода в это "другое поле".
Screen1


Возможная критика такого решения:  к автоматическому перескакиванию фокуса принято относиться осторожно. Такие вещи иногда могут – наоборот – путать” Пользователя.
Ответ на возможную критику: в данном конкретном случае автоматическое перескакивание фокуса пусть и спорно, но допустимо. У нас здесь – небольшая (но часто используемая Пользователем) форма. Будь это окно редко используемым – действительно, от подобных “трюков” вроде перескакивания фокуса лучше отказаться: предсказуемость поведения GUI была бы важнее возможной выгоды от ускорения работы Пользователя. Но так как форма используется (по нашему сценарию) часто, то Пользователь успеет "привыкнуть" к этому поведению.

Перескакивание происходит только в одном месте формы, на соседних, близко расположенных,  control-ах. При этом выделяется (цветовой инверсией) содержимое control-а, на который мы автоматически переводим фокус. Плюс – вокруг control-а, на который, перешёл фокус появляется цветная рамка:
Screen1


То есть эти выделения привлекут внимание Пользователя и покажут ему – куда делся Фокус из предыдущего поля. Раз так, то можно не бояться того что Пользователь будет в недоумении – “куда это перепрыгнул Фокус, не могу его найти”.


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


Это - тоже из разряда "предсказания действий пользователя". Если пользователь поменял значение сначала одного из полей, а затем - другого, по всей вероятности вслед за тем он нажмёт кнопку SEARCH. Раз так, то начнём поиск, не дожидаясь этого.

Условия применения: применять данный приём надо весьма осторожно. Запуск Поиска здесь является (с точки зрения GUI) “деструктивным действиям”: операция Поиск хоть и не “уничтожает” никаких данных, но тем не менее она “сбрасывает” тот GUI-контекст который видел Пользователь.

Значит, если для Пользователя связка «заполнены оба поля From и To -> автоматически запущен Поиск” не будет “очевидной” – Пользователь может оказаться недоволен тем что [непрошеная] операция Поиск «сбросила” ему предыдущее состояние формы.

В данном случае – по нашему сценарию использования – это было приемлемо, так как представители Заказчика сами попросили о таком улучшении. Им – конкретно этому заказчику – данная связка показалась “очевидной”. Также играло свою роль то что типичный Пользователь использовал эту нашу форму довольно часто. Раз так, то он имел время «привыкнуть” к такому поведению интерфейса и начать считать его “естественным”.
В противном случае – если бы данная форма использовалась типичным Пользователем редко – я бы воздержался от автоматического запуска Поиска.


4.  Восстановление выбранных строк после перезагрузки содержимого Grid
Выберем (select) в Grid-е несколько строк:


Screen1

Затем осуществим поиск Событий по новому временному диапазону:
Screen1

Содержимое Grid-а перезагрузилось новыми строками:
Screen1

Но при этом мы сохранили selection на строках которые были selected перед операцией SEARCH.
Этот приём можно назвать принципом сохранения GUI-контекста”: стараться сохранить сложившийся на экране “контекст” при обновлении/пере-открытии некоей "локации" в GUI. Естественно - в том случае если есть основания полагать что Пользователю понадобится этот “контекст” (хотя бы частично) после этого обновления/пере-открытия.
Простой пример применения такого принципа: современные приложения обычно “запоминают” последнее расположение/размеры своего окна; и при повторном запуске приложения уже открывают это окно в запомненной позиции и с запомненным размером. При этом предполагается: “раз Пользователь ушёл от default-го размера/позиции окна, есть основания полагать что он захочет их иметь и в следующем сеансе работы с Приложением”.

Так и в нашем случае – если пользователь выделил некие строки в Grid-е, они могут быть ему интересны и после того как он изменит диапазон «From:” – “To:”. Поэтому программа – после перезагрузки Grid-а – восстанавливает selection на тех строках которые были выделены до перезагрузки Grid-а. Естественно, какие-то (или все) из предыдущих строк могут не попасть в новый диапазон дат – в этом случае они просто не будут показаны, и вопрос об их “выделении” не стоит.


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

Прокрутим Grid как показано ниже:
Screen1

Теперь поменяем диапазон дат и нажмём SEARCH:
Screen1

Содержимое Grid-а перезагрузилось в соответствии с новым диапазоном дат. Но при этом программа автоматически прокрутила Grid к тем же строкам которые были видны перед выполнением операции SEARCH:
Screen1
Это - тоже приём из серии (см. выше) “принцип сохранения GUI-контекста”: стараться сохранить сложившийся на экране “контекст” при обновлении/пере-открытии некоей локации GUI.

Естественно, какие-то (или все) из предыдущих строк могут не попасть в новый диапазон дат – в этом случае мы автоматически прокручиваем Grid к тем “предыдущим” строкам которые всё-таки попали в новый диапазон дат.

6.  Обработка ситуации “Дата FROM превышает дату TO”

В исходном варианте программы, если Пользователь вводил значение поля FROM превышающее значение поля TO, никакой специальной обработки у этого случая не было – просто поиск возвращал (естественно) пустой набор Событий.

Однако задумаемся – ведь ситуация “Дата FROM превышает дату TO” почти всегда будет в данном случае ошибкой ввода со стороны Пользователя. А раз так, то лучше не “проглатывать молча” эту ситуацию, а выдавать сообщение.
С другой стороны,  это сообщение не должно быть “слишком навязчивым” – ситуация не является “полноценной”, серьёзной ошибкой.
Поэтому в этой ситуации мы выводим такое вот сообщение:

Screen1

Это сообщение исчезнет как только Пользователь введёт что-то в поле FROM или TO.

Tags: рефакторинг GUI; usability
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 4 comments