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

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

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

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

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

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

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

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

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

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

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

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

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

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

113

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

Теория

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

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

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

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

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

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

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

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

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

114

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

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

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

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

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

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

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

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

115

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

Теория

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

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

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

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

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

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

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

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

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

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

116

117

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

Теория

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

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

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

Разработка иконок объектов

Разработчик графики должен отвечать за проектиро­вание иконок. Обратная связь с пользователями и прове­дение тестирования на удобство применения также долж­ны использоваться для подтверждения того, что иконки узнаваемы, понятны и способны помогать в решении задач (рис. 5.4).

Рис. 5.4. Примеры иконок объектов, выполненных вручную

Не тратьте слишком много времени на ранних стадиях разработки интерфейса на иконки. Начните с черновых набросков, затем постепенна дорабатывайте и тестируйте иконки в процессе разработки. Можно обратиться к кни­ге Вильяма Хортона (William Horton), где достаточно под­робно рассмотрен этот вопрос.

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

Разработчики видят объекты не так, как пользовате­ли. Поэтому имеет смысл предоставить графическим раз­работчикам возможность делать эту работу вместе с поль­зователями.

Пятый шаг: разработка меню и окна

Когда объекты, их типы и иконки определены и раз­работаны, остается выяснить, как пользователи будут об­щаться с объектами и окнами. Следует ответить на сле­дующие вопросы:

• Какие действия свойственны каждому объекту и типу?

• Что содержится во всплывающих меню?

• Каким окнам требуется панель меню?

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

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

Руководство, выпущенное фирмой Microsoft no Win­dows, не дает никаких указаний о том, когда следует использовать панель меню. В руководстве фирмы IBM

118

119

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

Теория

говорится о том, что такая панель должна быть, «когда окно предлагает более шести вариантов действий или маршрутов».

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

Шестой шаг: усовершенствование визуальной разра­ботки

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