Сообщений 0    Оценка 0        Оценить

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

Автор: Ланин Михаил Олегович

Опубликовано: 12.01.2015
Исправлено: 10.12.2016
Версия текста: 1.1

Введение

Проблема создания эффективного человеко-машинного интерфейса становится все более актуальной с увеличением темпов развития высоких технологий окружающих человека. Нередко разработчики программных продуктов в погоне за технологическим преимуществом забывают о проектировании взаимодействия с пользователем. И, несмотря на то, что технический прогресс должен бы облегчать жизнь людей, такие программы становятся все более сложными в применении и не приносят пользователю ожидаемого удовлетворения. Разработчикам не стоит забывать, что программа является лишь инструментом для достижения определенных целей человека, а потому важна не эффективность программы отдельно, а производительность в совокупности с пользователем. Хорошо спроектированное взаимодействие делает пользователей продуктивными, довольными и счастливыми, и тогда они с радостью заплатят за продукт и посоветуют его другим. Таким образом, успешное проектирование – путь к лояльности потребителей и успеху бизнеса. Более того, нередко пользователи воспринимают более удобный продукт, как более мощный, даже при объективно меньшей функциональности[‎1], в то время как сложное и неудобное взаимодействие даже в части процессов создает ощущение перегруженности всего продукта и отталкивает пользователя.

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

В данной работе проблема построения эффективного человеко-машинного взаимодействия рассматривается на примере системы ABBYY FlexiLayout Studio – инструмента для создания структурных описаний документов с нежесткой структурой, то есть тех документов, на которых расположение однотипных данных может варьироваться от одного экземпляра к другому. В основе процесса создания пользовательского интерфейса лежал целеориентированный подход, предложенный Аланом Купером[‎2], одним из пионеров в области проектирования эффективного взаимодействия. Построенные с использованием этого подхода сценарии позволили выявить набор функциональных и информационных требований, а также спроектировать и реализовать интерфейс режима автоматического создания гибких описаний с использованием образцов документов. Оценка эффективности описанных решений показала практическую применимость данного подхода при создании коммерческого программного продукта. Предложенные решения были реализованы в рамках разработки системы FlexiLayout Studio 10 и 11.

Методы проектирования взаимодействия

Проектирование поведения продуктов и систем – проектирование взаимодействия – область довольно новая, которая только в последние годы начала обретать зрелость в качестве самостоятельной дисциплины. На данный момент наибольшую известность получил предложенный А. Купером целеориентированный подход проектирования взаимодействия, являющийся логичным развитием метода ACD (Activity-Centered Design) и психологической теории деятельности А.Н.Леонтьева.

Проектирование, направленное на деятельность

В основе метода проектирования, направленного на деятельность(Activity-Centered Design, ACD), лежит психологическая Теория Деятельности, предложенная А.Н. Леонтьевым в начале 30-х годов 20 века. Впервые применение теории в рамках человеко-машинного взаимодействия было предложено Бонни Нарди в начале 90-х годов прошлого века^[‎6]. Согласно теории, пользователи воспринимаются не как личности, имеющие характерные привычки и пожелания, а скорее как участники некоторой деятельности. Предпочтениями пользователя можно в разумной степени пренебречь, ведь если продукт достаточно хорошо удовлетворяет осуществлению определенной деятельности, человек охотно к нему приспособится. В качестве подтверждения теории упоминается высокая популярность множества сложных технических систем, таких как автомобили или мобильные телефоны, использованию которых обучается большое количество самых разных людей, несмотря на то, что само по себе подобное взаимодействие не заложено в природу человека^[‎8].

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

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

Целеориентированное проектирование

Целеориентированный подход к проектированию (Goal-Directed Design, GDD) был предложен Аланом Купером в 1995 году^[‎1]. Развивая метод проектирования, направленного на деятельность, А. Купер отмечает, что в реальности деятельность не образуется сама по себе, а всегда обусловлена некоторой целью. Соответственно, понимание этих целей позволяет понять ожидания и устремления пользователя, а значит определить виды деятельности, реально имеющие отношение к проектированию продукта. Необходимо отличать цели от задач и деятельности: тогда как цели - это предвосхищение конечного состояния, задачи и деятельность - лишь промежуточные этапы, необходимые для достижения целей.

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

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

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

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

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

Методы оценки эффективности пользовательского интерфейса

Оценка эффективности пользовательского интерфейса – субъективный и трудно формализуемый процесс. В общем случае определение эффективного взаимодействия может быть сформулировано следующим образом: более качественное взаимодействие делает пользователя более эффективным. Определение эффективности зависит от задач, решаемых пользователем с помощью системы, продолжительности взаимодействия с пользователем, среды взаимодействия и многих других факторов. Универсальных общепризнанных критериев эффективности не существует, однако, на практике, как правило, рассматривается набор показателей Шнейдермана^[‎9]:

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

Значимость каждого показателя определяется в каждом конкретном случае в зависимости от контекста использования системы.

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

Методы оценки интерфейса при непосредственном участии потенциальных пользователей

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

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

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

Методы оценки интерфейса без непосредственного участия потенциального пользователя

Наиболее распространенные методы тестирования без непосредственного участия пользователя могут быть разделены на два класса: экспертная оценка и методы формальных расчетов на основе GOMS (Goals, Operators, Methods and Selection Rules). Экспертная оценка подразумевает выявление слабых и сильных сторон интерфейса экспертом на основе того, насколько интерфейс соответствует выработанным ранее правилам и рекомендациям. Метод GOMS заключается в моделировании поведения пользователя на основе разбиения процесса взаимодействия на атомарные физические и когнитивные действия.

Экспертная оценка

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

Однако, этот подход обладает и рядом недостатков:

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

GOMS

Другой распространенный метод оценки эффективности интерфейса – метод, называемый GOMS^[‎4] (Goals, Operators, Methods and Selection Rules), позволяет провести моделирование поведения пользователя. Идея метода заключается в следующем: взаимодействие пользователя с системой можно разбить на атомарные физические и когнитивные действия. Обладая знаниями о метриках каждой из таких составляющих, можно делать заключение об эффективности взаимодействия в целом: оценка эффективности интерфейса сводится к разбиению типовых задач на элементарные действия и сложению метрик каждого из них. В общем случае для анализа интерфейса выделяется четыре сущности:

1. Цели, которых хочет добиться пользователь в результате взаимодействия с системой.
2. Операторы – элементарные действия, которые пользователь может совершать в рамках взаимодействия с системой.
3. Методы – последовательности операторов, которые приводят к достижению целей.
4. Правила выбора, описывающие, когда и почему пользователь выбирает один из конкурирующих методов для достижения конкретной цели.

Определение набора сущностей зависит от целей моделирования, определения эффективности интерфейса и самой рассматриваемой системы.

Распространенным вариантом этого метода для оценки времени, затрачиваемого на решение задачи, является Keystroke-level Model^[‎5] (KLM). Этот метод выделяет следующие элементарные задачи и длительность каждой из них:

• нажатие на клавишу клавиатуры в зависимости от опыта уровня владения клавиатурой: профессиональный наборщик – 0,08 сек, эксперт – 0,12 сек, частая работа с текстом – 0,20 сек, продвинутый пользователь – 0,28 сек, неуверенный пользователь – 0,5 сек, не знакомый с клавиатурой (раскладкой) – 1,2 сек;
• навести мышь на объект на экране – 1,1 сек;
• нажатие или отпускание клавиши мыши – 0,1 сек;
• перевод руки с мыши на клавиатуру или обратно – 0,4 сек;
• выбор действия – 1,2 сек;
• ожидание ответа системы.

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

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

Модель структурного описания документов

Рассматриваемый программный продукт FlexiLayout Studio предназначен для разработки и отладки структурных описаний документов, используемых в системе потокового ввода ABBYY FlexiCapture. В используемой модели структура документа описывается деревом типизированных элементов, которые задают формат и содержимое определенных частей документа. Доступно 18 различных типов элементов для таких типов данных, как фиксированные варианты текста, дата, денежная сумма, штрих-код, текстовый абзац, регулярное выражение, число, телефон и т.д. Для каждого из элементов дерева может быть задан набор свойств, определяющих содержимое самого элемента (варианты текста, минимальное и максимальное значение, формат, выравнивание, количество символов, количество строк и т.д.), либо всего документа (обязательные и запрещенные элементы, возможное количество дочерних элементов в группе, допустимое количество экземпляров элемента и т.д.). Кроме того, для каждого элемента могут быть заданы ограничения области поиска – набор полуплоскостей, в которых элемент может быть найден. Ограничения области поиска могут быть заданы относительно границ изображения либо относительно расположения других, найденных ранее, элементов.

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

Проектирование взаимодействия

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

Система персонажей

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

1. Разработчик – человек, создающий сложные гибкие описания для крупных проектов. Типичный представитель этой группы – сотрудник процессингового центра. Создание и настройка гибких описаний – большая часть рабочей деятельности этого персонажа. Для гибких описаний, разрабатываемых Разработчиком, характерны большой объем и разнообразие обрабатываемых документов. Разработчик имеет навыки программирования и хорошо разбирается в тонкостях построения гипотез и штрафов. Целью Разработчика является создание гибкого описания оптимального по времени и надежности наложения.
2. Новичок – начинающий разработчик гибких описаний, имеющий общее представление о работе системы. Для его описаний характерен небольшой объем и разнообразие обрабатываемых документов. Цель Новичка – быстрое создание приемлемо работающего описания с возможностью дальнейшей доработки. Новичок хорошо знаком с офисными приложениями и, вероятно, имеет общее представление об основах программирования. Готов разбираться в тонкостях работы системы, если это принесет существенное улучшение за разумное время.

Обзор текущего решения

С точки зрения пользователя реализация FlexiLayout Studio 9 состоит из следующих элементов:

1. Главное меню. Содержит меню File, Edit, View, Batch, Image, FlexiLayout/Classifier, Tools и Help, обеспечивающие быстрый доступ к часто используемым командам.
2. Панель инструментов Standard содержит кнопки вызова команд, выполняющих стандартные действия: открыть проект, создать проект, сохранить, вырезать, копировать, вставить, отменить действие и повторить действие. А так же две команды навигации по изображениям документов: переход на предыдущую и следующую страницу.
3. Панель инструментов Extracted Objects содержит кнопки, позволяющие отображать и скрывать на изображении объекты, выделенные при предраспознавании.
4. Панель инструментов Tools содержит кнопки, позволяющие активировать текущий инструмент для выделения региона элемента, измерения размеров объекта, создания и редактирования эталонной разметки.
5. Панель инструментов Image Tools содержит кнопки, позволяющие повернуть, отразить и инвертировать изображение, а также изменить масштаб изображения.
6. Панель инструментов Layout содержит кнопки, позволяющие просматривать тестовые изображения в различных режимах: эталонный, наложенный и дифференсный.
7. Окно пакета Batch содержит список изображений, добавленных пользователем для создания и отладки гибкого описания. Для каждой страницы отображается диагностическая информация и результаты операций, выполненных с изображением:

• Page No. – номер страницы;
• Recognized – выполнено ли предраспознавание;
• Analyzed – наложено ли гибкое описание;
• Has Reference Blocks – была ли создана эталонная разметка блоков;
• Matched Document Number – номер документа, к которому отнесена данная страница в процессе наложения описания;
• Matched Sequence Number – номер страницы в документе, который был ей присвоен в процессе наложения описания;
• Reference Document Number – номер документа, к которому должна относиться страница согласно эталонной сборке;
• Reference Sequence Number – номер страницы в документе, который должен быть присвоен странице согласно эталонной сборке;
• Excess Areas – результаты сравнения наложения гибкого описания и эталонной разметки, показывается суммарная площадь областей блоков, найденных при наложении, но не вошедшие в блоки эталонной разметки, выраженная в процентах по отношению к суммарной площади блоков эталонной разметки;
• Missing Areas – результаты сравнения наложения гибкого описания и эталонной разметки, показывается суммарная площадь областей блоков эталонной разметки, не вошедших в блоки, полученные при наложении, выраженная в процентах по отношению к суммарной площади блоков эталонной разметки;
• Matched Alternative – наименование варианта гибкого описания, наложенного на страницу;
• Reference Alternative – эталонный вариант гибкого описания;
• Comment – комментарий к данному изображению;
• Source – путь к исходному файлу изображения.

1. Окно элементов описания FlexiLayout отображает древовидную структуру гибкого описания. Описание состоит из ветви блоков и нескольких ветвей элементов, каждая ветвь элементов соответствует альтернативе гибкого описания.
2. Блок гибкого описания позволяет вычислить положение поля документа, из которого в дальнейшем необходимо извлечь данные в системе обработки форм. Расположение блоков может быть найдено или вычислено при помощи элементов, а также задано в виде абсолютных координат. Целью создания гибкого описания является задание алгоритма поиска блоков на изображении документа.
3. Элементы используются для поиска различных объектов изображения. Для каждого объекта или группы объектов, которые необходимо найти на изображении, в гибком описании создается элемент. Поддержано 15 видов типизированных элементов для поиска информации, таких как дата, телефон, валюта, штрих-код, статический текст и т.д. Для каждого из элементов есть возможность настроить систему характеристик (длина строки в символах, пределы численных значений, длина, ширина), штрафов (штраф за перенос строки, превышение количества символов) и область поиска, в которой предположительно находится объект.
4. Блоки описания не зависят друг от друга. Элементы можно группировать, формируя дерево любой степени вложенности, в котором элементы логически связаны друг с другом и могут искаться относительно друг друга. Иерархическая группировка элементов позволяет оптимизировать их поиск. Порядок расположения элементов в дереве соответствует порядку их поиска, т.е. при наложении описания на изображение программа будет искать элементы последовательно от верхних к нижним. При этом на изображении ищутся объекты, соответствующие элементам, а затем, ориентируясь на основании информации о найденных элементах, определяются координаты блоков.
5. Окно Properties отображает свойства объекта, выбранного в окне Batch, FlexiLayout, Image или Hypotheses. В нижней части окна дается описание выбранного свойства и его значение.
6. В окне Image показано изображение, соответствующее странице, выбранной в окне Batch. В заголовке окна указывается номер документа, наименование варианта гибкого описания, номер открытой страницы и режим просмотра. Также указываются признаки Header и Footer, если они присутствуют у данной страницы в выбранном режиме просмотра.
7. В окне Image возможно три режима просмотра изображения:

• в режиме Matched layout отображаются результаты наложения гибкого описания;
• в режиме Reference layout можно создавать, редактировать и просматривать эталонную разметку;
• в режиме Difference layout отображаются различия между результатом наложения гибкого описания и эталонной разметкой.

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

Рисунок 1. Пользовательский интерфейс системы ABBYY FlexiLayout Studio 9

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

Улучшение интерфейса с точки зрения Разработчика

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

Улучшение интерфейса с точки зрения Новичка

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

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

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

1. Отдаленность модели представления от ментальной модели пользователя. Нередко пользователь не может разобраться с тем, что происходит, так как его представление сильно отличается от того, как сущность представлена в интерфейсе.
2. Большое количество настроек требует большого времени для того, чтобы получить первый приемлемый результат. Не всегда понятно, какие настройки действительно критичны для успешного наложения описания.

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

В составе целеориентированного метода проектирования интерфейса на основе персонажей выделены четыре основных вида деятельности:

1. Создание сценариев – повествовательного описания идеального с точки зрения пользователя взаимодействия
2. Определение требований, соответствующих действиям, объектам и контексту исходя из сценариев
3. Выявление ограничений на основе анализа требований. Ограничения могут быть как внутренними по отношению к системе (технические), так и внешние (временные, бюджетные, культурные и т.д.)
4. Формулировка решений, уточняющих исходный сценарий с учетом выявленных ограничений и требований.

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

Базовый сценарий взаимодействия

С точки зрения Новичка идеальный базовый сценарий взаимодействия с приложением выглядит следующим образом:

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

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

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

Детализация сценария взаимодействия

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

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

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

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

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

Таким образом, был получен следующий набор требований:

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

Выделены объекты взаимодействия:

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

Макетирование интерфейса и описание взаимодействия

Описанные ограничения и решения приводят к следующему сценарию:

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

Интерфейс автоматической генерации гибкого описания состоит из окна пакета, окна элементов обучения и окна изображений.

Рисунок 2. Макет интерфейса автоматического создания гибкого описания. Класс документа с выключенной опцией автоматического создания реперных элементов.

Окно пакета содержит список добавленных изображений документов и отображает для них следующую информацию:

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

Документ может быть добавлен или исключен из набора обучения с помощью установки или снятия флажка в соответствующей колонке. Возможно добавление или исключение группы страниц из набора обучения с помощью команд контекстного меню Add Selected Pages to Training Set, Remove Selected Pages from Training Set и Use Selected Pages for Training.

Колонка Training Layout State содержит одну из пиктограмм, соответствующих наличию на странице неразмеченных элементов:

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

В колонке Reference Alternative отображается имя класса документа, установленного пользователем.

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

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

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

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

В окне изображений отображаются добавленные образцы документов, результаты распознавания и регионы элементов описания. Регионы элементов описания могут быть указаны двумя способами: двойным щелчком по региону элемента распознавания или рисованием региона элемента непосредственно на изображении. Имя текущего размечаемого элемента пишется возле курсора инструмента разметки. Элемент может быть отмечен как отсутствующий на изображении с помощью команды Not Present или щелчка средней клавишей мышью. Каждый регион, соответствующий полю или реперу, имеет подпись, соответствующую имени элемента.

Генерация гибкого описания запускается пользователем после окончания процесса разметки. При запуске генерации пользователю показывается диалог выбора альтернатив для обучения.

Рисунок 3. Диалог выбора альтернатив для генерации

Диалог содержит список альтернатив, входящих в набор обучения, и кнопки Generate и Cancel. В списке альтернатив пользователь отмечает те, которые надо заменить при обучении. При показе диалога в списке отмечены и находятся сверху те альтернативы, разметка обучения для которых изменилась с момента последнего создания гибкого описания.

Оценка эффективности предложенных решений

Предложенные решения были реализованы на языке C++ в рамках разработки 10 и 11 версий системы ABBYY FlexiLayout Studio. В качестве критериев эффективности реализованного интерфейса, рассматривался набор показателей Шнейдермана^[‎9]:

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

С точки зрения Разработчика, наибольшую значимость имеет показатель скорости работы, тогда как для Новичка на первый план выходит скорость обучения. Еще одним значимым параметром, с точки зрения обоих, является количество человеческих ошибок. С учетом нерегулярного использования системы Новичком, для него важным фактором является и сохраняемость навыков.

Метод оценки эффективности интерфейса Keystroke-level Model (KLM), позволяет хорошо оценить скорость работы и количество ошибок пользователя, и является намного менее ресурсоемким, чем полноценное юзабилити-тестирование. Поэтому, с учетом технических и временных ограничений, именно этот подход использовался для оценки эффективности предложенных и реализованных улучшений текущего решения с точки зрения Разработчика и Новичка. В качестве тестового сценария было использовано задание тренинга по использованию системы FlexiLayout Studio, описывающее порядок создания типичного гибкого описания простой структуры. В соответствии с описанным сценарием были составлены протоколы выполнения заданий персонажами Разработик и Новичок с использованием продуктов FlexiLayout Studio 9 и 11 версии. Результаты тестирования представлены в таблицах 3 и 4.

Согласно результатам тестирования, время, необходимое на создание типового гибкого описания, сократилось на 18% с точки зрения Разработчика и на 13% c точки зрения Новичка. При этом количество ситуаций, требующих от пользователя принятия решения о дальнейшем действии, а значит, и количество потенциальных ошибок, сократилось практически в полтора раза, как для Новичка, так и для Разработчика.

Анализ эффективности интерфейса автоматического создания гибкого описания с точки зрения Новичка производился с помощью метода экспертной оценки. Такое решение было принято, потому что сохраняемость навыков, как и скорость обучения, на практике очень плохо измеримы. Предполагаемое повышение скорости обучения обусловлено тем, что для создания гибкого описания простой структуры, достаточно нарисовать регионы для 4-5 полей на 5-6 страницах. То есть необходимо нарисовать 25-30 регионов, при том, что в исходном интерфейсе представлено 17 типов элементов, каждый из которых имеет от 3 до 7 типизированных свойств. О высокой скорости обучения свидетельствует тот факт, что на тренингах по использованию системы FlexiLayout Studio оказалось достаточным ввести всего одно задание, посвященное режиму автоматического создания описаний. Как отмечают тренеры, из 13 выполняемых во время тренинга заданий, именно это, как правило, не вызывает вопросов пользователей.

Заключение

В данной работе были выделены проблемы взаимодействия с пользователем системы ABBYY FlexiLayout Studio 9. Были предложены решения выделенных проблем; предложенные решения были реализованы в рамках разработки FlexiLayout Studio 10 и FlexiLayout Studio 11.

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

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

Список литературы

1. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. – Пер. с англ. – СПб.: Символ-Плюс, 2010. – 688 c.
2. Купер А. Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. – Пер. с англ. – СПб.: Символ-Плюс, 2004. – 336 c.
3. Пономарев И.А. Методы оценки качества пользовательского интерфейса. Интеллектуальные технологии и системы (сборник статей). Выпуск 4. – М.:Изд-во МГТУ им. Н.Э.Баумана, 2002.
4. Card S., Moran T., Newell A. The Psychology of Human Computer Interaction. Lawrence Erlbaum Associates, 1983. – 488 с.
5. Kieras D.: Using the Keystroke-Level Model to Estimate Execution Times. The University of Michigan. Unpublished report, 1993. URL: http://www.pitt.edu/~cmlewis/KSM.pdf
6. Nardi B. Context and Consciousness: Activity Theory and Human-Computer Interaction. MIT Press, 1996. – 407 с.
7. Norman D. Emotional design : why we love (or hate) everyday things. New York : Basic Books, 2004. – 257 c.
8. Norman D. Human-centered design considered harmful. Interactions, 12.4, July 01 2005.
9. Shneiderman B., Plaisant C. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley, 2005 – 652 с.

Сообщений 0    Оценка 0        Оценить