Содержание Введение Понятие пользовательского интерфейса Подходы к пониманию пользовательского интерфейса
Скачать 0.54 Mb.
|
Постановка задачи. На этой стадии собираются и анализируются данные о пользователях, формализуется функциональность, и определяются объективные критерии успеха проекта.
Описываются следующие свойства аудитории системы:
Выделяются объективные критерии оценки эргономичности интерфейса, такие как показатели эффективности, продуктивности, удовлетворенности пользователей (на более ранних этапах выделить эти критерии невозможно).
Разработчику необходимо четко осознавать, что пользователям не нужны инструменты сами по себе, нужны лишь результаты их работы. Никому не нужен текстовый процессор - нужна возможность с удобством писать тексты. Никому не нужна программа обработки изображений - нужны уже обработанные изображения. Это значит, что сами по себе функции никому не нужны и не важны. Людям нужно средство вообще, делающим возможным выполнять какую-либо работу [4].
Функциональность любой системы разделяется на несколько ролей пользователей: разным пользователям нужны разные блоки функциональности (в системах автоматизации эти роли называются бизнес-ролями). Навигация по системе прямо зависит от этих ролей, поскольку в пределах одной роли в навигацию не желательно включать функции из чужой роли. Соответственно, на этом этапе выделяются основные роли пользователей с относящимися к этим ролям функциям. Так же, на этом этапе проводятся собеседования с каждым из представителей определенной роли на предмет выявления особенностей данной роли и выяснения, какие дополнительные (по отношению к формальным) возможности следует предусмотреть.
На этом этапе частично изучаются, частично разрабатываются типовые сценарии действий пользователя: формализуются данные, необходимые пользователям для выполнения работы, последовательность самой работы, критерии завершенности этой работы, разрабатывается структура диалога. Цель этого этапа - написать словесное описание взаимодействия пользователя с системой, не конкретизируя, как именно проходит взаимодействие, но уделяя возможно большее внимание всем целям пользователей. Количество сценариев может быть произвольным, главное, что они должны включать все типы задач, стоящих перед системой, и быть сколько-нибудь реалистичными. Сценарии очень удобно различать по именам участвующих в них вымышленных персонажей.
Большая часть аудитории любой системы обладает навыками использования нескольких конкурирующих систем; если разрабатываемый интерфейс полностью несхож с конкурентами, пользователям придется переучиваться. Кроме того, конкурирующие системы часто содержат эффективные решения, которые полезно перенять (или, что чаще случается, учесть при проектировании интерфейса).
На этой стадии начинается непосредственное проектирование интерфейса; предыдущие этапы посвящены исключительно сбору данных и постановке задачи.
На этом этапе, основываясь на сценариях работы и ролях пользователей, формируется структура экранов системы, т.е. определяется количество экранов, функциональность каждого из них, навигационные связи между ними, формируется структура меню и других навигационных элементов. По сути, на этом этапе выделяются отдельные функциональные блоки. Под функциональными блоками будем подразумевать функцию или группу функций, связанных по назначению или области применения в случае программы и группу функций/фрагментов информационного наполнения в случае сайта. Существует три основных вида связи между блоками. Это логическая связь, связь по представлению пользователей и процессуальная связь [14]. Логическая связь. Логическая связь определяет взаимодействие между фрагментами системы с точки зрения разработчика. Полученные связи очень существенно влияют на навигацию в пределах системы (особенно, когда система многооконная). Поэтому чтобы не перегружать интерфейс, стоит избегать как слишком уж отдельных блоков (их трудно найти), так и блоков, связанных с большим количеством других. На этом этапе выделяются объективные критерии оценки эргономичности интерфейса, такие как показатели эффективности, продуктивности, удовлетворенности пользователей (на более ранних этапах выделить эти критерии невозможно). Связь по представлению пользователей. Пользователи имеют свое мнение о системе, и это мнение тоже является важным видом связи. В информационных системах, когда необходимо гарантировать, что пользователь найдет всю нужную ему информацию, необходимо устанавливать связи между блоками, основываясь не только на точке зрения разработчика, но и на представлениях пользователей. Дело в том, что самый распространенный способ поиска, а именно поиск по классификации признаков, работает только в том случае, когда пользователи согласны с принципами этой классификации. Большинство же понятий однозначно классифицировать быть не могут из-за наличия слишком большого количества значимых признаков. Также проблема состоит в том, что реальный классификационный признак может отличаться от широко распространенного. Например, помидор, который все считают овощем, на самом деле ягода. Не менее тяжело признать ягодой арбуз. Это значит, что классификация, приемлемая для ботаника, не будет работать для всех остальных, причем обратное не менее справедливо [22]. Из этой ситуации есть выход. Существует простой способ классификации - способ карточной сортировки. Все понятия, которые требуется классифицировать, пишутся на карточках из расчета «одно понятие – одна карточка». После чего группе пользователей из целевой аудитории предлагается эти карточки рассортировать (при этом каждый субъект получает свой набор карточек). Получившиеся кучки из карточек нужно разобрать на составляющие и свести результаты от разных субъектов в один способ классификации. Процессуальная связь. Процессуальная связь описывает не вполне логичное, но естественное для имеющегося процесса взаимодействие. Установление качественной процессуальной связи обычно довольно трудная задача, поскольку единственным источником информации является наблюдение за пользователем. В то же время установление такой связи дело исключительно полезное. Зачем, например, рисовать на экране сложную систему навигации, если точно известно, к какому блоку пользователь перейдет дальше? В этом смысле зачастую оправдано навязывать пользователю какую-либо процессуальную связь, жертвуя удобством, зато выигрывая в скорости обучения (поскольку пользователю приходится думать меньше). Жестко заданная связь позволяет также уменьшить количество ошибок. Классическим примером жестко заданной процессуальной связи является устройство мастеров, при котором пользователя заставляют нажимать кнопку Далее.
На основе разработанной ранее структуры экранов на этом этапе выбирается наиболее адекватная навигационная система и разрабатывается её детальный интерфейс. Навигационная система показывает механизм распределения функций и задач между окнами программы. Навигационная система определяет, каким образом пользователи смогут перемещаться как между различными задачами, так и внутри отдельной задачи. Например, можно ли будет оставить частично завершенную задачу и начать другую [18].
Разрабатывается справочная система (к настоящему этапу уже известна вся информация, необходимая для выработки структуры справочной системы, не просто описывающей интерфейс, но и помогающей пользователю решать его задачи).
Разрабатываются интерфейсы конкретных экранов системы (состав, взаимное расположение и поддерживающие текст интерфейсных элементов).
На данном этапе разрабатываются интерфейсы основных экранов системы.
На основе объективных критериев успеха интерфейса и сценариев действий пользователей разрабатываются тестовые задания, которые выполняются пользователями с фиксацией всех значимых характеристик деятельности (таких как производительность труда, количество человеческих ошибок). После этого выполняется подсчет соответствующих показателей и сравнение их с заданными. На основании полученных данных интерфейс либо дорабатывается, либо считается разработанным.
На данном этапе разрабатываются интерфейсы второстепенных экранов системы. К ним относятся диалоговые окно и всевозможные сообщения.
На основе объективных критериев успеха интерфейса и сценариев действий пользователей разрабатываются оставшиеся тестовые задания, которые выполняются пользователями с фиксацией всех значимых характеристик их деятельности. После этого выполняется подсчет соответствующих показателей и сравнение их с заданными. На основании полученных данных интерфейс либо дорабатывается, либо считается разработанным. Наиболее известные языки проектирования на 2010 год: VHDL (англ. VHSIC (Very high speed integrated circuits) Hardware Description Language) - язык описания аппаратуры высокоскоростных интегральных схем. Язык проектирования VHDL является базовым языком при разработке аппаратуры современных вычислительных систем. Был разработан в 1983 г. по заказу Министерства обороны США с целью формального описания логических схем для всех этапов разработки электронных систем, начиная модулями микросхем и заканчивая крупными вычислительными системами. Verilog - это язык описания аппаратуры, используемый для описания и моделирования электронных систем. Этот язык (также известный как Verilog HDL) позволяет осуществить проектирование, верификацию и реализацию (например, в виде СБИС) аналоговых, цифровых и смешанных электронных систем на различных уровнях абстракции. SystemC - язык проектирования и верификации моделей системного уровня, реализованный в виде C+ библиотеки с открытым исходным кодом [1]. Библиотека включает в себя ядро событийного моделирования, что позволяет получить исполняемую модель устройства. Язык применяется для построения транзакционных и поведенческих моделей, а также для высокоуровневого синтеза. ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность) - визуальный алгоритмический язык, созданный в рамках космической программы Буран. Разработка данного языка была начата в 1986 г. под руководством Владимира Паронджанова. В разработке языка принимали участие Российское космическое агентство (НПЦ автоматики и приборостроения им. акад. Н.А. Пилюгина, г. Москва) и Российская академия наук (Институт прикладной математики им. акад. М.В. Келдыша). Одно из задач, ставившихся перед разработчиками, было создание единого универсального языка, который должен был заменить специализированные языки ПРОЛ2 (для разработки бортовых комплексных программ Бурана), ДИПОЛЬ (для создания наземных программ Бурана) и ЛАКС (для моделирования) [3]. Работы по разработке языка были закончены в 1996г. (спустя 3 года после закрытия программы Буран), когда была создана автоматизированная технология проектирования программных систем (CASE-технология) Графит-Флокс. Эта технология эксплуатируется, начиная с 1996г. во многих крупных космических программах: международный проект Морской старт, разгонный блок космических аппаратов Фрегат, модернизированная ракета-носитель Протон-М и др. Правила языка ДРАКОН по созданию диаграмм оптимизированы для восприятия алгоритмов человеком. Таким образом, язык является одним из инструментов усиления интеллекта. Язык ДРАКОН может удачно применяться для специфицирования протоколов взаимодействия (например, клиент-серверных). UML (сокр. от англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. 5. Процедуры проектирование диалоговых режимов Большинство программных продуктов, ориентированных на конечного пользователя, работают в диалоговом режиме взаимодействия с пользователем, при котором ведется обмен сообщениями, влияющими на обработку данных. В режиме диалога осуществляются запуск функций обработки, изменение свойств объектов, производится настройка параметров выдачи информации на печать и т.п. Системы, поддерживающие диалоговый интерфейс, разделяются на классы [13]:
При проектировании ПИ необходимо определить:
Выбор структуры диалога - это первый из этапов, который должен быть выполнен при проектировании ПИ. Рассмотрим далее 4 варианта структуры диалога, каждая из которых имеет свои особенности и наиболее удобна для определенного класса задач. Диалог на основе командного языка. Система постоянно выводит приглашение на ввод команды. Каждую команду пользователь вводит с новой строки и обычно заканчивает нажатием клавиши «ввод». Ответственность за правильность задаваемых команд ложится на пользователя. Система информирует о невозможности выполнения команды, не сообщая, как правило, причин. Такой диалог часто используется в операционных системах. Достоинства:
Недостатки:
Диалог типа «вопрос-ответ». В каждой точке диалога система выводит в качестве подсказки один вопрос, на который пользователь дает один ответ. В зависимости от полученного ответа система должна решить, какой следующий вопрос задать. Достоинства:
Недостатки:
Диалог на основе меню. Является наиболее популярным вариантом организации запросов на ввод данных во время диалога. Посредством меню удобно отображать возможные варианты данных для ввода, доступных в любое время работы с системой. Существует несколько основных форматов представления меню на экране:
Достоинства:
Недостатки:
Диалог на основе экранных форм. Допускает обработку на одном шаге диалога нескольких ответов. Пользователь может выбирать последовательность ответов, временно пропускать некоторый вопрос, возвращаться назад для коррекции предыдущего ответа, иначе говоря, работать до тех пор, пока не заполнит форму полностью и не передаст ее системе. Достоинства:
Разработка сценария развития диалога - второй этап в проектировании ПИ. В ходе этого этапа рассматриваются возможные варианты переходов системы из текущего состояния диалога в требуемое, а также количество шагов, которое для этого надо сделать. Цели разработки сценария диалога:
Методы разработки сценария диалога:
В настоящее время нашли широкое применение формальные методы описания сценариев на основе сетей Петри и их расширений, а также на основе систем представления знаний (фреймовые и продукционные модели). Их достоинства заключаются в том, что они позволяют автоматизировать как проектирование диалога, так и его адаптацию в соответствии с характеристиками пользователя. Основной структурной единицей сценария является шаг диалога, соответствующий одному акту взаимодействия пользователя с системой. Сценарий диалога позволяет описать процесс взаимодействия пользователя с приложением на уровне решаемой им прикладной задачи. Однако для программной реализации интерфейса такое описание носит слишком общий характер. Поэтому на этапе реализации необходимо перейти на уровень описания соответствующих процессов с помощью используемых инструментальных средств разработки приложения. В процессе разработки сценария диалога важно обеспечить приемлемый темп ведения диалога, который характеризуется временем ответа (отклика) системы [9]. Время ответа системы определяется как интервал между событием и реакцией системы на него. Данная характеристика ПИ определяет задержку в работе пользователя при переходе к выполнению следующего шага задания. В настоящее время выработаны следующие рекомендации по допустимому времени ответа интерактивной системы: 0,1…0,2 с - для подтверждения физических действий (нажатие клавиши на клавиатуре, работа с «мышью»); 0,5…1,0 с - для ответа на простые команды (например, от момента ввода команды, выбора альтернативы из меню до появления нового изображения на экране); 1…2 с - при ведении связного диалога (когда пользователь воспринимает серию взаимосвязанных вопросов как одну порцию информации для формирования одного или нескольких ответов, задержка между следующими друг за другом вопросами не должна превышать указанную длительность); 2…4 с - для ответа на сложный запрос, состоящий в заполнении некоторой формы (если задержка не влияет на другую работу пользователя, связанную с первой, могут быть приемлемы задержки до 10 с); более 10 с - при работе в мультизадачном режиме, когда пользователь воспринимает данную задачу как фоновый процесс. Если пользователь не получает ответ в течение 20 и более сек, то приложение должно сообщить пользователю, что задержка ответа не является следствием выхода системы из строя. В процессе разработки сценария диалога важно обеспечить гибкость (адаптивность) интерфейса. Различают следующие виды адаптации: 1. Фиксированная адаптация. Здесь пользователь явно выбирает уровень диалоговой поддержки. В простейших случаях реализуется правило двух уровней: подробного (для начинающих пользователей), краткого (для подготовленных пользователей), а в других - правило N уровней. 2. Полная адаптация. Диалоговая система стремится построить модель пользователя, которая по мере обучения последнего определяет стиль диалога в зависимости от этих изменений. 3. Косметическая адаптация призвана обеспечить гибкость диалога не только без учета поведения пользователя, но и без однозначного выбора им конкретного стиля диалога. Здесь находят применение методы:
Выбор визуальных атрибутов отображаемой информации предполагает выполнение следующих действий:
Общие принципы расположения информации на экране должны обеспечивать для пользователя:
В заключении необходимо заметить, что рассмотренные методы и рекомендации позволяют устранить грубые ошибки в построении ПИ, однако лучший способ оценить его качество - дать возможность потенциальному пользователю поработать с системой в процессе ее испытания и опытной эксплуатации. 6. Графический интерфейс пользователя Графический интерфейс пользователя является обязательным компонентом большинства современных программных продуктов, ориентированных на работу конечного пользователя. Наиболее часто графический интерфейс реализуется в интерактивном режиме работы пользователя для программных продуктов, функционирующих в среде Windows, и строится в виде системы спускающихся меню с использованием в качестве средства манипуляции указательное устройство и клавиатуру [2]. Работа пользователя осуществляется с экранными формами, содержащими объекты управления, панели инструментов с пиктограммами режимов и команд обработки. Стандартный графический интерфейс пользователя должен отвечать ряду требований:
Рассмотрим некоторые приемы по разработке графического пользовательского интерфейса [7]. Панель приложения обычно разделяют на три части:
Преимущество использования меню действий (и выпадающего меню) заключается в том, что эти действия наглядны и могут быть запрошены пользователем установкой курсора, функциональной клавишей, вводом команды либо каким-то другим простым способом. Тело панели содержит элементы:
Область функциональных клавиш - необязательная часть, показывающая соответствие клавиш и действий, которые выполняются при их нажатии. В области функциональных клавиш отображаются только те действия, которые доступны на текущей панели. Для указания текущей позиции на панели используется курсор выбора. Для более быстрого взаимодействия можно предусмотреть функциональные клавиши, номер объекта выбора, команду или мнемонику. Разбивка панели на области основана на принципе «объект - действие». Этот принцип разрешает пользователю сначала выбрать объект, затем произвести действия с этим объектом, что минимизирует число режимов, упрощает и ускоряет обучение работе с приложениями и создает для пользователя комфорт. Если панель располагается в отдельной ограниченной части экрана, то она называется окном, которое может быть первичным или вторичным. В первичном окне начинается диалог, и если в приложении не нужно создавать другие окна, окном считается весь экран. Первичное окно может содержать столько панелей, сколько нужно для ведения диалога. Вторичные же окна вызываются из первичных. В них пользователь ведет диалог параллельно с первичным окном. Часто вторичные окна используются для подсказки. Первичные и вторичные окна имеют заголовок в верхней части окна. Пользователь может переключаться из первичного окна во вторичное и наоборот. Существует также понятие «всплывающие окна», которые позволяют улучшить диалог пользователя с приложением, ведущийся из первичного или вторичного окна. Рассмотрим кратко принципы проектирования диалогов [7]. Когда пользователь и ЭВМ обмениваются сообщениями, диалог движется по одному из путей приложения, т.е. пользователь перемещается по приложению, выполняя конкретные действия. Путь, по которому движется диалог, называют навигацией. Он может быть изображен в виде графа, где узлы - действия, дуги - переходы. Диалог состоит из двух частей: запросов на обработку информации и навигации по приложению. |
Похожие:
 | Пояснительная записка На тему: «Проектирование программного пользовательского... На тему: «Проектирование программного пользовательского интерфейса для электронной социально-ориентированной системы поддержки очного... | | Реферат Windows 95\ 98. Пользовательский интерфейс, настройки пользовательского интерфейса Федеральное агентство по образованию. Государственное образовательное учреждение высшего профессионального образования “ Глазовский... |
| Программа по формированию навыков безопасного поведения на дорогах... В этом уроке вы познакомитесь с основными элементами пользовательского интерфейса 3d Studio max, узнаете об их назначении и о способах... |  | «Проектирование программного пользовательского интерфейса для электронной... Тема I: Методологический характер дисциплины «Исследование социально-экономических и политических процессов» |
| Отчет по преддипломной практике На тему: «Проектирование программного... Целью работы является проектирование программного человеко-машинного интерфейса для социально-ориентированной системы поддержки очного... | | Контрольная работа по дисциплине «Операционные системы» Своим лидирующем положением на рынке 16-разрядные среды Windows обязаны отнюдь не превосходному качеству и удобству пользовательского... |
| Дизайн пользовательского интерфейса для интернет-сми Ми в сферу потребления и производства массовой информации в ее экономическом, культурном и творческом измерениях. Рост аудитории... | | Кафедра системного программирования Разработка программного интерфейса... Разработка программного интерфейса для мэшап-приложений на базе платформы Ubiq Mobile |
| Курсовая работа по дисциплине: «Программирование» На тему: «Демонстрационная программа» ... | | Идентификация пользователей веб-сайтов с помощью графического интерфейса zip-auth |
| Идентификация пользователей веб-сайтов с помощью графического интерфейса zip-auth | | Проекта Проект о проблеме человеко-машинного интерфейса и его влиянии на архитектуру персональных компьютеров |
| Требования к программе Разработчики не смогут создавать приложения с помощью интерфейса Win32 api для запуска на Windows rt | | Рефераты по темам Изучить и написать обзор указанного формата, языка описания данных, протокола или интерфейса* |
| 10 свойств интерфейса Photoshop Вот они, короткие и приятные 10 техник для работы в Фотошоп, о существовании которых, возможно, вы и не подозревали | | Программа по формированию навыков безопасного поведения на дорогах... Цель: Воспитание экологической культуры. Формирование пользовательского опыта по взаимодействию с окружающей средой, представлений... |
