000
ОтложитьЧитал
Прогрессивное улучшение
В 2003 году фестиваль South by Southwest в Остине, штат Техас, был в первую очередь мероприятием для музыкантов и кинематографистов. Сегодня музыкальная и кинематографическая части затмевают по значимости South by Southwest Interactive, посвященный всему цифровому. В 2003 году South by Southwest Interactive была небольшим мероприятием, втиснутым в один угол одного этажа Остинского конференц-центра. Это был шанс для нескольких веб-дизайнеров и блоггеров собраться вместе и обменяться идеями. В тот год Стивен Чампеон и Ник Финк представили доклад под названием "Инклюзивный веб-дизайн для будущего с прогрессивным улучшением". В начале доклада они обратились с призывом к оружию:
«Веб-дизайн должен созреть и принять развитие последних нескольких лет, отказаться от отчужденного отношения, сформировавшегося в эпоху грубости и беспорядка доткомов, осознать грядущее будущее широкого разнообразия устройств и платформ и отделить семантическую разметку от логики представления и поведения.»
Как и Тим Бернерс-Ли, Стивен Шампеон имел опыт работы с SGML, языком разметки, который оказал сильное влияние на HTML. Работая с документами, которые необходимо было перепрофилировать для различных целей, он понял, как важно отделять структуру от представления. Осмысленно размеченный документ может быть представлен множеством способов с помощью CSS и JavaScript.
Такой многоуровневый подход к Интернету позволяет предоставлять один и тот же контент широкому кругу людей. Но это не означает, что все получают одинаковые впечатления. В Champeon поняли, что четкое разделение задач позволит применять улучшения в соответствии с возможностями устройства конечного пользователя.
Перефразируя Карла Маркса, прогрессивное улучшение позволяет дизайнерам требовать от каждого браузера в соответствии с его возможностями и предоставлять каждому устройству в соответствии с его потребностями.
Должны ли веб-сайты выглядеть одинаково в каждом браузере?
Некоторые веб-дизайнеры опасались, что прогрессивное улучшение станет творческой смирительной рубашкой. Проектирование для наименьшего общего знаменателя не похоже на рецепт прогресса. Но это было заблуждение. Прогрессивное улучшение требует, чтобы дизайнеры начинали с самого низкого общего знаменателя (хорошо размеченного документа), но нет предела тому, куда они могут двигаться дальше.
На самом деле, именно наличие прочной основы HTML позволяет веб-дизайнерам экспериментировать с новейшими и лучшими CSS. Благодаря закону Постеля и свободной модели обработки ошибок в CSS дизайнеры могут свободно применять стили, которые работают только в новейших браузерах.
Это означает, что не у всех будет одинаковый визуальный дизайн. Это не ошибка. Это особенность Интернета. Новые браузеры и старые браузеры; монохромные дисплеи и многоцветные дисплеи; быстрые соединения и медленные соединения; большие экраны, маленькие экраны и отсутствие экранов – все могут получить доступ к вашему контенту. Этот контент должен выглядеть по-разному в таких разных ситуациях. Если веб-сайт выглядит одинаково как в браузере десятилетней давности, так и на новейших устройствах, то, скорее всего, он не использует преимущества большой гибкости, которую предлагает Интернет.
Чтобы подчеркнуть это, дизайнер Дэн Седерхолм создал веб-сайт, чтобы ответить на вопрос: "Должны ли веб-сайты выглядеть одинаково в каждом браузере?". Ответ на этот вопрос вы можете найти по адресу URL:
dowebsitesneedtolookexactlythesameineverybrowser.com
Рискуя испортить вам сюрприз, ответом будет громкое "Нет!". Если вы посетите этот сайт, вы увидите этот ответ, гордо вывешенный на экране. Но в зависимости от возможностей вашего браузера, вы можете увидеть или не увидеть некоторые стилистические изыски, примененные к этому однословному ответу. Даже если вы не увидите никаких стилей, вы все равно получите содержимое, размеченное с помощью семантического HTML.
Cut the Mustard (
Разрезание
горчицы
)
Разделение структуры и представления относительно простое. Вы можете объявлять любые стили, какие захотите, будучи уверенными в том, что браузеры проигнорируют то, что им непонятно. Разделить структуру и поведение не так просто. Если вы дадите браузеру JavaScript, который он не понимает, он не только не применит желаемое поведение, но и откажется разбирать остальную часть JavaScript.
Прежде чем использовать ту или иную функцию JavaScript, стоит проверить, поддерживается ли она. Такое обнаружение функции может уберечь посетителей вашего сайта от проблем из-за неподдерживаемой функции. Если вы хотите использовать Ajax, сначала проверьте, поддерживает ли браузер объект, который вы собираетесь использовать для включения этой функции Ajax. Если вы хотите использовать API геолокации, сначала проверьте, поддерживает ли его браузер.
Команда веб-разработчиков, работающая над новостным сайтом BBC, назвала этот вид обнаружения функций " разрезание горчицы". Браузеры, которые отрезают горчицу, получают улучшенный опыт. Браузеры, которые не отрезают горчицу, по-прежнему получают доступ к контенту, но без улучшений JavaScript.
Обнаружение особенностей, отрезание горчицы, как бы вы это ни называли, является довольно простой техникой. Допустим, вы хотите обойти DOM с помощью querySelector и прикрепить события к некоторым узлам в документе с помощью addEventListener. Ваша логика разрезания горчицы может выглядеть примерно так:
if (document.querySelector && window.addEventListener) {
// Enhance!
}
Здесь следует отметить два момента:
Это определение функции, а не браузера. Вместо того чтобы спрашивать "какой у вас браузер?" и пытаться сделать вывод о поддержке функции из ответа, безопаснее просто спросить "поддерживаете ли вы эту функцию?".
Другого утверждения не существует.
Агрессивное улучшение
В те времена, когда веб-дизайнеры пытались контролировать браузеры, как печатные издания, успешный дизайн измерялся пиксельным совершенством: выглядел ли сайт одинаково в каждом браузере?
Если каждый браузер не поддерживал определенную функцию – скажем, закругленные углы в CSS, – то эта функция была недоступна. Вместо этого дизайнеры имитировали ее с помощью дополнительной разметки и изображений. В результате веб-сайтам не хватало структурной честности. Это была не только пустая трата таланта и сил дизайнеров, но и возможностей современных веб-браузеров.
Появление мобильных устройств, планшетов и отзывчивого дизайна помогло ослабить это ограничивающее мышление. Теперь уже нереально ожидать пиксельно идеального паритета между устройствами и браузерами. Однако до сих пор можно встретить веб-дизайнеров, сетующих на то, что им приходится поддерживать устаревший браузер, потому что часть их аудитории все еще пользуется им.
Они абсолютно правы. Тот, кто пользуется старым браузером, должен иметь доступ к тому же контенту, что и пользователь новейшего и лучшего веб-браузера. Но это не значит, что они должны получать одинаковые впечатления. Как сказал Брэд Фрост:
«Существует разница между поддержкой и оптимизацией.»
Поддерживайте все браузеры … но не оптимизируйте все.
Некоторые дизайнеры неправильно понимают прогрессивное улучшение, считая, что все функциональные возможности должны быть предоставлены каждому. На самом деле все наоборот. Прогрессивное улучшение означает предоставление основной функциональности для всех. После этого каждый браузер сам за себя. Прогрессивное улучшение не ограничивает возможности использования функций, а предоставляет веб-дизайнерам возможность безопасно использовать новейшие и лучшие функции, не беспокоясь о старых браузерах. Скотт Джел из агентства Filament Group выразил это кратко:
«Прогрессивное улучшение позволяет нам сосредоточиться на затратах на создание функций для современных браузеров, не беспокоясь о том, что мы кого-то оставим без внимания. При наличии квалифицированной кодовой базы поддержка старых браузеров предоставляется почти бесплатно.»
Если сайт создан с использованием прогрессивного улучшения, то ничего страшного, если какая-то функция не поддерживается или не загружается: Ajax, геолокация, что угодно. До тех пор, пока основная функциональность остается доступной, веб-дизайнерам не нужно изгибаться, пытаясь впихнуть поддержку новых функций в старые браузеры.
Вы также получаете сайт, более устойчивый к модели обработки ошибок JavaScript. Мат Маркиз работал вместе со Скоттом Джелом над отзывчивым веб-сайтом для газеты Boston Globe. Он отметил:
«Множество классных функций в Boston Globe не работают, когда JS ломается; "чтение новостей" – не одна из них.»
Сложность заключается в том, чтобы определить, что считать основной функциональностью, а что – расширением.
Рекомендации
Inclusive Web Design For the Future with Progressive Enhancement by Steven Champeon and Nick Finck
Do websites need to look exactly the same in every browser? by Dan Cederholm
Support vs Optimization by Brad Frost
The Pastry Box by Scott Jehl
Глава 6: Шаги
"Всегда проектируйте вещь,
рассматривая ее в следующем, более широком контексте", – говорил финский архитектор Элиэль Сааринен. "Стул в комнате, комната в доме, дом в окружении, окружение в плане города".
На первый взгляд, веб-дизайн является разновидностью графического дизайна. Использование инструментов графического дизайна, таких как Photoshop, для разработки веб-сайтов укрепляет эту точку зрения. Но чтобы понять суть предназначения веб-сайта, мы должны рассматривать интерфейс в более широком контексте: чего люди пытаются достичь?
При разработке дизайна для Интернета очень соблазнительно думать о таких видах взаимодействия, как пролистывание, касание, нажатие, прокрутка, перетаскивание и опускание. Но очень немногие люди просыпаются утром, предвкушая день пролистывания и простукивания. Они скорее думают о том, как читать, писать, делиться, покупать и продавать. Веб-дизайнеры должны видеть не только поверхностные действия, но и находить под ними более значимые глаголы.
В своей книге Designing With Progressive Enhancement группа Filament Group описывает технику, которую они называют “the x‐ray perspective”( рентгеновской перспективой ):
«Использование рентгеновской перспективы означает просмотр сложных виджетов и визуальных стилей дизайна, определение основного контента и функциональных частей, составляющих страницу, и поиск простого HTML-эквивалента для каждого из них, который будет работать универсально.»
Если вы не привыкли к такому подходу к веб-дизайну, к нему нужно привыкнуть. Но через некоторое время это войдет в привычку, и тогда будет трудно не рассматривать интерфейсы таким образом. Это все равно, что пытаться не замечать плохого кернинга, или не видеть стрелку в белом пространстве логотипа FedEx, или не помнить, что все утки на самом деле носят собачьи маски.
Клюв этой утки похож на морду собаки.
Фотография Асмаа Ди.
Под лицензией Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic.
Вот трехэтапный подход, который я использую в веб-дизайне:
Определите основную функциональность.
Сделайте эту функциональность доступной, используя максимально простую технологию.
Улучшайте!
Определение основной функциональности может показаться довольно простым делом, и после некоторой практики так оно и есть. Но поначалу может быть сложно отделить то, что действительно необходимо, от того, что приятно иметь.
Информация
Допустим, вы поставщик новостей. Это и есть основная функциональность – предоставлять новости. Есть много, много других услуг, которые вы также можете предоставить; интерактивные головоломки, уведомления в реальном времени и многое другое. Какими бы ценными ни были эти услуги, они, вероятно, не так важны, как обеспечение доступа людей к новостям.
Подборка новостных изданий.
Когда основная функциональность определена, пора переходить ко второму шагу: как сделать эту основную функциональность доступной с помощью максимально простой технологии?
Теоретически, простой текстовый файл был бы самым простым возможным способом предоставления новостей. Но поскольку мы говорим именно о веб-технологиях, давайте сделаем оговорку: как сделать основную функциональность доступной с помощью максимально простой веб-технологии? Это может быть HTML-файл, передаваемый по URL.
Даже на этой ранней стадии можно все переусложнить. HTML может быть излишне раздутым. URL может быть излишне многословным; его трудно передать или запомнить.
Теперь, когда новости были размечены с помощью соответствующих элементов HTML – статей, заголовков, абзацев, списков и изображений – пришло время для третьего шага: улучшить!
По умолчанию новости будут представлены с использованием собственной таблицы стилей браузера. Это разборчиво, но не совсем приятно. Применив собственный CSS, вы можете придать содержимому более приятную форму. В вашем распоряжении пробелы, выравнивание, цвет и контраст. Вы даже можете использовать пользовательские шрифты – улучшение, которое было невозможно в Интернете в течение многих лет.
Нет никакой гарантии, что каждый браузер сможет выполнить все правила CSS, которые вы ему подкинете. Это нормально. Эти браузеры будут игнорировать то, что они не понимают. Важно, что новости по-прежнему доступны для всех, независимо от возможностей CSS в их браузере.
Для браузеров на устройствах с большим экраном можно внедрить макет. Поначалу может показаться странным рассматривать верстку как улучшение, но в этом и заключается урок мобильного отзывчивого дизайна. Сначала рассмотрите содержимое, затем разметьте его с помощью разумного порядка исходного текста, а затем примените декларации верстки в медиа-запросах.
Благодаря постоянно развивающейся природе CSS, существует множество способов применения макета. Как сказал Энди Таненбаум:
«Самое приятное в стандартах то, что у вас есть из чего выбрать..»