2015-05-13
879
Факторы проектирования текстовых сообщений:
| Содержание | Справочная система должна знать, что делает пользователь, и реагировать на его действия сообщениями соответствующего содержания |
| Опыт пользователя | Если пользователи хорошо знакомы системой, им не нужны длинные и подробные сообщения. В то же время начинающим пользователям такие сообщения покажутся сложными, малопонятными и слишком краткими. В справочной системе должны поддерживаться оба типа сообщений, а также должны быть средства, позволяющие пользователю управлять сложностью сообщений |
| Профессиональный уровень пользователя | Сообщения должны содержать сведения, соответствующие профессиональному уровню пользователей. В сообщениях для пользователей разного уровня необходимо применять разную терминологию |
| Стиль сообщений | Сообщения должны иметь положительный, а не отрицательный оттенок. Всегда следует использовать активный, а не пассивный, тон обращения. В сообщениях не должно быть оскорблений или попыток пошутить |
| Культура | Разработчик сообщений должен быть знаком с культурой той страны, где продается система. Сообщение, вполне уместное в культуре одной страны, может оказаться неприемлемым в другой |
Сообщения об ошибках. Проектирование справочной системы. Документация пользователя: функциональное описание, документ по инсталляции системы, вводное руководство, справочное руководство, руководство администратора
Первое впечатление, которое пользователь получает при работе с программной системой, основывается на сообщениях об ошибках. Неопытные пользователи, совершив
ошибку, должны понять появившееся сообщение об ошибке.
Новички и опытные пользователи должны предвидеть ситуации, при которых могут
возникнуть сообщения об ошибках.
При получении сообщения об ошибке пользователь часто не знает, что делать, и обращается к справочной системе за информацией. Справочная система должна предоставлять разные типы информации: как ту, что поможет пользователю в затруднительных ситуациях, так и конкретную информацию, которую ищет пользователь. Для этого справочная система должна иметь разные средства и разные структуры сообщений.
Все справочные системы имеют сложную сетевую структуру, в которой каждый раздел
справочной информации может ссылаться на несколько других информационных разделов. Структура такой сети, как правило, иерархическая, с перекрестными ссылками. Наверху структурной иерархии содержится общая информация,
внизу — более подробная.
Строго говоря, документация не является частью пользовательского интерфейса, однако проектирование оперативной справочной поддержки вместе с документацией является хорошим правилом. Системные руководства предоставляют более подробную информацию, чем диалоговые справочные системы, но строятся так, что бы быть полезными
пользователям разного уровня.
1. Функциональное описание, в котором кратко представлены функциональные возможности системы. Прочитав функциональное описание и вводное руководство, пользователь должен определить, та ли это система, которая ему нужна.
2. Документ по инсталляции, в котором содержится информация по уста-
новки системы. Здесь должны быть сведения о дисках, на которых поставляется система, описание файлов, находящихся на этих дисках, и минимальные
требования к конфигурации. В документе должна быть инструкция по инсталляции и более подробная информация по установке файлов, зависящих от
конфигурации системы.
3. Вводное руководство представляющее неформальное введение в систему, описывающие ее "повссдневное" использование. В этом документс должна содержаться информация о том, как начать работу с системой, как использовать общие возможности системы. Все описания должны быть снабжены примерами и
содержать сведения отом, как восстановить систему после ошибки и как начать
заново работу. В книге предложен эффективный способ составления вводного руководства, при котором основное внимание уделено восстановлению
системы после ошибок, а вся остальная информация, необходимая пользователям, сводится к минимуму.
4. Справочное руководство, в котором описаны возможности системы и их использование, представлял список сообщений об ошибках и возможные причины их появления, рассмотреть способы восстановления системы после выявления ошибок.
5. Руководство администратора, необходимое для некоторых типов программных
систем. В нём дано описание сообщений, генерируемых системой при взаимо-
действия с другими системами, и описаны способы реагирования на эти сооб-
щения. Если в систему включена аппаратная часть. то в руководстве админист-
ратора должна быть информация о том, как выявить и устранить неисправно-
сти, связанные с аппаратурой, как подключить новые периферийные
устройства и т.п.
36. Оценивание интерфейса. Показатели удобства использования интерфейса: изучаемость, скорость работы, устойчивость, восстанавливаемость, адаптируемость. Методики оценивания интерфейсов пользователя. Анкетирование, наблюдения за работой пользователей, видеонаблюдения типичного использования системы.
Это процесс, в котором оценивается удобство использования интерфейса и степень
его соответствия требованиям пользователя. Таким образом, оценивание интерфейса является частью общего процесса тестирования и аттестации систем ПО.
В идеале оценивание должно проводиться в соответствии с показателями удобства ис-
пользования интерфейса, перечисленными в табл. Каждый из этих показателей
можно оценить численно. Например, изучаемость можно оценить следующим образом:
опытный оператор после трехчасового обучения должен уметь использовать 80% функциональных возможностей системы. Однако чаще удобство использования интерфейса
оценивается качественно, а не через числовые показатели.
| Показатель | Описание |
| Изучаемость | Количество времени обучения, необходимое для начала продуктивной работы с системой |
| Скорость работы | Скорость реакции системы на действия пользователя |
| Устойчивость | Устойчивость системы к ошибкам пользователя |
| Восстанавливаемость | Способность системы восстанавливаться после ошибок пользователя |
| Адаптируемость | Способность системы "подстраиваться" к разным стилям работы пользователей |
Существуют простые и менее дорогостоящие методики оценивания интерфейсов пользователя, позволяющие выявить отдельные дефекты в интерфейсах.
Анкетирование пользователей — относительно дешевый способ оценки интерфейса. Вопросы должны быть точными, а не общими. Не следует использовать вопросы типа "Пожалуйста, прокомментируйте практичность системы", так как ответы, вероятно, будут существенно различаться.
При наблюдении пользователей за работой оценивается, как они взаимодействуют с системой, какие используют сервисы, какие совершают ошибки и т.п. Вместе с наблюдениями могут проводиться семинары, на которых пользователи рассказывают о своих попытках решить тс или иные проблемы и о том, как они понимают систему и как используют се для достижения целей.
Видеооборудование относительно недорого, поэтому к непосредственному наблюдению можно добавить видеозапись пользовательских семинаров для последующего анализа. Полный анализ видеоматериалов дорогостоящий и требует специально оснащенного комплекта с несколькими камерами, направленными на пользователя и на экран. Однако видеозапись отдельных действий пользователя может оказаться полезной для обнаружения проблем. Чтобы определить, какие именно действия вызывают проблемы у пользователя, следует прибегнуть к другим методам оценивания.
Вставка в программу кода, собирающего статистические данные при использовании системы, улучшает интерфейс несколькими способами. Обнаруживаются наиболее часто используемые операции. Интерфейс изменяется так, чтобы эти операции выбирались более быстро по сравнению с другими. Например, в вертикальном или выпадающем меню, наиболее часто используемые команды должны находиться вверху списка. Такой код также позволит обнаружить и изменить команды, способствующие появлению ошибок.
