Заголовок1. Arial 12, полужирный, по центру, интервал

Тема 5. Методология построения графических интерфейсов.
12
Файл 147335735
С. 1 из
Тема 5. Методология построения графических интерфейсов
1. Суть проектирования взаимодействия. Целеориентированное проектирование
1.1. Проектирование для персонажей. Персонаж как обобщение класса пользователей
1.2. Проектирование ради результата
1.3. Сценарий как инструмент описания задач
2. Описание модели взаимодействия объектно-ориентированными средствами. RUP, целеориен
тированное проектирование и практичное проектирование
3. Основные положения современного подхода к разработке интерфейсов
3.1. Положения, базирующиеся на когнитивных характеристиках взаимодействия
3.2. Положения, связанные с эффективностью интерфейса
3.3. Положения, касающиеся размещения и компоновки элементов интерфейса
3.4. Положения, касающиеся базовых принципов проектирования
1. Принципы проектирования взаимодействия. Целеориентированное проектирование
Неоднократно отмечалась как общность взглядов ведущих разработчиков на проектирование ПО в
целом и проектирование взаимодействия как основную составляющую, так и различие в
используемой терминологии (здесь, возможно, сказывается и то, что большинство источников –
переводные). Поэтому за основу возьмем терминологию, используемую Аланом Купером, проведя
затем аналогию с терминами других авторов. Используемый метод Купер называет целеориентированным проектированием (Goal-Directed Design)1. Далее при упоминании метода будет использована аббревиатура его оригинального названия – GDD.
1.1. Проектирование для персонажей. Персонаж как обобщение класса пользователей
Основной принцип проектирования взаимодействия – максимально точное описание пользователя
продукта и его целей. Нетривиальные принципы создания такого описания представляют одну из
главных составляющих проектирования.
В процессе проектирования классы пользователей представлены персонажами.
Это –
гипотетические архетипы реальных пользователей. Основные характеристики персонажей
появляются в результате исследования характеристик и требований потенциальных
пользователей. Эти характеристики персонифицируются: к ним добавляются имена и личные
сведения, в результате чего персонажи определяются достаточно жестко и точно. Проектирование
ведется для конкретных персонажей, и такой подход оказывается эффективным во всех случаях 2.
Какие персонажи имеют отношение к делу и каковы их цели, определяется в процессе
исследования предметной области. Процесс уточнения набора персонажей и их характеристик
имеет итеративный характер – аналогично процессу разработки ПО. Фундаментальное отличие
состоит в следующем: циклическое совершенствование дизайна проекта проводится до
кодирования, на бумаге, и потому происходит достаточно быстро и легко (в отличие от
циклического совершенствования готового продукта, где необходима переделка кода).
 Принципы проектирования для персонажей
•• Проектируйте для одного персонажа
Предположение, что для удовлетворения как можно более широкой аудитории пользователей
необходимо возможно больше расширить функциональность продукта, логически ошибочно.
Попытка сочетать противоречивые требования различных подгрупп пользователей может
привести к появлению продукта, который не купит никто. Расширение функциональности, чтобы
охватить еще одного пользователя, означает введение искусственных ограничений и органов
управления для прочих пользователей. Купер прекрасно иллюстрирует это на примере проекта
автомобиля, который должен одновременно удовлетворять требованиям матери с малолетним
ребенком, плотника и младшего руководящего работника.
1
2
См. кн. Купера, гл. 9
Этот подход взят на вооружение и компанией Microsoft
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 2 из
12
«Если вы желаете достичь уровня удовлетворенности продуктом в 50%, это невозможно сделать,
осчастливив 50% широкой аудитории. Единственный способ достичь цели состоит в том, чтобы
выявить эти 50% и стремиться осчастливить их на 100%. ... проектирование для единственного
пользователя – самый эффективный способ удовлетворить широкую аудиторию».
Примеры:
- чемодан на колесиках; изначально задумывался для экипажей самолетов, т.е. для очень узкойаудитории пользователей;
- липкие закладки; были придуманы для решения сугубо личных задач их изобретателя.
•• Проектирование для некоего мифического пользователя, который будет приспосабливаться к
программам, – миф, дающий разработчику писать код удобным для него образом. Это программа
должна адаптироваться к потребностям пользователя. Реальные пользователи, в отличие от
мифических, «неэластичны».
Проектирование «для пользователя вообще» призвано оправдать навязывание собственных
интересов проетировщика.
•• Персонаж должен быть конкретным, вплоть до наличия имени и дополнения его изображением.
Детализация персонажа уменьшает его эластичность, по мере обретения конкретных черт он
становится в представлении разработчиков конкретным человеком. В таком случае в процессе
проектирования легче видеть мотивацию и цели персонажа и понять, действительно ли он
является архетипом пользователя.
Смысл этого принципа – подавление склонности разработчика искажать характеристики
пользователей.
•• Персонаж должен быть воображаемым.
Смысл принципа состоит в том, чтобы убрать из описания персонажа индивидуальные
характеристики, не характерные для целевой группы пользователей.
•• Описание персонажа должно быть подробным, а не идеальным
Персонаж должен быть характерным для группы, но точно, подробно и конкретно описанным.
Если есть сомнение в центральном расположении персонажа (в его типичности для группы), его
следует исключить из рассмотрения. Программирование определяется пограничными случаями
предметной области (вспомним анализ аномалий для обеспечения надежности); проектирование
ориентируется на центральные случаи.
Расширение описания персонажа размывает последний. То же касается усреднения. Средний
пользователь – это не математически средний. Так, например, у пользователя не может быть 2.3
ребенка; если число детей является характеристикой персонажа, то более полезен персонаж с
двумя или тремя детьми как личность, обладающая точными характеристиками.
Персонажи – основа GDD. Они позволяют видеть масштаб и природу проблемы проектирования,
точно понять и определить цели пользователя и таким образом определить, что должен делать
продукт и чего он может не делать.
Точно определенный персонаж также дает определенность относительно уровня владения пользователя компьютером и помогает разрушить некоторые ложные представления – например, разделение пользователей на «продвинутых», «компьютерно образованных» и «неподготовленных».
Так, первые в действительности чаще всего являются апологетами компьютера или отдельного
продукта (например, «линуксоиды»), ко второму классу могут быть отнесены люди, работа которых
связана с выполнением определенных, хотя и сложных последовательностей действий на
компьютере и которые могут даже не иметь представления о принципах работы компьютера. Для
разрушения классификации достаточно вспомнить конкретных людей из круга знакомых.
•• Персонажи закрывают споры о функциях
Для программистов пользователь предстает как некая обобщенная категория. На этом уровне
речь о некоторой функции продукта может вестись с тех позиций, что функцию надо реализовать,
потому что она «кому-то» понадобится. Парировать такое утверждение на этом же уровне
невозможно. Ситуация меняется, если в дело пускается конкретный персонаж. Тогда возражение
может выглядеть так: «Но мы проектируем для N, а не для кого-то, а N эта функция не нужна.
Таким образом, персонажи выступают в качестве инструмента общения и позволяют приходить к
взаимоприемлемым и однозначным решениям многих спорных вопросов.
Тема 5. Методология построения графических интерфейсов.
12
 Подбор персонажей
Файл 147335735
С. 3 из
Для каждого проекта формируется набор персонажей в количестве от трех до двенадцати.
Проектирование ведется не для каждого из них, хотя все персонажи так или иначе отображают
пользовательскую аудиторию. Некоторые создаются лишь для того, чтобы было ясно, для кого
проектирование не делается.
Персонажи с уникальными целями идентифицируются. При этом возможно, пересечение наборов
целей отдельных персонажей.
В каждом наборе персонажей есть хотя бы один ключевой персонаж. Это – личность, находящаяся
в фокусе процесса проектирования. Ключевой персонаж характеризуется тем, что для достижения
его целей ему необходим отдельный интерфейс.
Каждый ключевой персонаж требует отдельного уникального интерфейса 1.
Наличие более трех ключевых персонажей означает, что рассматриваемый набор проблем
предметной области слишком велик.
Итоговый набор персонажей, полученный в результате итерационного анализа их совокупности,
включает от трех до семи персонажей. Информация об этих персонажах – имена, изображения,
описания, должности, цели – фиксируется на бумаге, и этот жокумент становится неизменной
составляющей дальнейшего проектирования.
 В качестве примера отхода от традиционных решений и эффективности своего подхода Купер
описывает разработку интерфейса развлекательной системы P@ssport для гражданской авиации,
позволяющей
демонстрировать видео по запросу (независимо от других пассажиров).
Традиционный вариант системы хорошо ложился на внутреннюю структуру программы, т.е.
отображал реализацию. Однако оказывалось, что среднему пользователю понадобится несколько
десятков щелчков для выбора чего-то подходящего. Проведя анализ проблемы, фирма Купера
остановилась на группе персонажей, наиболее интересными из которых оказалась четверка
пассажиров с сильно различающимися требованиями к интерфейсу. Работа с этими персонажами
позволил выделить ключевой персонаж – такой, что удовлетворяющий его интерфейс
удовлетворял бы и остальных пассажиров. В итоге был разработан нетривиальный, удобный и
очень интересный из-за своей нетривиальности и практичности интерфейс 2. Другая группа
персонажей была представлена шестью членами экипажа, среди которых было выделено два
ключевых, для которых и были разработаны соответствующие интерфейсы.
1.2. Проектирование ради результата
Персонажи неотделимы от целей. Цели придают смысл персонажу.
Пользователь стремится достичь целей бизнеса, но лишь после того, как достигнет целей личных.
Самая важная личная цель – сохранить достоинство.
Сущность качественного проектирования взаимодействия заключается в разработке таких
взаимодействий, которые помогут пользователю достичь практических целей, не препятствуя достижению личных целей.
 Соотношение целей и задач: задачи не являются целями
Цель – конечное состояние, задача – переходный процесс, необходимый для достижения цели.
Задачи меняются вместе с технологией, тогда как цели очень стабильны 3. Поэтому проектирование под задачи не всегда уместно, а проектирование под цели уместно всегда.
 Виды целей
Купер выделяет четыре вида целей:
- личные;
- корпоративные;
- практические;
- ложные.
Кого можно считать ключевым персонажем в задании к лаб. работе № 4? Почему? Предлагаемый вами
вариант единственный или возможен иной подход к решению? Если да, то чем объясняется неоднозначность подхода? О чем она свидетельствует?
2
См. кн. Купера. Пример: Sony Trans Com и P@ssport. С 196.
3
Примеры: путешествие из одного пункта в другой в различные эпохи: ведение войны ради мира; еще?
1
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 4 из
12
Вероятно, с позиций философии предлагамые положения подлежат критике; однако в данном
случае гораздо важнее, что вопрос реального проектирования взаимодействия едва ли может
быть решен средствами философии, тогда как автор положений добивается в своей области
практических результатов. Приведем эти положения в сокращенном виде и без обсуждения.
Важность их состоит в установлении иерархии и взаимодействия целей при проектировании
взаимодействия.
•• Личные цели:
- не чувствовать себя глупо;
- не совершать ошибок;
- выполнить адекватный объем работы;
- развлечься (или не страдать от скуки).
Любая система, идущая вразрез с личными целями, в конечном итоге обречена на неудачу,
независимо от того, насколько качественно позволяет достигать целей иного рода.
•• Корпоративные цели:
- увеличить прибыль;
- увеличить рыночную долю;
- победить конкурентов;
- нанять больше сотрудников;
- предложить новые продукты и услуги;
- выпустить акции компании в свободное обращение.
•• Практические цели:
- избегать собраний;
- удовлетворять требованиям клиента;
- сохранять информацию о заказах клиента;
- создавать математические модели бизнеса.
Корпоративные и практически цели – цели, необходимые для эффективной работы, но сами по
себе не мотивирующие. Работу выполняет не корпорация, а люди, а для людей важнее цели
личные.
Если пользователь не может достичь личных целей, то он не способен эффективно достигать
целей компании. Непреложный факт: счастливые и довольные сотрудники наиболее эффективны.
С другой стороны, если программа игнорирует практические цели и служит только целям
пользователя, это означает, что вы спроектировали компьютерную игру.
•• Ложные цели:
- экономия памяти;
- уменьшение потребности в клавиатурном вводе;
- поддержка работы в броузере;
- простота в освоении;
- обеспечение целостности данных;
- ускорение ввода данных;
- увеличение скорости исполнения программы;
- применение супертехнологии или супервозможностей;
- улучшение внешнего вида;
- сохранение единообразия интерфейса на различных платформах.
Ложные цели – это подмена целей задачами и средствами. Пользователю безразлично, как решаются его задачи, ему важно удовлетворяющее его выполнение работы.
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 5 из
12
 Эксперименты показывают1, что люди реагируют на компьютеры так же, как на других людей. Как
следствие, к любой достаточно развитой информационной среде предъявляются такие же требования, как и другому человеку. Эта реакция бессознательна и неизбежна, она присуща каждому
человеку, даже если он отрицает ее наличие. Это надо учитывать при проектировании.
 Проектирование и вежливость
Если мы хотим, чтобы пользователю понравилась программа, то должны проектировать ее
поведение таким образом, чтобы оно напоминало поведение симпатичного нам человека. Если мы
хотим, чтобы пользователи эффективно работали с продуктом, то должны спроектировать его так,
чтобы он вел себя подобно хорошему сотруднику.
Программы должны быть "вежливыми", поскольку это повсеместно распространенная
поведенческая особенность человека. Если программа скупа на информацию, затрудняет
понимание происходящего, заставляет пользователя долго искать самые востребованные
функции и сваливает на пользователя вину за собственные недостатки, пользователю эта
программа не понравится, а опыт работы с ней будет неприятным. Если взаимодействие
проникнуто уважением, благородством, содержит полезную информацию, то пользователю
программа понравится и работать с ней ему будет приятно. И этот результат не зависит от типа
интерфейса: интерфейс командной строки на зеленом фоне будет принят пользователями, если
сможет реализовать перечисленные свойства.
Вот список элементов вежливости программы, повышающих качество взаимодействия.
Вежливая программа интересуется мной.
Вежливая программа относится ко мне уважительно.
Вежливая программа обходительна.
Вежливая программа ведет себя разумно.
Вежливая программа предвидит мои потребности.
Вежливая программа отзывчива.
Вежливая программа не склонна делиться своими личными проблемами.
Вежливая программа в курсе происходящего.
Вежливая программа проницательна.
Вежливая программа уверена в себе.
Вежливая программа всегда сосредоточенна.
Вежливая программа покладиста.
Вежливая программа дает мгновенное удовлетворение
Вежливой программе можно доверять.
1.3. Сценарий как инструмент описания задач
Если у нас есть персонажи и мы представляем себе их цели, мы можем начать изучение задач.
Инструментом для такого изучения являются сценарии – сжатое описание способов применения
программного продукта персонажем для достижения цели.
Эффективность сценария определяется в большей степени его охватом, чем глубиной. Иначе
говоря, важнее, чтобы сценарий описывал процесс от начала до конца, чем чтобы он описывал
каждый шаг в исчерпывающих подробностях.
Рассматривается три вида сценариев – повседневные, обязательные и сценарии исключительных
ситуаций – и требования к их поддержке.
 Повседневные сценарии – самые полезные и важные. Они описывают основные действия,
которые пользователь выполняет чаще всего.
В общем случае для большинства пользователей репертуар повседневных сценариев
оказывается весьма ограниченным. Чаще это один или два сценария. И редко их бывает больше
трех.
1
Купер, с. 219
Тема 5. Методология построения графических интерфейсов.
12
Файл 147335735
С. 6 из
Требования к поддержке таких сценариев:
- поддержка быстрого обучения;
- наличие ускоренных методов работы;
- адаптация к индивидуальному стилю работы.

Обязательные
неукоснительно.
сценарии
описывают
все
действия,
выполняемые
и
нечасто,
но
Обязательное взаимодействие также требует поддержки механизма обучения. Однако редкое
применение означает, что любой пользователь согласится с механизмами, предложенными
программой, поэтому индивидуализация не потребуется.
В большинстве продуктов репертуар обязательных сценариев достаточно ограниченный, но
количество последних обычно превышает количество сценариев повседневных.
 Сценарии исключительных ситуаций. Программисты обращают особое внимание именно на
них, но в процессе проектирования продукта эти сценарии можно игнорировать. Это означает, что
взаимодействие для таких сценариев можно проектировать грубо и упрятывать в глубины
интерфейса. Работоспособность кода может зависеть от того, обрабатываются ли
исключительные ситуации, а успех продукта зависит от способности справляться со случаями,
описанными в сценариях повседневных и обязательных.
 Резюме. Если пользователь решает некую задачу часто, то взаимодействие в данном месте
программы должно быть продумано до мелочей. Точно так же, если задача выполняется редко, но
в любом случае, то взаимодействия для этой задачи, пусть и преследующее иные цели, должно
быть спроектировано качественно. Задачи, не являющиеся обязательными или повседневными,
просто не требуют тщательного проектирования. Мы должны создать все сценарии, но тщательно
проектировать интерфейс следует лишь для сценариев важных или применяемых постоянно.
2. Описание модели взаимодействия объектно-ориентированными средствами.
RUP, GDD и практичное проектирование
Рассмотрим теперь, как соотносится целеориентированное проектирование взаимодействия по
Куперу с методологией RUP, позиционирующейся как наиболее перспективная методология разработки ПО.
 Напоминание. Методология объектно-ориентированного анализа и проектирования
(ООАП) адекватна широкому классу задач, связанных с конкретными предметными областями.
Однако при этом принципиально речь идет о достаточно масштабных проектах и сложных (т.е. обладающих большим количеством объектов со сложными взаимосвязями и не поддающихся формализации) предметных областях.
Под предметной, или проблемной областью понимается часть реального мира, которая имеет
непосредственное отношение к процессу функционирования создаваемой программы, т.е. те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения задачи. Главное отличие разработки программных проектов в сложных предметных областях
заключается в необходимости предварительной разработки концептуальной схемы, или модели,
отображающей общие взаимосвязи ее объектов и особенности организации соответствующей информации.
Разработка концептуальной схемы предметной области с использованием объектноориентированного подхода и последующая реализация этой схемы в проекте и составляют суть
ООАП.
Одной из реализаций ООАП является Rational Unified Process (RUP) от Rational Software Corporation. Концепция RUP разработана в ходе работы над языком UML; таким образом, это концепция
процесса ООАП, осуществляемого в рамках языка UML, а RUP и UML здесь тесно взаимосвязаны.
Поэтому изучение UML по сути дела равноценно практическому освоению методологии ООАП.
Язык UML ориентирован на применение в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач ООАП. Различные виды
диаграмм, поддерживаемые UML, и богатейший набор возможностей представления определенных аспектов системы делает UML универсальным средством описания как программных, так и
деловых систем.
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 7 из
12
UML может быть применен на всех этапах жизненного цикла ПО, однако основное его назначение
– поддержка первых двух этапов.
 Сотношение RUP (UML) и GDD
С позиций проектирования взаимодействия предметная область являет собой способ структуризации реального мира, или построения упомянутой концептуальной модели, в соответствии с целями того, для кого решается задача – пользователя. Именно на это – на создание описания
предметной области согласно целям пользователя – и направлено целеориентированное проектирование. Это – основная проблема на начальных этапах проектирования1. Важно отметить следующее:
- эта проблема не имеет и не может иметь теоретического решения;
- методологии, направленные на разработку ПО в целом (например, RUP), предоставляют некоторые рекомендации и язык для описания проектирования, но в силу широкой ориентированности отображают этап проектирования в значительной степени с позиций реализации;
- предлагаемая Купером методология, во-первых, дает адекватные, средства описания взаимодействия, во вторых, представляет собой работающий инструмент, и, в-третьих, прекрасно согласуется с подходами, представляющимися на данный момент наиболее перспективными2.
Таким образом, по отношению к RUP GDD можно рассматривать как методику реализации начальных этапов RUP. Уровень моделей UML, соответствующих GDD, – концептуальный, соответствующий класс диаграмм описания – диаграммы вариантов использования (use case diagram).
На рис. 5.1.приведено примерное соответствие терминов в RUP (UML) и GDD.
GDD
Персонаж
(Persona)
UML
Актер
(Actor)
Цель
Сценарий (сжатое описание
способов применения
программного продукта
персонажем для достижения цели)
Сценарий (содержание варианта
использования)
Вариант использования –
описание некоторого
аспекта поведения
проектируемой системы
Рис. 5.1. Примерное соответствие терминов в RUP (UML) и GDD
Соответствие приблизительное, так как в UML понятие цели непосредственно не отображается, а
выражено через вариант использования. Кроме того, сценариям отводится разная роль: если в
UML сценарий является дополнением к модели, то в GDD он рассматривается как основной элемент и по определению очень схож с вариантом использования.
 Приведем также взгляд на проектирование взаимодействия с позиций практичного проектирования по Константайну.
Здесь используются понятия пользовательских ролей, сценариев и вариантов использования.
Пользовательская роль – абстрактный набор потребностей, интересов, ожиданий, предполагаемого поведения и обязательств, характеризующий взаимоотношения между некоторым классом или
видом пользователей и системой3. Очевидно, это аналог персонажа в GDD.
Сценарий, в отличие от GDD, более свободен; это скорее повествовательный рассказ о совершаемых действиях, реалистичный и детальный. Поэтому авторы считают, что сценарии недостаточны для выделения и понимания основной сути взаимодействия.
Эти вопросы рассматривались в теме 5 курса проектирования ПО
См. источники по RUP и UML, кн. Раскина, Константайна, Головача, а также кн. Нильсена, Кирсанова,
Круга и др. и Интернет-источники
3
Константайн, с. 101
1
2
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 8 из
12
Модели Use Case расцениваются как «близкий родственник сценариев». Отмечается, что эти модели в своем исходном виде слишком сильно опираются на реализацию и в недостаточной мере
заботятся о проблемах, выявленных пользователем». предлагается модификация моделей, суть
которой состоит в смещении с действий пользователя на его цели, т.е. обобщении модели, и симбиозе изобразительных средств UML и сценариев. Новые формы модели именуются сущностными элементами Use Case. «Сущностный элемент Use Case – это структурированное повествование, выраженное на языке данной прикладной области и пользователей системы и содержащее
упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной
завершенной, наполненной смыслом и хорошо определенной с точки зрения пользователей задачи или взаимодействия. Предполагается, что пользователь играет определенную роль по отношению к системе, а в описании воплощаются цели и замыслы лежащего в его основе взаимодействия»1.
 Вывод. Симптоматично и отрадно, что все приведенные (а также множество не приведенных)
точки зрения не противоречат друг другу, а рассматривают проектирование взаимодействия под
разными углами, но в едином направлении. Поскольку эти позиции выражаются лидерами в разработке ПО, можно именно их (позиции) расценивать как ведущие.
Все приведенные положения дополняют друг друга и в идеале могли бы быть интегрированы в
единую концепцию.
3. Основные положения современного подхода к разработке интерфейсов
Выводы из этих положений могут быть сформулированы как принципы или правила, хотя точно
разделить принципы и правила едва ли возможно. Правомерно отнести к принципам утверждения
общего характера о необходимых свойствах интерфейса, а к правилам – указания о том, как следует (или не следует) строить интерфейс. В части положений такие принципы или правила сформулированы явно; там, где это не сделано, можно внести коррективы.
Здесь предлагается ряд положений, непосредственно присутствующих в материале курса. В разных источниках формулировки и число таких положений различно, однако сущность примерно одна. Можно утверждать, что нижеприведенный текст по меньшей мере включает основные из них.
3.1. Положения, базирующиеся на когнитивных характеристиках взаимодействия
 Всем продуктам, основанным на программном обеспечении, присуще когнитивное сопротивление, т.е. трудности в освоении и использовании компьютерных продуктов, причиной которых является несоответствие их интерфейса когнитивным характеристикам человека. Единственный способ разработки компьютерных продуктов с низким уровнем когнитивного сопротивления – это проектирование взаимодействия с ними, исходя из целей пользователей и на базе экспериментально
и теоретически обоснованных принципов.
 Результат восприятия информации определяется знаниями и опытом прошлого и формируется
как интерпретация новой информации в контексте имеющихся знаний.
Сенсорная система работает постоянно, но получаемая информация обрабатывается автоматически, без участия сознания.
 У человека есть по крайней мере две формы знания – «когнитивное сознательное» и «когнитивное бессознательное». Переход бессознательного в сознательное напрямую связан с процессом
переключения внимания. Объект, на котором сосредоточено наше внимание, становится локусом
внимания.
 Формирование привычек заключается в том, что повторяющиеся действия перестают быть локусом внимания. Этот процесс неизбежен и является неотъемлемой частью нашего ментального
аппарата.
Интерфейс должен способствовать формированию полезных привычек.
 Следствием формирования привычек является отсутствие идеального способа подтверждения
операции. Единственный способ избежать ошибок автоматического подтверждения по привычной
схеме — это предусмотреть в интерфейсе неизбежность формирования привычек:
- дать пользователю возможность отменить ошибочную команду;
- если по тем или иным причинам какое-то действие никогда не должно выполняться, следует
предотвратить саму возможность действий, которые никогда не должны выполняться;
1
Константайн, с. 126
Тема 5. Методология построения графических интерфейсов.
Файл 147335735
С. 9 из
12
- устранить сообщения, которые не требуют ответа от пользователя, либо отображать их так,
чтобы можно было продолжать работу.
 Локус внимания может быть только один.
Интерфейс должен оставлять в качестве локуса внимания пользователя решаемую задачу, а
не анализ возможных комбинаций элементов, предлагаемых интерфейсом.
Следствия сингулярности локуса внимания:
- отрицательное: чем более критической является задача, тем меньше вероятность того, что
пользователь заметит предупреждения относительно тех или иных потенциально опасных
действий; выход – возможность отмены результатов любого действия;
- положительное: можно производить изменения в частях системы, не являющихся локусом
внимания (создание эффекта мгновенного восстановления состояния компьютера при продолжении работы после его выключения и последующего включения, сокрытие разного рода
запаздываний с помощью эффектов, сопутствующих ходу процесса).
 Образы непосредственного восприятия хранятся в перцептивной памяти в течение небольшого
периода времени.
Если сообщение содержит важную информацию, оно должно оставаться на экране до тех пор,
пока сохраняет актуальность, либо пользователю должна быть предоставлена возможность
немедленно обработать эту информацию, прежде чем она исчезнет из его памяти.
 Информация, ставшая локусом внимания, перемещается в кратковременную память, где будет
храниться в течение 10 секунд. Кратковременная память ограничена по объему и способна вместить 7  2 несвязанных между собой элементов. Увеличить объем кратковременной памяти можно, организуя элементы в группы согласно логике их связи. Тогда речь будет идти о сохранении в
памяти 7  2 групп элементов.
Интерфейс должен по возможности снижать нагрузку на кратковременную память, поскольку
запоминание информации, ее извлечение и удержание в памяти при поступлении новых стимулов требует усилий.
Снижение нагрузки достигается, если информация и получается, и используется в одном месте.
 Из кратковременной информация попадает в долговременную память:
- при повторении, т.е. при необходимости частого использования системы;
- при глубокой семантической обработке (соотнесении новой информации с уже хранящейся в
памяти, включении ее в уже имеющиеся смысловые структуры).
Объем этой памяти очень велик, время хранения не ограничено, структура сложна, а извлечение
информации вызывает затруднения.
Интерфейс должен оказывать помощь при обращении к долговременной памяти.
Стратегиями и для получения информации из памяти, и для ее сохранения являются мнемоника – приписывание смысловых значений к запоминаемой информации и разбиение информации
на группы.
Для извлечения информации существует два основных метода: восстановление в памяти и
распознавание (выбор из предлагаемого набора).
Выбрать правильный вариант из списка всегда проще, чем воспроизвести его по памяти. Это
– способ снижения нагрузки на память пользователя.
 Совершение пользователем ошибок неизбежно. Хорошо спроектированная система должна препятствовать совершению ошибок и помогать работать без них.
Средства борьбы с ошибками:
- плавное обучение пользователей в процессе работы;
- снижение требований к бдительности;
- повышение разборчивости и заметности индикаторов;
- снижение чувствительности системы к ошибкам.
Тема 5. Методология построения графических интерфейсов.
из 12
3.2. Положения, связанные с эффективностью интерфейса
Файл 147335735
С. 10
 Скорость работы интерфейса может быть оценена по модели GOMS. Применение модели
наиболее эффективно и целесообразно при сравнении различных вариантов интерфейсов для
решения некоторой задачи.
 С точки зрения эффективности в целом:
- модель «объект – действие» предпочтительнее модели «действие – объект»;
- интерфейс должен быть немодальным, т.е. не предполагать режимов;
- интерфейс должен быть монотонным;
- интерфейс должен быть состоятельным.
 Оценки информационной производительности интерфейса приводят к следующим выводам:
- информационная производительность элементов, не предполагающих выбора, равна нулю
(к решению задачи вводимая информация, например, нажатие кнопки, не относится);
- чем более производительным в информационном плане является интерфейс, тем более
продуктивным и более человекоориентированным он является.
3.3. Положения, касающиеся размещения и компоновки элементов интерфейса
 Чем дальше находится объект от текущей позиции курсора или чем меньше размеры этого объекта, тем больше времени требуется для перемещения к нему курсора (закон Фитса).
Отсюда две стратегии оптимизации:
- размещать объекты ближе друг к другу;
- делать далекие объекты больше.
 Предоставление пользователю нескольких вариантов выбора одновременно является более
эффективным, чем организация этих же вариантов в иерархические группы (закон Хика). Например, время выбора из одного меню, включающего 8 пунктов, меньше времени выбора из двух меню, состоящих из 4 элементов каждое (пункты меню одни и те же).
3.4. Положения, касающиеся базовых принципов проектирования
 Проектировать для персонажей.
 Проектировать ради результата, т.е. ориентироваться на цели.
Сущность качественного проектирования взаимодействия заключается в разработке таких
взаимодействий, которые помогут пользователю достичь практических целей, не препятствуя достижению личных целей.
 Использовать сценарии как инструмент описания задач, решение которых ведет к реализации
целей.
 Учитывать при проектировании, что люди реагируют на компьютеры так же, как на других людей.
Программы должны быть "вежливыми".
 Для описания модели взаимодействия могут быть использованы средства ООАП, в частности,
методология RUP, позиционирующейся как наиболее перспективная методология разработки ПО,
и средства концептуального уровня языка UML (концептуальные модели и диаграммы вариантов
использования – use case diagram).
Безусловно, многие из приведенных положений взаимосвязаны, а некоторые не слишком согласуются между собой, вплоть до противоречий. Тем не менее можно утверждать, что мы имеем достаточно хорошо сформулированную и работающую систему положений, характеристик и оценок.
Эта система конкретизирует общие, неформальные критерии качества, описанные в теме 2, и позволяет определить, что именно следует закладывать в интерфейс.
Тема 5. Методология построения графических интерфейсов.
из 12
Файл 147335735
С. 11
Верхний колонтитул
Заголовок1. Arial 12, полужирный, по центру, интервал одинарный, перед: 6
пт, после: 6 пт
Заголовок2. Arial 12, полужирный, курсив, по центру, интервал одинарный,
перед: 6 пт, после: 6 пт
Заголовок 3. Arial 11, полужирный, курсив, интервал одинарный, перед: 6 пт, после: 3 пт
Подзаголовок 1. Основной текст, полужирный. Так выглядит текст, отформатированный в
этом стиле.
Обычный – Arial 10, влево, интервал одинарный. Так выглядит текст, отформатированный в этом
стиле.
Обычный по центру
Основной текст - Обычный, по ширине, интервал после: 6 пт.
Так выглядит текст, отформатированный в этом стиле. Так выглядит текст, отформатированный в
этом стиле.
Основной текст-заголовок - Основной текст + интервал перед: 6 пт.
Основной текст с отступом - Обычный №1 + отступ: первая строка 0.67, по ширине, интервал
после: 6 пт.
Так выглядит текст, отформатированный в этом стиле. Так выглядит текст, отформатированный
в этом стиле.
 Маркиров. список1
 Так выглядит текст, отформатированный в этом стиле отформатированный в этом стиле отформатированный в этом стиле
 отформатированный в этом стиле.
- Маркиров. список2
 Маркиров. список 3
 Так выглядит текст, отформатированный в этом стиле отформатированный в этом стиле
отформатированный в этом стиле
- Так выглядит текст, отформатированный в этом стиле отформатированный в этом стиле отформатированный в этом стиле
- отформатированный в этом стиле.
1. Нумеров. Список №1.
2. Так выглядит текст, отформатированный в этом стиле отформатированный в этом стиле отформатированный в этом стиле отформатированный в этом стиле.
3. Так выглядит текст, отформатированный в этом стиле.
Курсив-выдел. Так выглядит текст, отформатированный в этом стиле.
Курсив-жирный . Так выглядит текст, отформатированный в этом стиле.
Полужирный
Заголовок таблицы
Подпись под рисунком
Тексты выносок: обычный
Тексты выносок по центру
Алгоритм, 1-я строка: обычный + интервал перед 6
Алгоритм
Алгоритм
Тема 5. Методология построения графических интерфейсов.
из 12
Алгоритм
Алгоритм, последняя строка: обычный + интервал после 6
Формула: p=(np/n)*100 (1)
Файл 147335735
С. 12