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

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

1. Классы интерфейсов и их функциональные возможности.

2. Принцип WYSIWYG и функции, которые он обеспечивает.

3. Преимущества интерфейсов прямой манипуляции.

4. WIMP-интерфейс, его составные части, функции каждой из частей.

5. Преимущества трехмерного интерфейса.

6. Основные признаки виртуальной реальности.

7. Характеристики ПИ, обеспечивающие виртуальную реальность.

8. Принципы создания объемных изображений, их сравнительная оценка, варианты технической реализации.

9. Как изменялись формат данных, мерность представления пространства, способ и средства взаимодействия в процессе эволюции человеко-компьютер-ного взаимодействия?

Литература

Основная

1. Человеческий фактор / Под ред. Г. Салвенди: В 6 т.: Пер. с англ. – М.: Мир, 1991. Т. 1, 4, 5.

2. DixA., Finlay J. (Eds). Human-Computer Interaction. – Printed in Great Britain, Glasgow. Publisher – Prentice Hall: 3rd ed. 2004. Ch.20

3. Handbook of Human Factors and Ergonomics / Ed. by Gavriel Salvendy. 2nd Ed. Purdue University. John Wiley Sons, Inc. – N.Y., 1997.

4. ISO/DIS 9241-13: User guidance.

5. ISO/DIS 9241-14: Menu dialogues.

6. ISO/DIS 9241-15: Command language dialogues.

7. ISO/DIS 9241-16: Direct manipulation dialogues.

8. ISO/DIS 9241-17: Form-filling dialogues.

9. ISO/IEC 10741-1 Dialogue interaction – Cursor control for text editing.

10. ISO/DIS 13407 Human-centered design processes for interactive systems.

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

1. www.mebelstyle.ru/news/2003/10/09/01.html#top

2. www.cnews.ru/newtop/index.shtml?2005/04/14/177238

3. www.cnews.ru/newtop/index.shtml?2005/03/14/175822

4. www.cnews.ru/newtop/index.shtml?2004/08/10/162202

5. www.cnews.ru/newtop/index.shtml?2004/12/30/171759

6. www.cnews.ru/news/top/index.shtml?2005/06/14/180328

7. www.cnews.ru/cgi-bin/redirect.cgi?http://jeremynewton.com

8. www.aist.go.jp/aist_e/latest_research/2006/20060210/20060210.html

9. www.cnews.ru/news/line/index.shtml?2004/11/11/167957

10. www.polit.ru/event/2006/02/20/3d_monitors.html

11. www. io2technology.com/salesinquiry

12. www.seereal.com/

13. www.grundig.com/

14. www.optics.com/

15. www1.cs.columbia.edu/graphics/projects/mars/mars.html

16. www.epindustries.com/4Dvideo/index.html

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

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

• Понятие модели пользователей.

• Типы моделей пользователей и их характеристики.

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

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

• Пользовательские профили, их содержание и цель составления.

• Правила описания портрета потенциального пользователя (персоны).

• Метод GOMS и его описание.

3.1. Общие положения

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

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

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

Как узнать характеристики будущего пользователя (построить его модель)? Самым общим методом является опрос людей, являющихся (как вы надеетесь) вашими потенциальными пользователями. Если разрабатываемая программа предназначена для широкого круга пользователей (скажем, редактор web-страниц), можно выбрать наугад пять коллег, друзей, родственников, рассказать им в общих словах о назначении вашей программы. Затем предложите ситуацию: «Ты работаешь над web-страничкой. У тебя есть файл с картинкой под именем Picture1. JPG. Ты хочешь вставить эту картинку на свою страницу. Как ты себе представляешь свои действия?» Далее полезно задавать вопросы по ходу процесса: «Куда делась картинка? Если теперь ты удалишь свой файл Picture1.JPG, сможет ли страница по-прежнему показывать твою картинку?» Можно спросить, где хранятся ярлычки картинок. Конечно, некоторые пользователи не имеют об этом представления и никогда об этом не задумывались, другим все равно, но когда будет обработано много различных мнений, более отчетливо станет решение, которое вас устроит. Просто просите их думать вслух, задавайте вопросы, которые предполагают альтернативные варианты ответов, и попытайтесь построить модель пользователя. Самый часто встречающийся вариант ответа и есть, как правило, нужная характеристика пользователя, важнейшая часть его модели. Так, постепенно варьируя задания и вопросы, можно построить более или менее адекватную модель пользователя.

Следующий этап – проверка сделанных предположений, т.е. предварительной модели. Проверка предположений предполагает обычно создание прототипа ПИ (хотя бы бумажного на этом этапе – см. разд. 4.2.1.) и его апробацию, т.е. первые варианты его юзабилити-тестирования. Попросите группу приглашенных вами пользователей комментировать свои действия во время решения поставленных задач. Цель тестирования заключается в том, чтобы понять, чего они ожидают от программы. Предположим, вы дали задание: вставить картинку. Если вы увидите, что человек пытается мышью затащить картинку в документ, вы поймете, что вам следует поддержать технологию drag-and-drop. Если он остановит курсор на кнопке Вставка панели инструментов, вы поймете, что было бы полезно разместить в этом меню опцию Картинка. Когда же он на панели инструментов будет пытаться заменить слова Тimes New Roman на Вставить картинку, вы сообразите, что вам попался редкий персонаж, который ищет командную строку, будучи совсем не знаком с графическими интерфейсами.

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

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

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

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

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

Второй базируется на когнитивных моделях, т.е. акцент делается на процессах восприятия, памяти, мышления, психологических особенностях. Эти модели представлены:

• иерархической моделью, представляющей задачи пользователя и структуру целей;

• лингвистическими моделями, представляющими единый язык человека и программы;

• физическими моделями, представляющими моторные навыки человека.

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

3.2. Пользовательские профили

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

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

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

Пример профиля

1. Социальные характеристики:

• пол;

• возраст;

• образование;

• уровень занимаемой должности;

• использует ли компьютер только он и (или) другие (члены семьи, коллеги).

2. Навыки и умения:

• общий стаж работы с компьютером;

• стаж использования Интернета;

• уровень теоретических знаний об устройстве Интернета;

• уровень практических знаний о внутреннем устройстве Интернета (что конкретно умеет делать).

3. Рабочая среда:

• тип подключения к Интернету;

• размер монитора;

• экранное разрешение;

• быстродействие компьютера;

• используемая операционная система;

• язык операционной системы;

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

• количество времени, проводимого ежедневно за компьютером на работе;

• количество времени, проводимого ежедневно за компьютером дома.

4. Мотивационно-целевая среда:

• цели пользователя вообще;

• мотивация к обучению работе с программой (сайтом).

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

• кто они;

• возможно, они не похожи на вас;

• поговорите с ними;

• наблюдайте за ними;

• используйте ваше воображение.

Кто они

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

Возможно, они не похожи на вас

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

Поговорите с ними

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

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

Наблюдайте за ними

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

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

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

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

Используйте ваше воображение

Даже если бы вы хотели привлечь множество потенциальных пользователей к вашей разработке, это не всегда будет возможно. Это может быть слишком дорого, или они, возможно, не смогут уделить вам много времени (например, консультант больницы), может быть и так, что их слишком много (например, если вы создаете web-сайт). Однако, не имея возможности привлечь всех реальных пользователей, вы можете, по крайней мере, пробовать вообразить их опыт. Но это довольно опасно. Было бы легко думать: «Если бы я был складским менеджером, я сделал бы то и это». Следует понять не то, что вы бы сделали на месте пользователей, а то, что они сделают. Это требует использования некоторого метода. Вообразите себя складским менеджером. Какой смысл имеет для него опция меню «undo»?

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

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

Ниже приведен пример персонажа Ольги – складского менеджера.

Ольге 37 лет. Она была менеджером склада в течение пяти лет и работала в компании «Воздушные замки» в течение 12 лет. Она не поступила в университет, но училась по вечерам в бизнес-школе. У нее двое детей в возрасте 15 и 7 лет, она не любит работать поздно. Она закончила часть вводного компьютерного курса несколько лет назад, но была вынуждена прервать, когда была назначена на должность, и больше не могла позволить себе тратить столько времени. У нее отличное зрение, но движения правой руки немного ограниченны после несчастного случая на производстве три года назад. Она работает с энтузиазмом, проявляет готовность как делегировать ответственность, так и брать ее на себя, если от управления компании поступает соответствующее распоряжение. Однако она ощущает беспокойство от плана введения новой компьютерной системы.

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