Процесс разработки графического пользовательского интерфейса
Рассмотренные выше варианты архитектур описывают взаимодействие интерфейса как с пользователем, так и с приложением. Перейдём теперь к фазе непосредственного проектирования графического пользовательского интерфейса, как изображения, предъявляемого пользователю. Эту работу хорошо бы поручить отдельному специалисту, являющемуся в первую очередь дизайнером, но с образованием программиста.
В начале следует провести социологическое исследование, определяющее ожидания пользователей от системы. Особенно это важно при разработке специализированных приложений. Нужно изучить порядок работы пользователей, технологию работы, привычки, формы рабочих документов. Это исследование, разумеется, проводится для проектирования всей системы, но немаловажно произвести повторные исследования, а ещё лучше работать в постоянном контакте с будущим пользователем. Следует учесть развитие системы во времени – определить, что будет меняться в ходе работы системы (или интерфейса, если он независим), а что останется неизменным. Например, ряд достаточно сложных систем позволяют пользователям или программистам заказчика самостоятельно создавать экранные формы, для реализации тех или иных действий системы, неучтённых при первоначальном проектировании. Это позволяет создать гибкий, настраиваемый под конкретного пользователя интерфейс.
На втором этапе следует составить полный список экранов пользователя с кратким описанием их назначения.
|
|
|
На третьем этапе следует построить диаграмму переходов между экранами пользователя (какие окна из каких должны открываться). Диаграмма должна отвечать двум противоречивым требованиям: во-первых, она должна быть достаточно полной, чтобы из любой функции (если допустимо предметной областью) можно было бы перейти к любой другой функции (полный граф), во-вторых, возможности множества переходов часто приводят к перегрузке экранов пользователя избыточной информацией, непосредственно не требующейся в реализации той или иной функции, т.е. система должна быть простой. Между этими противоречиями разработчику нужно искать компромисс. Следует учесть: во-первых, что пользователю однажды может понадобиться новая возможность, потенциально присутствующая в системе (тогда должен быть механизм, позволяющий быстро и просто настроить систему на такую возможность), во-вторых, новый пользователь должен достаточно быстро понять «идеологию» технологического процесса, поддерживаемого системой (чтобы не «заблудился» в формах).
На четвёртом этапе следует детализировать содержимое каждого экрана, исходя из точки зрения пользователя, реализующего этап технологического процесса, поддерживаемый экраном.
|
|
|
На пятом этапе следует провести анализ совокупности всех экранов и провести нормализацию (вынести общие функции в отдельные формы). По правилу: на каждую атомарную функцию по одной форме. Но не следует слишком детализировать функции (с системой, открывающей 20 диалоговых окон работать очень неудобно – рассеивается внимание). В результате должна быть построена окончательная диаграмма переходов между экранами.
На шестом этапе следует разработать методику работы с каждым экраном и выбрать подходящие элементы управления для реализации работы с каждым параметром системы, группировать и размещать их согласно требованиям к качеству интерфейса.
На седьмом этапе следует соединить вместе пользовательский интерфейс с приложением, отработать методику обмена данными. Провести тестирование и отладку.
На восьмом этапе полезно заняться оформлением (добавить картинки, нарисовать красивые пиктограммы, подобрать цвета, шрифты). Пользователь должен получать эстетическое удовольствие от работы системы.
Для работы со сложными изображениями следует предусмотреть ряд чисто интерфейсных функций системы, позволяющий удобно работать с картинкой. Разработчик должен добиться простоты реализации функций поворота, сдвига, масштабирования изображения. Должны быть созданы удобные инструменты для редактирования изображения, зависящие от его природы (векторная или растровая графика, оформление текста, внедрение объектов и т.д.). Полезно использовать функцию перетаскивания (drag & drop) – для перетаскивания пользователю не требуется строить мысленный план действий: «я должен нажать эту кнопку, затем щёлкнуть в это место». Функция перетаскивания позволяет визуализировать действие пользователя, предотвратить возможные ошибки (отказ принять брошенный объект в случае попытки его некорректного размещения).
|
|
|
5. БЫСТРОДЕЙСТВИЕ
ГРАФИЧЕСКОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Поговорим теперь о быстродействии графической системы. В этой теме следует различать два направления: первое, системы реального времени (анимация, видео) – такие системы к торможению нетерпимы (для плавности изменения картинки должно выводиться не менее 24 кадров в секунду, при этом загрузка процессора свыше 80% не рекомендуется), второе, системы, визуализирующие работу пользователя (отображение статических или редко обновляемых динамических данных). Вот о быстродействии последних мы и поговорим.
|
|
|
Сразу можно сказать, что быстродействие системы есть субъективное ощущение пользователя. В самом деле, есть люди неторопливые, которые не любят быстрого темпа работы, а есть люди нетерпеливые, которым нужно «всё и сразу». Для первых компьютер может и подождать, пока они продолжат работу с системой, для вторых недопустим медленный отклик или ожидание.
Можно выделить скорость работы графической среды, предоставляющей интерфейс. В ранних системах она программировалась вместе с приложением, сейчас эти функции берут на себя оконные менеджеры операционных систем. Быстродействие компьютеров возросло, код, реализующий вывод графики оконными менеджерами достаточно эффективен, поэтому в настоящий момент ставить вопрос о быстродействии отображения экранных элементов бессмысленно.
Можно выделить скорость обновления результатов самой системой. Среднестатистический пользователь не выносит ожидания более 1–3 секунд (расстраивается его внимание), поэтому реакция системы не должна быть более длительной. Часто и даже очень часто приложение не в состоянии справиться с вычислениями за такой короткий срок. Для решения этой проблемы существует два пути: первый путь лежит в изменении архитектуры системы (это самый дорогостоящий, но зато самый эффективный путь – конвейерная обработка транзакций, инициируемых пользователем с обработкой взаимоисключений), второй путь лежит в индикации пользователю процесса обработки его команды (это намного дешевле, но не так эффективно). Первый путь крайне неудобен для программистов, поэтому в подавляющем большинстве случаем к нему не прибегают, от чего страдают пользователи и качество пользовательского интерфейса. Второй путь очень удобен для реализации, но даже на нём допускаются грубые ошибки. Для индикации процесса выполнения системы часто используют такие экранные элементы, как панели степени выполнения (progress bars). Ленивые программисты используют эти элементы лишь в качестве индикаторов того, что приложение не «зависло», а продолжает работать. Пользователи же (особенно начинающие) воспринимают эти элементы, как индикаторы времени выполнения, полагая, что скорость движения индикатора постоянна. Из этого различия в понимании пользователи очень часто расстраиваются. А недовольство системой – это первый шаг к отказу от неё, переходу к конкуренту и т.д. Программистам следует более внимательно подходить к представлению пользователям долго выполняющихся процессов. Хорошим примером являются некоторые системы установки приложений в Microsoft Windows, включая саму операционную систему, начиная с MS Windows 98. Пользователь видит весь процесс, производимый системой, на каком шаге он находится в данный момент, реалистичные оценки времени окончания процесса (хотя последнее тоже далеко не везде встречается).
Следует обратить внимание на вывод сложных графических объектов, особенно трёхмерных. GDI в Microsoft Windows не предназначен для построения таких объектов, поэтому им в таких случаях лучше не пользоваться – слишком медленное построение, занимающее, иногда, десятки секунд. Наиболее распространенными являются многоплатформенная библиотека высокопроизводительной графики OpenGL и система реального времени по выводу мультимедийных потоков (графика, видео, звук) DirectX, поставляемая вместе с Microsoft Windows. Эти системы даже не на самой новой технике позволяют строить приложения с поддержкой достаточно мощной и быстрой графики.
6. ПЕРСПЕКТИВЫ РАЗВИТИЯ
ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
В заключении несколько слов о перспективах развития пользовательского интерфейса.
Можно с уверенностью сказать, что произойдет (точнее, уже произошло) разделение пользовательского интерфейса настольных и карманных вычислительных систем. Настольные системы развиваются в сторону графики с более высоким разрешением, что позволяет расширить «ёмкость» экрана, разместив на нём больше элементов. Карманные же системы идут по пути более жёсткого отбора информации для вывода – выводится только самое главное.
Скорее всего, в ближайшее время получат более широкое распространение системы голосовой связи. Эти системы позволят общаться с компьютером, не подходя к нему, не используя клавиатуру и мышь. Такие системы обладают принципиально иным пользовательским интерфейсом, нежели графический, поэтому к ним будут предъявляться свои требования.
Дата добавления: 2016-01-05; просмотров: 87; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!