теперь дело уже не в размере экрана / UIDG corporate blog / Habr
В марте 2012 года Гай Подъярны (Guy Podjarny) провел тест, в ходе которого сравнивалась продуктивность работы сотен новых адаптивных сайтов на устройствах с четырьмя различными разрешениями экранов. Получившиеся результаты были весьма разочаровывающими.После двух лет подъема адаптивного дизайна, когда любой дизайнер и разработчик, которых только можно представить, запрыгнули в этот поезд, тест производительности на различных разрешениях потряс сами основы адаптивной теории.
Гай доказал, что практически все адаптивные сайты имеют избыточный вес.
«Мы сделали интернет по своему подобию … Тяжелым», – Джейсон Григсби.
Но, что еще важнее, мобильные пользователи точно так же, как и пользователи настольных ПК, подвергались килобайтной перегрузке.
Представители веб-сообщества по-разному отреагировали на эти данные. Некоторые заявляли, что адаптивный дизайн не является решением на все случаи жизни и, возможно, на данный момент недостаточно развит, чтобы справляться со всеми вызовами, с которыми сегодня сталкиваются дизайнеры.
К счастью, в веб-сообществе всегда найдутся люди, которые схватят быка за рога и перевернут ситуацию с ног на голову.
Современные веб-гуру вроде Брэда Фроста (Brad Frost), Люка Вроблевски (Luke Wroblewski) и Кристиана Хейльманна (Christian Heilmann) увидели возможности там, где другие ужасались кризису, и смогли обернуть проблему на пользу сообществу.
«Если ваш сайт весит 15MB, то это не HTML5. Это глупость», – Кристиан Хейльманн.
Без обид, но производительность в вебе традиционно достигалась за счет вещей, которые лучше всего описываются жаргонизмами разработчиков. Термины вроде GZIP-инг, уродование (uglifying), минификация, DNS Lookup, файл-конкатенация… Все эти непонятные слова выносят дизайнеров за скобки.
Умные люди в сообществе, однако, все же поняли, что корни проблемы лежат глубже. На самом деле абсолютно не важно, оптимизируете вы или сжимаете изображение в ультра высоком разрешении, если при этом вы просто скрываете его от мобильного пользователя, который все равно должен скачать это изображение, чтобы его посмотреть.
«Хорошая производительность – это хороший дизайн», – Брэд Фрост.
Чтобы создавать по-настоящему легкие сайты, не стоит заморачиваться на производительности, вместо этого, производительность должна рассматриваться как один из элементов дизайна.
Производительность так же важна, как и любая другая вещь. Сайты, которые добиваются хороших результатов производительности, с самого начала придерживаются такого подхода. А те, кто упускает это из виду, в конечном итоге страдают от низкой скорости загрузки.
«Производительность – это уважение. Уважайте своих пользователей и они вернутся снова», – Брэд Фрост.
Почему так происходит
Показатель отказов
Существует исследование, согласно которому, 57% пользователей уйдут с вашего сайта, если он загружается дольше трех секунд.
Google, Page Speed & SEO
Весной 2010 года Google начал учитывать скорость при ранжировании сайтов. Она не оказывает большое влияние на позицию сайтов со средней скоростью загрузки, но если страница не загружается за определенное время, то поисковый алгоритм применяет к такому сайту штрафные санкции.
Это еще раз доказывает, что когда речь идет о пользовательском опыте, необходимо уделять внимание скорости.
Соображения скорости
Люди часто говорят о довольно абстрактной концепции «Мобильного контекста». Согласно знаменитой теории Google мобильные пользователи делятся на три типа:
- Повторяющие (Repetitive Now): люди, которые используют свои телефоны, чтобы быть в курсе непрерывных, повторяющихся изменений (спортивные результаты, обновления ленты в Facebook, динамика акций на фондовом рынке).
- Скучающие (Bored Now): Пользователи, которые обращаются к телефону во время ожидания какого-то события.
- Срочные (Urgent Now)
Похоже на правду, не так ли?
На самом деле это не имеет ничего общего с действительностью. Нет никакого «мобильного контекста». Люди будут использовать свои телефоны во время прогулки по улице, домашнего отдыха или в путешествии на поезде. Они делают все одновременно!
Телефоны следуют за людьми, куда бы те ни отправились. Поэтому люди их используют абсолютно везде.
«Мобильный контекст – важная штука, но сначала нужно понять, что же это вообще, черт возьми, такое», – Тим Кадлец.
Люк Вроблевски приводит действительно интересную статистику:
Где люди используют мобильные устройства?
- 84% дома
- 80% в свободное время в течение дня
- 76% в очередях и в процессе ожидания
- 69% в процессе шоппинга
- 64% на работе
- 62% во время просмотра ТВ-программ (альтернативные исследования дают цифру в 84%)
- 47% во время подготовки к работе
С возникновением новых возможных ситуаций, развитием новых рынков и появлением новых привычек у людей, мобильный контекст неизбежно изменится. Можно с уверенностью предположить, что концепция
И это заставляет нас внимательнее взглянуть на скорость интернета. Есть только одна возможность давать пользователям тяжелый сайт и не получить при этом проблем: если пользователь будет открывать его на Macbook Pro находясь дома с быстрым интернетом.
Однако же необходимо предусмотреть и прочие ситуации, которых существует великое множество. Люди используют для просмотра сайтов бесконечное количество устройств, появляющихся на рынке каждый день.
«Вы не можете знать, с каких устройств будут просматривать ваш сайт. Это решают пользователи», – Карен МакГрейн.
Даже в тех странах, где пару лет назад было не так много смартфонов, сейчас их число растет бешеными темпами.
«Если ваши материалы, контент, информация, продукты, услуги недоступны в мобильной среде, то для этих людей они не существуют вовсе», – Карен МакГрейн.
Еще более важный момент – места, из которых люди будут приходить на ваш сайт. Так что вы должны будете учитывать любую скорость интернета. Дело даже не в том, что некоторые пользователи живут в удаленных регионах, где качество покрытия оставляет желать лучшего. Люди будут заходить на сайт с работы, где есть канал на 100 мб/с, из дома, где доступна скорость от 2 до 30 мб/с, через 3G и 4G и так далее.
Говоря напрямую, адаптивный дизайн больше не история про размеры экранов, но различные сценарии, решения для которых должны быть гибкими и продуманными «от и до».
И как?
Хорошо, что вы спросили.
Выше мы говорили, что производительность не стоит рассматривать, как набор автоматизированных заданий, запускаемых на стороне сервера для спасения обреченного сайта. Существуют способы преодолеть подобные проблемы и даже обратить их в конкурентные преимущества.
Чего стоит избегать
Гай Подъярны выделяет три главные причины существования большого количества тяжелых адаптивных сайтов:
- Загрузка и сокрытие: большое количество элементов загружается, но не показывается пользователю
- Загрузка и урезание: изображения в высоком разрешении загружаются, а затем урезаются для соответствия пользовательскому экрану
- Избыточный DOM: не существует способа избежать парсинга и обработки браузером всех зон DOM, включая скрытые
Упреждающий подход
Существует большое количество информации на тему того, почему сайтам не всегда удается соответствовать ожиданиям в плане производительности. Большинство специалистов говорят что-то вроде «нужно быть адаптивным с самого начала».
Все техники, которые мы обсудим далее, не являются чем-то новым. Интересный момент здесь в том, как они совмещаются и переплетаются, сглаживая недостатки и подчеркивая достоинства друг друга.
Прогрессивное улучшение
Смысл этой техники заключается в обеспечении опыта использования сайта в вебе, который ограничен только самым главным.
Пару лет назад эта теория воспринималась главным образом с «браузерной» точки зрения. С развитием таких технологий как HTML5, CSS3, jQuery и т.п. разработчики, кажется, забыли о своих пользователях. Многие из них создавали несовершенные сайты, слишком полагаясь на эти новые технологии.
Теперь, когда браузеры на основе Webkit, Firefox и другие отвоевали большую долю рынка, появилась другая проблема – огромное количество мобильных устройств с браузерами, которые не обладают возможностями iPhone или Samsung. Прогрессивное улучшение – это единственный подход, который предполагает, прежде всего, учет способностей всех этих забытых игроков, а уже затем движение в сторону более навороченных устройств.
Разработка Mobile First
В 2009 году Люк Вроблевски предложил подход к разработке, получивший название Mobile First, по трем причинам:
- Мобильный рынок продолжает развиваться бешеными темпами.
- Мобильная среда заставляет вас фокусироваться (позволяя избавиться от беспорядка, причиной которому является слишком большее количество места на экране).
- Мобильная среда расширяет ваши возможности (благодаря технологиям вроде GPS, геолокации, мультитач-жестам, акселерометру, камерам).
С тех пор веб-дизайн постоянно смещается в сторону этого подхода. Многие дизайнеры и разработчики отмечают, что построение сначала мобильной версии сайта, дает преимущественно над десктопной разработкой (что очень неплохо иллюстрирует второй пункт выше). Прогрессивное улучшение и подход Mobile First также неплохо сочетаются друг с другом. Разработчики начинают создавать сайт для мобильных устройств, постепенно улучшая его, добавляя большие разрешения к первоначально небольшому размеру экрана.
Джордан Мур (Jordan Moore) собрал отличный список причин использования Mobile First. Он утверждает, что из-за того, что полностью положиться на скорость соединения нельзя, «адаптивный веб-дизайнер» должен начинать работы с самой низкой входной точки – мобильной версии сайта, предполагая низкую скорость соединения, и двигаясь в разработке поэтапно, к более крупным точкам прерывания для более быстрого соединения. В будущем мы сможем полагаться на высокую скорость соединения, но пока стоит принять как должное низкое качество связи и не предпринимать опрометчивых шагов.
Вывод
Разрабатывайте сайт с расчетом на небольшие разрешения и возможности. Используйте технику прогрессивного улучшения с самого начала. Добавляйте дополнительную функциональность, улучшенные визуальные эффекты и способы взаимодействия там, где это имеет смысл.
RESS: Responsive Web design + Server Side components
По мнению многих людей у адаптивного дизайна есть один большой недостаток – он целиком и полностью зависит от определения ширины экрана.
С появлением все большего количества типов устройств, включая гибриды вроде ноутбуков с тачскринами, определение разрешения экрана стало крайне важной вещью в адаптивном дизайне. Библиотеки, которые обеспечивают эту функциональность (главным образом, Modernizr), буквально расцвели и сейчас используются в большинстве проектов. Они помогают разработчикам понимать, поддерживает ли браузер пользователя ту или иную функциональность и, соответственно, предоставлять ее. Но во многих случаях полагаться на браузеры – не лучшая идея, поскольку, зачастую, они могут поддерживать те или иные функции лишь частично, при этом «заявляя» о полной поддержке.
Для решения этой проблемы и был создан RESS. Как и Mobile First термин RESS был образован Люком Вроблевски в 2011 году. Он основывается на определении типа устройства, его оценке и обеспечении связанного пользовательского опыта. Для выполнения этой задачи существуют тяжелые средства вроде WURFL, DeviceAtlas и более легкие, такие как Browser Gem, которые считывают строку User Agent и действуют на основе этой информации.
Оценка типа устройства имеет и другие преимущества. Она позволяет разработчикам использовать различные шаблоны сайта в зависимости от устройства пользователя. Скажем, вы создаете очень большой сайт и хотите упростить мобильную навигацию. Вы можете «поиграть с контентом», показывая или скрывая что-либо, подвигать дивы по JavaScript коду или использовать разные шаблоны для мобильной и десктопной версии сайта, необходимость показа которых определяется сервером.
Представители BBC говорят о том, как RESS и прогрессивное улучшение могли бы работать отдельно. Подход называется Cut the Mustard! Он состоит в создании основной версии сайта, которая будет работать на любом устройстве. Затем устройство оценивается сервером для того, чтобы определить, «срезает ли оно горчицу». Если ответ да, то используется улучшенная версия сайта. Если же устройство не обладает нужными параметрами, пользователь все равно видит основной контент.
Условная загрузка
«Мобильные пользователи хотят видеть наше меню, часы работы и телефон доставки. Пользователи десктопа само собой хотят видеть картинку в 1 мб, на которой кто-то смеется в салат», – Мэт «Wilto» Маркиз.
Рассмотрим пару точек зрения:
1) Мобильные пользователи хотят получить контент, также сильно, как пользователи десктопов.
«Если ваш контент доступен по URL, то его обязательно будут просматривать с мобильных устройств», – Брэд Фрост.
2)Мобильная среда заставляет фокусироваться. Существуют определенные ограничения (вроде скорости соединения или размера экрана), которые дизайнерам необходимо принять, чтобы одинаково хорошо предоставить тот же самый контент.
Эта техника, также называемая «Агрессивным улучшением», позволяет дизайнерам фокусироваться на ключевом контенте и прогрессивно улучшать его для бОльших экранов. Она подразумевает базовый доступ к определенному контенту, который затем может быть дополнен на странице, при появлении места.
«Возможно, более точным определением условной загрузки будет назвать ее подходом content-first. В этом случае сайдбары или многочисленные столбцы с красивым, но нефункциональным контентом – роскошь, вам недоступная», – Джереми Кейт.
Вы можете использовать отличное средство MatchMedia, которое подражает поведению CSS и оценивает размер экрана в JavaScript.
Ленивая загрузка
Сайты, тяжелые на вид и в использовании (Facebook, Twitter, Pinterest), когда им необходима оптимизация для мобильной среды, прибегают к использованию техники ленивой загрузки (lazy loading) для обеспечения лучшего пользовательского опыта. Когда вы загружаете страницу впервые, загружается определенное число постов. Когда вы прокручиваете страницу вниз, дизайнер предполагает, что вы хотите увидеть больше контента, поэтому тот вставляется на страницу с помощью Ajax. Это позволяет значительно ускорить загрузку страницы и избежать избыточности DOM.
Установка бюджета производительности
Тим Кадлец утверждает, что установка максимального веса страницы и контроль этого показателя, является главным способом сокращения времени загрузки страницы. «Задавайте цели и стремитесь к ним». Стив Соудерс (Steve Souders) предлагает на выбор три опции, если вы уже превысили свой бюджет:
- Оптимизация существующей функции или элемента
- Удаление существующей функции или элемента
- Избегание добавления новой функции или элемента
Звучит довольно радикально, но такой подход позволяет сфокусироваться на том, как на общую производительность сайта влияет каждая новая функция.
Кроме того, существует определенное количество методов, работающих на более техническом и менее концептуальном уровне.
Техники работы с изображениями
Веб-сайты примерно на 60% состоят из изображений. И если вы показываете мобильным пользователям с неизвестной скоростью соединения картинки десктопного размера, то обрекаете свой сайт на проблемы со скоростью загрузки.
Способ решения этой проблемы заключается в показе различных версий изображений в зависимости от размера экрана или типа устройства. Таким образом, вы будете показывать маленькое изображение при заходе на сайт с мобильного телефона, картинку в высоком разрешении пользователю десктопа и еще в два раза большее изображение в случае HiDPI устройства.
Адаптивные изображения
Дизайнеры и разработчики во всем мире вели борьбу за включение адаптивных изображений в спецификацию HTML. Мэт ‘Wilto’ Маркиз один из наиболее ярких сторонников этой идеи. Битва еще не выиграна, но появились решения на базе JavaScript, которые помогают добиться желаемого результата.
Скот Йель (Scott Jehl), из Filament Group написал плагин, который имитирует разметку, предложенную сообществом, и прекрасно работает: это PictureFill.
Сжатие изображений
Голландский дизайнер Даан Джобсис (Daan Jobsis) обнаружил очень странный феномен при сжатии изображений в Photoshop. Ему удалось осуществить следующую последовательность действий: он взял изображение, удвоил его размер (200%), сжал его до 25% или менее от его первоначального качества, затем восстановил размер изображения в браузере до изначальной величины (100%). В результате изображение не только стало легче, но и изначально было оптимизировано для HiDPI экранов, благодаря дублированию плотности пикселей.
Единственная обнаруженная проблема здесь заключается в том, что браузеру может быть тяжело отрисовывать увеличенное вдвое изображение в его изначальном размере (особенно если это необходимо делать сотни раз, в случае сайтов с большим числом медиа контента). Чтобы убедиться в оптимальности данного решения необходимо уделить время тестированию.
Векторные vs растровые изображения
Отличным выбором можно назвать SVG изображения. Они полностью масштабируемы, благодаря чему хорошо работают на любом экране. Реализовать fallback в этом случае будет очень просто с помощью Modernizr.
Иконочные шрифты
Технически они на самом деле являются векторными изображениями, только представленными в виде шрифта. Как говорит Крис Койер (Chris Coyier), «иконочные шрифты изумительны» потому что:
- Легко изменять их размер
- Легко менять их цвет
- Легко оттенять форму шрифта
- Они работают в IE6, в отличие от прозрачных PNG.
- С ними можно делать все то же, что и с изображениями
- Они предоставляют неограниченный простор для типографики
Изображения HiDPI
Дэйв Бушелл (Dave Bushell) не так давно написал очень интересную статью с размышлениями о HiDPI-изображениях. Он утверждает, что, даже несмотря на то, что сегодня мы можем показывать пользователям iPhone, iPad или других современных устройств изображения, которые соответствуют возможностям этих девайсов, все еще слишком рано предполагать, что это не навредит сайту.
«Означает ли высокая скорость и высокая плотность пикселей, что пользователи хотят видеть изображения лучшего качества? В случае пакетного тарифа с ограничением по количеству гигабайт, вряд ли», – Дэйв Бушелл.
Что дальше?
Недавно Google разработал новый формат изображений – WebP. Он предоставляет возможность сжатия изображений без потерь, что позволяет получать в три раза меньшие файлы, в сравнении с PNG.
Сегодня существуют простые и легкие JavaScript-библиотеки, с помощью которых можно конвертировать изображения в и из WebP формата. Учитывая влияние последних новинок Google, вполне возможно, что начать эксперименты с WebP для улучшения работы сайтов с большим числом изображений уже сейчас может быть хорошей идеей.
Загрузка элементов
Загружайте элементы аккуратно и по порядку. Контроль этого аспекта несет в себе большие преимущества, позволяя странице сначала отображать базовый контент, а затем улучшать его.
CSS, изображения
Контролируйте загрузку с помощью media query, условной или ленивой загрузки и применяйте техники адаптивных/сжатых изображений.
JavaScript
Используйте такие функции HTML5, как async или defer. Кроме того существуют такие «помощники при загрузке», как RequireJS, который может контролировать загрузку и зависимости.
Реклама, социальные виджеты и сторонние элементы
Просто вставляйте их на страницу после загрузки.
Олдскульные техники улучшения производительности
Они известны довольно давно, но все еще неплохо работают.
Снижайте число HTTP-запросов
Чтобы это добиться, разработчикам необходимо приложить усилия, однако есть ряд способов, позволяющих достичь этого:
- Применяйте конкатенацию для всех CSS-файлов или используйте CSS Preprocessors, чтобы скомпилировать их в один файл.
- Объединяйте JS плагины в том же файле и всегда загружайте их в футере, за исключением случаев, когда им действительно необходимо блокировать рендеринг страницы (если вы загружаете шрифты Typekit в футере, вы получите знаменитый эффект FOUT или «Взрыв нестилизованного текста»).
- При необходимости работы с PNG-изображениями, используйте спрайты. Они объединяют все изображения в одно и используют CSS для «нарезки» его на нужные кусочки.
- По возможности используйте схему данных URL (рус, англ), которая позволит включать изображения в качестве строчных данных и еще сократить число HTTP-заголовков.
Снижайте число байтов
Минифицируйте каждый скрипт или CSS-файл, который вызывается со страницы. Настройте на сервере GZIP-компрессию/расширение и применяйте их для всех элементов.
Заключение
Со времен рождения адаптивного дизайна важность производительности в вебе была сильно преувеличена.
Дизайнеры и разработчики фокусируются на сборке адаптивного паззла, в качестве элементов которого стали выступать различные скорости доступа в сеть, множество различных устройств, разные места нахождения пользователей.
Чтобы подготовиться к проблемам завтрашнего дня нам необходимо обращать большое внимание на производительность, ведь декстоп-ориентированный веб исчезает прямо на наших глазах. Мобильный пользователь быстр, легок и не будет преодолевать препятствия для доступа к контенту, и, учитывая, что сайтов с каждым днем становится все больше, быть быстрым означает быть впереди.
Вам также может понравиться [en]…
P. S. Замечания по переводу принимаются в личку.
P. P. S. Еще мы начали размещать дайджесты интересных публикаций мира юзабилити и UX в своем блоге. Вдруг кому интересно.
Основы адаптивного дизайна / Sandbox / Habr
В этой статье я попытаюсь рассказать, как сделать простой шаблон адаптивным. И, конечно же, я попытаюсь объяснить, что такое адаптивный дизайн.Что такое адаптивный дизайн?
Я уверен, что вы часто «серфите» по сайтам с мобильных устройств и не раз замечали, что есть сайты, где надо масштабировать страницу, чтобы прочитать текст. А бывает, что еще хуже — текст может не поместится на всю страницу и вам придется крутить страницу и по горизонтали, и по вертикали.
Зайдя на сайт с адаптивным шаблоном все меняется, ибо текст «подстраивается» под ваш телефон (разрешение экрана).
Теория (основы)
Думаю, всем известно, что все шаблоны (их стиль) построен на CSS. И адаптивный дизайн — не исключение. Наиболее важное изменение — изменение единиц измерения. Представим, ширина блока 400 пикселей, а значит, что ее надо указывать в процентах (например, 40%).
max-width и width
Тоже очень важная часть в дизайне. Например, ширина нашего сайта 1000 пикселей, но при изменение окна (по ширине, меньше 1000 пикселей), появится горизонтальная прокрутка. Но все поменяется, если мы укажем width: 100%, ибо сайт будет «подстраиваться» под наш экран.
С большими мониторами не так все просто, поскольку текст растянется на весь экран. А получается, если монитор широкоформатный, то текст будет нечитабельным.
Если вам нужно, чтобы сайт остался с такой же шириной, но при этом остался «адаптивным» — надо изменить CSS-код, как указано ниже.
Было
width: 1000px;
Стало
width: 100%;
max-width: 1000px;
min-width и width
Если чуть выше мы ставили максимальную ширину, то здесь мы устанавливаем минимальную ширину. К примеру, если установить минимальную ширину 200 пикселей, то окно браузера достигает этой ширины и оно больше не будет уменьшаться (появится горизонтальная прокрутка).
Практика
Шаблон, который будет выступать в качестве демонострации, будет иметь в себе три составляющих: шапка, основной контент и боковая колонка (сайтбар).
- Шапка — #headerInner
- Основной контент — #colLeft
- Боковая колонка — #colRight
Проверить адаптивность шаблона можно с помощью масштабирования окна (см. скриншот).
HTML
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Адаптивный шаблон</title>
</head>
<body>
<div>
<div>
<a href="http://bifot.ru/blog/">Логотип</a>
</div>
</div>
<!-- начало wrapper -->
<div>
<div>
<div>
<div>
<div>
<h2>Основной контент</h2>
<p>Здесь будет находится основной контент страницы</p>
</div>
</div><!-- конец colLeft -->
<!-- начало colRight -->
<div>
<div>
<h2>Текст сайтбара</h2>
<p>Содержимое сайтбара</p>
</div>
</div><!-- конец colRight -->
</div><!-- конец content -->
</div><!-- конец middle -->
</div><!-- конец wrapper -->
</body>
</html>
CSS
* {
margin: 0;
padding: 0;
}
body {
width: 100%;
height: 100%;
color:#333;
background: url(images/body.png) 0px 0px repeat;
font-family: "Segoe UI", "HelveticaNeue-Light", "Helvetica Neue Light", "Helvetica Neue", Helvetica, Arial, sans-serif;
font-size:0.94em;
line-height:135%;
}
h2 {
font-size:30px;
font-weight:normal;
padding:0px 0 0px;
line-height:100%;
font-style:italic;
}
a {
color: #cd5252;
text-decoration:none;
}
a:hover {
color:#963c3c;
text-decoration: none;
}
/* -------------------------------
Структура
----------------------------------*/
/* -------------------------------
Ширина сайта в 1000px
----------------------------------*/
#wrapper {
margin-top:40px;
border:0px solid #000;
width: 100%;
max-width:1000px;
margin: 0 auto;
height: auto !important;
}
/* -------------------------------
Шапка сайта
----------------------------------*/
#headerInner {
border: 0px solid #000;
background: #d04942;
position:relative;
width:100%;
max-width:1000px;
height:100px;
margin:0 auto;
margin-top:0px;
}
.text {
margin:15px;
}
/* -------------------------------
Главный контент
----------------------------------*/
#content #colLeft {
border: 0px solid #000;
float:left;
width:67%;
margin-right:0px;
background: #85c9cf;
}
/* -------------------------------
Сайтбар сайта
----------------------------------*/
#content #colRight {
position:relative;
margin-left:30px;
float:left;
width:30%;
border: 0px solid #1FA2E1;
background: #7a9e0e;
}
#middle:after {
content: '.';
display: block;
clear: both;
visibility: hidden;
height: 0;
}
/*----------------------------
Логотип
------------------------------*/
.logo {
position:absolute;
left:0px;
top:40px;
}
.logo a {
margin-left:30px;
font-size:30px;
color:#96b551;
}
Как вы заметили, ширина шаблона 1000 пикселей. В шаблоне используется width и max-width: о них написано выше.
У шапки ширина все таже — 1000 пикселей. У основного контента (#colLeft) ширина 67%, а у правой колонки — 30%. Отступ между ними 30 пикселей (3%).
Использование media screen
Стоит отметить, что в media screen задается нужное разрешение экрана устройства. Их очень много, можно указывать даже свои, но самые популярные: 320px, 480px, 600px, 768px, 1024px. В моем примере используется два разрешения: 768px и 1024px.
Таким образом выглядит тег media screen в CSS
@media screen and (min-width:200px) and (max-width:1024px) {
}
Как можно увидеть, мы используем максимальную ширину — 1024px. Данное свойство будет предаваться только тогда, когда ширина окна будет меньше 1024 пикселей.
1024 пикселя
Допустим, что наша цель — чуть-чуть сузить шаблон при этом разрешении, но основной контент и сайтбар должны оставаться на месте.
Вот, что необходимо прописать в CSS
@media screen and (min-width:100px) and (max-width:1024px) {
/* размер блока, где находятся главный контент и сайтбар*/
body #wrapper {
margin-top:40px;
width: 90%;
margin: 0 auto;
}
/* размер шапки сайта*/
body #headerInner {
width:90%;
margin:0 auto;
}
/* размер главного контента*/
#wrapper #content #colLeft {
width:67%;
}
/* размер сайтбара*/
#wrapper #content #colRight {
margin-left:3%;
width:30%;
}
} /* скобка, закрывающая тег @media screen
Шапка сайта (#headerInner) имеет новый размер в 90%. Стоит отметить, что для шапки мы не используем max-width, ибо он здесь не нужен. #wrapper — блок, в котором находится основной контент и сайтбар, его ширина тоже 90%. Ширина и сайтбара, и основного контента остаются неизменными, изменился лишь отступ у сайтбара (3%). Это используется для того, чтобы при уменьшение окна сайтбар не «падал» вниз.
768px
Теперь мы пишем настройки для окон, ширина которых 768 пикселей и меньше. Сейчас мы будем распологать сайтбар под основным контентом.
@media screen and (min-width:100px) and (max-width:768px) {
#wrapper #colLeft {
float:none;
width:100%;
margin-right:0px;
}
#wrapper #colRight {
margin-left:0px;
margin-top:25px;
float:none;
width:100%;
}
}
Для блока основного контента (#colLeft) мы указали ширину 100%, чтобы блок растянулся на весь экран. Также мы убрали выравнивание по левому краю, указав float: none, чтобы сайтбар (#colRight) «уплыл» под основной блок контента.
Для сайтбара ширина та же, а выравнивание по правому боку (float: right;) мы убрали. Ко всему этому, мы добавили отступ (margin-top: 25px;), чтобы эти два блока разделялись.
Для того, чтобы картинки также сужались нужно использовать этот код
img {
max-width: 100%;
height: auto;
width: auto\9; /* для ie8 */
}
9 основных принципов отзывчивого веб-дизайна / Habr
Отзывчивый дизайн — отличное решение проблемы корректного отображения сайта на разных экранах. Однако новичкам зачастую трудно понять основы, обучаясь только по книгам/статьям. С каждым днём появляется всё больше различных устройств, имеющих разные размеры экрана, поэтому создание дизайна в пикселях и только для настольных компьютеров/смартфонов остаётся в прошлом. Именно поэтому сейчас стоит изучить принципы отзывчивого дизайна — дизайна, совмещающего в себе адаптивность и резиновость (если вы ещё не знакомы с адаптивным дизайном, то эта статья будет хорошим выбором для начала изучения).
Отзывчивый vs Адаптивный веб-дизайн
Может показаться, что это одно и то же. Однако оба этих вида дизайна дополняют друг друга и подходят каждый для своей задачи.
Поток
Когда размер экрана уменьшается, содержимое страницы начинает занимать больше высоты, и элементы начинают смещаться вниз. Такое поведение называется потоком. Это может быть труднодоступным для понимания, если раньше вы использовали фиксированные размеры элементов. Однако, когда вы начнёте использовать поток, вы поймёте принцип его работы.
Относительные единицы измерения
Область просмотра страницы может быть монитором, экраном мобильного или чем угодно ещё. Плотность пикселей на разных экранах также разная, поэтому нам нужны гибкие единицы измерения, работающие везде. Отзывчивый дизайн — именно тот случай, когда относительные единицы измерения вроде процентов становятся действительно полезными. С помощью процентов мы можем задать блоку ширину в 50%, и на любом устройстве он будет занимать лишь половину экрана.
Контрольные точки (Breakpoints)
Контрольные точки позволяют менять расположение блоков на странице только в случае использования экрана с определёнными размерами. Например, на настольных компьютерах у сайта будет три колонки, а на мобильных — только одна. Как вы расставите контрольные точки, зависит от поведения контента. Если содержимое страницы «ползёт», то определённо следует добавить контрольную точку. Однако, контрольные точки следует использовать с осторожностью — вы можете в них запутаться.
Max- и min-значения
Контент, занимающий всю ширину экрана — это здорово, если он отображается на мобильном. А если вы откроете страницу через ваш телевизор? Вряд ли увиденная картина обрадует вас. Поэтому здравым решением будет использование минимальных и максимальных значений. Например, если задать блоку свойства `width: 100%` и `max-width: 1000px`, то он будет отображаться на весь экран, если ширина экрана меньше 1000 пикселей; в противном случае, блок будет занимать 1000 пикселей.
Вложенные объекты
Помните
position: relative? Если у вас будет много элементов, зависящих от расположения других элементов, то их будет тяжело контролировать. Намного проще и правильнее обернуть эти элементы в один контейнер. Кстати, это тот случай, когда статичные единицы измерения вроде пикселей помогут вам. Они полезны для содержимого, которое вы не хотите адаптировать к размеру экрана — например, это может быть логотип или кнопка.Desktop или mobile first
С технической стороны нет никаких отличий: вы можете писать базовую разметку для мобильных, и расставлять ключевые точки для десктопов (mobile first) и наоборот. Часто люди не знают, какой подход выбрать. Подумайте как следует и выберите подходящий вам подход.
Веб-шрифты vs системные шрифты
Хотите использовать на своём сайте круто смотрящуюся гарнитуру Futura или Didot? Используйте веб-шрифты! Хоть они и выглядят красиво, не стоит забывать, что каждый подключённый шрифт будет загружен. Соответственно, чем больше шрифтов, тем медленнее загружается страница. С другой стороны, системные шрифты загружаются моментально за исключением случаев, когда пользователь не имеет локально установленного шрифта, используемого на странице. В таких случаях браузер будет использовать шрифт по умолчанию.
Растровые vs векторные изображения
Имеет ли ваше изображение множество мелких деталей и впечатляющих эффектов? Если да, то используйте растровый формат. В противном случае используйте векторный формат. Для растровых изображений используйте форматы jpg, png или gif, для векторных лучшим выбором будут SVG и иконочные шрифты. Каждый из форматов имеет свои преимущества и недостатки. В любом случае, помните о размере изображений — ни одна картинка не должна попасть в онлайн, не будучи оптимизированной (сжатой). Векторные изображения зачастую избавлены от лишнего размера, однако они не поддерживаются старыми браузерами. Также стоит помнить, что если векторное изображение содержит много деталей, то оно может весить больше растрового.
Как сделать один сайт для всех устройств (Responsive Web Design) / Habr
Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»
Почему это глупо
Во-первых, никто не сможет предугадать, какими устройствами будут пользоваться ваши посетители. Нужно ориентироваться не на устройства, а на разрешения.
Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).
Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».
Как сделать один сайт для всех устройств
Вопросы, которые поднимал автор вышеуказанной статьи, уже довольно давно в цивилизованном мире обдуманы, и, более того, они уже решены.
Сейчас можно сделать 1 сайт с единственной версткой, который будет работать на устройствах, начиная с телефонов, заканчивая огромными телевизорами. Например, yiibu.com или alistapart.com (поуменьшайте окно браузера):
Все это называется «Responsive Web Design»
Responsive состоит из следующих техник:
Резиновый макет на основе пропорций (fluid grid)
Основная идея — формула для вычисления пропорций в процентах «target / context = result». Например, у нас есть макет psd с шириной 1000px. В нем есть два блока: один слева шириной 270px, другой справа 730px. Сверстаем мы их так:
.leftcolumn {
width: 27%; /* 270px / 1000px = 0,27 */
float: left;
}
.rightcolumn {
width: 73%; /* 730px / 1000px = 0,73 */
float: right;
}
Если внутри левого столбца будет еще один блок и, скажем, на макете он шириной в 170px, то для него поменяются цель и контекст, и код будет выглядеть вот так:
.leftcolumn .some-div {
width: 62,962963%; /* 170px / 270px = 0.62962963 */
float: left;
}
На хабре был перевод оригинальной статьи Ethan Marcotte «Fluid Grids».
Резиновые изображения (fluid images)
Подстраивают свои размеры под блок родителя. Основная идея в неочевидном применении свойства { max-width: 100% }. Изображение с img { max-width: 100% } никогда не вылезет из своего блока-родителя.
Если блок-родитель меньше, чем размеры img, то изображение пропорционально уменьшится. Этот принцип применим как для img, так и для embed, object, video.
Подробная оригинальная статья «Fluid Images».
Media queries
Нужны для отображения макета, оптимизированного под разрешение, с которого в данный момент этот сайт смотрится. Это часть стандарта CSS, которая позволяет применять стили на основе информации о разрешении устройства.
Например, так:
/* начало css */
Здесь базовые стили для глупых браузеров. Например, для телефонов не high-end уровня. Pocket Internet Explorer для Windows Mobile 6.5 здесь же :).
@media only screen and (min-width: 480px) {
Здесь стили более разумных, но все еще мобильных устройств. Android, iPhone и так далее.
}
@media only screen and (min-width: 768px) {
Планшеты в режиме portrait.
}
@media only screen and (min-width: 992px) {
Планшеты в режиме landscape, нетбуки, ноутбуки, десктоп.
}
@media only screen and (min-width: 1382px) {
Десктоп с большими разрешениями, телевизоры.
}
/* конец css */
media queries понимают все разумные браузеры. Для ie же есть Respond.js
Mobile first
Это техника, при которой сайт верстается сначала для устройств с меньшими возможностями, а затем с помощью media queries добавляются возможности и плюшки.
Так глупые браузеры без media queries получат самый простой контент (например, на мобильных телефонах). А более продвинутые поймут и отрисуют страницу, беря во внимание media queries.
Подробнее о Mobile first
Ссылки
1. Русскоязычный блог о Responsive Web Design
2. Единственная хорошая книга на эту тему — «Responsive Web Design». Написана Ethan Marcotte, который в общем и положил начало адаптивным макетам. После ее прочтения многое прояснится.
Чем тестировать адаптивный дизайн? / Habr
Хватит менять размер окна браузера, хватит его насиловать! Готов спорить, вы не раз слышали это. Хорошо, возможно и не слышали. Но если вы профессионально занимаетесь разработкой адаптивных сайтов, вы понимаете о чем я: любое изменение DOM или правка CSS, и вы снова начинаете тянуть край браузера вперед, назад, тестируя изменения и просматривая ничего ли не сломалось.
Целью ваших движений является имитация экранов различных устройств.
В корпоративной среде зачастую, у вас есть множество гаджетов предоставленных компанией для теста. На моей работе в моем распоряжении есть iPad, iPod, другие планшеты, ноутбуки, а также настольные мониторы. Если у вас нет такой роскоши, приходится использовать то, что под рукой.
К счастью, есть внушающий набор онлайн инструментов, имитирующих различные диагонали устройств. Конечно, каждый из них имеет свои преимущества и недостатки, мы рассмотри несколько таких инструментов.
Для тестирования я выбрал реально адаптивный сайт PajamasOnYourFeet.com, сайт построено на основе HTML5 шаблона, бесплатно предоставленным EGrappler.
Am I Responsive?
Am I Responsive, очень простой инструмент, позволяющий быстро просмотреть ваш сайт на 4 устройствах. Все они — IOS и разработчик объясняет это фишкой сайта. В общем никаких настроек, никакого выбора, а очень просто и наглядно.
Доступные размеры:
- настольный монитор — 1600 x 992px;
- ноутбук — 1280 x 802px;
- планшет — 768 x 1024px;
- мобильный телефон — 320 x 480px.
Цитирую разработчика: «это не инструмент для тестирования, крайне важно проводить тестирование на реальных устройствах. А данный инструмент поможет быстро сделать скриншот и показать клиенту, что вы имеете ввиду».
Есть две приятные фишки: возможность таскать устройства по вашему экрану, а также возможность поделится ссылкой на тест сайта.
deviceponsive
deviceponsive очень похож на Am I Responsive, тем, что он настолько же прост, с минимум настроек и опций. Все доступные устройства отображаются сразу на одной длинной странице. Из всех доступных опций это возможность отредактировать фон заголовка и добавить туда свой логотип, что будет полезно когда вы решите поделится скриншотом.
Устройства и доступные разрешения экранов.
- Macbook — 1280 x 800
- iPad портрет — 768 x 1024
- iPad портрет — 1024 x 768
- Kindle портрет — 600 x 1024
- Kindle альбомная ориентация — 1024 x 600
- iPhone портрет — 320 x 480
- iPhone альбомная ориентация — 480 x 320
- Galaxy портрет — 240 x 320
- Galaxy альбомная ориентация — 320 x 240
Как и на большинстве подобных инструментах отображаются полосы прокрутки, которых бы не было бы на реальных устройствах. Это вынужденный шаг для обеспечения возможности прокрутки на не сенсорных устройствах.
responsive test
Как и deviceponsive, responsive test отображает ваш сайт в различных устройствах. Но вместо показа всех сразу, вы сами выбираете необходимое устройство в верхнем меню страницы. Кстати тут корректно работает масштабирование, что позволяет проводить тестирование большего разрешения на меньшем.
30 различных разрешений доступно на сайте, начиная от огромного настольного монитора, до того, что они называют «дрянный андроид» (справедливости стоит заметить, что есть и нормальный андроид).
Что касается браузера Firefox, то он немного не корректно работает с данным сайтом. Обратите внимание, что на скриншоте не отображается слайдер между зеленым заголовком и белой областью фонового содержания.
responsive.is
Очень похож на предыдущих два инструмента, но есть одна вещь которая отличает responsive.is от других. Это плавная анимация при переходе от одного устройства к другому, а также полу-прозрачная область которая показывает реальную площадь сайта не попадающую в область просмотра.
Доступные варианты устройств — авто (то как вы видите сайт), настольный комьютер, планшет в альбомной и портретной ориентации, смартфон в портретной и альбомном положении. Задавать произвольные размеры в px, к сожалению нельзя.
Screenqueries
А вот возможности и доступные опции отличают Screenqueries от предыдущих сервисов. 14 телефонов и 12 планшетов представлены здесь, с отдельной возможностью переключения в портретный и альбомный режим. Результаты отображаются на сетке с линейками. Также возможно задать произвольное разрешение, потянув за правый или нижний край.
Интересной особенностью этого сайта, для ряда устройств есть “Trueview” вариант, который показывает ваш сайт в нативном браузере устройства.
К сожалению, Firefox и тут не смог отобразить слайдер. Не нужно обвинять меня, Firefox мой любимый браузер, но такие вот дела.
Screenfly
Screenfly пожалуй наиболее функциональный из всех. Доступно 9 больше чем планшет устройств — от 10″ ноутбуков, до 24″ мониторов, 5 планшетов, 9 телефонов, 3 телевизионных разрешения, а также произвольное разрешение. Добавьте сюда отдельный переключатель в портретный и альбомный режим, а также опцию показа прокрутки. Также можно поделится ссылкой на тест с помощью одной кнопки.
У каждого устройства в меню указано размер экрана в px., а также в правом верхнем углу отображается фактический размер вашего окна браузера.
Все перечисленные достоинства позволяют претендовать на лидерство если бы не одно но (цитата разработчика): «Screenfly может использовать прокси-сервер, чтобы имитировать устройства во время просмотра вашего сайта. Прокси-сервер имитирует строку агента пользователя, но не поведение этих устройств.» Screenfly является единственным сервисом из списка, который позволяет тестировать на основе строки агента пользователя.
Используете ли вы представленные инструменты в своей практике? Делитесь своими секретами разработки адаптивных сайтов в комментариях.
P.S. Ошибки по поводу перевода просьба сообщать в личку.
Адаптивный дизайн приложения под каждого пользователя / Habr
Я придерживаюсь мнения, что мобильные приложения должны быть более персонализированными. Какие-то функции мне не нужны, другие использую чаще. Но почему-то мы уравниваем всех под одну гребенку, чтобы по чуть-чуть, но угодить большему количеству людей. Чуть дальше в плане персонализации ушли новостные ленты и соц. сети, которые предоставляют уникальный каждому контент.А что если уйти еще дальше и помимо контента предоставлять людям персонализированный UI?!
Теория
Концепция
- Приложение само понимает, чем ты часто пользуешься и выносит часто используемую функциональность на первый экран.
- Располагает элементы по степени значимости на странице так, чтобы вам не нужно было бы тянуться большим пальцем до него.
- В зависимости от того насколько часто этот элемент используется, его содержание тоже будет сильно отличаться
- Так же есть триггеры: пришло пуш уведомление, определенная дата или действие пользователя. Этот триггер имеет свой удельный вес, который присваивается отдельному элементу на короткое время.
Логика
Этап калибровки
Человек пользуется приложением.
А программа сама анализирует количество кликов на каждый элемент и дает элементам удельный вес.
Этап плавного внедрения
После первоначальной калибровки, мы можем осторожно внедрять самый популярный запрос на главную страницу, отдельным блоком.
Этап проверки элемента
Мы анализируем частоту заходов и определяем достоин ли элемент того, чтобы остаться на главной странице.
И если достоин и им пользуются часто, то рассматриваем вариант расширения этой ячейки, для того, чтобы пользователь еще быстрее выполнил целевое действие.
Практика
Пример реализации приложения
Хороший пример это банковские приложения.
Почему?
- Они многофункциональные
- Большая часть функций мне как пользователю вообще не нужна, но другим они могут быть важней
- Некоторая часть функций может быть нужна, только в определенный момент
- Такими приложениями пользуются все, поэтому легче понять концепцию
Здесь я постараюсь показать на этапе эскизов как я вижу должно быть. Если пост будет интересен, то тогда я уже сделаю демо приложение на iOS.Грубый эксиз приложения
Сценарии
У каждого человека есть свои сценарии которые он выполняет. Они не всегда логичны, а задача приложения облегчить путь достижения этой цели.
Сценарий 1: Перевожу часто деньги одному и тому же человеку (младший брат, ребенок, жена).
Мы можем добавить блок с возможностью быстрого перевода именно ему.
Но блок сам по себе может эволюционировать, как покемоны. Если мы видим, что им достаточно часто пользуются.
2 уровень блока:
Здесь мы уже можем переводить непосредственно с самой ячейки, нажав на кнопку перевести
Приложение понимает что этой функцией не только пользуются часто, но еще и сумма одинаковая, поэтому мы идем еще дальше и изменяем ячейку так чтобы была установлена дефолтная для данной операции сумма.
3 уровень блока
Сценарий 2 Раз в месяц я плачу за квартиру, здесь уже срабатывает триггер даты.
Приложение понимает, что примерно в это число каждый месяц я отдаю деньги за квартиру.
И логично нам показать именно этот блок именно в этот день на главном экране и после исполнения платежа его убрать.
Сценарий 3 Закрываю кредит после получения зп.
Триггер. Я получил зп на карту и приложение понимает, что обычно после этого действия в течение дня или двух я закрываю кредит, который на мне висит.
В блоке теперь появляется оплата кредита.
Сценарий 4 Использую чат с поддержкой
Зачастую мы если переписываемся в чате с поддержкой, то этот процесс не быстрый, мы можем несколько раз свернуть приложение, заняться своими делами и вернуться позже, поэтому мы можем в период общения с чатом, его вынести на первый экран. Так как мы знаем когда он начала разговор и когда в принципе решил проблему.
Сценарий 5 Вывожу деньги с расчетного счета на карту
Срабатывает триггер о поступлении денег р/с и я допустим всегда распределяю их между своими картами:
Я хотел донести мысль, что пользовательский опыт можно улучшить, пытаясь помочь ему выполнить то, что он хочет как можно быстрей, конечно это будет сложнее для нас как разработчиков, но это будет оценено нашими клиентами. Cкажите, что вы думаете о таком подходе?
Адаптивный веб-дизайн vs. Отзывчивый веб-дизайн, в чем разница? / Habr
С тех пор, как вышли книги «Adaptive Web Design» Аарона Густафсона и «Responsive Web Design» Итана Маркотта (русское издание называется «Отзывчивый веб-дизайн»), в сообществе веб-дизайнеров и разработчиков ведутся споры о том, чем отличаются эти 2 подхода. Одни считают, что эти 2 понятия являются синонимами, а другие, что это совершенно разные понятия. Но, как известно, истина всегда где-то посередине, поэтому предлагаю вашему вниманию перевод статьи финского веб-дизайнера и разработчика Вильями Салминена (Viljami Salminen) «Adaptive vs. Responsive, what’s the difference?»:
Кажется, есть некоторая путаница относительно этих терминов и того, что они означают, так вот здесь мои мысли на данную тему и несколько ссылок, чтобы подкрепить их. Я, как правило, не очень пылкий, когда дело доходит до обсуждения чего-либо, но на этот раз я хотел бы внести в этот вопрос ясность, т.к. слышу его очень часто.
«Отзывчивый веб-дизайн» (Responsive Web Design) является частью более широкого понятия, которое называется «Адаптивный веб-дизайн» (Adaptive Web Design). Когда идет речь об отзывчивом веб-дизайне, то мы имеем в виду только макет веб-страницы (Итан Маркотт, «резиновый» макет, гибкие изображения и медиазапросы).
С другой стороны, «Адаптивный веб-дизайн» включает в себя гораздо больше, чем просто «резиновый» макет. На практике это почти одно и то же, что и прогрессивное улучшение (progressive enhancement), если говорить кратко, то это понятие означает, что мы стремимся предоставить лучшие возможности для максимально широкой аудитории. Также: нельзя смешивать понятия «Адаптивный веб-дизайн» и «Адаптивный макет» (Adaptive layout), т.к. это совершенно разные вещи.
И, наконец, «Адаптивный макет» означает макет, сделанный путем сочетания множества фиксированных горизонтальных размеров (ширины). Сейчас, мне кажется, если все сделано правильно и блоки фиксированной ширины сочетаются с «резиновыми» блоками, то Адаптивный макет можно считать одной из форм отзывчивого веб-дизайна, а не просто его альтернативой. Зельдман уже высказывал немного похожую идею в 2011 году в одной из записей своего блога.
Примечание переводчика. К сожалению, из текста Вильями Сальминена сложно понять, что такое «Адаптивный макет», поэтому я постараюсь объяснить, что это означает своими словами. Подход Итана Маркотта предусматривает использование «резинового» макета (ширина, отступы и поля задаются в процентах), а адаптивный макет предполагает, что для каждого размера экрана у нас используются свои стилевые правила, в которых жестко заданы фиксированные размеры элементов (в пикселях). Более развернутое описание данного подхода вы можете найти в статье «Switchy McLayout: An Adaptive Layout Technique» (перевод).
Ссылки
Update v1. Если моя статья сделала эти 2 понятия более сложными для восприятия, чем они есть на самом деле, то постараюсь объяснить все в двух словах: отзывчивый веб-дизайн является частью адаптивного. Отзывчивый веб-дизайн = «резиновый» макет, в то время как адаптивный веб-дизайн = «резиновый» макет + прогрессивное улучшение.