Нельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

Graceful degradation может выражаться в возможности работы при отключенном JavaScript, в достаточно аккуратном отображении интерфейса в браузере, не поддерживающем новые свойства CSS3, в адекватном отображении сайта при отключенных изображениях. В каждом из этих случаев работа пользователя с интерфейсом будет в принципе возможна, хотя и не так удобна.

Что же такое progressive enhancement? Чаще всего этот термин переводят, как прогрессивное улучшение. Прогрессивное улучшение предполагает, что веб-интерфейсы должны создаваться поэтапно, циклически, от простого к сложному. На каждом из этапов должен получаться законченный веб-интерфейс, который будет лучше, красивее и удобнее предыдущего. Можно сказать, что сейчас таких этапов четыре:

1. «Старый-добрый-HTML» этап
2. CSS этап
3. CSS3 этап
4. JavaScript этап

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

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

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

На четвёртом этапе до ума доводится процесс взаимодействия с интерфейсом: различные AJAX решения, динамические элементы, те же календарики и так далее. Тут во всю используется JavaScript. Этот этап отвечает за удобство.

Резюмируем назначение описанных этапов:

1. Смысл документа, логическая разметка. Технология: HTML.
2. Внешний вид. Технология: CSS.
3. Безупречный внешний вид. Технология: CSS3.
4. Взаимодействие, интерактивность, удобство. Технология: JavaScript.

Можно сказать, что веб-интерфейс, созданный добросовестно и качественно, в соответствии с подходом graceful degradation, будет вести себя так же, как и веб-интерфейс, построенный в соответствии с progressive enhancement. То есть, progressive enhancement — это не что иное, как graceful degradation, доведенный до совершенства. Всё же отметим ключевые различия этих понятий:

• Graceful degradation — более широкое понятие, чем progressive enhancement, который ограничен только веб-интерфейсами. Progressive enhancement — это наше, родное, вебовское.
• Progressive enhancement задает вектор движения (начинай с простого!), а для graceful degradation это не так важно.
• Progressive enhancement настаивает на важности содержания, а для graceful degradation оно на втором плане.

В общем, progressive enhancement — это более строгая и последовательная идеология разработки веб-интерфейсов.

Почему появился Progressive Enhancement

Ранее говорилось, что если взять и в соответствии с graceful degradation максимально качественно сделать веб-интерфейс, то получится то же самое, что и при применении progressive enhancement. Так зачем же было придумывать этот enhancement?

Ответ прост: мало кто делал graceful degradation очень качественно. Это расстраивало действительно высококлассных и ответственных разработчиков. Ведь сказать, что «я — молодец и делаю graceful degradation» мог почти любой, но затраты сил и времени у разных разработчиков различались на порядки.

В самом простом случае плохого graceful degradation делается сайт для самых современных браузеров, а для устаревших в верхней части страницы добавляется сообщение, что браузер староват. При этом никого не волнует, что будет происходить с сайтом в старом браузере: развалится он или нет, будет виден весь контент или что-то исчезнет. Другой распространенный вариант плохого graceful degradation — интерфейс перестает работать при отключенном JavaScript. Простой пример: попробуйте отправить сообщение во ВКонтакте при отключенном JavaScript.

Короче говоря, такая халтура с отказоустойчивостью порядком надоела «правильным» разработчикам, надо было что-то делать. Progressive enhancement возник как реакция на плохой graceful degradation. Теперь действительно хорошие разработчики и дизайнеры могут делать progressive enhancement, а плохие не могут, так как это сложнее и трудозатратнее. Заодно новый подход впитал в себя все лучшие практики из graceful degradation.

Практический пример

Мы разобрались с тем, что такое progressive enhancement, теперь пришло время на практическом примере продемонстрировать, как этот подход применять в жизни. Разработаем и оформим простую форму авторизации в соответствии с ним.

На первом этапе создадим форму с помощью чистого HTML. Да, форма не так красива, зато функциональна.

На втором этапе c помощью простейшего CSS сделаем форму красивее: добавим фон, размеры, отступы.

На третьем этапе используем некоторые новые CSS свойства, чтобы придать форме блеск. Добавим закругления с помощью border-radius, тени для элементов с помощью box-shadow, используем css-градиенты для оформления кнопки и так далее. Используем некторые продвинутые селекторы, чтобы избавиться от лишних отступов.

На четвёртом этапе с помощью JavaScript можно было бы сделать AJAX-отправку формы, чтобы пользователь мог залогиниться без перезагрузки страницы. К сожалению, динамическое поведение нельзя продемонстрировать с помощью скриншота.

На простейшем примере мы показали, как работает подход progressive enhancement. Кстати, данный пример можно «пощупать вживую» в интерактивной демонстрации на htmlacademy.

Чтобы понять, как работает graceful degradation, просто просмотрите шаги в примере в обратном направлении. Возникает вопрос — можно ли для этого примера сделать graceful degradation плохо? Конечно, да! Например, если бы верстальщик размышлял вот так:

“

Логиниться будем с помощью AJAX, значит с формой заморачиваться не надо, использую div. Круглые уголки и тенюшки... Это проблема. Для полей ввода использую input без границ, а фоном задам картинку с рамкой и тенями. Кнопку сделаю с помощью div, на фон повешу картинку кнопки с градиентом и тенями. Классно! И в старом IE будет красиво смотреться, и всего несколько картинок вырезать.

Какие проблемы возникнут при таком подходе? Во-первых, при отключенном JavaScript залогиниться будет невозможно, так как формы нет и данные не отправить. Во-вторых, при отключенных изображениях формы не будет видно, так как внешний вид полей задан исключительно с помощью изображений. Остаётся надеяться, что такие верстальщики уже вымерли.

Progressive Enhancement и Responsive Design

В последнее время набирает популярность подход, который называется responsive design, по-русски адаптивный или отзывчивый дизайн. Суть подхода заключается в том, чтобы с помощью определенного набора техник (резиновые сетки, резиновые изображения, CSS media queries) сделать так, чтобы веб-страница адекватно отображалась на различных устройствах: от смартфона до широкоформатного монитора. Это достигается за счет динамического изменения сетки страницы, размеров элементов и так далее.

Одновременно появился похожий подход, который называется mobile first. На русский его название можно перевести, как «сначала для мобильников!». По сути, это тот же адаптивный дизайн, но с обязательным требованием: всегда начинать проектирование адаптивного интерфейса с мобильной версии.

Соотношение подходов responsive design и mobile first очень похоже на соотношение graceful degradation и progressive enhancement. Первый подход в паре общий, а второй подход частный и добавляет к первому дополнительные требования: «начинай с простого html», «начинай проектировать с мобильной версии», «погладь кота».

Стоит отметить, что озвученные подходы отлично сочетаются друг с другом и отлично друг друга дополняют. И в скором будущем все топовые исполнители будут заявлять: «Мы делаем mobile first + progressive enhancement».

Зачем вы это прочитали

Зная об этом подходе и понимая его работу, вы можете ставить задачи исполнителю более корректно. Применение progressive enhancement разработчиками вашего сайта сэкономит вам и деньги, и время.

Оригинал: http://serenity.su/blog/post/33636043528/progressive-enhancement

Захар Наханов
Технический директор в AREALIDEA

Автор описал хорошее решение для заказчика, который располагает временем и средствами, для реализации этих подходов и заранее готов платить за имидж. Реализация сайта в полном соответствии с данными требованиями значительно увеличит стоимость и время разработки. На выходе будет результат в виде — «А посмотрите какой у нас крутой сайт, и даже без Javascript работает!» Хотя в реальности такой сайт будет продавать ничуть не лучше сайта, который не умеет работать без Javascript’a. Почему? Потому что доля пользователей, не использующих Javascript менее 1%, и, наверняка, это не ваша целевая аудитория. То же касается и старых, редко используемых, браузеров вроде IE6 или IE7. Стоимость верстки без них будет существенно меньше, а результат, который покажет сайт, тем же. Конечно, при этом сайт в этих браузерах не превращается в не пойми что, а имеет вполне читабельный вид. Пользователям же без Javascript доступен базовый функционал и выводится предложение его включить. 

Немного коснемся и подхода «mobile first». Многие клиенты еще думают о десктопных версиях и не готовы реализовывать сразу же и мобильную версию, как правило, она у них в планах на будущее, когда сайт уже покажет себя, так как адаптивная верстка требует больше усилий и более высокой квалификации верстальщика, что ведет к увеличению стоимости. Конечно, в будущем у данного подхода есть потенциал, когда сайт без мобильной версии будет неконкурентоспособным. Пока же для большинства клиентов будет достаточно и более простых реализаций мобильной версии. 

В общем и целом, я — за золотую середину. Пользователям старых браузеров выводится предложение об их обновлении, но они могут работать с сайтом в простом оформлении или без некоторых элементов интерфейса, а пользователям без Javascript доступен только базовый функционал. Реализация мобильной версии каждый раз обсуждается отдельно.
 

Максим Степанов
Руководитель группы разработчиков в AGIMA

Это все замечательно и классно, но только для портфолио программиста (just for fun), на практике такое практически невозможно. Как правило, заказчику важен сам результат, а не процесс работы, верстки. Ему нужно, чтобы по итогу все работало так, как было расписано в ТЗ, который он подписывал.

Вторая проблема этого подхода — это сроки разработки. Ради 0,5-1% посетителей сайта с IE5 приходится либо отказываться от каких-то интересных и красивых задумок дизайнера, либо тратить огромное количество времени на доработку функционала/верстки. Возникает вопрос: «А стоит ли овчинка выделки?».

Третья проблема — совместимость или прогресс. Самый яркий пример: Microsoft и Apple. Microsoft делает упор на совместимость, но в ущерб прогрессу. Apple же прогрессирует в ущерб совместимости. Вся эта совместимость тащит за собой миллионы строк лишнего кода для поддержки старого оборудования, старых технологий и старого ПО. На двух стульях усидеть невозможно.

Неужели еще существуют устройства, не поддерживающие JavaScript? В таком случае, какова глубина этого «Progressive Enhancement»? С какого года нужно начинать улучшаться? Можно начать с поддержки черно-белых мониторов и текстовых браузеров...

Каждый проект индивидуален, у каждого проекта свои цели и своя целевая аудитория. Кому-то важны эти 0,5-1% посетителей, особенно если их в количественном выражении более сотни в день, а для кого-то эти 0,5-1% — всего лишь 1 посетитель в день, да и тот сам разработчик/тестировщик. Все нужно взвешивать, продумывать и анализировать. Можно также подходить к вопросу комплексно: какая-то часть проекта (страница/модуль) будет разрабатываться с учетом Progressive Enhancement, а какая-то часть — через Graceful Degradation. На одной идее далеко не уедешь, за идейность и за раздутые сроки платить не будут. А преимуществом это будет являться только для «своих».