Разработка адаптивного пользовательского интерфейса Eclipse

    Перемещение в верхнюю часть меню элементов  с наибольшей  вероятностью выбора повышает   скорость обучения и  эффективность [10].

    Первоначально наш подключаемый модуль  адаптивного  пользовательского интерфейса (AUI) не изменяет систему меню, только удаляет  элементы меню, подсвеченные серым цветом (отключённые).

    Например, как показано на рисунке 1, некоторые элементы меню, такие как "Сохранить", "Сохранить всё" и "Вернуть",

    отключены, так как система меню не позволяет  пользователю их выбрать.

    В этом случае, мы скрыли все отключенные  элементы меню. Это сокращает объём  меню и обеспечивает быстрый доступ к элементам меню, которые пользователь может выбрать.

    Это устанавливает такой же базовый  уровень скорости обучения, как  первоначальный уровень у меню системы Eclipse. Изменения в меню начинают происходить  только после того, как  собрано достаточное количество данных о его использовании. Для повышения эффективности мы размещаем элемент меню, который выберут с большей вероятностью на самом верху. Таким образом, пользователю незачем просматривать всё меню в поисках нужного элемента. Так как пользователь постоянно взаимодействует с меню системы, а объём собранных об использовании меню данных растёт, улучшается  точность прогнозирования элементов меню.

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

    

 

    Рисунок 1- Меню системы Eclipse IDE

3. АДАПТИВНЫЕ ПОЛЬЗОВАТЕЛЬСКИЕ ИНТЕРФЕЙСЫ

 

    Для повышения удобства использования  в Eclipse IDE, мы разрабатываем

    адаптивный  пользовательский интерфейс (AUI), как  подключаемый модуль для Eclipse IDE.

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

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

    AUI подключаемый модуль динамически  изменяет меню системы Eclipse IDE.

    Например, в первоначальном меню системы, как  показано на рисунке 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), чтобы внести соответствующие изменения в меню системы.

    Кроме того, адаптивные алгоритмы решают, когда и какие изменения вносить  в меню.

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