Прототипирование. Практическое руководство.

Часть 1: создание наброска.

Создание наброска – производительная часть прототипирования, и ваша цель на этой стадии – «вытащить» идеи из головы и материализовать их.

Я предпочитаю устанавливать рамки для «времени делать наброски». Это заставляет сотрудников работать быстро и не вдаваться в детали.

Цель создания набросков – не конкретизация идей (этим мы занимаемся на стадии разработки прототипа), а определение концепций, «вытаскивание» их из головы максимально быстро и переход к следующей стадии.

Совет.

Количество важнее качества.

При создании наброска не старайтесь разделить идеи на хорошие и плохие. В данный момент ваша цель – изучить идеи. На стадии создания набросков количество важнее качества. Качество придет позже.

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

Прототипирование. Практическое руководство

РИС. 2.2. Набросок модуля настроек для видео на Vimeo, демонстрирующий толщину линий и пометки[8].

Совет.

Быстрый и яростный.

Установите ограничения времени на создание набросков.

Я предпочитаю отводить на это 10–30 минут, а затем переходить к показу и критической оценке. Такой короткий период заставляет фокусироваться на продуктивных идеях, не вдаваясь в подробности.

Большинство наших набросков делается на бумаге с использованием специальных планшетов. Планшет – просто лист бумаги с набором небольших окошек-шаблонов. Он подобен планшету для раскадровки.

Вот как выглядит один из наших планшетов для набросков (рис. 2.3).[9].

Прототипирование. Практическое руководство

РИС. 2.3. Пример планшета с несколькими набросками

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

Совет.

Хорошая идея не приходит одна.

Использование планшета для набросков – отличный способ выдать несколько идей. Небольшое пространство стимулирует обдумывание отдельных элементов интерфейса. Такой планшет также подойдет для небольшой раскадровки, если необходимо описать проект AJAX или RIA.

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

Рассмотрим преимущества и недостатки набросков на бумаге, лекционных досках и в программном коде.

Наброски в коде.

Наброски можно делать не только на бумаге или лекционных досках. Разработчики часто делают их в привычной им среде – программном коде (это тоже возможно).

Одно из преимуществ набросков в коде – возможность их превращения в прототип. В условиях роста числа JavaScript-библиотек, CSS-фреймворков и шаблонизаторов вроде Ruby on Rails создавать наброски в коде становится все легче.

Преимущества.

• Делать наброски в коде все легче, поскольку инструментов для этого становится больше.

• Наброски «оживают» – их можно опробовать на практике.

• Это дает возможность эффективно использовать написанный код.

Недостатки.

• Не каждый умеет писать код.

• Для этого необходим компьютер.

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

• Это занимает больше времени, чем создание набросков на бумаге или лекционной доске.

Создание набросков на лекционной доске.

Одно из главных преимуществ создания набросков на лекционной доске – возможность совместной работы. Кто угодно может принять участие в обсуждении и предложить собственный вариант.

Преимущества.

• Обеспечивает возможность совместной работы.

• На лекционной доске может рисовать каждый.

• Одновременно могут участвовать несколько человек.

• Не нужен компьютер.

• Внести изменения очень просто: достаточно стереть рисунок и изобразить что-то новое.

Недостатки.

• Перенести лекционную доску сложнее, чем код или лист бумаги.

• Наброски статичны.

• Перенести наброски с доски на рабочие материалы иногда сложно[10].

Создание набросков на бумаге.

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

Преимущества.

• Обеспечивает возможность совместной работы.

• На бумаге может рисовать каждый.

• Может участвовать несколько человек одновременно.

• Не нужен компьютер.

• Внести изменения просто – достаточно добавить в рисунок нужные элементы или взять другой лист бумаги.

• Этим можно заниматься когда угодно и где угодно.

• Наброски легко перемещать.

Недостатки.

• Наброски статичны.

Часть 2: демонстрация и критика.

Демонстрация и критика – вероятно, наиболее важная часть процесса прототипирования. На этой стадии мы сосредоточиваемся на качестве.

Метод демонстрации и критики я освоил в студенческие годы, когда изучал графическое проектирование. И хотя потом я выбрал специальность «английский язык и когнитивная психология», я никогда не забывал ценные уроки демонстрации и критики.

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

Представляя наброски на обсуждение, мы часто крепим их к стене, как показано на рис. 2.4.

Прототипирование. Практическое руководство

РИС. 2.4. Показ набросков в ходе их критического разбора в дизайнерской студии

Рекомендации по демонстрации и критике.

Будьте кратки. Как я упоминал ранее, демонстрация и критика – вторая стадия, для которой мы устанавливаем жесткие рамки. Фактически на нее выделяется еще меньше времени, чем на набросок. Я стараюсь ограничивать время демонстрации двумя минутами, а обсуждение – тремя.

Не тратьте слишком много времени. Я знаю, что это звучит отчасти парадоксально. Но цель здесь – быстро получить результат и двигаться дальше. Вы сможете детализировать свои идеи позже.

Три минуты на демонстрацию идеи. Лимит времени в три минуты на демонстрацию идеи означает, что вы должны будете сосредоточиться на сильных сторонах. А если вы не можете объяснить суть идеи за это время, вероятно, что-то с вашей идеей не так.

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

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

Часть 3: прототип.

К началу этой стадии процесса вы набросали свои идеи, показали и обсудили их, отобрали только самые сильные варианты. Их прототипы вы и будете создавать.

Именно на стадии прототипирования вы начинаете детализировать свои проекты и выяснять, какие из них действительно жизнеспособны.

Когда я создаю прототип, то рассматриваю следующие вопросы:

• использую ли я инструменты или среду, с которыми мне удобно работать;

• есть ли у меня возможность эффективно передать аудитории этого продукта или его потребителям то, что я считаю нужным;

• каким временем я располагаю;

• какая степень точности необходима.

На деле способ прототипирования не важен. Большинство моих прототипов созданы с помощью HTML и AJAX, но это объясняется характером моей работы и потребностями клиентов. Я делал прототипы с помощью Flash, Keynote и на бумаге.

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

Совет.

Проект и набросок.

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

Часть 4: тестирование.

Я делю тестирование на две категории: тестирование с клиентами и тестирование с конечными пользователями.

Тестирование с клиентами.

Тестирование с клиентами сочетает в себе показ, критическое обсуждение и создание набросков. Встречи длятся обычно 1,5–3 часа в зависимости от сложности прототипа.

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

Фиксация изменений на набросках гарантирует, что мы не будем использовать для этого таблицу. Текстовые замечания легко понять неправильно. Наброски помогают снизить этот риск. Их создание допускает сотрудничество, и клиент может внести свой вклад.

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

Когда этап рассмотрения проекта закончен, клиент получает доступ к прототипу. Я прошу потребителя опробовать прототип в течение следующих двух или трех дней.

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

Тестирование с конечными пользователями.

Тестирование с конечными пользователями – стандартный тест на удобство использования: 8–12 участников, 5–6 сценариев, аудио– и видеозапись, анализ, а после тестирования – сообщение о результатах. В главе 12 подробнее рассказано о тестировании прототипов.

При любом тестировании я учитываю полученную в его ходе информацию в следующей версии прототипа.

Резюме.

Я рассказал о процессе прототипирования в Messagefirst. Надеюсь, это поможет новичкам в данной области увидеть, как прототипирование улучшает процесс проектирования. А бывалые профессионалы, возможно, найдут несколько полезных советов для усовершенствования используемых ими процессов прототипирования.

Прототипирование – процесс, а не продукт, средство достижения цели. Вот несколько важных моментов, о которых нельзя забывать:

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

• используйте метод дизайнерской студии: составление набросков; показ и критическое обсуждение. Это помогает быстро и последовательно улучшать прототип;

• начинайте с количества, исследуя множество идей. Качество придет позже.

В следующих двух главах я рассмотрю 5 различных способов прототипирования и 8 руководящих принципов его выполнения.

Глава 3. Пять моделей прототипирования.

Еще до начала работы над книгой я знал, что должно быть несколько разных видов прототипирования. Это подтвердит любой человек с приличным опытом в нашей области. И хотя я не могу утверждать, что открыл новый вид прототипирования или новое применение этому методу, обсуждение его с другими практиками привело к тому, что я стал воспринимать его по-новому.

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

А когда мы с Джедом Вудом обсуждали взаимодействие с пользователями, возникло гениальное определение. Джед помог мне понять, что такое прототипирование: способ разработки своих проектов.

Как я уже говорил, это вовсе не было внезапным открытием нового способа использования метода. На самом деле в ходе разговора я постепенно осознал, что уже давно применяю такой подход. Я никогда не задумывался об этом до разговора с Джедом. Для меня как практика данное определение, пожалуй, самый веский довод в пользу прототипирования.

Модель № 1: коммуникация.

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

Доводилось ли вам бывать в одной комнате с группой инженеров и маркетологов? Они не могут общаться друг с другом. То есть говорить-то они могут, но беседы не получается. Они друг друга не понимают. Они используют разные языки. Пригласите в одну комнату разработчика интерфейсов, архитектора информационных систем и специалиста по удобству использования – и можете запастись попкорном и колой, усесться поудобнее и наслаждаться представлением.

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

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

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

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

Совет.

Используйте возможность сотрудничества.

Прототипирование в сотрудничестве с коллегами – отличное упражнение для создания команды. Опробуйте этот подход.

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

Другая важная выгода от прототипирования как платформы для общения проявляется, когда команды разработчиков находятся далеко друг от друга. По мере роста компании команда становится сегментированной. Группа маркетинга сидит на одном этаже, проектировщики – на другом, разработчики – на третьем. Позже сотрудники могут оказаться в разных зданиях, а то и в разных городах. К тому же существует офшорный бизнес – ваши разработчики могут оказаться в Индии, России или Китае.

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

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

Такой метод «покажи и расскажи» Роберт Хекман-младший называет протокастами (своего рода аналог подкастов[11]). Хекман создает серию экранов, обычно в программе OmniGraffle, и затем записывает симуляцию работы важных элементов прототипа.

Протокоммуникации.

Роберт Хекман-младший (www.rhjr.net, www.miskeeto.com).

Несомненно, прототип может кратко рассказать о проекте взаимодействия или даже о приложении в целом. Но создание прототипов – не только материализация идеи для показа заинтересованным сторонам, как будет работать приложение, или оценки реализуемости проекта.

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

Рассмотрим конкретный пример.

При работе над многофункциональными интерфейсами, например RIA или интерфейс «по требованию» в стиле Web 2.0[12], иногда сложно детально описать многочисленные состояния одного экрана или одиночное взаимодействие с экраном через отдельные изображения. Чтобы разделить эти взаимодействия на удобоваримые компоненты, я обычно создаю раскадровку – серию эскизов, показывающих состояния экрана по мере взаимодействия. И, конечно, я стараюсь как можно лучше документировать взаимодействия, подробно отражая варианты использования в «документе описания проекта» (Design Description Document, см. www.rhjr.net/ddd). Однако часто этого недостаточно.

При использовании раскадровок возникают две проблемы. Во-первых, мне необходимо визуализировать переход из одного состояния в другое, но я не имею возможности «проделать» этот путь воочию. Во-вторых, то же приходится делать клиентам. И хотя во многих случаях раскадровки приносят отличный результат, прототипы «оживляют» идею и дают возможность каждому изучать проект таким способом, который не может быть реализован с использованием только статичных изображений, даже в формате раскадровки.

Теперь я иногда использую для работы по проектированию взаимодействия программу OmniGraffle. Она поддерживает назначение некоторых базовых функций на клики по каркасным представлениям и диаграммам. Это позволяет быстро создать и передать другим очень схематичный набросок прототипа, который можно «прощелкать», в виде документа PDF в любой момент. Таким образом, я не только могу представить документ, который каждый в состоянии открыть и опробовать. Создаваемый мною прототип выше уровнем, чем обычный видеофильм, показывающий работу прототипа и записанный с помощью инструментов SnapzProX (Mac) или Camtasia (Windows).

Эти «протокасты» (www.rhjr.net/shorty/protocasting), как я их называю, – просто запись моего взаимодействия с прототипом, сопровождаемая голосовыми комментариями по поводу выполняемых действий. Это могут быть размышления, технические ограничения, предложения по улучшению и т. д.

Протокасты – отличный инструмент не только для более четкого объяснения взаимодействия, чем при использовании раскадровки, но и для обзора удобства использования и важных исследований других характеристик. Я просто фиксирую изображение экрана, когда завершаю одну из задач приложения, и надиктовываю свои критические замечания, прежде чем переходить к следующей. Я даже могу говорить от лица гипотетического пользователя, например: «На самом деле я не понимаю, что означает этот значок… Может, я лучше нажму на эту кнопку и посмотрю, что произойдет… Ой, это не то, чего я хотел».

Для создания прототипа в формате PDF с помощью OmniGraffle и записи протокаста требуется очень мало усилий и времени. Я могу делать это часто в рамках рабочего процесса. А время, требующееся на создание прототипов и протокастов, с лихвой компенсируется экономией минут и часов на обсуждениях, которые неизменно давали только схематичные результаты.

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

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

Эффективное общение – важный элемент успешного проекта.

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

Модель № 2: доработка и проектирование.

В перепроектировании используются две модели: «легкая ретушь» и радикальная переработка.

В первом случае сохраняется облик проекта, вносятся небольшие обновления. Может быть, вводится несколько новых функций, улучшений или исправлений, но в целом проект остается прежним. Это больше похоже на «причесывание», чем на перепроектирование.

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

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

Модель № 3: «продайте» свою идею в компании.

В большинстве случаев работа на благо потребителей и обеспечение большего удобства использования в итоге оказываются крайне выгодными. Чтобы проверить эту гипотезу на практике, консультационная фирма по вопросам удобства использования Teehan+Lax создала фонд UX Fund, который вкладывает средства в компании, нацеленные на обеспечение максимального удобства использования их продуктов, чтобы посмотреть, каковы будут результаты в сравнении с другими компаниями в отрасли.

В ноябре 2007 года этот фонд показал годовые темпы роста в 39,5%[13]. Эта величина сама по себе впечатляет. Она будет еще более впечатляющей, если сравнить ее с общим состоянием рынка в то время. В конечном итоге вложения в удобство использования наиболее интересны для бизнеса, но не все в это верят.

Несколько лет назад я участвовал в разработке одного из первых коммерческих продуктов VoIP (голосовая связь в интернете) на рынке. На самом деле это была моя вторая попытка в данной области; первая стала жертвой краха доткомов.

При поиске решения чаще всего рассматриваются конкурирующие варианты. Другой метод – посмотреть на похожие продукты (например, мобильные телефоны, домашние телефоны, телефоны для офиса). Еще один метод, мой любимый, – исследование новых моделей взаимодействия и решений. Каждая проблема имеет много вариантов решений, и выбрать лучшее иногда сложно.

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

Существуют традиционные модели ввода в веб-приложения нескольких номеров или фрагментов данных. Главное – разместить на экране несколько десятков полей для ввода. Это помогает достичь цели, но десятки полей для ввода номеров нельзя назвать простым и аккуратным решением. Поэтому у меня появилась другая идея: добавлять поля по мере необходимости. Начните с простого дизайна и модифицируйте его, когда это потребуется.

Я описал свою идею менеджеру продукта и команде разработчиков, а затем показал им набросок (рис. 3.1). Рассмотрев его, они поняли концепцию. Менеджменту идея понравилась, но команда разработчиков хотела сделать группу статичных полей, поскольку это проще. (Ниже я расскажу, что произошло дальше.).

Прототипы – инструмент «продажи» технической реализуемости и ценности вашей концепции. В некоторых случаях они могут оказаться настолько эффективными, что высшее руководство даст распоряжение команде разработчиков просто создать их.

Прототипирование. Практическое руководство

РИС. 3.1. Набросок динамически добавляемых полей

Совет.

Лучше показать, чем рассказать.

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

Модель № 4: тестирование удобства использования.

Помните программу VoIP, о которой шла речь выше? Нам было нужно, чтобы группа разработчиков «купила» ее. Они не были уверены в пользе предложенного решения, и мы решили провести тесты на удобство пользования. Это помогло бы оценить, хороша концепция или нет. Если она эффективна – отлично. Мы смогли бы предоставить полученные данные руководству и разработчикам как сильный аргумент в пользу своей идеи. Если нет, то мы бы об этом быстро узнали и смогли бы рассмотреть другой вариант.

До начала тестов я был уверен, что люди получат рабочую модель с динамическим вводом, но не знал, будет ли она понятна. Я ожидал, что кто-то примет ее сразу, а кто-то поймет только в ходе использования.

Каркасное представление не вызывает бурных восторгов. Я никогда с таким не сталкивался.

Дэвид Верба, Adaptive Path.

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

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

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

Я считаю, что успех объясняется рядом факторов. Во-первых, на экране был только один вариант действия, если не считать кнопки «Сохранить»: кнопка со значком «плюс», которую все воспринимали как кнопку добавления». (В данном случае мы также использовали всплывающую подсказку.) Уменьшение количества вариантов возможных действий сокращает вероятность непонимания. Во-вторых, размещение этого значка рядом с полем ввода помогало сделать вывод: «Это действие относится к этому полю».

Мы могли бы потратить часы, ходя кругами вокруг команды разработчиков и пытаясь «продать» им наше решение. А на деле им надо увидеть пример и результаты, а не просто услышать о них. Тогда они станут более восприимчивы, хотя сомнения останутся.

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

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

Модель № 5: оценка технической осуществимости и стоимости.

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

Множество отличных проектов было отвергнуто разработчиками или технологическими командами, убежденными, что реализовать эти идеи не удастся. Если вы проектировщик и у вас есть отличный проект без прототипа, вам предстоит жестокая и упорная битва.

Иногда на вашей стороне высшее руководство компании, которое заставит разработчиков реализовать ваш проект. А если нет? Если проект действительно сложен? Если в нем непросто разобраться? Тогда необходимо задуматься о создании прототипа.

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

Реализуемость и целесообразность одинаково важны. Имея программу, вы можете сделать все, что захотите. Нужно лишь вложить в нее достаточно времени и ресурсов. Но в этом и кроется ловушка. Для бизнеса в целом может быть значительно хуже, если на разработку некоторой возможности или нескольких возможностей будут потрачены время и усилия. Окупаемость инвестиций – весомый аргумент и для разработчиков, и для руководства.

Для участников технологической команды окупаемость инвестиций означает соотношение размера кода и его функциональности. Работоспособность они определяют на основе технических аспектов. Один мой подчиненный, инженер, как-то заявил, что определяет работоспособность так: если он открывает окно терминала, то должен увидеть, что на компьютере запущен сервер Apache. А я ожидаю увидеть страницу в окне моего браузера. И обе эти ситуации означают, что Apache «работает».

Для бизнеса окупаемость инвестиций – соотношение вложений и прибыли. Затраты могут быть фиксированными, например при покупке компьютерного оборудования и программного обеспечения для создания рабочего места, или плавающими, например стоимость обслуживания или привлечения и удержания клиентов. Чем сильнее мы хотим получить чистое соотношение, тем больше практического опыта нам нужно, чтобы достичь «просветления»; на деле же бизнес несет финансовую ответственность перед «просветленными» работниками.

Большинство наших прототипов имели качество конечного продукта. HTML, CSS и JavaScript часто используются командой разработчиков для создания финальной версии. Нельзя сказать, что это типично, зато реализуемо.

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

Когда мы отдаем прототип пользователям, они видят немедленную выгоду. Предоставьте им несколько дней на тестирование – и они ваши. Если пользователи «купят» прототип, руководство последует их примеру.

Практический пример: IntraLinks.

Тодд Заки Варфел.

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

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

Итоговый вариант стал результатом эволюции прототипов. Сотрудники IntraLinks не тратили полтора года на один-единственный прототип. Они показали мне ряд предыдущих версий. Многие из тех прототипов значительно отличались от последней версии, которую они были готовы представить пользователям. Они подвергали каждый прототип тестам, и результаты получались разными.

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

Возможно, вы удивитесь: «Если это действительно так здорово звучит, то зачем они стали этот прототип тестировать?» Потому что для них это была новая концепция проектирования. Точнее, имелось несколько радикально новых концепций. Проектировщики хотели увидеть реакцию пользователей. Некоторые потребители применяли предыдущую версию в течение пяти лет. Даже если новый проект оказывался «лучше», его запуск стал бы катастрофой, если бы представители целевой аудитории не смогли с ним работать.

Во-первых, старая версия была ориентирована на страницы: страница обновлялась после каждого действия, сопровождаемого нажатием кнопки. Это не значило, что приложение нерабочее; просто оно устарело и стало неэффективным. А в новой версии использовалась экранная модель с частично отсутствующими фиксированными состояниями и богатыми возможностями взаимодействия, которую часто называют RIA. В ней была масса современных функций, например перетаскивание, использование правого клика мышью, контекстные меню и автообновление. Как и в любом случае кардинального изменения интерфейса, разработчики хотели узнать, не испортили ли они продукт. А если приложение улучшилось, то насколько?

Во-вторых, у них были актуальные вопросы. Смогут ли пользователи воспринять новую концепцию? Обнаружат ли они возможность перетаскивания? Как насчет кликов правой кнопкой и контекстных меню? Если они станут использовать эти возможности на одних участках приложения, на каких еще участках такие возможности будут уместны? Какие концепции не работают вовсе или нуждаются в улучшении?

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

В целом участники позитивно отреагировали на новый дизайн.

Некоторые отметили, что он напоминает другие приложения. Многие возможности взаимодействия, отличавшиеся от таковых в предыдущей версии IntraLinks, были знакомы из-за схожести с проводником Windows, Outlook и другими программами. Команда проектировщиков IntraLinks выгодно использовала знания, полученные при работе с другими приложениями, в своем новом проекте.

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

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

Для компании IntraLinks способность применять прототипы для изучения различных решений в ходе проектирования была первостепенной. Разработчики использовали прототипы для изучения решений, что особенно ценно при создании новой концепции дизайна или RIA.

Резюме.

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

• создание среды для совместного общения;

• переработку методом проектирования;

• «продажу» идеи своему начальнику или коллегам в компании;

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

• оценку технической реализуемости и стоимости.

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

В следующей главе я опишу восемь руководящих принципов прототипирования.

Глава 4. Восемь руководящих принципов.

Создать прототип не так сложно, как кажется. На это способен любой человек. И как в любом деле, чем больше опыта – тем легче. Но здесь есть подвох: потерпеть неудачу тоже легко.

Большинство ошибок (как моих, так и тех, о которых я знаю) было вызвано вовсе не выбором плохого инструмента или метода. Многие из них возникали в таких ситуациях:

• создавалось слишком много или, наоборот, слишком мало прототипов;

• прототипировались не самые нужные компоненты;

• не определялись ожидания, которым должны были удовлетворять прототипы.

Для эффективного прототипирования необходимо найти баланс и определить ожидания. В этой главе я опишу восемь руководящих принципов для повышения эффективности прототипирования. Они не зависят от применяемых методов или инструментов.

Эти принципы будут полезны и тем, кто имеет опыт прототипирования, и тем, кто только начинает пробовать себя в этой области.

Принцип № 1: узнайте целевую аудиторию и ее намерения.

Это первый и наиболее важный принцип прототипирования. Понимание того, для какой целевой аудитории создается прототип и с какими намерениями, определяет все остальные аспекты этого процесса. Выявив аудиторию и ее намерения, вы сможете сделать следующее:

• определить, что́ необходимо для создания прототипа;

• установить приемлемые границы ожидаемого;

• определить требуемый уровень точности;

• выбрать правильный инструмент для работы.

Для начала нужно решить вопрос о целевой аудитории – это отправная точка разработки. Когда вы поймете, кто будет изучать прототип, то сможете определить, что от него требуется, насколько подробным должно быть прототипирование и насколько высокая точность желательна.

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

Однако если аудиторией будут пользователи или высшее руководство, вам, скорее всего, понадобится что-то более привлекательное. Эскиз на салфетке их не устроит.

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

Когда вы определили аудиторию и направление к цели, можно начинать планирование и прототипирование.

Принцип № 2: планируйте немногое, прототипируйте остальное.

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

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

Меня часто спрашивают: что нужно спланировать, прежде чем начать прототипирование? Единого рецепта нет. Лично я делаю до 70% проекта в виде набросков и затем приступаю непосредственно к прототипированию.

Почему 70%? Тому есть две основные причины. Во-первых, моя цель – получить отзывы от аудитории, и чем быстрее я представлю ей проект, тем раньше появится отклик. Во-вторых, прототипирование – отличный инструмент для работы над проектом. Если я проделаю 70% работы на бумаге, то во время прототипирования выполню оставшуюся часть.

Поэтому прототипирование – смелый и решительный шаг. Тем, кто использует каскадную модель[14] или работает в условиях ограничения сроков, оно, скорее всего, неудобно. Но попробовать стоит. Отведите 70% времени на создание плана на лекционной доске или бумаге, а затем начните прототипирование. Я уверен, вам понравится результат.

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

Есть и другие важные факторы, например среда разработки, используемые инструменты и т. п. Возможно, вам лучше потратить на план не 70% времени, а больше (или меньше). Поэкспериментируйте с количеством времени на планирование и прототипирование. После нескольких попыток вы найдете для себя золотую середину.

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

Принцип № 3: формируйте ожидания.

Формирование ожиданий основано на психологическом приеме подготовки. Когда вы готовите аудиторию к чему-то, вы направляете ее внимание.

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

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

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

Ожидания обычно формируются по двум направлениям: точности и функциональности прототипа. У компаний, которые только начинают прототипирование, на этом этапе возникают серьезные ошибки (но их легко избежать).

Вспомните первый принцип: знать целевую аудиторию и ее намерения. Если это первый опыт прототипирования для аудитории, важно задать ее ожидания в отношении прототипа. Реакция будет более доброжелательной, если зрители смогут предугадать, что они увидят, а чего не увидят.

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

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

Совет.

Создайте сценарий показа.

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

Принцип № 4: делайте наброски.

Мы сделали прототип с настолько низкой точностью, что это даже было не смешно.

Скотт Мэттьюз, Компания Xplane.

На небольшой конференции под названием Overlap («Совпадение») Дэвид Грей из Xplane попросил поднять руки тех, кто умеет рисовать. Из более чем 40 участников руки подняли только несколько человек. Тогда Дэйв задал другой вопрос: «Кто умел рисовать в детстве?» Руки подняли все. Потом Дэйв спросил: «Так что же случилось за это время, почему вы разучились рисовать?» Ни у кого не нашлось достойного ответа.

Дэйв с помощью коллеги Скотта Мэттьюза показал, как можно изобразить все нужное с использованием простых элементов: квадрата, треугольника, круга и прямых линий. Он нарисовал бегущего человека (рис. 4.1).

Прототипирование. Практическое руководство

РИС. 4.1. Набросок бегущего человека

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

Я не считаю себя художником, но я делаю наброски – много набросков. Некоторые из них более тщательны, чем другие. Иногда я добавляю на полях заметки, в других случаях просто рисую линии, чтобы показать, что здесь должна быть заметка (рис. 4.2).

Прототипирование. Практическое руководство

РИС. 4.2. Набросок с линиями для заметок и текста

Если я делаю черновой набросок, то меня интересуют только отдельные необходимые участки экрана, и тщательно я ничего не прорисовываю, использую только линии. Этот же метод я применяю, если делаю набросок с другим проектировщиком или с клиентом.

Если порядок полей важен и мне надо передать это, я рисую более тщательно, либо добавляю заметки, либо запускаю Illustrator и делаю набросок в нем.

Таким образом, мы снова вернулись к первому принципу: знать целевую аудиторию и ее намерения. Мне достаточно линий и квадратов, без примечаний. (Их список у меня есть на отдельном листе бумаги.) Если мне нужно показать набросок другим людям, то я обычно добавляю заметки.

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

Совет.

Симулируйте AJAX на лекционной доске.

Попробуйте использовать для набросков лекционную доску.

Симулировать взаимодействия и переходы AJAX можно путем стирания и перерисовывания элементов.

Принцип № 5: это прототип, а не Мона Лиза.

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

Если он не закончен, участники обсуждения охотнее высказывают замечания. У них нет ощущения, что все решения приняты и, следовательно, не подлежат изменению.

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

Однако я точно могу сказать вам, что в большинстве случаев прототип не обязан быть Моной Лизой. Главное, чтобы он помогал достичь цели.

Ваша цель не совершенство. Это ведь прототип. Нужно с минимальными затратами сил и времени передать аудитории суть вашей идеи. И для этого необходимо правильно выбрать уровень точности. Не больше, чем требуется. Но и не меньше.

Принцип № 6: если не можете что-то сделать, притворитесь, что можете.

Вероятно, это самое серьезное препятствие для начинающих. Все лекции и доклады о прототипировании я начинаю с того, что задаю аудитории несколько вопросов:

• сколько участников умеют уверенно писать код (HTML или любой другой);

• сколько участников создавали прототипы ранее любым способом и в любой форме (в PowerPoint, HTML, Dreamweaver, PDF и пр.).

Как правило, оказывается, что чем больше проектировщиков в зале, тем меньше участников могут писать код и занимались прототипированием или чувствуют себя уверенно в этом деле. Обычно это порождает миф, что если вы не умеете программировать, то не можете и создавать прототипы. И этот миф стал еще более популярен с появлением RIA («Если вы не умеете писать программы на JavaScript, вы не можете и прототипировать»).

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

Барух Закс, Директор Компаний Human Factors Design И Pegasystems.

Если вы не умеете или не можете писать код, есть несколько способов сымитировать этот процесс:

• Можно сформировать серию экранов в формате JPEG. Используйте Dreamweaver для создания изображений и связывания их друг с другом. Вы не напишете ни строчки кода, но сможете получить отзывы об интерфейсе и понять, если ли в идее смысл.

• Применяйте встроенные функции Fireworks для связывания страниц и фреймов и создайте HTML-прототип, с которым можно работать с помощью мыши.

• Используйте Adobe Acrobat или другой редактор PDF и свяжите экраны между собой, чтобы добиться такого же результата, как и в предыдущем случае.

• В PowerPoint вы сможете связать последовательность статичных экранов.

• Применяйте последовательность HTML-экранов, чтобы симулировать AJAX и другие варианты многофункциональности.

В докладе о процессе DC Refresh я обсуждал прототип, который мы недавно создали для клиента. Я поведал о некоторых многофункциональных взаимодействиях, внедренных в прототип с помощью популярной JavaScript-библиотеки Prototype.

Я сказал слушателям, что покажу несколько основных взаимодействий типа «скрыть-показать», встроенных в прототип, и добавил, что одни из них реальны, а другие только изображены. Затем я продемонстрировал им функцию «скрыть-показать» для расширенного поиска (рис. 4.3 и 4.4).

Прототипирование. Практическое руководство

РИС. 4.3. Простой поиск (скрыть)

Прототипирование. Практическое руководство

РИС. 4.4. Расширенный поиск (показать)

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

Однако это не имело значения. Аудитория восприняла концепцию.

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

Принцип № 7: прототипируйте только необходимое.

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

Если главная цель – тестирование, вероятно, вы опробуете 5 или 6 сценариев. Тогда необходимо создать только те элементы, которые нужны для этих сценариев.

Что будет, если участник тестирования нажмет на нерабочий элемент прототипа? Это прототип. Он по своей сути неполон. Если участник тестирования выберет еще не реализованную возможность, узнайте у него, чего он ожидал.

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

Принцип № 8: снижайте риски – прототипируйте на ранних этапах и часто.

У нас есть гигантские компании, которые по традиции делают на компьютерах трехмерные модели, создают вещи и обнаруживают проблемы, когда уже слишком поздно.

Андерс Рэмси.

Как я уже говорил, прототипирование имеет ряд преимуществ, одно из которых – благоприятное соотношение затрат и прибыли. Рассмотрим две модели разработки: традиционную каскадную и модель с быстрым итеративным прототипированием.

В традиционной каскадной модели все функции и возможности системы планируются до начала разработки. Поэтому цикл планирования до начала непосредственной работы иногда длится 6–9 месяцев.

В среде, которая меняется медленно или несущественно, это не проблема. Однако в современной отрасли программного обеспечения девять месяцев – это продолжительность жизни: за это время компания может быть создана, куплена, продана или закрыта.

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

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

Другой метод более гибок. Вы выделяете небольшие куски и используете инкрементный[15], итеративный и эволюционный подход. А если вы вдобавок применяете прототипирование, то работаете только над небольшими фрагментами системы. Меньше вложений – меньше риск.

Вы выделяете по несколько недель на небольшой набор концепций и проверяете, эффективны они или нет. Если они не срабатывают, то вред намного меньше, поскольку вы теряете всего пару недель и можете выбрать другие, более эффективные идеи. Вам не нужно тратить на это еще 6, 9, 12 или 18 месяцев.

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

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

Чем раньше вы обнаружите ошибку, тем легче и дешевле будет ее исправить. И не пытайтесь обмануть себя – ошибки неизбежны. Согласно экспертным оценкам, изменения, внесенные на этапе проектирования, могут обойтись в 10% стоимости проекта, а в ходе разработки или после выпуска продукта – до 100%.

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

Резюме.

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

• узнайте целевую аудиторию и ее намерения;

• планируйте немногое, прототипируйте остальное;

• формируйте ожидания;

• делайте наброски;

• это прототип, а не Мона Лиза;

• если не можете что-то сделать, притворитесь, что можете;

• прототипируйте только необходимое;

• уменьшайте риски – прототипируйте на ранних этапах и часто.

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

Глава 5. Выбор правильного инструмента.

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

Мне ответили около 200 человек из различных областей, включая исследователей, проектировщиков, разработчиков, менеджеров продуктов и бизнес-аналитиков.

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

Факторы влияния.

Большинство моих ранних прототипов было создано с использованием HTML и CSS. Мне пришлось симулировать почти все взаимодействия и переходы AJAX. Программировать на JavaScript я умел плохо.

Однажды я решился познакомиться поближе с JavaScript-библиотеками Prototype и script.aculo.us. Испытания заняли несколько дней, и наконец у меня начало что-то получаться. С тех пор моя жизнь изменилась.

В то время, когда писалась эта глава, большинство своих прототипов я создавал с использованием HTML, CSS, Prototype и script.aculo.us. Мои навыки программирования на JavaScript совершенствовались, и мне больше не нужно было симулировать AJAX.

Количество доступных вариантов прототипирования продолжало увеличиваться. К тому моменту, когда я закончу эту книгу, мой набор инструментов может снова измениться. Я попробовал JavaScript-библиотеку jQuery. Компания Adobe только что выпустила новые версии Fireworks и Flash. Кто знает, что еще появится?

Так почему люди выбирают HTML, Flash, Fireworks, Axure или что-то еще? Согласно опросу, на выбор инструмента сильнее всего влияли следующие факторы (в порядке убывания важности):

1. Знание инструмента и его доступность.

2. Время и усилия, необходимые для создания работающего прототипа.

3. Возможность создания прототипа, пригодного для тестирования.

4. Цена.

5. Характер кривой обучения.

6. Возможность создавать свои интерфейсные виджеты.

7. Доступность на используемой платформе.

8. Возможности совместного и удаленного проектирования.

9. Встроенные решения или шаблоны для переходов AJAX.

10. Встроенные интерфейсные виджеты.

11. Создание кода, пригодного к дальнейшему использованию.

Я нашел в этом списке все факторы, влиявшие на мой выбор, за единственным исключением: знание аудитории и ее намерений. Для меня это критерий номер один. Но другие мои критерии, например знакомство с инструментом, доступность, удобство использования, наличие интерфейсных виджетов и AJAX или возможность создавать свои виджеты, в списке есть. Просто они менее важны для меня.

Я еще вернусь к этому списку, когда буду рассказывать об оценке инструментов для прототипирования.

В списке есть требование: создание кода, пригодного к дальнейшему использованию. Заметили, что оно стоит в списке последним? Оно несколько коварно.

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

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

Когда книга готовилась к изданию, не было инструмента прототипирования, предназначенного для людей, не умеющих программировать, который мог бы при небольших затратах быстро создавать прототипы и генерировать повторно используемый код. Если вам нужен инструмент для прототипирования, генерирующий код, придется изучить HTML или использовать шаблонизаторы, например Ruby on Rails.

Какими инструментами пользуются другие.

Как я и ожидал, предполагаемые лидеры, такие как бумага, PowerPoint, Flash и HTML, вошли в список наиболее часто используемых. Не удивило и то, что участники опроса назвали более одного инструмента. Например, они могли использовать бумагу для составления набросков, которые затем переносились в Photoshop и, наконец, в HTML.

В последние пару лет на рынок вышли два заметных новичка, а именно Axure RP и Fireworks. Fireworks уже некоторое время была представлена на рынке, но только недавно в ней появилась возможность создания прототипов. Вот список инструментов, чаще всего использовавшихся для прототипирования взаимодействия с пользователем в 2008 году (табл. 5.1)[16].

Таблица 5.1. Результаты опроса о часто используемых инструментах прототипирования

Прототипирование. Практическое руководствоПрототипирование. Практическое руководство

Наверняка вы найдете в списке несколько знакомых инструментов. Заметили ли вы что-нибудь странное?

Пожалуй, самым удивительным для меня было число людей, использующих для прототипирования Visio. Я ожидал увидеть в списке эту программу, но не думал, что ее доля составит 60%. Другим сюрпризом оказалось присутствие в списке Excel и FileMaker (правда, обе набрали меньше 1% голосов). Наконец, удивило общее число инструментов, используемых для прототипирования, – более 26, если считать те, что вошли в графу «Другие».

Какие виды прототипов они создают.

Бумага по-прежнему во главе списка. Рост популярности библиотек AJAX, например Prototype и jQuery, в сочетании с увеличением числа инструментов с автоматической генерацией кода, таких как Axure, iRise и Fireworks, существенно облегчил процесс создания интерактивных прототипов.

Среди инструментов прототипирования, увеличивающих свою долю, – Ruby on Rails (RoR). Это фреймворк для быстрой разработки приложений – идеальный инструмент и для прототипирования, и для создания конечного продукта. В нем есть все возможности HTML плюс возможность использования динамических данных.

В табл. 5.2 приведена разбивка видов прототипирования по доле их использования членами сообщества специалистов по взаимодействию с пользователем.

Таблица 5.2. Результаты опроса о видах используемых прототипов

Прототипирование. Практическое руководство

Большинство моих прототипов созданы с применением HTML и AJAX. Я пользуюсь средой HTML/CSS, которую мы разработали в Messagefirst для своих нужд, в сочетании с JavaScript-библиотеками Prototype и jQuery. Поскольку код всех моих прототипов написан вручную с использованием существующих проверенных сред и JavaScript-библиотек, я могу обеспечить быстрый итеративный подход.

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

Резюме.

Я никогда не делал что-либо только потому, что это делают другие. Работа по созданию прототипов не исключение из этого правила.

Мои прототипы в основном HTML-разработки уровня конечного продукта, но большинству людей я не рекомендовал бы такой подход. Я выбрал этот метод, потому что он удовлетворяет моим нуждам и мне удобно использовать соответствующие инструменты. Так что же я рекомендую при выборе метода и инструмента прототипирования? Учитывайте следующие факторы:

1. Аудитория: кто будет смотреть прототип или работать с ним?

2. Намерения: вспомните пять видов прототипов. Какие из них вам нужны?

3. Степень знакомства и возможность изучения: знакомы ли вы с методом или инструментом, хотите ли их изучать?

4. Стоимость: принимайте во внимание стоимость не только лицензии, но и простоя, пока вы будете изучать инструмент.

5. Совместная работа: нужна ли она? Если да, то ваши возможности заметно ограничены.

6. Распространение: как вы собираетесь сообщать результаты другим людям?

7. Выбросить или использовать повторно: если нужен повторно используемый код, то выбор ограничен. Если нет, что гораздо более вероятно, то перед вами широкий выбор.

Сравнительная таблица есть на форзаце книги. Она поможет оценить рассмотренные методы и инструменты.

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

Бумажный и другие аналоговые методы.

[17].

Прототипирование. Практическое руководство

Глава 6. Бумажный и другие аналоговые методы.

Прототипирование на бумаге – самый гибкий метод из существующих. Бумага идеальна для создания чего угодно, от веб-интерфейсов до жестовых взаимодействий.

Прототипирование на бумаге существует много десятилетий и было популярно преимущественно в академических институтах и крупных корпорациях, таких как IBM, Digital и Sun в 1990-е годы. В те времена на вас, скорее всего, посмотрели бы странно, если бы вы сказали, что делаете прототипы из бумаги. Как изменились времена!

Фотография Кристиана Крамера, компания Cultured Code

Прототипирование. Практическое руководство

РИС. 6.1. Образец бумажного прототипа приложения Things для iPhone

В наше время прототипирование на бумаге – самый распространенный метод. 76% респондентов моего опроса сказали, что применяют его. Из всех методов, которыми я пользовался за долгие годы, он остается одним из любимых. Конечно, бумага и иные аналоговые инструменты имеют свои недостатки, как и любой другой метод. Но преимущества настолько велики, что глупо не использовать его в прототипировании.

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

Сильные стороны.

Некоторые очевидные сильные стороны прототипирования на бумаге перечислены ниже.

• Гибкость. Бумага – один из немногих инструментов, которые одинаково хорошо подходят для прототипирования и программ, и физических устройств, особенно мобильных, а также взаимодействий с помощью жестов.

• Быстрота. Практически любое взаимодействие можно прототипировать в считаные минуты.

• Дешевизна. Не нужно оплачивать лицензии на программы. Все инструменты, скорее всего, уже есть у вас дома или в офисе.

• Легкость. Входной барьер практически отсутствует. Заняться этим может любой человек.

• Изменения вносятся на лету. Представьте, что в середине процесса тестирования участник выдвигает концепцию, о которой вы не подумали. Нет проблем. Вы отредактируете свой бумажный прототип сразу, и этот участник даже может вам помочь.

• Совместная работа. Очень удобно работать с другими членами команды или с участниками тестирования на удобство использования.

• Не связан какими-либо программными или аппаратными ограничениями. При прототипировании на бумаге вы не привязаны к предустановленным виджетам графического интерфейса или способам взаимодействия. Бумага позволяет изучить любые взаимодействия.

• В любом месте, в любое время. Прототипирование на бумаге не требует наличия компьютера и может осуществляться где угодно и когда угодно.

Слабые стороны.

Хотя прототипирование на бумаге – один из самых популярных (и любимых мной) методов, и у него есть свои недостатки.

• Распределенная работа. По очевидным причинам работа с бумажными прототипами затруднена, если члены команды находятся далеко друг от друга. Пересылка бумажных прототипов, например из США в Ирландию и обратно, несколько затруднительна. Средства совместной работы с изображениями на экране, такие как Adobe Acrobat Connect или WebEx, облегчают задачу.

• Нужно воображение. Это не настоящий iPhone, поэтому придется включить воображение.

• Визуальная эстетика. Если вы хотите оценить влияние цвета на удобство использования, бумага, скорее всего, вам не подойдет.

«Бумажное» прототипирование на лету.

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

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

Мы провели тестирование с первым участником четко по сценарию и спросили его, как он представляет себе блокировку номера. Он поступил неожиданно (как часто и бывает): попытался нажать на номере правую кнопку, ожидая увидеть список команд и среди них «Заблокировать этот номер». Такого решения мы не прорабатывали. Оно было разумно, но не входило в число концепций, которые мы рассматривали (это было до того, как на сцене воцарился AJAX).

Мой ассистент спросил: «Что же нам теперь делать?» Я просто взял желтый листок для заметок с липким слоем, нарисовал на нем несколько команд, налепил его выше номера и спросил: «Примерно так?» Участник тестирования улыбнулся и ответил: «Да, да, именно так».

Другие девять участников сделали то же. Бумажный прототип позволил нам создать альтернативное решение за считаные секунды – мы не смогли бы добиться этого при использовании цифровых прототипов.

Инструменты, необходимые для прототипирования на бумаге.

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

• Бумага. Стопка обычной белой бумаги формата АЧ. Мы используем ее как основу для любого проекта.

• Прозрачная пленка. Стопка листов прозрачной пленки формата АЧ. Она удобна для симуляции нажатия нескольких клавиш и популярных эффектов подсветки.

• Каталожные карточки. Стандартные карточки размером 7,5×12,5 см используются для разных целей, например изображения диалогового окна или виджетов графического интерфейса. Мы предпочитаем карточки, разлинованные с одной стороны и чистые с другой. Сообщения диалогового окна можно аккуратно написать по линейкам.

• Бумага для заметок. Я предпочитаю желтую, но подойдет любой цвет. Липкие листочки удобны для таких целей, как изображение смены состояний слоев на страницах, подсветка отдельных элементов на экране или диалоговых окон.

• Цветные ручки или маркеры. Я включаю в набор маркеры с тонкими и толстыми наконечниками: черный, синий, красный и зеленый. Большинство эскизов делаются черным или синим цветом, сообщения об ошибках – красным, а сообщения об успешном завершении – зеленым.

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

• Плоская зубная нить. Это одна из моих хитростей. Она отлично подходит для симуляции анимации. В прошлом я использовал ее для перемещения головки аудиопроигрывателя или протягивания ленты фотографий через окно фотогалереи.

Используйте Illustrator или Visio, чтобы создать свои интерфейсные виджеты.

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

Последовательное прототипирование на бумаге.

Дальше будет весело. Я покажу ряд приемов по созданию многофункциональных прототипов. Начнем с основных приемов, таких как проектирование форм, и перейдем к более развитым методам, например симуляции AJAX. В первую очередь рассмотрим приемы создания виджетов графического интерфейса для бумажных прототипов. Файл Illustrator с примерами виджетов можно скачать здесь: rosenfeldmedia.com/books/downloads/prototyping/Paper_Prototype_GUI.ai.

Основы прототипирования на бумаге.

Рассматривайте ваш бумажный прототип как рецепт: вы берете несколько основных ингредиентов и комбинируете их так, чтобы создать нечто удивительное. Основные составляющие бумажного прототипа – оболочка и интерфейсные виджеты. Они могут быть нарисованы вручную (рис. 6.2) или напечатаны (рис. 6.3).

Не забудьте подготовить включенное и выключенное состояния для каждого элемента.

Совет.

Ручки.

Загните одну сторону виджета вверх под прямым углом, чтобы сформировать подобие ручки (рис. 6.4). Это облегчит манипуляции с ними во время тестирования.

Теперь, когда почти все нужные элементы готовы, начнем с простого, например формы для регистрации.

Прототипирование. Практическое руководство

РИС. 6.2. Нарисованные от руки виджеты приложения с графическим интерфейсом

Прототипирование. Практическое руководство

РИС. 6.3. Напечатанные виджеты приложения с графическим интерфейсом

Прототипирование. Практическое руководство

РИС. 6.4. Отогнутая ручка интерфейсного виджета

Прототипирование простой формы регистрации на бумаге.

Форма регистрации – обычный элемент веб-приложений и сайтов электронной торговли, поэтому с нее и начнем. Создадим форму для ваших клиентов, которая содержит следующие элементы:

• Введите имя и фамилию.

• Введите адрес электронной почты (используется для входа и восстановления пароля).

• Введите пароль.

• Запомнить меня.

• Зарегистрироваться.

• Вход для зарегистрированных пользователей.

На рис. 6.5 показан созданный мной пример. Все понятно, не так ли?

Прототипирование. Практическое руководство

РИС. 6.5. Бумажный прототип простой регистрационной формы

Коммуникативные изменения состояния.

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

При работе с бумажным прототипом изменения состояния могут быть легко отражены путем добавления текста к прототипу. Если участники тестирования хотят установить флажок, они могут просто нарисовать его ручкой. Но это работает только при установке флажка. А что делать, если его надо снять?

Помните те виджеты графического интерфейса, которые мы создали ранее? Если кто-то из участников хочет установить флажок, просто наложите сверху изображение с флажком (рис. 6.6). Это отразит изменения в состоянии и в то же время позволит легко проделать обратную операцию.

Прототипирование. Практическое руководство

РИС. 6.6. Бумажный прототип с установленным флажком на добавленном сверху интерфейсном виджете

Этот эффект полезен и для других элементов, таких как выбор из меню, переключатели и управление воспроизведением.

Можно было бы использовать его для отображения эффектов наведения курсора на объект или подсветки, но я в этих случаях предпочитаю прозрачные пленки.

Это одна из моих любимых маленьких хитростей. Пленки невероятно гибки. Я использую их для имитации разных эффектов, включая состояния навигации (см. рис. 6.7), подсветку полей ввода, когда в них переходит фокус, и эффектов перекрытия.

Прототипирование. Практическое руководство

РИС. 6.7. Прозрачной пленкой отмечена выделенная миниатюра в фотогалерее

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

Чтобы добиться этого, нужно следующее:

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

• кусок каталожной карточки для перекрывающего окна;

• лента или резиновый клей.

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

Когда участник переходит от одного поля формы к другому, вы можете сдвигать пленку вниз, симулируя контекстную подсказку. Если в поле подсказки нет, возьмитесь за отогнутый угол и снимите пленку. Так вы получите то, что нужно: контекстную подсказку в строке.

Прототипирование. Практическое руководство

РИС. 6.8. Подсвечивание выбранного поля и отображение контекстной подсказки в строке

Передовые методы прототипирования на бумаге.

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

Один из наиболее обычных приемов в духе AJAX[18] – скрытие или показ элементов, когда пользователь нажимает на ссылку для отображения дополнительной информации, а затем нажимает еще раз для ее скрытия. Этот эффект, пожалуй, симулировать проще всего.

Достаточно согнуть лист бумаги.

В этом примере я буду использовать виджет голосовой почты, который мы создали для веб-приложения. В состоянии по умолчанию он отображает каждое голосовое сообщение с некоторой информацией о нем. Если вы нажимаете кнопку раскрытия, то выбранное сообщение открывается, показывая дополнительную информацию и возможные действия (см. рис. 6.9). Если кнопку нажать еще раз, оно сжимается, пряча дополнительную информацию.

Чтобы достичь эффекта скрытия-показа, я возьму распечатку виджета и сделаю две складки – одну выше и одну ниже содержимого, которое я собираюсь скрывать или показывать (рис. 6.10).

Прототипирование. Практическое руководство

РИС. 6.9. Расширенное состояние виджета

Прототипирование. Практическое руководство

РИС. 6.10. Складки для симуляции эффекта скрытия-показа

Выход за границы привычного.

На конференции по взаимодействию, прошедшей в 2009 году в Саванне, я проводил занятие по прототипированию на бумаге и попросил участников создать карусель для фотогалереи. Я показал им виджет из библиотеки интерфейсов Yahoo! (YUI) в качестве примера. Большинство участников создали стандартную галерею со скользящими изображениями, похожую на карусель YUI (рис. 6.11).

Однако две группы создали совершенно неожиданный и потрясающе удачный вариант (рис. 6.12).

Прототипирование. Практическое руководство

РИС. 6.11. Простой бумажный прототип карусели

Прототипирование. Практическое руководство

РИС. 6.12. Трехмерный бумажный прототип карусели

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

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

Чтобы симулировать эффект, я складываю лист бумаги (по умолчанию это означает скрытый слой). Чтобы симулировать показ, я распрямляю бумагу, отображая дополнительное содержание. Это действительно просто.

Другой обычный прием симуляции – метод скольжения. Он полезен для представления фотогалереи, движения в видео– или аудиопроигрывателе, эффектов перелистывания обложек в iTunes или «умной» прокрутки в iPhone. Это уже сложнее и все-таки относительно просто.

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

Для начала потребуются три элемента: окно просмотра, средство выбора миниатюр и лента фотографий. Я создал их в программе Illustrator (рис. 6.13).

Прототипирование. Практическое руководство

РИС. 6.13. Компоненты фотогалереи

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

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

Прототипирование. Практическое руководство

РИС. 6.14. Лента с фотографиями, проходящая через окно просмотра

Совет.

Сделайте стопоры для полос.

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

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

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

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

Демонстрируя эффект, я мог получить более подробные отзывы, чем при простом описании. И я смог его симулировать в течение нескольких минут без всякого программирования.

Прототипирование физических устройств из бумаги.

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

Физические устройства более осязаемы, чем интерфейс программы, и ценность прототипирования на бумаге в данном случае выше. Можно сделать из бумаги физическую модель такого устройства, как iPhone (рис. 6.15), или даже автомата по продаже билетов в метро (рис. 6.16).

Фотография Стивена Туми

Прототипирование. Практическое руководство

РИС. 6.15. Бумажный прототип iPhone. www.flickr.com/photos/typeweight/357099407/in/set-72157594476948766/

Прототипирование. Практическое руководство

РИС. 6.16. Бумажный прототип автомата по продаже билетов в метро. www.flickr.com/photos/knute/2247602574/

Симулировать изменения экрана на физическом устройстве так же легко. Используйте изложенные выше рекомендации для эффектов скольжения.

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

Магниты с интерфейсными элементами.

Магниты с интерфейсными элементами – маленькие гибкие магниты с нарисованными на них элементами графического интерфейса. Их можно использовать на лекционных досках при проведении «мозговых штурмов» и легко перетаскивать в поисках наилучшего прототипа интерфейса. Купить их можно на сайте http://www.guimagnets.com/order/.

Дополнительную информацию можно найти в книге Кэролин Снайдер «Прототипирование на бумаге» на сайте paperprototyping.com.

Резюме.

Я убедил вас в необходимости прототипирования на бумаге? Чувствуете, что можете решить любую задачу? Теперь вы поняли, почему я считаю этот метод таким мощным:

• он быстрый, дешевый (чаще бесплатный) и простой;

• его можно использовать в любое время и в любом месте, компьютер не нужен;

• это один из немногих инструментов, удобных для совместной работы.

PowerPoint и Keynote.

Прототипирование. Практическое руководство

Глава 7. PowerPoint и Keynote.

Прототипирование. Практическое руководство

РИС. 7.1. Пример инструментальной панели, созданной в PowerPoint 2007. Источник: www.istartedsomething.com/20071018/powerpointJprototypeJtoolkitJ01/

Программы Microsoft PowerPoint и Apple Keynote – больше чем просто приложения для создания отличных презентаций. Они не так хороши, как Axure, Flash или HTML, но стали популярными инструментами прототипирования.

Насколько? Примерно в 40% случаев они в той или иной форме используются для прототипирования в отрасли. PowerPoint сыграл центральную роль в проектировании интерфейса Windows 7, Windows Live, Internet Explorer и Expression Blend в корпорации Microsoft[19].

PowerPoint так же вездесущ, как и Microsoft Word. Он поставляется в составе Microsoft Office, который установлен почти на каждом рабочем компьютере на планете. Те, кто сделал выбор в пользу Apple iWork, в тех же целях используют Keynote.

Бывало ли, что клиент или проектировщик давал вам несколько файлов Photoshop и просил сделать прототип? Вы можете, например, скрепить их в Dreamweaver и создать карту изображений. А можно применить PowerPoint или Keynote.

В этой главе я расскажу об использовании PowerPoint и Keynote для создания повествовательных и интерактивных прототипов и методах симуляции AJAX.

Сильные стороны.

Вот некоторые сильные стороны этих программ при создании прототипов:

• Кривая обучения. PowerPoint и Keynote – идеальные программы для людей нетехнического склада. В них используется модель перетаскивания и не требуется кода для обеспечения интерактивности.

• Осведомленность и распространенность. Пожалуй, главное преимущество PowerPoint – широкая распространенность. Почти на каждом компьютере установлены PowerPoint или Keynote. Скорее всего, это приложение есть и у вас, и у вашей целевой аудитории. Если у кого-то этих программ нет, можно экспортировать файл в PDF или HTML.

• Образцы слайдов. Можно использовать образцы слайдов, чтобы создать шаблоны и применять общие элементы в большом числе изображений. Образцы также повышают продуктивность работы и обеспечивают единообразие.

• Копирование и вставка. Можно легко копировать отдельные элементы или экраны целиком.

• Изменение порядка перетаскиванием. Изменение порядка экранов выполняется простым перетаскиванием. В режиме таблицы слайды показаны на сетке, что дает возможность легко перемещать целые разделы.

• Экспорт в HTML или PDF. Хотите запустить прототип в окне браузера? Экспортируйте его в HTML. Или экспортируйте в PDF и используйте Adobe Acrobat для создания дополнительной интерактивности, которую не поддерживают PowerPoint и Keynote.

Слабые стороны.

Эти инструменты имеют и свои слабые стороны при использовании для прототипирования:

• Ограниченный набор инструментов. Инструменты для рисования в PowerPoint и Keynote рудиментарны. Если вы хотите создать высококачественный проект, лучше использовать программы вроде Illustrator, Fireworks или Photoshop.

• Ограниченная интерактивность. Интерактивность ограничена ссылками. Их можно использовать только для перехода на другие экраны в пределах прототипа или на сайты в интернете.

• Код нельзя использовать повторно. Ни один из этих инструментов не создает код, который можно использовать повторно. В большинстве случаев это не проблема, поскольку не подразумевается, что прототип станет рабочим приложением. Однако если поставлена цель создать конечный код, лучше рассмотреть другие инструменты.

Я хотел бы избежать избыточности, поэтому дальше буду упоминать только PowerPoint вместо PowerPoint и Keynote. Все описываемые методы применимы к обеим программам, если явно не оговорено иное. Если метод нельзя использовать в обеих программах, я приведу отдельное описание для Keynote.

Создание повествовательных прототипов в PowerPoint.

Повествовательные прототипы часто используются для получения отзывов о работе верхних уровней программы: общем поведении приложения или общей эстетике системы.

Я использовал этот метод в прошлом для тестирования линейных систем, таких как мобильные устройства или цифровые видеокамеры, а также для сравнительного тестирования многочисленных вариантов дизайна (подробнее см. главу 12).

Процесс разработки повествовательного или линейного прототипа в PowerPoint достаточно прямолинеен. Если экраны созданы в другом редакторе изображений, например Photoshop или Fireworks, можно просто импортировать их в нужном порядке. Запустите презентацию и покажите все слайды.

Нет нужды в причудливых методах, приемах, программировании или настройке. Параметры PowerPoint по умолчанию позволяют сделать повествовательный прототип из экранов, которые вы создадите в других программах. Образец набора для прототипирования в PowerPoint и Keynote можно загрузить по адресу: rosenfeldmedia.com/books/downloads/prototyping/chapter7.zip.

Создание экранов в PowerPoint включает три основных шага.

Шаг 1: создайте файл.

1. Начните с пустого шаблона, выбрав из меню приложения File > New.

2. В Visio, Illustrator или другой программе для рисования создайте типовой экран или сделайте скриншот из браузера.

3. Выберите образец слайда и используйте стандартное окно как фоновый рисунок для образца.

4. Повторите пункт 3 для создания образца слайда для каждой разновидности экрана-шаблона, которая вам нужна.

Шаг 2: примените фоновый рисунок к образцу слайда в PowerPoint.

1. Выберите образец слайда, нажмите на нем правой кнопкой, выберите Fill Effects, затем Picture и потом картинку.

Шаг 2 (альтернативный): примените фоновый рисунок к образцу слайда в Keynote.

1. Откройте слайд. Выберите Appearance > Slide Inspector, затем Background и Image Fill (рис. 7.2).

Прототипирование. Практическое руководство

РИС. 7.2. Используйте фоновый рисунок в образце слайда в Keynote

Шаг 3: создайте набор общих интерфейсных виджетов.

Для программ Visio, OmniGraffle, Fireworks и Illustrator есть библиотеки интерфейсных элементов, которые можно найти на сайте этой книги. Один из самых простых способов создать типовую библиотеку интерфейсов для PowerPoint – скопировать элементы и вставить их в одну из таких библиотек.

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

Если вам нужен набор интерфейсных виджетов для PowerPoint, можно использовать PowerPoint Prototyping Toolkit (есть на сайте istartedsomething.com). Это набор окон приложений, диалоговых окон и типовых интерфейсных элементов в Windows Vista (рис. 7.3).

Прототипирование. Практическое руководство

РИС. 7.3. Набор инструментов для прототипирования в PowerPoint

Совет.

Образец слайда.

Создайте образец слайда и используйте его как палитру для интерфейсных виджетов. Когда вам понадобится виджет, вы сможете скопировать его из образца.

Создание интерактивных прототипов в PowerPoint.

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

• ключевые точки или начальное и конечное состояния;

• осмысленные названия слайдов;

• ссылки к кнопкам.

Шаг 1: ключевые точки.

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

При использовании PowerPoint размещайте каждую ключевую точку на отдельном слайде. Прототип не усложнится, и связать между собой экраны и состояния окажется проще. Если вы упустили какие-то точки, не беспокойтесь. Их можно добавить позже и изменить порядок слайдов при помощи перетаскивания.

Шаг 2: отключите продвижение по клику (PowerPoint).

1. Из меню Slide Show выберите Slide Transition.

2. Настройка Advance Slide on Mouse Click по умолчанию активна (рис. 7.4). Отключите ее и примените ко всем слайдам.

Прототипирование. Практическое руководство

РИС. 7.4. Отключите продвижение по клику мыши в PowerPoint

Стоит упомянуть о ссылках. PowerPoint не поддерживает ссылки на 100% прозрачных объектах. Почему это важно? Потому что PowerPoint часто используется для создания интерактивности в сериях импортированных изображений, таких как проекты интерфейса или экраны.

Возьмем в качестве примера окно Slide Transition (рис. 7.4). В нем возможен ряд активных действий: Cancel, Apply to All и Apply. Вместо создания новых кнопок для каждого из них я, вероятно, нарисую фигуры вокруг каждой из трех кнопок, сделаю их прозрачными и добавлю к ним действие или ссылку для перехода на другой экран.

Если фигура прозрачна на 100%, PowerPoint не позволит добавить к ней ссылку. Чтобы обойти этот запрет, задайте непрозрачность равной 1%.

Совет.

Один процент.

Если вы используете PowerPoint, убедитесь, что объекты кнопок имеют непрозрачность не ниже 1%. Иначе вы не сможете добавить к ним ссылки.

Шаг 3: добавьте к кнопкам действия и ссылки (PowerPoint).

1. Чтобы добавить действие, выберите кнопку и кликните правой кнопкой мыши. Затем выберите из меню Action Settings (рис. 7.5).

Прототипирование. Практическое руководство

РИС. 7.5. Кликните правой кнопкой, чтобы вставить ссылку в PowerPoint

Прототипирование. Практическое руководство

РИС. 7.6. Добавьте действие при клике мышью или наведении курсора на объект в PowerPoint

2. Выберите Hyperlink to и укажите слайд или адрес (рис. 7.6).

Совет.

Давайте слайдам названия.

Давайте слайдам осмысленные названия. Гораздо проще сослаться на нужный слайд, если он будет называться «Подробности о продукте», а не «Слайд 41».

Шаг 4: добавьте к кнопкам действия и ссылки (Keynote).

1. Выберите Hyperlink Panel в Inspector.

2. Установите переключатель Enable as Hyperlink и выберите Slide или URL (рис. 7.7).

После назначения ссылки на кнопке появится визуальная подсказка: стрелка в синем кружке (рис. 7.8).

Вот и все. Теперь у вас есть интерактивный прототип. Видите, как это просто?

Прототипирование. Практическое руководство

РИС. 7.7. Добавление интерактивности к слайду Keynote

Прототипирование. Практическое руководство

РИС. 7.8. Пример кнопки с интерактивной функцией или подключенной ссылкой

Эффекты AJAX в PowerPoint.

Встроенные в PowerPoint возможности перехода облегчают симуляцию стандартных эффектов AJAX. В качестве примера рассмотрим метод потускнения в JavaScript. Он используется, чтобы подсветить объект на экране на несколько секунд. По истечении этого времени подсветка пропадает.

Вот, пожалуй, простейший способ симуляции такого эффекта в PowerPoint.

1. Создайте две ключевые точки, одна из которых подсвечена (рис. 7.9), а другая нет (рис. 7.10).

2. Начните со слайда с подсветкой. Выберите Transition, затем Dissolve и задайте начало перехода по клику. Установите задержку равной 1 секунде.

Прототипирование. Практическое руководство

РИС. 7.9. Ключевая точка с подсветкой для метода потускнения в JavaScript

Прототипирование. Практическое руководство

РИС. 7.10. Ключевая точка без подсветки для метода потускнения в JavaScript

Ключевая точка с подсветкой будет терять яркость, открывая экран без подсветки и симулируя тем самым метод потускнения в JavaScript.

Можно также применять в PowerPoint такие действия с объектами, как Move, Opacity или Scale. Раньше я использовал их для симуляции других эффектов AJAX, например скрытия-показа.

Так что, даже если вы не умеете программировать переходы в AJAX, их можно симулировать в PowerPoint.

Резюме.

Итак, вот причины, по которым имеет смысл воспользоваться PowerPoint или Keynote для прототипирования:

• вероятно, программа у вас уже есть;

• кривая обучения низка;

• образцы слайдов обеспечивают высокие единообразие и эффективность;

• можно экспортировать результат в интерактивный прототип PDF или HTML.

Visio.

Прототипирование. Практическое руководство

Глава 8. Visio.

Прототипирование. Практическое руководство

РИС. 8.1. Обновление страницы загрузки Flickr с помощью Visio 2007 Professional

Если вы работали в Windows, то, вероятно, использовали Visio. И хотя изначально программа была создана для построения диаграмм, она может быть очень полезным инструментом прототипирования.

Кривая обучения Visio довольно низкая. Если вы умеете перетаскивать объекты с одного участка страницы на другой, вы можете создать интерфейсы веб– или настольных приложений в Visio. В программе заложен набор стандартных фигур, трафаретов[20] и шаблонов, что позволяет создавать интерфейсы легче и быстрее. Если встроенных возможностей недостаточно, можно скачать из интернета дополнительные элементы, созданные сторонними компаниями, и инструменты для прототипирования.

В этой главе рассказано о прототипировании с использованием встроенных возможностей Visio, а также популярных трафаретах и библиотеках инструментов, созданных другими компаниями. Список дополнений со ссылками на них приведен в конце главы.

Сильные стороны.

Visio – не первый инструмент для прототипирования, который сразу приходит на ум, но его стоит не упускать из виду по ряду причин.

• Кривая обучения. В Visio для создания рисунков используется модель перетаскивания объектов, поэтому кривая обучения сравнительно низкая.

• Осведомленность и распространенность. Visio – стандартный инструмент для профессионалов в области бизнеса и технологий, работающих в среде Windows. Если на вашем компьютере установлена Windows и вы сотрудник компании, скорее всего, у вас есть и Visio.

• Фоновые изображения. Visio поддерживает использование фоновых изображений для размещения общих элементов на группе экранов.

• Изобилие трафаретов, фигур и шаблонов. В Visio предусмотрен большой набор трафаретов, фигур и шаблонов для создания всего необходимого – от сетевых диаграмм до интерфейса приложений Windows. Если встроенных трафаретов и шаблонов недостаточно, есть ряд решений, созданных Биллом Скоттом, Джекко Ньюлендом, Ником Финком, Гэрретом Даймоном и др. Их список приведен в конце главы.

• Экспорт в HTML или PDF. Если у целевой аудитории Visio не установлен, всегда можно экспортировать файл в HTML или PDF.

• Программируемость. Если вы уверенно пользуетесь языком Visual Basic, то можете симулировать в Visio ряд уровней многофункционального взаимодействия.

Слабые стороны.

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

• Только Windows. Версии Visio для Mac не существует. Если у вас такой компьютер, то, пожалуй, вам этот вариант не подходит. Можно запустить Windows на виртуальной машине и использовать Visio, но зачем? Есть другие хорошие варианты.

• Ограниченная интерактивность. Интерактивность ограничена в основном ссылками. Они могут использоваться только для перехода на другие экраны в пределах прототипа или сайты в интернете.

• Ограничения многофункционального взаимодействия. В Visio с помощью Visual Basic возможно симулировать некоторые уровни интерактивности, для большинства пользователей это неудобно (и они не умеют пользоваться этой функцией).

• Ссылки на фоновых изображениях повреждаются при экспорте. Ссылки, помещенные на фоновые изображения, не поддерживаются при экспорте в форматы HTML или PDF. Если вы хотите, чтобы навигация работала после экспорта, необходимо разместить на каждом экране невидимые элементы и связывать ссылками их; но это противоречит самой идее фоновых изображений. Это существенная помеха.

• Неудобные меню и интерфейс. Visio иногда неудобен для создания переходов между элементами. Некоторые ключевые операции, например добавление ссылки к объекту, недоступны при правом клике мышью, их надо выполнять из основного меню. Если необходимо получить доступ к меню Shapes, нужно выбрать команду File из основного меню – хотя удобнее было бы использовать меню View или Tools. Навигация по документу в 20 и более страниц неудобна. Попробуйте использовать вкладки как образы страниц. Чувствуете, что здесь что-то не так?

• Код нельзя использовать повторно. Когда Visio выполняет экспорт в HTML, формируется изображение всей страницы и создается карта ссылок поверх картинки. Итоговые страницы оказываются скорее просто скриншотами.

Прототипирование в Visio.

В Visio предусмотрен ряд полезных шаблонов для создания чего угодно – от диаграмм процессов и документов UML до пользовательского интерфейса Windows XP. В этой главе в качестве примера мы воссоздадим приложение Flickr Uploadr, предназначенное для загрузки фотографий на популярный сайт Flickr компании Yahoo!. Образец файла Visio, использованный в этой главе, можно скачать по ссылке: rosenfeldmedia.com/books/downloads/prototyping/Visio_Demo.vsd.

Шаг 1: создание нового файла.

1. Выберите File > New из меню приложения. Меню New File, показанное на рис. 8.2, отражает ряд полезных возможностей Visio.

2. Если выбрать New Drawing, будет создан новый пустой рисунок с доступом к фигурам и шаблонам, используемым по умолчанию. Выберите New Drawing from Template, чтобы использовать один из собственных шаблонов. Или примените один из полезных шаблонов из комплекта Visio, показанных в виде списка папок в меню.

3. При выборе одного из шаблонов автоматически загрузятся соответствующие фигуры и трафареты.

В данном случае выберем Windows XP User Interface из папки Software and Database, как показано на рис. 8.3.

Выбрав шаблон Windows XP User Interface, мы автоматически получим доступ к ряду фигур и трафаретов Windows UI. По умолчанию они будут показаны на панели Shapes (см. рис. 8.4).

Прототипирование. Практическое руководство

РИС. 8.2. Меню New File программы Visio

Прототипирование. Практическое руководство

РИС. 8.3. Пункт Windows XP User Interface в меню New Drawing

Прототипирование. Практическое руководство

РИС. 8.4. Панель Shapes в Visio показывает фигуры, используемые в Windows и ее диалоговых окнах

Шаг 2: создание нового окна приложения.

1. Перетащите фигуру пустого окна с панели Windows and Dialogs на рабочее пространство.

2. Добавьте обычные элементы оформления и управления, например строку состояния, строку меню, кнопки Minimize, Maximize и Close. Результат должен выглядеть примерно так, как показано на рис. 8.5.

Прототипирование. Практическое руководство

РИС. 8.5. Рисование в Visio обычного окна приложения

На этой стадии есть два эффективных варианта дальнейшей работы. Можно создать фоновые рисунки страницы или трафарет для разработки окна приложения.

• Фоновые рисунки страницы. Их можно применять к новым страницам; они полезны для создания глобальных элементов, таких как окно контейнера или меню навигации. Фоновый рисунок нельзя модифицировать на самой странице. Необходимо изменять его на исходной странице.

• Трафареты. Их можно использовать для определения элементов, которые вы хотите неоднократно использовать в документе. Трафареты можно изменять на странице, на которую они помещены. Однако это не повлияет на исходный трафарет.

Для демонстрации мы сначала создадим трафарет, а затем применим его к фоновому рисунку страницы. Это даст нам возможность создать из единственного трафарета ряд фоновых рисунков с альтернативными состояниями.

Совет.

Что выбрать – трафарет или фоновые рисунки?

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

Шаг 3: создание трафарета.

1. Сгруппируйте рисунок. Выделите все его элементы и кликните на них правой кнопкой. Выберите из меню Shape > Group (рис. 8.6).

2. Когда фигура сгруппирована, вы можете сохранить ее как трафарет, выбрав из основного меню приложения команды File > Shapes > New Stencil (рис. 8.7). Созданный трафарет появится в меню Shapes в левой части окна приложения.

3. Перетащите фигуру в новый трафарет. После этого вы сможете переместить ее из трафарета, когда это понадобится.

4. Перетащите в трафарет все другие фигуры, которые вы хотите использовать повторно.

Прототипирование. Практическое руководство

РИС. 8.6. Пункт меню Group Shape в Visio

Прототипирование. Практическое руководство

РИС. 8.7. Пункт меню New Stencil в Visio

Шаг 4: создание фонового рисунка страницы.

1. Выберите одну из вкладок текущей страницы и кликните на ней правой кнопкой. Выберите из меню команду Insert Page.

2. Автоматически откроется вкладка Page Properties. На ней нужно выбрать вариант Type и установить переключатель Background (рис. 8.8).

3. Дайте странице осмысленное имя. Это полезно при применении фонового рисунка к другим страницам или указании страницы для перехода при создании интерактивности. Предлагаю назвать ее Main Application Window («главное окно приложения»).

4. Примените трафарет окна приложения к странице, перетащив его из меню Stencil на рабочую поверхность рисунка.

Прототипирование. Практическое руководство

РИС. 8.8. Установите на вкладке Page Properties переключатель Background

Шаг 5: применение фонового рисунка страницы.

1. Выберите одну из вкладок текущей страницы и кликните на ней правой кнопкой. В меню выберите Insert Page.

2. Будет автоматически выбрана вкладка Page Properties. На этот раз в качестве типа страницы выберите Foreground.

3. Дайте странице осмысленное имя. В данном случае это будет Browse for File («поиск файла»).

4. Установите переключатель на пункт выше Background и выберите из списка Main Application Window (рис. 8.9). Фоновый рисунок главной страницы приложения будет применен к новой странице.

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

Теперь, когда определены ключевые точки, стоит добавить интерактивность.

Прототипирование. Практическое руководство

РИС. 8.9. Примените фоновый рисунок к новой странице в Visio

Шаг 6: обеспечение интерактивности.

1. Выберите объект, который хотите связать. В нашем примере это будет кнопка Add.

2. В главном меню приложения выберите команды Insert > Hyperlink.

3. В диалоговом окне выберите Address, чтобы дать ссылку на локальный файл или внешний адрес (рис. 8.10). Выберите Sub-address, чтобы указать связь со страницей, входящей в текущий рисунок. В нашем случае это будет Sub-address.

4. Выберите страницу, с которой вы хотите установить связь, из меню Page (рис. 8.11).

Можно показывать прототип. Чтобы сделать это в Visio, выберите в главном меню View > Full Screen. Можно также экспортировать файл Visio в форматы HTML или PDF для последующего просмотра.

Прототипирование. Практическое руководство

РИС. 8.10. Диалоговое окно гиперсвязи в Visio

Прототипирование. Практическое руководство

РИС. 8.11. Диалоговое окно Sub-address – гиперсвязь в Visio

Дополнительные ресурсы.

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

Swipr.

Swipr – интерактивный набор инструментов для Visio, разработанный Джакко Ньюландом. Дополнительную информацию можно найти на сайте Swipr: http://swipr.blogspot.com.

Набор инструментов Билла Скотта для прототипирования в Visio.

Билл Скотт, директор по разработке пользовательского интерфейса в компании Netflix, создал набор инструментов для каркасного прототипирования в Visio и выложил его в свободный доступ. Здесь есть ряд великолепных возможностей, в том числе:

• полная библиотека трафаретов веб-компонентов (включая стандартные компоненты, таблицы, меню, вкладки и деревья);

• быстрая и «умная» раскладка с привязкой с использованием предварительно запрограммированных коннекторов Visio;

• способ визуализации многофункциональных взаимодействий (анимация каркаса);

• «умные» компоненты со встроенными правилами поведения;

• инструмент генерации документов с требованиями из каркасных объектов;

• инструмент генерации кода из каркасных объектов;

• инструмент для автоматического аннотирования и создания выносок.

Созданный Биллом набор инструментов для прототипирования можно скачать бесплатно на сайте: looksgoodworkswell.blogspot.ru/2005/11/visio-wireframe-toolkit-for-download.html.

Набор прототипирования GUUUI для Visio.

Хенриком Олсеном создан еще один хороший набор инструментов для Visio, содержащий как традиционные шаблоны из линий, так и напоминающие нарисованные от руки эскизы. Хенрик также написал ряд статей об использовании Visio для прототипирования. Эти статьи и последнюю версию инструментов можно найти на его сайте: http://goo.gl/5ECAM.

Библиотека трафаретов Ника Финка.

Библиотека для обычных элементов интерфейса, таких как строка навигации, вкладки и ссылки. Ее можно бесплатно скачать с сайта: http://www.nickfinck.com/blog/entry/visio_stencils_for_information_architects/.

Шаблоны и трафареты Гаррета Даймона для Visio.

Гаррет предлагает ряд шаблонов и трафаретов для Visio. Нужно изменить состояние флажка или переключателя с включенного на выключенное? Гаррет предусмотрел это. Просто нажмите на переключатель правой кнопкой и укажите, должен ли он быть включен, выключен, разрешен или запрещен к использованию. Шаблоны можно скачать здесь: http://iainstitute.org/documents/tools/GarrettDimon_Wireframes_2003.vsd; http://iainstitute.org/documents/tools/GarrettDimon_IA_Stencil_2002.vss.

Статьи.

Создание интерактивных прототипов в формате PDF в Visio[21].

Кейтлин Гэннон написала статью об использовании Visio для создания интерактивных прототипов в формате PDF. Статья доступна на ее сайте: caitlingannon.com/2008/03/16/how-to-create-an-interactive-pdf-prototype-in-visio/.

Прототипирование и тестирование удобства использования с помощью Visio[22].

Это презентация, представленная Карен Бэчманн и Уитни Кесенбери на ежегодной конференции Общества по изучению технических средств связи (Society for Technical Communication, STC). Слайды доступны в формате PDF по адресу: http://www.wqusability.com/handouts/visio-prototyping.pdf.

Резюме.

Visio – удобный инструмент для прототипирования, и вот почему:

• если вы работаете за компьютером компании, скорее всего, эта программа у вас уже установлена;

• кривая обучения низкая;

• использование фоновых рисунков, трафаретов и шаблонов обеспечивает единообразие и эффективность;

• можно экспортировать интерактивные прототипы в форматы PDF и HTML;

• если главный в компании специалист по Visual Basic объявит забастовку, вы сможете использовать Visio для создания некоторых форм многофункционального взаимодействия.

Fireworks.

Прототипирование. Практическое руководство

Глава 9. Fireworks.

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

Я всегда испытывал чувство вины после разговора с такими людьми. В конце концов, если это действительно такой удивительный инструмент, почему я его не применяю? Вероятно, я что-то упустил.

Почему они так преданы Fireworks? Многие фанаты программы заявляют, что причина – в ее способности создавать векторные и растровые изображения с помощью одних и тех же инструментов. Это своего рода гибрид Illustrator и Photoshop, но создаваемые файлы меньше по объему. Кто-то упоминает оптимизацию изображений.

После выхода Fireworks CS4[23] появилась еще одна причина. Теперь эта программа уже может считаться хорошим инструментом прототипирования.

Сильные стороны.

В Fireworks есть много возможностей, благодаря которым она стала мощным инструментом для прототипирования.

• Интеграция помогает повысить продуктивность. Fireworks превосходно интегрируется с Illustrator, Photoshop, Dreamweaver, Flash и Device Central. Она поддерживает слои программ Illustrator и Photoshop при импорте файлов AI и PSD. Файлы прототипов легко могут быть экспортированы в форматы Flash и Photoshop. Device Central дает возможность тестировать прототипы Fireworks для мобильных устройств.

• Небольшой размер файла. По умолчанию файлы Fireworks имеют разрешение 72 пикселя на дюйм, поэтому их объем относительно невелик.

• Состояния страниц. Теперь страницы могут иметь разные состояния. Панель States дает возможность настраивать внешний вид каждой страницы в приложении (например, для зарегистрированных и незарегистрированных пользователей). Однако при экспорте в формат PNG отображается только активное состояние.

• Асинхронное сохранение файлов. Можно сохранять один файл и в то же время работать над другим. Сохранение не блокирует работу всего приложения. Это новая возможность в CS4.

• Векторная и растровая графика «под одной крышей». Возможность создавать векторную и растровую графику в одной программе означает, что вам не придется одновременно использовать Illustrator и Photoshop. Fireworks также дает возможность применять одни и те же стили к векторным и растровым изображениям.

• Экспорт в форматы HTML, PDF и др. Fireworks поддерживает ряд форматов для экспорта, включая HTML, PDF, Flash, Flex и AIR.

• Достаточная гибкость для проектов и с низкой, и с высокой точностью. С помощью Fireworks можно создать как примерный проект, так и хорошо проработанный, который можно показать заказчику.

• Полезные стили и символы. В Fireworks есть ряд встроенных стилей и символов для типовых элементов графического интерфейса. Сообщество разработчиков постоянно пополняет коллекцию дополнений.

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

• Режим предварительного просмотра. Дает возможность протестировать прототип, не экспортируя его.

Слабые стороны.

В настоящее время Fireworks, вероятно, один из лучших инструментов для прототипирования. Но кое-что нуждается в усовершенствовании.

• Неудобный рабочий процесс для знатоков Photoshop и Illustrator. Версия CS4 больше похожа на программы компании Adobe. Однако если вы знаток Photoshop или Illustrator, то поначалу вам будет сложно, поскольку процесс работы в Fireworks существенно отличается от такового в упомянутых программах.

• Полосатость градиентов. Градиентные заливки Fireworks не настолько плавные, как созданные в Photoshop, что дает эффект полосатости.

• Недостаточная трассируемость и документированность. Если вам нужно создавать документацию, то потребуется дополнительный инструмент для фиксации требований и изменений, вносимых в прототип.

• Снижение производительности в случае больших, 50–70-страничных прототипов. Adobe проделала громадную работу по повышению эффективности, однако проблемы с производительностью неизбежны, когда размер прототипа больше 50–70 страниц. Единственный известный способ решения этой проблемы – деление прототипов большого размера на несколько файлов.

• Ограничение в одну главную страницу на документ. Главные страницы выступают в качестве шаблонов. Такое ограничение вынуждает использовать один и тот же шаблон на всех страницах прототипа, а не задавать главные страницы для каждого раздела (например, одну для выбора товаров и другую – для работы с корзиной).

Прототипирование приложений для iPhone в Fireworks.

В Fireworks CS4 есть ряд полезных символов графического интерфейса для создания приложений для Mac, Windows и веб-приложений. Поэтому прототипировать с помощью Fireworks легко и не требует больших затрат времени.

Однако мы не будем использовать символы, входящие в комплект поставки. Мы воссоздадим Twitterific – популярное приложение Twitter для iPhone. Вам не нужно разрабатывать весь трафарет с нуля. Его можно скачать по ссылке: rosenfeldmedia.com/books/downloads/prototyping/iPhone_Stencil_GUI.png. Можно также загрузить готовый файл прототипа: rosenfeldmedia.com/books/downloads/prototyping/iPhone_Prototype.png.

Шаг 1: создание нового файла.

1. Создайте новый файл. Выберите File > New в меню приложения (рис. 9.2) или Create New Fireworks Document на панели запуска (рис. 9.3).

2. Задайте размер рабочего поля 320 пикселей в ширину и 480 в высоту. Это размер экрана по умолчанию для приложений iPhone. Принятое по умолчанию разрешение 72 пикселя на дюйм вполне подходит для нашего случая.

3. Выберите фоновый цвет рабочего поля. По умолчанию это белый; нас это также устроит.

Прототипирование. Практическое руководство

РИС. 9.2. Окно New File в программе Fireworks CS4

Прототипирование. Практическое руководство

РИС. 9.3. Выберите Create New Fireworks Document на панели запуска Fireworks CS4

Шаг 2: создание главной страницы.

На главной странице должны быть только те элементы, которые появятся на всех экранах. Нам нужна главная страница с главной панелью инструментов.

1. Добавим главную страницу (рис. 9.4).

2. На панели Pages (рис. 9.5) дважды нажмите на имя страницы и назовите ее Master.

3. Кликните правой кнопкой на странице Master и выберите из контекстного меню команду Set As Master Page (рис. 9.6).

Прототипирование. Практическое руководство

РИС. 9.4. Главная панель инструментов iPhone

Прототипирование. Практическое руководство

РИС. 9.5. Панель страниц со страницей Master

Прототипирование. Практическое руководство

РИС. 9.6. Команда Set As Master Page

Шаг 3: создание ключевых экранов.

1. Кликните правой кнопкой на странице Master и выберите New Page. Можно также выбрать команду New Page в меню Pages (см. рис. 9.7).

2. Дважды нажмите на заголовок страницы в панели Pages и введите Home.

3. Скопируйте домашний экран из трафарета iPhone и поместите его на созданную страницу.

4. Добавьте к экрану значок Twitterific (рис. 9.8).

5. Повторите шаги 1–2, чтобы создать дополнительные экраны (рис. 9.9).

6. Добавьте на эти экраны необходимые элементы.

Прототипирование. Практическое руководство

РИС. 9.7. Команда New Page из меню Pages

Прототипирование. Практическое руководство

РИС. 9.8. Значок Twitterific, добавленный на домашний экран

Прототипирование. Практическое руководство

РИС. 9.9. Панель Pages с ключевыми экранами

Совет.

Осмысленные названия.

Давайте страницам осмысленные имена (например, Home («домашняя»), View Message («просмотр сообщения»), Reply to Message («ответ на сообщение»)). При создании интерактивности будет легче понять, к чему относится страница, если она названа Reply to Message, а не Untitled 3 («без названия 3»).

Шаг 4: добавляем к значку приложения перебор и интерактивность.

1. На панели Pages выберите домашнюю страницу.

2. Выберите панель States.

3. Дважды нажмите State 1 и введите текст MouseOut. Состояниям тоже лучше давать осмысленные имена.

4. Добавьте новое состояние, кликнув правой кнопкой на состоянии MouseOut и выбрав из меню (рис. 9.10) команду Duplicate State.

5. Дважды нажмите на новое состояние и введите текст MouseOver.

6. Выберите состояние MouseOver и нарисуйте вокруг значка Twitterific прямоугольник со скругленными углами. Заполните его белым цветом с прозрачностью 70%.

7. Еще раз выберите состояние MouseOut на панели States.

8. Выберите инструмент Slice из раздела Web палитры Tools (см. рис. 9.11). Нарисуйте прямоугольник над значком Twitterific. Должно получиться что-то подобное изображенному на рис. 9.12.

9. Выберите окошко на экране и кликните на нем правой кнопкой. Выберите команду Add Swap Image Behavior из меню (рис. 9.13).

10. В диалоговом окне в параметре State no: выберите MouseOver (2) и нажмите OK. Это создаст эффект, срабатывающий при наведении курсора на значок.

11. Еще раз выберите слой и нажмите на список Link на панели Properties. Из меню Options выберите TwitterStream.htm. Когда вы будете экспортировать прототип, появится ссылка от значка Twitter к списку сообщений на странице прототипа TwitterStream.

12. В режиме предварительного просмотра проверьте работу эффекта наведения курсора, выбрав кнопку Preview в левом верхнем углу окна документа. Проведите курсором по значку Twitter. Вы должны увидеть эффект прозрачности.

13. Нажмите в верхнем левом углу окна документа Original, чтобы вернуться в режим редактирования.

Прототипирование. Практическое руководство

РИС. 9.10. Команда Duplicate State на панели States

Прототипирование. Практическое руководство

РИС. 9.11. Инструменты Web на палитре Tools

Прототипирование. Практическое руководство

РИС. 9.12. Домашний экран со слоем над значком приложения Twitterific

Прототипирование. Практическое руководство

РИС. 9.13. Команда Add Swap Image Behavior в контекстном меню

Шаг 5: добавляем интерактивность на экран Twitter Stream.

1. На панели Pages выберите страницу Twitter Stream.

2. Выберите инструмент Rectangular Hotspot из раздела Web палитры Tools.

3. Нарисуйте прямоугольник вокруг облачка Chat на панели инструментов (рис. 9.14).

4. Выберите «горячую точку» и затем меню List из группы Link на панели Properties. Выберите из меню команду Create New Message.htm.

Прототипирование. Практическое руководство

РИС. 9.14. «Горячая точка» для облачка Chat

Шаг 6: добавляем интерактивность к экрану New Message.

1. На панели Pages выберите Create New Message.

2. Выберите инструмент Rectangular Hotspot из раздела Web палитры Tools.

3. Нарисуйте прямоугольники вокруг всех кнопок с буквами и кнопки Close на клавиатуре (рис. 9.15).

4. Выберите одну из «горячих точек» для буквы, затем меню List из раздела Link на панели Properties. Выберите в меню команду Type Message.htm. Повторите это действие для всех букв.

5. Выберите «горячую точку» кнопки Close, а затем меню List из раздела Link на панели Properties. Выберите в меню команду Twitter Stream.htm.

Прототипирование. Практическое руководство

РИС. 9.15. «Горячие точки» для букв на клавиатуре и кнопки Close

Шаг 7: добавляем интерактивность к экрану Type Message.

1. На панели Pages выберите Type Message.

2. Выберите инструмент Rectangular Hotspot из раздела Web палитры Tools.

3. Нарисуйте прямоугольники вокруг кнопок Close, Send и Backspace на клавиатуре (рис. 9.16).

4. Выберите «горячую точку» кнопки Close, а затем меню List из раздела Link на панели Properties. Выберите в меню команду Twitter Stream.htm. Повторите это действие для кнопки Send.

5. Выберите «горячую точку» кнопки Delete, а затем меню List из раздела Link на панели Properties. Выберите в меню команду Create New Message.htm.

Прототипирование. Практическое руководство

РИС. 9.16. «Горячие точки» для кнопок Close, Send и Backspace на клавиатуре

Шаг 8: экспорт и тестирование.

1. В меню File выберите Export.

2. Выберите папку, куда будет экспортирован прототип.

3. В параметрах экспорта выберите HTML and Images (рис. 9.17).

Прототипирование. Практическое руководство

РИС. 9.17. Диалоговое окно Export as HTML and Images

4. В разделе Slices выберите Export Slices. Иначе эффект при наведении курсора на значок Twitter работать не будет.

5. Снимите галочку в поле Current Page Only. Иначе будет экспортирована только текущая страница, а не весь прототип.

6. Выберите параметр Put Images in Subfolder. Папка прототипа частично «очистится»: в ней будут расположены только файлы HTML, а все рисунки окажутся в подпапке Image.

7. Нажмите кнопку экспорта.

8. Найдите папку, в которую вы экспортировали прототип, и откройте страницу с тем названием, которое вы дали первому экрану прототипа (например, Home.htm). Дважды нажмите ее, чтобы открыть в браузере и протестировать прототип.

9. Другой вариант экспорта – интерактивный файл PDF. Выполните шаги, описанные выше, но в качестве формата экспорта выберите PDF, а не HTML and Images. Возможно, вы измените формат сжатия рисунков на JPEG вместо используемого по умолчанию JPEG2000 (во всяком случае, мои рисунки в этот формат экспортировались с растеризацией).

Вот и все. Я только слегка затронул тему Fireworks как мощного инструмента прототипирования. Уверен, вам не терпится изучить эту программу и понять, как вы можете использовать ее в этом качестве.

Дополнительные ресурсы.

Ниже приведен список дополнительных ресурсов, в том числе трафаретов для iPhone, статей, презентаций и несколько видео.

Обучающие материалы Fireworks.

Обучающие материалы практически по всему спектру возможностей Fireworks, начиная от того, как с выгодой использовать главную страницу, до рекомендаций по улучшению рабочего процесса, можно найти на сайте: www.fireworkszone.com.

Создание интерактивного PDF-файла из многостраничного документа в Fireworks CS4[24].

В этой статье рассказано, как без малейших усилий выполнить экспорт в PDF из Fireworks, причем особое внимание уделено интерактивным файлам PDF: www.adobe.com/devnet/fireworks/articles/interactive_pdf.html.

Разработка интерактивных продуктов в Fireworks[25].

Статья компании Cooper interactive о том, как они используют Fireworks для создания интерактивных прототипов: www.adobe.com/devnet/fireworks/articles/cooper_interactive.html.

Тонкости и хитрости Fireworks – создание интерактивных прототипов[26].

Дэвид Хог, директор по информационному дизайну и удобству использования в компании Fluid, объясняет, как они используют Fireworks для создания интерактивных прототипов: http://tv.adobe.com/watch/fireworks-tips-and-tricks/creating-interactive-prototypes.

Изучаем Fireworks CS4 – создание интерактивных прототипов для просмотра[27].

Обзор возможностей экспорта в Fireworks CS4 с сайта lynda.com.

Видео посвящено экспорту в форматы HTML, PDF и даже Adobe AIR: http://tv.adobe.com/watch/learn-fireworks-cs4/creating-interactive-prototypes-for-reviews/.

Прототипирование приложений Adobe AIR в Fireworks CS4[28].

Презентация с кратким обзором прототипирования приложений AIR в Fireworks CS4: http://tv.adobe.com/watch/max-2008-design/prototyping-adobe-air-applications-with-fireworks-cs4/.

Прототипирование для мобильных устройств в Fireworks CS4[29].

Короткая статья, в общих чертах описывающая методы, которые используются для построения макета и создания активного дизайна в мобильных приложениях: http://www.adobe.com/devnet/fireworks/articles/design_mobile_devices.html.

Трафареты интерфейса iPhone.

Трафареты iPhone компании Teehan+Lax: www.teehanlax.com/blog/?p=447.

Шаблоны значков iPhone, разработанные Keep The Web Weird: www.keepthewebweird.com/iphone-icon-psd-template/.

Трафареты iPhone на сайте 320480: 320480.com/.

Резюме.

Почему же столько людей считают Fireworks отличным инструментом прототипирования? Вот несколько аргументов в пользу того, чтобы ее использовать в этом качестве:

• это своего рода гибрид Photoshop и Illustrator, причем объединяющий их главные достоинства;

• в ней используются главные страницы, общие слои и символы для обеспечения единообразия и эффективности;

• в ней есть встроенные наборы для создания графического интерфейса;

• можно экспортировать интерактивные прототипы в форматы PDF, HTML, Flash, Flex и AIR. Высокая гибкость, не правда ли?

• интеграция с другими программами из семейства CS позволяет эффективнее организовать работу.

Axure RP Pro.

Прототипирование. Практическое руководство

Глава 10. Axure RP Pro.

Прототипирование. Практическое руководство

РИС. 10.1. Видеосайт Acme, созданный в Axure RP 5.5

Если вы одновременно используете Visio, Word и Flashlite, то, вероятно, захотите попробовать Axure RP – объединенную среду для создания каркасных представлений, прототипов и спецификаций.

Я не утверждаю, что Axure сродни наркотику для разработчиков пользовательского интерфейса, но она определенно привлекает их внимание. В версии 5.5[30] создание интерактивных прототипов почти не требует усилий.

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

Сильные стороны.

Axure RP Pro имеет ряд достоинств, которые делают ее отличным инструментом для прототипирования.

• Каркасные представления, прототипы и спецификации. Axure дает возможность использовать один инструмент и для проектирования, и для документирования. Модуль построения диаграмм аналогичен используемым в Visio и OmniGraffle. Главное же достоинство Axure – возможность добавлять к проектам аннотации, автоматически генерировать документы со спецификациями и интерактивный прототип.

• Низкая кривая обучения. В Axure для создания рисунков используется модель перетаскивания объектов, как и в Visio и OmniGraffle. Разобраться в принципах создания базовой интерактивности просто.

• Осведомленность. Если вы использовали Visio или OmniGraffle, перейти на Axure будет несложно. Приложение похоже на Visio, но с лучшей моделью навигации по страницам, подобной используемой в OmniGraffle.

• Образцы и виджеты. Axure поставляется с рядом виджетов для создания стандартных каркасных представлений и типов документов. Если этого недостаточно, дополнительные библиотеки доступны на различных сайтах. Кроме того, вы можете создать собственную.

• Создание взаимодействий без программирования. В Axure для создания взаимодействий используется подобие обычных образцов. Не нужно знать JavaScript, чтобы имитировать взаимодействия в духе AJAX, например перекрытия, скрытие-показ или карусель фотографий.

• Простота публикации прототипов. Когда проект готов, для генерации прототипа в Axure нужно всего лишь выбрать команду Generate Prototype из меню приложения. Все остальное сделает программа.

• Совместная работа. Axure облегчает совместную работу над проектом. При этом несколько человек одновременно получают доступ к одному и тому же файлу проекта. Это возможно благодаря встроенной системе проверок, включающей систему контроля версий.

Слабые стороны.

Недостатков у Axure немного, но все-таки они есть.

• Только для Windows. Axure не работает на платформе Mac, поэтому если вы пользуетесь компьютером Apple, то эта программа, скорее всего, вам не подойдет. Можно запустить Windows в виртуальной среде, чтобы использовать Axure, но зачем? Есть ряд хороших альтернатив, например Fireworks, Flash и HTML26.

• Мало инструментов для рисования. В Axure не хватает базовых инструментов для рисования, как в Illustrator, OmniGraffle или Visio. В Axure есть фигуры, которые вы можете перетащить на свою страницу, но создать красивые округлые кнопки с эффектом градиентной заливки весьма непросто. Лучше нарисовать их в Photoshop или Fireworks, а затем импортировать в Axure.

• Исходный код нельзя использовать повторно. Axure умеет создавать настоящие страницы в HTML, а не просто скриншоты с картами изображений. Но никто в трезвом уме не станет использовать получившийся результат в реальной работе.

Создание прототипа видеосайта в Axure RP.

В Axure есть встроенные виджеты для создания проектов прототипов. Файл прототипа, использованный в этой главе, можно скачать по адресу: rosenfeldmedia.com/books/downloads/prototyping/chapter10.zip.

Шаг 1: создание нового файла.

1. Создайте новый файл. Выберите в меню приложения команды File > New. По умолчанию Axure создаст новый документ с несколькими страницами. Вы увидите их на панели Sitemap (рис. 10.2).

Прототипирование. Практическое руководство

РИС. 10.2. Панель Sitemap

Шаг 2: создание шапки страницы.

1. Выберите набор виджетов Wireframe на панели Widgets (рис. 10.3).

Прототипирование. Практическое руководство

РИС. 10.3. Панель Wireframe Widgets

2. Перетащите элемент Horizontal с панели виджетов на страницу. Дважды кликайте в центре каждого элемента, чтобы изменить текстовую метку.

3. Перетащите на страницу элементы Text Field и Button. Дважды кликайте в центре каждого элемента, чтобы изменить текстовую метку.

4. Результат должен выглядеть, как показано на рис. 10.4.

Прототипирование. Практическое руководство

РИС. 10.4. Пример шапки с элементами навигации и логотипом

Шаг 3: разработка содержимого домашней страницы.

1. Перетаскивайте с панели Widgets элементы Rectangles и Text Panels на страницу, пока не увидите что-то подобное тому, что показано на рис. 10.5.

Прототипирование. Практическое руководство

РИС. 10.5. Пример каркасного представления проекта домашней страницы

Шаг 4: разработка содержимого страницы Video Player.

1. Выберите элементы шапки, затем в меню приложения выберите команды Edit > Copy.

2. Нажмите страницу Video Player; в меню приложения выберите Edit > Paste.

3. Перетащите элемент Placeholder с панели Widgets на страницу. У вас должно получиться что-то похожее на то, что изображено на рис. 10.6.

Прототипирование. Практическое руководство

РИС. 10.6. Пример каркасного представления проекта страницы Video Player

Шаг 5: связывание страницы.

1. Нажмите домашнюю страницу и выберите большой заполнитель для видео. Вы увидите зеленую линию вокруг этого элемента.

2. Убедитесь, что панель Annotations & Interactions видима. Если она отсутствует, в меню приложения выберите View > Annotations & Interactions.

3. На панели Annotations & Interactions дважды нажмите пункт On Click, как показано на рис. 10.7.

Прототипирование. Практическое руководство

РИС. 10.7. Панель Annotations & Interactions

4. Появится диалоговое окно Interactions Case Properties (рис. 10.8). Введите осмысленное название на шаге 1: Description (например, Link to Video Page – ссылка на страницу с видео). На шаге 2: Selection Actions выберите вариант Open Link in Current Window. На шаге 3: Edit the Actions description выберите действие Link.

5. Появится диалоговое окно Link Properties с предложением выбрать страницу (рис. 10.9). Выберите в этом окне Video Player и нажмите OK.

Прототипирование. Практическое руководство

РИС. 10.8. Диалоговое окно Interaction Case Properties

Прототипирование. Практическое руководство

РИС. 10.9. Диалоговое окно Link Properties

Шаг 6: настройка эффектов перекрытия с помощью элементов динамических панелей.

1. Выберите вкладку страницы Video Player.

2. Перетащите два элемента динамических панелей с панели Widgets на страницу и измените их размер, чтобы они соответствовали размерам элементов управления видеоплеером (рис. 10.10).

Прототипирование. Практическое руководство

РИС. 10.10. Пример динамических панелей на экране

3. Дважды нажмите на правый элемент динамической панели. Откроется диалоговое окно Dynamic Panel State (рис. 10.11).

Прототипирование. Практическое руководство

РИС. 10.11. Окно Dynamic Panel State Manager

4. Введите осмысленное название в поле Dynamic Panel Label (например, Social Media Controls).

5. Выберите состояние первой панели, затем нажмите Rename. Введите в поле Name название On_hover и нажмите OK.

6. Введите название в поле Add new state, введите On_click и нажмите OK.

7. В диалоговом окне Dynamic Panel State Manager выберите первое состояние (On_hover) и дважды кликните на нем. Откроется одноименная вкладка. На экране также появится панель Dynamic Panel Manager с выделенным жирным шрифтом элементом On_hover (рис. 10.12).

Прототипирование. Практическое руководство

РИС. 10.12. Элемент On_hover панели Dynamic Panel State Manager

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

Прототипирование. Практическое руководство

РИС. 10.13. Динамическая панель Social Media Controls

9. На панели Dynamic Panel Manager выберите состояние On_click и дважды кликните на нем. Появится новая вкладка, помеченная On_click (Video Player).

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

Прототипирование. Практическое руководство

Рис. 10.14. Состояние On_click динамической панели Social Media Controls

11. В Dynamic Panel Manager выберите состояние On_click и дважды кликните на нем. Появится новая вкладка, помеченная как On_click.

12. Выберите прямоугольник Share.

13. На панели Annotations & Interactions дважды нажмите на вариант On_click. Появится диалоговое окно Interaction Case Properties. На шаге 1: Description field введите осмысленное название (например, Share (поделиться)). На шаге 2: Select Actions установите галочку в поле Set Panel state(s) to State(s). На шаге 3: Edit Actions description выберите связь Panel state to State. Появится диалоговое окно Set Panel state to State (рис. 10.15).

14. На шаге 1: Select Panels выберите флажок Set Social Media state to State. На шаге 2: Edit Actions description выберите связь On hover link. Появится диалоговое окно Select Panel State (рис. 10.16).

15. Выберите вариант On_click и нажмите OK. Диалоговое окно закроется, станет видимым окно Set Panel state to State (рис. 10.17).

16. В обновленном окне Set Panel state to State нажмите OK. Диалоговое окно закроется, станет видимым обновленное окно Interaction Case Properties (рис. 10.18).

17. В обновленном диалоговом окне Interaction Case Properties нажмите OK.

18. Теперь можно сгенерировать прототип, чтобы протестировать взаимодействие On_click. В строке меню выберите пункт Generate. В появившемся меню выберите пункт Prototype (F5), как показано на рис. 10.19.

Прототипирование. Практическое руководство

РИС. 10.15. Диалоговое окно Set Panel state to State

Прототипирование. Практическое руководство

РИС. 10.16. Диалоговое окно Select Panel State

Прототипирование. Практическое руководство

РИС. 10.17. Обновленное диалоговое окно Set Panel state to State

Прототипирование. Практическое руководство

РИС. 10.18. Диалоговое окно Interaction Case Properties

Прототипирование. Практическое руководство

РИС. 10.19. Генерация прототипа из меню приложения

Вы сможете наблюдать появление динамических панелей, которые отображаются при загрузке экрана Video Player. Мы исправим эту недоработку буквально за секунду. Но сначала нажмите находящийся справа элемент Share, чтобы убедиться, что взаимодействие On_click работает правильно.

Шаг 7: скрытие и показ динамических панелей.

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

1. Выберите вкладку страницы Video Player.

2. На панели Page Notes & Interactions выберите вариант OnPageLoad и дважды кликните на нем. Откроется диалоговое окно Interaction Case Properties.

3. На шаге 1 введите осмысленное название. На шаге 2 выберите Hide Panel(s). На шаге 3 выберите связь Panel.

4. В диалоговом окне Select Panels выберите оба варианта: Video Controls и Social Media controls.

5. Нажмите OK в диалоговом окне Interaction Case Properties.

6. Сгенерируйте прототип и убедитесь, что управляющие элементы скрыты.

Шаг 8: показ и скрытие управляющих элементов при наведении на них курсора.

Теперь, когда начальное и конечное состояние определены, мы создадим промежуточные состояния для показа управляющих элементов, когда курсор наводится на видеоплеер.

1. Выберите вкладку страницы Video Player.

2. Выберите на странице большой элемент-заполнитель объекта Video.

3. На панели Annotations & Interactions выберите вариант OnMouseEnter и дважды кликните на нем. Появится диалоговое окно Interaction Case Properties.

4. На шаге 1 введите осмысленное название (например, Show Video Controls). На шаге 2 выберите Show Panel(s). На шаге 3 выберите связь Panel.

5. В диалоговом окне Select Panels выберите оба варианта: Video Controls и Social Mediacontrols. Затем нажмите OK.

6. Нажмите OK в диалоговом окне Interaction Case Properties.

Вы только что настроили показ управляющих элементов при наведении курсора на элемент-заполнитель видеоплеера. Теперь нужно скрывать их, когда курсор сместится с заполнителя.

1. Выберите на странице большой элемент-заполнитель объекта Video.

2. На панели Annotations & Interactions выберите вариант OnMouseOut и дважды кликните на нем. Появится диалоговое окно Interaction Case Properties.

3. На шаге 1 введите осмысленное название (например, Hide Video Controls). На шаге 2 выберите Hide Panel(s). На шаге 3 выберите связь Panel.

4. В диалоговом окне Select Panels выберите оба варианта: Video Controls и Social Mediacontrols. Затем нажмите OK.

5. Нажмите OK в диалоговом окне Interaction Case Properties.

После этого панель Annotations & Interactions должна выглядеть, как показано на рис. 10.20.

6. Сгенерируйте прототип и опробуйте его.

Прототипирование. Практическое руководство

РИС. 10.20. Пример динамических панелей на экране

Как компания Ander Zorg поняла ценность интерактивного прототипирования.

Хэнк Вижнолз и Стефан Воббен из компании Concept7.

Компания Concept7 использовала интерактивные прототипы как ключевой инструмент коммуникации в процессе переработки сайта AnderZorg («Другое здравоохранение»); в результате существенно повысились и удовлетворенность клиентов, и продажи онлайн.

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

Варианты дополнительной страховки очень трудно сравнивать. Они меняются каждый год и различаются в разных компаниях. Например, исследование, проведенное сайтом Independer.nl 9 декабря 2008 года, показало, что 40% голландцев, застраховавших свое здоровье, не знают, какую именно программу они оплачивают и какие заболевания она покрывает.

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

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

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

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

Дьявол кроется в деталях – они и определяют пользовательский опыт. В данном случае крайне важным было качество содержимого сайта. Используя в интерактивном прототипе, который мы создали с помощью Axure RP Pro, реальное содержимое, мы могли видеть, как участники исследований реагируют на метки и информацию при посещении сайта. Эту область мы не могли бы эффективно протестировать без интерактивного прототипа.

Прототипирование. Практическое руководство

РИС. 10.21. Прототип матрицы страхования

Создав прототип, мы смогли продемонстрировать матричную версию представления результатов (рис. 10.21), дав пользователям возможность изучить информацию о разных вариантах страхования.

В ходе тестирования мы получали от пользователей комментарии вроде: «Теперь у меня больше информации, и я могу принять решение. Так гораздо лучше».

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

Благодаря прототипу мы смогли повысить удовлетворенность пользователей с 72 до 82%. Согласно независимым исследованиям рынков, этот результат – один из наивысших в Нидерландах, и не только в области медицины.

Переработка сайта AnderZorg также привела к увеличению доли посетителей, совершающих покупку, на 48,15% и удвоению числа подписок на медицинское страхование.

Дополнительные ресурсы.

На сайте Axure есть ряд видеоуроков и дополнительных библиотек. А некоторые сторонние ресурсы существенно упрощают расширенные взаимодействия в духе AJAX.

Видеоуроки Axure.

Несколько видеоуроков по Axure есть непосредственно на сайте программы: http://www.axure.com/learn.

Образцы файлов Axure.

Загрузите образцы проектов, чтобы улучшить свои навыки прототипирования, с сайта Axure: http://www.axure.com/sample-prototypes.

Библиотеки виджетов Axure.

Распространенные значки интерфейса и компоненты дизайна, основанные на наборе YUI Design Stencil Kit, доступны непосредственно на сайте Axure: http://www.axure.com/download-widget-libraries.

Библиотека Axure RP Master Library.

Благодаря Яну Фенну и Люку Перману вы можете воспользоваться библиотекой компонентов, которая упрощает создание в Axure взаимодействий в духе AJAX. Axure RP Master Library хранится на сайте Google Code: code.google.com/p/axlib/. Ее также можно найти в твиттере: @axlib.

Библиотека Лорен Бакстер: Axure Design Library.

Эта библиотека содержит ряд шаблонов дизайна для валидации полей AJAX, самовосстановления, карусели и др. Ее можно скачать с сайта: www.acleandesign.com/2008/09/axure-design-pattern-library-v2/.

Резюме.

Программа Axure RP Pro безусловно оставила свой след в прототипировании. Вот несколько доводов в пользу того, чтобы использовать ее в этих целях:

• программа похожа на Visio, но имеет гораздо больше возможностей для прототипирования;

• можно использовать один инструмент для разработки каркасных представлений, спецификаций и прототипирования;

• в ней есть шаблоны и встроенные виджеты для создания распространенных элементов графического интерфейса;

• в ней очень просто сделать интерактивный прототип.

HTML.

Прототипирование. Практическое руководство

Глава 11. HTML.

Прототипирование. Практическое руководство

РИС. 11.1. Окно с исходным кодом HTML-прототипа

HTML-прототипы могут быть разными: от простейших связанных изображений до симуляции готовой программы.

Проще всего использовать HTML для связывания нескольких изображений в формате JPG и создания интерактивности на базе этих связей.

Рабочие HTML-прототипы основаны на HTML-коде, но не могут или не должны применяться для создания окончательной версии продукта. Примерами можно считать прототипы, сгенерированные в Axure RP Pro или с использованием редактора, например Dreamweaver в режиме WYSIWYG («что видишь, то и получаешь»).

Существуют и HTML-прототипы уровня конечного продукта – «святой грааль» прототипирования. Они хороши, если ручная HTML-верстка не вызывает у вас затруднений. Сейчас этот метод, пожалуй, наименее распространен, но именно его я предпочитаю.

CSS-фреймворки, в том числе Blueprint, 960 и YUI, в сочетании с популярными JavaScript-фреймворками, включая jQuery, Prototype и YUI (в ней есть библиотеки и для CSS, и для JavaScript), облегчили прототипирование на HTML.

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

Сильные стороны.

Вот главные достоинства прототипирования на HTML:

• Независимость от платформы. HTML-код можно писать в среде Mac, Windows и Linux.

• Бесплатность. Есть бесчисленное множество бесплатных редакторов HTML.

• Переносимость. Вы можете выложить HTML-прототип на сервер и дать доступ к нему людям со всего мира. Чтобы посмотреть прототип, им не потребуется ничего загружать.

• Реалистичность. HTML-прототип может быть максимально приближен к реальности – здесь все зависит от вас.

• Показатель реализуемости. Работа с реальным кодом позволит лучше понять, что можно сделать и каких усилий это потребует.

• Модульность, основанность на компонентах. HTML-прототипы могут включать файлы, использующие модульный, основанный на компонентах подход. Как следствие, продуктивность и связность повышаются.

• Множество открытых фреймворков. Растет количество открытых фреймворков, таких как jQuery, Prototype и Blueprint, существенно облегчающих задачу HTML-прототипирования.

• Совместная работа. HTML-прототип содержит более одного файла, и несколько членов команды могут работать над ним одновременно. Но если прототипом занимаются несколько человек, используйте средства контроля версий, например Git или Subversion: тогда вас не хватит удар, когда кто-то случайно запишет старую версию поверх рабочего файла.

• Повторно используемый код. Если код сделан правильно, можно сэкономить время и усилия, использовав его в рабочей версии продукта. Код, который мы создаем в Messagefirst, часто составляет 80–85% от общего объема интерфейсного кода, необходимого для реализации продукта.

• Безграничный потенциал. Программно можно сделать что угодно – все зависит от вас.

Слабые стороны.

Увы, ничто не совершенно. Есть у HTML несколько недостатков, которые мешают ему стать безупречным методом прототипирования.

• Время и усилия. Начинающий потратит на верстку HTML-прототипов много времени. Будьте готовы учиться. Когда ваши навыки разовьются, скорее всего, вы сможете создавать прототипы с помощью HTML не медленнее, чем другими методами, или даже быстрее.

• Комментирование. Комментирование созданных прототипов может оказаться сложной задачей. Чаще всего разработчик добавляет заметки в нижней части страниц или заключает их в теги <div>, что позволяет включать и выключать их отображение. W3C[31] работает над инструментом для включения аннотаций в RDF[32].

Прототипирование на HTML.

Я не создавал каркасных представлений с 2006 года и не думаю, что когда-либо еще буду этим заниматься! Мне нравится прототипировать с использованием HTML, CSS и JavaScript. И думаю, что причин тому две.

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

Да, проблема различий в браузерах может вызвать замешательство, особенно когда дело доходит до IE6 (это бич для любого разработчика). Однако…

Когда я вижу живой пример продукта, для которого я создавал прототип, я представляю себе сцену из фильма «Франкенштейн»[33], где доктор Генри Франкенштейн в исполнении Колина Клайва воздевает руки к небу и кричит: «Оно живое!» Да, я испытываю похожие чувства.

Во-вторых, реакция клиентов, увидевших HTML-прототип, намного интереснее, чем при изучении других прототипов. Некоторые мои клиенты буквально подпрыгивали в кресле, когда видели на экране эффекты в духе AJAX.

Взаимодействия в духе AJAX.

Не так давно мы проектировали внутреннее приложение для одного из клиентов. Оно использовалось для создания новых проектов в их системе и уведомляло работников о том, что они будут участвовать в проекте.

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

Можно было показывать на экране не все допустимые варианты, а только необходимые поля. После выбора поля, от которого зависят другие поля, последние должны были друг за другом выводиться на экран.

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

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

Как только мы закончили настройку проекта, он поднял глаза и взглянул на сообщение об успешной настройке. Затем он увидел, как оно медленно закрывается и растворяется, – автомагически.

Он уронил телефон на стол и закричал: «Боже мой! Это лучше всего, что я когда-либо видел. Можно это повторить?» Конечно, я показал ему все еще раз.

Я никогда не отмечал такой реакции у клиентов, которым показывал каркасные представления. Но с тех пор как я начал делать HTML-прототипы, я все чаще вижу восхищение клиентов.

Создание HTML-прототипа.

В некоторых случаях я буду переносить часть кода на следующую строку из-за недостаточной ширины страницы. Символ «¿» означает перенос строки. В файлах примеров на сайте книги этот символ не используется.

Прежде чем читать дальше, вы, вероятно, захотите скачать файлы примеров с сайта: rosenfeldmedia.com/downloads/prototyping/chapter11.zip. Там есть два дополнительных файла CSS, используемых для форматирования текста и формирования элементов, а также изображений форм, которые не включены в инструкции ниже.

Если вы предпочитаете начинать с нуля и не использовать файлы примеров, то все равно сможете освоить HTML. Правда, результат будет выглядеть не так привлекательно.

Шаг 1: создание нового файла.

Создайте новый пустой HTML-документ и сохраните его под именем index.html. Я обычно начинаю прототипы в HTML со следующего текста.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN".

"http://www.w3.org/TR/html4/strict.dtd">

<html lang="en">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Untitled Document</title>

<!– Import CSS framework ->

<!– Import JavaScript framework ->

</head>

<body>

</body>

</html>

Вы, вероятно, заметили несколько блоков с комментариями. Это места для вставки CSS– и JavaScript-файлов, которые будут импортированы, чтобы прототип выглядел привлекательно, и добавления интерактивности в духе AJAX.

Шаг 2: добавление основной структуры.

Теперь, после создания простого HTML-документа, нужно разработать основную структуру, которая определяет содержание. Стандартные ее части – шапка, панель навигации, область основного содержимого, боковая панель и подвал. Начнем с создания контейнеров div для каждой из этих основных частей.

<div class="wrapper">

<div id="Header"></div>

<div id="Nav"></div>

<div id="Main">

<div id="Sidebar"></div>

</div>

<div id="Footer"></div>

</div>

Совет.

Обеспечьте возможность различения классов и идентификаторов.

При создании стилей CSS я использую названия классов, начинающиеся со строчной буквы (например, wrapper), а идентификаторы – с прописной (например, SlideShow).

Это облегчает быстрый просмотр программного кода и помогает отличить классы от идентификаторов.

Я обрамляю структурные элементы тегами div. В этом случае элементы помещаются в удобные контейнеры 950 пикселей в ширину и отцентрированные на экране с помощью небольшого CSS-файла, который будет добавлен позже.

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

<div class="wrapper">

<div id="Header">

<div id="Logo">

<h1>ACME</h1>

</div>

</div>

<div id="Nav">

<ul>

<li class="current"><a href="#">Home</a></li>

<li><a href="#">About</a></li>

<li><a href="#">Blog</a></li>

<li><a href="#">Contact</a></li>

</ul>

</div>

<div id="Main" class="clearfix">

<div id="Article">

<div class="container">

<h2>Content</h2>

</div>

</div>

<div id="Sidebar">

<div class="container">

<h2>Sidebar</h2>

</div>

</div>

</div>

<div id="Footer">

<div class="container">

<h2>Footer</h2>

</div>

</div>

</div>

Если в этот момент открыть страницу в браузере, она будет выглядеть примерно так, как показано на рис. 11.2.

Прототипирование. Практическое руководство

РИС. 11.2. Основа HTML-прототипа без стилей

Шаг 3: стили базовых элементов структуры.

Теперь, когда основная структура определена, можно добавить к элементам стили. Обычная проблема при веб-проектировании заключается в том, что каждый браузер имеет свои настройки по умолчанию для отображения HTML-элементов. Наша первоочередная задача – исправить ситуацию. Мы хотим обеспечить единую форму и использовать CSS для сброса стилей.

В сети есть немало CSS-файлов для сброса стилей. Два наиболее часто используемых созданы Эриком Мейером (meyerweb.com/eric/tools/css/reset/) и компанией Yahoo! (developer.yahoo.com/yui/reset/).

1. Создайте новый файл с нижеприведенным текстом и сохраните под именем reset.css:

html, body, div, span, object, iframe, h1, h2, h3, h4, h5, h6, ¿

p, blockquote, pre, a, abbr, acronym, address, code, del, dfn, ¿

em, img, q, dl, dt, dd, ol, ul, li,

fieldset, form, label, legend, table, caption, tbody, ¿

tfoot, thead, tr, th, td {margin:0; padding:0; border:0; ¿

font-weight: inherit; font-style: inherit; font-size:100%; ¿

font-family: inherit; vertical-align: baseline;}.

body {line-height:1.618;}.

table {border-collapse: separate; border-spacing:0;}.

caption, th, td {text-align: left; font-weight: normal;}.

table, td, th {vertical-align: middle;}.

blockquote: before, blockquote: after, q: before, ¿

q: after {content: "";}.

blockquote, q {quotes: "" "";}.

aimg {border: none;}.

Совет.

Использование модульной среды в HTML-прототипах.

Я создал единственный файл CSS с названием style.css и использую метод @import, чтобы включить в него файлы reset.css, typography.css, base.css и custom.css. Файл reset.css задает одинаковые настройки для всех браузеров. Файл typography.css задает стили для текста. Файл base.css задает основную структуру (например, шапку, логотип, элементы навигации, тело страницы, боковую панель, подвал) для среды прототипирования. Наконец, файл custom.css я использую для настройки внешнего вида прототипа. Благодаря такому подходу мне приходится вводить только 30–100 строк кода CSS в файле custom.css для настройки вида прототипа и устранения проблем с разными браузерами.

Мы не будем рассматривать файл typography.css, который я обычно использую в своей рабочей среде прототипирования. Его можно скачать по ссылке: rosenfeldmedia.com/downloads/prototyping/chapter11.zip.

Теперь, когда все браузеры настроены, создадим файл CSS, чтобы указать стили основных элементов на экране.

2. Создайте новый файл с приведенным ниже текстом и сохраните под именем base.css.

body {margin:2px 0; background:#111;} /* Оставляет немного ¿

свободного пространства вокруг тела страницы (сверху и снизу).*/

.wrapper {width:950px; margin:0 auto; background:#eee;} ¿

/* Группирует все элементы и располагает по центру экрана. */

/* Устанавливает базовую раскладку элементов.

– */

#Header, #Logo, #Search, #Nav, #Main, #Article, ¿

#Section, #Sidebar, #Footer {margin:0; padding:0;}.

/* Элементы шапки.

– */

#Header {height:48px;}.

#Logo {width:230px; padding:5px 10px;}.

#Nav {height:30px; width:950px; border-bottom:1px solid #ddd;}.

/* Основные элементы навигации.

– */

#Nav ul {margin:10px 0 -9px 10px;}.

#Nav li {height:24px; padding:5px 10px; ¿

list-style-type: none; display: inline; color:#4a69a5;}.

#Nav li a: link, #Nav li a: visited {color:#0089dc; ¿

text-decoration: none;}.

#Nav li a: hover {color:#222;}.

#Nav li.current,#Navli.current a: link ¿

{font-weight: bold; color:#222;}.

#Navli.current a: link {border-bottom:2px solid #222}.

/* Основные элементы.

– */

#Main {width:950px; border-bottom:1px solid #ddd; ¿

border-top:1px solid #fff;}.

#Article {float: left; margin:0 10px 0 ¿

0;width:670px; min-height:540px; background:#fff;}.

/* Элементы боковой панели.

– */

#Sidebar {float: right; width:270px;}.

#Sidebar.container {margin:0 10px 10px 0;}.

/* Элементы подвала.

– */

#Footer {height:120px; width:950px; color:#eee; ¿

border-top:1px solid #fff; }.

/* Таблицы.

– */

th {background:#fff;}.

tr td {border-bottom:1px solid #ddd;}.

tr.even td {background:#e5ecf9;}.

tr.new-comment td {background:#ffffdd;}.

/* Разные элементы.

– */

.container {padding:1.5em;margin-bottom:1.5em;} /* Используется для создания контейнера с отступами внутри колонки. */

hr{background:#ddd; color:#ddd; clear: both; ¿

float: none; width:100%; height:1px;margin: 1em 0 ¿

1.45em 0; border: none;} /* Используется для создания ¿

горизонтальной линейки в колонке. */

/* Сброс плавающих элементов без дополнительной разметки на о??????????? снове метода ¿

[http://www.positioniseverything.net/easyclearing.html] */

.clearfix: after, container: after {content: " "; ¿

display: block; height:0; clear: both; visibility: hidden;}.

.clearfix, container {display: inline-block;}.

* html.clearfix, * html.container {height:1%;}.

.clearfix, container {display: block;}.

3. Создайте новый файл со следующим текстом и сохраните под именем style.css:

@import 'reset.css';

@import 'base.css';

4. Введите следующие строки сразу под комментарием <!– ImportCSSframework ->, чтобы подключить CSS-файлы:

<link rel="stylesheet" href="lib/css/style.css" ¿

type="text/css" media="screen, projection" />

Откройте в браузере страницу index.html (рис. 11.3).

Прототипирование. Практическое руководство

РИС. 11.3. Структура HTML-прототипа с основными стилями

Шаг 4: добавление содержимого.

Базовая структура создана, пора перейти к содержимому. Мы добавим в запись блога «рыбу» и несколько комментариев. Ниже разместим форму для отправки комментария. Нажатие кнопки Post Message будет создавать на экране эффект в духе AJAX (отправка комментария).

1. Добавим шапку и несколько строк «рыбы» в раздел Article.

<div id="Article">

<div class="container">

<h2>Most Awesome Blog Post Ever</h2>

<p>Lorem ipsum dolor sit […].</p>

</div>

</div>

2. Под записью в блоге добавим блок с комментариями. Он будет включать комментарий, который мы вначале скроем, используя jQuery. Следующий код должен быть помещен сразу за последней строкой текста сообщения, но внутри контейнера, обрамленного тегами div.

<hr />

<h3>Comments</h3>

<table>

<tr>

<th width="25%"></th>

<th width="75%"></th>

</tr>

<tr class="new-comment">

<td><strong>Tom Sawyer</strong><br />

<span class="quiet">1 minute ago</span></td>

<td>Sit amet, consectetuer adipiscing[..].</td>

</tr>

<tr>

<td><strong>Betty Boop</strong><br />

<span class="quiet">4 minute ago</span></td>

<td>Lorem ipsum dolor sit amet, con[…].</td>

</tr>

<tr>

<td><strong>Barney Rubble</strong><br />

<span class="quiet">16 minute ago</span></td>

<td>Consectetuer adipiscing elit, […].</td>

</tr>

<tr>

<td><strong>Winnie Pooh</strong><br />

<span class="quiet">45 minutes ago</span></td>

<td>Sed diam nonummy nibh euismod […].</td>

</tr>

</table>

<h3>Say Something</h3>

<form>

<ul>

<li>

<label for="Name">Name</label>

<input id="Name" class="third" />

</li>

<li>

<label for="Email">Email</label>

<input id="Email" class="third" />

</li>

<li>

<label for="Comment">Comment</label>

<textarea id="Comment"></textarea>

</li>

<li>

<label></label>

<a href="#" id="PostMessage"><img.

src="images/post-message.gif" /></a></li>

</ul>

</form>

3. Затем подключим в шапке библиотеку jQuery сразу за тегом комментария Import JavaScript framework.

<!– Import JavaScript framework ->

<script src="lib/js/jquery-1.2.6.min.js"></script>

4. Наконец, осталось добавить маленький фокус jQuery в шапку HTML-страницы сразу после строки, подключающей файл jQuery.

<script>

// Если страница готова.

$(document). ready(function(){

$(".new-comment"). hide();

$("a#PostMessage"). click(function () {

$(".new-comment"). show();

});

});

</script>

Вот и все. Откройте обновленный прототип в браузере, как показано на рис. 11.4.

Нажмите кнопку Post Message, и новый комментарий появится в начале списка комментариев, а страница подсветится желтым (см. рис. 11.5).

Прототипирование. Практическое руководство

Рис. 11.4. Окончательный HTML-прототип с записью в блоге и комментариями

Прототипирование. Практическое руководство

РИС. 11.5. HTML-прототип с подсвеченным новым сообщением в блоге

Я называю эти переходы в духе AJAX «постепенным раскрытием». Это отличный метод, если элементы экрана взаимосвязаны или их показ ограничен определенными условиями (выбор элемента на экране приводит к изменению содержимого в другой части экрана).

В 2008 году я использовал этот метод прототипирования при усовершенствовании онлайновой формы для университета. Приложение занимало 13 полных экранов, на заполнение требовалось не меньше 20 минут. Ниже я расскажу, как использовал метод постепенного раскрытия для доработки приложения и размещения его на двух экранах. В итоге на заполнение формы стало уходить в среднем 2,5 минуты.

Практический пример: как прототипирование снизило потери времени на 85%

Тодд Заки Варфел.

В 2008 году моя компания Messagefirst участвовала в доработке сайта университета и онлайнового заполнения формы. Мы специализируемся на увеличении эффекта от посещений и повышении удобства использования систем, основанных на транзакциях.

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

Когда мы изменяем систему, то всегда проводим основные тесты на удобство использования. Изучение результатов дает нам возможность не только обнаружить серьезные проблемы, но и провести ключевые измерения для ROI. Единственный способ достоверно измерить успех или провал – сравнение с предыдущим вариантом.

В ходе основных тестов мы обнаружили, что участникам неудобно работать с 13-страничной формой. Мысли о 13 страницах пугали и лишали уверенности в себе. Несколько участников с тревогой отметили, что если документ заполнен частично, то в случае сбоя или падения браузера вся введенная информация теряется. Это очень неприятно.

Мы также заметили, что многим приходится проматывать длинные экраны с бесконечными списками полей формы, многие из которых для студентов были неактуальны. 13 страниц, прокрутки, «танцы» с полями и ошибки из-за внесения данных в не связанные друг с другом поля приводили к тому, что в среднем на заполнение формы у участников уходило около 25 минут.

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

Мы надеялись, что новый дизайн решит следующие проблемы:

• Снизит страх. Вместо экрана с 20–30 полями и индикатором, что это первый экран процесса, состоящего из 13 стадий, мы вывели 5 полей с контактной информацией и индикатор, показывающий, что участники находятся в начале процесса из двух шагов.

• Предотвращение ошибок. Удалите с экрана все несвязанные поля. Начните с необходимого (рис. 11.6). Исключите возможность ошибки.

• Создайте более четкий интерфейс. Когда выбор сделан, выведите на экран удобочитаемый текст, а не множество полей и для показа следующих вопросов используйте метод постепенного появления (рис. 11.7–11.8).

• Обеспечьте восстановление после ошибок. Если участники случайно выберут неправильный вариант или изменят свое мнение, дайте им возможность отредактировать выбор. Клик по фрагменту текста должен обеспечить перемещение пользователя в редактируемое поле.

• Повысьте эффективность и удовлетворенность. Мы хотели, чтобы студенты заполняли формы быстрее, делали меньше ошибок и были больше удовлетворены процессом.

Как мы это делали? Мы сохранили ту же информацию, но использовали переходы в духе AJAX, чтобы свести 13 страниц к двум экранам – 85%-ное улучшение. В среднем время заполнения уменьшилось с 25 минут до менее чем 2,5 минуты – 1000%-ное улучшение.

Прототипирование. Практическое руководство

РИС. 11.6. Выбор уровня образования, постепенное появление

Прототипирование. Практическое руководство

РИС. 11.7. Выбор варианта программы, постепенное появление

Прототипирование. Практическое руководство

РИС. 11.8. Выбор специализации, постепенное появление

Количество ошибок тоже было снижено с 2,5 в исходной модели до 0 в прототипе. Участники отмечали бо́льшую аккуратность нового интерфейса по сравнению с исходным. Некоторые пришли в восторг, когда увидели постепенное появление полей, и отмечали, что им очень понравился вариант с выводом информации только после того, как сделан выбор.

Наконец, доля общей удовлетворенности увеличилась с 60 до 95% для прототипа.

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

Дополнительные ресурсы.

Есть ряд дополнительных ресурсов, которые могут быть вам полезны.

Инструменты.

Dreamweaver. Сайт и среда для разработки приложений от компании Adobe. Разделенный экран и модели анимированного предварительного просмотра дают приблизительное представление, на что будет похож прототип в браузере, когда вы выйдете из программы. А таким пуристам, как я, можно не беспокоиться, что эта программа перепишет ваш сверстанный вручную HTML-файл. www.adobe.com/products/dreamweaver/.

TextMate. TextMate отражает подход компании Apple к операционным системам, примененный к текстовому редактору. TextMate совмещает основы UNIX и графический интерфейс и предоставляет лучшие наработки и экспертам-программистам, и новичкам: macromates.com/.

Coda. Отличный небольшой «инструмент разработки в одном окне» от компании Panic Software[34]. www.panic.com/coda/.

Фреймворки.

960 Grid System. Система 960 Grid облегчает процесс разработки веб-приложений. Предоставляет фреймы наиболее часто используемых размеров с шириной 960 пикселей. Существует два варианта – 12 и 16 колонок. Каждый из них можно использовать отдельно; возможно также применять оба варианта одновременно. 960.gs.

Blueprint. CSS-фреймворк, цель которого – сократить время разработки. Он дает серьезную основу для создания проектов с легкой в использовании сеткой, толковой разметкой текста, полезными дополнениями и даже стилями для печати. www.blueprintcss.org.

jQuery. Это быстрая и лаконичная JavaScript-библиотека, которая упрощает действия в HTML, обработку событий, анимацию и взаимодействия в духе AJAX для быстрой веб-разработки. Она предоставляет новый способ написания команд на JavaScript. jquery.com/.

Prototype. JavaScript-фреймворк, цель которого – легкая разработка динамических веб-приложений. www.prototypejs.org.

Script.aculo.us. Используется вместе с Prototype, предоставляет простые в использовании кроссбраузерные интерфейсные библиотеки для создания сайтов и быстрых веб-приложений. script.aculo.us.

Protonotes. Маленькая JavaScript-библиотека, которая дает возможность добавлять комментарии к прототипам в окошках, внешне напоминающих листочки-стикеры. www.protonotes.com.

Статьи.

Гаррет Даймон, «Просто сделай: HTML-прототипирование и гибкая разработка»[35]: www.digital-web.com/articles/just_build_it_html_prototyping_and_agile_development/.

Джулия Стэнфорд, «Каркасные модели и прототипы в HTML без всяких хлопот»[36]: www.boxesandarrows.com/view/html_wireframes_and_prototypes_all_gain_and_no_pain.

Резюме.

Иногда нет ничего лучше настоящей вещи. Потратьте немного времени на изучение HTML, CSS и основ JavaScript. Это целый новый мир. У HTML есть ряд достоинств, делающих его удобным инструментом для прототипирования:

• это гораздо проще, чем кажется;

• есть много доступных CSS– и JavaScript-фреймворков, которые будут полезны новичку;

• это бесплатно;

• это позволяет оценить реализуемость и стоимость проекта;

• это один из немногих доступных инструментов и методов, который обеспечивает возможность совместной работы;

• он дает возможность экспортировать полученный код в рабочую версию, заметно сократив сроки вывода продукта на рынок.

Глава 12. Тестирование прототипа.

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

Тестирование удобства использования – целая отрасль промышленности. У нее есть свои профессиональные организации: UPA (Usability Professionals Organization – организация профессионалов в области удобства использования) и SIGCHI[37]. На эту тему написано много книг, наиболее заметные из них – «Проектирование с учетом удобства использования» Джекоба Нильсена и «Практическое руководство по тестированию удобства использования» Джозефа Думаса и Дженис Редиш[38]. Есть даже сайт американского правительства, посвященный этой теме: usability.gov.

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

Частые ошибки.

Существуют различные методы, например личное и удаленное тестирование. Есть разные инструменты, такие как Silverback, Morae или обычная видеокамера, закрепленная на штативе. А способов провести тестирование и составить отчет больше, чем разновидностей мороженого.

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

Ошибка № 1: тестирование – процесс, а не событие.

Процесс включает несколько одинаково важных этапов: планирование, подбор участников, управление тестированием, анализ и составление отчета.

Наблюдать за тем, как кто-то использует продукт, несложно. А получить качественные результаты – гораздо более трудная задача.

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

Ошибка № 2: неграмотное планирование.

При планировании тестов важно понимать, кто будет тестировать, что, когда, где, зачем и как.

Для начала задайте себе вопрос: «Зачем мы проводим тестирование?» Ответ прост: мы хотим выяснить, как работает продукт, на основании оценок времени, усилий и удовлетворенности.

Если вы хотите получить отзывы о чем-то не очень объективном и измеряемом, например мнение о погоде, вариантах дизайна А и Б, то такое тестирование в качестве основного метода исследования – не лучший метод. Эти вопросы можно задать в конце теста.

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

Выберите даты тестирования и опирайтесь на них. У нас в Messagefirst цикл тестирования составляет обычно 3–4 недели – от начала планирования до создания отчета. Типичный график выглядит примерно так:

• Неделя 1: выбор человека, который будет проводить отсев участников тестирования, разработка сценариев.

• Неделя 2: набор участников, окончание тестирования сценариев и создание прототипа.

• Неделя 3: тестирование прототипа и начало анализа.

• Неделя 4: окончание анализа и отчет о результатах.

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

Ошибка № 3: выбор неподходящих участников.

Исследователи часто говорят: «Введешь плохие данные – получишь плохой результат». Цель тестирования – посмотреть на продукт глазами людей, которые будут его использовать. Если набрать неподходящих участников (или не набрать подходящих), то вы получите ошибочные данные.

Что может быть хуже, чем не увидеть свой проект глазами потребителей? Увидеть его глазами тех, кто не будет им пользоваться.

Несколько лет назад я проводил тестирование для крупного сайта, посвященного поиску развлечений в Лос-Анджелесе в выходные. Мы искали постоянных посетителей социальных сетей и авторов контента (записей в блогах и обзоров продуктов).

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

Лучший способ убедиться в высокой квалификации участников – или подбирать их самому в соответствии с подробным списком требований, или нанять профессионала. В настоящее время в Messagefirst мы подбираем участников сами. Пример списка наших требований можно найти здесь: rosenfeldmedia.com/downloads/prototyping/Sample_Screener.doc.

Ошибка № 4: плохо сформулированные вопросы.

Правильная формулировка вопросов – одна из самых сложных задач при тестировании на удобство использования. Задача – получить ответ на вопрос, не задавая самого вопроса. Сложно, не правда ли?

Рассмотрим пример сайта, посвященного развлечениям в Лос-Анджелесе в выходные. В прототипе, который мы тестировали, были представлены анонсы фильмов, концертов, местных мероприятий и список ресторанов.

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

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

Мы не спрашивали: «Как бы вы спланировали обед и поход в кино с друзьями с помощью этого сайта?» Мы спросили: «Как бы вы с помощью этого сайта нашли занятие себе и друзьям на эти выходные?».

Чувствуете разницу? В первом вопросе есть прямое указание на обед и кино; результат будет предсказуемым. Второй вопрос более неопределенный, дающий возможность выяснить, как они стали бы использовать сайт. Так мы можем понять, как сайт поможет им, когда они окажутся дома, вдали от нас, в привычной обстановке.

Ошибка № 5: неграмотная модерация.

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

Что делает человека хорошим модератором? Умение находить равновесие.

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

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

Лучший способ улучшить свои навыки модерирования – найти наставника, тренироваться, прислушиваться к критике и снова практиковаться. Можно записывать свои разговоры, а потом по аудио– или видеозаписи оценивать себя. Увиденное и услышанное может вас удивить.

Ошибка № 6: выбор неправильного метода для объявления результатов и рекомендаций.

Никто не будет читать ваш 10–20-страничный отчет. Единственное его назначение – служить подтверждением того, что работа проведена. Он останется набором цифр и букв. Такова жизнь. Но отчет составить все-таки нужно.

Если люди не хотят читать ваш отчет, как донести до них ценную информацию? Все зависит от условий и команды, с которой вы работаете.

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

Презентация в PowerPoint или Keynote с резюме данных отчета – тоже хороший вариант. Эффективны видеоклипы, показывающие ключевые моменты тестирования. Услышать о том, что делают участники в ходе тестирования, – хорошо. Но увидеть это на экране – просто отлично. Это один из лучших способов получить информацию из первых уст.

Подготовка тестирования.

Помните первый руководящий принцип прототипирования из главы 4: «Узнайте целевую аудиторию и ее намерения»? Это также первый шаг в подготовке к тестированию удобства использования. Как и в прототипировании, он определяет все прочие решения.

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

Пример можно найти по адресу: rosenfeldmedia.com/downloads/prototyping/Sample_Screener.doc. Вы можете отредактировать его в соответствии со своими нуждами и свободно использовать.

Если вы собираетесь делать аудио– или видеозапись, то неплохо дать участникам на подпись документ об отказе или согласии на съемку. Тогда вы получите право просматривать ролики впоследствии, а участникам это даст гарантию, что их изображение в дальнейшем не появится на YouTube.

Пример такого документа можно найти по ссылке: rosenfeldmedia.com/books.downloads/prototyping/Waiver.doc. Вы можете его редактировать и свободно использовать.

Цели тестирования влияют на сценарии, изучаемые вопросы и прототип. Эти три элемента взаимосвязаны.

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

Имеет смысл ограничивать продолжительность сеансов тестирования 45–60 минутами. Это позволит изучить 5–6 ключевых сценариев и не утомить участников. Мы обычно проводим 45-минутные сессии с получасовыми перерывами. При таком формате можно проводить 6–8 тестовых сессий в день.

30-минутный перерыв между испытаниями разных групп участников дает достаточную гибкость на случай, если кто-то опоздает (это практически неизбежно) или если сессия продлится дольше 45 минут (что тоже случается).

Кроме того, за время 30-минутного перерыва можно кратко опросить участников после сессии и при необходимости внести изменения в сценарии или прототип.

Создание сценариев тестирования.

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

В приведенном выше примере сайт использовался для поиска развлечений в Лос-Анджелесе на выходные. Цель была не в том, чтобы найти подходящий ресторан или даже концерт. Участникам требовалось что-то интересное для них самих и их друзей. Поиск ресторана или концерта был только процессом для достижения цели – приятного времяпрепровождения с друзьями.

Хороший сценарий тестирования сосредоточен на цели, при этом учитывает действия, которые надо предпринять для ее достижения, и соответствующий процесс. Отличный вариант в таком случае – кратко описать сценарий и добавить несколько наблюдений или ключевых вопросов.

Если цель в том, чтобы найти развлечение для компании на выходные, то тестовый сценарий можно определить так:

«Вы сказали, что вы и ваши друзья искали, чем заняться в выходные, и это могло бы включать [поход в ресторан, на концерт], и вы хотели бы заглянуть в новый клуб […]. Покажите мне, как вы могли бы спланировать выходные с помощью данного сайта».

Вместо […] нужно вставить ключевую контекстную информацию, собранную во время открытого обсуждения с участниками.

Затем можно было бы включить несколько ключевых вопросов или наблюдений.

• Как они начинают действовать (поиск, переход по страницам)?

• Ищут ли они первым место для развлечений или место, где можно поесть?

• Как они определяют, в какой ресторан пойти?

• Как они выбирают вид развлечений?

• Как они согласовывают план (например, по телефону, с помощью СМС, электронной почты, в Twitter)?

• Видят ли они расположение объектов на карте? Что думают?

Возможно, вы захотите включить в сценарий некоторую систему оценок. Мы предпочитаем шкалу от 1 до 5 для оценки сценария как участником тестирования, так и модератором.

Тестирование прототипа.

Получить отклики участников тестирования проще, если они чувствуют себя комфортно. Я часто использую такой прием: обязую модератора приветствовать участников, представиться, предложить им напитки и начать разговор по дороге в комнату. Это дает ему возможность завязать контакт с участниками и обеспечить им комфорт как можно быстрее.

Я обнаружил, что участники удаленного тестирования чувствуют себя комфортно с самого начала. Думаю, этому способствует привычная обстановка: не приходится идти в странное место и сидеть в комнате перед объективом видеокамеры, зная, что к тому же из соседней комнаты за ними кто-то наблюдает.

Когда участники расслаблялись, я начинал вводный диалог, прося их описать их опыт, относящийся к тому, что́ мы собирались тестировать. Например, если я хотел узнать, как они будут использовать сайт, чтобы найти развлечение на выходные в Лос-Анджелесе, я просил их рассказать мне о том, как в последний раз они планировали вечер с друзьями.

Я мог спросить, как они договаривались о встрече, использовали ли электронную почту, СМС, телефонные звонки или другие способы связи. Иногда меня интересовало, какие виды развлечений их привлекали: поход в кино, посещение ресторана или концерта.

Собрав информацию во время вводного диалога, используйте ее для создания контекста.

Сделайте вид, что у вас есть замечательный проект, который облегчит планирование отдыха. Предложите им вариант «Что находится поблизости». Суть такова: когда кто-то находит интересующее его место, например ресторан, вы показываете ему другие точки питания и рассказываете о проводящихся поблизости мероприятиях. Эти элементы должны быть отмечены на карте со звездочками рейтинга и числом отзывов.

Во время вводного диалога участник рассказал вам, что он хотел зайти в ресторан In-N-Out Burger[39], а затем на концерт местной группы. Превосходно. Вы можете использовать эту информацию, чтобы задать рамки сценария и дать участнику реальный контекст.

Я мог бы начать так: «Вы сказали, что собирались пойти в In-N-Out Burger, а потом на концерт местной группы. Вот страница. Покажите на ней, как вы стали бы искать ресторан и что-нибудь еще неподалеку, что вас могло бы заинтересовать».

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

Это тонкий нюанс. Однако он отражает сбалансированный подход к постановке вопроса: участника просят поискать что-нибудь неподалеку от In-N-Out Burger, не давая прямых указаний.

Совет.

Руками не трогать.

Если вы тестируете прототип, находящийся на тестовом сервере или сервере разработчиков, убедитесь, что разработчики не вносят в него изменения в день тестирования. Я сталкивался с таким пару раз. Это не только неприятно, но и приводит к напрасной трате времени участников тестирования и клиентов.

Запись наблюдений и отзывов.

Модерировать и одновременно фиксировать происходящее непросто. Лучше назначить одного человека в качестве модератора, а другого – для ведения записей. В этом случае каждый будет сосредоточен на своей задаче.

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

Как я уже упоминал, и участники, и модераторы используют одну и ту же шкалу для оценки каждого сценария. По завершении работы модератор задает примерно такие вопросы: «Как бы вы оценили поиск развлечений на выходные в Лос-Анджелесе по шкале от 1 до 5, где 1 – очень трудно, а 5 – очень легко?».

Оценки участников записываются, модератор указывает свою оценку отдельно, не сообщая ее участникам.

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

Оценка участников более субъективна, выражена в качественной форме и представляет собой меру их удовлетворенности решением задачи. Оценка модератора более объективна и количественна, поскольку основана на измеримых параметрах (время и усилия).

Некоторые записывающие системы, такие как Silverback, Morae или видеокамера, смонтированная на штативе-треноге, помогают убедиться, что вы ничего не упустили. Если вы забудете важные детали, то всегда сможете отмотать запись назад и пересмотреть ее. Это также хороший способ уточнить свои заметки.

Методы фиксации заметок варьируют: от записи на бумаге до использования таблиц Excel и специально разработанных для этой цели программ.

Программа Morae имеет встроенные возможности записи заметок и пометки флажками ключевых точек во время записи. Эти функции хороши, но я считаю, что интерфейс и взаимодействия в этой программе сложны и неудобны. Кроме того, она не работает на компьютерах Mac. Если в вашей аудитории только пользователи Windows, то она вам подойдет. Но наша работа часто требует участия в тестировании пользователей и Mac, и PC, поэтому для нас такая программа непригодна.

Качество наших выводов имеет первостепенное значение, и мы стараемся отфильтровать все, что не относится непосредственно к тестируемой системе. Опыт использования Firefox на Windows не то же самое, что опыт использования Firefox на Mac. Поэтому мы предоставляем в распоряжение пользователей Mac компьютеры Mac, а пользователей Windows – компьютеры с Windows.

Мы используем компьютеры iMac с процессорами Intel и программу Silverback, чтобы вести аудио– и видеозапись. Это позволяет нам запускать и Mac, и Windows на одной машине. Функция общего доступа к изображению на экране, встроенная в Mac OS X, позволяет видеть экраны удаленных компьютеров; при этом не нужно использовать дополнительное оборудование или ПО.

При удаленном тестировании можно обеспечить общий доступ к экрану с помощью ряда программ, в том числе NetMeeting, WebEx и Adobe Acrobat Connect.

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

• наблюдение: услышанное или увиденное;

• время: в какой момент это произошло;

• теги: ключевые слова, описывающие наблюдение.

Мы создали свою систему, облегчившую сбор и анализ информации. А вы можете записывать сведения на листе бумаги или в электронную таблицу, если вам так удобнее.

Анализ и определение следующих шагов.

В большинстве случаев, когда я начинаю процесс анализа, у меня есть короткий список важных проблем (их я уже обдумываю). Обычно сюда входят моменты, которые я не раз наблюдал в ходе тестирования. Этот короткий список – точка отсчета.

Недавно мы провели некоторое количество тестов для клиента как на месте, так и удаленно. Мы знали, что собрали много информации. Но насколько много ее было – мы даже не задумывались, пока не распечатали все заметки на листах клейкой бумаги и не повесили на стену. Оказалось, что мы записали более 1000 фрагментов данных (см. рис. 12.1).

Прототипирование. Практическое руководство

РИС. 12.1. Тысяча фрагментов данных

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

Работа с ними заняла несколько дней, но я не верю, что мы могли бы провести такой эффективный, глубокий и широкий анализ как-то иначе.

Когда темы определены, можно оценить их важность и выводы по каждой из них. Как это сделать?

Я знаю несколько способов определения важности проблем. Вероятно, самый распространенный основывается на частоте (как часто возникала), тяжести или изучаемости (становится ли это проблемой всякий раз, и позволяет ли система снизить ее сложность).

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

Заключение.

Несколько лет назад я участвовал в дискуссии с консультантом по удобству использования, который сослался на итоговое тестирование (проводимое на финальном этапе). Я сомневаюсь в ценности такого тестирования, поскольку не верю в то, что процесс разработки продукта когда-нибудь заканчивается. Это непрерывный цикл.

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

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

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

И, наконец, мне всегда интересно изучать новые методы и приемы. Если у вас есть метод или прием, о котором вы готовы рассказать, я с удовольствием послушаю. Кто знает: может быть, ваш совет появится на страницах следующего издания (да, это намек).

Резюме.

Тестирование прототипа – ключевой этап прототипирования. Во время тестов не забывайте о следующем:

• это процесс, а не событие;

• полученные результаты хороши настолько, насколько хороши участники. Убедитесь, что вы привлекли нужных людей;

• управление тестированием – навык, на развитие которого уходят годы. Поэтому практикуйтесь, и чем чаще – тем лучше;

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

• выберите правильный метод сообщения о результатах;

• видеозапись – очень мощный инструмент.

Благодарности.

В создании этой книги мне очень помогла поддержка разных людей. Прежде всего хочу поблагодарить Лу Розенфельда и консультативный совет издательства Rosenfeld Media. Я пришел к Лу с тремя темами для будущей книги. Он выбрал ту из них, к которой я был готов меньше всего (так обычно и бывает). Спасибо издательству, что подтолкнуло меня к написанию этой книги. Во время этой работы я многому научился.

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

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

Я благодарен этим людям, внесшим вклад в эту книгу: Биллу Скотту из компании Netflix, Андерсу Рэмси, независимому консультанту по взаимодействию с пользователями, Дэвиду Вербе из Adaptive Path, Роберту Рейману из агентства Frog Design, Крису Палле, независимому консультанту по взаимодействию с пользователями, Виктору Шу из Axure, Скотту Мэттьюзу из Xplane, Тому Хамбергеру из iRise, Роберту Хекману-младшему из Miskeeto, Джо Соколу из Regular Joe Consulting, Натану Кертису из Eight Shapes, Хэнку Вижнолзу и Стефану Уоббену из Concept7, Джонатану Бейкер-Бейтсу из Expedia и Фреду Бичеру из Evantage.

Несколько замечательных людей отрецензировали главы, где я описывал конкретные методы и инструменты, чтобы уточнить детали. Я благодарю Джефа Пэттона, независимого консультанта по взаимодействию с пользователями и консультанта по Agile, за рецензирование главы о прототипировании на бумаге; Андерса Рамси за рецензирование глав, посвященных Visio и HTML; Алана Массельмана, ведущего разработчика интерфейсов и приверженца Fireworks в компании Adobe, за рецензирование главы о Fireworks и Фреда Бичера за рецензирование главы об Axure RP Pro.

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

Об авторе.

Прототипирование. Практическое руководство

Тодд Заки Варфел – основатель и главный проектировщик компании Messagefirst – консультационного агентства по проектированию, оказывающего помощь компаниям в усовершенствовании, повышении полезности и удобства пользования их продуктов. Спросите у Тодда, на что он тратит свою жизнь, и он ответит: «Я просто проектировщик». Он считает, что проектирование – комплексное умение, ремесло, и, как любой великий мастер, очень гордится своими творениями. Он не из тех, кто обсуждает замысловатые различия между архитектурой информационных систем, разработкой взаимодействия, обоснованным проектированием и созданием услуг. Для него все это – «большой дизайн». Любую проблему Тодд рассматривает как вызов, возможность исправить ошибку. Тодд – мастер-наладчик. Иначе он не умеет. Он редко удовлетворен существующим положением дел и верит, что всегда смог бы сделать работу лучше. И это одна из причин, по которым он стал проектировщиком.

Тодд – проектировщик по профессии, а не по образованию. Он имеет диплом по когнитивной психологии и писательству (английский язык). Когда он окончил колледж, всемирной сетью управляли терминалы VAX, а книги печатались только на бумаге.

Тодд проектировал, создавал и ломал вещи в течение более 15 лет. Ему посчастливилось разрабатывать сайты, веб-приложения и другие программные системы для таких клиентов, как AT&T Wireless, Bankrate, Citi, Comcast, Cornell, Numara и Нью-Йоркский университет. Он признан одним из лидеров отрасли в области исследований и проектирования, неоднократно выступал на конференциях и проводил занятия в разных уголках земного шара. Он входит в состав участников Оперативной группы по обучению разработке веб-стандартов (Web Standards Project Education Task Force) и составляет расписание курсов обучения прототипированию.

Тодд имеет репутацию гурмана и ценителя вин. Если вам выпадет шанс пообедать с ним, скорее всего, пиршество окажется настоящим приключением, которое вы не скоро забудете. Тодд также имеет удостоверение профессионального гонщика и надеется когда-нибудь получить удостоверение летчика.

Сейчас Тодд живет в Филадельфии со своей прекрасной женой Анжелой, сыном Элией и английским бульдогом по кличке Дачесс. Тодд ведет блог по адресу www.zakiwarfel.com и пишет в Twitter под именем @zakiwarfel.

Примечания.

1.

OmniGraffle – приложение по созданию диаграмм, разработанное Omni Group для компьютеров Mac. Выпускается с июня 2012 года.

Balsamiq – графический пользовательский интерфейс для создания макетов. Онлайновая версия вышла в 2008 году. Прим. ред.

2.

Snyder C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, 2003.

3.

Специалисты используют для описания этого метода термин «вайрфрейм» (wireframe). Прим. науч. ред.

4.

AJAX (от англ. Asynchronous JavaScript and XML, асинхронный JavaScript и XML) – использование «фонового» обмена данными браузера с веб-сервером в интерактивных пользовательских интерфейсах веб-приложений (позволяет ускорить и повысить удобство работы). Термин появился в 2005 году. Прим. ред.

5.

Подробнее см.: http://developer.yahoo.com/ypatterns/richinteraction/transition/selfhealing.html. Прим. науч. ред.

6.

Генеральный директор. Прим. ред.

7.

См.: http://www.youtube.com/watch?v=j5tFFIBDzVs.

8.

www.flickr.com/photos/soxiam/2532060829/.

9.

www.flickr.com/photos/soxiam/2532060829/.

10.

Эскизы можно зафиксировать с помощью фотоаппарата или интерактивных досок Smartboard.

11.

Подкаст – аудио– или видеофайл в стиле радио-/телепередачи, распространяемый в интернете. Прим. ред.

12.

Web 2.0 – сетевые проекты, информацию для которых подбирают и уточняют непосредственно пользователи. Прим. ред.

13.

www.teehanlax.com/blog/?p=293.

14.

Каскадная модель (waterfall model) – модель последовательной разработки программного обеспечения. Впервые описана У. У. Ройсом в 1970 году. Прим. науч. ред.

15.

Инкрементный – связанный с увеличением значения на фиксированную или переменную величину; инкрементный подход заключается в том, что на каждом этапе вы работаете только над теми элементами, над которыми не работали ранее. Прим. ред.

16.

Участникам опроса разрешали, но не требовали от них выбирать несколько чаще всего используемых ими инструментов, не более трех – например, бумагу, Visio и HTML. Поэтому общая сумма процентных значений превышает 100. Источник: http://goo.gl/OAjRR.

17.

* Возможность оценить полноту информации на каждом шаге в связанном процессе. Прим. науч. ред.

18.

Я использую термин «в духе AJAX», поскольку пуристы стали бы утверждать, что AJAX переносит информацию на сервер и обратно. Но во многих случаях эффект достигается без фактического обмена данными с сервером.

19.

www.istartedsomething.com/20071014/microsoft-prototpying-powerpoint/. Обратите внимание, что при наборе этой ссылки слово «prototyping» надо написать с ошибкой.

20.

Под трафаретами здесь и далее понимаются «стенсилы» (stencils) – схематичные элементы интерфейса. Прим. науч. ред.

21.

Caitlin Gannon, Creating an Interactive PDF Prototyping with Visio.

22.

Karen Bachmann and Whitney Quesenbery, Prototyping and Usability Testing with Visio.

23.

Текущая версия Fireworks CS6, вышла в 2012 году. Прим. ред.

24.

Jim Babbage, Creating an interactive PDF file from a multipage document in Fireworks CS4.

25.

Nick Myers, Designing interactive products with Fireworks.

26.

David Hogue, Fireworks Tips & Tricks – Creating Interactive Prototypes.

27.

Learn Fireworks CS4 – Creating Interactive Prototypes for Review.

28.

Prototyping Adobe AIR Applications with Fireworks CS4.

29.

Kumar Vivek, Designing for Mobile Devices Using Fireworks CS4.

30.

В 2012 году вышла версия 6.5. Прим. ред.

31.

World Wide Web Consortium – Консорциум всемирной сети. Прим. ред.

32.

Resource Description Framework – среда описания ресурса (модель для представления данных). Прим. ред.

33.

Речь о фильме 1931 года, режиссер – Джеймс Уэйл, в одной из главных ролей Борис Карлофф. Прим. ред.

34.

Panic Software – американская компания по производству программного обеспечения для Mac OS X. Первый продукт компании (Transmit) выпущен в 1998 году. Прим. ред.

35.

Garrett Dimon, Just Build It: HTML Prototyping and Agile Development.

36.

Julie Stanford, HTML Wireframes and Prototypes: All Gain and No Pain.

37.

SIGCHI (Special Interest Group on Computer – Human Interaction) – специализированная группа по пользовательскому взаимодействию, подразделение Ассоциации вычислительного оборудования (Association for Computing Machinery, ACM). Прим. ред.

38.

Nielsen J. Usability Engineering. Morgan Kaufmann, 1993; Dumas J. S., Redish J. C. A Practical Guide to Usability Testing. Intellect Ltd; Rev Sub edition, 1999.

39.

In-N-Out Burger – американская региональная частная сеть ресторанов быстрого обслуживания в пяти западных штатах. Включает 282 филиала, основана в 1948 году. Прим. ред.