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

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

• обеспечивает на более поздних стадиях разработки, модернизации и/или эксплуатационного обслуживания критический анализ решений, конкретных альтернатив, которые исследовались, и причин того, почему одна альтернатива была предпочтена другой;

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

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

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

В области человеко-компьютерного взаимодействия объяснение дизайнерских решений ПИ особенно важно по следующим причинам:

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

2. Даже если оптимальный вариант для конкретного ПИ действительно существует, область возможных альтернатив настолько велика, что вряд ли разработчик рассмотрел их все. Поэтому важно, чтобы были указаны те конкретные варианты (альтернативы), которые были исследованы. Это может пригодиться позже, когда кто-либо будет совершенствовать данный ПИ и анализировать какие-то иные варианты.

3. Юзабилити интерактивной системы очень зависит от контекста ее использования. Самый прекрасный графический интерфейс бесполезен, если конечный пользователь не имеет высококачественного графического дисплея или устройства прямого управления курсором (мыши, например). Описание всех обстоятельств работы, ее контекста поможет позже, когда будут разрабатываться новые программы. Если контекст остается тем же самым, то старое объяснение может быть принято без пересмотра. Если контекст как-то изменился, старое объяснение может быть проанализировано, и, возможно, это приведет к пересмотру выбора вариантов.

Заказчик, к примеру, совершенно не обязан быть ни ценителем дизайна, ни его знатоком, он, как правило, просит сделать то, что уже у кого-то видел: «Вот у корпорации N хороший интерфейс, сделайте мне так же». Однако, чтобы сделать «как корпорация N», нужно, как минимум, знать, почему N сделал именно так, а не иначе, что он знал, чего хотел и каких ошибок избегал. И если создатели ПИ «корпорации N» оставили письменное объяснение своих решений, ваша задача станет вполне решаемой.

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

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

Объяснение, ориентированное на последовательность разработки, базируется на предложенной Риттелем (Rittel) еще в 1970-х годах форме представления процесса разработки, названной информационной системой, основанной на результате (Iissue-Based Iinformation System – IBIS). Эта информационная система представляет собой иерархическую структуру объяснения дизайна. Какой-то ключевой вопрос, положение образуют корневой узел структуры, к которому обращены позиции и их аргументы.

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

Отметим, что аналогичная визуализация имеет место в широко известной диаграмме причин и воздействующих факторов или диаграмме Исикавы, т.е. схеме, показывающей отношения между показателем качества и воздействующими на него факторами. Диаграмму Исикавы (иногда – Ишикавы) называют еще «рыбий скелет» или «дерево проблем» (разработчик – японский ученый Каору Исикава).

Рис. 5.6. Структура объяснения дизайнерских решений в форме IBIS

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

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

Объяснение, ориентированное на структуру разработки, основано на апостериорном анализе рассматриваемых вариантов. Такой подход базируется на трех основных составляющих каждого из решений – вопросов, обстоятельств и критериев, сокращенно – QOC (Questions, Options, Criteria). Область решений сначала структурируется некоторым набором ключевых вопросов, ответы на которые содержатся в конкретных решениях. Понятие «ключевой вопрос» здесь аналогично понятию «ключевое положение, вопрос» системы IBIS (рис. 5.7). В данной системе основное внимание уделено общности критериев. Если, например, надо решить, какой способ отображения – кнопки или меню – более адекватен для пользователя, то такой критерий, как необходимость постоянного отображения всех возможных действий, поможет решить проблему.

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

Другой вариант структурно-ориентированного подхода называют «язык представления решений», сокращенно – DRL (Decision Representation Language). Он несколько расширяет средства представления объяснений (и решений) по сравнению с подходом QOC и содержит формальные семантики. Наличие последних позволяет формализовать описание, что очень важно при больших объемах информации для компьютеризации просмотров. С помощью подхода DRL можно, например, отследить зависимости между разными ключевыми проблемами так, что при изменении в объяснении определенного дизайнерского решения это будет автоматически распространено на зависимые решения тоже.

Рис. 5.7. Объяснение в форме QOC

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

Объяснение, ориентированное на психологию пользователя, базируется на том известном положении, что область реального применения любого нового продукта превышает (и чаще всего значительно) те потребности, которые данный продукт изначально был призван удовлетворить. Скажем, одна из первых электронных таблиц VisiCalc разрабатывалась как средство автоматизации табличных вычислений. Но уже через сравнительно короткий период (около 10 лет) электронные таблицы использовались во всех типах финансовой отчетности, в представлении и анализе разных вариантов развития финансовых ситуаций, форматах отчетности и даже как обязательный формат программных языков. С расширением числа реальных областей применения росли и возможности новых версий, призванные удовлетворить потребности, о которых создатели первых VisiCalc даже не подозревали. Другой пример – текстовые процессоры, изначально призванные просто заменить пишущую машинку, а сейчас способные выполнять весьма обширный круг задач. Сегодня области применения электронных таблиц и текстовых процессоров объединены, по сути, в единую область.

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

• Что я могу делать? Иначе, какие возможные операции или функции позволяет выполнять эта программная среда?

• Как это работает? Конкретнее, что делают различные функции?

• Как я могу это делать? Иначе, если я знаю операции, которые я хочу выполнить, как я могу их запрограммировать?

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

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

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

Контрольные вопросы

1. Что такое юзабилити-тестирование, когда оно проводится?

2. Каковы цели юзабилити-тестирования на разных этапах разработки ПИ?

3. Основные характеристики юзабилити-тестирования согласно стандарту ISO 9241 и их показатели.

4. Возможные метрики юзабилити и их содержание.

5. Варианты таксономии понятия «юзабилити».

6. Процедура подготовки и проведения юзабилити-тестирования.

7. Основные направления анализа данных юзабилити-тестирования.

8. Методики юзабилити-тестирования, их возможности, сравнительный анализ.

9. Контрольные списки, их содержание и место в разработке ПИ.

10. Последовательность и содержание этапов разработки ПИ.

11. Цели и возможности прототипирования ПИ.

12. Требования к прототипу на разных этапах разработки ПИ.

13. Какие существуют версии прототипа? Их характеристики, сравнительный анализ.

14. Программные средства создания прототипов, их сравнительные возможности, достоинства и недостатки.

15. Причины целесообразности письменного объяснения дизайнерских решений ПИ.

16. Методы письменного объяснения дизайнерских решений ПИ.

Литература

Основная

1. Нильсен Я. Элементарные основы юзабилити. Авг. 2003 г. www.i2r.ru/ static/255/out_20415.shtml

2. Usability в России. www.usability.ru/

3. Сполски Дж. Руководство по UI дизайну для программистов: Пер. с англ. 2000. http://russian.joelonsoftware.com/uibook/chapters/1.html

4. Головач В.В. Дизайнер, проектировщик, юзабилити-специалист. Окт. 2006 г. http://www.usethics.ru/lib/types/index.shtml

5. Головач В.В. Прототипирование интерфейсов в Adobe InDesign. Окт. 2004 г. http://www.usethics.ru/lib/types/index.shtml

6. Борецкий Ф. Друзья и враги пользователя InDesign. Май 2005 г. http://www. usethics.ru/lib/types/index.shtml

7. Филатова Е. Руководство пользователя для пользователя. Июль 2006 г. http://www.usethics.ru/lib/types/index.shtml

8. Кирсанов Д. Веб-дизайн. – М.: Символ-Плюс, 2001.

9. Вукс Т. Основы web-дизайна. Интерфейс, понятный посетителю сайта. 2005 г. www.i2r.ru/static/255/out_22172.shtml

10. http://www.uie.com/

11. Кристофер Ш. Создание web-страниц средствами CSS. – М.: КУДИЦ-ОБРАЗ, 2003.

12. Norman D. Design of Everyday Things (formerly – Psychology of Everyday Things). – New York: Basic Books, Inc. Publishers, 1988.

Дополнительная

13. Porter J. The Freedom of Fast Iterations: How Netflix Designs a Winning Web Site. Published: Nov. 14. 2006 г. http://www.uie.com/articles/fast_iterations/

14. Wroblewski L. Visible Narratives: Understanding Visual Organization. Jan. 20, 2003 г. http://www.uie.com/articles/visible_narratives/

15. CarrolM., Moran T.P. (Ed.). Design Rationale: Concepts, Techniques and Use. – Lawrence Erlbaum, 1996.

16. Sommerville. Software Engineering. 6th еd. – Addison-Wesley, 2000.

17. Lee J., Lai K.-Y. What's in a design rationale? Human-Computer Interaction, 6(3 4): 251-80, 1991.

18. MacLean A., Young R.M., Belotti V.M.E., Moran T.P. Questions, options, and criteria: elements of design space analysis. Human-Computer Interaction, 6 (3 4): 201-50, 1991.

19. Silvers T.J., Voorheis Ch.M., Anders S.H. Rapid Prototyping With Microsoft PowerPoint: Page Linking And Animation. Dayton, OH, Proceedings of the Human Factors and Ergonomics Society. 48th Annual Meeting, 2004. P. 1011.

20. McGee M., Rich A., Dumas J. (Oracle Corporation). Understanding The Usability Construct: User-Perceived Usability. Proc. of the Human Factors and Ergonomics Society. 48th Annual Meeting, 2004. P. 907.

21. Whiteside J., Holtzblatt B. and K. Usability Engineering: Our Experience and Evolution // M. Helander (Ed.). Handbook for Human-Computer Interaction. -North-Holland, 1988.

22. Diez M., Sherry L., Deborah A., Boehm-Davis. Rafiv: A Method For Cognitive Usability Analysis. Proc. of the Human Factors and Ergonomics Society. 48th Annual Meeting, 2004. P. 396.

23. Diez M. Why A Consumer Electronic Device Is Difficult To Use. Proc. of the Human Factors and Ergonomics Society. 48th Annual Meeting, 2004. P. 927.

24. Беккер Л. 90% всех юзабилити-тестов – бесполезны: Пер. с англ. http:// HYPERLINK «http://www.i2r.ru/static/255/out_21891»www.i2r.ru/static/255/out_21891. html

25. http://www.arrtlebedev.ru/kovodstvo/

26. http://www.bio.ru/stat/S5.html

27. http://research.rbc.ru/rev_short/921225.shtml

28. http://www.dist-cons.ru/modules/qualmanage/section3.html

ТЕМА 6. СРЕДСТВА МУЛЬТИМЕДИА ПРИ РАЗРАБОТКЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

Изучаемые вопросы:

• Определение и понятие мультимедиа.

• Разные формы представления информации, их целесообразность.

• В каких случаях предпочтительнее использовать текст, чем другие формы представления информации.

• Основные правила текстового изложения материала.

• Правила расстановки ссылок в тексте.

• Преимущества и недостатки цветового кодирования; требования к цветовому кодированию.

• Графическое представление данных, основные типы графических описаний.

• Фотографии (или изображения), видео, анимация – их возможности, целесообразность применения, преимущества и недостатки, основные требования.

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

• Правила интеграции звуковой и визуальной информации.

• Роль и основные средства навигации.

• Разновидности и стили метафор для обеспечения навигации.

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

• Основные правила навигации, пути и средства их выполнения.

• Типичные навигационные решения в web-сайтах.

• Ориентация в процессе поиска, средства и методы достижения.

6.1. Понятие «мультимедиа» и общие принципы разработки мультимедийных приложений

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

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

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

Одна и та же информация может быть представлена в различной форме (модальности): текстом, речью, графикой, изображением или видео. Но качество, доступность, полнота и возможность интерактивного управления могут быть при этом разными. Поэтому полезно руководствоваться некоторыми общими принципами, показанными в табл. 6.1.

Таблица 6.1

Целесообразность представления информации в визуальной либо звуковой форме

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

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