Моделирование пользователей в человеко-машинном взаимодействии

Несколько успешных примеров

Некоторые исследователи человеко-машинного взаимодействия были заинтересованы в моделировании пользователей потому, что здесь существует возможность того, что методы моделирования пользователей улучшат коллаборативную природу человеко-машинных систем. В контексте этой статьи модели пользователей определены как модели для таких систем, где пользователи находятся внутри вычислительного окружения. Их следует отличать от ментальных моделей, в которых пользователи имеют умозрительное представление о системах и задачах , во взаимодействии с другими (пользователями) и материальными предметами (модели D₁, D₂ и D₃ на рис. 4 являются примерами ментальных моделей). Далее следуют описания некоторых конкретных попыток моделирования пользователей и проблем в HCI.

Как завоевали Запад — один из первых успешных примеров моделирования пользователей

Система WEST [Бартон и Браун, 1982] представляет раннюю новаторскую попытку исследовать вопросы, связанные с моделированием пользователей. Это была обучающая подсистема для игры «How the West was Won» («Как был завоёван Запад»), она же была смоделирована в игре «Chutes and Ladders» («Желоба и Лестницы»). Игроки вращают три волчка и должны сформировать арифметическое выражение из трёх чисел, выпавших на волчках, используя символы операций +,-,*,/ и круглые скобки (так же игроки должны определять результат полученного выражения). Так, например, игрок, у которого выпали числа 2, 3 и 4, может составить выражение (2 + 3) * 4 = 20 и продвинуться на 20 шагов (в игре). Если при этом игрок попал в «город» (они расположены через каждые 10 шагов), он может переместиться в следующий город. Если он попал в «желоб», то должен скатиться назад, к его началу. Если игрок очутился там же, где и его противник, то противник отправляется назад на два города. Оптимальная стратегия в том, чтобы обрисовать все возможные ходы и выбрать тот, который продвинет вас вперёд как можно дальше от оппонентов. Однако, эмпирический анализ показал, что студенты не использовали эту стратегию. Они были гораздо более склонны полагаться на стратегию сложения меньших чисел и умножения на наибольшее.

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

В контексте WEST были исследованы следующие задачи моделирования пользователей:

общий контекст: компьютерные тренажёры ограничены в выводе заключения о недостатках студентов в том, что те делают в контексте игрового процесса или решения задачи.
инициатива и интрузивность: модель пользователя была применена (1), чтобы вынести суждение о том, когда давать полезные советы и делать релевантные комментарии студентам, чтобы не быть настолько назойливым, чтобы испортить удовольствие от игры; и (2) чтобы избежать опасности того, что студенты никогда не разовьют необходимые навыки контроля своего собственного поведения и поиска своих собственных ошибок потому, что инструктор немедленно указывает на эти ошибки.
релевантность: WEST развивала парадигму «обучение на задачах и примерах». Оценивая контекст ситуации и действуя соответствующим образом, студенты обучались тем способом, в котором они могли видеть практическую значимость задачи в то время, когда они были наиболее восприимчивы к представляемой идее. Основываясь на информации, содержащейся в модели пользователей, WEST использовала стратегии явного вмешательства и наставничества, чтобы позволять системе говорить «нужные» слова в «нужное» время.

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

Многофункциональные приложения

Многофункциональные приложения (см. пакет прикладных программ) используются, чтобы моделировать компоненты существующих миров и чтобы создавать новые миры. Это сложные системы, потому что они обслуживают потребности многочисленных и разнообразных популяций пользователей. Если бы вы спросили 100 различных пользователей о том, какие характеристики они хотели бы иметь в конкретном приложении, вы бы столкнулись с очень большим числом их. Проекты таких приложений должны решать три задачи: (1) неиспользуемая функциональность не должна мешать; (2) неизвестная существующая функциональность должна быть доступна и представляться в то время, когда она требуется; (3) широко используемой функциональности следует быть не слишком трудной для изучения, использования и запоминания.

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

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

Овалы на рис. 4 представляют знания пользователей о совокупности понятий системы. D₁ представляет понятия, которые хорошо известны пользователю, легко применимы и регулярно используемы им. D₂ содержит понятия, которые известны поверхностно и используются изредка, часто требуя систем пассивной помощи. Понятия, о существовании которых в системе пользователь предполагает, представляет D₃. Прямоугольник D₄ представляет функциональность, обеспечиваемую системой. Множество «D₃AND NOT D₄» представляет понятия в ментальной модели пользователя, от которых ожидается, что они существуют, хотя в настоящей системе они и не существуют. Чтобы разрешить пользователям добавлять эту функциональность, требуется поддержка программирования и модификации конечным пользователем [Фишер и Джирдженсон, 1990].

По мере того, как функциональность увеличивается до D₄‘, мало что становится достижимым для пользователей, если не существует механизмов помочь им соотнести дополнительную функциональность с их потребностями. Большинство пользователей не хотят становиться техническими экспертами — они лишь хотят видеть свои задачи выполненными. Часть множества D₄, которая не является частью D₃, представляет особый интерес для исследований в моделировании пользователей. Это системная функциональность, о существовании которой пользователи не знают. Для множества «D₃AND NOT D₄» доступа к информации (инициированное пользователем расположение информации, когда ощущается необходимость в ней для какой-то операции) недостаточно, а вот доставка информации (информации, предлагаемой системой, которая, как подразумевается, должна быть релевантной текущей задаче пользователя) является необходимой. Требуются критики и системы активной помощи, чтобы указать пользователям на функциональность, которая может быть полезна для их задач, и помочь им обойти «неоптимальные места», чтобы не застрять там.

Рис. 4 показывает шаблоны использования многофункциональных приложений, не принимая во внимание конкретные задачи пользователей. У них нет причин, чтобы беспокоиться о существовании дополнительных функций в D₄, если эти функции не соответствуют пользовательским задачам. Однако, если система способна обеспечивать функциональность D₄, релевантную их задачам, то желательно избегать наличия пользователей, которые не способны выполнить задачу, или выполнить её неоптимальным или подверженным ошибкам способом, потому что они не знают об этой функциональности. На рис. 5 серый прямоугольник T представляет информацию, релевантную текущей задаче пользователей, а точки представляют различные функциональные компоненты. Системы пассивной помощи, поддерживающие доступ к информации, могут помочь пользователям изучить функции, которые находятся в D₃ и T, в то время как активные интеллектуальные системы, поддерживающие доставку информации, требуются для функций, входящих в T, но не в D₃. Функциональность всех точек, включая и те, что в D₄ снаружи от T, часто предлагается специальными push-системами, такими, как системы «Знаете ли вы?» [Овэн, 1986] или «Совет дня» от Microsoft [Робертс, 1989]. Этот подход страдает от той проблемы, где понятия подбрасываются пользователям вне контекста.

Рис. 5. Функциональность и её релевантность текущей задаче

Экспертиза в многофункциональных приложениях: В многофункциональных приложениях больше не существует «экспертов» (пользователей, которые знают все о системе). В таких системах существование «эксперта», в лучшем случае, является признаком определённого контекста, а не персональным признаком. Различные пространства для экспертизы (определяемые индивидуальными интересами) проиллюстрированы на рис. 6. В этой многоядерной модели множество {D₁, U_i} означает область функциональности, которая хорошо известна пользователю U_i; например: U₁ знает о редакторе формул, U₂ знает об автоматизации почтовой рассылки, U₃ использует библиографическую подсистему для ссылок, а U₄ — знаком с инструментами совместной работы. Такое видение обеспечивает логическую обоснованность существования многофункциональных приложений в этом мире: поскольку от дизайнеров требуется писать программы для миллионов пользователей (в процессе разработки) для широкого круга различных задач, которые станут известны только в процессе эксплуатации.

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

Многофункциональные приложения создают сложные проблемы обучения, которые являются показательными для большого числа сложных систем. Как видно из вышеприведённых иллюстраций, никто не знает такие системы полностью, а пользователи овладевают некоторой основной функциональностью и изучают дополнительную функциональность по мере необходимости. Методы моделирования пользователей могут эффективно поддерживать обучение по требованию [Фишер, 1991], помогая пользователям выявлять возможности для изучения дополнительных функций, соответствующих текущей задаче, и избегать попадания в неоптимальные ситуации. Методы моделирования пользователей, основанные на журналируемых пользовательских данных, могут поддерживать общее для всей организации обучение многофункциональным системам [Линтон и др., 1999]. Работники с типичными знаниями стали так завалены информацией, что считают, что все труднее получить доступ к информации, которая им нужна — абсолютный объем иррелевантной информации затрудняет поиск информации, которая является релевантной. Эта проблема особенно важна в контексте систем корпоративной памяти, потому что большинство таких систем будут содержать слишком много информации для просмотра, чтобы быть эффективными. Проект «InVision» был ранним подходом к моделированию пользователей, в котором использовались подробно представленные модели знаний и информации, нужных членам организации [Касс и Стадник, 1992], чтобы улучшить организационное общение и организационное обучение.

Справочные системы, основанные на знаниях

Наше исследование, связанное с моделированием пользователей, пробовало решить проблемы, созданные многофункциональными приложениями. Активные справочные системы (такие, как Activist [Фишер и др., 1985], UNIX Consultant [Виленский и др., 1984] и EUROHELP [Уинкельс и др., 1991]) являлись ранней попыткой проанализировать поведение пользователей и вывести высокоуровневые цели из низкоуровневых операций [Горвиц и др., 1998; Нарди и др., 1998]. Activist — это активная справочная система для текстового редактора, подобного EMACS. Она поддерживала людей в постепенно возрастающем изучении элементов функциональности, релевантных их задачам (см. рис. 5). Она решала проблему, состоящую в том, что люди зачастую учатся путем получения ответов на вопросы, которые они никогда не задавали или были не способны задать. Activist способен иметь дело с двумя типами неоптимального поведения: (1) пользователь не знает сложную команду и использует «неоптимальные» команды, чтобы достигнуть цель, и (2) пользователь знает сложную команду, но не использует кратчайшую клавиатурную последовательность для её ввода. Конкретный специалист по планированию (который имеет дело с командой «удаление левой части слова») показан на рис. 7.

Рис. 7. Пример работы одного из специалистов по планированию системы Activist

Подобно наблюдателю-человеку, Activist был способен обрабатывать следующие задачи: (1) распознавать, что пользователь делает или хочет сделать; (2) оценивать, как пользователь пытается достичь цели; (3) строить модель текущего пользователя (накапливая информацию за длительные периоды использования), основанную на результатах оценки задачи; и (4) решать (зависит от информации в модели), когда и как вмешаться.

Распознавание и задача оценивания в Activist'е были возложены на 20 различных специалистов по планированию. Как пример системы, моделирующей пользователя, Activist моделировал пользователей в ходе «непосредственного наблюдения» за действиями, а не делая предположения [МакКеон, 1990]. В противоположность системе WEST, Activist действовал в гораздо более разомкнутом окружении, создающем проблему выявления целей пользователя из низкоуровневых взаимодействий. Основная философия проекта Activist позволяла пользователям игнорировать советы, даваемые системой; если они неоднократно игнорировали информацию, предоставляемую определенным специалистом по планированию, то Activist выключал его.

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

Среды проектирования и критикующие системы

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

В дальнейшем мы приняли этот подход в нашем исследовании, разрабатывая проблемно-ориентированные среды проектирования [Фишер, 1994]. Это окружения, которые моделируют определённые области задач (напр. компьютерные сети, пользовательские интерфейсы, кухни [Накакоджи, 1993] и проект голосового диалога [Самнер, 1995]), позволяя проектировщикам заниматься аутентичными задачами из их собственного опыта соответствующей работы. Проблемно-ориентированные среды проектирования позволяют компьютерам быть «невидимыми», давая возможность проектировщикам взаимодействовать с понятиями, представлениями и инструментами из определённой предметной области. Приводя объекты ближе к концептуальному миру их пользователей, предметная ориентированность этих сред делает многофункциональные приложения более практичными, более полезными и более изучаемыми.

Часть 3. Адаптивные и адаптируемые системы

CC-BY-CA Анатольев А.Г., 26.12.2016