В апреле 2010 года Итан Маркотт выступил на сцене An Event Apart в Сиэтле, где собирались люди, создающие веб-сайты. Он говорил об интересной школе мысли в мире архитектуры: отзывчивый дизайн, идея о том, что здания могут меняться и адаптироваться в зависимости от потребностей людей, использующих здание. Это, как он объяснил, может стать способом подхода к созданию веб-сайтов.

Месяц спустя он развил эту идею в статье под названием Responsive Web Design ("Отзывчивый веб-дизайн"). Он был опубликован на А List Apart, том же веб-сайте, который опубликовал John Allsopp's A Dao Of Web Design десять лет назад. Статья Итана разделяла тот же дух, что и предыдущий громкий крик Джона. На самом деле, Итан начинает свою статью со ссылки на А Dao Of Web Design ("Дао веб-дизайна").

Обе статьи призывали веб-дизайнеров принять идею Единого Веба. Но если Dao Of Web Design ("Дао веб-дизайна") был в основном отвергнут дизайнерами, которым было удобно работать с инструментами WYSIWYG, то Responsive Web Design ("Отзывчивый веб-дизайн") нашел свою аудиторию среди дизайнеров, отчаянно пытающихся решить проблему мобильных устройств.

Смежные возможности

Писатель Стивен Джонсон задокументировал историю изобретений и инноваций. В своей книге Where Good Ideas Come From ("Откуда берутся хорошие идеи") он исследует идею под названием "смежные возможности":

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

Стивен Джонсон

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

К тому времени, когда Итан ввел термин "отзывчивый веб-дизайн", ряд технологических достижений уже был на месте. Как я написал в предисловии к последующей книге Итана на эту тему:

Флюидные (гибкие) сетки. Возможность использовать проценты вместо пикселей появилась у нас еще во времена макетов TABLE.

«Технологии уже существовали: флюидные (гибкие) сетки, гибкие изображения и медиа-запросы. Но Итан объединил эти технологии под одним знаменем и тем самым изменил наше представление о веб-дизайне.»

Гибкие изображения. Исследование, проведенное Ричардом Раттером, показало, что браузеры становятся все более искусными в изменении размеров изображений. Внутренние размеры изображения не должны быть ограничивающим фактором.

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

Слои были на месте. Желание перемен, вызванное неуклонным ростом мобильной связи, также имелось. Нужен был лозунг, под которым их можно было бы объединить. Это то, что дал нам Итан с помощью Responsive Web Design.

Изменение мышления

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

Люк Вроблевски придумал термин Mobile First в ответ на рост популярности мобильных устройств:

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

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

Стефани и Брайан Ригер воплотили в жизнь подход к разработке отзывчивого дизайна, ориентированного на мобильные устройства:

«Отсутствие медиазапроса – это ваш первый медиазапрос.»

В этом контексте "Mobile First" в меньшей степени относится к мобильным устройствам как таковым, а вместо этого фокусируется на приоритетности контента и задач независимо от устройства. Отказ от предположений. В прошлом веб-дизайнеры не раз попадали впросак из-за необоснованных предположений о настольных устройствах. Теперь не менее важно не делать предположений относительно мобильных устройств.

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

В книге "A Dao Of Web Design" дизайнер Марк Боултон вписал этот новый подход в исторический контекст:

«Примите гибкость Интернета. Создавайте макеты и системы, которые могут справиться с любой средой, в которой они могут оказаться. Но единственный способ сделать все это – избавиться от образа мышления, который был кандалами на нашей шее. Они удерживают нас. Начните проектировать с контента, а не с холста..»

Этот способ мышления "контент-аут" в корне отличается от подхода "холст-ин", который восходит к Книге Келлса. Он требует от веб-дизайнеров отказаться от иллюзии контроля и создать материально-честную дисциплину для Всемирной паутины.

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

ский веб-дизайнер Трент Уолтон сначала с опаской относился к отзывчивому дизайну, но вскоре понял, что это более честный, аутентичный подход, чем создание макетов в Photoshop с фиксированной шириной:

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

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

В двадцатую годовщину создания Всемирной паутины Тим Бернерс-Ли написал статью для журнала Scientific American, в которой он повторил эти основополагающие принципы:

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

Глава 4: Языки

Джон Постел был одним из

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

Джон Постел.

Фотография Ирен Фертик, Служба новостей Университета Южной Калифорнии.

Авторское право 1994, USC.

Если узел в сети получает дейтаграмму с ошибками, но все еще понятную, то пакет должен быть обработан в любом случае. И наоборот, каждый узел в сети должен стараться отправлять хорошо сформированные пакеты. Эта линия мышления была закреплена в Принципе устойчивости, также известном как Закон Постеля:

«Будьте консервативны в том, что вы посылаете; будьте либеральны в том, что вы принимаете.»

Если это звучит знакомо, то это потому, что именно таким образом веб-браузеры работают с HTML и CSS. Даже если в HTML или CSS есть ошибки, браузер все равно попытается обработать информацию, пропуская все фрагменты, которые он не может разобрать.

Объявление

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

Большинство языков программирования не являются декларативными, они императивные. Perl, Java, C++ … все это примеры императивных языков. Если вы пишете на одном из этих языков, вы должны дать точные инструкции компьютеру, интерпретирующему ваш код.

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

Императивные языки, такие как PHP, Ruby и Python, можно найти на серверах, питающих Всемирную паутину, читающих и записывающих записи баз данных, обрабатывающих входные данные и выполняющих сложные алгоритмы. Вы можете выбрать практически любой язык программирования при написании кода на стороне сервера. В отличие от неизвестности веб-браузера конечного пользователя, вы можете контролировать возможности своего сервера.

Если вы хотите писать императивный код, который работает в веб-браузере, у вас есть только один выбор: JavaScript.

Скриптинг

Идея выполнения программы изнутри веб-страницы так же стара, как и сам веб. Вот раннее письмо в список рассылки www-talk:

«Я хотел бы знать, расширил ли кто-нибудь WWW так, чтобы можно было запускать произвольные программы нажатием кнопки в WWW-браузере.»

Тим Бернерс-Ли, создатель Всемирной паутины, ответил на это:

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

Это было в 1992 году. Универсальный интерпретируемый язык программирования наконец-то появился в 1996 году. Он был написан за десять дней программистом из Netscape по имени Брендан Эйх.

Язык пережил несколько смен названий. Сначала он назывался Mocha. Затем он был официально представлен как LiveScript. Затем в дело вмешался отдел маркетинга и переименовал его в JavaScript, надеясь, что это название подхватит волну шумихи, связанную с новым тогда языком Java. На самом деле у этих языков мало общего. Java для JavaScript – это как ветчина для хомяка.

Характерные черты прогресса

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

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

До появления JavaScript форма должна была быть отправлена на веб-сервер, прежде чем вы могли убедиться, что все необходимые поля заполнены, или что введенная информация соответствует ожидаемому формату.

Оба этих варианта использования все еще существуют, но теперь нет необходимости обращаться к JavaScript. Вы можете создавать эффекты перелистывания с помощью псевдокласса :hover в CSS. Вы можете проверять поля формы с помощью атрибутов REQUIRED и TYPE в HTML.

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

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

Пред.1 2 345 6 ...8 След.

Устойчивый веб-дизайн

Положительная реакция