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