Текст книги "Человеко-компьютерное взаимодействие"

• заблокированные файлы на остальных дисках показываются иначе, чем незаблокированные;

• при попытке записать документ поверх заблокированного появляется сообщение об ошибке (рис. 4.7).

Внимание! Кнопка «Закрыть» выбрана по умолчанию, чтобы снизить вероятность перезаписи важных файлов. Конечно, лучше всего было бы, чтобы ОС сама снимала с копируемых с компакт-диска файлов метку «Read Only». Многие проблемы при этом бы исчезли, поскольку защищенными от записи остались бы только действительно важные для ОС файлы.

Об этом примере осталось сказать немного. Во-первых, текст сообщения должен быть возможно более коротким. Во-вторых, диалоговое окно не самый лучший способ показывать сообщения об ошибках, во всяком случае в ПО. Дело в том, что в Windows имеется элемент управления, который значительно лучше использовать для показа сообщений. Называется этот элемент «пузырь» (balloon) (рис. 4.8).

Рис. 4.8. «Пузырь» в его лучшем проявлении (не обращайте внимание на текст)

«Пузырь» по сравнению с диалоговым окном имеет существенные достоинства. Во-первых, он не так сбивает фокус внимания, нежели окно. Во-вторых, чтобы закрыть «пузырь», пользователям не обязательно нажимать на какую-либо кнопку, достаточно щелкнуть мышью в любом месте экрана. В-третьих, он не перекрывает значимую область системы. В-четвертых (что самое главное), он показывает, в каком именно элементе управления была допущена ошибка. Все это делает «пузырь» вещью незаменимой. К сожалению, «пузыри» имеют и недостатки: первое – в них не может быть никаких элементов управления, так что использовать «пузырь» в предыдущем примере, например, невозможно; второе – «пузырей» практически нет в Интернете.

Для лучшего понимания разных способов сообщения об ошибках полезно просматривать примеры хороших и плохих интерфейсов. К счастью, существуют их коллекции, именуемые «Зал почета интерфейсов» и «Зал позора интерфейсов», первый по адресу http://www.akzhan.midi. ru/iarchitect/mfame.htm, второй – http://www.akzhan.midi.ru/iarchitect/ mshame.htm.

4.4. Обучение работе

Растущее число пользователей делает проблему их обучения работе с компьютерной системой чрезвычайно важной. Вместе с тем цель хорошего ПИ – возможность понять логику его работы неподготовленному пользователю. Минимизация затрат на обучение работе с системой и есть одно из основных направлений человеко-компьютерного взаимодействия.

Учатся же пользователи только при наличии соответствующей мотивации. Но мотивация пользователя должна быть адекватна усилиям, затрачиваемым на обучение. Кроме того, пользователь будет учиться какой-либо функции, только если он знает о ее существовании, поскольку, не обладая этим знанием, он не способен узнать, что за ее изучение ему воздастся. Иначе говоря, одной мотивации недостаточно, если пользователь не знает, какое вознаграждение за свои усилия он получит. Так, например, есть ничтожно мало людей, которые бы действительно полностью знали MS Word, подавляющее большинство умеют пользоваться не более чем 5% его возможностей, при этом даже не подозревая об остальных. Плохо это по многим причинам. Во-первых, пользователи работают с системой не слишком эффективно, поскольку вместо методов адекватных они используют методы знакомые. Во-вторых, достаточно часто случается, что пользователи, не зная, что имеющийся продукт делает то, что им нужно, ищут (и находят) продукт конкурента. В-третьих, при таком положении затруднительно продавать новые версии продукта: если пользователь не умеет работать с тем, что есть, убедить его совершить покупку ради новой функции вряд ли удастся. Таким образом, чтобы пользователь начал учиться, ему нужно рассказать о функциональности системы, делая акцент на возможностях, которые пользователь получит, этой функции обучившись. А дальше он сам будет учиться, если, конечно, будет знать чему и за какие преимущества.

Есть два основных направления повышения скорости и качества обучения за счет свойств ПИ – это общая «понятность» системы и наличие обучающих материалов. Рассмотрим их по порядку.

Термин «понятность» не очень строг, его следует понимать интуитивно как такой интерфейс, который адекватен представлению пользователя о работе с системой. Основной смысл термина «понятность» – соответствие системы и ее ПИ модели этой системы в голове пользователя, т.е. соответствие объективного и субъективного.

Важность адекватной субъективной модели логики работы. Как правило, чтобы успешно пользоваться какой-либо системой, человеку необходимо понимать, как система работает. При этом не обязательно точно понимать сущность происходящих в системе процессов, важнее понимать то, что можно назвать логикой ее работы. Скажем, утюгом никогда не сможет воспользоваться человек, который не знает, что провод от утюга надо включить в розетку. При этом не обязательно знать, сколько энергии утюг потребляет (отсутствие точности), равно как и то, при сохранении искренной уверенности, что электричество по проводам течет как вода (отсутствие правильности). Неприятности наступают, когда представления человека о логике работы системы не совпадают с реальным ее устройством. Так, например, человек, никогда не встречавшийся с электричеством, поставит утюг на огонь, отчего прибор непременно сгорит.

Аналогичная ситуация возникает и с ПИ. Трудно бывает объяснить новичку пользу от записи файла после его редактирования. Дело в том, что без понимания сущности происходящих в компьютере процессов понять необходимость записи невозможно. Допустим, пользователь создал новый документ, что-то в нем сделал, после чего попытался выйти из программы. Программа спрашивает его: «Сохранить документ или нет?» Во-первых, в этом вопросе главное значимое слово непонятно. Что такое сохранить? Где сохранить? Куда сохранить? Если же вопрос ставится техническим языком, а именно «Записать документ на диск?», то и здесь возникает недоумение: на какой диск? Во-вторых (что важнее), даже если пользователь понял вопрос, он все равно не может понять, зачем документ сохранять. Ведь документ уже имеется, сохранять его не надо. Ситуация усугубляется тем, что даже начинающий пользователь знает, что, если он нажмет кнопку ОК, начнется какое-то действие. А поскольку пользователь не хочет, чтобы действие, которого он не понимает, начиналось, он недрогнувшей рукой нажимает кнопку «Нет», после чего программа закрывается, а файл не сохраняется. Проблема в том, что пользователь искренне уверен, что, если файл есть, с ним уже ничего не сделается.

Есть два способа научить пользователя сохранять файлы. Сущность первого состоит в следующем: научить пользователя время от времени и перед выходом из программы сохранять файл, иначе у него будут проблемы. Рано или поздно (скорее поздно) пользователь начнет сохранять файл автоматически, по-прежнему не понимая, почему он это делает и только подчиняясь полученному указанию (т.е. совершая действие, по сути, ритуальное). Заметим, что такого рода действия весьма часты среди многих пользователей. Второй способ: пользователю можно объяснить, что в компьютере есть две подсистемы памяти, одна постоянная, а другая временная; при выключении или при зависании компьютера содержимое временной памяти теряется, так что если документ будет нужен и позже, его надо перенести в постоянную память; перенос туда документа называется сохранением.

Проблема в том, что изначально пользователь не имел адекватной субъективной модели логики работы компьютера. Компьютер же не дает ему возможности самому построить модель, так что единственным ее источником может являться обучение. Это один из самых больших недостатков дизайна современных компьютеров. Показательно, что первый компьютер без разделения памяти на постоянную и временную (Palm Pilot) разошелся тиражом в миллионы экземпляров.

Таким образом, без адекватной субъективной модели пользователи фактически не способны научиться пользоваться системой. К сожалению, проектирование системы, для которой модель построить легко, есть дело сложное, так что придумать универсальный алгоритм невозможно. Существует, однако, одно простое правило: поскольку элементы, выполняющие несколько разных функций в зависимости от контекста, существенно усложняют построение субъективной модели, их лучше не создавать. Поэтому слишком много элементов управления обычно делать лучше, нежели слишком мало, во всяком случае, опасно ставить цель «во что бы то ни стало сократить количество элементов.

Метафора как основное средство обеспечения общей «понятности» системы. В большинстве случаев не следует заставлять пользователя создавать свою субъективную модель системы, а хорошо бы воспользоваться субъективными, уже готовыми моделями, которые были построены ранее по другому поводу, но могут использоваться для работы с ПИ. Таковым средством является метафора.

Самым простым примером метафоры в интерфейсе является устройство программ для проигрывания звуков на компьютере. Ведь вся аудио-техника имеет почти одинаковый набор кнопок: со стрелками (назад-вперед), с треугольником (воспроизведение), с двумя дощечками (пауза), с квадратиком (полная остановка) и красный кружок (запись). При этом обычно жизнь складывается так, что сначала человек научается пользоваться этими кнопками на материальных устройствах, а уж потом начинает пользоваться компьютером. Соответственно, при проектировании программы аналогичного назначения разумно скопировать существующую систему маркировки кнопок. Благодаря этому пользователям для работы с этой программой ничему не приходится учиться (и даже переучиваться). Сказанное выше можно проиллюстрировать примером, представленным на рис. 4.9.

Рис. 4.9. Главный экран ОС «Magic Cap»

Эта система, будучи вся построена на метафорах, приобрела большую популярность среди журналистов компьютерных изданий (они сразу все понимали). В то же время разработчики не смогли добиться такой же любви у других пользователей: они ее понимали, но отказывались с ней работать из-за ее неэффективности.

Другой пример использования метафоры. Сотрудники корпорации «Sony» разработали оригинальную концепцию интерфейса для переноса файлов с одного устройства на другое, получившую название «pick-and-drop» («взять и бросить» (рис. 4.10), по аналогии с «drag-and-drop»). Несмотря на то что сегодня существует множество способов отправки информации, обмен файлами между двумя цифровыми устройствами, находящимися рядом, зачастую затруднен. Применять электронную почту слишком громоздко, а справиться с настройками беспроводного соединения может далеко не каждый пользователь. Созданная система, в свою очередь, обеспечивает интуитивно понятный способ управления и предельно проста в применении.

Работает технология «pick-and-drop» следующим образом. Вначале необходимо выбрать файлы для передачи, ткнув в их ярлыки на экране специальным пером. Это перо имеет уникальную метку и распознается системой при приближении к дисплею. Далее нужно поднести указательное устройство к экрану компьютера-получателя, на котором при этом появится затененное изображение ярлыка. Последующее прикосновение к дисплею завершает операцию отправки файла, автоматически передающегося по локальной сети. При этом создается впечатление того, что файлы переносятся именно пером, в то время как в действительности перо выполняет функцию интуитивно понятного интерфейса. Более того, в настоящее время Sony адаптировала систему для работы с проектором. Документ, «поднятый» с экрана монитора, можно быстро отобразить на большом дисплее, просто щелкнув пером по проектору. Данная технология получила название «pick-and-beam» («взять и отобразить»).

Рис. 4.10. Технология «pick-and-drop» в действии

Вообще, метафора является отправной точкой всякого хорошего интерфейса. Обстановка на экране и способы взаимодействия с системой должны апеллировать к ситуации, хорошо знакомой пользователю. Так, оконный интерфейс задумывался как метафора рабочего стола с документами. Использованием метафоры достигается сразу несколько целей. Во-первых, пользователю легче понимать и интерпретировать изображение на экране. Во-вторых, ему не нужно каждый раз заглядывать в руководство, чтобы узнать, как выполняется то или иное действие. По крайней мере, некоторые действия должны естественно следовать из метафоры. В-третьих, у пользователя возникает чувство психологического комфорта, характерного для встречи с чем-то хорошо знакомым.

Ярким примером хорошего концептуального дизайна интерфейса (помимо некоторых компьютерных игр) может служить система дорожных знаков. Ее разработка не так проста, как может показаться на первый взгляд. Стоит обратить внимание на сочетание реалистических пиктограмм с абстрактными, на комбинирование многих знаков, висящих вместе, на словарь фонов. Кроме того, удалось решить почти неразрешимую задачу – знаки заметны и не портят красоту окружающей природы там, где эта красота есть. И главное, эта система хорошо работает и не требует от своих пользователей высшего образования. Во многих интерфейсных разработках идея дорожных знаков должна занимать значительное место.

Выбранная метафора может продиктовать все изобразительные решения дизайна интерфейса. Однако следует остерегаться фотографической похожести среды в компьютере с выбранной метафорой (тут есть аналогия с живописью). Все-таки компьютерная среда – искусственна, и полностью повторить все элементы взаимодействия из физического мира не удастся. А фотографическая похожесть может спровоцировать пользователя на то, чтобы пользоваться этой искусственной средой в точности как той, которую она напоминает. В первый раз, когда пользователь натолкнется на различие, он испытает психологический стресс, который может привести к полному отторжению системы.

Сказанное тесно примыкает к важнейшему принципу создания ПИ – балансу между интерактивными возможностями ПИ и сложностью его изобразительного ряда. Так же как при создании игр, главным является баланс между сложностью игры и ее увлекательностью, что занимает основное время, так и в интерфейсе должен обеспечиваться баланс между функциональными возможностями программы, возможностями манипуляции ею и ее изобразительным рядом. Простая программа не должна иметь сложное управление, это очевидно, но для нее исключается и слишком изощренная графика, что типично для многих ПИ, особенно для web-сайтов. Сложная картинка психологически готовит к сложной работе с программой. Из этого не следует, что у сложной программы должны быть изощренная графика и сложные пути взаимодействия. Лучше эту сложность вводить постепенно, подобно наращиванию уровней в компьютерных играх.

Расширенные средства визуализации в новой ОС Windows Vista значительно расширяют возможности метафорических решений ПИ и обеспечивают максимальную понятность информации. Эти средства предоставляют пользователю возможность видеть содержимое файлов, не открывая их (с помощью анимационных иконок и функции «Flip 3D» их увеличения в трехмерном пространстве), мгновенно находить приложения и файлы, эффективно переключаться между открытыми окнами и более уверенно ориентироваться в диалоговых окнах и мастерах. Гарантируется надежное взаимодействие ОС с пользователем: исчезли такие явления, как мерцание и перерисовка экрана, кратковременное прерывание работы, запаздывания и искажение изображения. Усовершенствованные общие элементы окон позволяют сосредоточиться на содержании, не отвлекаясь на оформление интерфейса, а визуальные элементы стали более информативными, интуитивными и полезными. Windows Vista предлагает пользователям выбор из четырех видов интерфейсов: простого, классического, стандартного и Windows Aero.

Отличительной особенностью интерфейса Windows Aero является оригинальный дизайн в виде прозрачного стекла, для которого реализованы такие эффекты, как отражения и плавная анимация. С помощью «стеклянных» окон (блестящее дизайнерское решение!) создается открытая многофункциональная среда, которая помогает сосредоточиться на содержимом, не отвлекаясь на окружающий интерфейс. Две новые функции интерфейса Windows Aero – Flip и Flip 3D – позволяют управлять окнами на рабочем столе, упорядочивая их непривычным (пока), но удобным способом.

В использовании метафоры есть и несколько подводных камней. Все-таки процесс взаимодействия с пользователем проходит не в реальном мире, а с помощью таких искусственных приспособлений, как экран, мышь и клавиатура. Поэтому где-то приходится метафору «подправлять». Кроме того, возможности мира внутри компьютера обычно шире возможностей физического мира, что может с успехом использоваться для более мощного интерфейса. Наконец, существует сложившаяся практика пользования компьютером у профессионалов, и эта практика кажется естественной создателям новых интерфейсов. Но есть у метафор и довольно серьезные недостатки, а именно:

1. Не для любой функциональности можно подобрать подходящую метафору, причем невозможно заранее узнать, есть ли хорошая метафора или нет, так что можно потратить время и ничего не найти. Это, как минимум, неэффективно.

2. Даже подходящая метафора может оказаться бесполезной, если ее не знает какая-то часть аудитории или ее трудно однозначно передать.

3. Почти всегда метафора будет сковывать функциональные возможности. Что делать, если проектируемая система обладает большим количеством функций, чем копируемый образец? Следование метафоре в таких условиях будет только вредить, поскольку совпадающим функциям будет учиться легче, а несовпадающим – сложнее (они будут иначе устроены). Зачем тогда система, почему бы пользователю не обратиться к исходному образцу?

4. Совершенно не обязательно, что сам по себе копируемый образец работает идеально. Если его копировать, окажется, что система не сможет быть эффективнее своего прародителя. Например, Adobe PageMaker во многом копирует традиционные верстальные гранки, наследуя их известность пользователям вместе с их ограничениями. Благодаря этому он стал чрезвычайно популярен. Однако через некоторое время появился не копирующий гранки QuarkXpress и отвоевал большую часть пользователей лишь потому, что работал более эффективно, не таская на себе груз старой идеи. Пользователи предпочитали потратить больше времени на обучение, зато выиграть в скорости работы. Парадоксальность ситуации в том, что сейчас гранки не используются вовсе, появилось поколение пользователей, которое никогда их не видело. Результат: обучаясь PageMaker, они должны дополнительно обучаться работе с гранками, которая им не нужна. Анализируя опыт успешных случаев применения метафор, можно вывести следующие правила:

• опасно полностью копировать метафору, достаточно взять из нее лучшее;

• не обязательно брать метафору из реального мира, ее можно придумать самому;

• эффективнее всего метафорически объяснять значение отдельных объектов: например, для графической программы слои можно представлять как положенные друг на друга листы стекла (этот пример подходит и для предыдущего пункта);

• если метафора хоть как-то ограничивает систему, от нее необходимо немедленно отказаться;

• почти всегда метафору можно использовать в документации, не перенося ее в интерфейс, при этом с тем же успехом. Достаточно просто написать, что «система во многом напоминает…», и нужный результат будет достигнут.

В заключение можно сказать, что применять метафору надо с большой осторожностью. Полезно помнить, что очень многие системы, базирующиеся на метафоре, проиграли конкурентам. Таков уже упоминавшийся PageMaker, таковой была ОС Magic Cap, оболочка MS Bob, в разработку которой было вложено множество денег, но которая не имела успеха, и т.д. Еще о метафорах будет сказано в разд. 6.5.2 при обсуждении возможностей мультимедиа в ПИ.

Свойства объекта, показывающие способ взаимодействия с ним. Другой составляющей понятности является использование (или придание) таких свойств объекта, которые сами показывают способ своего использования (это свойство в англоязычной литературе называется трудно переводимым словом affordance). Например, надпись «На себя» на двери не является таким свойством, а облик двери, который подсказывает человеку, что она открывается на себя, является. Польза заключается в том, что это позволяет пользователям обходиться без какого-либо предварительного обучения, обеспечивая самый эффективный и надежный путь обеспечения понятности (рис. 4.11).

Рис. 4.11. Дизайн кухонной плиты

Слева на рисунке представлен стандартный вариант, недостаток которого заключается в том, что невозможно умозрительно определить, какой диск управляет какой конфоркой. В центре и справа варианты, не имеющие этой проблемы, при этом работающие по-разному. В центральном примере расположение регуляторов повторяет расположение рабочих объектов (конфорок), благодаря чему неоднозначность исчезает. В правом примере каждому объекту соответствует отдельный регулятор. Эти два способа уничтожения неопределенности используются и в экранном дизайне.

Однако, в отличие от мира реального, единственным способом передать какие-то свойства объекта в ПИ является их визуализация. Это хорошо и естественно по отношению к визуальным характеристикам, но крайне сложно (и противоестественно) по отношению к другим (вкусовым, тактильным, обонятельным, проприоцептивным). Это ограничение приводит к тому, что доступными оказываются всего несколько способов передачи таких свойств, из которых основными являются четыре:

1) мэппинг (mapping), или повторение конфигурации объектов конфигурацией элементов управления (этот способ хорошо работает в реальном мире, но не очень хорошо – на экране, поскольку предпочтительнее прямое манипулирование);

2) видимая принадлежность управляющих элементов объекту;

3) визуальное совпадение свойств экранных объектов с такими же свойствами объектов реального мира (реальная кнопка в реальном мире предлагает пользователю нажать на нее, псевдотрехмерная кнопка в интерфейсе, являясь метафорой, предлагает нажать на нее уже по аналогии);

4) изменение свойств объекта при подведении к нему курсора (слабый аналог тактильного ощущения).

Стандарты и язык шаблонов в ПИ. Другой важнейшей составляющей понятности являются стандарты. Дело в том, что, если нельзя что-то сделать «самопроизвольно» понятным, всегда можно сделать это везде одинаково, чтобы пользователи обучались только один раз. Например, кран с горячей водой всегда маркируют красным цветом, а кран с холодной – синим. Частично это соответствует свойствам человеческого восприятия (красный цвет мы называем теплым, а синий – холодным), но в основном здесь работает привычка. Использование стандартов чрезвычайно эффективно, но, к сожалению, не слишком надежно. Дело в том, что стандарт очень хорошо работает, когда популярен, в противном случае не работает вовсе. Популярность же его может быть достигнута двумя способами: во-первых, он может иметь место во всех системах, во-вторых, он может иметь место внутри отдельной системы. Например, стандарт интерфейса MS Windows популярен почти во всех программах для Windows, именно поэтому его следует придерживаться. В то же время этот стандарт оставляет неопределенным очень многое, и это многое в разных системах трактуется по-разному. Бесполезно пытаться найти общий знаменатель во всех системах, гораздо эффективнее установить собственный стандарт, не противоречащий стандарту ОС, но дополняющий его. После этого надо строго придерживаться данного стандарта. Отсюда следует правило: последовательность в реализации интерфейса есть первое условие качества результата.

Конечно, разработка собственного стандарта дело довольно трудное. Но сказать, что она совсем уж невозможна, тоже нельзя. Во-первых, самое главное уже стандартизовано. Во-вторых, стандарт может развиваться параллельно процессу разработки, при этом поддержание стандарта не стоит почти ничего. Обширный же стандарт вполне окупает вложенные в него усилия ускорением обучения пользователей, не говоря уже о снижении стоимости разработки.

Развитие идеи стандартов привело к так называемому языку шаблонов. Существуют интерфейсные решения, хорошо работающие почти всегда. Эти решения можно систематизировать с помощью так называемого языка шаблонов. Идея языка шаблонов (pattern language) принадлежит человеку, далекому от разработки ПИ, – известному архитектору ХХ столетия Кристоферу Александру. Он предложил язык шаблонов в качестве средства для писания архитектурных решений, однако оказалось, что данная концепция может успешно использоваться в дизайне интерфейсов. Более того, на сегодняшний день последователей Александра гораздо больше среди специалистов в области человеко-компьютерного взаимодействия, чем среди архитекторов.

В применении к ПИ идею шаблонов можно описать так: это отнюдь не описание отдельных элементов управления, а описание способа, которым пользователь взаимодействует с системой или с элементом системы. Например, кнопка в интерфейсе Windows – это не шаблон, но неактивная (серая) кнопка является одним из способов реализации шаблона под названием «Отключенные Ненужные Элементы» (автор этого шаблона Дженифер Тидвелл). Причем один и тот же шаблон может быть использован и в высокоуровневых, и в низкоуровневых структурах. Главная сила шаблонов в их универсальности. Определенный шаблон может применяться и в традиционном ПО, и в web-сайте, и в промышленных панелях управления, и в видеоиграх, и в интерфейсе телефона. Есть ряд причин, стимулирующих использование шаблонов в ПИ:

• опытные дизайнеры стремятся систематизировать накопленные знания и опыт для ускорения работы. Такая систематизация выгодна (возможно, даже в большей степени) и начинающим дизайнерам. Использование языка шаблонов может избавить их от повторения ошибок, которые уже кто-то совершал раньше. В данном случае язык шаблонов работает как аккумулятор лучших идей и решений в области дизайна взаимодействия, поэтому важно, чтобы в создании шаблонов принимали участие как можно больше профессионалов;

• язык шаблонов представляет собой отличное средство коммуникации между различными специалистами, работающими над одним дизайнерским проектом: дизайнерами, программистами и др.;

• шаблоны помогают посмотреть на старые проблемы свежим взглядом, преодолеть косность мышления, когда кажется, что все лучшие решения придуманы и остается только копировать чужие (кстати, порой не самые лучшие) интерфейсные решения. Наверное, каждому приходилось произносить фразу «почему я не подумал об этом раньше?»;

• язык шаблонов может служить удобным и универсальным способом документирования интерактивных систем, включая высокоуровневые и низкоуровневые структуры.

Перечисленные достоинства языка шаблонов тесно связаны с настоятельной рекомендацией письменного обоснования (или хотя бы объяснения) всякого дизайнерского решения, о чем подробнее будет сказано в разд. 5.2.3. Язык шаблонов задает структуру для такого обоснования.

На сегодня, к сожалению, всеобщего единого универсального языка шаблонов для дизайна взаимодействия не существует. Тем не менее многие компании, которые занимаются дизайном интерфейсов, создают свои языки шаблонов для внутреннего использования. Создавая язык шаблонов, необходимо определить стандартную структуру описания его элементов (шаблонов). Существует несколько отличных друг от друга структур, разработанных разными авторами. Для примера мы рассмотрим структуру описания, которую использует Дж. Тидвелл [4]. Данная структура хороша как пример именно своей полнотой. Итак, описание каждого шаблона состоит из следующих пунктов:

1. Примеры – краткие примеры из различных областей применения дизайна взаимодействия: программного обеспечения, Интернета, панелей управления, бытовой техники и т.д.

2. Контекст – контекст, обстоятельства, в которых следует использовать данный шаблон. Например, для шаблона «Контрольная панель» контекст будет следующим: «Изделие должно обеспечить пользователю возможность либо изменить состояние артефакта, либо отдать команду что-то сделать».

3. Проблема – проблема, которую при помощи данного шаблона не обходимо решить. Для того же шаблона «Контрольная панель» примером проблемы является фраза: «Каким образом изделие может наилучшим образом показать, какие действия пользователь может совершить?»

4. Условия – дополнительные условия, которые необходимо принимать во внимание при нахождении решения проблемы. Обычно в этом пункте перечисляются 3-4 наиболее важных условия.

5. Решение – описание решения проблемы с учетом условий и контекста. Обычно дается краткое, сжатое описание решения, а затем идет объяснение.

6. Результатный контекст – обычно ссылки на другие шаблоны, ко-

торые рекомендуется использовать вместе с рассматриваемым. Вообще, описания шаблонов полны перекрестных ссылок друг на друга.

Начало увлечения языками шаблонов в человеко-компьютерном взаимодействии (даже мода на них) пришлось на середину 1990-х годов, и число сторонников этой идеи только растет. Поклонники концепции шаблонов создали целое направление в дизайне интерфейсов (его часто называют «Pattern Movement»). Подробности и литературу об этом направлении можно узнать на сайте http://patterns.usethics.ru/.

Некоторые общие принципы интуитивной «понятности» ПИ можно свести к следующим.

Полнота – все требования к интерактивному взаимодействию удовлетворяются при решении всех предусмотренных задач.

Управляемость – использованные медийные среды должны управляться пользователем. Должна обеспечиваться возможность всегда остановить процесс, повторить его ход, чтобы сосредоточиться на деталях, либо вывести последовательность процесса для его лучшего понимания. Средства управления должны быть хорошо известны пользователю и спроектированы с учетом зрительной аналогии с реальными физическими средствами.

Последовательность – важно соблюдать последовательность компоновки средств индикации и управления для сохранения хорошей ориентации пользователя. Одинаковые функции или элементы дисплея должны всегда быть на том же самом месте. Одинаковое действие должно всегда иметь тот же самый результат.

Избыточность – параллельное представление важной информации различными средствами мультимедиа, что улучшает восприятие этой информации.

Ориентация – пользователи должны всегда знать, где они находятся и по какому пути следует двигаться для получения нужной информации. Это может достигаться путем использования общего плана, списка разделов, указателей, навигационных диаграмм, круговых обзоров и т.д.