Создание сайтов
Шрифт:
Оговоримся: прототипируют не только сайты, но и, например, мобильные приложения, игры для социальных сетей, интранет-порталы. Да, в общем-то, любое программное обеспечение, какое только существует в Интернете. Однако в данный момент мы сосредоточены на сайте.
Кому нужны прототипы
Прототипы полезны всем сторонам, участвующим в разработке сайта. Каждому по-своему.
Заказчик легко считывает с макета, как его пожелания и требования воплощаются в графической форме. Также ему не составит труда сделать поправки к прототипу, указав, куда именно, по его мнению, закралась ошибка и вообще «что не так».
Команда проекта с помощью прототипа лучше согласует свои действия. Еще бы: у каждого перед глазами «декларация о намерениях в картинках». В спорной ситуации гораздо проще ткнуть пальцем в проблемный узел схемы, чем ожесточенно спорить о том, кто где ошибся. Это дорожная карта веб-разработки.
Для веб-студии или исполнителя-фрилансера, которому поручено исходя из итогов предварительного обсуждения, из черновой версии ТЗ дать свое видение сайта, прототип – самый короткий и дешевый путь к тому, чтобы ударить с заказчиком по рукам. Набросав первичный эскиз, толковый разработчик одновременно продемонстрирует лаконичное воплощение требований, предъявляемых к сайту, и, возможно, предложит собственные решения.
Какую пользу приносит прототип
Притом что прототипирование – дополнительный труд, по существу, это «энергосберегающая» технология. Прототип перво-наперво выгоден тем, что дает возможность оценить логику работы сайта в целом на любом этапе реализации проекта без привязки к дизайну. Вкратце его преимущества таковы:
• Снижаются сопутствующие веб-разработке риски. Благодаря прототипу можно на самой ранней стадии понять, что не было учтено ни в концепции, ни в техническом задании. Например, в сервисе онлайн-бронирования билетов продумана внутренняя страница с расширенной формой поиска, однако на главной забыли разместить форму упрощенную.
• Уменьшается общее количество ошибок. С каждым шагом в создании сайта все сложнее восполнять упущенное и переделывать необдуманные решения. Особенно когда ошибки воплотились в коде и дизайне.
• Как следствие, повышается общее качество проекта. Если ошибок минимум, а любые структурные изменения отслеживаются в истории редактирования прототипа, то при возникновении внештатной ситуации в использовании готового сайта будет легче добраться до корня зла. Не говоря уж о том, что просчеты стратегического характера («Ой, а как мы зарабатывать-то будем?») отсекаются таким образом еще на подступах к веб-разработке.
• Сокращаются сроки разработки, снижается ее совокупная стоимость. Ведь каждая переделка – это лишние человеко-часы, которые оплачивает в конечном счете клиент. При наличии внятного прототипа дизайнеры не рисуют кнопки, добавленные ради сакраментального «пусть будет», и программисты не пишут сотни строк кода лишь из-за того, что никто не подумал упомянуть об автоматическом начислении четырех– или пятипроцентной, в зависимости от суммы заказа, скидки зарегистрированному в интернет-магазине покупателю при добавлении товара в «Корзину» («Это же можно перед самым открытием докрутить, да?»).
• Справедливо распределяется ответственность между исполнителем и заказчиком. Благо прототип, особенно интерактивный, вкупе с грамотно регламентирующим обязанности сторон техзаданием помогает оперативно разобраться, по чьей инициативе была выполнена та или иная часть работы и нужна ли она была вообще согласно ранее заключенным договоренностям.
Разновидности
В проекте может быть использован прототип как одного, так и нескольких типов.
• Эскиз – набросок (на бумаге ли, в цифровом виде ли), рисуя который проектировщик старается отобразить основополагающие элементы сайта. Делается он за считанные минуты и часы, однако обычно остается внутренним, промежуточным продуктом. Дешево, сердито, пригодно для первых, пристрелочных дискуссий о реализации проекта. Главный недостаток эскизов, особенно бумажных, заключается в том, что их затруднительно использовать на следующих этапах веб-разработки, и прежде всего в тестировании. Да и во взаимодействии «исполнитель – заказчик» от набросков проку мало: с эскизом по-настоящему удобно работать его автору. Иногда рисуют бумажные макеты, с тщательной прорисовкой интерфейса, с модульной сеткой. Впрочем, такой вариант – на любителя.
• Wire-frame – то же, что блок-схема (рис. 3). Она простейшим образом показывает, какие модули содержит сайт и как они увязываются в единую структуру. Формы – прямоугольные, гамма – обычно монохромная, характер – аскетический. В отличие от интерактивного прототипа (см. далее), классическая блок-схема фиксирует самый общий вид страницы в статике. Как следствие, чтобы было ясно, что должно происходить при работе с каким-нибудь нетривиальным динамическим элементом, зачастую требуются чрезвычайно подробные текстовые ремарки.
• Интерактивный прототип – схематическая развертка конечного продукта, досконально имитирующая работу пользователя с сайтом: нажатие на кнопки, выбор пунктов меню, заполнение чекбоксов. Эдакая «идея сайта», по Платону, которая может быть воплощена в дизайне бесконечно разнообразно. Хороший интерактивный прототип имитирует взаимодействие человека и сайта по меньшей мере в базовых аспектах и обеспечивает быструю обратную связь, благодаря чему ощутимо повышается темп разработки. Он дает возможность на скорую руку протестировать решения, выбранные вами и исполнителем, равно как и опробовать пользовательские сценарии на фокус-группе. Для создания интерактивного прототипа навыки кодинга и верстки обычно не требуются: достаточно воспользоваться одной из несложных в изучении тиражных программ или онлайн-инструментов (см. ниже). Наконец, такой прототип проще поддерживать в актуальном состоянии.
Рис. 3. Прототип главной страницы Setup.ru, выполненный с помощью сервиса Axure
• Мокап (от англ. mock-up – «полноразмерный макет») – строго говоря, не вполне прототип. Вернее даже, без пяти минут сайт. Как правило, подразумевает близкий к финальному вид каждой страницы, однако статичен и лишен интерактивности. Посмотреть, но не «пощупать». Большое достоинство мокапа в том, что его чаще воспринимают всерьез многие заказчики – в противовес аскетичным прототипам («Пф, что за казаки-разбойники со стрелочками вместо сайта?»). Если мокап всплывает в проекте, то либо в начале, либо в конце его реализации: в первом случае – когда требуется убедить заказчика в том, что разработчики не оторваны от реальности и видят возможные «инкарнации» сайта задолго до его рождения, во втором – когда нужно подтвердить, что прототип удачно облачен в дизайнерские одежды. Далее мокапы уместны в том случае, если заказчику трудно воспринимать абстрактные концепции в отрыве от их конкретного воплощения (а прототип – это абстракция).