Устойчивый веб-дизайн - Jeremy Keith Страница 14

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

Масштаб

Уорд Каннингем, создатель вики, придумал термин "технический долг", чтобы описать общую проблему в мире программного обеспечения. Решения, принятые в спешке в начале проекта, приводят к каскаду проблем в дальнейшем. Мне нравится думать о трехэтапном многоуровневом подходе как о своего рода "техническом кредите". Уделив время обеспечению основной функциональности в начале, вы получаете свободу для экспериментов в дальнейшем.

Некоторые люди неправильно понимают прогрессивное улучшение как отказ от новейших и лучших браузерных технологий, но на самом деле все наоборот. Многоуровневый подход к созданию веб-страниц дает вам разрешение попробовать новейшие API JavaScript, независимо от того, как много или мало браузеров в настоящее время их используют.

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

Определите основную функциональность.

Сделайте эту функциональность доступной, используя максимально простую технологию.

Улучшайте!

Этот подход работает в разных масштабах. Он работает не только на самом высоком уровне сервиса; его можно применять и на уровне отдельных URL-адресов.

Спросите "Какова основная функциональность этого URL?" сделать эту функциональность доступной с использованием простейшей технологии, а затем улучшить оттуда. Это может действительно прояснить, какой контент наиболее важен, что важно в мобильном первом реагирующем рабочем процессе. Как только вы это установите, убедитесь, что содержимое отправляется с сервера как HTML (простейшая возможная технология). Затем, используя условную загрузку, вы можете решить сделать запросы Ajax для поддержки контента, если экран недвижимости доступна. Для URL-адреса отдельной новостной истории, сама история будет отправлена в первоначальном ответе, но связанные с ней истории или комментарии могут быть перенесены с сервера только по мере необходимости (хотя вы все еще можете предоставить ссылки на соответствующие истории и комментарии для всех).

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

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

Стоит помнить, что улучшения могут предоставляться по скользящей шкале. Первым улучшением для текстового адреса может быть статичное изображение. Следующим усовершенствованием может быть замена статичного изображения интерактивной "скользкой" картой, работающей на Ajax. Если браузер поддерживает API геолокации, можно показать расстояние до места. Добавьте анимацию и переходы, чтобы лучше передать направление.

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

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

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

Рекомендации

Designing With Progressive Enhancement by Filament Group

Глава 7: Проблемы

Четвертая ежегодная конференция по

гипертексту состоялась в Сан-Антонио, штат Техас, в декабре 1991 года. Проект Тима Бернерса-Ли "World Wide Web" тогда только начинал формироваться. Полагая, что организаторы и участники конференции оценят проект, он подал предложение на Hypertext '91. Предложение было отклонено.

Гипертекстовое сообщество считало проект World Wide Web слишком упрощенным. Почти каждая другая гипертекстовая система включала концепцию двусторонней связи. Если ресурс перемещается, любые ссылки, указывающие на этот ресурс, автоматически обновляются. Сеть не давала таких гарантий. Его система ссылок была намного проще – вы просто ссылаетесь на что-то, и все. Организаторам «Гипертекста-91» это казалось безнадежно наивным. Они не понимали, что простота Интернета на самом деле была его силой. Поскольку связывание было таким простым, любой мог это сделать. Это окажется решающим фактором в принятии и успехе Всемирной паутины.

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

Это решение выносилось много раз за всю историю существования сети.

"Это слишком просто"

Когда проект Web Standards Project начал кампанию, призывающую дизайнеров перейти с таблиц для верстки на CSS, она встретила сопротивление. Их снова и снова критиковали за наивность. "Конечно, макет на основе CSS может подойти для простого персонального сайта, но он никак не может подойти для большого сложного проекта".

Затем Даг Боуман возглавил CSS-редизайн сайта Wired.com, а Майк Дэвидсон – CSS-редизайн сайта ESPN.com. После этого открылись шлюзы.

Когда Итан Маркотте продемонстрировал возможности отзывчивого дизайна, это встретило сопротивление. "Конечно, отзывчивый дизайн может подойти для простого персонального сайта, но он никак не может быть масштабирован для большого сложного проекта".

Затем газета Boston Globe запустила свой отзывчивый сайт. Microsoft сделала свою домашнюю страницу отзывчивой. Снова открылись шлюзы.

Сегодня похожая история. "Конечно, прогрессивное улучшение может сработать для простого персонального сайта, но оно никак не может подойти для большого сложного проекта".

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

"Это слишком сложно"

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