В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 40
Текст из файла (страница 40)
Даже если системе требуется много времени для выполнениякаких-то действий, показываемые в это время картинки и предоставляемаядополнительная информация могут снизить субъективную длительность ожидания.o Если у пользователей, даже достаточно неопытных, не возникает стресса при работе ссистемой. Стресс может возникнуть по многим причинам. От осознания ответственности за производимые действия и невозможностиотменить их, если они вдруг окажутся неправильными. От необходимости поддерживать высокий уровень внимания, запоминать какие-товещи, чтобы использовать их позднее, или серьезно обдумывать выполнениекаждого очередного действия. От отсутствия контроля за поведением системы, когда она выполняет непонятныедействия или сообщает о событиях, которые сам пользователь не инициировал (илине может связать их со своими предыдущими действиями).Другой источник потери ощущения контроля — изменчивость самого интерфейса.Если кнопки, элементы меню и пр.
то появляются в определенных местах, тоисчезают или становятся неактивными по неизвестным (ненаблюдаемымнепосредственно) причинам, пользователь теряется. Связанный с таким поведениемсистемы стресс объясняется также невозможностью быстро построить в сознаниимодель ее поведения — система становится чем-то зыбким, неустойчивым. От частых, категоричных и неинформативных сообщениях об ошибках.128o Удовлетворение пользователей выше, если дается возможность настроить интерфейспрограммы так, как им нравится, но при этом предоставленных вариантов не чересчурмного, чтобы пользователь не мог в них «заблудиться».Специалисты по удобству использования обычно формулируют некоторый набор принципов иправил, позволяющих как оценивать удобство интерфейса, так и предлагать решения,повышающие его удобство.
Ниже приведены такие правила из [3].• Правило доступности.Система должна быть настолько понятной, чтобы пользователь, никогда раньше невидевший ее, но хорошо разбирающийся в предметной области, мог без всякого обученияначать ее использовать.Это правило служит некоторым идеалом, к которому надо стремиться, поскольку напрактике достичь такой степени понятности почти никогда не удается.
Тем не менее, все,что можно сделать для достижения этого идеала, делать нужно.• Правило эффективности.Система не должна препятствовать эффективной работе опытных пользователей,работающих с ней долгое время.Очевидным примером нарушения этого правила является нацеленность системы только нановичков, например, выполнение почти всех операций с помощью мастеров (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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
