Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Второй этап : разработка пользовательского интерфейса



Примерно 70% стоимости продукта идет на

разработку пользовательского интерфейса.

Бил Бакстон (Bill Buxton)

Разработка пользовательского интерфейса для про­граммного продукта обычно требует значительных затрат времени и ресурсов. Этап разработки состоит из опреде­ленных шагов, выполняемых в заданной последователь­ности. Существует большой соблазн начать программиро­вание финальной версии продукта уже сейчас, не занима­ясь разработкой интерфейса. Однако пройдите все этапы процесса разработки, прежде чем приступить к програм­мированию.

Разработка включает в себя следующие шаги:

♦ определение цели с точки зрения удобства приме­нения продукта;

♦ разработка задач и сценария действий пользовате­лей;

♦ определение целей и операций интерфейса;

♦ определение иконок объектов и визуального пред­ставления;

♦ разработка меню объектов и окон;

♦ оптимизация визуальной разработки.

Первый шаг: определение цели с точки зрения удоб­ства применения продукта

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

113


Человеко-машинное взаимодействие: теория и практика


Теория


 


Как можно судить о том, работает ли продукт, если даже не определиться с тем, что представляет собой прак­тичная в использовании система? Это похоже на поглажи­вание мишени под выпущенные стрелы вместо предвари­тельного их нацеливания и последующей констатации результата попадания!

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

♦ пригодность;

♦ эффективность;

♦ легкость в освоении;

   ♦ оценка пользователями качества продукта.
Второй шаг: разработка сценария действий пользо­вателей и задачи, стоящие перед ними

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

Джон Кэролл (John M. Carroll)

Сложно с высокой степенью точности определить, что представляет собой сценарий по сравнению с задачей, стоя­щей перед пользователями. Как правило, сценарий явля­ется описанием действий, выполняемых пользователем. Сценарий представляется как последовательность задач, стоящих перед пользователями, или событий, направлен-

114


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

Помните, речь идет об итерационном процессе разра­ботки! Сценарии, которые вы разрабатываете для опреде­ления характера пользовательского интерфейса, станут основой для тестирования на удобство его использования. Если сценарии не управляют разработкой требуемого ин­терфейса, то вполне возможно, что впоследствии сам ин­терфейс будет управлять ими. То есть в данный момент вы будете разрабатывать сценарии, допускаемые интер­фейсом, а не сценарии, которым хотят следовать пользо­ватели.

На втором шаге следует разработать несколько сцена­риев пользователей. Чем больше их будет, тем меньше ве­роятность того, что вы упустите из виду ключевые объек­ты и операции, необходимые в интерфейсе. Если вы соз­даете программу для множества разных людей, убедитесь в том, что сценарии содержат весь диапазон требований пользователей и навыков, необходимых для выполнения стоящих задач. Разработка компьютерных систем, осно­ванная на сценарии действий пользователей, стала важной частью разработки системы, ориентированной на их по­требности.

Третий шаг: определение объектов и операций

Третий шаг является, возможно, самым сложным (и самым важным) в процессе разработки. Ниже представ­лены некоторые действия, которые следует предпринять на этой стадии:

♦ выделить объекты, данные и действия из сценари­ев и задач, стоящих перед пользователями;

♦ просмотреть и уточнить список объектов и действий совместно с пользователями;

♦ начертить диаграмму взаимодействия между объ­ектами;

115


Человеко-машинное взаимодействие: теория и практика


Теория


 


♦ заполнить матрицу прямого манипулирования объ­ектами.

Прежде всего определите исходный набор объектов и действий пользователя на основании информации, соб­ранной на первом этапе, а также сценариев, разработанных на втором этапе. Составить список объектов и действий несложно — просто подчеркните все существительные в ваших сценариях и задачах и обведите кружком (в нашем примере они выделены курсивом) все глаголы. Это помо­жет вам составить перечень объектов и данных (сущест­вительных), а также действий (глаголов), применимых к ним.

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

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

Обычно основному объекту (например, гостинице) с более чем одной копией требуется объект-контейнер вы­сокого уровня для хранения всей «коллекции» индивиду­альных объектов. Например, в системе, связанной с тор­говлей автомобилями через сеть дилеров и имеющей мно­жество объектов «автомобилей», вероятно, будут присут­ствовать и объекты — «группы автомобилей». Такие объ­екты-контейнеры в итоге могут превратиться в папки ин­терфейса или в элементы управления списком. Однако на данный момент важно не забыть о том, что «коллекция» одинаковых объектов, как правило, содержится в объек­те-контейнере более высокого уровня.

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


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

Посмотрите на объекты, расположенные с левой сто­роны схемы отношений между объектами. Контейнеры высокого уровня, или списки, представляют собой внут­ренние бизнес-структуры, или программные структуры системы. Такие взаимоотношения демонстрируют ведение базы данных, выполняемое системой на регулярной осно­ве. Выведение счета клиента на экран может потребовать доступа к многочисленным базам данных, которые при этом остаются в тени, но пользователям и не надо знать, что происходит на уровне системы. Они видят в них только инструменты для получения и хранения информации — им нет необходимости знать, как эти базы данных работают. В данном случае речь идет скорее о системных объектах, чем об объектах интерфейса. Будьте осторожны с тем, как вы представляете их на экране!

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

Работа, которая выполняется на третьем шаге, необ­ходима для обеспечения вспомогательным материалом по объектам и действиям интерфейса. Теперь самое время создать изображения идентифицированных вами объек­тов. Это самая увлекательная часть разработки.


 


116


117


Человеко-машинное взаимодействие: теория и практика


Теория


 


Действительно, хорошая идея — просмотреть резуль­таты, начиная со второго этапа анализа, совместно с поль­зователями.

Четвертый шаг: определение иконок объектов и ви­зуальных представлений

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


Поделиться:



Последнее изменение этой страницы: 2019-03-31; Просмотров: 272; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.021 с.)
Главная | Случайная страница | Обратная связь