Usability.Ru | Статьи | Персоналии | Коллективы | Библиотека | Глоссарий | Обучение | Форум | Ссылки |
Виктор Андреев, Екатерина Сугак
Постановка задачи на проектирование и разработку сигнализации режимов работы пользователя
Материалы к докладу на 6 Юзабилити-семинаре
Практика разработки дизайнерских решений GUI в компании, производящей программный продукт, хорошо известны. Чаще всего решение принимается на уровне разработчика, пишушего клиентскую часть без всякого обоснования этого решения под грифом «а я так вижу». Однако бывает и так, что необходимость дизайнерского решения вообще не осознается. Если, например, индикация какого-либо качественного изменения в данных разработчику интутивно ясна, то сигнализация о состоянии взаимодействия пользователя с приложением (кроме, пожалуй, режима ожидания) вообще не расматривается как существенная часть GUI. В работе сделана попытка аргументировано обосновать введения отдельных дизайнерских решений, использующая классический эргономический подход в виде оценки ресурсов пользователя.
Для сертификации программного обеспечения по эргономическим стандартам ISO-9241 требуется обоснование для выбора важных дизайнерских решений в отношении элементов пользовательского интерфейса. К таким относятся режимы взаимодействия пользователя и приложения, работающего под Oracle.
Описание режимов работы:
- Режим просмотра данных в форме, где не допускается редактирование информации в полях ввода, при попытке это сделать выводится соответствующее сообщение.
- Режим первичного ввода данных при создании нового объекта БД, где большинство полей доступно для ввода или выбора значений.
- Режим редактирования полей формы, часть полей может быть недоступна для изменений, в том числе и при формировании новой версии объекта.
- Режим поиска (запроса), часть полей формы (поисковые поля) доступны для ввода или выбора, в других изменения и ввод неразрешены.
- Режим вывода версий объектов (предистории), аналогичен режиму просмотра, но позволяет «листать» версии и в случае вывода списка объектов дополняет его разными версиями этого объектов.
Проблема:
Причины возникновения неправильного распознавания лежат в большинстве случаев в необходимости работы с несколькими формами или приложениями, а также при переключении на другую деятельность (телефон, «живая» беседа) с отвлечением пользователя от страниц экрана на время более 30 сек. Неправильное распознавание режимов вызвано трудностью запоминания и диагностики состояния диалога в конкретной форме. Причем по преварительным наблюдениям было выявлено, что пользователи практически не смотрят на подсказку в строке состояний (статус – баре), к тому же подсказка возникает чаще всего при нажатии кнопок переключения режимов.
Для диагностики режимов в качестве сигналов используются отдельные визуальные признаки формы:
- просмотр
- диагностических признаков не обнаружено;- ввод нового объекта
– часть пустых полей в форме.- ввод новой версии
– диагностических признаков не обнаружено;- редактирование
- диагностических признаков не обнаружено;- поиска
– отсутствие данные почти во всех полях формы;- вывода версий (предистории)
– состояние кнопки на панели инструментов (тулбаре);Результаты оценки пользовательских ресурсов
Была проведена оценка объективных и субъективных показателей работы пользователя при неправильном распознавании режимов работы и получении сообщения об ошибке при выборе режима работы.
Значения объективных показателей показывают снижение продуктивности работы пользователя:
- Средняя частота неправильного распознавания – одна ошибка в час;
- Время исправления ошибки существенно зависит от задачи и личности пользователя, и лежит в диапазоне от 2 сек. до 2 минут. Среднее время – 10 сек.
Полученные данные показывают, что потери времени пользователя исходя из частоты и времени исправления ошибки – невелики. Однако эти данные были получены на семи опытных пользователях и нет сведений, каковы затраты у обучающихся и новичков.
Чаще ошибки совершались при неправильном распознавании режима поиска (запроса), возможно из-за того, что в одном случае необходимо было «войти» в режим запроса посредством нажатия кнопок, в другом случае режим запроса устанавливался по умолчанию при входе в форму.
Субъективные показатели были выбраны следующие:
- Место среди других раздражающих факторов. Вопрос- «Если расположить в ряд неудобства, раздражающие при работе, в ряд с какими неприятными и мешающими работе фактами Вы бы поставили отсутствие индикации режимов работы (отдельно поиск, ввод, редактирование, предистория)».
- Степень неприязни к возникающей ситуации. Вопрос – «По шкале от 0 до 99 в какой степени Вам мешают и раздражают ошибки, связанные с неправильным распознаванием режима работы».
- Приоритет исправления сигнализации режима. Вопрос – «Если бы была шкала приоритетов, какой бы Вы приоритет поставили доработкам, связанным с введением индикации режимов (отдельно для каждого)».
- Сравнение значимости субъективных и объективных показателей. Вопрос- «Если сравнить объективные потери времени исправления ошибки и субъективные потери, связанные с получением негативных эмоций, раздражения от нераспознавания режимов, какой из параметров будет важнее, значительнее?.»
По результатам опроса семи опытных пользователей из разных подразделений компании – разработчика (в основном – тестеры) было выявлено:
- субъективные факторы более значимы и сигнализация режимов работы в большей степени влияет на привлекательность, удобство работы;
- более неприятной для пользователя ситуацией является задержка во времени ответа, менее неприятной ошибки не выявлено, что свидетельствует о том, что к данной ситуации пользователи привыкли и относятся к ней снисходительно;
- степень неприязни к ошибке, возникающей при неправильном распознавании режимов, зависит от пользователя: для одних высокая, для других низкая, но в среднем она находится на субъективно значимом уровне (выше 25%);
- пользователи высказались, что приоритет доработок режима сигнализации – ниже среднего, но при исправлении других, важных функциональных ошибок - приоритет может повышаться до среднего.
Важное замечание
Фактом, требующим особого внимания, является высокая субъективная значимость ошибки распознавания режима при начальном знакомстве клиента с системой и на этапе обучения.
При знакомстве, возникновение ошибки вызывает у пользователя потерю ориентации в диалоге с системой и эмоции в зависимости от его характера: чувство вины или агрессию.
Этап обучения, сопровождающийся подобными ошибками, затягивается, и даже в первые месяцы пользователи совершают множества ошибок, пока не обнаружат существующие диагностические признаки или привыкнут к формам.
Примечание:
в последующих экспериментах проводилась оценка эффективности вариантов сигнализации режима запроса (поиска) и было обнаружено, что отсутствие сигнализации приводит к возникновению чувства тревоги у пользователей-новичков как реакции на неопределенность в поведения формы.Предложения к руководству отдела разработки ПО
- Разработать несколько вариантов сигнализации для одного режима – режима поиска, где чаще наблюдаются ошибки распознавания - 3 чел/часа эргономиста, т.к. часть вариантов уже есть.
- Подготовить методику сравнительной оценки эффективности каждого варианта по нескольким объективным и субъективным критериям - 8 чел/час руководителя группы эргономики
- Выбрать формы, для которых будет проводиться оценка (критерием отбора является частота использования режима поиска (запроса). – 2 чел/часа эргономиста
- Внести изменения в форму с учетом вариантов сигнализации – 4 чел/часа разработчика
- Провести оценку на 5-6 пользователях (можно на наших тестерах) – 15 чел/часов эргономиста и 10 чел/часов сотрудника – пользователя
- Произвести изменения во всех формах для включения сигнализации выбранного режима – по 1-2 час на форму.
Работа выполнялась сотрудниками группы по эргономике крупной софтверной компании.
Постановка задачи, выбор показателей, анализ результатов и выводы – руководитель группы Андреев В.Н., организация и проведение опросов пользователей и замеры объективных показателей реальной работы пользователя – эргономист Сугак Е.Е.
Разработка форм осуществялась с помощью стандартной библиотеки компонет Developer 2000 под Oracle.Варианты сигнализации режимов работы, возможные для реализации
Дата
публикации: 10 декабря 2001 г.
©Usability.Ru Публикация материала только с
согласия автора. При публикации ссылка на Usability.Ru обязательна!
Usability.Ru | Статьи | Персоналии | Коллективы | Библиотека | Глоссарий | Обучение | Форум | Ссылки |