Сообщений 0 Оценка 0 Оценить |
Проблема создания эффективного человеко-машинного интерфейса становится все более актуальной с увеличением темпов развития высоких технологий окружающих человека. Нередко разработчики программных продуктов в погоне за технологическим преимуществом забывают о проектировании взаимодействия с пользователем. И, несмотря на то, что технический прогресс должен бы облегчать жизнь людей, такие программы становятся все более сложными в применении и не приносят пользователю ожидаемого удовлетворения. Разработчикам не стоит забывать, что программа является лишь инструментом для достижения определенных целей человека, а потому важна не эффективность программы отдельно, а производительность в совокупности с пользователем. Хорошо спроектированное взаимодействие делает пользователей продуктивными, довольными и счастливыми, и тогда они с радостью заплатят за продукт и посоветуют его другим. Таким образом, успешное проектирование – путь к лояльности потребителей и успеху бизнеса. Более того, нередко пользователи воспринимают более удобный продукт, как более мощный, даже при объективно меньшей функциональности[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[4] (Goals, Operators, Methods and Selection Rules), позволяет провести моделирование поведения пользователя. Идея метода заключается в следующем: взаимодействие пользователя с системой можно разбить на атомарные физические и когнитивные действия. Обладая знаниями о метриках каждой из таких составляющих, можно делать заключение об эффективности взаимодействия в целом: оценка эффективности интерфейса сводится к разбиению типовых задач на элементарные действия и сложению метрик каждого из них. В общем случае для анализа интерфейса выделяется четыре сущности:
Определение набора сущностей зависит от целей моделирования, определения эффективности интерфейса и самой рассматриваемой системы.
Распространенным вариантом этого метода для оценки времени, затрачиваемого на решение задачи, является Keystroke-level Model[5] (KLM). Этот метод выделяет следующие элементарные задачи и длительность каждой из них:
Оценка времени, затрачиваемого на решение задачи, сводится к сложению продолжительностей каждой из простейших составляющих. Так, например, продолжительность ввода слова из 10 символов будет равна десятикратной продолжительности нажатия на клавишу, а щелчок мыши – суммой нажатия и отпускания клавиши мыши.
Несмотря на то, что метод KLM не дает возможности изучить степень субъективного удовлетворения пользователя и время, необходимое на обучение, этот способ достаточно хорошо подходит для сравнения времени, необходимого для решения задачи в разных версиях интерфейса. Также метод позволяет сравнивать количество ошибок – оно считается пропорциональным количеству ситуаций, когда перед пользователем возникает неоднозначность действий. Кроме того, существенным плюсом KLM является и то, что он намного менее ресурсозатратен, чем полноценное юзабилити-тестирование.
Рассматриваемый программный продукт FlexiLayout Studio предназначен для разработки и отладки структурных описаний документов, используемых в системе потокового ввода ABBYY FlexiCapture. В используемой модели структура документа описывается деревом типизированных элементов, которые задают формат и содержимое определенных частей документа. Доступно 18 различных типов элементов для таких типов данных, как фиксированные варианты текста, дата, денежная сумма, штрих-код, текстовый абзац, регулярное выражение, число, телефон и т.д. Для каждого из элементов дерева может быть задан набор свойств, определяющих содержимое самого элемента (варианты текста, минимальное и максимальное значение, формат, выравнивание, количество символов, количество строк и т.д.), либо всего документа (обязательные и запрещенные элементы, возможное количество дочерних элементов в группе, допустимое количество экземпляров элемента и т.д.). Кроме того, для каждого элемента могут быть заданы ограничения области поиска – набор полуплоскостей, в которых элемент может быть найден. Ограничения области поиска могут быть заданы относительно границ изображения либо относительно расположения других, найденных ранее, элементов.
На основе заданных свойств и областей поиска определяется качество гипотезы того, что распознанное слово или множество слов является соответствующим элементом. Нарушение каждого из правил приводит к наложению определенного штрафа, размер которого зависит от степени нарушения и пользовательских настроек. В процессе анализа документа строится дерево гипотез – для каждой из гипотез расположения текущего элемента выдвигается множество гипотез расположения следующих элементов. Качество цепочки гипотез рассчитывается как произведение качеств каждой из гипотез этой цепочки. Результатом анализа является цепочка гипотез наилучшего качества, если качество такой цепочки превосходит предельное минимальное значение, в противном случае считается, что документ не соответствует заданному структурному описанию. В общем случае логика построения структурного описания заключается в определении статического «каркаса» документа и последующей локализации извлекаемых данных относительно его.
Проектирование взаимодействия в рамках работы производилось на основе предложенного А. Купером целеориентированного подхода, предполагающего использование системы персонажей. Поскольку рассматриваемая система достаточно узкоспециализирована, в нашем случае персонажи разделяются только по уровню знакомства с программой. После определения целей и поведенческих характеристик персонажей была произведена оценка существующего на момент начала проектирования решения. Последующая разработка и описание решений состояли из следующих этапов: описание контекстных сценариев, определения технических и внешних ограничений, выделение требований и конечного макетирования.
Так как ABBYY FlexiLayout Studio – достаточно узкоспециализированный инструмент, то полноценный контекстный анализ в совокупности с комплексом этнографических исследований пользователей не проводился. Персонажи разделяются, главным образом, на основе представления о предназначении системы и опыта ее использования. Тем не менее, в качестве основы для создания сценариев и понимания потребностей пользователей использовались данные, разработанные отделом аналитики и маркетинга. Поведенческие особенности уточнялись также в процессе наблюдения за пользователями на тренингах, интервьюирования новых и опытных пользователей и экспертов предметной области. В рамках описанного проектирования использовались два персонажа:
С точки зрения пользователя реализация FlexiLayout Studio 9 состоит из следующих элементов:
Рисунок 1. Пользовательский интерфейс системы ABBYY FlexiLayout Studio 9
Система изначально позиционировалась как профессиональный инструмент, и проектировалась с учетом целей и потребностей Разработчика. Большое количество типов и настроек элементов позволяет создавать гибкое описание высокого качества для обработки любых документов полужесткой структуры. Однако сильная нацеленность интерфейса на нужды Разработчика имеет минусы с точки зрения Новичка. Большое количество настроек требует времени на то, чтобы в них разобраться, а большое количество диагностической информации мешает сосредоточиться на главном и понять, что именно является наиболее важным в текущем контексте. В результате Новичок часто чувствует себя растерянным и не знает, какие действия стоит совершить на следующем шаге. Время, которое необходимо потратить на то, чтобы обучиться работе с системой, превышает его ожидания, и Новичок не получает должного удовлетворения от работы с системой.
Анализ показал, что текущее решение в большой степени соответствует целям Разработчика, поскольку проектировалось именно под его потребности и через призму его представления о предметной области. Тем не менее, были выявлены определенные недостатки, связанные с тем, что в сценариях его работы есть задачи, которые приходится решать достаточно часто, но при этом само решение требует больших усилий. К таким проблемам можно отнести сложность поиска и редактирования текущих зависимостей между элементами большого структурного описания, труднодоступность некоторых часто используемых команд и т. д. Автоматизация решения подобных задач достаточно сильно облегчит работу с приложением. Это привело к созданию таких решений как браузер зависимостей между элементами описания или кастомизация сочетаний горячих клавиш. Однако эти решения лежат за рамками данной статьи и не будут описаны подробнее.
Цель Новичка – за короткое время получить несложное работоспособное гибкое описание. Также Новичок хотел бы иметь удобный способ разобраться с возможностями и тонкостями работы системы, стать Разработчиком. Для определения проблем, которые возникают у Новичка в процессе обучения работе с системой, было проведено исследование, состоящее из трех частей:
Проведенные исследования позволили определить те стороны взаимодействия, которые вызывают у Новичка наибольшие сложности, понять представление Новичка о работе системы, а также о структуре гибкого описания и документов. В общем виде найденные проблемы могут быть разделены на две группы:
Поскольку, с одной стороны, текущее решение далеко от модели представления новичка и не удовлетворяет его целям и потребностям, а с другой – хорошо удовлетворяет потребностям Разработчкика, для которого важна тонкая настройка, было принято решение спроектировать для Новичка новый интерфейс взаимодействия. Созданный интерфейс должен соответствовать основной потребности – быстрому созданию гибкого описания приемлемого качества, не требующему длительного предварительного обучения работе с системой. Таким образом, он станет переходным этапом к существующему решению, облегчив процесс изучения тонкостей настройки гибких описаний.
В составе целеориентированного метода проектирования интерфейса на основе персонажей выделены четыре основных вида деятельности:
Детализация сценариев, таким образом, проводится до необходимой степени, наполняя структуру взаимодействия все более детальными описаниями и решениями. На основе анализа информационных и функциональных потребностей пользователя, а так же имеющихся ограничений, выделяются технологические требования, информационные и функциональные элементы. С учетом того, как объекты интерфейса соответствуют рабочему процессу персонажа, строится макет общей инфраструктуры взаимодействия. В совокупности с детальными описаниями сценариев, макет образует проект взаимодействия, используемый на этапе программной реализации интерфейса.
С точки зрения Новичка идеальный базовый сценарий взаимодействия с приложением выглядит следующим образом:
Поскольку система не может гарантировать создания идеального гибкого описания, а понятие приемлемого качества гибкого описания зависит от потребностей и представлений конкретного пользователя, необходима возможность контроля качества наложения описания со стороны пользователя. Если качество наложения созданного описания оказывается неудовлетворительным, система должна иметь возможность улучшить описание, учитывая ошибки наложения. Таким образом, базовый сценарий взаимодействия должен включать в себя шаги контроля и улучшения качества создаваемого гибкого описания и приобретает следующий вид:
Добавление изображений в проект – стандартная и знакомая Новичку операция, похожая на добавление фотографий в альбом или песен в список воспроизведения. Задачи и сценарии ничем не отличаются от добавления изображений в текущем решении, а соответственно, и взаимодействие стоит в полной мере наследовать из существующего решения.
Чтобы пользователь мог указать, какие именно данные необходимо извлекать, в интерфейсе должна быть представлена сущность, соответствующая тому, что извлекаем – поле. Пользователь должен различать поля, то есть у них должны быть идентификаторы, или, с точки зрения пользователя – имена. Часто суть обрабатываемых документов такова, что извлекать данные не имеет смысла, если не найдено одно из ключевых полей, поэтому должна быть возможность указать для части полей, что они являются обязательными. Существует два стандартных, привычных Новичку, способа указать расположение объекта на изображении документа – нарисовать на изображении документа область, содержащую данные, или выделить символ, слово или строку, которая им соответствует. Таким образом, с каждым полем должен соотноситься определенный регион на изображении документа. Для того чтобы понимать, какие поля уже размечены на документе, должна быть визуальная дифференциация размеченных и не размеченных элементов. Так как часть полей может отсутствовать на документе, должна быть возможность отметить элемент как отсутствующий.
На этапе создания описания, в идеале, от пользователя требуется только сообщить системе, что на выбранных страницах указаны все регионы данных, которые необходимо извлечь. Однако есть ряд технологических ограничений, связанных с автоматизацией создания описания: принципы наложения гибкого описания подразумевают, что поиск полей производится относительно статического текста. Тестирование методов автоматического поиска статического текста показало, что поиск реперного текста на основе анализа положения полей показывает удовлетворительные результаты только на документах достаточно жесткой структуры. Следовательно, в случаях, когда автоматический поиск реперов не дает желаемого результата, должна быть возможность задать положение реперного текста вручную. То есть помимо самих данных (полей) в интерфейсе должна быть представлена сущность статический текст, с точки зрения пользователя – подпись к данным. Автоматически создаваемое описание достаточно чувствительно к структуре документа, поэтому для получения приемлемого качества необходимо создавать различные альтернативные описания для документов разной структуры. То есть должна быть возможность разделить документы на классы. При этом, как правило, наборы реперных элементов могут сильно различаться для документов различной структуры, поэтому каждому классу должен соответствовать свой набор реперных элементов. Для того чтобы альтернативы не накладывались на документы чужого класса, нужны идентификаторы (как правило, заголовки) – по сути, обязательный статический текст, поэтому у реперов тоже должно быть свойство обязательности.
Необходимо обеспечить удобный способ проверки качества наложения. Поскольку речь идет о небольшом количестве полей и малом количестве документов, достаточно удобно будет просмотреть наложение на страницы. При переходе на следующий документ можно автоматически накладывать гибкое описание, созданное на основе имеющейся разметки. На основе результатов наложения можно создать регионы элементов: полей и статического текста. Таким образом, в процессе разметки страниц для создания описания, пользователь может увидеть, насколько хорошо накладывается описание, а значит – понять, насколько хорошим будет описание, если создать его уже сейчас. Кроме этого, такой подход позволит автоматизировать сам процесс разметки документов: если описание наложилось хотя бы частично правильно – количество полей и реперов, которые надо размечать вручную, уменьшилось; если же все элементы описания наложились неправильно – пользователю просто надо указать регионы для всех элементов, как если бы ничего и не накладывалось. Кроме того, плохое наложение может быть подсказкой пользователю о том, что документ необходимо выделить в новый класс, или что класс документа указан неверно. Для того чтобы понять по набору регионов, полученных в результате наложения, насколько хорошо наложилось описание, надо иметь возможность быстро установить соответствие "регион-элемент".
Таким образом, был получен следующий набор требований:
Выделены объекты взаимодействия:
Описанные ограничения и решения приводят к следующему сценарию:
Интерфейс автоматической генерации гибкого описания состоит из окна пакета, окна элементов обучения и окна изображений.
Рисунок 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.
FlexiLayout Studio 9 |
FlexiLayout Studio 11 |
|
Разработчик |
255,73 |
210,43 |
Новичок |
324,31 |
281,19 |
FlexiLayout Studio 9 |
FlexiLayout Studio 11 |
|
Разработчик |
58 |
40 |
Новичок |
65 |
44 |
Согласно результатам тестирования, время, необходимое на создание типового гибкого описания, сократилось на 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.
Сообщений 0 Оценка 0 Оценить |