Пользователи должны видеть удобные в применении и имеющие смысл названия объектов и представлений объектов. На решении именно этой задачи должны сосредоточиться разработчики. Внимательно и осторожно выбирайте названия объектов и представлений. Обязательно проводите тестирование на удобство применения с участием потребителей.
Названия объектов и представлений чаще всего появляются в меню и названиях окон. Каждое открытое окно содержит название объекта и представления на панели названия.
Помощь пользователям должна оказываться в том виде, в котором она им необходима. Она является представлением объекта и состоит из информации, принимающей любые формы. Необходимо определить, какой тип помощи предпочитают пользователи.
Представления объектов должны быть динамическими и тесно взаимосвязанными. Если пользователь вносит в объект изменения, влияющие на другие представления, то новшества должны отражаться немедленно или как можно быстрее. Использование многочисленных представлений позволяет сразу же увидеть результаты их изменений.
Перечисленными представлениями должны сопровождаться все типы объектов. В проблемно-ориентированных программах опции и свойства, как правило, отражаются в диалоговых окнах внутри приложения. В ООПИ пользователи должны уметь изменять все характеристики объекта в виде свойств (цвета, шрифта, названий и т.д.).
Представление системы помощи. Информация отражается в представлениях системы помощи для поддержки работы пользователя с объектами. С точки зрения разработчика – помощь является видом объекта, однако пользователи, как правило, получают вспомогательную информацию через главное или всплывающее меню. Помощь может оказываться на уровне объекта или конкретного элемента, например для поля ввода (контекстная подсказка).
Описание типа объекта (данных, контейнера или устройства) являются техническими терминами, а пользователи должны видеть только названия объектов или классов, например «документ», «папка» или «принтер». Составное представление также является техническим термином, у которого должно быть пользовательское название, например WYSIWYG вид для документа. Представления содержания подаются пользователям как название вида содержания (иконки, древовидная схема, детали и т.п.). Представление свойств является и техническим, и пользовательским термином. Изображается как окно Свойства.
Как и в реальном мире, совокупность объектов (возможно, различных типов), образует некоторую среду (окружение) пользователя. Исходя из этого, большинство заданий пользователя могут быть представлены (описаны) как определенная комбинация взаимосвязанных объектов. Так, например, обработка текстового документа может быть описана как композиция операций, выполняемых над его элементами (отдельными словами, параграфами и т.д.). Благодаря такому подходу любые, сколь угодно сложные конструкции могут быть реализованы на основе небольшого числа базовых соглашений. При условии последовательной и согласованной реализации этих соглашений для всего пользовательского интерфейса эффективность работы пользователя существенно возрастает. Кроме того, указанный подход способствует модульной, компонентно-ориентированной разработке приложения, т.е. новое задание может быть выполнено путем адаптации или рекомбинации тех же объектов.
В реальном мире объекты сохраняют свое текущее состояние до тех пор, пока оно не будет изменено под влиянием каких-либо внешних воздействий. Например, если вы, уходя из дому, закрыли окно, оно, скорее всего, останется в таком же состоянии до вашего возвращения. Это же правило должно быть справедливо и для объектов интерфейса. За исключением тех случаев, когда требуется явное указание пользователя на сохранение данных, все объекты окружения должны быть сохранены автоматически. Кроме того, должна сохраняться и визуальная информация о состоянии окружения, такая, например, как позиция курсора, расположение и размер окна, с тем чтобы это состояние могло быть восстановлено при последующем сеансе работы пользователя.
При всех достоинствах объектного подхода к разработке интерфейса, его использование само по себе не гарантирует требуемого качества интерфейса. Для создания эффективного пользовательского интерфейса необходимо дополнить объектный подход тщательным проектированием всех компонентов интерфейса с ориентацией на потребности потенциального пользователя.
Первым шагом в объектно-ориентированном проектировании интерфейса должен быть анализ целей пользователей и особенностей выполняемых ими заданий. При проведении такого анализа следует определить основные компоненты или объекты, с которыми взаимодействует пользователь, а также характерные особенности объектов каждого типа. Необходимо также выявить перечень операций, выполняемых над объектами, их влияние на состояние и свойства объектов.
После завершения анализа можно переходить к описанию возможных способов взаимодействия пользователя с объектами различных типов. На этом шаге выбирается форма визуального представления объектов. При этом следует иметь в виду, что визуальный образ объекта в зависимости от ситуации может изменяться. Например, контейнер может быть представлен и в виде пиктограммы, и в виде окна, отображающего содержимое этого контейнера.
Завершает процесс проектирования компоновка и размещение на экране визуальных элементов интерфейса.
Объектные интерфейсы практически всегда гораздо лучше интерфейсов имплементационных (собственно говоря, объектные интерфейсы – это следующая, после имплементационных интерфейсов, ступень эволюции). Поспорить с этим невозможно, но открытым остается вопрос – что лучше объектных интерфейсов? Какова следующая эволюционная ступень?
Это, вероятно, деятельностно-ориентированные интерфейсы (ДоИ, обратите внимание, что это наш, относительно условный термин). В отличии от объектных интерфейсов, в которых пользователю предоставляются объекты и свобода манипулирования ими, в ДоИ «строительными блоками» являются задачи пользователя. В качестве примера можно привести диалоговое окно создания нового документа в MS Word: создать можно не просто обобщенный документ, одинаково плохо решающий все задачи, но документ для текущей задачи пользователя (например, письмо).
Перед тем, как перечислять преимущества этого вида интерфейсов, нужно определить, чем несовершенны интерфейсы объектные. Недостатки их таковы:
Такие интерфейсы требуют от пользователя существенных когнитивных нагрузок и способности к абстрактному мышлению: пользователю необходимо транслировать цель своих действий в конкретный алгоритм использования объектов. Это требует определенных усилий, так что при прочих равных от этой работы пользователей следует освободить.
Объектные интерфейсы зачастую требуют от пользователя серьезных усилий по отвлечению от собственной предметной области и привлечения внимания к вопросу «компьютерной поддержки» своей деятельности: репрезентируемые объекты, будучи универсальными, не полностью соответствуют предметной области конкретного пользователя. Например, разные интерфейсы почтового клиента нужны пользователю, который получает 5 писем в день и пользователю, который получает 70 писем, хотя в обоих случаях объекты (письма) одни и те же.
Во многих случаях «объектность» интерфейса подталкивает его разработчика к совершению некорректных действий: в поиске объектов деятельности разработчики чаще всего ограничиваются правами доступа. Смена парадигмы может форсировать разработчиков более тщательно подходить к проектированию функциональности и интерфейса (хотя и новая парадигма, вероятно, тоже будет подталкивать разработчиков к совершению некорректных действий).
Деятельностно-ориентированные интерфейсы этих недостатков, как правило, лишены, благодаря чему они оказываются более эффективными, чем объектные интерфейсы.
Частным, вырожденным, примером деятельностно-ориентированного интерфейса являются мастера (Wizards). Вместо того, чтобы показывать пользователю единое диалоговое окно со сложной конфигурацией элементов управления, пользователю выдается сравнительно простая последовательность экранов. В идеальном случае, когда каждый последующий экран зависит от действий пользователя на предыдущем экране, мастер оказывается чрезвычайно эффективным. В неидеальном случае, когда его экраны не связаны между собой, он всё равно оказывается более эффективным (незначительное снижение скорости работы компенсируется низкими когнитивными нагрузками пользователя и другими факторами).
Но мастера это только начало пути: деятельностно-ориентированного в них не так уж и много. В будущем интерфейсы, идя по пути большей ориентированности на задачи и деятельность пользователей, достигнут ещё большей эффективности, при этом:
Разделение между интерфейсами, предназначенными для профессионалов и непрофессионалов, будет увеличиваться (как это уже произошло во всех других областях техники).
Программы будут становиться все более и более специализированными: не просто текстовый редактор, а текстовый редактор для сугубо определенной группы пользователей, решающих определенные задачи.
Адаптивность интерфейсов будет увеличиваться: они будут все больше и больше учитывать характерные особенности работы конкретных пользователей.
Количество технических подробностей (файлы, папки, порты и т.п.) в большинстве интерфейсов будет резко сокращено, поскольку эти объекты не связаны напрямую с деятельностью пользователей.
Что такое тестирование на удобство применения? Международная организация стандартизации (ISO) дает следующее определение: «Удобство применения – это эффективность, рентабельность и удовлетворение, с которым пользователи могут выполнить те или иные задачи в заданной среде». Тестирование на удобство применения проводится для того, чтобы оценить качество работы продукта и выяснить, насколько он эффективен, рентабелен и довольны ли им пользователи.
Тестирование на удобство применения является неотъемлемой частью итерационного процесса разработки и проектирования продукта.
В бюджете тестирование на удобство применения и его оценка должны рассматриваться как часть рабочих расходов. На проведение такого тестирования должно выделяться от 5 до 10% от общего бюджета. Как и другие рабочие расходы, они впоследствии окупятся повышением доходов, связанных с улучшением качества продукта.
Существуют следующие способы проведения тестирования:
- наблюдение;
- проведение опросов и исследований;
- контекстуальные опросы;
- эвристические оценки;
- работа с выделенными группами;
- лабораторное тестирование.
Важной частью любого тестирования является правильный подбор пользователей (и достаточного их числа). Участники теста должны быть типичными представителями пользователей данного продукта. Их количество зависит от многих факторов: времени, ресурсов, проекта теста, типа тестируемых задач и вида статистического анализа результатов.
Если вас интересуют основные проблемы удобства применения, то достаточно будет 4-8 участников. Если по завершении тестирования возникают новые проблемы, то количество участников следует увеличить.
Методы оценки удобства применения должны быть производными от целей и задач, стоящих перед продуктом. Как правило, тестирование на удобство применения включает два типа методов оценки:
- методы оценки работы, подразумевающие подсчет действий, определение полноты выполнения задачи, подсчет времени, затраченного на это выполнение, ошибок и обращений за помощью. Такие методы называют численными;
- субъективные методы, включающие сбор устных и письменных сообщений пользователей об их восприятии, мнениях, суждениях, предпочтениях, а также степени удовлетворенности от системы и их собственной выполненной работы. Эти методы носят название качественных.
