Рис. 3.16. Эта отличная инфографика с сайта BBC News содержит жизненно необходимую с точки зрения контента информацию. Простое масштабирование может оказаться неэффективным
В этом случае нужно найти способы передачи различных вариантов одной и той же картинки в разных диапазонах разрешений. Другими словами, вы можете создать один образец для десктопных браузеров, а второй, более линейный, – для устройств с маленькими экранами. Задав эти параметры, вы можете положиться на сервер, который сам выберет наиболее подходящее изображение.
Такое решение выходит за рамки данной книги (и не всегда по силам вашему покорному слуге), однако дизайнер-разработчик Брайан Ригер описал возможный подход в своем блоге (http://bkaprt.com/rwd/23/), откуда вы и сможете его скачать.
Если вы решили использовать серверное решение, его можно укрепить различными клиентскими приемами, которые мы уже обсуждали. Например, вы можете создать несколько вариантов изображения под разные диапазоны разрешений, а затем использовать правило max-width: 100 %, чтобы сгладить переход на другие устройства, браузеры и диапазоны разрешений.
Гибкие сетки и изображения как древо познания
Итак, к этому моменту мы изучили все, что необходимо для успешного создания сложных, но гибких макетов: простая математика для гибких сеток и немного стратегических решений для изображений и других медиафайлов. Все эти знания вы можете применять не только по отношению к блогу, который мы писали, но и ко всему сайту Robot or Not, создавая дизайн, основанный на системе пропорций и процентов, без всяких пикселей (рис. 3.17).
Имея на руках гибкую основу, мы готовы добавить еще один ингредиент к нашему отзывчивому дизайну.
Рис. 3.17. Использовав рекомендации, содержащиеся в двух главах, мы получили завершенный и гибкий макет, который может расширяться и сужаться в зависимости от размеров окна браузера
В общем-то, я всегда был противником фиксированной верстки. Я с самого начала чувствовал, что будущее – за макетами, которые обладают гибкостью хоть в малейшей степени, ведь они всегда могут подстроиться под размеры окна, экрана или разрешения устройства. Более того, настаивая на необходимости гибкости, я часто использовал эпитеты «перспективный» и «приспосабливающийся». Увы, ко мне не очень-то прислушивались и считали страшным занудой.
Но в какой-то момент все изменилось.
Однако вернемся к нашему сайту Robot or Not. Мы сделали его максимально гибким, однако он все же еще не очень надежный. Да, «резиновая» сетка сделала его менее чувствительным к изменениям размера окна или разрешения экрана, чем при фиксированном макете. Однако изменения в размере и форме окна браузера могут вызвать деформацию всей верстки.
И знаете что? В этом нет ничего страшного!
Понимаю, это неприятно, но все же нам придется понять, что именно случилось с нашим дизайном и где он нарушился. Определив все проблемы, мы сможем эффективно их устранить, даже если придется немного помучиться в процессе.
Поскольку мы работаем с гибким макетом, мы можем просто изменить размеры окна браузера. Это, конечно, не заменит полноценного тестирования на отдельных устройствах, но позволит быстро оценить, как себя поведет наш дизайн в различных диапазонах разрешений. Мы увидим, как именно он будет выглядеть на экране телефона, планшета или другого устройства.
Прежде всего, изменим разрешение окна браузера с 1024 пикселей на 760 пикселей (рис. 4.1). Проблемы сразу же станут весьма наглядными.
Рис. 4.1. Чтобы понять, каким образом будет выглядеть наш дизайн при разном разрешении экрана, достаточно изменить размеры окна браузера
В первоначальном дизайне было несколько привлекательных элементов: впечатляющие заголовки, яркая выделяющаяся картинка и широкие поля. Все это осталось, но – с визуальной точки зрения – стало каким-то невзрачным.
Обратите внимание на то, что картинка в верхней части сайта стала занимать практически всю страницу (рис. 4.2). Поскольку мы обрезали ее при помощи свойства overflow, она не адаптировалась под изменения всей сетки. Кроме того, само изображение – наш любимый робот – теперь обрезано. То есть картинка не только огромная, но и непонятная. Кошмар какой-то…
Рис. 4.2. В верхней части нашего дизайна творится что-то не то
На фоне этой гигантской картинки логотип выглядит совсем крошечным, а поле между навигацией и картинкой исчезло. Глядя на все это, испытываешь приступ клаустрофобии.
Мне неприятно это говорить, но даже при небольшом уменьшении разрешения сайт превращается в нелепое нагромождение различных элементов.
Маленькая сетка, большие проблемы
И это еще не самое ужасное. Если мы уменьшим окно браузера до 600 пикселей – ширины окна маленького браузера или портретного режима на планшетном компьютере, – наша головная боль только усилится (рис. 4.3). В верхней части экрана творится полное безобразие: картинка обрезана настолько, что непонятно, что там вообще изображено, а бедный логотип стал еще меньше. Навигация же выглядит просто непотребно. С этим нужно срочно что-то делать.
Рис. 4.3. Любой посетитель сайта будет в восторге от нашего исковерканного дизайна (это сарказм)
Двигаемся ниже. Господи, что же это происходит с сайтом (рис. 4.4)! Раньше двухколоночная верстка обеспечивала легкий доступ к дополнительной информации, сейчас же она сжимает текст, такие короткие строчки читать крайне неудобно. Фотография не совпадает с текстом, а что на ней изображено, не понять никому.
Рис. 4.4. Эта запись напоминает японское стихотворение хайку – строчки, короткие до боли
И наконец, заканчивая наш печальный обзор, посмотрим на фотографии в нижней части страницы. Они выглядят хуже всего (рис. 4.5), даже хуже картинки в верхней части. Они такие маленькие, что разглядеть, что там на них, невозможно.
Широкие поля, которые мы использовали для обрамления этих картинок, превратились в огромные пробельные моря, поглотившие их.
Рис. 4.5. Мелкие картинки, монструозные поля. Отвратительно!
Широкоэкранные неприятности
Однако проблемы возникают не только тогда, когда разрешение экрана меньше. Если мы максимально увеличим окно браузера, на свет вылезут новые проблемы. Верхняя часть страницы выглядит довольно неплохо (рис. 4.6), правда, картинка теперь меньше, чем выделенное под нее место. В остальном же все более-менее нормально… Ну, далеко от идеального, но вытерпеть можно. Сетка в целом сохранилась хорошо.
Рис. 4.6. Верхняя часть выглядит довольно широкой
А теперь прокрутим страницу вниз, и наше радостное настроение вмиг испарится (рис. 4.7). Помните, какими короткими выглядели строчки текста в маленьком окне? Глядя на то, что появилось на экране, я начинаю по ним скучать. Теперь строчки стали невероятно длинными, и, несмотря на то, что ничто не доставляет мне большего удовольствия, чем выискивать следующую строчку после прочтения предыдущей, придется искать другой способ.
Рис. 4.7. Двигаясь вниз по странице, мы видим все больше проблем. Длинные строки, крошечные изображения, печальный Итан
Ко всему прочему, фотографии в нижней части страницы стали невероятно большими (рис. 4.8). Выглядят они неплохо, но занимают слишком много места. На самом деле на моем мониторе даже и не видно, есть ли что-то над или под этим блоком. Интересно, можем мы сделать хоть что-то, чтобы читатели не сломали глаза, рассматривая наш сайт?
Рис. 4.8. Говоря техническим языком, эти изображения слишком крупные и массивные
Итак, мы определили основные визуальные неполадки. Однако нужно смотреть на проблему шире. Как только мы меняем оригинальное разрешение, сетка оказывает нежелательное воздействие на контент. Ее пропорции ограничивают содержание при низких разрешениях и окружают его пустым пространством – при высоких.
Причем эта проблема возникает не только с гибкими макетами. Ни один дизайн, фиксированный или гибкий, не сможет масштабироваться вне контекста, для которого он спроектирован.
Так как же нам сделать дизайн, который будет адаптироваться к изменениям разрешения экрана и размеров области просмотра? Как сделать так, чтобы страница оптимизировалась в соответствии с браузером и устройством, на котором ее просматривают?
