Разработка адаптивного пользовательского интерфейса Eclipse
Разработка адаптивного пользовательского интерфейса Eclipse
Alex Leung, Scott Morisson, Matt Wringe and Ying Zou
Department of Electrical and Computer Engineering
Queen’s University
Kingston, Ontario, Canada
{2akyl,
1mw, 2esm}@qlink.queensu.ca, [email protected]
АННОТАЦИЯ
Во время проектирования и разработки программных приложений удобством пользовательских интерфейсов часто пренебрегают. Интегрированная среда разработки Eclipse (IDE) вызывает некоторые трудности в процессе работы с ней по причине своей богатой функциональности, выраженной добавлениями внешних встраиваемых функций-расширений и возможностями
панели управления пользовательской базы Eclipse (от новичка до разработчика-специалиста).
Чтобы повысить удобство пользовательского интерфейса Eclipse, мы предлагаем использовать архитектуру адаптивного интерфейса пользователя (AUI), которая изменяет существующее Eclipse меню. Система основывается на статистических моделях взаимодействия пользователя с пользовательским интерфейсом.
В частности, AUI скрывает редко используемые элементы меню и предугадывает, какой элемент меню пользователь, вероятно, вызовет.
Кроме того, мы разрабатываем адаптивные алгоритмы, которые выполняют анализ затрат и выгод для принятия изменений в меню
системы, а также определяют оптимальные изменения, которые следует внести.
Прототип
AUI разрабатывается как встраиваемая функция-расширение
Eclipse. Прежде всего мы рассмотрим те улучшения,
которых удалось добиться по сравнению
с нынешней системой меню Eclipse с помощью
адаптивного интерфейса пользователя.
- ВВЕДЕНИЕ
Компьютерная система Xerox 8010 была внедрена в 1981 году.
Она была первым компьютером, использовавшим окна, иконки, меню и указатели (WIMPS) как основу пользовательского интерфейса (UI). С тех пор способы взаимодействия пользователя с программным продуктом практически не изменились.
Для выполнения растущих требований со стороны делового мира, программные приложения постепенно менялись для того, чтобы выполнять более сложные функции. Чтобы повысить удобство использования программных продуктов, многие исследователи предложили методики для проектирования и разработки адаптивных пользовательских интерфейсов.
Предложенные методики реагируют на различные ситуации и требования посредством изучения поведенческих схем и стиля каждого конкретного пользователя.
Ранние работы над адаптивным пользовательским интерфейсом сосредотачивались на отслеживании поведении пользователей посредством Интернет-браузера и предугадывании интересов пользователя. Предыдущее исследование анализирует поведение пользователей при соответствии ключевых слов в веб-документах.
Помощник Microsoft Office использует результаты проекта Lumiere, который применяет сеть Bayesian, чтобы предугадать грядущие события и конечную цель и вывести список возможных потребностей пользователя, анализируя буфер обмена пользователя, действия и запросы.
Microsoft Word Office и Windows XP могут динамично скрывать редко используемые элементы меню. Однако такие программные продукты не в состоянии прогнозировать возможные будущие шаги.
В работе представлены данные о методах, которые обеспечивают персонализированную, сиюминутную помощь пользователям и автоматически извлекают схемы последовательности работы пользователя исходя из движений мышки, в том числе и при редактировании текста, создаваемого пользовательским интерфейсом.
Результаты этого исследования используются при редактировании текста.
Тем не менее, несмотря на все эти достижения, использованием IDE зачастую пренебрегают, отдавая предпочтение UI, программе сложной и трудной в эксплуатации.
А ведь IDE часто располагают широким спектром функций, способных помочь в разработке различных проектов, так как они и проектируются для того, чтобы удовлетворить любые требования пользователей.
По этой причине все функциональные возможности программы доступны пользователям в любое время, чего не скажешь об UI.
Такие IDE, как Eclipse (то есть Java среды разработки с открытым исходным кодом), часто позволяют подключить внешние модули расширения для увеличения функциональности.
Подобные внешние модули расширения располагают своими собственными компонентами UI (например, дополнительное меню иконок и значков), которые еще более усложняют поставленную задачу.
Удобство
является важным фактором, который
влияет на производительность пользователей.
Использование громоздкой, сложной и трудной UI, наверняка, снизит эффективность пользователя, и они могут перейти на альтернативные программные приложения.
Поэтому совершенствование популярных в настоящее время WIMPS парадигм должно привести к обеспечению более эффективного и приятного интерфейса для IDES.
Чтобы повысить эффективность пользователей IDES,
Гильдия проектов [11] расширяет возможности интерфейса Eclipse для
начинающего пользователя.
И тем не менее, пользовательский интерфейс предоставляет статические функции в меню.
В этой статье мы предлагаем адаптивную архитектуру пользовательского интерфейса (AUI), которая динамически адаптируется под интерфейс пользователя для любой программы, используемой разработчиком ежедневно, как, например, программы написания кода, компиляции и отладки.
В частности, наш адаптивный пользовательский интерфейс (AUI) разработан как плагин, то есть встраиваемый, для Eclipse, а также он постоянно работает в фоновом режиме для сбора статистики о том, как пользователь взаимодействует с системой меню.
Например, для разработчиков, которые сосредоточены на отладке кода, мы будем скрывать такие нерелевантные меню, как "Файл" и "Навигатор".
В отличие от предыдущих работ, в основе которых лежал план будущих действий пользователя, мы также разрабатываем такие адаптивные алгоритмы, как Fade (постепенно изменяющийся) и Enlighten (оповещение), которые выполняют анализ затрат и прибылей, когда необходимо внести изменения в меню, а также определяют оптимальные изменения, которые следует внести в меню системы.
Например,
благодаря использованию
Такая методика может уменьшить объём элементов меню и позволяет получать быстрый доступ к элементам меню, которые наиболее часто используются.
Чтобы ещё больше повысить эффективность использования, наш подключаемый модуль перемещает те элементы, которые, как предсказывает алгоритм Enlighten, пользователь выберет в следующий момент, в начало меню.
Решения, какие элементы меню скрыть, а какие переместить, оцениваются предлагаемыми нами экономически эффективными формулами.
Последующая часть работы построена следующим образом.
Раздел
2 – это руководство
В разделе 3 обсуждается конструкция нашего адаптивного пользовательского интерфейса. В разделе 4 представлены результаты наших исследований. В разделе 5 мы подводим итоги и описываем планы на будущее.
- СИСТЕМЫ ВЗАИМОДЕЙСТВИЯ С ПОЛЬЗОВАТЕЛЬСКИМ МЕНЮ
Из-за
присутствия человеческого
Однако все ещё допустимо использовать метрики и определённую методологию, чтобы количественно измерить, сравнить, и улучшить удобство и простоту его использования.
Вообще, удобство и простота использования – это качественный признак программного обеспечения, показывающий степень, с которой можно использовать приложение, чтобы достичь эффективности и цели в заданном контексте [4].
Более того, удобство и простоту использования можно охарактеризовать пятью признаками:
- скорость обучения, которая отражает простоту освоения прикладных функциональных возможностей;
- эффективность, которая показывает простоту использования и
- уровень производительности, которого может достичь пользователь;
- запоминаемость, которая отражает легкость запоминания функциональных возможностей системы;
- низкая вероятность ошибки, которая показывает, как пользователям с помощью системы поддержки делать меньше ошибок;
(5)
удовлетворённость
насколько пользователям нравится приложение.
В
нашем исследовании мы стремимся усовершенствовать
все пять признаков удобства и простоты
использования системы с помощью адаптивного
пользовательского интерфейса.
2.1
Модель пользователя
Чтобы лучше понять, каким образом повысить удобство и простоту использования меню системы, мы количественно определяем удобство использования и строим упрощенные модели пользователя, имитирующие, как пользователь взаимодействует с системой меню и запоминает модели использования приложений.
Таким образом, для повышения удобства использования можно сделать оптимальные изменения в системе меню.
В частности, мы считаем, что взаимодействие пользователя с меню
происходит в следующие три этапа:
- Пользователь выбирает из меню, что он хочет увидеть, используя либо мышь, либо клавиатуру. Его внимание концентрируется на заголовке меню в верхней части рабочего пространства.
- Когда появляется меню, внимание пользователя по-прежнему обращено к верхней части меню.
- Пользователь последовательно просматривает меню сверху вниз до тех пор, пока не найдет то, что искал. Если используется мышь, пользователь должен перемещать мышь вниз, проходя над каждым элементом меню последовательно. Та же логика применяется, если пользователь использует клавиатуру для доступа к системе меню. В этом случае пользователь должен нажимать клавишу "Стрелка вниз" для перемещения по меню системы до тех пор, пока он не достигнет выбранного элемента.
Когда пользователь знает позицию нужного элемента меню системы, он, вероятно, не будет просматривать меню системы в последовательном порядке. Скорее всего, пользователь переместит курсор непосредственно на то место, где, как он считает, находится этот элемент.
Это
также относится и к случаю,
когда пользователь знает клавиши
быстрого вызова для доступа к
меню и его элементам в структуре
меню.
2.2
Анализ Модели
Одним
из показателей, которые можно определить
с помощью модели пользователя, является
среднее время доступа к
Для
меню со случайным образом
Среднее время доступа к элементу меню - это число элементов, которые
необходимо было просмотреть для того, чтобы выбрать нужный элемент. Сокращая среднее время доступа к элементу, можно увеличить эффективность системы меню. Достичь этого можно двумя способами:
- путем устранения элементов, которые, вряд ли, могут быть выбраны и
- путем перемещения элементов с высокой вероятностью выбора в верхнюю часть меню.
Кроме того, среднее время доступа к элементу – это время, которое затрачивает пользователь, чтобы перейти от одного элемента меню к другому.
Перемещение в верхнюю часть меню элементов с наибольшей вероятностью выбора повышает скорость обучения и эффективность [10].
Первоначально наш подключаемый модуль адаптивного пользовательского интерфейса (AUI) не изменяет систему меню, только удаляет элементы меню, подсвеченные серым цветом (отключённые).
Например, как показано на рисунке 1, некоторые элементы меню, такие как "Сохранить", "Сохранить всё" и "Вернуть",
отключены, так как система меню не позволяет пользователю их выбрать.
В этом случае, мы скрыли все отключенные элементы меню. Это сокращает объём меню и обеспечивает быстрый доступ к элементам меню, которые пользователь может выбрать.
Это устанавливает такой же базовый уровень скорости обучения, как первоначальный уровень у меню системы Eclipse. Изменения в меню начинают происходить только после того, как собрано достаточное количество данных о его использовании. Для повышения эффективности мы размещаем элемент меню, который выберут с большей вероятностью на самом верху. Таким образом, пользователю незачем просматривать всё меню в поисках нужного элемента. Так как пользователь постоянно взаимодействует с меню системы, а объём собранных об использовании меню данных растёт, улучшается точность прогнозирования элементов меню.
Когда точность прогнозирования достаточно высока, пользователю больше не нужно помнить, где расположены элементы меню системы. Модуль прогнозирования будет перемещать выбранный элемент меню вверх, и, таким образом, нам нет необходимости помнить, как работает система меню.
Рисунок 1- Меню системы Eclipse IDE
- АДАПТИВНЫЕ ПОЛЬЗОВАТЕЛЬСКИЕ ИНТЕРФЕЙСЫ
Для повышения удобства использования в Eclipse IDE, мы разрабатываем
адаптивный пользовательский интерфейс (AUI), как подключаемый модуль для Eclipse IDE.
Подключаемый модуль загружается и выполняется при запуске Eclipse.
Пользователь взаимодействует с системой меню в том же порядке, как с оригинальным меню системы Eclipse. Меню системы улучшается с помощью адаптивной функциональности подключаемого модуля. В то время как пользователь использует Eclipse, подключаемый модуль собирает схемы работы в фоновом режиме.
AUI
подключаемый модуль
Например, в первоначальном меню системы, как показано на рисунке 1, каждый пункт меню верхнего уровня (например, файл, изменение и перемещение) имеет ряд элементов меню и подменю.
После сбора достаточного количества схем работы, подключаемый модуль будет скрывать элементы меню, которые пользователь редко
выбирает. Например, когда пользователь постоянно создает новые проекты, выбирая пункт меню "Новый", AUI подключаемый модуль
динамически только отображает только элемент меню "новый" и скрывает остальную часть элементов меню, как показано на рисунке 2.
Более того, AUI подключаемый модуль добавляет кнопки в нижней части каждого верхнего уровня меню «Развернуть меню».
Нажав
на эту кнопку, пользователь может
вернуться к первоначальному
виду, когда в меню нет скрытых
элементов.
Рисунок
2- Адаптированное меню Eclipse
3.1
Архитектура адаптивных
интерфейсов пользователя
Общая архитектура AUI подключаемого модуля изображена на рисунке 3. По сути, взаимодействие с пользователем происходит посредством трех основных компонентов: Адаптивная система меню (AMS); AUI помощник; и AUI предпочтения.
• AMS является главной формой взаимодействия пользователя с
меню системы.
• В AUI Мастер дает соответствующие указания и уведомления пользователям, когда интерфейс пользователя запускается впервые после изменений, внесенных в существующий пользовательский интерфейс.
• В AUI устанавливаются предпочтения пользователя, как следует
действовать AUI. Эти настройки будут доступны точно так же, как и все другие настройки в Eclipse IDE.
Когда
пользователь взаимодействует с
системой меню, для каждого выбора
меню создается событие. События
обрабатываются посредством Event Engine. Event Engine
имеет две особенности: во-первых, уведомлять
адаптивную часть о том, что событие произошло,
а другая заключается в том, чтобы обновить
меню, если адаптивная часть решила изменить
меню. Короче говоря, обработка события
в Event Engine
захватывает все необходимые данные (то
есть, какая кнопка была нажата, и время,
когда произошло событие), и передает их
на рассмотрение Event
Handler.
Рисунок 3- Архитектура AUI подключаемого модуля
Обработчик события принимает все входящие данные и вызывает обработчик данных для сохранения информации в памяти в XML формате.
Программа обработки событий будет также определять, какой из перечисленных Адаптивных алгоритмов следует запустить. С помощью данных схемы использования, полученных от пользователя, и настроек AUI, установленных пользователем, адаптивные алгоритмы определяют, требуются ли изменения в интерфейсе. Если изменения в интерфейсе необходимы, то Адаптивные алгоритмы уведомляют Обработчика событий, запускающего программу Мастер AUI, чтобы подтвердить все изменения, которые следует применить.
Если
пользователь одобряет какие-либо изменения,
то вызывается Обработчик AMS, чтобы
осуществить необходимые
Любые
изменения, которые не принял пользователь,
будут сохранены для
Перспективные
аспекты разработки Адаптивных Алгоритмов
заключаются в том, чтобы определить,
каким образом алгоритмы могут
изучать и изменять пользовательский
интерфейс, основываясь на взаимодействии
пользователя с AUI.
3.2
Использование прогнозирования
Чтобы предсказать, какой элемент меню пользователь, скорее всего, выберет следующим в AUI, необходимо разработать методику, которая может эффективно отслеживать схему использования системы меню и применять собранную информацию для эффективного прогнозирования будущих событий.
В качестве примера рассмотрим случай, когда пользователь достаточно часто выбирает сначала элемент меню "Копировать", который находится в меню "Правка", и нажимает кнопку "Вставить", которая тоже находится в меню "Правка".
Подключаемый модуль AUI может предположить, что пользователь, вероятно, выберет элемент меню "Вставить" из меню "Правка" после того, как пользователь выбирает команду "Копировать" в разделе "Правка".
Для уменьшения времени доступа прогнозируемый элемент меню (например, "Вставить") копируется в верхнюю часть меню (например, меню "Правка"), чтобы поставить его первым элементом, который пользователь увидит. Каждый выбор элемента меню генерирует событие.
Мы захватываем группу последующих событий из системы меню в так называемой последовательности событий.
Мы считаем, что каждой последовательности соответствует один шаблон использования, как например, шаблон копирования и вставки.
Одна из проблем заключается в том, чтобы создать метод, который прозрачно определяет границы нескольких последовательностей событий, которыми пользователь оперирует при работе с интерфейсом пользователя в течение определенного периода времени.
Нецелесообразно требовать от пользователя вручную отметить отправную точку и конечный пункт шаблона.
Это непрактично по двум причинам:
Во-первых, это требует дополнительных усилий со стороны пользователя, которому надлежит запомнить начало и конец последовательности событий, что будет, несомненно, раздражать, а потому не будет запоминаться.
Во-вторых, пользователь может не всегда быть в курсе своего пользования шаблонами и не осознавать последовательность событий как шаблон, который часто используется.
В наших исследованиях мы считаем, что последовательности событий могут отличаться друг от друга по интенсивности использования.
Например, мы обрабатываем события меню, когда пользователь интенсивно взаимодействует с пользовательским интерфейсом. Мы измеряем интенсивность путем вычисления скорости возникновения событий.
Когда
интенсивность использования
Чтобы
охватить все эти события
Каждый узел также имеет счетчик, показывающий количество проходов через данный узел.
Рисунок 4- Дерево последовательности событий
На рисунке 4 изображено дерево, созданное на основе данных последовательностей.
Когда начинается последовательность событий, производится поиск соответствующего дерева, если такое находится, то счетчик узла растёт, и указатель на текущее дерево сохраняется; в противном случае создается новое дерево с корневым узлом, соответствующим произошедшему событию.
На рисунке 4 дана следующая ситуация: когда возникает первая последовательность, нет деревьев с соответствующими корневыми узлами, и создается новое дерево с корневым узлом-событием А.
Когда происходит последовательность событий 2,
дерево с корневым узлом А уже создано, таким образом, счетчик узла растёт.
Одно из преимуществ этой структуры заключается в том, что её можно использовать для прогнозирования сразу, как только она построена.
После
того, как произошла
и указатель установлен на текущую позицию, адаптивные алгоритмы могут проверить список дочерних узлов и их счетчики, чтобы предположить, каким будет следующее событие.
Когда произойдет следующее событие, его можно вставить в дерево, как отрезок, формирующий структуру дерева в данный момент.
Принесло бы большую пользу дальнейшее изучение методов определения начала и конца последовательности событий.
Также
возможно, чтобы система динамично
определяла прошедшее время между
цепочками событий и использовать
этот интервал для определения начала
и конца последовательности с желаемым
уровнем точности.
3.3
Адаптивные алгоритмы
Для того чтобы динамически настроить меню системы, основанной на моделях использования, мы предлагаем два адаптивных алгоритма: Fade алгоритм, который отвечает за временное удаление элементов из меню системы и алгоритм Enlighten, который отвечает за перемещение элементов меню в верхнюю часть.
Оба адаптивных алгоритма собирают статистические данные, собранные исходя из последовательностей событий, определяют, какие элементы меню должны быть изменены, и уведомляют об этом обработчика AMS (как показано на рисунке 3), чтобы внести соответствующие изменения в меню системы.
Кроме
того, адаптивные алгоритмы решают,
когда и какие изменения
В частности, не следует делать изменений в меню, когда все его элементы выбираются равномерно, то есть вероятность выбора каждого элемента одинакова. А меню, где у нескольких элементов есть высокая вероятность быть выбранными и очень низкая вероятность выбора остальных элементов, является подходящим кандидатом, который нужно подстраивать под поведение пользователя.