На главную

Веб-страница — это документ

Как работают frontend-разработчики

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

Публикация от .

Как делают

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

Как работают frontend-разработчики
Этап «дизайнер — frontend-разработчик»

Давайте детальнее рассмотрим деятельность разработчиков интерфейсов, тех frontend'еров, чья работа связана прежде всего, с разметкой, стилями, UI-framework'ами и т.п. Как строится их работа, когда к ним попадает новый макет?

Как работают frontend-разработчики
Типичный ход разработки UI

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

Формально задача будет выполнена, продуктовые требования соблюдены.

У вас в команде происходит именно так? В таком случае у вась процесс разработки интерфейса строится вокруг одной цели «удовлетворить интересы дизайнера».

Что не так?

Ведь верстка готова, поведение интерфейса соответствует ожиданиям, шаблоны и стили соответствуют корпоративным стандартам. Придирки!

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

Прошу обратить внимание, что html-страница — это документ. Это данные, которые мы показываем пользователю. Эти данные должны быть структурированы и согласованны между собой.

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

Во времена, когда везде и всюду властвует маркетинг, тот факт, что страница является документом, просто ушел даже не второй план, а про него просто забыли. Главные требования — требования «маркетологов», в широком понимании, в нашем случае дизайнера.

Получается парадоксальная ситуация: важен не сам документ, а его подача.

К сожалению, это всеобщая тенденция присущая рыночной экономике, общество вместо оценки самого продукта, оценивает упаковку/фантик и его подачу.

Многие и не помнят, а ведь были времена, когда сайт без стилей был вполне нормальным явлением. Всё делали тегами. Если ссылочка, то <a>, если выделить чего нужно / акценты расставить, то используем <b>, <strong>, <i>, <em>.

В случае с вёрсткой, фантиком являются стили. К сожалению, в online-мире, ценность HTML-страницы без стилей, как самостоятельно продукта, ничтожно мала. «Голый» HTML с данными пользователю не нужен. Так для чего это нужно?

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

Попробуем разобраться, кто является потребителями продукта, в виде «грамотного» HTML-документа:

  1. Поисковики Понять содержание страницы куда проще, когда она структурирована, когда ее содержание согласовано между собой и разметкой её окружающей, то есть когда страница является — документом.
  2. SEO-специалисты Не то, чтобы потребители, но те специалисты, кому вы очень сильно поможете учитывая пункт 1.
  3. Средства машинной обработки данных Агрегаторы, парсеры и различные катологи… если, конечно, вы не преследуете цель закрыть контент от распространения; в таком случае, вам лучше не публиковать свой контент. К данному пункту можно отнести и голосовые браузеры.
  4. Социальные сети и их пользователи В случае с facebook имеет место поведение когда, при попытке «поделиться» статьёй на стороннем сайте далёком от принципа «страница — это документ», изображение к данной статье бралось совсем не из контекста самой статьи, а из колонки с рекламой по неведомой логике. В таких случаях, предполагаю, парсер соцсети, просто не в состоянии корректно справиться с кашей тегов страницы.
  5. Менеджер продукта и вся команда проекта Почему? Да потому что, всё описанное выше работает на продвижение вашего любимого продукта на рынке. А это ли не цель?

Как надо

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

При построениии UI, главное — смысл
При построениии UI, главное — смысл

Задавайте вопросы «а что значит эта часть контента?», «для чего она?», «понятен ли смысл без стилей?». Вы же привыкли заголовок обрамлять тегом <h1>, так почему ограничиваетесь только этим? Нет, ну вы, конечно обрамляете текст тегом <p> (простите за сарказм), но это совершенно недостаточный уровень. Необходимо, чтобы вся страница целиком была осмысленна, а не только её отдельные части.

Настоятельно рекомендую разобрать по кирпичикам доклад Вадима Макеева «Вёрстка со смыслом»

Вёрстка со смыслом. Новая семантика HTML5 (2011г.)

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

это не просто статья — а настоящий рецепт, а список статей на самом деле просто оформлен как однородный список, а на самом деле в нём одна главная полноценная статья, а все остальные всего на всего анонсы других статей,

а в списке товаров цены — это не просто красивые цифры, а они являются прежде всего ценой, требующей соответствующего оформления в разметке.

Если вы разработчик серверной части — участвуйте в разработке интерфейса, участвуйте в формировании требований к интерфейсам, больше общайтесь внутри команды.

Эти действия будут способствовать понимаю и осмыслению frontend-разработчиком шаблонов и повышению качества конечного продукта.