В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдём к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.

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

Так как весь вопрос, как обычно, во временных затратах и стоимости, то в этой статье мы рассмотрим «прогрессивное улучшение vs обычная разработка» с точки зрения дополнительных временных затрат. Как и в предыдущей статье, делать это будем поэтапно.

«Старый-добрый-HTML»

На этом этапе верстальщик создаёт логичную и семантически правильную HTML-разметку без использования CSS. Никаких дополнительных временных затрат на этом этапе не возникает. Естественно, некоторым верстальщикам удобнее создавать HTML-код и одновременно набрасывать стили. Прогрессивное улучшение не запрещает этого: пожалуйста, пишите и стили, но сначала уделите пристальное внимание разметке.

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

«CSS»

Важное замечание: прогрессивное улучшение не имеет ничего общего с вёрсткой под Internet Explorer 6. вёрстка под IE6 — который не просто не поддерживает стандарты, а поддерживает их неправильно — это отдельная задача, которая у многих исполнителей так и называется — «вёрстка под IE6» и оценивается дополнительно. Таким образом, поддержка IE6 вносит дополнительные затраты при любом подходе. Если клиент хочет заплатить за это — пожалуйста, а если нет, то и не надо ему это втюхивать.

Для тех, кто настаивает на поддержке IE6, приведу аналог с кодировками. Раньше создавалось несколько версий сайта, заточенных под разные кодировки, например, KOI8-R и Windows-1251. Сейчас так уже не делают, хотя, при желании можно раскопать и запустить Очень Старый Компьютер с Очень Старой Виндовс. Так может быть уже пора забыть IE6 как страшный сон?

Что касается других старых браузеров, которые корректно поддерживают CSS2, то в них сайт будет смотреться прилично. Под старинный Firefox 3 в далёком 2008 году верстать было легко и приятно.

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

«CSS3»

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

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

Все это ведёт к огромной экономии времени. И как бонус — верстальщик начинает получать удовольствие от работы, потому что избавляется от рутины и одновременно получает простор для творчества и экспериментов. Ведь сэкономленное время можно тратить на другие проекты, а можно и экспериментировать с новейшими свойствами на текущем проекте, добавляя wow-фичи для пользователей новых браузеров.

Подведём итог: на третьем этапе прогрессивное улучшение даёт существенную экономию времени разработчика.

«JavaScript»

Этот этап самый спорный и самый интересный, поэтому на нём остановимся более подробно и разберём несколько практических примеров.

Вначале небольшая оговорка: мы не будем рассматривать сайты, работа которых без JavaScript в принципе невозможна или теряет всякий смысл, например: HTML Academy, различные онлайн-редакторы и так далее.

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

Различные ситуации, возникающие на этом этапе, лучше разбирать на практических примерах.

Пример 1. Форма «Заказать звонок»

Задача: «На каждой странице сайта есть ссылка „Заказать звонок“, при щелчке на которую всплывает форма обратного звонка с оверлеем».

Задача была решена в соответствии с прогрессивным улучшением следующим образом:

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

Что мы получили в итоге? Форма существует в теле страницы и всегда доступна в «голом-HTML-режиме». При наличии CSS форма спрятана, не ломает сетку и умеет отображаться при наведении. Реализация такого поведения на чистом CSS имеет свои минусы, но форма остаётся доступной. С помощью JavaScript отображение и поведение формы приводится к желаемому идеалу.

Дополнительные временные затраты в данном примере минимальны. К необходимой JavaScript-логике нужно дополнительно добавить навешивание дополнительных классов на форму и добавление в HTML-кода для оверлея. Это и есть то самое усложнение инициализации скрипта.

Пример 2. Форма поиска отелей

Этот пример описан в посте про Graceful Degradation. Задача заключалась в том, чтобы сделать форму поиска отелей работающей без JavaScript. Для этого пришлось дорабатывать не только клиентскую часть, но и усложнять серверную. Сервер научился отличать запросы на подгрузку локаций от поисковых запросов.

В этом примере дополнительные временные затраты уже более существенны. В общей сложности они составили примерно рабочий день. Оправданы ли они? Отметим два момента:

  1. Важность формы. Работа с сайтом практически всегда начинается с поиска отеля.
  2. Важность фильтрации по месторасположению: отели часто ищут в конкретном городе или даже в конкретном районе.

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

Пример 3. Конструктор пиццы

Задача заключается в том, чтобы сделать сайт, на котором можно заказать себе пиццу. Причём пиццу можно заказывать как в «изначальной комплектации», так и в изменённой: выбирать тесто, менять соус, добавлять добавки. Доработка пиццы производится в специальном конструкторе.

Задача была решена в соответствии с прогрессивным улучшением следующим образом:

  1. При щелчке на ссылку «Заказать онлайн» в корзину добавляется пицца в исходном варианте.
  2. Если JavaScript работает, то при щелчке на ссылку появляется конструктор, в котором можно выбрать тесто, соус, добавки, после чего уже доработанную пиццу можно добавить в корзину. Вот примеры интерфейса:
Пример интерфейса
Пример интерфейса

При таком решении, как вы заметили, доработка пиццы с помощью конструктора возможна только при работающем JavaScript. Сделать этот же конструктор работающим без JavaScript будет достаточно долго и дорого. А стоит ли? В этом случае, скорее всего, не стоит, потому что:

  1. Базовым функционалом для подобных сайтов является возможность положить в корзину понравившуюся пиццу. После оформления заказа клиенту перезванивает оператор, который уточняет детали заказа, доставки и т. д. То есть клиент всегда может «оттюнинговать» свою пиццу с помощью оператора.
  2. JavaScript отключён у малого процента пользователей, а подобный функционал будет достаточно дорог и затянет сроки (и другие типовые аргументы против прогрессивного улучшения).

Как видите, и в рамках прогрессивного улучшения можно отказываться от реализации дополнительного функционала на «чистом HTML», что сэкономит и время, и деньги.

Но! Если вдруг заказчик посчитает конструктор критичным и захочет, чтобы он работал и без JavaScript? Это всегда можно сделать за дополнительную оплату. Ключевой момент заключается в том, чтобы не включать стоимость таких доработок в изначальную оценку.

Вывод по примеру: прогрессивное улучшение надо применять грамотно, без фанатизма. Если появляются серьёзные дополнительные затраты, то пусть они появляются по осознанной воле клиента, а не по глупости разработчика. Или, проще говоря, не надо втюхивать эти дополнительные затраты клиенту только потому, что «так вроде правильно по прогрессивному улучшению».

Подведём итог: на четвёртом этапе прогрессивное улучшение в большинстве случаев приводит к незначительным дополнительным временным затратам. В некоторых случаях затраты существенны. Ещё раз подчеркнём, что прогрессивное улучшение требует, чтобы всегда был доступен только базовый функционал. А реализовать базовый функционал без JavaScript в большинстве случаев не так затратно.

Итого

Дополнительные временные затраты при применении прогрессивного улучшения на каждом из этапов:

  1. HTML этап — отсутствуют;
  2. CSS этап — отсутствуют;
  3. CSS3 этап — экономия времени;
  4. JavaScript этап — присутствуют, но незначительные.

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

Однако, чтобы прогрессивное улучшение работало эффективно, необходимо наличие двух условий:

  1. Высокая квалификация и опыт разработчиков. Нельзя с первого раза сделать все быстро и качественно. Сначала нужна практика. Но ведь и применять ООП в PHP все тоже долго и мучительно учились.
  2. И заказчик, и разработчик должны смириться с тем фактом, что сайт в некоторых браузерах, особенно старых, будет выглядеть «хуже» (а в IE6 даже разваливаться).

Вывод: прогрессивное улучшение — это хороший прагматичный подход, который позволяет разрабатывать интерфейсы быстрее и качественнее. И ничего общего с перфекционизмом прогрессивное улучшение не имеет.

В заключение о грустном

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

Проблема с кадрами на рынке остра. Трудно найти хорошего программиста, но и хороший верстальщик — рыба очень редкая. Взяться им особо неоткуда, так как даже в ведущих ИТ-вузах страны хороших верстальщиков не готовят, да и не ставят себе такую цель. Есть надежда, что новые ФГОСы с их компетентностным подходом и ориентацией на рынок помогут улучшить ситуацию. А пока — остаётся выращивать хороших специалистов самим.

✔ ✅ ❌ ❓🔥🕸💭🏝🔮🖌🚀💽🎓📚🚶‍♂️⚡👉👆🛠🧂😞🐈⚠️🧬🏗🚶‍♂️⭐💫💡📖📹💚💬🙂📎


«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Читать дальше

Зачем нужен метатег viewport

Зачем нужен метатег viewport

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

Метатеги — это инструкции для браузера о том, как отображать содержимое страницы. Один из таких метатегов — viewport, который говорит браузеру, как масштабировать и отображать страницу на разных устройствах, особенно на смартфонах и планшетах.

Читать дальше
HTML
  • 18 сентября 2023
Атрибут class в HTML на примерах

Атрибут class в HTML на примерах

Атрибут class используется для добавления CSS-классов элементам HTML. Классы позволяют применять одни и те же стили CSS или поведение JavaScript к разным элементам на странице.

Так, одному элементу можно присвоить один или несколько классов, разделяя их пробелами.

<!-- Один класс -->
<div class="container">
  <!-- ... -->
</div>

<!-- Несколько классов -->
<div class="container special-box">
  <!-- ... -->
</div>
Читать дальше
HTML
  • 14 сентября 2023
Осмысленный alt-текст: 6 правил

Осмысленный alt-текст: 6 правил

Альтернативный текст — это описание изображения словами. Это описание должно помогать людям, которые читают или слышат это описание, иначе оно не нужно и лучше вообще его не указывать.

Мы уже обсудили основные правила написания alt-текста для фотографий и изображений. В этот раз поговорим о том, каким именно должно быть описание, чтобы в нём был смысл.

Читать дальше
HTML
  • 31 июля 2023
Как понять, что перед вами заголовок

Как понять, что перед вами заголовок

Заголовки используются для организации и структурирования содержимого на сайте. В HTML существует шесть уровней заголовков, обозначаемых тегами от <h1> до <h6>. Каждый уровень заголовка имеет свой семантический вес, где <h1> имеет наибольший вес, а <h6> — наименьший.

Часто кажется, что заголовок — это простой и понятный тег. Но это впечатление обманчиво, потому что не всегда крупный и выделенный текст на макете является заголовком.

При вёрстке сайта важно соблюдать семантику, чтобы все теги использовались корректно и ресурс работал без ошибок. Если напутать уровни заголовков, то структура страницы будет не семантичной, а скринридеры неправильно прочтут сайт.

В статье разберёмся, как верно определять заголовки по макету, какие из них лучше делать скрытыми и почему.

Читать дальше
HTML
  • 8 июня 2023
Как правильно вставлять SVG

Как правильно вставлять SVG

Есть несколько способов вставки SVG-изображения. Выбор одного из них зависит от задач, которые стоят перед верстальщиком.

SVG — это формат векторной графики, дословно: масштабируемая векторная графика. МВГ? SVG! В векторных форматах хранится не само изображение, а инструкция по его построению по точкам и кривым.

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

�PNG
IH�aV
PLTE�������0�
IDAcZ�d���� �W=
S�3�o;���]P
���IEND�B`�~

Формат SVG тоже можно создавать и менять в редакторах графики, например, в Illustrator или Figma. Но ещё он текстовый, а значит его можно открыть как HTML или CSS в любом редакторе кода.

<svg width="20">
  <rect fill="#fc0"
    width="20"
    height="20"/>
  <line stroke="black"
    x1="0" y1="0"
    x2="20" y2="20"/>
</svg>

SVG — это как отдельная HTML-страница. Когда вставляете SVG, вы, на самом деле, вставляете не просто картинку, а целую страницу. Со своей системой координат, вьюпортом, стилями, скриптами и удивительными особенностями.

Если смотреть на SVG как на отдельную страницу — становится понятнее, какой способ вставки вам нужен.

Читать дальше
HTML
  • 1 июня 2023
Как создавать адаптивные изображения. Атрибут srcset

Как создавать адаптивные изображения. Атрибут srcset

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

Давайте рассмотрим несколько способов создания адаптивных изображений.

🎓 В статье мы говорим о пикселях и ретина-дисплеях. Если вы не знаете, что это такое — прочитайте статью.

Читать дальше
HTML
  • 25 мая 2023
В чём разница между <p> и <br>

В чём разница между <p> и <br>

Чтобы разметить текст, нужно понимать, какие использовать теги. Для создания новой строки в тексте есть несколько способов. В статье мы расскажем, как ими пользоваться.

Читать дальше
HTML
  • 24 мая 2023
Как сделать таблицу в HTML

Как сделать таблицу в HTML

<table> — один из основных элементов HTML, который используют для отображения данных (текста, изображения или другого элемента) в ячейках на странице. Таблица состоит из строк и столбцов.

Основные теги, используемые при создании таблицы:

  • <table> — определяет начало и конец таблицы. Всё содержимое таблицы должно находиться между <table></table>.
  • <thead> — определяет заголовок таблицы. Заголовок может содержать одну или несколько строк, в которых могут использоваться теги <th> для определения заголовков столбцов.
  • <tbody> — определяет тело таблицы. Тело содержит одну или несколько строк, в которых могут использоваться теги <td> для определения содержимого ячеек.
  • <tfoot> — определяет нижний колонтитул таблицы. Колонтитул может содержать одну или несколько строк, в которых могут использоваться теги <td> для определения содержимого ячеек.
  • <tr> — определяет строку таблицы. Каждая строка должна находиться между тегами <tbody>, <thead> или <tfoot>.
  • <th> — определяет заголовок столбца или строки таблицы. Используется внутри тегов <thead> и <tr>.
  • <td> — определяет содержимое ячейки таблицы. Используется внутри тегов <tbody>, <tfoot> и <tr>.
  • <caption> — определяет заголовок таблицы, который будет размещен над таблицей. Используется внутри тега <table>.
Читать дальше
HTML
  • 16 мая 2023