Планшетный компьютер самостоятельно переключает ориентацию экрана в зависимости от положения устройства в руках владельца, программы геолокации ориентируются на текущее местоположения пользователя и адаптируют уровень масштабирования карты в зависимости от актуальной скорости движения, фоновая подсветка телефона включается при использовании его в темноте — всё это примеры технологий, «знающих» об окружающей их среде и контексте применения устройства.
Еще менее 10 лет назад такие функции не являлись широко распространенным явлением и с ними можно было ознакомиться только на прототипах устройств, которые находились в исследовательских лабораториях, работающих над контекстно-зависимыми компьютерными технологиями (Context-Aware Computing).
Рисунок 1: переключение ориентации экрана iPad является хорошим примером контекстно-зависимых технологий.
1. Вступление
Когда разработчик ставит себе цель спроектировать приложение, устройство или систему, которое будет простым в эксплуатации, важно понять контекст использования будущего продукта. В случае контекстно-зависимых технологий теперь стала доступной возможность рассматривать ситуацию использования не только в процессе проектирования, но и в режиме реального времени, когда устройство находится в эксплуатации. В сфере человеко-компьютерного взаимодействия (Human-Computer Interaction, HCI) традиционно существует стремление понять пользователя и контекст применения продукта, что служит созданию проектов, поддерживающих основные ожидаемые варианты и ситуации использования устройства/сервиса.
С другой стороны, внедрение контекстно-зависимых технологий вызывает кардинальные изменения: мы можем обеспечивать более одного контекста использования, каждый из которых в равной степени будут оптимальным. Во время выполнения задачи в реальном времени — когда пользователь взаимодействует с приложением — система может определить, что представляет собой текущий контекст и предоставить пользовательский интерфейс, специально оптимизированный для этого контекста. В сфере контекстно-зависимых технологий работа по проектированию пользовательского интерфейса обычно становится более сложной, поскольку количество ситуаций и контекстов, в которых система будет применяться, обычно увеличивается. В отличие от традиционных систем, здесь не разрабатывается один единственный — либо ограниченный набор их — контекст использования; наоборот, проектируется несколько контекстов. Преимущество такого подхода заключается в том, что разработчики могут предоставить пользовательские интерфейсы (user interface, UI), оптимизированные для целого ряда возможных контекстов.
Рассмотрим следующий пример: предположим, что вас попросили спроектировать пользовательский интерфейс для наручных часов. Проведя предварительные исследования, вы узнаете, что люди будут использовать интерфейс в помещении и на открытом воздухе, как в темноте, так и при ярком солнечном свете; пользователи будут применять UI как на бегу, пытаясь не опоздать на поезд, так и скучая на лекции. Как хороший дизайнер вы получаете множество идей для разработки захватывающего пользовательского интерфейса для каждой ситуации: например, когда пользователь бежит, чтобы успеть на поезд, UI (в данном случае — циферблат), должен показывать время, выделяя минуты и секунды при помощи очень крупного шрифта. С другой стороны, в то время, когда пользователь посещает лекцию, пользовательский интерфейс должен отображать текущее время очень мелким шрифтом, дополнительно предоставляя владельцу часов возможность читать на циферблате забавные цитаты.
В ходе традиционного процесса разработки вы вынуждены будете осознать, что после создания своих эскизов и конструкторской документации вам предстоит решить, какую из ваших идей применить для пользовательского интерфейса. Вы поймете, что поддержка всех возможных ситуаций в одном дизайнерском решении работать не будет. Типичным результатом применения традиционной методики разработки станет компромисс, при котором большая часть идей, изначально придуманных вами, чаще всего будет потеряна.
Однако, если вы воспользуетесь методикой Context-Aware Computing, то вы сможете создать часы, ориентированные на контекст применения, в которых вы объедините все ваши оптимизированные под конкретные ситуации разработки в одном конструктивном решении. Если вы спроектируете свои часы так, чтобы они могли распознавать каждую из ситуаций, обнаруженных вами в предварительных исследованиях (например, пользователь бежит, чтобы успеть на поезд, посещает лекцию и т. д.), то ваши часы могли бы переконфигурировать себя на основе распознанного контекста. На рисунке 2 показан проектный эскиз «контекстно-ориентированных» часов.
Рисунок 2: проектные эскизы, иллюстрирующие идеи визуализации времени в различных контекстах. Левый фрагмент: пользователям, спешащим занять места в поезде, облегчили просмотр времени в минутах. Посередине: визуализация для скучных лекций и совещаний — показывает обратный отсчет времени, оставшегося до конца мероприятия, и некоторую информацию для вовлечения пользователя. Справа: визуализация, которая предоставляет только очень грубое понятие о времени, подобно информации, которую вы получаете от уровня солнечной освещенности — этот вариант, пригодится, например, для ситуации общения с друзьями, когда время не играет особого значения. Пользуясь пониманием контекста, вы можете создать продукт, объединяющий все три визуализации, и выбрать наиболее подходящий вариант, соответствующий опознанным условиям применения устройства/сервиса.
Приведенный выше пример свидетельствует о существенном преимуществе контекстно-зависимых вычислительных систем, поскольку в случае их применения увеличивается свобода проектирования. В то же время компьютерные системы становятся сложнее, а их разработка и имплементация зачастую становится гораздо более трудной задачей. В данном посте мы расскажем об основах создания продуктов, ориентированных на контекст, и обсудим, как эти концепции могут способствовать проектированию качественного пользовательского опыта.
2. Осведомленность о контексте
В первые дни существования вычислительных технологий контекст, в котором использовались цифровые системы, определялся конкретным местом, где были установлены компьютеры (см. рис. 3). Персональные компьютеры использовались в офисных помещениях или в фабричных цехах. Контекст использования не менялся радикально, и в ситуациях, связанных с компьютером, наблюдались незначительные различия. Следовательно, не существовало и необходимости адаптироваться к различным средам. Многие традиционные методы в дисциплине человеко-компьютерного взаимодействия — такие, как контекстный опрос или анализ задач — возникли именно в этот период, и поэтому их наиболее просто использовать в ситуациях отсутствия постоянных изменений. С появлением мобильных компьютеров и распространением повсеместных вычислений положение дел изменилось. Пользователи носят компьютеры с собой и используют их во множестве самых различных ситуаций (см. рисунок 4).
В начале эпохи мобильных вычислений, в конце 80-х и 90-х годов, центральной темой дискуссий был вопрос, как сделать мобильность прозрачной для пользователя, автоматически предоставляя одинаковый опыт в любой точке мира. Здесь прозрачность означала, что пользователь не должен был заботиться об изменениях в окружающей среде и мог полагаться на одинаковую функциональность, не зависящую от окружения.
В начале 90-х годов исследование повсеместных вычислений в лабораториях Xerox PARC вызвало сдвиг в мышлении. Помимо обеспечения прозрачности функциональных возможностей — таких как поддержка сетевого подключения на всей территории кампуса, не требующая от пользователя, чтобы он вручную передавал свои данные между различными сетями, — исследователи обнаружили возможность применить контекст использования в качестве ресурса, к которому могут быть адаптированы системы. В своем докладе 1994 года на семинаре по мобильным вычислительным системам и приложениям Билл Шилит (Bill Schilit), исследователь из лаборатории Xerox PARC, предложил концепцию контекстно-зависимых вычислений и описал ее следующим образом:
«Такое программное обеспечение, зависимое от контекста, адаптируется к месту использования, присутствию поблизости людей, других компьютеров и доступных устройств, а также к изменениям этих вещей с течением времени. Система, обладающая подобными возможностями, может исследовать вычислительную среду и реагировать на изменения в этом окружении».
Основные идеи заключаются в том, что мобильные устройства могут предоставлять разный опыт в различных условиях — там, где контекст имеет самое прямое отношение к местоположению устройства.
Большая часть первоначальных исследований контекстно-зависимых вычислений, следовательно, была сосредоточена на системах, ориентированных на местоположение. В этом смысле широко используемые сегодня автомобильные спутниковые навигационные системы являются контекстно-зависимыми. Однако контекст — это нечто большее, чем местонахождение объекта.
Рисунок 3 A-B-C: на начальном этапе цифровой эпохи контекст определялся местоположением компьютера, поскольку ЭВМ фактически являлась рабочим местом пользователя. Позже компьютеры стали устанавливаться в определенных местах для решения конкретных задач, и, следовательно, контекст конкретно определялся местоположением вычислительной машины. Персональные компьютеры использовались в офисах или в заводских цехах.
Рисунок 4 A-B: даже в ранние годы мобильных вычислений, когда ноутбуки считались чем-то вроде компьютеров, которые можно в одиночку переносить с места на место, пользователи могли выбирать условия для работы. С распространением мобильных и карманных компьютеров и развитием повсеместных вычислений ситуация изменилась еще более радикальным образом. Пользователи берут компьютеры с собой и используют их во множестве различных ситуаций, имеющих место в реальном мире. В следующий раз, когда вы отправитесь на прогулку, обратите внимание на разнообразие сценариев использования мобильных устройств.
2.1 Пример 1: спутниковый навигатор как контекстно-зависимая система
В спутниковой навигационной системе (Satellite Navigation System; SatNav) текущее положение является основным контекстуальным параметром, который используется для автоматической настройки визуализации (например, карты, стрелки, дороги) в соответствии с нынешним местонахождением пользователя (см. рисунок 5). Однако, рассматривая современные коммерческие спутниковые навигаторы, можно заключить, что в них используется гораздо больше контекстной информации и большая часть визуализаций подверглась изменениям. В дополнение к текущим координатам в системе глобального позиционирования (GPS; Global Positioning System) контекстуальные параметры могут включать в себя время суток, условия освещенности, ситуацию с дорожным движением по расчетному маршруту или предпочитаемые пользователем географические локации. Помимо визуализации и включения или выключения подсветки, навигационная система может рассчитывать маршрут с учетом влияния контекста, например, чтобы избегать улиц с потенциально оживленным движением в это время суток.
Рисунок 5 A-B: навигационные устройства стали обычным явлением и широко используются как автомобилистами, так пешеходами. На рисунке 4A показано навигационное приложение TomTom, работающее на смартфоне Nokia N95. На рисунке 4B показан сервис Google Maps, активированный на другом устройстве Nokia. Системы спутниковой навигации, вероятно, являются наиболее распространенными компьютерными приложениями, ориентированными на контекст.
2.2 Пример 2: автоматические переключатели освещения в качестве контекстно-зависимой системы
В быту обычным явлением стали автоматические системы управления освещением, устанавливаемые в подъездах жилых домов и коридорах гостиниц. Эти устройства также можно рассматривать как простые контекстно-зависимые системы. В качестве контекстуальных параметров учитываются текущее состояние освещенности и наличие движения поблизости. Механизм адаптации достаточно прост: если зафиксирована ситуация, при которой в темноте происходит какое-то движение, то включается освещение. Затем свет будет гореть до тех пор, пока человек движется, а после того, как в течение определенного периода движение обнаружено не будет, освещение снова выключится. Точно так же свет выключится, если вокруг будет светло.
Эти простые примеры показывают основной принцип работы контекстно-зависимой системы. На рисунке 6 изображена эталонная архитектура для контекстно-зависимых вычислительных систем. Датчики предоставляют данные о действиях и событиях, происходящих в реальном мире. Алгоритмы восприятия будут анализировать эти стимулы и классифицировать ситуации согласно контексту. Исходя из наблюдаемого контекста, система начнет совершать определенные действия.
Рисунок 6: на схеме представлена базовая архитектура контекстно-зависимой компьютерной системы. Она предполагает получение данных от множества сенсоров, что позволяет поддерживать контекстуальное поведение нескольких приложений. Обозначения: Sensor — датчик, Feature Calculation Sensor — вычислительная функция датчика, Perception across all relevant sensors — суммарное восприятие данных от всех релевантных датчиков, Context Calculation — вычисление контекста, Context Provision — обеспечение контекста, Application — приложение.
3. Контекстная осведомленность как стимулятор повсеместных вычислений
Понятие осведомленности о контексте тесно связано с концепцией повсеместных вычислений, представленной главным научным сотрудником лаборатории Xerox PARC Марком Вайзером (Mark Weiser) в его основополагающей статье, опубликованной в 1988 году в журнале Scientific American. Поскольку компьютеры становятся частью повседневной жизни, важно, чтобы они были просты в использовании. Этот тезис подчеркивается следующим утверждением:
«Самые глубокие технологии — это те, которые исчезают. Они вплетают себя в ткань повседневной жизни, пока не становятся неотличимыми от нее», — Марк Вайзер, 1991 г.
Рисунок 7: Марк Вайзер озвучил концепцию повсеместных вычислений. Контекстная осведомленность является важнейшим компонентом, необходимым для воплощения этой идеи в жизнь.
Многие исследователи считают упомянутый Вайзером уровень интеграции вычислительных технологий конечной целью развития компьютерной отрасли. В такой ситуации технологии не требуют к себе особого внимания со стороны пользователя и с «первого взгляда» будут готовы к применению. Если подобное состояние дел будет достигнуто, компьютеры исчезнут — не в техническом смысле, а с психологической точки зрения.
«По сути только тогда, когда вещи исчезают таким образом, мы освобождаемся, чтобы использовать их, не задумываясь», — Марк Вайзер, 1991 г.
Для реализации таких повсеместных вычислительных систем, обладающих оптимальным юзабилити, то есть прозрачностью использования, контекстно-зависимое поведение должно рассматриваться как ключевой фактор, способствующий достижению успеха. Компьютеры уже наполняют нашу повседневную жизнь — они находятся в наших телефонах, холодильниках, телевизорах, тостерах, будильниках, часах и т. д., — но, чтобы полностью исчезнуть, как в концепции Вайзера о вездесущих вычислениях, они должны предвосхищать потребности пользователя в конкретной ситуации и действовать превентивно, чтобы уметь оказать надлежащую помощь. Эта способность требует средств для осознания окружения, то есть для понимания контекста.
Существует множество примеров столь хорошо реализованных вычислительных систем, что пользователи не отдают себе отчет, что они взаимодействуют с некими устройствами. Автомобильная отрасль является хорошим примером подобного подхода: ABS (антиблокировочная тормозная система) и ESP (электронная система контроля устойчивости) теснейшим образом интегрированы в автомобили и влияют на их поведение в экстремальных ситуациях. Тем не менее, большинство людей не будут сознательно задумываться об этих технологиях при повседневной эксплуатации автомобиля. Эти технологии стали настолько вездесущими, что исчезли из сознания пользователей.
4. Определение контекста
Термин «контекст» обладает целым рядом очень различающихся значений. Следующее определение из Кембриджского толкового словаря (Cambridge Dictionary), а также синонимы обеспечивают базовое понимание смысла контекста.
- Контекст, существительное — причина события; ситуация/среда, в которой что-то существует или происходит.
- Синонимы: обстоятельства, ситуация, фаза, положение, позиция, отношение, место, точка, условия, режим.
В литературе по контекстно-зависимым вычислениям также есть несколько определений и объяснений того, что такое контекст. Ниже приведены наиболее наглядные примеры, подчеркивающие основное толкование этого термина, разделяемое сообществом HCI.
В Университете Кента (University of Kent) были проведены исследования, в ходе которых рассматривалось, как мобильные устройства с GPS (с внешним подключением), доступ к сети и дополнительные датчики могут использоваться для оказания поддержки археологических полевых работ, проводимых приезжими работниками. Исследовательская группа предложила следующее определение:
«[...] “контекстная осведомленность”— это термин, описывающий способность компьютера действовать на основе воспринимаемой информации, такой как местоположение, время, температура или идентификация пользователя. Эта информация может использоваться не только для маркировки данных, собранных на местах, но также для обеспечения избирательных ответных действий, таких как включение аварийных сигналов или получение информации, относящейся к поставленной задаче», — Ник Райан (Nick Ryan) и др., «Улучшенная реальность. Полевые работы: археологический помощник, ориентированный на контекст» (Enhanced Reality Fieldwork: the Context-aware Archaeological Assistant), 1998 г.
Рисунок 8: Ланкастерский замок (Lancaster castle) является одной из самых посещаемых локаций, представленных в туристической системе GUIDE.
Проект GUIDE (2001 г.), осуществленный в Университете Ланкастера (Lancaster University) стал первым крупным и общедоступным внедрением исследовательского прототипа для изучения контекстной осведомленности в сфере туризма. В нем основное внимание было уделено тому, как контекст может использоваться для развития мобильной информационной системы, предназначенной для посетителей исторического города Ланкастер. Один из авторов проекта, Кит Митчелл (Keith Mitchell), в своей диссертации предлагает следующее понятие контекста, основанное на работе с системой GUIDE:
«[...] были определены два класса контекста, а именно персональный и экологический контекст. [...]. Примеры экологического контекста включают: время суток, время начала осмотра достопримечательностей и текущий прогноз погоды», — Кит Митчелл, «Поддержка разработки мобильных контекстно-зависимых приложений» (Supporting the Development of Mobile Context-Aware Computing), 2002 г.
Перед нами такое понимание контекста, при котором сами пользователи являются частью функционального содержания (например, пользовательские профили и предпочтения). С технической точки зрения GUIDE следовал интересному подходу, поскольку использовал модифицированный браузер, в котором контекстная информация применялась в фоновом режиме для адаптации контента и формы его представления.
Профессор университета Карнеги-Меллон (Carnegie Mellon University) Анинд Дей (Anind Dey) предложил очень общее описание того, что представляет собой контекст:
«Контекст — это любая информация, которая может использоваться для описания ситуации и сущности. Сущность — это человек, место или объект, считающиеся релевантными для взаимодействия между пользователем и приложением, включая самого пользователя и приложение», — Анинд Дей.
Рисунок 9: эта традиционная доска объявлений рекламирует один и тот же продукт всем потенциальным пользователям, проходящим мимо нее — суп домашнего приготовления. В будущем такие доски будут заменены цифровыми экранами, и тогда станет возможным адаптировать контент к текущему контексту.
В практических целях контекст часто иерархически структурируется для описания релевантных функций. Предположим, вы хотите разработать «цифровую замену» традиционному меню, которое часто можно увидеть у входа в ресторан (см. рисунок 9).
Если у вас не зависимая от контекста версия меню, то в нем обычно указывается «блюдо дня». Вместо этого — если вы будете проектировать меню как как контекстно-зависимое — вы хотели бы отображать на дисплее различные предложения, изменяющиеся в зависимости от того, кто проходит мимо него. Если мимо проходят родители с детьми, вы покажете им меню, рассчитанное на семью; паре влюбленных, вечером смотрящих на дисплей вечером, вы предложите меню для романтического ужина при свечах. Если день жаркий и солнечный, вы рекламируете ассортимент мороженого, которое есть в вашем ресторане.
Функциональное пространство для этого приложения может включать людей, которые смотрят на него, время суток и погоду. Контекст, определяемый человеческим фактором, может быть уточнен по следующим параметрам: количество посетителей, их пол и возраст. Контекст погодных условий может включать в себя температуру воздуха и наличие/отсутствие атмосферных осадков. При предоставлении структурированного подобным образом пространства становится проще связать контексты реального мира с адаптивными реакциями системы. Попробуйте в качестве примера сделать полное пространство функций для меню и определить соответствующие адаптации. Даже контрольный перечень блюд можно рассматривать как очень простой пример пространства функций, не являющегося иерархическим
Не существует законченных пространств функций, описывающих все возможные варианты доступных опций — такое функциональное пространство в реальности обернулось бы попыткой предоставить полное исчерпывающее описание окружающего мира. Обычный подход заключается в создании функционального пространства для конкретного контекстно-зависимого приложения сообразно его предназначению. Преимущество пространства функций заключается в том, что, просматривая набор параметров, можно легко определить, соответствует ли ситуация контексту или нет.
Рисунок 10: контекстное пространство объектов, детализирующее свет как одну из особенностей условий физической среды. Обозначения: Human factors — человеческие факторы, User — пользователь, Social Environment — социальное окружение, Task — задача; Physical Environmental — физическое окружение, Conditions — условия, Infrastructure — инфраструктура, Location — местонахождение; Light — свет, Pressure — давление, Acceleration — ускорение, Audio — громкость звука, Temperature — температура; дополнительные световые характеристики: Level — уровень освещенности, Flickering — мерцание, Wave-length — длина волны (спектральный цвет); Time — время.
Совет по проектированию #1: при разработке контекстно-зависимой системы сначала создайте (иерархическое) пространство объектов, включающее в себя факторы, влияющие на поведение системы.
Зная, какие факторы оказывают влияние на поведение системы, можно приступить к рассмотрению того, как эти факторы могут определятся устройствами. Во многих случаях для этого требуются датчики, позволяющие обеспечить восприятие контекста.
5. От датчиков — к контексту
Конечная цель контекстно-зависимой системы заключается в том, чтобы система достигла представления окружающего мира, близкого к восприятию пользователя. Важнейшим вопросом в области проектирования пользовательского опыта является сокращение разрыва между пользовательским и «системным» восприятием и пониманием реального мира. Для контекста, зависимого от местоположения, хорошо известны различные способы определения (например, GPS) и интерпретации (всемирная система геодезических параметров — World Geodetic System, почтовый индекс). Однако для многих других датчиков обычно не существует единого и хорошо понятного способа интерпретации информации, получаемой их посредством.
Восприятие пользователем окружающей среды базируется на человеческих ощущениях, но одновременно связано с опытом и памятью. Человеческое восприятие имеет многогранный (многоаспектный) характер. Возвращающийся домой с автобусной остановки поздно вечером пользователь способен почувствовать, что вокруг темно, тихо и холодно, но в то же время он может воспринимать ситуацию как пугающую.
Другой пользователь, который весь прошедший день был обременен заботами и окружен другими людьми, может воспринимать ситуацию также как темноту, тишину и холод, но в то же время чувствовать себя расслабленным и свободным. Этот пример показывает, что использование только информации, поступающей от датчиков, не дает полной картины происходящего. Важно помнить, что даже идеально спроектированная и реализованная система не сможет воспринимать окружающую среду точно так же, как пользователь.
Теперь у нас есть следующие компоненты: пользовательские опыт и восприятие, которые ведут к ожиданиям пользователя; воспринимаемый системой контекст, опирающийся на входной сигнал датчика; модель мира, предоставляемая системой, включая модель пользователя, управляющего системными реакциями (см. рисунок 5). Основная цель хорошего и полезного дизайна должна заключаться в минимизации «несоответствия уровню осведомленности» (Awareness Mismatch), как показано на рисунке 11.
Рисунок 11: представленная здесь модель восприятия пользовательского контекста (User-Context Perception Model, UCPM) выделяет параллельные процессы восприятия, происходящие как со стороны пользователя, так и со стороны системы. Если они различаются, то мы создаем системы с несоответствием уровней осведомленности, в которых поведение системы не соответствует ожиданиям пользователей. Обозначения: User — пользователь, Sensory Perception —чувственное восприятие, Perceived Experience — воспринимаемый опыт, User's Expectations for Contextual System Reactions — ожидания пользователя в отношении контекстуальной реакции системы, Memory and Experience — воспоминания и опыт; Awareness Mismatch — несоответствие уровней осведомленности; Context-Aware System — контекстно-зависимая система, Sensory Input — сенсорный ввод данных, Perceived Context — воспринимаемый контекст, Context-Aware System Response and Feedback — реакция и обратная связь со стороны контекстно-зависимой системы, Model of the World — модель мира, Model of the Human — модель человека.
Модель восприятия пользовательского контекста (UCPM) — это образец, созданный для того, чтобы помочь дизайнеру понять, с какими проблемами он сталкивается при создании контекстно-зависимых систем. Модель не описывает, каким образом работают люди, и не устанавливает, как надлежит имплементировать систему. Тем не менее, образец контекстно-зависимой системы, как его предоставляет данная модель, может стать хорошей отправной точкой для проектирования системной архитектуры приложений, ориентированных на контекст.
Рассмотрим пример автомобильной навигационной системы для чуть более подробного ознакомления с деталями UCPM. Если вы используете спутниковый навигатор, вы, вероятно, заметили, что он работает очень хорошо, если вы находитесь в городе, в котором вы никогда не были. Если вы используете его в местности, в которой вы живете, вы можете, однако, иногда удивляться маршруту, которым пытается направить вас навигатор. Это явление можно объяснить при помощи модели UCPM.
Предположим, что контекстно-зависимая система (правая сторона на рисунке 11) одинаково качественно работает в обоих местоположениях. Это означает, что различие должно быть на стороне пользователя. Сенсорное восприятие (например, визуальное сопоставление зданий и мест, которые вы знаете, основываясь на вашем зрительном опыте) различается для знакомого и нового, незнакомого места. Для нового места вам не хватает опорных точек, а часть памяти и опыта (Memory and Experience на рис. 11) в модели UCPM значительно отличается. В знакомой среде у вас будут ожидания относительно того, какой маршрут предпочесть и какой путь будет хорошим выбором. В незнакомой среде вам не хватает опыта и контрольных точек, и, следовательно, ваши ожидания просто сводятся к тому, что система будет направлять вас к месту назначения. В результате система навигации, которая успешно направит вас к месту назначения по неоптимальному маршруту, удовлетворит ваши ожидания в незнакомой обстановке, но вызовет ваше недовольство при навигации в знакомом окружении. Неоптимальный маршрут может включать в себя объезд нескольких кварталов, потому что карта устарела или необходимость ждать смены сигнала на трех светофорах, тогда как вы могли бы использовать в качестве альтернативного решения немного более длинный путь через мост без необходимости задерживаться у светофоров. В знакомой среде у нас возникает существенное несоответствие уровню осведомленности, тогда как при навигации в незнакомом окружении мы имеем минимальное несоответствие осведомленности.
Совет по проектированию #2: в пользовательском интерфейсе укажите информацию о данных, полученных при помощи датчиков и используемых для определения контекста — это позволит вам свести к минимуму несоответствие уровню осведомленности.
Качество контекстно-зависимых систем — как оно воспринимается пользователем — напрямую связано с несоответствием уровню осведомленности, а хороший дизайн направлен на проектирование систем с минимальным уровнем несоответствия. Одним из необходимых условий минимизации несоответствия осведомленности понимание пользователем того, какие факторы оказывают влияние на систему. На примере упрощенной автомобильной навигационной системы можно понять, что таким фактором является только текущее местоположением — и ничто другое. В таком случае пользователь знает, что реакции системы основаны исключительно на его нынешнем местонахождении, а также на пункте назначения, и пользователь может объяснить ответ системы на эти факторы. В случаях, когда дополнительные параметры играют роль — например, навигационной системы, которая учитывает интенсивность дорожного движения — пользователю может быть труднее понять причинно-следственные связи, влияющие на поведение системы. В таком случае навигационная система может предлагать разные маршруты утром и вечером, поскольку ситуация с дорожным движением отличается в зависимости от времени суток. Если пользователь не знает, что система предлагает маршруты с учетом текущего местоположения и транспортной ситуации, вполне вероятно, что пользователю будет сложно понять, что именно делает система. Важнейшее правило разработки контекстно-зависимых систем: пользователь должен быть осведомлен о сенсорной информации, которую использует система.
Существует множество примеров устройств и приложений, которые обеспечивают такую обратную связь, например, значок используемого типа беспроводной связи в мобильном телефоне и символ приема сигналов GPS. Такие подсказки необходимы пользователю для понимания поведения системы. Например, пользователь может понять и принять, что существуют значительные различия в скорости загрузки данных на мобильном устройстве, когда запрашиваемая информация в некоторых случаях загружается через сеть GSM, а в других случаях — через соединение WiFi. Однако, если пользователь не имеет понятия о разнице между передачей данных через GSM и Wi-Fi, то вся эта информация не принесет реальной пользы, а несоответствие уровней осведомленности останется. Поэтому советы по проектированию, такие как вышеупомянутый совет #2, не являются абсолютными правилами и не освобождают разработчика от проведения пользовательских исследований и тестов юзабилити. «Знайте своего пользователя», — как гласит популярный в кругах разработчиков UX афоризм.
Рисунок 12: пользовательские интерфейсы смартфонов предоставляют очень простую контекстную информацию. На этом снимке показано, что телефон подключен к сети GSM, а также к базовой станции WiFi. Наличие этой информации позволяет пользователю лучше понять поведение системы — например, в случае, если пользователи разговаривают по телефону и качество речи ухудшается после входа в здание. Глядя на черточки, указывающие на мощность принимаемого сигнала, пользователь может понять, что сетевое покрытие является недостаточным. Поскольку у вас есть ментальная модель проблемы и ее решение, вы двигаетесь к окну или назад к двери, чтобы восстановить удовлетворительное качество сигнала.
Самой основной идеей, достигаемой с помощью сенсорной информации осведомленности о контексте, является предположение, что подобные ситуации (рассматриваемые как один контекст) представлены подобными стимулами. Поэтому датчики могут использоваться для определения контекстов на основе предположения, что в аналогичных контекстах исходные сенсорные данные, образующие характеризующие признаки ситуации, будут схожими. Самая трудная задача заключается в том, чтобы оценить и определить, каковы релевантные и характеризующие особенности контекста. Как люди, мы делаем это в нашей повседневной деятельности снова и снова. Входя в помещение, мы понимаем, что в комнате идет совещание с участием людей, сидящих за столом, — даже если незнакома эта комната и неизвестны люди, участвующие в этом заседании. Основной подход состоит в том, чтобы сделать (неявный) анализ сенсорных исходных данных, полученных из окружающей обстановки, и сравнить его с ситуациями, с которыми вы сталкивались ранее.
Предположим, что в конференц-зале первого этажа здания SimTech происходит вечернее совещание деканата Штутгартского университета. Кроме того, в британском городе Ланкастер состоится заседание в конференц-зале на втором этаже строения InfoLab — оба мероприятия назначены на 10 часов утра. Давайте сравним сенсорные показания для этих двух ситуаций и добавим еще две ситуации: студенческие лабораторные работы в Штутгарте и уборка конференц-зала в Ланкастере.
Особенность | Совещание | Совещание | Лабораторная | Уборка |
Географическое положение: | Штутгарт | Ланкастер | Штутгарт | Ланкастер |
Свет включен или выключен: | Свет включен | Свет выключен | Свет выключен | Свет включен |
Количество человек | 7 | 9 | 8 | 1 |
Язык общения: | Немецкий | Английский | Немецкий | Не используется |
Активность | Сидение | Сидение | Сидение | Движение |
Потребляемая мощность в помещении: | 2 кВт | 1,6 кВт | 3,4 кВт | 3 кВт |
Используемые устройства: | Ноутбук, телефон | Проектор, ноутбук | Ноутбук, телефон | Пылесос |
Таблица 14.1: примеры ситуаций и их характеризующих особенностей
Если мы создадим матрицу, в которой подсчитаем количество схожих характеристик, мы придем к результатам, представленным в таблице 2. Используя этот набор особенностей, мы обнаружим, что совещание в Штутгарте больше похоже на лабораторную работу, чем на другое совещание, проводимое в Ланкастере. Если бы мы выбрали другой набор характеристик, мы бы получили другие сходства, отличающиеся от предыдущих. Это иллюстрирует, насколько важно выбирать правильные особенности для классификации ситуаций. Важно найти конкретные характеристики для контекста, и во многих случаях добавление дополнительных особенностей может быть контрпродуктивным.
Сходства | Совещание | Совещание | Лабораторная | Уборка |
Совещание | 7 | 1 | 4 | 1 |
Совещание | 1 | 7 | 2 | 1 |
Лабораторная | 4 | 2 | 7 | 0 |
Уборка | 1 | 1 | 0 | 7 |
Таблица 2: подсчет схожих особенностей для каждой пары ситуаций. Становится ясно, что простой подсчет любого набора характеристик хорошо работать не будет. Важным является выбор «правильных» особенностей, чьи характеристики имеют важнейшее значение.
Общий подход заключается в том, чтобы посмотреть, какие входные данные от датчика вы ожидаете получить в определенном контексте. В таблице 3 приведены два примера. Совещание обнаруживается, когда в комнате присутствуют несколько и когда эти люди взаимодействуют. Когда сенсорная информация указывает на текущее изменение света и определенный уровень звука, а также местоположение человека во внутреннем помещении, где он находится в неподвижном состоянии, мы предполагаем, что пользователь смотрит телевизор. Примеры показывают, что ожидаемые показания датчика связаны с пространством функций, представленным на рисунке 10. Если посмотреть на описание ожидаемого входного сигнала от сенсора, становится очевидным, что распознавание ситуации никогда не бывает идеальным.
Легко можно предположить ситуации, которые не являются совещанием, но будут восприниматься в качестве такового (например, совместный ланч, скорее всего, будет классифицироваться как совещание в соответствии с приведенным ниже описанием).
Аналогично, мы можем спроектировать ситуацию, которая принадлежит контексту, но не распознается как соответствующая ожидаемой входной информации от датчика. Если пользователь смотрит телевизор в саду и, возможно, даже использует субтитры и отключает звук, эта ситуация не будет опознана. Такие описания могут быть сделаны на очень разных уровнях абстракции (например, люди напротив пассивного инфракрасного датчика, обнаруживающего движение). Используемые описания обычно зависят от типов предполагаемых сенсоров.
Контекст | Ожидаемый входной сигнал датчика |
Совещание |
Присутствует несколько человек |
Пользователь смотрит телевизор | Уровень и цвет освещения меняется, определенный уровень звука (не тихий), тип местоположения — внутри помещения, пользователь главным образом неподвижен |
Таблица 3: пример иллюстрирует допущения, сделанные для конкретных сенсорных входных данных в двух контекстах.
Совет по проектированию #3: найдите параметры, характерные для контекста, который вы хотите обнаружить, и определите средства для измерения этих параметров.
В современных контекстно-зависимых системах для получения контекстуальной информации используется широкий ряд датчиков. Важнейшими из сенсорных устройств являются датчики GPS (служащие для определения местоположения и скорости движения), светочувствительные элементы (применяемые для обнаружения объектов и действий), микрофоны (используемые для получения информации о шуме, действиях и разговорах), акселерометры и гироскопы (предоставляющие данные о движении, ориентации устройства и вибрации), датчики магнитного поля (применяемые в качестве компаса для определения ориентации по сторонам света), сенсоры близости (для обнаружения явного и неявного взаимодействия с пользователем), датчики температуры и влажности (для оценки состояния окружающей среды), сенсоры для измерения атмосферного давления. Существуют также датчики для определения физиологического контекста пользователя (например, измерения гальванической реакции кожи, снятия электроэнцефалограмм и электрокардиограмм). Гальванические характеристики кожных покровов понимаются как сопротивление между двумя электродами, размещенными на коже. Измеренное значение зависит от того, насколько кожа сухая. Как правило, такие измерения могут быть использованы для определения реакций, изменяющих сухость кожи, например, удивление или страх (детекторы лжи основаны на аналогичных механизмах). В принципе, можно использовать все типы датчиков, доступных на рынке, для подачи контекстной информации в систему.
В некоторых приложениях может иметь смысл использовать большее количество однотипных датчиков для того, чтобы упростить определение контекста. Например, довольно просто определить количество динамиков и обнаружить места их размещения в комнате, пользуясь набором микрофонов; в то же время выполнить эту задачу при помощи одного микрофона будет практически невозможно. Качество полученной информации также может быть улучшено за счет использования набора датчиков, а не одного. Простым примером является то, что с помощью одного светочувствительного датчика можно только определить уровень освещенности в окружающей среде, однако большее число подобных сенсоров образует «фундамент» любой современной цифровой видео- или фотокамеры — записывающую светодиодную матрицу.
Чтобы совместить сенсорную информацию с контекстами, необходимо выполнить сопоставление. Эти задачи восприятия обычно выполняются с использованием средств машинного обучения и интеллектуального анализа данных. Самый простой способ — описать набор характеристик, которые определяют ситуацию. Затем в любой ситуации система будет контролировать информацию, получаемую от сенсорных входов, и проверять ее на соответствие списку особенностей. В эту категорию входят простые системы, основанные на правилах. Другой пример — записываются типичные ситуации и вычисляются особенности, являющиеся для них характеризующими. В случае обнаружения новой ситуации ее особенности вычисляются и сравниваются с изученными (записанными). Затем при простом так называемом «сопоставлении ближайших соответствий» можно вычислить текущий контекст.
Качество алгоритмов, вычисляющих контексты, необходимо оценить, чтобы определить, насколько хорошо работает система. Эти алгоритмы могут быть оптимизированы для повышения точности подобно классическим информационно-поисковым системам. При оценке контекстно-зависимых систем важно учитывать вероятность того или иного контекста; в противном случае могут быть не учтены очень редко происходящие события. Рассмотрим следующий пример: вы хотите разработать противопожарную сигнализацию и предполагаете, что по прошествии 10 000 суток функционирования системы наступит тот самый один единственный день, когда произойдет пожар. Если вы поднимете камень с земли и заявите, что это — «пожарная сигнализация», вы можете быть уверены, что этот вариант не сработает. Тем не менее, вы все равно можете утверждать, что ваша «пожарная сигнализация» будет работать в 99,99% случаев. Однако, при предоставлении информации для контекста «пожар (0%)» и контекст «пожара нет (100%)», сразу становится очевидным, что камень в качестве противопожарной сигнализации бесполезен. Чтобы оценить это, используется матрица ошибок (Confusion Matrix). Она показывает взаимосвязь между реальной ситуацией и воспринимаемым контекстом для каждой определенной ситуации.
Таблица 4: матрица ошибок для камня. Обозначения в таблице: контекст, воспринимаемый «системой» (Perceived context by the "system"), ситуация в реальном мире (Situation in the real world), наличие пожара (Fire), отсутствие пожара (No Fire).
Таблица 5: матрица ошибок для оптимальной пожарной сигнализации.
Рисунок 13: чтобы узнать, насколько хорошо работает «детектор контекста», вам необходимо знать эффективность распознавания им каждой определенной ситуации. Вы, скорее всего, согласитесь с тем, что по сравнению с реальной пожарной сигнализацией камень не будет работать так же хорошо, как настоящая противопожарная система.
6. Использование контекста в приложениях и пользовательских интерфейсах
Информация, поступающая от датчиков, позволяет определить конкретный контекст, вследствие чего к нему могут быть привязаны различные функции и модели поведения систем и приложений. Как упоминалось ранее, основной мотивацией для вычисления/определения контекста является углубление понимания системой окружающей среды. Это позволяет дизайнеру создавать системы, которые по-разному действуют в различных условиях, и, если они хорошо спроектированы, они соответствуют ожиданиям пользователя в данном контексте, то есть наблюдается совпадение уровней осведомленности (см. рисунок 11).
Различные типы поведения могут быть спроектированы с учетом разных уровней системы и варьироваться от низкоуровневой функциональности (например, выбора наиболее подходящего сетевого протокола для текущего контекста), до коррекции поведения приложений и поддерживаемых функций (например, мобильное устройство, используемое во внутренней сети компании, может получить доступ все ко всем документам, тогда как это же самое устройство при подключении за пределами компании может иметь доступ только к подмножеству документов) и до изменений на уровне пользовательских интерфейсов (например, уровень масштабирования карты зависит от скорости, с которой движется автомобиль). Зачастую трудно четко разграничить, в какую категорию попадает такое адаптивное поведение.
Обычно различают следующие типы контекстно-зависимых вычислений:
- Контекстно-адаптивные системы — активные приложения, триггеры функций и адаптивные приложения
- Адаптивные и контекстно-зависимые пользовательские интерфейсы
- Управление прерываниями на основе ситуаций
- Обмен контекстом и контекстной связью
- Сгенерированные данные для метаданных и контент, неявно производимый пользователями
- Контекстно-ориентированное управление ресурсами
Знание этих базовых категорий помогает в разработке контекстно-зависимых приложений. В некоторых случаях не между отдельными типами вычислений нельзя провести строгое разграничение, или они же могут быть объединены в одном приложении. Еще в оригинальную статью Шилита и др. (1994 г.) были включена дискуссия по поводу того, каким образом контекст может быть использован, и таблица разграничений. В таблице исследователи фиксировали различия между тем, что — с одной стороны — зависит от контекста (information or commands), и тем, как применяется контекст (вручную или автоматически) — с другой стороны. Эта точка зрения находит воплощение в первом и последнем типах контекстно-зависимых системах из приведенного выше списка, то есть проактивных приложениях и управлении ресурсами.
Ручное применение | Автоматическое применение | |
Информация | Непосредственный выбор и контекстная информация | Автоматическая контекстная реконфигурация |
Команда | Контекстные команды | Вызываемые контекстом действия |
Таблица 6: базовая таксономия создания контекстно-зависимых систем, предложенная Шилитом и другими в 1994 году.
6.1 Контекстно-адаптивные системы — проактивные приложения, триггеры функций и адаптивные приложения
Проактивные (действующие с опережением) приложения берут на себя инициативу совершения неких действий от имени пользователя, основываясь на обстановке и контексте. Примером может служить система отопления, которая заблаговременно начинает обогревать жилые помещения, когда обнаруживает контекст «пользователь находится на пути домой». Основная идея проактивных приложений заключается в том, что система предполагает — на основе контекста —какое приложение пользователю потребуется и заранее запускает его. С технической точки зрения подобные процессы иногда называют триггерами (Trigger — англ. «спусковой крючок»). Контекст инициирует запуск приложения.
Адаптивные приложения концептуально очень похожи на триггерные функции. Основное различие заключается в том, в одном случае на основе контекста запускаются отдельные функции, в другом — полные приложения. Однако детализация приложений и функций может сильно различаться; в силу чего разграничение не имеет большого значения. При проектировании контекстно-адаптивных систем основным подходом является первоначальное определение набора контекстов, имеющих отношение к адаптации, затем выбор набора функций или приложений, которые будут использоваться, и, наконец, создание сопоставлений между контекстами и функциональными возможностями.
Установить сопоставления можно, создав таблицу, подобную таблице 7, которая применима к адаптивному «главному экрану» приложения. Сопоставление также определяет, каким образом активизируется триггер. В этом примере большинство функций приложения выполняются в режиме «При входе» («On Entry»), что означает, что процесс запускается, когда пользователь входит в контекст. Когда пользователь переключается на другое приложение, триггер не будет применяться повторно. Триггер, называющийся «Постоянно» («Always»), будет следить за тем, чтобы вызываемое приложение инициировалось множество раз; в нашем случае карта всегда будет отображаться на главном экране, когда пользователь находится в автомобиле. В случае, если пользователь переключится на другое приложение, триггер будет проверяться каждые 30 секунд и переключится обратно на отображение карты при отсутствии альтернативной активности пользователя. Еще одним примером является триггер «Каждые 60 секунд» («Every 60 Seconds»). Такой триггер полезен для постоянного (в этом случае каждые 60 секунд) обращения к функции, пока пользователь остается в определенном контексте. Последним примером триггера является процедура «При выходе» («On Exit»), вызывающая сопоставленную функцию в тот момент, когда пользователь покидает контекст.
В рассматриваемом случае не существует настоятельной необходимости в формальном описании, но создание таблицы, как показано ниже, помогает в проектировании и имплементации приложения. Таблица также показывает, что один и тот же контекст может присутствовать более чем в одной строке одновременно, так как некоторые ситуации требуют запуска более чем одной функции. Аналогичным образом функции не относятся исключительно к одному какому-то определенному контексту и могут инициироваться многими условиями.
Контекст | Расписание/Режим запуска | Запускаемая функция |
В офисе | При входе в контекст | Показать календарь на главном экране |
В автобусе | При входе в контекст | Запустить музыкальный проигрыватель |
В автомобиле | Всегда, проверка каждые 30 секунд | Показать карту на главном экране |
В автомобиле | Каждые 60 секунд | Отправить текущее местоположение для веб-сервиса |
Дома | При входе в контекст | Показывать сообщения Facebook на главном экране |
Дома | При выходе из контекста | Показать список дел и покупок |
В спортзале | При входе в контекст | Запустить музыкальный проигрыватель |
Таблица 7: сопоставление контекста и функций для образца приложения.
Совет по проектированию #4: разработка проактивных приложений очень сложна, потому что система должна «предвидеть», чего хочет пользователь. Во многих случаях гораздо проще не представлять «приложение», а скорее предъявить набор потенциально интересных приложений, которые пользователь мог бы запустить.
Например, контекстный «главный экран» может предлагать выбор приложений, которые окажутся полезными в данном контексте, а не пытаться самостоятельно правильно выбрать одно из них.
6.2 Адаптивные и контекстно-зависимые пользовательские интерфейсы
Контекстно-зависимые пользовательские интерфейсы являются особым случаем контекстно-зависимых функций. По существу, это означает систему, в которой контекстно-зависимые функции являются элементами пользовательского интерфейса. Уровни сложности системы в областях адаптации и осведомленности могут сильно различаться. Очень простой пример контекстно-зависимого пользовательского интерфейса — это подсветка устройства, которая включается при снижении уровня освещенности окружающей среды. Другими примерами являются аудио профили, которые соответствуют конкретной ситуации (например, уровни громкости звонка смартфона для помещения или улицы), или компоновка веб-страницы на дисплее, оптимизированная для данного контекста. На мобильном устройстве условия ввода могут зависеть от контекста. Например, в автомобиле мобильное устройство может применять для интеракции простое меню с большим шрифтом, которое может быть активировано с помощью простых голосовых команд; но этот же самый гаджет, будучи включен во время совещания, может представить более сложный пользовательский интерфейс. В докладе Билла Шилита, в котором была первоначально вынесена на рассмотрение идея контекстно-зависимых приложений, используется пример пользовательского интерфейса для выбора принтера. На рисунке 14 показаны способы отображения меню выбора принтера, когда близость расположения устройства используется в качестве контекста. Это выглядит очевидным способом представления списка принтеров, но даже сегодня, спустя десятилетия, мы не видим применения такого подхода в операционных системах.
Рисунок 14: дизайн пользовательского интерфейса отображает различные способы представления контекста пользователю (в данном случае — близости принтера).
Контекстно-ориентированные пользовательские интерфейсы могут включать как выходные, так и входные данные, а также их различные формы. Разработка контекстно-зависимых пользовательских интерфейсов предусматривает средства для создания пользовательского интерфейса, специально предназначенного для каждого контекста. Это, однако, не так просто, как может показаться. Пользователи обучаются обращению с пользовательским интерфейсом и подстраивают свое поведение к конкретному UI. Они будут помнить, где находится определенный элемент меню или какую «навигационную» задачу надо выполнить, чтобы перейти к конкретной функции. Сделав размещение элементов пользовательского интерфейса адаптивным, а его структуру — динамической, мы усложним процесс обучения использованию данного UI. Если представление адаптивных возможностей системы будет непонятной, например, если сделать основную причину применения адаптации неясной для пользователя, это может отрицательно сказаться на пользовательских способностях к запоминанию пользовательских интерфейсов и эффективному взаимодействию с ними.
Если взять в качестве примера элементы меню в интерфейсе типа WIMP («window, icon, menu, pointing device» — «окно, значок, меню, манипулятор»; в человеко-компьютерном взаимодействии эта аббревиатура используется в качестве приблизительного синонима графического интерфейса), то можно утверждать, что пункты меню должны быть заново упорядочены в соответствии с их частотой использования, а неиспользуемые элементы должны быть скрыты от пользователя. Адаптивные меню были доступны в более ранних версиях Microsoft Office, и это оказалось плохой идеей — их применение вводило в заблуждение множество людей и затрудняло обучение использованию продукта. Последующие версии Microsoft Office сочетали в себе стабильность и контекстную осведомленность, сохраняя все пункты меню видимыми, но «затеняя» сохраняя функции, недоступные в текущем контексте. Это изменение работало очень хорошо.
Совет по проектированию #5: используйте адаптивность в пользовательском интерфейсе с большой осторожностью и убедитесь, что она понятна для пользователя. Хорошие конструкции UI сохраняют стабильность компоновки элементов и способствуют усилиям пользователя по запоминанию пользовательского интерфейса, используя контекст для снижения сложности.
6.3 Управление прерываниями на основе ситуаций и совместное использование контекста в сфере коммуникаций
Прерывания происходят постоянно. Вы пишете электронное письмо и на середине незаконченного предложения получаете SMS-сообщение. Прерванный тональным сигналом уведомления, вы переключаете свое внимание на экран телефона и читаете сообщение. Затем вы возвращаетесь к письму — и не можете вспомнить, что хотели написать. Такие ситуации широко распространены, но в большинстве случаев они не имеют критического значения, и люди научились справляться с ними.
Рассматривая прерывания, мы можем сформулировать основной факт: компьютеры и устройства связи «очень невежливые». Представьте, что вы находитесь в очереди в библиотеке. Вы третий в очереди, и вы терпеливо ждете, пока библиотекарь обслужит посетителей перед вами. Вдруг некто входит и направляется прямо в самое начало очереди, прерывает разговор между библиотекарем и первым в очереди человеком и спрашивает о книге, которую заказал неделю назад. Такое случается редко, и все посетители будут раздражены подобным бесцеремонным поведением. Но когда дело доходит до телекоммуникаций, нечто похожее происходит постоянно. Если два человека беседуют лицом к лицу, и у одного из них звонит мобильный телефон, этот собеседник, скорее всего, переключит свое внимание на поступивший вызов и прервет личную беседу. Такое поведение, возможно, связано со старой моделью поведения, когда телефонные звонки были дорогими и, как правило, важными — подобная проблема в настоящее время менее актуальна. Кроме того, до появления идентификатора вызывающего абонента вы не могли просто отклонить телефонный звонок, так как не узнали бы, кто звонил вам, если бы не ответили на него. Хотя в сфере телекоммуникаций произошли значительные изменения, некоторые из наших поведенческих паттернов в обращении с новыми технологиями по-прежнему основаны на понимании предыдущих технических решений.
Существует несколько способов использования контекста для минимизации прерываний. Например,
- Контекст как источник для планирования прерывания и возобновления коммуникаций
- Обмен контентом для определения времени передачи сообщений
Используя контекстную информацию, мы можем решить, когда и как обеспечить асинхронную передачу данных. В приведенном выше примере, где SMS прерывает процесс написания электронного письма, можно представить себе решение, где уведомление будет отложено до тех пор, пока пользователь не нажмет кнопку отправки письма. Другим вариантом является изменение формы уведомления: например, вместо того чтобы телефон сообщал о получении SMS звуковым сигналом, оповещение могло бы выглядеть как баннер, всплывающий в строке состояния, что было бы менее отвлекающим фактором для текущей задачи. Этот пример показывает, однако, что дизайн всегда является продуктом компромисса. Если мы отложим уведомление, пользователь может получить сообщение слишком поздно, и даже если мы будем использовать дополнительный или альтернативный способ оповещения, мы все равно можем прервать пользователя.
В сфере синхронной коммуникации автоматизацию обеспечить очень трудно. В этом случае совместное использование контекста является перспективным способом его применения в целях улучшения пользовательского опыта. В статье «Неявное человеко-компьютерное взаимодействие при помощи контекста» (Implicit Human Computer Interaction Through Context, 2000 г.) профессор Штутгартского университета Альбрехт Шмидт (Albrecht Schmidt) совместно со своими коллегами представил идею публикации контекста для ситуации потенциально нежелательных звонков — например, статус «Я нахожусь на совещании», чтобы предоставить решение — звонить или нет — вызывающему абоненту. Обоснование этого предложения заключается в том, что только зная оба контекста — ситуации вызывающего и вызываемого абонентов — можно решить, следует ли устанавливать соединение.
С появлением социальных сетей, таких как Facebook и Google+, стало возможным использовать контекст в основных коммуникационных системах. Например, некоторые телефоны интегрируют данные адресной книги с информацией о статусе на Facebook и местонахождении пользователей.
6.4 Генерация информации для создания метаданных и неявно производимый пользователями контент
Очевидно, что все, что мы делаем, происходит в определенном контексте. Если мы пишем статью — мы делаем это где-то, в какое-то время дня, после какой-то другой деятельности или перед еще одним каким-нибудь последующим занятием. Мы можем находиться вместе с другими людьми, пока пишем текст, и в это время, вероятно, мы будем искать какой-то другой материал. В настоящее время текст, который вы читаете, не отражает контекст, в котором он создавался. Вы не можете видеть, что слова, которые вы читали в этой статье, были написаны во время нескольких поездок на поезде. Однако если у нас есть контекст, мы можем «прикрепить» метаинформацию к каждому слову, написанному нами. Позже, взглянув на текст, мы могли бы посмотреть, где он был создан и кто присутствовал при его написании. Одной из областей, для которых был бы полезен автоматический сбор метаинформации, является подтверждение личных воспоминаний и поддержка истории личного поиска.
Представьте, что вы ищете заметки о некой встрече. Возможно, вы не помните, когда встреча состоялась, но вы можете вспомнить место, где она проходила, и людей, которые присутствовали при этом, и что было поздно вечером, когда мероприятие закончилось. Если эта метаинформация была записана, вы можете использовать ее для поиска.
Такие сервисы как YouTube, Википедия, Flickr или Facebook являются примерами средств массовой информации, где люди создают контент и делятся им. Все этот контент создается явным образом: видеоролики записываются, статьи «набиваются», фотографии снимаются — и совместно используются. Этот явно — эксплицитно — сгенерированный контент составил гигантский кладезь информации и существенно изменил Интернет.
Если мы посмотрим на контекстную информацию, то обнаружим не менее интересный источник пользовательской информации: неявно — имплицитно — созданные пользователем данные. Когда вы ведете машину по маршруту от своего дома до места, вы генерируете информацию. Предположим, что вы записываете информацию, поступающую от автомобиля (например, от сенсоров ускорения и вибрации, термодатчика, гигрометра и т. д.) и навигационной системы (например, скорость, местоположение, направление) и передаете эту информацию в Интернет. Если несколько пользователей будет обмениваться подобными контекстными данными, то они составят совершенно новую информационную сферу, охватывающую диапазон от информации о движении в реальном времени до дорожных условий и точно локализованных метеорологических отчетов. Хотя этот сценарий технически осуществим, он оставляет много вопросов в отношении конфиденциальности.
6.5 Контекстно-зависимое управление ресурсами
Управление ресурсами (за пределами пользовательского интерфейса) косвенно связано только с пользовательским опытом. Основным подходом к контекстно-зависимому управлению ресурсами является оптимизация работы устройства и использование ресурсов на основе контекста. Один очень яркий пример — максимизация мощности батареи с использованием контекстной информации — и другой — переключение между доступными сетями на основе текущего контекста. Эти подходы часто реализуются в нижележащих слоях операционной системы.
Следует помнить, что эти адаптации могут повлиять на пользовательский опыт.
Открытое управление ресурсами важно для простоты использования системы; представьте, что вам придется выбирать соответствующую базовую станцию для осуществления связи при помощи мобильного телефона каждый раз, когда вы посещаете другой район города. Даже если вы просто будет видеть окно сообщения каждый раз, когда вы попадете в зону охвата новой базовой станции, это сделает мобильный телефон скорее раздражающим, нежели полезным. Эта открытость великолепна, пока она работает. Если же это не срабатывает, или автоматическая адаптация системы вызывает у пользователя вопросы, разработчики должны предоставить пользователю средства для решения проблем.
Это возвращает нас к основной проблеме проектирования и компромиссу, который часто возникает при внедрении систем, ориентированных на контекст: поиск баланса между видимостью и открытостью. Этот вопрос часто связан с визуальным дизайном, а также с вопросом восприятия абстракций. Возьмите простой индикатор мощности сигнала мобильного телефона: он показывает некоторую контекстную информацию о ресурсе «возможность соединения». В этом случае вся информация о качестве сетевого интерфейса, включая потерю пакетов, задержки, SNR, RSS и т. д., представлена пятью черточками, и эта абстракция позволяет пользователю рассуждать о связи, даже если он мало что знает о беспроводных коммуникациях.
7. Неявное человеко-компьютерное взаимодействие
Имплицитное человеко-компьютерное взаимодействие (Implicit Human-Computer Interaction; iHCI) (обобщает концепцию понимания контекста в области HCI. Эксплицитная интеракция (традиционное, явное взаимодействие с компьютерами) противоречит идее невидимых вычислений и исчезающих интерфейсов. Чтобы спроектировать естественное взаимодействие, как нам представляется, от нас потребуется понимание имплицитных интеракций в дополнение к явному взаимодействию. Явное и неявное взаимодействие могут основываться на разных модальностях, включая командную строку, графические пользовательские интерфейсы (GUI) и взаимодействия в реальном мире. На рисунке 9 показана модель интеракции, учитывающая неявное и явное взаимодействие с человеческим компьютером.
Рисунок 14.15: эта модель объясняет концепцию неявного и явного человеко-компьютерного взаимодействий. Здесь Implicit Input — неявный ввод данных, Implicit Output — имплицитный результат, Explicit Output — явный вывод данных, User Input — ввод данных пользователем; Context — контекст, Application — приложение, Network System — сетевая система, The rest of the World — остальная часть мира.
1. Определение: неявное человеко-компьютерное взаимодействие (iHCI)
Имплицитное человеко-компьютерное взаимодействие — это интеракция человека со своей окружающей средой — включая искусственно созданные объекты — с целью достижения цели. В рамках этого процесса система получает неявный входные данные от пользователя и может представлять имплицитные выходные данные пользователю.
2. Определение: неявный ввод данных
Неявный ввод — это действия и поведение людей, осуществляемые для достижения цели и главным образом не рассматриваемые как взаимодействие с компьютером, но воспринимаемые, распознаваемые и интерпретируемые компьютерной системой как входные данные.
3. Определение: неявные выходные данные
Результат компьютерной обработки данных, который напрямую не связан с явным вводом информации и который беспрепятственно интегрируется с окружающей средой и задачей пользователя.
Неявное человеко-компьютерное взаимодействие не является альтернативой традиционной эксплицитной интеракции между человеком и компьютером — они достаточно независимы друг от друга. Чтобы сделать компьютеры более» внимательными» и естественными в использовании, нам нужны неявные каналы связи между людьми и компьютерами. Профессор Вычислительного факультета Ланкастерского университета Алан Дикс (Alan Dix) использовал для описания аналогичной концепции термин «побочное взаимодействие» (Incidental interaction).
8. Резюме и будущие направления деятельности
Контекстная осведомленность — захватывающая и сложная область человеко-компьютерного взаимодействия. Основная идея состоит в том, чтобы обеспечить компьютерам перцептивные качества («глаза и уши»), позволяющие устройствам распознавать ситуации, в которых пользователи взаимодействуют с информационными системами. Использование датчиков позволяет обнаруживать ситуации и классифицировать их в качестве контекстов. Сразу же как только система распознает, в каком контексте происходит взаимодействие, то эту информацию можно будет использовать для изменения, запуска и адаптации поведения приложений и систем. На стороне ввода данных в процессе неявного человеко-компьютерного взаимодействия рассматривается информация, генерируемая пользователями для того, чтобы взаимодействовать с реальным миром, и таким образом обеспечивается генерализация понимания контекста, в котором осуществляется интеракция.
Создание контекстно-зависимых интерактивных систем — задача не из простых. Следует иметь в виду, что пользователи учатся взаимодействовать с компьютерами, для чего приводят свое поведение в соответствие с системными требованиями. Очень важно, чтобы пользователи понимали вариативное и адаптивное поведение приложений и связывали его с ситуациями, в которых они находятся. В противном случае пользователи будут испытывать при изучении систем большие трудности .
Следовательно, центральной задачей разработчиков является создание понятных контекстно-зависимых систем, которые будут соответствовать ожиданиям пользователей. Если говорить коротко: хорошо спроектированная контекстная осведомленность — это великий и могучий способ создания дружественных в использовании приложений. Однако если все сделано неправильно, контекстно-зависимые приложения могут стать источником сильнейшего разочарования. Просто подумайте об автоматическом переключении освещения, и вы, вероятно, легко придумаете примеры, в которых такая система работает очень хорошо, и другие — в которых нет.
Осведомленность о местоположении как особая форма контекста стала главным направлением контекстно-зависимых вычислений, поскольку большинство телефонов среднего и высокого класса имеют GPS-приемник и другие средства для определения географической локации. Понимание местонахождения ваших друзей и семей в сочетании с навигацией для пешеходного передвижения, скорее всего, изменит способы, которыми мы координируем наше поведение, и мы постепенно начнем использовать нашу среду по-другому, поскольку технологии с течением времени изменяются. В будущем вам не придется звонить кому-нибудь, чтобы сообщить, что вы опаздываете на встречу, или спрашивать, где именно она произойдет — при необходимости эта информация будет легко доступна (ваши перемещения и местоположение будут известны лицам из вашей адресной книги). С точки зрения проектирования и исследований контекстно-зависимых систем большой проблемой при разработке подобных сценариев станет создание моделей интеракций, позволяющих индивиду контролировать свою видимость с минимальными усилиями и, возможно, косвенным, неявным образом.
Благодаря устройствам, которые позволяют нам более подробно отслеживать пользователей, контекстно-зависимая информация во все более возрастающих степенях будет присутствовать в потребительских устройствах. Представьте себе, что в бытовых приборах, оргтехнике, в рабочей и в домашней обстановке задействованы технологии, такие как камеры и датчик Kinect, устройство для обнаружения движения от Microsoft для игровой консоли Xbox 360. Возможность распознавания того, где люди находятся и что они делают, позволит дизайнерам создавать «внимательные» приложения — приложения, которые «смотрят», что вы делаете, а затем реагируют соответствующим образом. Душевая кабина узнает, какой из членов вашей семьи будет использовать ее (например, на основе профиля тела) и заблаговременно выберет предпочитаемую этим человеком температуру воды. Дизайнеры, минимально вступая во взаимодействие с устройствами, сумеют провести исследования того, как могут работать ваши приборы — потенциально просто «находиться там» достаточно воздействия на вашу окружающую среду. В этой области главная задача — обеспечить в пользовательском интерфейсе наличие средств, позволяющих исправить неверные решения, принятые системой, и способ, который поможет пользователю почувствовать, что всё находится у него под контролем.
Еще одна интересная сфера — это имплицитно создаваемый контент. Если мы находимся в окружающей среде, обильно оснащенной сенсорными устройствами, у нас появляется беспрецедентная возможность создавать модели того, как люди живут и взаимодействуют. Хорошим примером такого подхода является коллекционирование маршрутов GPS для создания карт для автомобилистов (результаты можно увидеть на сайте openstreetmap.org). Если бы у нас было аналогичное количество информации о том, какую пищу люди едят, о том, насколько хорошо они спят и сколь много они общаются друг с другом, мы могли бы делать выводы наподобие того, что «люди, которые едят яблоки между 5 и 7 часами вечера, спят на 20% лучше, чем люди, смотрящие мыльные оперы». Потратьте некоторое время и подумайте об этом примере. Мы полагаем, вы что сможете придумать множество свежих идей для контекстно-зависимых систем и приложений, но в то же время подобные перспективы могут и напугать вас. Обязанность разработчиков заключается в том, чтобы сделать окружающий мир лучше и интереснее при помощи имеющихся у них инструментов и технологий — и контекст представляет собой самое мощное из всех этих средств.
Высоких вам конверсий!
По материалам: interaction-design.org
