Отзывчивый веб-дизайн - [26]
На этом этапе начинает прорисовываться прототип. Он основан на оригинальном макете, созданном командой дизайнеров, но в процессе написания кода разработчики дают свои рекомендации по поводу того, как этот дизайн должен реагировать на различные устройства. Другими словами, разработчики действуют как дизайнеры, просто они работают в другой среде и рассматривают дизайн с точки зрения браузера, а не Photoshop. Затем эти рекомендации обсуждаются, проверяются и анализируются всей командой.
Данный вариант еще не может быть полностью выверенным или готовым к производству, поскольку на этом этапе мы снова приступаем к анализу дизайна. Но теперь разработчики и дизайнеры обсуждают код, а не макет.
Интерактивный анализ дизайна
Перед общим собранием разработчики загружают страницу прототипа в различные целевые устройства (рис. 5.6), а на самом собрании представляют ее всей группе. Целью этого этапа является испытание прототипа и анализа отображения страницы на ноутбуках и стационарных компьютерах, телефонах и планшетах. Члены команды меняют размеры окон браузера, изучают фотогалереи и проверяют, насколько удобно выполнять различные действия на устройствах с клавиатурой и с сенсорными экранами.
>Рис. 5.6. Устройства, применяемые при тестировании сайтов в jQuery Mobile (Filament Group, Inc.)
Эти эксперименты с прототипом проходят в русле содержательной дискуссии. Я считаю, что для команды разработчиков полезно будет заранее составить список проблем, которые возникли в процессе создания отзывчивого дизайна. Возможно, они заметили, что на сенсорном экране тяжело попасть в какую-нибудь важную ссылку или что анимация отображается слишком медленно в каком-нибудь десктопном браузере. Определяя области интересов и потенциальные камни преткновения, разработчики подготавливают почву для конструктивного обсуждения функциональности дизайна и его общего впечатления.
Цель такого собрания – анализ «живого» дизайна. Оригинальный макет – это примерный план с правилами разметки, инструкцией по типографике и библиотекой шаблонов, который команда разработчиков должна превратить в отзывчивый дизайн. Другими словами, мы проверяем рекомендации разработчиков и обсуждаем, есть ли необходимость в дальнейшей доработке. Это может быть полный пересмотр оригинального макета или всего лишь некоторые незначительные изменения. После собрания обе команды расходятся со своими новыми задачами, и все повторяется с начала. Анализ, дизайн, разработка и повторение.
Вот гипотетический пример того, как это работает. Например, команда дизайнеров сделала макет модуля глобальной навигации с двумя ключевыми ссылками и полем поиска.
С этим макетом в руках команда разработчиков начинает встраивать навигацию в шаблон (рис. 5.7).
>Рис. 5.7. Так будет выглядеть только что спроектированная строка навигации на экране десктопа
Довольно простой дизайн предусматривает две ссылки, расположенные в ряд, и поле поиска с правой стороны от них. При создании отзывчивого дизайна разработчики решили, что для устройств с маленькими экранами будет более эффективно, если поле поиска займет всю ширину страницы, а ссылки расположатся под ним (рис. 5.8).
>Рис. 5.8. Для устройств с более мелким разрешением ссылки помещены ниже строки поиска
На этапе анализа дизайна несколько дизайнеров высказались в том смысле, что более мелкая версия совсем неудобна. Строка поиска слишком заметна и затмевает собой ссылки. Кроме того, когда они начали тестировать дизайн на различных устройствах, то, пытаясь нажать на ссылку на сенсорных телефонах, попадали в поле поиска.
То есть эта версия никуда не годится. Обсудив все возможности, дизайнеры предложили альтернативное решение (рис. 5.9). Вместо того чтобы отображать поле поиска в меньшем разрешении, они решили оставить его первоначальный размер и поместить его в виде еще одной ссылки рядом с двумя другими. Само поле должно появиться под основным меню при нажатии на эту ссылку (рис. 5.10).
>Рис. 5.9. После обсуждения проблемы дизайнеры решили использовать для проблемной строки навигации другой вариант
>Рис. 5.10. Окончательный вид строки навигации, созданный дизайнерами и разработчиками после нескольких попыток
Это только один небольшой пример того, как идет такая совместная работа. Взаимодействие дизайнеров и разработчиков должно быть постоянным. Обе команды должны периодически проверять свою работу и давать ее на рассмотрение другой. Работая над текущим проектом, наши дизайнеры и разработчики встречаются каждую неделю и выполняют его интерактивный анализ, но в течение недели они также обмениваются эскизами кода или дизайна.
В конечном счете мы хотим объединить традиционные циклы «проектирования» и «разработки» и дать возможность двум группам сотрудничать на такой близкой основе, которая позволит им создать эффективный отзывчивый дизайн. Работая над текущим проектом, наши дизайнеры и разработчики, конечно, используют для проектирования дизайна такие программы, как Photoshop, но более динамичный подход заставил их обратиться к нашему реальному холсту: браузеру.
