Необходимость ТО-анализа пользовательского интерфейса специальных программных комплексов экстренных оперативных служб

Размещено на http://www.allbest.ru/

Необходимость ТО-анализа пользовательского интерфейса специальных программных комплексов экстренных оперативных служб

Быков Андрей Андреевич - магистрант,

Учебно-научный комплекс автоматизированных систем и информационных технологий,

Академия Государственной противопожарной службы Министерства Российской Федерации

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

Аннотация

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

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

С 1 июня 2015 года на территории Московской области работает система вызова экстренных оперативных служб по единому номеру «112», сокращенно - Система- 112. С начала работы в Подмосковье операторы обработали уже свыше 31 миллиона вызовов. Ежедневно операторы Системы-112 принимают порядка 21,5 тысячи вызовов от заявителей, находящихся на территории Московской области. Это телефонные звонки, SMS-сообщения, сообщения из мобильного приложения и «ЭРА- ГЛОНАСС», вызовы по Skype от людей с нарушениями слуха и речи.

Основным рабочим инструментом Системы-112 Московской области является программный комплекс «КоордКом». Пользовательский интерфейс данного программного комплекса выполнен на базе стандартных элементов операционной системы Windows.

Наитивность программного комплекса сама по себе должна гарантировать быстроту работы, не требующих больших аппаратных затрат, процессов. Но опыт использования программного комплекса показывает, что, например, открытие, заполненной оператором 112, карточки происшествия на автоматизированном рабочем месте той же Системы-112, установленном в пожарной части, может занимать до 40 секунд; открытие карты с обозначением местонахождения заявителя - до 4,5 минут, либо может не произойти вовсе.

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

Многие кнопки (Рис. 1), имеющие графическое обозначение, плохо читабельны, имеют большое количество мелких, плохо различимых и визуально лишних элементов. Что увеличивает время поиска нужной кнопки пользователем.

Рис. 1. Фрагмент пользовательского интерфейса ПК «КоордКом»

Размер основного рабочего поля «Свободный текст» (Рис. 2), используемого во всех карточках, при любом происшествии, невозможно увеличить, хотя в стандартных средствах Windows это предусмотрено. В результате просмотр текста больше 165 символов доступен только с помощью прокрутки колеса мыши, а увидеть текст целиком невозможно.

Рис. 2. Фрагмент пользовательского интерфейса ПК «КоордКом»

Поле «Индекс» (Рис. 3) предназначено исключительно для индексации карточки, то есть - присвоения определенной категории происшествия (например: ДТП, потерявшиеся люди, обнаружение боеприпаса и т.д.). Почти всегда индексация происходит в самом начале работы с карточкой и только один раз. Но после индексации данное поле никак не видоизменяется и продолжает занимать значительную часть визуальной поверхности карточки происшествия.

Рис. 3. Фрагмент пользовательского интерфейса ПК «КоордКом»

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

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

Сама карточка происшествия занимает все рабочее пространство одного из двух мониторов АРМ (второй монитор по задумке авторов программного комплекса постоянно занят картой), закрывая собой даже кнопки управления голосовой связью. Что так же делает невозможным одновременный просмотр двух и более карточек происшествия.

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

Для выявления всех спорных моментов в программном комплексе необходимо провести полноценный анализ пользовательского опыта (опыта взаимодействия) - UX-анализ.

Опыт взаимодействия (UX) - термин широко применяется в информационных технологиях для описания субъективного отношения, возникающего у пользователя в процессе использования как программного комплекса в целом, так и отдельной его части. Опыт пользователя, в том числе, связан с таким понятием как юзабилити, применяемым при разработке и анализе пользовательских интерфейсов приложений [1].

Впервые термин user experience (пользовательский опыт) применил американский учёный в области когнитивистики, дизайна и пользовательской инженерии Дональд Норман в 1993 году.

UX -- это сфера между дизайном и аналитикой: дизайнеры думают о том, какие ощущения вызывает продукт, и разрабатывают прототипы.

Экспертный UX-анализ дает возможность точно определить неидеальные области системы. Он оценивает различные разделы программного комплекса и показывает, какие области или функции следует решать в первую очередь. Создавая условия для улучшения функций, необходимо следовать хорошо спланированному научному процессу, разделенному на две части: оценка UX и исследование пользователей [2].

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

Цели программного комплекса и пользовательские задачи.

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

Статистику по использованию программного комплекса.

Данные по техническому обслуживанию.

Соответствие правилам юзабилити.

Ментальное моделирование.

Оценка проекта.

Применение лучших практик UX.

Одним из распространенных методов UX-анализа являются так называемые «эвристики» Якоба Нильсена.

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

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

Результатом иХ-анализа должна стать дорожная карта для решения всей выявленных проблем.

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

Редакционная коллегия UX Booth. Complete Beginner's Guide to Interaction Design // UX Booth [Электронный ресурс], 2018. Режим доступа: https://www.uxbooth.com/artides/complete-beginners-guide-to-interaction-design/ (дата обращения: 10.05.2019).

Hassenzahl Marc. User Experience and Experience Design // The Encyclopedia of Human-Computer Interaction. 2nd Ed., 2018. С. 2-3.

Размещено на Allbest.ru