Проектирование ПО
Проектирование, ориентированное на удобство использования, - это, с одной стороны, очень обтекаемый, с другой стороны, систематический подход, В результате его применения должны получаться программы, соответствующие реальным запросам пользователей. Такие программы не только удобнее в использовании, но и проще в разработке. Проектирование, ориентированное на удобство использования, приспособлено под непростые реалии, с которыми приходится сталкиваться сегодня разработчикам ПО.
Творчество при проектировании ПО
Мы считаем, что творческий зуд - это жизненно необходимая сила при проектировании, но в качестве платформы рассматриваем звуковое инженерное искусство. Многие специалисты, работающие над пользовательскими интерфейсами, склонны рассматривать их как своего рода театр. Дизайн рассматривается ими как плод художественного вдохновения, которому приходится бороться с систематической природой проектирования, ориентированного на удобство использования. Тем не менее энтузиазм, вложенный в наш подход, привлекает дизайнеров и художников, которых сильно вдохновляют абстрактные модели.
Homo Habilis - Человек умелый
Люди - это существа, пользующиеся инструментами, не так ли? С помощью инструментов мы расширяем свою власть над природой, можем заглянуть за горизонт и в подземелья, можем созидать и разрушать. Инструменты помогают нам перемещать в пространстве вещи и самих себя, создавать вещи и даже другие инструменты. Все программные системы - это инструменты, а их разработчики, таким образом, являются изготовителями инструментов.
Элементы практичного подхода
Подход к практичному проектированию, описанный в этой книге, является результатом длительных усовершенствований и переделок, нашего собственного опыта и опыта многих наших студентов и клиентов. Он базируется на действенных приемах, наиболее целостно и стабильно обеспечивающих наилучшие результаты труда разработчиков, работающих над реальными проблемами.
Модели и моделирование
Благодаря тому что в центре внимания практичного подхода находится выполняемая пользователями работа и ее цели, он постепенно стал базироваться на моделях. Применяя модели, разработчики могут лучше понять свои задачи, а также выразить свое понимание в подходящем для общения с заказчиками и программистами виде.
Вернемся к сущности
Сущностные модели, будучи особенно эффективной формой абстракции, составляют основу практичного проектирования. Корни сущностного моделирования уходят по меньшей мере к структурному проектированию , в котором диаграммы потоков применяются для определения и описания требований к приложению, отдельно от структур данных и алгоритмов, отвечающих этим требованиям на практике.
Плюрализм взглядов
Согласитесь, мы вряд ли сможем построить дом, основываясь только лишь на набросках, показывающих вид с улицы. Точно так же не следует полагать, что нам удастся создать хороший пользовательский интерфейс на основе какого-то однобокого представления о нем. Если мы строим дом, нам понадобится множество видов под разными углами зрения, а также специализированные чертежи каждой) этажа с указанием размещения электропроводки и санузлов.
Обобщение и упрощение
Абстрактные модели, с которыми приходится иметь дело при практичном подходе к проектированию, способствуют развитию тенденции к упрощению и помогают разработчику мыслить более обобщенными понятиями. Упрощение и обобщение - это те виды деятельности, которые имеют смысл даже сами по себе.
Правило второе: эффективность
Система не должна никоим образом препятствовать эффективной работе опытных пользователей, долгое время работающих с ней. Правило эффективности сформулировано с помощью частицы "не, потому что при работе с реальными интерфейсами приходится сталкиваться с проблемой, которую можно сформулировать только так.
Правило четвертое: поддержка
Система должна способствовать более простому, быстрому или увлекательному решению задач, стоящих перед пользователями, предоставлять новые возможности.
Правило пятое: контекст
Система должна удовлетворять существующим реалиям и текущей среде эксплуатационного контекста, внутри которого она будет разворачиваться и применяться. Правило контекста обращает наше внимание на то, что даже самые лучшие побуждения проектировщика не будут адекватными, если он не учитывает, где и в каких условиях будет реально работать его система.
Настоящие пользователи и другие
Те, кого нам нужно понять, с кем нужно наладить контакт, - это настоящие пользователи ПО, то есть конечные потребители, которые и будут осуществлять реальное взаимодействие с программой.
Заместители пользователя
Заместителями пользователей являются люди, не использующие реально систему, однако способные при решении каких-то вопросов заменить пользователей. Если у разработчика нет возможности переговорить с конечным пользователем, то лучше уж поговорить с его заместителем, чем пытаться создать что-либо из ничего, не советуясь вообще ни с кем.
Информанты и истолкователи
Многие люди и группы всегда готовы рассказать разработчикам о нуждах пользователей или истолковать их при отсутствии пользователя или его неспособности вразумительно объяснить суть дела. Среди информантов и истолкователей чаще всего встречаются служащие маркетинговых отделов и отделов продаж, управляющие и технические служащие.
Косвенные источники
Направлять процесс проектирования путем предоставления информации могут не только люди. Как археологи могут узнать многое о культуре народа по руинам городов и остаткам деревень, так и внимательный разработчик может использовать в качестве источника информации артефакты современного бизнеса.
Понимание и сопереживание
Многие разработчики искренне пытаются представить себе нужды пользователей, однако этим не следует увлекаться сверх меры и пытаться учесть идеальные требования. В условиях отсутствии по тем или иным причинам настоящих пользователей разработчики могут пытаться делать какие-то умозаключении самостоятельно, опираясь на информацию, которую они могли бы получить напрямую от первоисточника.
Модели пользовательских ролей
Не вызывает никаких сомнений то, что на каком-то этапе разработки, причем лучше раньше, чем позже, представителю команды разработчиков необходимо встретиться с одним или несколькими реальными пользователями системы. Дело, конечно, не только в самих переговорах.
Актеры и роли
Концепция ролей пользователей в том виде, в каком она используется в этой книге, в значительной степени совпадает с тем, что обозначается как "актер" (actor) в объектно-ориентированной программной инженерии (Jacobson и др., 1992). Но нельзя не отметить одно важное отличие: актером в его исходном значении могла быть любая другая неодушевленная программная или аппаратная система, взаимодействующая с данной системой.
Моделирование ролей
В простейшем виде модель ролей (или модель пользовательских ролей) - это просто список ролей, которые должна поддерживать система. Каждую роль можно описать совокупностью требований, интересов, ожидании, поведения и обязательств, характеризующей и отличающей ее от других ролей. Каждой пользовательской роли дается имя, фиксирующее основную природу роли и представляющее собой обычно два или три слова, сцепленных в одно.
Построение пользовательских ролей
Проектирование, ориентированное на удобство использования, строится на моделях, направляющим весь процесс, среди которых модели пользовательских ролей и модели задач. Во многих аспектах построение моделей является искусством, однако оттачивать искусство лучше всего, когда есть понимание творческого процесса.
Центральные роли
Центральные пользовательские роли занимают особое место при формировании пользовательского интерфейса. В самом деле, можно выделить некоторые роли, которые являются наиболее существенными в процессе проектирования пользовательского интерфейса. Некоторые из них встречаются повсеместно, некоторые следует иметь в виду, даже если они специфичны и редко встречаются среди реальных пользователей.
Карты пользовательских ролей
Модели пользовательских ролей, организованные в виде обычных списков, просты в разработке, однако они не учитывают многие важные аспекты ролей, играемых пользователями. К большим системам может предъявляться требование поддержки пользователей, и грающих любое количество ролей, некоторые из которых могут быть похожи или связаны между собой. Простой список ролей и характеристик не может учесть эти связи.
Классификация
В некоторых случаях пользовательская роль может быть подтипом другой, более общей роли и представлять собой ее более узко специализированную версию. В процессе разработки модели ролей для приложения, предназначенного для управления розничной торговлей, мы можем выделить роли Постоянного Продавца и Временного Продавца. Это два частных случая одной и той же темы - темы продавцов.
Структурированные модели пользовательских ролей
До сих мы рассматривали в качестве моделей пользовательских ролей некие беспорядочные наборы поименованных ролей, сопровождаемых неформальными описаниями наиболее выдающихся и важных характеристик. Такое отсутствие формализации, конечно" ускоряет процесс моделирования и неплохо подходит для небольших проектов, рассчитанных на относительно короткий период, или для проектов, создаваемых с помощью хорошо налаженных процедур.
Работа с системой пользователей
Взаимодействия. Профиль ролевых взаимодействий содержит разнообразную информацию о типичных или ожидаемых паттернах использования системы пользователями, играющими эту роль. Здесь можно найти данные, например, о том, как часто и с какой периодичностью происходит взаимодействие.
Создание структуры
Построение структурированной модели пользовательских ролей очень похоже на построение неформальной модели, только связано с более значительными масштабами. Главным источником информации являются сами конечные пользователи, эксперты в данной проблемной области, а также (в меньшей степени) клиенты и управляющие конечных пользователей.
Работа, работа и еще раз работа
Работа пленяет. За тем, как работают другие, можно наблюдать без устали часами. Это, несомненно, один из способов постижения задач, решаемых людьми, и способов их программной поддержки. Чтобы создать хороший инструмент, нужно понимать, что люди делают и что они пытаются сделать.
Моделирование задач
Есть много способов моделирования действий. Самыми традиционными способами описания задач являются различные модели, которые должны быть знакомы разработчикам программного обеспечения. Одним из популярных подходов является создание своеобразных блок-схем, описывающих процессы в виде логических последовательностей событий или процессов. Даже большие, сложные задачи можно описать, разбив их на ряд мелких, последовательных шагов. Эта идея лежит в основе всех компьютерных программ, всего программирования вообще.
От сценариев к моделям use case
Сценарий - это еще один способ описания структуры задачи. Это повествовательный рассказ о совершаемых действиях, это история, эпизод, происходящий в данных временных рамках и в данном контексте. Различные формы сценариев широко применяются при разработке программного обеспечения [Carroll, 1995).
Сущностные элементы use case
Некоторые разработчики и специалисты по методологии предпринимали попытки использовать элементы use case в их исходном виде, в качестве вспомогательного средства при разработке пользовательского интерфейса [Biiow, 1995; Graham, 1994; McDaniel, Obun и Olson, 1994, Whitehead, 1995J, и делали это с большим энтузиазмом и с переменным успехом. Наши ранние работы и эксперименты выявили ряд больших проблем и ограничений, связанных с использованием элементов use case для этих целей.
Уровни абстракции и обобщения
Как обычные, так и сущностные элементы use case тесно связаны со сценариями. Хотя некоторые авторы определяют понятие сценария настолько широко, что под него подходит практически любая деятельность, связанная с повествованием [Carroll, 1995:20-21], а некоторые даже используют это слово как синоним use case [Booch, 1994; Firesmith, 1994; Wirfc-Brock, 1993], мы полагаем, что следует обращать внимание на различие между этими понятиями.
Карты элементов use case
Элементы use case не существуют отдельно от внешнего мира Полноценная программная система должна обеспечивать поддержку десятков, а то и сотен элементов use case, причем внутри каким-то образом связанного с ней приложений должна существовать связь между этими элементами. Отображение взаимосвязи между приложениями дает нам возможность описать общую структуру задачи, решаемой приложением и его интерфейсом.
Расширение
Одной из инноваций в объектно-ориентированной программной инженерии, навеянных идеями Якобсона, стало признание расширения одним из возможных отношений между элементами use case. Говорят, что один элемент "расширяет" другой, когда он содержит вставляемые или альтернативные паттерны взаимодействия, которые войдут в расширяемый элемент.
Намерение пользователя
Отношение композиции напоминает одновременно отношения специализации и расширения. Они действительно похожи, хотя есть и существенные отличия. В отношениях соединения описание суперэлемента use case, показанного в декомпозированном виде, относится к тем под элементам, от которых он зависит.
Центральные элементы use case
Прежде чем считать процесс создания сущностной модели use case завершенным, следует определить один или несколько центральных элементов use case. Центральные элементы use case так называются потому, что именно они находятся в центре внимания при организации всего пользовательского интерфейса или его части. Центральные элементы use case для всей системы вбирают в себя все самые важные, представительные, одним словом, центральные варианты использования.
Пользователи и элементы use case
В зависимости от ваших предпочтений и от модели жизненного цикла разработки ПО, применяемой в той организации, где вы работаете, процесс создания модели задач, как и ролевой модели, будет в большей или в меньшей степени включать в себя взаимодействие с пользователями. Некоторые группы программистов считают весьма производительным подход, при котором представители пользователей участвуют в мозговом штурме или даже в создании описаний элементов use case.
Создание описаний элементов use case
Процесс создания описания элемента use case начинается с выяснения основного предназначения этого элемента или пользовательских намерений, воплощенных в данном взаимодействии. Итак, чем же занимаются пользователи? Чего они пытаются добиться, отрабатывая тот или иной вариант использования? Зачем они этого добиваются? После определения основного предназначения элемента use case ему присваивается простое имя, служащее намеком на связанную с ним целесообразную, осмысленную деятельность.
Возвращение назад
В любом случае, одним из важнейших этапов, возможно, самым важны м во всем процессе практичного проектирования, является возвращение назад и внимательное изучение того, что уже сделано. Может быть, стоит попытаться еще больше упростить и обобщить написанное. Этот шаг необходимо повторять снова и снова, только тогда удастся создать более дешевую и удачную систему. То, что разработчик делает при создании сущностных описаний, задает некий нижний предел простоты и компактности будущего интерфейса.
Вывод соответствующего символа
Мы уже начинаем подозревать, что существует потенциальная возможность поддержки нескольких элементов use case одним пользовательским интерфейсом, но не будем пока отвлекаться на размышления о прототипе этого интерфейса. Мы еще не детализировали два расширения, которые уже описали, Имеются в виду пои "Символов и определение Набора Символов.
Хорошие пользовательские интерфейсы
Зависящая от контекста природа труда столь естественна и настолько широко распространена, что едва ли кто-то из нас станет противиться существующему положению вещей. Когда можно достичь хорошей производительности? Только тогда, когда все необходимые инструменты и материалы под рукой. Именно поэтому помощник зубного врача раскладывает на столике врача инструменты и препараты всегда в одном и том же привычном порядке.
Содержимое интерфейса
Нам кажется, что наилучшим способом моделирования содержимого пользовательского интерфейса является один из самых простейших - моделирование на бумаге, с добавлением пояснительных замечаний. Разумеется, такой способ применяется давным-давно профессионалами в самых разных областях, но особенно нас вдохновила работа, авторами которой являются Карен Хольцблатт (Karen Holtz-blatt) и Хью Байер (Hugh Beyer).
Энтропические эльфы
Большие доски или листы бумаги, прикрепленные к стене - это очень хорошее наглядное пособие, особенно при работе в группе. Каждый участник проекта имеет возможность наблюдать и влиять на пространства взаимодействия. Тем не менее нелишним здесь будет небольшое предупреждение.
Списки содержимого
Модель содержимого с пояснительными записками - это хороший способ преодоления проблем с архитектурой интерфейса, однако такой метод плохо подходит для ведения документации, в ряде случаев это оказывается плохим средством общения и перманентного архивирования. Нам кажется, что текстовая форма модели содержимого для перечисленных целей годится куда лучше.
Инструменты и материалы
В каждое пространство взаимодействия в модели содержимого входит набор абстрактных инструментов и материалов, представляющих собой внутреннее наполнение и те возможности, которые будут предоставлены пользователю интерфейсом. Эти абстрактные компоненты играют роль меток для реальных визуальных компонентов создаваемого интерфейса.
Информационные потребности
После того как мы определили свои информационные потребности, необходимо пересмотреть все поддерживаемые элементы use case, чтобы определить свои потребности в функциях и операторах. Для каждого выявленного таким образом инструмента создается метка в контексте взаимодействий, Все пояснительные заметки снабжаются краткими названиями, характеризующими главные функции или предназначение отображаемых компонентов.
Карты навигации по контекстам
В реальном мире типичным программным инструментам и приложениям присуще наличие множества контекстов взаимодействий. При решении сложных задач, состоящих из множества подзадач, обычно приходится перемещаться из одного контекста в другой- Каждое абстрактное пространство взаимодействий, в конечном счете находит свое выражение в экране, диалоговом окне или обычном окне, которое должно быть понято пользователем, и каждое изменение контекста требует соответствующего изменения мышления пользователя.
Представления: поведенческое, архитектурное и последовательное
Карты навигации по контекстам могут служить для разных целей. Простейшим вариантом является поведенческое представление, которое моделирует переходы между контекстами взаимодействия, связанными с отработкой одного конкретного элемента use case. Такое представление часто является отправной точкой проектирования архитектуры. Если все поведенческие представления для всевозможных элементов use case приложения собрать в одну диаграмму, включающую в себя все контексты взаимодействия плюс переходы между ними, то результатом этого действия будет архитектурное представление.
Применения карт навигации
Карты навигации по контекстам применяются действительно для самых разных целей. Такая карта может служить контрольным средством для проверки пространств взаимодействия, входящих в состав модели содержимого, так как с ее помощью можно выявлять проблемы распределения задач по этим пространствам.
Уменьшение количества функций и средств
Система не будет работать, если не предоставлены необходимые средства реализации всех элементов use case; именно поэтому проверяется, все ли требуемое для этого вошло в модель. Если же в интерфейс входят пространства взаимодействия или элементы содержимого, не востребованные никакими элементами use case, это означает, что интерфейс получился болев объемным, чем нужно.
Проектирование элемента case для печати
В терминах практичного проектирования элемента case для печати Документа расширяется элементом смена Режимов Печати. Среди прочей информации" необходимой пользователю для отработки элемента печать Документа, есть и данные о текущем режиме печати.
От абстракции к выражению
Сущностные модели, представленные в трех предыдущих главах, - это отнюдь не вещи в себе. Модели содержимого, наряду с моделями ролей и задач, служат ориентирами для разработчиков, стремящихся к созданию качественного пользовательского интерфейса, привязанного к решаемым системой задачам. В этой главе, как и в последующих, мы начнем изучать специфику превращения модели содержимого в модель реализации, являющуюся прототипом реальной системы.
Забавные шрифты
Обычно хорошим стилем считается отказ от смешивания большого количества шрифтов разных стилей и размеров (не берем в расчет журнал Wired и тому подобные издания). Постоянные изменения шрифтов и стилей могут разрушить взаимодействие и способны только раздражать и отвлекать пользователей. Это не означает, что абсолютно все должно быть представлено пользователю в едином, стандартизованном виде, с использованием прямого шрифта без засечек (Sans Serif), применяемого в операционной системе.
Яркие интерфейсы
Современные графические пользовательские интерфейсы в целом и интерфейс Windows в частности увековечили низкоконтрастную, серую цветовую гамму, которая со временем начинает казаться ужасно скучной. На удобочитаемость в значительной степени влияет контрастность. Скажем, черный текст на белом фоне будет читаться просто прекрасно. Белый текст на черном фоне тоже будет вполне читаем.
Знаки и символы
Графические пользовательские интерфейсы, как следует из названия, подразумевают использование графики, и многие разработчики интерфейсов, особенно начинающие, чувствуют, что они просто вынуждены "сотворить что-нибудь этакое" при помощи графики. Графика - это серьезный канал коммуникации с пользователями, который при умелом использовании может давать хорошие результаты.
Озвучим интерфейс
Еще одним эффективным каналом общения с пользователями может быть звук. Разумеется, как и цветовое оформление, звук нужно применять с умом. А необходимо и достаточно на самом деле совсем немного. Пользователи быстро научатся игнорировать и отключать звуковое оформление , если оно будет встречаться слишком часто, если не будет понятно, для чего оно нужно, и в какой момент в следующий раз что-нибудь бумкнет или звякнет. В серьезных приложениях глупое звуковое сопровождение действий сильно утомляет.
Технологический процесс работы
В контексте пользовательского интерфейса и проектирования взаимодействий технологическим процессом работы называется способ перемещения между пространствами взаимодействия и внутри них. Разметка и организация элементов интерфейса формируют технологический процесс, определяя, каким он будет: гладким и эффективным или же полным трудностей и неуклюжим.
Организация рабочего потока
Все больше и больше. Недавно в организации рабочего потока, связанного с программным обеспечением, наметилась тенденция разбиения работы на маленькие шаги, каждый из которых представлен в отдельном контексте взаимодействий. На каждом шаге пользователю обычно приходится принимать какое-то одно решение или вводить одну единицу информации перед переходом к следующему шагу или сменой контекста. Иногда добавляется дополнительный шаг подтверждения ввода.
Распределение информации
Информация, как и инструменты и функции, должна быть распределена между контекстами взаимодействия таким образом, чтобы отражать ожидания, обусловленные паттерном (образцом) применения, Если, например, какая-то информация, целиком используемая при отработке элемента use case, будет разбросана по нескольким экранам или диалоговым окнам, то пользователю придется переходить из одного контекста в другой, что уменьшит эффективность и повысит количество ошибок.
Визуальная структура
В соответствии со структурным принципом практичность повышается, когда похожие или взаимосвязанные элементы представляются на интерфейсе похожим образом, а непохожие и независимые соответствующим образом отделяются друг от друга. Хорошая организация визуальных элементов позволяет пользователю вникать в смысл всех контекстов взаимодействий.
Выбор и проектирование видимых элементов
В процессе проектирования системы пользовательский интерфейс необходимо наполнять визуальными компонентами в форме реальных элементов интерфейса, которые будут служить в качестве инструментов и материалов, применяемых пользователями. В весьма редких случаях выбор элемента будет очевиден и однозначен.
Значки как средство коммуникации
Графический пользовательский интерфейс немыслим без значков. Значки - эта графические символы, изображаемые на инструментах и других видимых элементах. Они действительно настолько вездесущи, что многие считают графический интерфейс ничем иным, как набором значков, эти понятия для них являются практически синонимами.
Семиотика
Слово "знак" для разработчика ПО и специалиста по знаковым и символьным системам означает совершенно разные понятия. Разработчикам интерфейсов полезно было бы владеть хотя бы основами семиотики, науки о знаках [Callahan, 1994; Constantine и Henderson-Sellers, 1996J. Мы называем значками любые изображения на инструментах или других видимых элементах управления, однако с точки зрения семиотики это лишь одна из трех базовых категорий знаков.
Организация панелей инструментов
Структурный принцип применим к организации инструментов и значков не в меньшей степени, чем к любым другим частям интерфейса. Практически любой нормальный современный интерфейс предоставляет пользователям определенную степень свободы в его настройке (глава 12), но это не может служить оправданием отсутствию заботы об оптимальной организации стандартных, "заводских" настроек, которые пользователь может лицезреть сразу же после установки системы.
Меню
Меню - это, конечно, не такая захватывающая тема, как значки, однако она не менее обширна и многогранна, поскольку переоценить вклад меню в практичность современных программных средств, поверьте, непросто. Меню - это на самом деле нечто большее, нежели просто средство предоставления доступа к функциям и свойствам программы. Алан Купер [Alan Cooper, 1995J называет меню таким педантичным термином, как педагогический вектир, предполагая тем самым, что меню могут быть средством, позволяющим пользователям узнать, что и как они могут делать с помощью системы.
Организация меню
Меню должны быть организованы в соответствии с семантикой и структурой задачи, которая, опять же, обязывает разработчиков вникать в то, как пользователи представляют себе свою работу над задачей, а также в то, как, собственно, эта задача устроена. Названия меню и пунктов внутри них должны соответствовать общепринятым договоренностям, должны отражать словарь пользователей и прикладной области.
Проектирование качественных меню
Проектирование качественных меню, как и проектирование других элементов интерфейса, строится на нахождении баланса между различными формами и источниками сложностей. Строка меню е окне приложения должна отражать основные категории или наборы задач верхнего уровня, чтобы пользователь с максимальной вероятностью мог с первой попытки угадать, где он сможет найти нужные функции и настройки, чтобы ему не нужно было ползать для этого по всему иерархическому дереву меню.
Доступ с помощью клавиатуры
Меню - это лишь одно из нескольких средств доступа к функциям системы. Пользоваться ими можно не только с помощью нажатий клавиш мыши, но и с помощью клавиатуры. Все, что можно сделать, воспользовавшись инструментами с инструментальной панели, должно быть также доступно через меню.
Контекстные меню
Контекстные меню - это те небольшие меню, которые появляются при нажатии правой клавиши мыши, сочетания клавиш Shift+FW или специальной клавиши Application (Приложение) на клавиатурах с поддержкой Windows. Содержимое меню зависит от того, какой объект выделен в данный момент, потому такие меню и называются "контекстными".
Экспресс-меню
Любые движения мышкой занимают время. Всякий раз, наводя мышь на объект интерфейса и щелкая на нем, мы тратим целую секунду, а иногда и две. И если на нажатие клавиши у всех пользователей уходит примерно одно и то же время, то на перемещение по экрану и фокусировку на нужном объекте у пользователей уходит разное время, определяемое законом Фиттса [Fitts, 1954].
Подбираем элементы выбора
Когда дело доходит до компонентов пользовательского интерфейса, посредством которых пользователи осуществляют свой выбор, разработчики, сталкиваясь с их многообразием, иногда становятся в тупик. Однако базовый набор достаточно прост и представлен двумя основными компонентами; переключателями и флажками. Переключатели, называемые также селективными кнопками, позволяют пользователю выбрать только одно значение из множества. Флажки же служат для того, чтобы пользователь мог выбрать произвольное количество значений из множества.
Несколько из нескольких
Проблема выбора перестает быть столь острой, когда дело доходит до предоставления пользователю возможности выбора от 0 до Означений из N. Флажки. Флажки - это традиционные инструменты для выбора любого количества значений из множества. Они работают наиболее эффективно, когда мы имеем дело с умеренным количеством значений, однако порой их используют и с довольно обширными наборами данных.
Особые случаи
Описанные выше компоненты подходят для многих типичных случаев, однако время от времени возникают кое-какие ситуации, которые не удается очевидным образом разрешить с их помощью. Например, возможна такал ситуация, когда пользователь должен сделать какой-то выбор, но при этом может выделить как один, так и несколько элементов.
Творческая инженерия
Вспоминая Стивена Зондхайма (Steven Sondheim) и его Sunday in the Park with Georet мы, пожалуй, согласимся: искусство - штука непростая. Но и инженерия не проще, надо сказать! И там, и там нужен творческий подход, если вы всерьез намерены добиться хороших результатов. Возможно, благодаря графическим элементам и быстрому росту количества и профессионализма разработчиков графики, разработка пользовательских интерфейсов тоже стала своего рода искусством [Laurel и Mountford, 1990J.
К чему новаторство?
При проектировании, направленном на удобство использования, любой переход от модели содержимого к визуальному проектированию - это шанс, чтобы выйти на взлет, то есть шанс проявить свои творческие способности. Какова наилучшая реализация данного абстрактного компонента?
Проявления новаторских идей
Новаторство в деле разработки интерфейсов пользователя может оказывать влияние на визуальные компоненты, их комбинации и расположение. Оно может проявляться и во внешнем виде элементов, и в их поведении. А может, и в том и в другом. Обычно различают инновации следующих типов:
Процесс новаторства
В течение долгих лет нам приходилось работать с клиентами, требующими от нас разработки новых интерфейсов, которые были бы не просто хорошими, а абсолютно неповторимыми. Однажды мы даже согласились совершить маленький прорыв в пользовательских интерфейсах, причем были поставлены в весьма узкие временные и финансовые рамки.
Проектирование по антидихотомическому принципу
Одним из самых распространенных препятствий, встречающихся на пути разработчиков и мешающих им генерировать новые идеи, является склонность человека к дихотомическому мышлению. Люди слишком часто противопоставляют веши друг другу, делят мир на черное и белое, усматривают во всем, что их окружает, две противоборствующие силы.
Радикальное развитие
Билл Бакстон (Bill Buxton) из Silicon Graphics предложил свой подход к созданию новаторских интерфейсов. Он назвал его радикальным развитием. Радикальное развитие - это разновидность инженерного искусства, цель которой состоит во внесении в систему важных, но не революционных изменений. Радикальное развитие происходит в рамках некоторого status quo и связало с итеративными, но существенными изменениями в интерфейсе или организации взаимодействий.
Инструктивные интерфейсы
Идеал, установленный правилом доступности, состоит в том, чтобы разрабатывать такие интерфейсы, для эффективной работы с которыми не нужны справочники и специальная подготовка. Это задача трудная, но все же решаемая при помощи традиционных форм и знакомых компонентов, а вот разработать новаторский инструктивный интерфейс практически невозможно.
Средства и ограничения
Среди множества других заслуг гуру практичного подхода Дональда Нормана (Donald Norman) следует выделить введение двух терминов, ставших частью лексикона всех специалистов по пользовательским интерфейсам во всем мире. Средства (aftor-dances) и ограничения (constraints) - это два столпа инструктивных интерфейсов.
Мина Громкость
Запомните одно общее правило общения с пользователями: всегда точно выражайте то, что вы имеете в виду. Если вы хотите сообщить о том, что действия вне области диалогового окна запрещены, так и скажите, используя средства визуальной выразительности: например, измените форму курсора на перечеркнутый кружочек.
Устойчивость визуальных объектов
Все дети живут в удивительном мире WYSIWYG (What You See Is What You Get, то есть что видишь, то и получаешь). Если они видят, что мячик закатывается за кубик, то они уверены, что шарик перестает существовать. Но проходят годы, дети набираются опыта, приобретают то, что психологи называют устойчивостью визуальных объектов.
Идиоматические расширения
Идиомы взаимодействия - это привычные, традиционные действия и способы взаимодействия, используемые для работы с пользовательским интерфейсом [ср, с Cooper, 1995]. Подобно идиоматическим выражениям в устной и письменной речи, идиомы взаимодействия не передают информацию буквально.
Движущиеся интерфейсы
Анимация в интерфейсах может использоваться не только для создания картинок типа "состояние ожидания" или "горящая мусорная корзина". Хотя многие разработчики считают, что анимация - это своего рода развлечение, у нее есть масса законных применений в новаторских интерфейсах. Конечно же, анимированные элементы служат в том числе и для того, чтобы интерфейсы выглядели более интересно и захватывающе, однако справедливо также и то, что анимация в значительной мере влияет на практичность.
Работа над скроллингом
Широкая популярность какого-нибудь компонента или метода еще не означает, что он действительно хорош. Даже старые, установившиеся стандарты только улучшаются, когда к ним применяют творческий подход. Некоторые стандартные свойства современных графических интерфейсов оказываются никуда не годными, когда дело доходит до анализа практичности.
Перегрузка
Еще одним методом практической реализации радикального развития является активная перегрузка. Разработчик начинает с проектирования пассивных визуальных компонентов, а затем нагружает их активным поведением. Такая технология называется перегрузкой, поскольку, в конечном счете, элемент управления становится многозначным и многофункциональным.
Забавы
Это самая забавная часть книги. Для многих разработчиков настоящее веселье начинается, когда дело доходит до создания бумажного прототипа или визуального проекта пользовательского интерфейса. Неудивительно, что некоторым нравится бросаться в моделирование именно такого рода. В каком-то смысле они ведут себя так же, как программисты, обожающие сразу же начинать писать какой-нибудь код, не удосуживаясь как следует продумать свой проект.
Архетипы прототипов
Прототипы бывают самые разные: активные и пассивные, точные и неточные, горизонтальные и вертикальные. С каждым типом прототипов связаны свои проблемы, все они имеют свои характерные особенности и области применения. Активность. Прототипы могут быть либо активными, либо пассивными. Пассивный прототип сам по себе не делает ничего.
Пассивные прототипы
Итак, как уже говорилось, пассивные прототипы могут существовать в бумажном варианте, в виде компьютерных рисунков, созданных при помощи обычных программ для рисования, либо в виде неработающих экспериментальных моделей, созданных с использованием тех или иных инструментальных программных средств. Так называемые бумажные прототипы - это, как вы уже поняли, обычные наброски на листке бумаги, изображающие внешний вид пользовательского интерфейса.
Создание прототипов интерфейсов
Важным преимуществом прототипов является то, что создать прототип проще, чем программу. Надо сказать, что вычурные прототипы, пытающиеся возложить на себя слишком много обязанностей, оказываются нецелесообразными. Хорошая модель реализации - это простая модель, которую легко сконструировать и которой при этом достаточно для представления и документирования проекта.
Отображение моделей
Трансляция модели содержимого в модель реализации - задача более комплексная, нежели просто установление соответствий или замена конкретными компонентами абстрактных. В некоторых случаях, когда задача простая или модель была разработана с особой тщательностью или просто талантливо, процесс трансляции может напоминать тривиальный переход от одной формы представления к другой.
Контексты интерфейсов
Несмотря на то что некоторые программисты склонны мыслить преимущественно в терминах окон и диалогов, современные графические интерфейсы предоставляют большой набор возможностей, в котором есть из чего выбрать. К сожалению, слишком часто ни одно из стандартных решений не подходит для решения поставленной задачи.
Наполняя реализуемые контексты взаимодействий визуальными компонентами" разработчик всегда стремится к тому, чтобы работа с ПО была максимально упрощена. Мы всегда начинаем с простейших решений и отказываемся от них только в случае необходимости. Поначалу все абстрактные компоненты реализуются одним, независимым элементом пользовательского интерфейса. Таким образом, на первых порах обычно используются только стандартные элементы и стандартные решения, касающиеся их организации.
Просмотр экранных копий
Приступая к решению такой задачи, можно создать нечто незамысловатое, вроде того, что показано на рис. 10.3, а. Идентификатор изображения становится маркированным полем; экранное изображение отображается в контейнере в виде маленькой картинки предварительного просмотра, как и задумывалось. Наконец, инструмент для навигации представляет собой две кнопки, одна из которых служит для перехода к следующему изображению, а другая - к предыдущему.
Композиция интерфейса
Вопрос разметки интерфейса нельзя рассматривать отдельно от вопроса выбора визуальных компонентов. Необходимость вывода большого списка или области расположения рисунка может определять выбор элементов интерфейса. Может происходить и обратное: элементы, тесно связанные со структурой решаемой задачи, определяют использование экранного пространства, как проиллюстрировано рис. 10.3.
Модели реализации в деле
Изучив эту и три предыдущие главы, мы теперь можем смело приступить к проектированию модели реализации или к созданию визуального проекта для нашего апплета, расширяющего возможности клавиатуры. Мы начнем с центрального контекста взаимодействия, поддерживающего центральные элементы use case вставка Символа и вставка Фразы.
Проектирование апплета: вторая попытка
Одна из проблем исходного проекта связана с поведением прокручиваемого списка выбора, используемого для задания шрифта или определяемой пользователей группы символов. При прокрутке длинного списка в поисках нужного значения текущий выделенный набор "уезжает", пропадая из поля зрения, и пользователь может просто забыть, что конкретно он ищет среди символов, показанных в поле вывода слева и меняющихся синхронно со значениями списка, расположенного справа.
Даже экспертам нужна помощь
Вот типичная cm унция: вы забыли, как решить при помощи ПО некоторую нужную задачу, которая встречается редко, и вот вы неохотно обращаетесь к справочной системе. Смотрите по одному ключевому слову, по другому, затем просматриваете три уровня вложенных записей. Ничего, абсолютно ничего похожего на то, что нужно! Наконец, вы сдаетесь и спрашиваете своего коллегу.
Элементы use case для справочных систем
Получение справки иногда является необходимым этапом решения задачи. Обращение к справочной системе может быть (в терминах модели задачи) расширением практически любого элемента use case, поддерживаемого той или иной частью ПО. Если мы проанализируем обращения к справочкой системе с точки зрения пользовательских устремлений, то увидим, что справочная система может работать по-разному, и в зависимости от того, что именно пользователю нужно найти, должна различаться реакция ПО.
Организация справочных систем в соответствии с элементами use case
Проблема с процедурной помощью, то есть элементом поиск Инструкции, для пользователя заключается, прежде всего, в том, как сообщить системе, что именно ему нужно. Поиск нужной статьи справочной системы сильно упрощается за счет всеохватывающего, понятного индексирования, а также за счет квазиинтеллектуального механизма поиска типа мастера ответов (Microsoft).
Доступ к справочным системам
Существует множество механизмов активации справочных систем, и задача проектировщика - выбрать из этого многообразия метод, наиболее подходящий для данного элемента help case и интерфейса в целом- Некоторые методы возлагают ответственность за запуск справочной системы целиком или частично на программное обеспечение. Перечислим эти методы:
Звуки и другие развлечения
И звуки, и анимация могут применяться для предоставления помощи пользователям. Звук является многообещающим каналом представления процедурной помощи, то есть поддержки элемента help лоискИнструкции, особенно когда речь идет о пользователях, работающих с системой редко или нерегулярно. Озвученные справочные системы обладают некоторыми преимуществами по сравнению с обычным текстом, который необходимо считывать с экрана.
Самоучители
Программные обучающие системы предлагают еще один способ предоставления помощи. Самоучители представляют собой расширения инструкций. Они обычно служат для описания групп функций или целых систем. Чаще всего они нацелены на поддержку наименее опытных пользователей. Даже самые замечательные самоучители с трудом подходят для поиска справочной информации, касающейся конкретных свойств системы.
Помогающий стиль
Как и в любом деле, связанном с писательством, для написания хороших справочных файлов, сообщений и записей справочных систем требуется определенный навык и талант. Большинство программистов не преуспевают в деле написания справочных систем. Происходит это не только потому, что у них обычно отсутствуют писательские навыки, но и потому, что, с точки зрения пользователей, они видят все шиворот-навыворот.
Элементы стиля справочных файлов
Ну так в чем же секрет хорошей документации или встроенной справочной системы? Только суть! Людям бывает нужна помощь при выполнении каких-то задач. Их работа уже и так прервана, так зачем же заставлять их тратить время на чтение каких-то предисловий, "воды" или раздражающих обсуждении, не имеющих отношения к делу? Пользователи просто желают получить ответы на свои вопросы и затем вернуться к своей нормальной деятельности.
Сравнение документации и справочных систем
Документация и справочная система служат для разных целей. Первая не может заменить вторую, хотя документацию иногда и пытаются выдать за справочную Систему. Задача документации - фиксировать, документировать. Задача системы помощи - помогать. Встроенные справочные файлы и документация не должны противоречить друг другу, однако худшие образцы руководств пользователя - это распечатки из файлов справки, а худшие образцы справочных систем получаются при автоматическом их генерировании из документации.
Эффективная помощь
В какой форме помощь будет эффективнее всего? Это зависит от того, что подразумевать под помощью и что подразумевать под эффективностью. Целесообразным критерием оценки может служить эффективность затрат. Например, личный инструктор и консультант по PowerPoint обеспечат высочайший уровень поддержки, но затраты при этом также будут высоки. С точки зрения эффективности затрат такое решение нельзя считать оптимальным.
Полезные сообщения
Представьте себе: программист, собрав остатки воли в кулак, сконцентрировался и пытается отыскать ошибку в программе. Разумеется, он больше всего не хочет, чтобы в этот напряженный момент раздался телефонный звонок или выскочило на экран сообщение о приходе свежей электронной почты. Однако тому же программисту необходимо быть в курсе, например, того, что сервер скоро будет перезагружаться, или того, что в здании возник пожар.
Борьба с навязчивостью
Разработчикам следует прикладывать все усилия для того, чтобы программа могла исправлять обнаруженные ошибки, преодолевать их или хотя бы обходить, но не за счет элементарного вывода сообщений об ошибках. Обычно достаточно лишь немного поразмышлять, как становится очевидно, что почти всегда существуют некоторые признаки, проанализировав которые программа может выдать логичные, приемлемые и предсказуемые результаты. Чтобы избежать чрезмерного использования сообщений об ошибках, программисту следует:
Прогрессивное использование
Модель прогрессивного использования, или трехфазная модель [Constantine, 1994g], может служить техническим руководством по созданию архитектуры интерфейсов с применением только что описанной метафоры лыжного спорта. Такая модель подразумевает, что паттерны (образцы) применения развиваются по мере того, как пользователи набираются опыта работы с предоставляемыми возможностями и средствами.
Паттерн "Работа новичка"
По определению, новичками считаются те, у кого почти или вовсе нет опыта работы с теми или иными функциями системы. В то же самое время, как и всем пользователям, что-то им все-таки приходится делать даже тогда, когда они впервые видят данную часть ПО. Они начинают свою деятельность с полного незнания того, что и как работает, что и как организовано. Несмотря на отсутствие тренировки и опыта они, разумеется, рассчитывают сразу же получить с помощью системы высокую производительность труда.
Поддерживающие интерфейсы
Как горнолыжный курорт состоит из нескольких связанных между собой трасс разной степени сложности, так и качественный пользовательский интерфейс состоит из разнообразных средств и функций, некоторые из которых лучше подходят для профессионалов, а некоторые - для новичков. В результате получается, конечно, не три разных интерфейса, а один, но с взаимосвязанными функциональными частями. Эффективная архитектура должна позволять запросто переходить от одного набора средств к другому.
Средства эволюции
Средства эволюции, предназначенные для применения пользователями среднего уровня, это отдельная часть архитектуры интерфейса, В каком-то смысле, они служат чем-то вроде моста между средствами обучения и средствами производства для пользователей, приобретающих опыт и повышающих уровень своих знаний и умений. Качественные средства эволюции помогают повышать производительность труда, почти непрерывно расширяют возможности применения системы.
Мышь и клавиатура
Сторонники современных графических интерфейсов пользователи (GUI) с великим усердием восхваляют добродетели виртуальных рабочих столов и непосредственной манипуляции их элементами, тогда как ярые поборники старой школы утверждают, что нет на свете ничего быстрее ввода команд и параметров с групповыми символами из командной строки. На чьей стороне правда? Это, конечно, зависит от разных причин - не только от специфики приложения, но и от самого пользователя и его опыта.
Средства производства
Хорошие средства производства включают в себя различные традиционные и знакомые уже методы, позволяющие опытным пользователям работать более эффективно. Среди этих методов можно выделить горячие клавиши, мгновенно переносящие пользователя из одной части интерфейса в другую, сочетания клавиш быстрого доступа, представляющие собой альтернативу блужданиям по меню и инструментальным панелям при помощи мыши, встроенные пользовательские макросы и скрипты, автоматизирующие многие действия, а также заданные {пользователем) последовательности операций, вызываемые одним щелчком мыши или с помощью нескольких нажатий кнопок клавиатуры.
Проектирование прогрессивного использования
Одни из самых неприятных и сложных проблем, с которыми приходится сталкиваться разработчикам, связаны с поддержкой пользователей, продолжающих повышать свой уровень. Ведь при этом необходимо с одной стороны, создать дифференцирующиеся интерфейсные средства, а с другой стороны, обеспечить визуальную и функциональную последовательность всех режимов и стилей работы.
Помощь в эволюционном процессе
Помощь, предоставляемая в процессе эволюции, включает в себя справку, предназначенную для поддержки постепенного усложнения режимов работы с системой, то есть для начинающих, которые хотят продвигаться вперед, и для средних пользователей, желающих стать экспертами. Эволюционная помощь может принимать разнообразные формы.
Адаптируемые и адаптивные интерфейсы
При создании интерфейсов, предназначенных для поддержки разнообразных и развивающихся паттернов применения, можно использовать две принципиально разные стратегии: адаптивные интерфейсы и адаптируемые интерфейсы. Адаптируемым считается интерфейс, который пользователь может настраивать или изменять в соответствии со своими потребностями.
Непрерывная настройка
Задачей настройки является предоставление пользователям среднего уровня и опытным пользователям возможности простого и гибкого изменения интерфейса с помощью самых обычных навыков и повседневных операций. В некоторых случаях это просто установка флажка или переключателя, говорящего о том, что выбранное диалоговое окно или управляющий элемент будет иметь те или иные начальные значения или значения по умолчанию. Иногда требуются более творческие решения.
Особенности доступа
По мере усложнения использования программы становится желательным быстрый доступ ко все большему количеству инструментов. Одним из возможных механизмов упрощения доступа к самым используемым функциям является вариативная форма меню, когда оно может быть коротким или длинным. Разумеется, при этом необходима очевидная и понятная связь между этими двумя формами.
Прикладное прогрессивное использование
Апплет, расширяющий возможности клавиатуры, обладает некоторыми возможностями поддержки прогрессивного использования. Несмотря на некоторую нерегулярность, присущую любому использованию любой системы, можно выявить характерные особенности работы пользователей, играющих определенные роли. В частности, в роли Случайный Переводчик каждое использование программы связано с некоторыми последовательностями действий или выборов.
Контекст, исключающий звуки
Так как мы уже успели побывать в банке, занимающемся нашими корпоративными счетами, мы решили разузнать подробности осуществления финансовых трансфертов. По другую сторону большого стола из красного дерева сидит молодой клерк и помогает нам заполнять бумаги, связанные с транзакциями. Внезапно его терминал начинает пищать. Нам стало интересно, и мы взглянули на монитор терминала. Во весь экран сияло сообщение об ошибке.
Операционное моделирование
Действительно практичное ПО настроено на работу в своей среде. Пользовательский интерфейс и общая архитектура создаются с учетом операционного контекста. Нам ведь не придет в голову использовать одну и ту же базу данных для магазина, торгующего домашними животными, и для магазина автозапчастей; не придет в голову и создавать одинаковые наборы классов объектов для телефонных коммутаторов и торговых точек. Точно так же мы должны отбросить мысль о проектировании интерфейса систем с использованием "безразмерного" подхода.
Адаптация к среде
В некотором смысле операционную модель можно считать хранилищем потенциально важной информации об операционном контексте. Обычно она собирается путем накопления. Несмотря на то что большая часть информации может быть доступна достаточно рано в цикле разработки ПО, вполне допустимо расширять и уточнять операционную модель наряду с другими моделями и самим проектом интерфейса.
Привязка контекста
Итак, большая часть информации, составляющая операционную модель, становится доступной на относительно ранних стадиях процесса проектирования. Ее получение является частью процесса сбора требований и построения ролевой модели. Как уже говорилось в главе 4, структурированная ролевая модель служит не только в качестве исходной информации для составления модели задач, но и как хранилище информации об операционном контексте, связанном с ролями пользователей.
Профиль обязанностей
Профиль обязанностей включает в себя различные характеристики реальных пользователей, играющих определенную роль по отношению к системе. Не всегда представляется возможным заранее узнать тип людей, которые могут работать с данной системой, однако во многих случаях можно сделать правдоподобные предположения, основывающиеся либо на опыте прошлого, либо на опросах пользователей, либо исходя из общих понятий, либо просто угадав.
В профиле взаимодействий собрана информация, касающаяся взаимодействия с системой пользователей, играющих те или иные роли или работающих с теми или иными элементами use case. На пользовательский интерфейс могут оказывать влияние все перечисленные ниже аспекты: