Прототипирование – возможность показать, рассказать, получить опыт
Если картинка лучше тысячи слов, то прототип лучше десяти тысяч. Он значительно расширяет возможности показа и рассказа, дает возможность испытать разработку.
Одно дело рассказывать и показывать раскадровки, и совсем другое – видеть в реальности.
Роберт Хокман‑младший
Есть ряд способов документирования дизайна, включая описания требований, метод каркасного представления, визуальные компоненты и прототипы.
Стандартные модели документирования
Техническое задание. Обычно это документ, где объяснены технические и функциональные требования к системе.
В технических заданиях обычно много слов и мало иллюстраций. Они много говорят, но мало показывают. Недостаток визуальной симуляции часто приводит к неправильному пониманию задания. Чтобы снизить этот риск, в документ можно добавить изображения, но только статичные.
Каркасные представления. Вы видели архитектурные чертежи зданий? Это примерно то же, что и каркасное представление для программного обеспечения. Каркасные представления – изображение структуры функциональных страниц. Они показывают, какие элементы есть на странице и как они соотносятся друг с другом. Каркасные представления обычно выполняются в черно‑белом варианте или в оттенках серого.
Каркасные представления в сочетании с подробным описанием поведения элементов лучше решают задачу, чем технические задания. Однако часто остаются пробелы, что приводит к пропуску деталей или неправильному толкованию.
|
|
|
Прототипы. Прототип – модель или симуляция, представляющая финальный вариант системы. В отличие от технических заданий и каркасных представлений, он дает возможность испытать разработку.
Некоторые технические ограничения, например на размер страницы в 100 КБ, могут быть незаметными в прототипе. Их можно зафиксировать во вспомогательном документе, гораздо меньшем по размерам, чем 60–200 страниц.
По сути, технические задания и каркасные представления недостаточны для того, чтобы показать сложную систему и рассказать о ней. Их можно использовать для простых систем, но в случае сложной системы возникнут серьезные трудности. Нередко эти два метода применяются вместе для создания «полной картины». Однако испытания в таком случае часто заканчиваются неудачей.
Сочетание аннотированных каркасных представлений с техническим заданием может представить исходное ви́дение с точностью 70–80%. Остается слишком много возможностей для ошибок.
AJAX и Monkey Wrench
Что произойдет, если добавить AJAX[4] или другое приложение RIA (Rich Internet Applications – многофункциональные интернет‑приложения)? Все начнет разваливаться на части, причем быстро. Ни техническое задание, ни аннотированные каркасные представления не могут отразить правила взаимодействий и переходов.
|
|
|
В основе традиционных взаимодействий лежат страницы. В AJAX и RIA часто используются состояния. Страница или экран могут содержать несколько слоев или виджетов, которые работают независимо друг от друга (и в то же время взаимосвязаны). Например, обновление канала RSS на странице не требует обновления всей страницы. Обновляется только виджет RSS, все остальные элементы остаются прежними.
Это дало многим разработчикам повод заявить, что парадигма страницы мертва, а новая парадигма – экран или состояние.
Переходы и анимация – еще одна проблема. Пытались ли вы описать самоисправляющийся переход в AJAX?[5] Мое самое удачное описание, дополненное пассами фокусника и взмахами воображаемой волшебной палочки, вызвало удивление и непонимание у публики.
AJAX и другие технологии RIA используются все чаще; потребность в прототипах и их ценность как средства взаимодействия при разработке существенно возрастают. Я бы сказал, что прототипы становятся крайне важны для достижения успеха.
|
|
|
Прототипирование снижает вероятность неправильного восприятия
Возьмите 60‑страничное техническое задание. Посадите в комнате 15 человек. Раздайте им документ. Пусть они его прочтут. Спросите у них, что именно вы разрабатываете. Скорее всего, вы получите 15 разных ответов. Теперь представьте, что в документе 200 страниц. Результат будет еще хуже.
Прототипы – гораздо более конкретное и осязаемое представление системы, которую вы разрабатываете. Они дают ощутимый опыт.
Когда мы перешли от технических заданий к прототипированию, то сразу заметили сокращение количества необходимых уточнений и переделок. Когда‑то доля совпадений в интерпретации задания составляла 60–80%; теперь она достигала 90% и даже больше.
Оказалось, на разработку прототипа требуется меньше времени и усилий, чем на создание подробного технического задания и аннотированных каркасных представлений.
Я знаю несколько причин, по которым документация оставляет больше возможностей для неправильного истолкования:
• Техническое задание объемом 60–200 страниц никто не захочет читать. Это не приносит удовольствия.
• Если вы не сможете убедить людей прочесть задание, те не смогут до конца его понять.
|
|
|
• Документация не дает возможности увидеть картину в целом. Приходится читать строчку за строчкой.
• Слова слишком часто можно истолковать по‑разному.
Кроме того, прототипы имеют ряд преимуществ, которые помогают снизить вероятность неправильного толкования:
• Вы испытываете работу системы, а не просто читаете о ней.
• Прототипы поощряют игровое поведение. Когда вы даете человеку возможность поиграть с прототипом, повышается вероятность, что тот поймет, как должно работать ваше «детище».
Дата добавления: 2019-02-12; просмотров: 182; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!