Frontender Magazine

WYSIWTF

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

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

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

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

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

Как должны инструменты управления материалами способствовать тому, чтобы авторы обращали внимание на их значение и структуру? Какое количество средств управления представлением и стилизацией материалов в CMS является оптимальным? И как должны развиваться эти инструменты, если мы ломаем концепцию веб-страницы и публикуем материалы на множестве платформ? Давайте посмотрим на 3 инструмента, которые находятся на стыке создания материалов и их представления.

Кнопка предварительного просмотра

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

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

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

Одна издательская компания, которую я знаю, создала собственный интерфейс предварительного просмотра, который показывает редакторам, как материал будет выглядеть в браузере настольного компьютера, в мобильных браузерах и в приложении. Разве не прекрасно? Нет, не прекрасно. На самом деле материал будет просмотрен в гораздо большем количестве контекстов, чем эти три. Но это лучше, чем ничего? Определённо.

Визуальные редакторы (WYSIWYG)

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

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

Какое количество инструментов форматирования следует предоставить авторам? Это сложный вопрос, потому что он приводит нас к спору о том, что является оформлением, а что несет семантику. Даже такие простые вещи, как добавление полужирного или наклонного начертания, заставляют нас задуматься о том, просто стилизуем ли мы текст или наделяем его значением (например, если речь идет о названии книги или о предупреждающем сообщении).

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

Но мысль о том, что каждый блок данных является полем в базе данных (с отдельным полем ввода в CMS), быстро сводится к абсурду. Так можно с ума сойти. Настоящее решение не потребует отказа от больших объемов текста, но заменит панель визуального редактора семантической разметкой. Вместо того, чтобы вводить весь текст в отдельные поля, авторы оборачивают текст в теги, описывая, чем он является. Для заголовка книги не нужно создавать отдельное поле, если мы можем обернуть его в соответствующий тег.

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

Инлайновое редактирование

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

Инлайновое редактирование текста позволяет авторам управлять материалами, не разделяя интерфейс для их редактирования и опубликованную версию. Medium предлагает интерфейс редактирования, который идентичен представлению сайта в браузере настольного компьютера, а инлайновое редактирование добавлено в ядро Drupal 8.

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

Джеф Итон (Jeff Eaton) хорошо резюмирует проблему в своей публикации под названием Инлайновое редактирование и цена дырявой абстракции:

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

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

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

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом редакторам Антону Немцеву в skype ravencry, Константину Гупалову в skype cosmik_soul или в skype matmuchrapna доброму Владимиру Старкову.

Karen McGrane
Автор:
Karen McGrane
Сaйт:
http://karenmcgrane.com/
Twitter:
@karenmcgrane
about.me:
karenmcgrane
LinkedIn:
kmcgrane
Сергей Смольников
Переводчик:
Сергей Смольников
Мой Круг:
http://sergey-smolnikov.moikrug.ru/
Twitter:
@smolnikov
GitHub:
smolnikov