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

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

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

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

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

Легко заполнить окно десктопного браузера панелями инструментов социальных сетей, ссылками на похожие статьи, RSS-ссылками и облаками тегов. (Если я не ошибаюсь, то это называется «созданием дополнительной ценности».) Но как только мы вынуждены работать с экраном, размеры которого на 80 % меньше, чем наш обычный холст, несущественный контент и всякий хлам быстро отпадают, и мы можем сосредоточиться на действительно важных аспектах наших проектов.

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

 

Определяем разрешение

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

Табл. 5.1. Список устройств с различным разрешением

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

Когда список готов, можно приступать к самому дизайну.

 

Итеративный совместный дизайн

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

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

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

В процессе работы над последними проектами с отзывчивым подходом я обнаружил, что, если объединить этапы проектирования и разработки, такая коллективная работа будет более эффективной. Я называю этот новый этап «проектоработкой». (Шутка.)

Вначале команда дизайнеров представляет макет страницы всей группе. Как правило, это дизайн для стационарных компьютеров (рис. 5.3), хотя иногда мы можем начать с мобильного представления дизайна. Цель заключается в том, чтобы дать всей группе импульс для обсуждения того, как этот дизайн будет согласоваться с различными диапазонами разрешений и типами ввода. Возникают самые разнообразные вопросы: «Как это слайд-шоу будет работать с сенсорным интерфейсом?», «Этот модуль всегда будет свернутым по умолчанию или пользователи стационарных компьютеров увидят больше информации?», «Как этот элемент станет выглядеть (и функционировать), если в браузере не будет JavaScript?»

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

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

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

После этого мы начинаем менять размеры окна браузера и анализировать соответствующие изменения нашего дизайна (рис. 5.4). Некоторые расширения, как, например, Web Developer Toolbar для Firefox и Chrome (), на этом этапе могут быть исключительно полезны. Если у вас есть список разрешений (табл. 5.1), вы можете сохранить их в расширении для быстрого доступа в будущем (рис. 5.5).

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

Рис. 5.5. Меню Resize в Web Developer Toolbar позволяет изучить содержимое в разрешениях для различных устройств

Но вспомните: в предыдущей главе мы говорили о том, что изменение размеров окна браузера – это только промежуточный этап. Если вы действительно хотите проверить, как ваша страница будет отображаться на том или ином устройстве, ничто не заменит само устройство. (Если вы интересуетесь приложением для тестирования на мобильных устройствах, я настоятельно рекомендую вам почитать статью Питера-Пола Коха Smartphone Browser Landscape («Многообразие браузеров для смартфонов»), которую вы сможете найти на A List Apart: . В принципе, даже если вы не собираетесь покупать кучу разных телефонов, все равно почитайте, оно того стоит).

На этом этапе начинает прорисовываться прототип. Он основан на оригинальном макете, созданном командой дизайнеров, но в процессе написания кода разработчики дают свои рекомендации по поводу того, как этот дизайн должен реагировать на различные устройства. Другими словами, разработчики действуют как дизайнеры, просто они работают в другой среде и рассматривают дизайн с точки зрения браузера, а не 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, но более динамичный подход заставил их обратиться к нашему реальному холсту: браузеру.