Добрый день, коллеги.
Среди новинок издательства O'Reilly наше внимание привлекли следующие: книга Miki Godbolt, который, несмотря на свой небольшой объем, может открыть новую страницу в истории веб-разработки.
ОБНОВЛЕНИЕ под катом 
ОБНОВЛЕНИЕ: Нам прислали примерный список тем, которые планируется осветить в этой книге.
Среди них: работа с Sass, написание документации, библиотеки шаблонов, тестирование (визуальная регрессия, модульное, сквозное), управление сборкой, непрерывная интеграция, развертывание, обоснование управления, зачем нужна такая архитектура Интернет развивается, и в рамках этого процесса меняются отдельные роли в современной команде веб-разработчиков.
По мере совершенствования каждого из этих специалистов и повышения их профессионализма в Интернете стали формироваться не только новые роли, но и новые дисциплины.
О тех, кто принимает решения по поводу контента На самых ранних этапах развития Интернета существовал слой людей, которые, похоже, искренне верили, что лексическое содержание любой страницы так же важно, как ее дизайн, код и даже поисковая оптимизация.
До того, как они появились на сцене, контент считался проблемой, которую можно было смело отложить на потом.
«Просто добавьте lorem ipsum в дизайн и идите дальше.
Когда придет время, клиент заменит этот шаблон реальным, высококачественным и вдохновляющим контентом, прежде чем сайт заработает».
Эти любители слова постепенно стали подчеркивать, что сеть — это контент, а контент требует достаточного времени и должного внимания.
Дебаты продолжались, но иногда этих людей приглашали на ранние встречи по планированию, иногда консультировали по разумным методам SEO или просили разработать общий тон и стиль для общей редакционной стратегии сайта.
Дело двигалось вперед, и хотя борьба была трудной и велась в основном одиночками, результатами уже можно гордиться.
Так каждый из этих одиноких воинов шел своим путем до того рокового дня, когда он встретил однополчанина, и они оба поняли, что они не одиноки в этой борьбе.
Первый дружеский контакт постепенно перерос в целую сеть знакомств.
Наконец, появилось большое сообщество подобных филологов, которые все больше продвигают идею о том, что контент — это ценный актив, а не просто наполнитель.
Прошли десятилетия, а борьба за контент еще далека от завершения.
Но каждый раз, когда веб-дизайнера в очередной раз просят «сварить что-нибудь еще» для главной страницы сайта, кажется, что его горестный крик снова услышат все.
И вот однажды, 16 декабря 2008 года, на главной странице блога A List Apart появилась статья Кристины Халворсон.
В нем автор заявил, что отбор контента требует особой стратегии.
Кристина попросила читателей «поднять факел» и «начать относиться к контенту как к важнейшему ресурсу, который требует стратегического планирования и разумных инвестиций».
Тем, кто занимается контент-стратегией, рекомендуется «Учиться, практиковаться, продвигать».
Так в Интернете родилась новая дисциплина.
Статья г-жи Халворсон была не первой, в которой была сформулирована необходимость стратегического подхода к контенту, но именно она подробно описала смысл, дух и цель контент-стратегии, а также обозначила требования к специалисту такой работы.
На следующее утро целая группа работников веб-контента осознала, что у них есть имя, профессия и общее призвание.
Таких специалистов появилось в большом количестве в эпоху блогов, подкастов и видеоконференций, и причина их востребованности заключается в том, что контент действительно имеет значение.
Появление адаптивного Интернета Примерно в это же время на сцене появился мужчина в черной водолазке и просто изменил всеобщее представление о том, что такое «устройство с доступом в Интернет».
Впервые в истории Интернета мы были практически вынуждены признать, что сайты можно просматривать не только на мониторе с разрешением 1024 x 768 пикселей, не выходя из офисного или домашнего кресла, и что сам контент можно не только обслуживать.
через объемные каналы широкополосного Интернета.
Появление iPhone открыло новую эру мобильного Интернета с множеством вариантов разрешения экрана, совершенно разными возможностями устройств, скачкообразной скоростью соединения и довольно хаотичными режимами ввода.
Мы, разработчики, уже не могли догадаться, кто наш пользователь и каковы свойства его гаджета, с которого он заходит на наш сайт. В ответ на этот сбой мы опробовали несколько новых решений.
Мы постарались реализовать масштабирование экрана с помощью щипка или двойного тапа, практически не меняя сам сайт. В других ситуациях был реализован детектор строк пользовательского агента для перенаправления пользователей любого мобильного устройства на «усеченные», удобные для мобильных устройств версии сайтов.
Оба этих решения были недостаточно хороши.
На сайтах, где масштабирование осуществлялось с помощью щипка, возникали трудности с навигацией, а следовательно, с совершением покупок и заказом услуг.
Соответственно, рост мобильного трафика означал рост убытков.
Для создания отдельных версий сайтов, специально адаптированных для работы с мобильными устройствами, необходимо было набрать отдельную команду разработчиков, то есть поддерживать сразу две версии сайтов.
Многие мобильные сайты постепенно закрывались, они не успевали обновляться так быстро, как основная версия, либо набор функций на мобильном сайте оказывался настолько скудным, что пользователям приходилось откладывать телефон и включать компьютер, если им нужно было делать на сайте что-то более сложное, чем навигация по маршруту или звонок.
Ситуация требовала какого-то решения.
Хотя многие поначалу думали, что iPhone — это преходящее увлечение, вскоре стало ясно, что будущее Интернета за этими крошечными персональными устройствами.
Спустя три года после выпуска iPhone сообщество веб-разработчиков наконец нашло долгожданное решение всех этих проблем.
25 мая 2010 года Тан Маркотт опубликовал в блоге A List Apart длинную статью под названием «Адаптивный веб-дизайн».
В этой статье не описывалась какая-либо новая дисциплина и не провозглашались лозунги, под которыми должны были сплотиться сражающиеся веб-разработчики.
Вместо этого «адаптивный веб-дизайн» (сокращенно RWD) описывал методы создания веб-сайтов нового поколения, которые могли бы учитывать размер экрана устройства пользователя и автоматически вписываться в доступную область просмотра.
Автор описывает этот процесс не как инновационную технологию, а как набор уже существующих инструментов и приемов.
Адаптивный веб-дизайн — это не что иное, как сочетание следующих функций:
- Резиновые сетки, ширина которых рассчитывается в процентах, а не имеет жестко запрограммированный размер в пикселях.
- Гибкие изображения, которые заполняют 100% ширины выделенных для них контейнеров, а затем масштабируются по мере изменения параметров области просмотра.
- Медиа-запросы — возможность указывать разные стили в зависимости от размера области просмотра.
Теперь макет страницы можно менять в зависимости от размера экрана.
Но эта работа по адаптивному веб-дизайну, как и статья о контент-стратегиях, ясно объяснила, как объединить все эти инструменты и добиться результата, к которому все отчаянно стремились.
Как родилась концепция архитектуры веб-интерфейса Впервые я начал задумываться о концепции архитектуры веб-интерфейса в середине 2013 года.
В то время я разрабатывал клиентский интерфейс на Drupal и на собственном опыте знал все беды и горести, с которыми приходится сталкиваться контент-стратегам.
О дизайне интерфейса (темы) всегда думали постфактум.
Это был своего рода макияж, наносимый на готовую разметку после того, как дизайнеры и разработчики машинного интерфейса закончили свою работу.
Ничто так красноречиво не характеризует задачи, с которыми мы столкнулись на проекте, как процедура привлечения сотрудников в этот проект. Проект был запущен, затем мы обсудили его дизайн, разработали функциональные элементы.
после чего в проект был приглашен фронтенд-специалист, который реализовал именно тот дизайн, который нам передали сверху, и натянул его на любой существующий разметка.
Пережив этот процесс несколько раз, я твердо помню, какое испытание приходится пережить, чтобы собрать из массы фотошоп-документов для мобильных устройств и ПК тему, которую можно было бы применить к изрыгнутому Drupal div-супу.
Обсуждая со знакомыми Rails-специалистами все проблемы, с которыми приходится сталкиваться при проектировании панели навигации сайта в Drupal, я признал, что не каждый с ними справится и ничуть не преувеличил! Как только разметка была готова и разработчик приступил к решению очередной задачи, оставалось только мечтать о том, чтобы как-то подправить получившуюся комбинацию div, списков и ссылок.
Неизбежно нам приходилось прибегать к нелепым трюкам на уровне CSS в нашем дизайне, даже не ожидая, что макет навигации по умолчанию будет работать в рабочей среде.
В течение многих лет мастерство разработчика веб-интерфейсов измерялось его способностью создавать такие шаблоны дизайна-голема.
«Вставляю псевдоэлемент в 3-й вложенный div, беру фоновое изображение из этого спрайта…» — вот краткое описание наших боевых приёмов, которые, прямо скажем, никуда не годились.
Мы просто латали дыры, надеясь лишь на то, что сайт еще удастся запустить, прежде чем он окончательно окажется погребенным под колоссальным техническим долгом.
Я знал, что такой процесс разработки сайтов не может оставаться стабильным, поскольку наши задачи постоянно усложнялись.
Итак, вместо того, чтобы делать что-то по старинке, я решил представить, как мог бы выглядеть проект, если (перефразируя Кристину) разработка веб-интерфейса стала «важнейшим процессом, требующим стратегического планирования и разумных инвестиций».
Что, если бы мы могли участвовать в разработке CSS-фреймворков, инструментов документирования, процесса сборки, предлагать соглашения об именах и даже работать на уровне разметки?! Я представил, как мог бы выглядеть проект, если бы UX-дизайн диктовал дизайн машинного интерфейса, а не наоборот. Произошла бы тогда революция? Поднимет ли кто-нибудь наш факел с надписью «Учись, практикуйся, продвигай»? Но прежде чем мы смогли собраться под общим знаменем, нужно было решить, зачем мы его поднимаем.
Каковы наши запросы? Как мы собираемся достичь наших целей? Как оно будет называться? Что в имени Понимая, что в моей нынешней компании нет конкретной должности для человека, который бы выполнял такую работу, я начал просматривать вакансии, пытаясь найти что-то похожее.
Немного покопавшись на разных сайтах, я обнаружил, что следующий уровень иерархии после старшего разработчика — это архитектор.
Когда я прочитал описание вакансии, мое сердце начало биться быстрее.
Действительно, на самых ранних стадиях проекта следует привлечь специального архитектора для обсуждения потребностей клиента в контексте конкретной платформы.
Какой стек технологий мы собираемся использовать? С какими типами контента вам придется работать? Как контент будет создаваться, храниться и отображаться? Я понял, что с участием архитектора ничего не будет создано спонтанно; все элементы будут вплетены в глобальную структуру.
Довольно быстро нам удалось преобразовать базу данных и веб-сервер в структуру каталогов Sass, и родилась новая профессия — архитектор веб-интерфейсов.
Итак, придумав название, я начал корректировать должностную инструкцию, думая о том, какую пользу принесет такой специалист, как он сможет повлиять на проект, если предоставить ему необходимые возможности.
Эти мысли вылились в краткую разъяснительную беседу об архитектуре веб-интерфейсов, которая состоялась на очередном ежегодном корпоративном собрании.
Потом я отправил заявку на CSS Dev Conf, она была принята, после чего мне пришлось коротко, минут сорок, изложить свои идеи в специально подготовленной презентации.
Мой доклад «Поднимая знамя фронтенд-архитектуры», прочитанный перед переполненной аудиторией Нового Орлеана, стал программным документом для разработчиков веб-интерфейсов, которые, можно сказать, уже сражались в авангарде.
Мне хотелось донести до них, что они не одиноки, что есть люди, готовые их поддержать и застраховать.
Кроме того, я поговорил с менеджерами проектов и специалистами по продажам, описав им потенциал правильно построенного фронтенда и пользу, которую такая практика может принести команде и заказчику.
Единственным способом повлиять на проекты была работа над архитектурой в самом начале проекта, то есть клиенты должны платить за эти часы, а менеджеры были бы готовы правильно планировать ресурсы для этой работы.
Впоследствии я выслушал немало историй от разработчиков, которые наконец поняли, кто они такие и какую роль играют в организации.
Многие поняли, что работают архитекторами веб-интерфейсов, но просто раньше не использовали этот термин, а другие почувствовали себя вправе взяться за такую работу.
Я, будучи одним из инициаторов этих перемен, предпочитаю не оглядываться назад. Неважно, как именно называется должность, на которой я сейчас работаю, главное, что я архитектор веб-интерфейсов.
В опросе могут участвовать только зарегистрированные пользователи.
Войти , Пожалуйста.
Первое впечатление от книги 47,87% Многообещающая книга для обычных веб-разработчиков 45 9,57% Неплохая книга, но рассчитана на узкую аудиторию 9 42,55% Простейшие истины под новым соусом.
Не тратьте время на чтение книги.
40 Проголосовали 94 пользователя.
83 пользователя воздержались.
Теги: #архитектура #разработка сайтов #CSS #frontend #веб-дизайн #анонс #веб-разработка #книги #книги
-
Объявлен Новый План Выпуска Ruby 1.9.2
19 Oct, 24 -
Обзор Малышки От Sony Ericsson
19 Oct, 24 -
Что-То Пошло Не Так
19 Oct, 24
