Так ли дорого прогрессивное улучшение?


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

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

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

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


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

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

    Этап CSS


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

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

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

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

    Этап CSS3


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

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

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

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

    Этап JavaScript


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

    Вначале небольшая оговорка: мы не будем рассматривать сайты, работа которых без JavaScript (JS) в принципе невозможна или теряет всякий смысл, например: Яндекс.Карты, Htmlacademy, различные онлайн-IDE и так далее.

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

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

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

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

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

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


    3. С помощью JS на форму добавляются дополнительные классы, с помощью которых меняется логика отображения. Также усовершенствуется поведение формы, механизм позиционирования, добавляется оверлей.

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

    Итого


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

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

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

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

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

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

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


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

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

    Комментарии 18

      +1
      Иногда заказчика бывает очень сложно (почти невозможно) убедить смириться со слабой работоспособностью сайта в IE6.

      Это печально, но такие заказчики ещё случаются.
        +2
        Обычно это люди технически недалекие, и всегда можно предложить альтернативу поддержке шестого осла — например, добавить какую-то симпатичную фичу.

        По опыту, 90% соглашаются в случае грамотно аргументированного разговора. С остальными 10% обычно заканчиваем отношения — поддержка 6 эксплорера подчас удваивает стоимость разработки, при капитальной деградации качества и удорожания поддержки. Одним словом — поддерживать 6 эксплорер обычно выходит себе дороже.
          –3
          Вот не надо сразу диагноз ставить клиентам, их цель — улучшить свой бизнес, а решение об отказе от старого браузера может лишить части аудитории, ради какого-то то гламурного вываливающегося окошка. Такие решение как и всё в бизнесе должно приниматься на основе цифр. Можно посмотреть статистику сайта или поискать статистику сайтов подобной тематики и уже на основании этих цифр рассуждать о надобности того или иного решения.
          Тем более в вопросе с ИЕ 6 альтернативой является работающий сайт, но визуальными отклонениями от дизайна. Отсутствие плейсхолдера, скругляющихся уголков или полупрозарачности не является критичным. А писать кросбраузерный js не должно вызывать у нормального разработчика проблем с учётом кучи фреймворков.
            +3
            IE6 — старая вонючка, и все разработчики должны всячески способствовать переходу пользователей на другие браузеры.
              +8
              Приведу вам ряд аргументов, которые обычно привожу тем кто настаивает на поддержке IE6:

              1. присутствие IE6 в интернете сейчас в районе 0,2 процентов. Но из-за этих 0,2 процентов скорее всего пострадают остальные, т.к. помимо кастомных стилей, IE6 накладывает ограничения на использование яваскрипта и других технологий

              2. Из-за того, что необходимо поддерживать IE6, придется заплатить больше на этапе создания сайта, и поддержка будет стоить дороже (не говоря уже о том, что хрен найдешь исполнителя. который добровольно бы согласился поддерживать сайт с IE6)

              3. При условии что посещаемость сайта 1000 человек в день, с IE6 туда зайдут 2 человека. А вот с использованием Opera mini — около сотни. Так давайте вместо того, чтобы пытаться угодить этим двум чудакам, сделаем мобильную версию сайта (которая, кстати, обойдется как раз в стоимость поддержки IE6), чтобы обрадовать целую сотню потенциальных клиентов.

              Улучшать бизнес надо с умом. а не по принципу «мой конкурент Серега у себя на сайте поддерживает IE6, а я нет, поэтому я хочу чтобы IE6 у меня поддерживался тоже»
            +1
            Люди, где вы их откапываете-то таких? С кем работал в последнее время, даже на IE8 уже не тестируют.
              0
              Их никто не откапывает, такие обычно сами звонят в поисках бедствующих программистов, которые за еду готовы поддерживать говнобраузер.
            0
            > Почему многие студии считают, что прогрессивное улучшение делает разработку слишком долгой
            > и слишком дорогой, а поэтому ненужной клиентам?

            Даже если мы все квалифицированы, то не факт, что надо делать именно так. Если бизнес-условия позволяют — делаем, иначе нет.
            Это банальный элемент качества и не более того. Вот лично мне как разработчику он ОООЧень нравится, но клиенту вполне может быть реально не нужен. Вот прям чесна!

            Ибо мы по разные стороны :)
              +1
              И заказчик, и разработчик должны смириться с тем фактом, что сайт в некоторых браузерах, особенно старых, будет выглядеть «хуже» (а в IE6 даже разваливаться).

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

              Только что спросил у супруги («пользователь со стажем»), как часто она отключает JS в своём браузере?
              Ответ не заставил себя долго ждать… «Если б я знала что это такое...»
                0
                Тут все немного хитрее.

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

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

                А IE6 — гавно априори, и врядли кто-то гордится тем, что смог заставить работать какой-то сайт в шестом осле.
                  0
                  Да ладно! «Негласный показатель качества» и «IE6 гавно»… Только из этих двух фраз можно уже оценить ваш профессионализм.

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

                    Заставить работать сайт минимумом IE6 это означает отказаться от современных наработок в стандарте CSS и Javascript, что переносит нас лет так на 10 назад, а за это время не только технологии, но и стандарт развивался в направлении удобства его использования. Так что я не вижу профессионализма в использовании минимального подмножества CSS… Это дибилизм скорее.
                      0
                      Сорь. Не хотел обидеть. Не имел в виду конкретно вас.
                      Просто вижу противоречие.

                      Разве заставить сайт работать без JS это не тоже самое что «отказаться от современных наработок в стандарте Javascript, что переносит нас лет так на 10 назад»?

                      На мой взгляд, раз уж делать работу хорошо, то делать ее и для IE6 тоже.
                      С тем же самым деградешеном. Ну не будет тенюшек в IE6, не будет скругляшек ну кое где не будет «пиксель-перфекта», ну незначительно поедут отступы. Ну да и фиг с ним. Лишь бы сайт всё же оставался более менее рабочим в IE6 и не вызывал чувство недоделанного монстра.

                      Касаемо JS, ну не будут работать локал сторадж. Но он не будет работать и в брайзераз без JS. Ведь это уже предусмотрели.

                      Т.е. я не совсем понял, зачем кичиться перед клиентом что мол без JS ваш сайт всё равно будет работать, но в то же время терять свой авторитет из-за IE6.

                      Уверен, что на отключенный JS клиенту наплевать больше чем на потерю IE6.
                        0
                        Да где вы берете пользоателей с IE6? Те единицы которые им пользуются уже давно привыкли что у них все уродливо выглядят или вообще не работают.
                        Поставте себе IE6 и посидите на нем недельку.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Между прочим, плагин NoScript входит в десятку самых популярных.
                      0
                      Он менее популярен, чем Firebug или Greasemonkey, которые уж точно не являются плагинами общего назначения.
                    0
                    Кстати, пример с пицца-конструктором не показателен. Этот конкретный конструктор является типичной веб-формой с радо-кнопками и чекбоксами. Т.е. и тут можно довольно легко применить принцип прогрессивного улучшения.

                    Кстати насчёт онлайн-карт. Прогрессивное улучшение и тут легко сделать, просто никто этим не заморачивался. Достаточно вспомнить какими были карты до ставших каноном гугловских карт — это были всё те же карты, но не на весь экран и с элементами управления. И дело тут не только в прогрессивном улучшении, но и лучшей доступности и удобстве карт: devfiles.myopera.com/articles/523/demo12.html

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

                    Самое читаемое