sdt-book-2006 (1133574), страница 39
Текст из файла (страница 39)
Тем не менее, все,что можно сделать для достижения этого идеала, делать нужно.• Правило эффективности.Система не должна препятствовать эффективной работе опытных пользователей,работающих с ней долгое время.Очевидным примером нарушения этого правила является нацеленность системы только нановичков, например, выполнение почти всех операций с помощью мастеров (wizards),которые хорошо подходят для неопытного пользователя, ограничивая его в возможностисделать что-то не так, но неэффективны для эксперта, который и так знает, что и где емунужно сделать.• Правило непрерывного развития.Система должна способствовать непрерывному росту знаний, умений и навыковпользователя и приспосабливаться к его меняющемуся опыту.Плохие результаты приносит предоставление только базовых возможностей илиоставление начинающего пользователя наедине со сложным интерфейсом, которымуверенно пользуются эксперты.
Нарушение непрерывности при переходе от одного наборавозможностей к другому также приносит неудобства, поскольку пользователь вынужденразбираться с добавленными возможностями в новом контексте.Большинство пользователей можно поместить в три группы: новичков, опытных и средних,которые уже знают больше, чем новички, и не делают столько ошибок, но еще неприобрели автоматизма при выполнении большинства операций и иногда путаются винтерфейсе. Новичкам необходима помощь в освоении новой для них системы и контрольих действий, опытным пользователям — высокая эффективность выполнения частотребующихся действий и возможность гибкого управления системой в таких ситуациях,которые встречаются реже, но способны вызвать проблемы при их неадекватнойподдержке.
Про средних же пользователей часто забывают, хотя подавляющеебольшинство пользователей ПО относится к этой категории. Им нужны достаточновысокие эффективность и гибкость вместе с возможностью быстро получать адекватнуюпомощь по возникающим время от времени разнообразным вопросам.• Правило поддержки.Система должна способствовать более простому и быстрому решению задач пользователя.Это означает, прежде всего, что система должна действительно решать задачипользователя.
Кроме того, она должна решать их лучше, проще и быстрее, чем имевшиесядо ее появления инструменты и методы.• Правило соблюдения контекста.Система должна быть согласована с контекстом, в котором ей предстоит работать.Это правило требует от системы быть работоспособной не «вообще», а именно в томокружении, в котором ею будут пользоваться. В контекст могут входить специфика иобъемы входных и выходных данных, тип и цели организаций, в которых система должнаработать, уровень пользователей, зашумленность помещений и пр.129Представленные выше правила определяют общие требования, которым должен удовлетворятьудобный интерфейс. Кроме них при разработке ПО необходимы некоторые подсказки,позволяющие сделать его более удобным.Следующие принципы позволяют находить решения, повышающие удобствопользовательского интерфейса.••••••Принцип структуризации.Пользовательский интерфейс должен быть целесообразно структурирован.
Близкие посмыслу, родственные его части должны быть связаны видимым образом, а независимые —разделены; похожие элементы должны выглядеть похоже, а непохожие — различаться.Принцип простоты.Наиболее распространенные операции должны выполняться максимально просто. При этомдолжны быть видимые ссылки на более сложные процедуры.Принцип видимости.Все функции и данные, необходимые для решения определенной задачи, должны бытьвидны, когда пользователь пытается ее решить.Принцип обратной связи.Пользователь должен получать сообщения о действиях системы и о важных событияхвнутри нее.
Сообщения должны быть информативными, краткими, однозначными инаписанными на языке, понятном пользователю.Принцип толерантности.Интерфейс должен быть гибким и терпимым к ошибкам пользователя. Ущерб от ошибокдолжен снижаться за счет возможности отмены и повтора действий и за счет разумнойинтерпретации любых разумных действий пользователя и введенных им данных. Повозможности, следует избегать обязывающего взаимодействия (модальных диалогов),основанного на ограничении свободы пользователя.Принцип повторного использования.Следует стараться использовать многократно внутренние и внешние компоненты,обеспечивая тем самым унифицированность интерфейса и сходство между похожими егоэлементами.Методы разработки удобного программного обеспеченияОдним из наиболее технологичных подходов к разработке удобного пользовательскогоинтерфейса является проектирование, ориентированное на использование (usage-centered design),предложенное Л.
Константайном и Л. Локвуд (L. Constantine, L. Lockwood) [3].Основная идея этого метода — использование специальных моделей, способствующихадекватному определению набора задач, которые необходимо решать пользователям, и способоворганизации информации, позволяющих упростить их решение.Список моделей, которые используются в рамках проектирования, ориентированного наиспользование, следующий.• Модель ролей.Эта модель представляет собой список ролей пользователей системы. Каждая роль — этогруппа связанных задач и потребностей некоторого множества пользователей.
Модельролей может определять связи между ролями (роли могут уточнять друг друга, включатьдруг друга или просто быть похожими) и набор из одной-трех центральных ролей, накоторые, в основном, и будет нацелено проектирование.Кроме того, каждая роль может быть снабжена профилями, указывающими различные еехарактеристики по отношению к контексту использования системы. Профили могутвключать следующую информацию.o Обязанности — требования к знаниям (о предметной области, о самой системе и пр.),которым пользователь в данной роли, скорее всего, удовлетворяет.130o Умения — уровень мастерства в работе с системой.o Взаимодействия — типичные варианты взаимодействия пользователя в этой роли ссистемой, включая их частоту, регулярность, непрерывность, концентрацию,интенсивность, сложность, предсказуемость, а также управление взаимодействием(направляется ли оно пользователем, или он только реагирует на действия системы).o Информация — источники, объем, направление передачи и сложность информации привзаимодействии с системойo Критерии удобства — специфические критерии удобства работы для данной роли(быстрота реакции, точность указаний, удобство навигации и пр.).o Функции — специфические функции, возможности и свойства системы, необходимыеили полезные для данной роли.o Возможные убытки от ошибок, которые может совершить человек в данной роли, рискииспользования различных функций.Пример модели ролей для пользователей банкомата приведен на Рис.
61.МастеробслуживанияКлиент банкапохожиКлиент, иногдаснимающийнемного денегКлиент, иногдаснимающиймного денегКлиент,получающийзарплату по картеРисунок 61. Модель ролей пользователей банкомата.•Модель задач.Модель задач при проектировании пользовательского интерфейса строится на основесущностных вариантов использования (essential use cases). Описание сущностноговарианта использования отличается от обычного тем, что в рамках его сценариеввыделяются только цели и задачи пользователя, а не конкретные его действия.ДействияРеакцииВставить картуЗадачиОбязательстваРегистрация в системеСчитать данныеЗапросить PINПроверка личностиВвести PINПроверить PINВывести менюНажать клавишувыдачи денегПредложение набораоперацийВыбор операциивыдачи денегЗапросить суммуВвести суммуВывести суммуЗапроситьподтверждение131Нажать клавишуподтвержденияВернуть картуВыдать деньгиВыдача денегНапечатать чекВыдача чекаВыдать чекТаблица 9.
Описание обычного (слева) и сущностного (справа) вариантов использования.•Целью такого выделения является освобождение от неявных предположений о наличииопределенных элементов интерфейсов, что помогает разрабатывать их именно длярешаемых задач. Удобно описывать такие сценарии в виде двух последовательностей —устремлений пользователя (не действий, а задач которые он хочет решить) и обязательствсистемы в ответ на эти устремления.Пример описания обычного и сущностного варианта использования при работе приведен вТаблице 9.В результате модель задач представляет собой набор переработанных вариантовиспользования со связями между ними по обобщению, расширению и использованию.Некоторые из вариантов использования объявляются основными — без них программапотеряет значительное количество пользователей.Всякая пользовательская роль при этом должна быть связана с одним или несколькимивариантами использования.Модель содержимого.Модель содержимого пользовательского интерфейса описывает набор взаимосвязанныхконтекстов взаимодействия или рабочих пространств (представляемых экранами,формами, окнами, диалогами, страницами и пр.) с содержащимися в них данными ивозможными в их рамках действиями.При построении этой модели нужно определить, что войдет в состав интерфейса (какиеданные и функции), и не решать вопрос о том, как именно оно будет выглядеть.На начальном этапе один контекст взаимодействия ставится в соответствие одному (невспомогательному!) варианту использования или группе очень похожих вариантов, длявыполнения которых понадобится один и тот же набор инструментов.Средства для поддержки вспомогательных расширяющих вариантов использования обычноудобно помещать в контексты расширяемых ими основных вариантов.Сначала устанавливается, какая информация должна находиться в заданном контексте дляуспешного решения задач соответствующего варианта использования, затем определяетсясписок необходимых операций для работы с этой информацией.Поиск номеровИзвестная информация обискомом сотруднике (ФИОполностью, отдел, группа,номера телефонов, другое)Список найденныхсотрудников (ФИО,отдел, группа, номерателефонов)Поиск (по всематрибутам, в томчисле частичноопределенным)Сортировкаинформации осотрудникахПросмотр полнойинформации осотрудникеПереключатель междуразными списками (все,корпоративный, личный,часто используемыеномера)Рисунок 62.
Пример модели содержимого контекста взаимодействия.132Часто при обсуждении содержимого контекста взаимодействия для его представленияиспользуют лист бумаги с наклеенными на него подписанными стикерами разных цветов(для различения информационных элементов и элементов управления). Такоепредставление удобно для быстрого внесения изменений по ходу обсуждения. Оно такженаглядно показывает, что рассматривается лишь прототип окна или странички, а егоэлементы абстрактны, для них пока не предлагается конкретная форма. Его трудно принятьза «почти готовый» проект окна, формы или странички, описывающий итоговые форму,расположение и цвета элементов интерфейса.На Рис.
62 приведен пример модели содержимого окна поиска номеров телефоновпрограммы, реализующей корпоративный телефонный справочник.После определения набора контекстов и их информационного и функциональногосодержимого рисуется карта навигации между контекстами, показывающая возможныепереходы между ними. Карта навигации объединяет различные контексты взаимодействияв рамках модели содержимого интерфейса.ОсновноеокноПараметры страницы — переход на последнюю использованную закладкуПараметры страницыПечатьБумагаПечатьПоискпринтераДополнительныенастройки печатиОтступыРазмещениеНумерациястрокГраницыСвойствапринтераРисунок 63. Часть карты навигации редактора Microsoft Word.После разработки модели содержимого всякий основной вариант использования долженбыть поддержан при помощи одного или нескольких контекстов взаимодействия.
Чемменьше контекстов нужно использовать для выполнения одного варианта использования,тем лучше.Перечисленные три вида моделей — ролей, задач и содержимого — являются основными.Оставшиеся два вида моделей используются только при необходимости.• Операционная модель описывает контекст использования системы и состоит из профилейпользовательских ролей.• Модель реализации представляет собой визуальный проект интерфейса и описание егоработы.Основные виды деятельности в рамках проектирования, ориентированного на использование,следующие.• Совместное с пользователями определение требований к ПО, с учетом пожеланий итребований к его интерфейсу.• Разработка модели предметной области с помощью пользователей.• Разработка моделей ролей и задач с помощью пользователей.• Разработка модели содержимого.133•••••••••Разработка визуального проекта интерфейса (модели реализации).Контроль удобства использования проекта интерфейса с участием пользователей.Проектирование объектной структуры ПО.Определение стандартов и стиля интерфейса с привлечением пользователей.Проектирование и разработка справочной системы и документации.Привязка интерфейса к контексту использования.Итеративная разработка архитектуры ПО.Итеративное конструирование ПО с постепенным введением запланированных функций.Контроль удобства использования готового ПО.Совместное определение требований *Разработка моделисодержимогоРазработка проектаинтерфейсаКонтроль удобстваиспользования *ИтеративноеконструированиеВремяРазработка справочнойсистемы и документацииРазработка моделейролей и задач *Определение стандартов истиля *Проектированиеобъектной структурыПривязка к контекстуиспользованияРазработка моделипредметной области *АрхитектурныеитерацииКонтроль удобстваиспользования *Рисунок 64.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
