Pull to refresh

Знакомство с архитектурой веб-интерфейсов

Reading time 8 min
Views 9.3K
Original author: Micah Godbolt
Добрый день, коллеги.

Среди новинок издательства «O'Reilly», готовящихся к выходу, наше внимание привлекла следующая книга Мики Годболта, которая, несмотря на небольшой объем, может открыть новую страницу в истории веб-разработки.

UPDATE под катом





UPDATE: Нам прислали примерный список тем, которые планируется рассмотреть в этой книге. Среди них: работа с Sass, написание документации, библиотеки шаблонов, тестирование (визуальное регрессионное, модульное, сквозное), управление сборками, непрерывная интеграция, развертывание, обоснование для руководства, зачем нужна такая архитектура

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

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

О тех, кто принимает решения относительно контента

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

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

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

Минули десятки лет, а борьба за контент далека от завершения. Но всякий раз, когда веб-дизайнера в очередной раз просят «еще что-нибудь сварганить» для главной страницы сайта, вновь кажется, что все услышат его горестный вопль. И вот, в один прекрасный день 16 декабря 2008 года на главной странице блога «A List Apart» появилась статья Кристины Хэлворсон. В ней автор провозгласила, что подбор контента требует специальной стратегии. Кристина попросила читателей «подхватить факел» и «начать относиться к контенту как к критически важному ресурсу, требующему стратегического планирования и разумных инвестиций». Тем, кто занимается контент-стратегией, рекомендуется «Учиться, Практиковаться, Продвигать». Так в Интернете зародилась новая дисциплина.

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

Появление адаптивного веба

Примерно в то же время на сцене появился человек в черной водолазке и попросту перевернул всеобщие представления о том, что такое «устройство с выходом в Интернет». Впервые в истории Веба мы были практически принуждены признать, что сайты можно просматривать не только на мониторе размером 1024 x 768 пикселов, с комфортом расположившись в офисном или домашнем кресле, а сам контент может подаваться отнюдь не только по объемистым каналам широкополосного Интернета. С появлением iPhone наступила новая эра мобильного Веба с множеством вариантов разрешений экрана, сильно отличающимися возможностями устройств, скачущими скоростями соединений и довольно хаотическими режимами ввода. Мы, разработчики, более не могли гадать, кто наш пользователь и каковы свойства его гаджета, с которого он выходит на наш сайт.

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

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

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

Спустя три года после выпуска iPhone сообщество веб-разработчиков наконец нашло долгожданное решение всех этих проблем. 25 мая 2010 года Этан Маркотт разместил в блоге «A List Apart» длинную статью, которая называлась просто «Адаптивный веб-дизайн». В этой статье не описывалась какая-то новая дисциплина, не провозглашались лозунги, под которыми должны были сплотиться навоевавшиеся веб-разработчики. Вместо этого «адаптивный веб-дизайн» (сокращенно – «RWD») описывал методы создания нового поколения сайтов, которые могли бы учитывать размер экрана на пользовательском устройстве и автоматически вписываться в имеющуюся область просмотра. Автор описывает этот процесс не как инновационную технологию, а скорее как совокупность уже имеющихся инструментов и приемов.

Адаптивный веб-дизайн представляет собой не что иное, как комбинацию следующих возможностей:

  • Резиновые сетки, ширина которых рассчитывается в процентах, а не имеет жестко заданные размеры в пикселах.
  • Гибкие изображения, заполняющие на 100% по ширине отведенные для них контейнеры, а далее масштабируемые по мере изменения параметров области просмотра.
  • Медиа-запросы – возможность задавать различные стили в зависимости от размера области просмотра. Теперь компоновку страницы можно менять в зависимости от размеров экрана.


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

Как родилась концепция архитектуры веб-интерфейсов

Я впервые задумался о концепции архитектуры веб-интерфейса в середине 2013 года. В ту пору я разрабатывал клиентский интерфейс на Drupal и на собственном опыте знал все те беды и горести, с которыми приходится сталкиваться специалистам по контент-стратегии. Оформление интерфейса (тема) всегда додумывалась уже постфактум. Это был своеобразный макияж, применявшийся к готовой разметке после того, как дизайнеры и разработчики машинного интерфейса заканчивали свою работу. Ничто так красноречиво не характеризует вызовы, с которыми мы сталкивались на проекте, как порядок привлечения сотрудников к этому проекту. Проект запускался, потом обсуждали его дизайн, разрабатывали элементы функционала… после чего на проект приглашали специалиста по фронтенду, чтобы реализовать именно тот дизайн, который нам спустили сверху, натянуть его на любую имеющуюся разметку.

Несколько раз пережив этот процесс, я крепко запомнил, какие мытарства приходится терпеть, чтобы пересобрать из массы photoshop-документов для мобильных устройств и ПК такую тему, которую можно было бы применить к изрыгнутому Drupal’ом div-бульону. Обсуждая со знакомыми специалистами по Rails все те проблемы, с которыми приходится сталкиваться при оформлении навигационной панели сайта в Drupal, я признавался, что они по плечу не всякому и совершенно не преувеличивал! Как только разметка была готова, и разработчик переходил к решению другой задачи, оставалось лишь мечтать о том, чтобы как-то подправить получившуюся комбинацию div’ов, списков и ссылок. Неизбежно приходилось прибегать в дизайне к смехотворным уловкам на уровне CSS, даже не рассчитывая на то, что заданная по умолчанию навигационная разметка сможет работать в продакшене.

Много лет профессионализм разработчика веб-интерфейсов оценивался по его способности создавать такие големические паттерны проектирования. «Вставляю псевдоэлемент в 3-й вложенный div, беру фоновое изображение из этого спрайта…» — вот краткое описание наших боевых приемов, которые, честно признаться, никуда не годились. Мы просто латали дыры, надеясь лишь на то, что сайт все-таки удастся запустить, прежде, чем он будет окончательно похоронен под колоссальным техническим долгом.

Я знал, что такой процесс разработки сайтов не может оставаться стабильным, так как наши задачи постоянно усложнялись. Поэтому, вместо того, чтобы работать по старинке, я решил пофантазировать, каким мог бы получиться проект, если бы (перефразируя Кристину) разработка веб-интерфейсов превратилась в «критически важный процесс, требующий стратегического планирования и разумных инвестиций». Что, если бы мы могли участвовать в разработке CSS-фреймворков, инструментов для документации, процессе сборки, предлагать соглашения об именованиях и даже работать на уровне разметки?! Я вообразил, как мог бы выглядеть проект, если бы разработка UX определяла структуру машинного интерфейса, а не наоборот.

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

Что в имени тебе моем

Осознав, что в моей нынешней компании не предусмотрена специальная должность для человека, который занимался бы такой работой, я стал просматривать вакансии, пытаясь найти хоть что-нибудь похожее. Немного покопавшись по разным сайтам, я обнаружил, что следующая ступень иерархии после senior-разработчика — это архитектор. Когда я прочитал описание вакансии, сердце забилось сильнее. Действительно, на самых ранних этапах проекта к нему следовало бы подключить специального архитектора, который обсуждал бы нужды клиента в контексте конкретной платформы. Какой стек технологий мы собираемся использовать? С какими типами содержимого придется работать? Как контент будет создаваться, храниться и выводиться на экран? Я понял, что при участии архитектора ничего не будет создаваться спонтанно, все элементы будут вплетены в глобальную структуру. Достаточно быстро удалось преобразовать базу данных и веб-сервер в структуру Sass-каталогов, и родилась новая профессия — архитектор веб-интерфейсов.

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

Мой доклад “Raising a Banner for Front-End Architecture”, прочитанный в до отказа набитой новоорлеанской аудитории, стал программным документом разработчиков веб-интерфейсов, которые, можно сказать, уже сражались в авангарде. Я хотел донести до них, что они не одиноки, что есть люди, готовые их поддержать и подстраховать. Кроме того, я побеседовал с проект-менеджерами и специалистами по продажам, описав им потенциал правильно выстроенного фронтенда и пользу, которую такая практика могла бы принести команде и заказчику. Единственный способ повлиять на проекты заключался в том, чтобы работать над архитектурой в самом начале проекта, то есть, заказчики должны оплачивать эти часы, а менеджеры — готовы правильно планировать ресурсы для этой работы.

Впоследствии я выслушал массу историй от разработчиков, которые наконец-то поняли, кем являются, какую роль играют в организации. Многие осознали, что работают именно архитекторами веб-интерфейсов, но просто раньше не употребляли этот термин, а другие почувствовали себя в силах заняться такой работой. Я, будучи одним из зачинателей этих перемен, предпочитаю не оглядываться назад. Неважно, как именно называется та позиция, на которой я сейчас работаю, главное, что я – архитектор веб-интерфейсов.
Only registered users can participate in poll. Log in, please.
Первое впечатление о книге
47.87% Многообещающая книга для веб-разработчиков широкого профиля 45
9.57% Неплохая книга, но рассчитана на узкую аудиторию 9
42.55% Прописные истины под новым соусом. Не тратьте время на проработку книги 40
94 users voted. 83 users abstained.
Tags:
Hubs:
+4
Comments 5
Comments Comments 5

Articles

Information

Website
piter.com
Registered
Founded
Employees
201–500 employees
Location
Россия