1.3 Проектирование пользовательского интерфейса
1.3.1 Этапы проектирования пользовательского интерфейса
В процессе дизайна интерфейса выделяются три основных этапа, а именно первоначальное проектирование, создание прототипа и тестирование/модификация прототипа. Фактически процесс дизайна, чтобы быть успешным и безусловным, всегда стремится происходить в этой последовательности: проектирование, затем создание прототипа, затем тестирование и модификация до получения требуемого результата, то есть основным этапом оказывается не дизайн, но корректировка уже сделанного дизайна. С другой стороны, при тщательном проектировании длительного тестирования обычно удается избежать – но, с другой стороны, при этом проектирование становится достаточно длительным, так что неизвестно еще, что лучше сокращать [18].
Этап проектирования сам по себе состоит из нескольких составляющих, причем количество этих составляющих довольно велико. Важность этого этапа трудно переоценить. На нем закладываются основные концепции системы, влияющие абсолютно на все показатели качества её интерфейса.
Проектирование состоит из следующих этапов:
определение необходимой функциональности системы
создание пользовательских сценариев
проектирование общей структуры
конструирование отдельных блоков
создание глоссария
сбор и начальная проверка полной схемы системы.
Каждый последующий этап в такой системе зависит от результатов предыдущих этапов. Соответственно, пропуск какого-либо этапа (за исключением, разве что, создания глоссария) негативно влияет на результаты всех последующих этапов.
Часть этапов проектирования интерфейса совпадает с этапами проектирования всего программного комплекса. В частности, результат конструирования отдельных блоков и глоссарий будут детально рассмотрены в разделе 2.2.2 «Руководство пользователя».
1.3.2 Определение необходимой функциональности
Основным способом определение необходимой функциональности системы является анализ целей пользователей и их действий при работе с системой. Цели пользователей частично определяются их требованиями к продукту. На самом деле, пользователь далеко не всегда знает и требует то, что ему действительно необходимо. Поэтому вторым источником информации о целях пользователей служит сама предметная область, которая подлежит детальному изучению до начала проектирования системы в целом и её интерфейса в частности. В итоге цели пользователей определяются через предположения и диалог с пользователями, основанный на этих предположениях и тех, которые высказывались самими пользователями. На практике, на основании первичных требований пользователей создаются схематичные наброски 2-4 прототипов. На последующих этапах проектирования выбирается 1-2 варианта и происходит дальнейшая детализация с постепенным отбрасыванием неподходящих вариантов. Чтобы этот процесс не увеличивал в разы стоимость разработки продукта, необходимо соблюдать схематичность соответственно уровням абстракции. Также стоит дополнять демонстрации схем готовыми примерами их применения.
Во многом процесс диалога зависит и от психологии потенциальных пользователей. Некоторым из них необходима свобода выбора, тогда число предоставляемых на каждом этапе вариантов увеличивается до 3-6. Но в некоторых ситуациях можно убедить пользователя в том, что один разработанный вариант является единственно верным и именно он-то ему и нужен. Однако эти вопросы обычно решаются менеджером проекта и выходят за рамки ответственности разработчика.
Анализ действий пользователей по взаимодействию с интерфейсом ИПК можно проводить не ранее выпуска первого рабочего прототипа. Некоторые модели жизненного цикла программного продукта определяют в своих рамках необходимость выпуска прототипа на самых ранних стадиях разработки.
При отсутствии прототипа можно анализировать действия пользователей при работе с другими программными средствами, которыми они пользуются для достижения тех же целей.
В случае администрирования шлюза стоит обратить внимание на следующее:
Какие команды администратор использует чаще всего;
Какие команды наиболее сопряжены с основным функционалом ИПК;
Какие команды содержатся в первом и втором пункте одновременно.
Исходя из такого анализа, необходимо определить степень доступности функций. В частности, страницы, реализующие работу с командами из третьего пункта стоит вынести на главную страницу или в главное меню веб-интерфейса.
Необходимая функциональность интерфейса анализируется в разделе 1.1.4 «Требования пользователей».
1.3.3 Пользовательские сценарии
Цель создания пользовательских сценариев — написать словесное описание взаимодействие пользователя с системой, не конкретизируя, как именно проходит взаимодействие, но уделяя возможно большее внимание всем целям пользователей. Количество сценариев может быть произвольным, главное, что они должны включать все типы задач, стоящих перед системой, и быть сколько-нибудь реалистичными. Сценарии очень удобно различать по именам участвующих в них вымышленных персонажей.
В разделе 1.1.4 «Требования пользователей» приводится анализ вариантов использования ИПК в табличной форме. Отличием от пользовательских сценариев является моделирование внутренней работы системы. Если же оставить только входную и выходную информацию, где входной информацией будут действия пользователя, а выходной — результат, формируемый в окне браузера, то эти варианты использования окажутся составными частями пользовательских сценариев.
Например, пользовательский сценарий может выглядеть следующим образом:
«Пользователь Николай открывает страницу ИПК в браузере. Он вводит логин и пароль, авторизуясь в системе. Оказавшись на главной странице сайта, Николай переходит к выполнению команд системных утилит, проверяет состояние сетевых интерфейсов и таблицы маршрутизации, после чего переходит к справочной системе для просмотра справки по командам управления межсетевым экраном. Далее, пользователь возвращается на страницу выполнения команд и вручную добавляет правило для МСЭ, после чего выходит из системы».
Этот сценарий можно разбить по вариантам использования:
авторизация;
использование системных утилит (2 раза);
просмотр раздела руководства;
использование системных утилит;
выход.
Таким образом, варианты использования являются в некоторой мере декомпозицией пользовательских сценариев. Их можно использовать в дальнейшем при проектировании общей структуры интерфейса.
1.3.4 Общая структура интерфейса
Экранные формы – это строительные блоки интерфейса пользователя, являющие собой совокупность элементов управления, форм для ввода входных данных и блоков наглядного отображения выходной информации.
Логические связи между экранными формами определяются переходами между веб-страницами. При этом не учитываются переходы через пункты меню, иначе схема приобретёт вид паутины, что будет информативно, но не наглядно. По этой же причине не учитываются переходы из разделов справочного руководства.
Полученная структура экранных форм веб-интерфейса (веб-страниц) ИПК изображена на рисунке 6.
Рисунок 6 —Структура экранных форм веб-интерфейса
1.3.4 Полная схема интерфейса
Создание полной схемы интерфейса предполагает визуальное отображение всех используемых форм и их вариантов, в зависимости от действий пользователя. В создаваемом интерфейсе динамических страниц мало, поэтому вид экранных форм, связанных полной схемой интерфейса, изображённый на рисунке 7, практически полностью основывается на структуре экранных форм.
Р
исунок
7 – Вид экранных форм