62,11
рейтинг
10 февраля 2014 в 15:39

Дизайн → CMS будущего перевод

Покончим с устаревшим подходом к контенту


На протяжении всей истории интернета мы работали с контентом двумя способами:
  1. Создавали «один шаблон на все случаи жизни»
  2. Создавали для каждого случая свой уникальный шаблон

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

image

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

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

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

Но есть решение. Шесть месяцев назад оно существовало только в виде набросков в моём ноутбуке. А сейчас, это корневая часть нашего CMS. Многие наши клиенты уже используют это, и им нравится. Я покажу вам, как это работает. Уверен, что после этого вы не сможете думать о контенте уже по-другому. Но вначале я хочу немного углубиться в проблему шаблонов и дизайна, что потребует некоторого времени. Если вы торопитесь, то можете сразу перейти к разделу «Нам нужен модульный подход к контенту». Но обещайте, что чуть позже вы вернётесь и прочитаете всё целиком, договорились?



Управление контентом или управление страницами?


Управление контентом и управление страницами — две совершенно разные вещи. Пользуясь CMS, большую часть времени мы, к сожалению, заполняем содержимым формы, которые зависят от каждой конкретной страницы. Мы даём странице то, что нужно ей. Занимаясь созданием CMS долгое время, я неожиданно понял, насколько реальна та фрустрация, о которой мне постоянно твердят пользователи.

Большинство систем управления контентом создано в первую очередь для разработчиков, нежели для создателей контента. СMS индустрия совершенно оторвана от того, как люди создают и редактируют контент. (Mark Boulton)

То, как мы думаем об архитектуре систем управления контентом, неминуемо влияет на то, как мы думаем о форматировании контента. CMS склонны организовывать контент аналитически: раскладывать его по типам, для каждого задавая свой набор полей, свою структуру и логику. В то время как мы мыслим историями, в которых структура контента человечна, проста и проистекает из желания высказаться и выразить себя.

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

Например, я использую WordPress для своего личного сайта. За считанные минуты я могу создать полную структуру сайта настроить всё так, как я хочу. Но в то же самое время я сильно ограничен в том, что я могу делать с контентом, который будет на сайте. Для разработчиков WordPress всё очень здорово: число переменных невелико, надёжность высока. В конце-концов, это хорошо и для меня. Мне не очень-то нужно что-то другое, кроме «одного шаблона на все случаи жизни». Но это далеко не то, в чём нуждаются мои клиенты. Им нужно что-то большее. Как и вам тоже, смею предположить.

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

Глупо иметь «один шаблон на все случаи жизни». Когда мы не знаем, что нам нужно, мы поступаем самым естественным образом: не планируем ничего. Когда у нас нет чёткой поставленной задачи по тому, для чего предназначена комната, она может стать чем угодно. Большинство дизайнеров будут недовольны таким положением дел.

А теперь представим, что у нас может быть столько комнат в квартире, сколько мы захотим. У нас может быть и гостевая, и детская, и офис, и склад, и музыкальная, и спортивная, какая угодно. Тоже вроде звучит заманчиво. Если не брать в расчет, что мы довольно быстро покончим со всем этим, потому станет просто невозможно содержать всё это странное и огромное разнообразие.

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

Я провёл инвентаризацию всех прототипов, которые я спроектировал за последний год, и обнаружил, что обычно получается по 15-20 прототипов на проект. Это не включая всяких всплывающих окон, предупреждений или этапов покупки в онлайн-магазине. Я говорю только об уникальных шаблонах, предполагающих уникальные формы ввода контента и выводящих этот контент во всех возможных комбинациях. Каждый из этих шаблонов требует своего отдельного макета, т.е. мы говорим о 15-20 файлах, которые дизайнер должен создать и утвердить с заказчиком. (Эти шаблоны также не включают альтернативные версии дизайнов для мобильных устройств). Лично наблюдая, как усложняется, удлиняется и удорожается производственный дизайнерский процесс, могу сказать, что 15-20 шаблонов — это слишком много.

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

Модульный подход к контенту позволяет отказаться от создания множества уникальных и сложных шаблонов.
image

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

  1. Создателям контента приходится думать о макете слишком рано. Думать о том, как будет выглядеть контент, непродуктивно до тех пор, пока вы не будете до конца уверены, что это будет за контент, зачем он нужен, кому он предназначен, а также пока не будет ясности по целому ряду других прагматичных вопросов: кто создаёт контент, как часто он это делает.

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

  3. Управление контентом — очень сложное занятие. CMS ориентированы на аналитическую организацию контента по типам. Это значит, что с ростом количества типов контента способы связи между этими типами становятся всё более запутанными и трудозатратными. (Например: создать новую страницу — сохранить; создать слайдшоу — сохранить; создать картинку — сохранить; добавить картинку в слайдшоу — сохранить; добавить слайдшоу на страницу — сохранить; и т.д.)

  4. Поддержка слишком дорога в долгосрочной перспективе. Вероятность того, что вы захотите поменять макет, или даже просто какую-то мелкую деталь в нём — после того, как вы долго привыкали к работе с контентом в данном макете — практически нулевая. Более того, с 15-20 разными шаблонами, издержки разработчиков по внесению этого изменения могут оказаться далеко за пределами того, что вы ожидали заплатить.




Но как же…?


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

Давайте посмотрим повнимательней, что это такое. Имеется в виду что-то наподобие такого от Globalpost, или такого от Pitchfork, или такого шедевра от New York Times. Последний пример Snow Fall наделал столько шума, что создание страниц, подобных этой, стали называть «snowfalling». Эти страницы наполнены изысканной красотой, они вбирают в себя самое лучшее из того, что мы привыкли получать от печатных изданий и современного интерактивного веб дизайна. Они похожи на произведения искусства. Но они же являются настоящим проклятием для дизайнера. Почему?

image

Причины, по которым эти snowfalling служат плохим примером веб дизайна:

  1. Это отвлекает. Страницы, подобные тем, что мы видим у New York Times или Pitchfork — это дизайн, который не концентрирует наше внимание, а служит нашему развлечению. Как вы думаете, сколько людей, привлечённых красотой Snow Fall, реально прочитали весь текст на этой странице? Совершенно ясно, что есть большая разница между числом посетителей и числом тех, кто усвоил информацию. Я очень сомневаюсь, что те 3.5 миллионов людей что-то читали. Нужны ли людям все эти блестящие HTML5 эффекты? Я думаю, что нет.

  2. Это дорого. Сообщается, что для создания Snow Fall потребовались 6 месяцев и команда из 16 человек. Стоило ли оно того? Скорее всего нет. Но даже не в этом дело. New York Times могут позволить себе делать, всё что хотят. Но у кого из нас есть такой же объем ресурсов? Кто и нас может так долго создавать контент?

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

Я спросил Джона Лакса из Teehan+Lax, которые создают дизайн, похожий на тот, о котором я говорил выше, сколько ресурсов им требуется. И Джон ответил, что нужна команда из примерно 4 человек (2 дизайнера, 1 разработчик и 1 руководитель) и около 2 недель, чтобы создать подобное.

Я не знаю, какова ваша собственная почасовая оплата, но давайте признаем, что создание страниц, подобных тем, что делают ребята из Teehan+Lax, стоит дорого. Если вас вдохновляет Snow Fall, это прекрасно. Если вас вдохновляет Teehan+Lax, еще лучше. Но знайте: вы никогда не создадите продукт подобного калибра без соответствующих инвестиций. И вы никогда не найдёте CMS, которая сама делает подобную магию.



Примирение с CMS


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

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

Эти правила и ожидания как раз и делают шаблоны шаблонами. Плохо это или хорошо, но шаблоны — это валюта CMS. Они позволяют производить контент даже тем, кто ничего не смыслит в дизайне, либо тем, у кого нет времени заморачиваться с Фотошопом и кодом.

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

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

Прямо сейчас некоторые могут подумать: «А как же Medium»? Контент, создаваемый с помощью Medium, прекрасен. Он позволяет создавать потрясающие страницы, подобные Snow Fall, с простотой, которую сложно представить. Как они это делают? Не означает ли это, что всё, что я говорил ранее — неправда? Говоря кратко, нет, не значит. И вот почему. Вот страница, которую я создал в Medium за 5 минут. Чтобы её увидеть, нужно авторизоваться. Для тех, кому это кажется утомительным, вот скриншот.

image

Выглядит круто, правда? Похоже на мою собственную причудливую версию Snow Fall, да? На самом деле, нет.

  1. Medium — это система управления контентом с одним единственным шаблоном. Да, вы можете размещать на одной странице текст и картинки в самых разных причудливых комбинациях. Но при этом Medium не позволяет производить контент похожий на Snow Fall потому что:
    • Это CMS, а мы помним, что за созданием Snow Fall не стоит никакой CMS
    • Это специальная блогерская платформа: всё что вы помещаете в Medium, остаётся тут навсегда

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

  3. Самое главное: Medium — это не веб-сайт. Это Medium. Всё, что вы создаёте здесь, принадлежит им. Medium такая же CMS как и Blogger. Это система по созданию контента для специальной платформы, которая накапливает этот контент.

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

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

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



Нам нужен модульный подход к контенту


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

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

Каким условиям должна отвечать наша CMS:

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

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

  3. Минимальное раздувание шаблонов, хорошая масштабируемость и стабильность.

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

Я переспал с этим. На следующий день я стал думать дальше, как этот шаблон может работать внутри нашей CMS. Я стал думать, в каких случаях он может работать хорошо, а в чём у него будут ограничения. И сделал набросок на доске.

image

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



Как работает модульный подход к контенту


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

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

Замечу, что на картинке выше показаны не все возможные комбинации текста и мультимедиа в блоках. Вы можете сами создавать все необходимые комбинации. Можете создать блок, содержащий только один текст, растянутый на всю ширину, или двухколоночный текст, или текст и картинку, текст и видео, текст и слайдшоу, просто видео или просто слайдшоу. Ещё несколько примеров, чтобы прояснить картину.

Модульный контент можно использовать для создания как простых, так и сложных страниц.
image

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

  • Публикация блога
  • Большая форма
  • Тематический кейс
  • Входная страница
  • Биография сотрудника
  • И т.д.

Звучит довольно просто, не так ли? Безусловно, большинство CMS преподностяся легкими в использовании до тех пор, пока вы не начнете ими пользоваться. Но мне кажется, мы создали действительно простую в использовании систему. Взгляните, как она работает.

Откройте контентный блок. Добавляйте и перемещайте контентыне блоки. Создавайте и проектируйте контентные блоки.
image



Двигаемся дальше


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

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

  • Уникальные шаблоны для домашних страничек.

  • Руководства по стилю списков и сетке, лежащие в основе страниц, агрегирующих такой контент как блоги, статьи, видео, продукты и т.п.

  • Шаблоны, предполагающие усложнённую информационную архитектуру, например страницы продуктов с отдельными вкладками, содержащими разные слои информации, отзывы, формы заказа и другие данные, основанные на метаданных продукта и логике поведения пользователя.

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



Послесловие от переводчика


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

Публикации на theverge.com и lookatme.ru

image

Редактор публикаций lookatme, построенный на идее модульного подхода к контенту, используется редакцией издания.
image

Редактор публикаций readymag, тоже построенный на идее модульного подхода, предлагается как SAAS решение.
image
Автор: @karaboz Christopher Butler
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (73)

  • +13
    Небольшой open-source проект, реализующий похожий концепт — Sir Trevor JS.
  • +1
    Автор поста выразил мои сокровенные мысли.
    Но лично хочу скрестить редактирование контента с работой с источниками данных. То есть есть 100 ссылок, а контент выглядел бы вот так:

    @var links = DataManager.GetLinksByNamespace("smi");
    @foreach(var link in links) {
     - @link.Title [@link.Source]
    }
    

    В идеале, конечно, еще бы и автокомлит и рекомпиляция данных «на лету».

    А идея «вертикальной версткой из блоков» очень кстати, возьму себе на заметку.
    • 0
      А что это за язык?
      • 0
        Вероятно, C#
      • +2
        Это я так сделал сборную солянку из языка разметки markdown и препроцессора/шаблонизатора Razor (ASP.net, c#)
        • +1
          Спасибо )
          А я смотрю на @, минус и квадратные скобки и меня жестко наводит на мысли о Obj-C…

          Надо восполнить пробелы в знаниях ASP.Net.
  • +2
    Единственное что хотелось бы от CMS будущего — отдавать ВЕСЬ контент в «машинно понятном» виде (json/xml) + иерархия, а я уже сам буду решать как это будет выглядеть и в чем смотреть.
    • +2
      Боюсь, что эпоха бесплатного и качественного контента подходит к концу. Умрет как RSS.
      • +1
        Это почему? Расскажите.
        • +3
          Качественный контент требует профессиональной работы интеллекта (точнее, работы дорогих профессионалов интеллектуального труда). Обычно их оплачивает инвестор, который хочет вернуть деньги и заработать. Заработать с помощью рекламодателей становится сложно, поскольку большую часть рекламных бюджетов забирают крупные площадки типа Яндекса и Гугла. И инвестор решает не отдавать контент за рекламу, а брать за него деньги. А лучше — и деньги брать, и рекламу продавать.

          В общем остановить такое умирание сможет только искусственный интеллект в журналистике. Ждем, с десятилетия на десятилетие.
          • +2
            Полноценный искусственный интеллект тоже не захочет работать бесплатно. Можно конечно сделать его рабом… но рабство рано или поздно заканчивается восстанием.
            • 0
              Это мы ушли из практической области в философию. Хотя я полагаю, что начнется именно с рабства — можно почитать мнение церкви века эдак XVI по поводу души у не-европейцев. Сейчас же даже животных защищают и охраняют. И с компьютерным интеллектом будет так.
            • 0
              Кстати, по поводу компьютерного интеллекта фантасты предложили свои философские варианты — Дэн Симмонс в Гиперионе / Эндемионе, Иэн Бэнкс в книгах о цивилизации Культуры.
      • +1
        Тогда перевразирую, хочу качественный платный (в пределах разумного) контент в json/xml, и потом выбирать уже читалку под это. Ну по сути RSS, но более продвинутый, с обратной связью и прочими плюшками.
        • –1
          Может быть… Когда рынок насытится платным контентом с рекламой, начнут думать в эту сторону.

          «Ведомости», к примеру — подписка и доступ платные. И все равно рекламу пихают и на сайт, и в приложение.
          Платные каналы, типа Дискавери. Рекламы порой больше, чем на Первом.
    • +1
      Это верно, только отчасти. Большие медиа, например, NYTimes, приходят к такому формату подачи материала, когда весь контент нельзя будет отдать в виде json/xml, ибо манера его подачи ничуть не менее важна, чем сам контент.
  • +8
    В принципе все системы сайтов блочные. То что нет удобного UI в CMS у них это единственная проблема. Если говорить по существу то в реальности я не понял, что нового тут было донесено(скорее всего ничего). Блоки есть везде, от того что где-то они выглядят лучше, а где-то хуже — суть не меняется.

    Не в тему, но по тексту:
    www.svenread.com/readium-ghost-theme/
    Вообщем-то, если хотите себе собственный блог как на медиуме ну и впринципе стандартный шаблон у ghost тоже такого же типа.
  • +20
    Одна вода в статье.
  • 0
    После прочтения, хочется повторить это вновь: «Нам нужен модульный подход» )
  • +4
    Я бы многое отдал за редактор контента Look At Me, прикрученный к WP. Да что я обманываю, если будет такой редактор у какой либо cms, я сразу же начну ее использовать! Это все, разумеется, будет иметь смысл, если такой редактор отдает в шаблонизатор JSON.
    Очень хочется найти время и сделать свой редактор, с сеткой и блоками…
    • 0
      Подобная функциональность реализована в платной теме для WP под названием Lotus: themeforest.net/item/lotus-flexible-multipurpose-responsive-wp-theme/3909293

      Пользовался. Забавно, но требует улучшения сообразительности от контент-менеджеров.

      Ролик конкретно о возможностях редактора: www.youtube.com/watch?v=wuqhm5e9Cfg
      • 0
        Слишком много кнопок, как по мне сложноватый для повсеместного внедрения. Можно сделать намного проще.
        • 0
          Если сделаете, у Вас его оторвут с руками ;)
      • 0
        Спасибо!
        Выглядит действительно очень интересно. Да, кнопок много, но это не беда для небольшого круга редакторов. Попробую поискать, где можно купить этот редактор отдельно от темы.
      • 0
        Этот редактор предназначен, скорее, не для медийного контента, а для верстки страниц сайта.
        И интерфейс Lotus спроектирован таким образом, что верстка займет довольно много времени.
        Когда мы проектировали наш редактор, мы долго думали о том, как расположить элементы так, чтобы приходилось как можно меньше двигать мышью, чтобы все элементы управления попадали в экран (перед этим мы выяснили, на каких устройствах работают сотрудники редакции и ориентировались именно на них), использовали минимум попапов.
    • 0
      Сам по себе редактор обладает небольшой ценностью, если за ним не стоит работа дизайнера-эргономиста, который разработал информационную модульную систему. Подобные системы контекстозависимы, в том плане, что блоки, которые можно встраивать, разрабатываются под конкретный продукт (см. админку lookatme).

      Странно, что в статье не указан redigo (2011), а так же различные проекты с behance в промежутке от 2010 до 2014, всё-таки на lookatme эта фича появилась с новым дизайном (по-моему в 2013).

      Прогнозировал подобный подход в медиа с 2011 года, ждал что фейсбук создаст площадку под новостные сайты и журналы с подписками, но как-то не случилось. Зато появились отдельные проекты, что уже хорошо.
      • 0
        Подобные системы контекстозависимы, в том плане, что блоки, которые можно встраивать, разрабатываются под конкретный продукт (см. админку lookatme).

        Редактор Look At Media (Arcticle) как раз-таки универсален. Перед тем, как приступать к проектированию редактора, мы изучили все элементы фирменного стиля, из которых состоят статьи. Затем мы разбили их на логические группы — оформление текста / разделители / иконки / специальные блоки (часто встречающиеся приемы оформления, требующие довольно сложной верстки). При этом все эти элементы оформления накладываются на базовую модульную сетку (сетка дает вариативность верстки и при этом страхует дизайнеров от ошибок и позволяет придерживаться фирменного стиля). Такое сочение позволяет оформить практически любой материал, вариативность верстки высока, но при этом в управлении редактор прост и понятен даже неподготовленному редактору.
        • 0
          Всё верно. Я говорил о зависимости от контекста и в рамках статейно-медийного продукта он то что нужно. Отличная работа, кстати.

          Кстати, посоветовал бы протестировать различные сервисы отложенного просмотра, например в том же readability картинки и часть контента отсутствует (ну или, может, картинки создавали ощущение полноты).

    • +1
      Для WP был найден отличный плагин.
      codecanyon.net/item/visual-composer-page-builder-for-wordpress/242431
      Я его купил, посмотрев демку и оценив активность автора (всегда боюсь, что потрачу деньги и время на необновляемый плагин/библиотеку и тп).
      В общем, плагин устраивает более чем. Выдает, конечно, не json. Но тут придумано лучше — если отключить «редактор» плагина, то сразу видно в обычном WP редакторе, что у нас весь текст просто оброс шорткодами и его можно полностью менять без боязни что либо сломать.
      Стандартный css — просто обрезаный Bootstrap 2.3 с некоторыми переименованными классами. Кстати, стандартные классы (например, для строк или блоков) можно менять на свои через хук (пример есть в документации). В настройках замечена страница-заготовка для более человечного переменовывания классов.
    • 0
      свой редактор, с сеткой и блоками

      У меня тоже будет свой редактор… :-)
  • +1
    В последнее время понял, что мне не хватает местечка в интернете, где я мог быг бы писать небольшие статейки — что-то вроде pastebin-a на стероидах. Хотелось как раз иметь возможность модульно изменять контент. В итоге родился bluffy.net — при создании статьи есть возможность использовать HTML-редактор (redactor), редактор кода (ace) и вставлять галлереи из картинок (jquery galleria). Далеко от указанных в статье монстров, но, по-моему, получилось мило и достаточно удобно. Сайт пока совсем в бете и на дешевом дроплете digitalocean, но оценить функционал уже можно:)
  • 0
    Неужели на Wordpress нет ничего похожего?
  • +1
    Схожую идею, только с точки зрению бэк-энда, продвигает фреймворк Apotomo.
    Небольшой обзор для работающих с Ruby on Rails — Apotomo + Joosy.
  • 0
    Под контентом понимается вся страница сайта или то, что мы привыкли видеть в центре, например, статья?
    • 0
      Под контентом понимается только та часть, которую добавляют и меняют пользователя сайта.
      • 0
        А где грань между данными и их видом? Ведь подобный подход предполагает объединение данных с их оформлением (видом), а часто нужно разное отображение для одних данных — виды для печати, rss… Со страницами журнального типа ещё терпимо, а как же дела обстоят, например, с товаром? Добавлять товар в каталог созданием его визуальной карточки? Или предполагается хитрая система, которая сама отдельно создаёт объект данных и шаблон под них, если он отличается от уже существующих шаблонов?
        • +1
          В статье как раз говорится о границах применимости журнальной модульной вёрстки. Как раз карточки товаров автор выводит в те шаблоны, для которых предлагаемый модульный подход не работает уже.

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

          Такой подход противопоставляется распространённому подходу, при котором дизайнер заранее продумывает все варианты контента и для каждого задаёт жесткий шаблон (например, как во Вконтакте или Facebook — отдельный шаблон для видео, отдельный для слайдшоу, отдельный для картинки)/
  • 0
    идея хорошая, но я давно использую ее в виде сниппетов и подключаемых файлов, оставляя за основным шаблоном CMS роль скелета.
    • 0
      А можете пояснить, что имеете в виду? Как всё это выглядит для автора контента и для его читателя?
      • +1
        Для автора контента это выглядит как набор сниппетов (в контексте статьи — контентных блоков), которые генерируют необходимую разметку после добавления их в ВИЗИВИГ и отображают демо-контент (рисунок заглушку слева — текст справа, для примера).
        Для читателя это выглядит так же как и в самом редакторе для автора, так как стили сниппетов и стили офрмления текста подгружены в ВИЗИВИГ.
      • +1
        UPD: При необходимости сделать возможность перемешивания сниппетов (контентных блоков), для изменения порядка отображения контента, можно использовать сниппеты генерирующие отдельные подключаемые файлы.

        Пример: вставляем сниппет который include пустой файл, сам файл (через тот же визивиг) наполняем необходимым контентом. Вставляем несколько таких сниппетов и вуаля — их можно менять местами.

        Все описанное в статье можно реализовать на Битриксе.
  • +2
    не хочу показатся занудой, но поставленная автором задача уже давненько реализована в неймоверно большом числе разнообразных CMS…
    при этом есть полное визульное управление и блоками и шаблонами и содержимым…
    к сожалению, все эти реализации только коммерческие и стоят приличных денег
  • +2
    Сейчас как раз заканчиваем сайт для заказчика, который сказал: «Не знаю что там будет, сделайте мне конструктор», но денег дал. Вот пример движка: editor.test.magwai.ru/ Там песочница — контента не жалко. Правда если сейчас несколько человек будут править — заглючит
    • 0
      Неплохо. В открытом доступе вряд ли, но в продаже ожидать можно?)
      • 0
        Это обычный заказной проект. Технически идея была интересная (вот отсюда вдохновлялись), а вот как и кому это продавать — не знаю.
    • 0
      Похоже на изобретение велосипеда Word'а для веб. Имхо, требует умопомрачительной квалификации от контент-менеджера. Проще основам HTML+CSS его обучить, благо руководство писать не надо )
  • +1
    Наверное, это Вэб 3.0 и скоро никто уже не будет мыслить вертикально столбиком с меню, контентом и виджетами справа, а перейдем на горизонтальное мышление. Шапка, ботинки, пять разных модулей и можно отдавать сайт на заполнение.

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

    Кажется, мы все это могли делать и раньше — вставляли картинки как угодно, заголовки где захочешь… Может быть отказ от любимых колонок слева и справа, крупный текст и возможность раскрасить блоки цветами в настроение каждой отдельной статьи дает ощущение того, что мы поставили контент на первое место?
  • +4
    все это подразумевает, что заказчик или его представитель разбирается в технологиях или дизайне… на практике приходиться обрезать все что можно клиенту, чтоб не получился через месяц очередной сайт васи пупкина. большинству нужен именно шаблон- сюда текст, сюда картинку, так проще, быстрее и надежнее… да и представьте сами ваших заказчиков с полной свободой действий? часто заполнением сайта занимаются менеджеры (в лучшем ещё случае)

    идея, конечно, хорошая, сам о таком думал, но… мало кому она нужна из мелких-средних заказчиков…
  • +1
    Похоже как составляется шаблон рассылки в MailChimp. Мега удобно.
  • 0
    А если на сайте несколько страниц? Для каждой страницы настраивать заново расположение блоков или как понять какой блок на какой странице разместить? Как происходит интеграция со своим дизайном?
    Или это для одностраничных сайтов?

    В своей CMS (KodiCMS) я это решил по другому (на youtube есть мини tutorial и можно посмотреть как это работает на примере создания простого сайта), но мой подход позволяет настраивать расположение блока для каждой страницы индивидуально, настраивать кеширование и т.д., в общем не так визуально как у вас, но то же имеет право на жизнь
    • 0
      Выше мой комментарий про информационную модульную систему и контекстозависимость.

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

      Относительно вашей CMS — это не одно и то же, можно и про notepad++ сказать, что он позволяет настраивать расположение блока для каждой страницы индивидуально, настраивать кеширование и т.д. :)
      • 0
        вам нужен такой же специалист, который разработает под ваш проект модульную систему и набор сниппетов.

        По сути — напишет новый шаблон. Т.е. приходим опять к тому, с чего начинали. Просто шаблоны которые до некоторой степени может править редактор. Как я понимаю отличие модульного подхода просто в выдаче пользователю большей свободы. Но в визуальных редакторах сейчас это и так есть. Мы можем вставить картинку, указать куда она будет выравниваться, как её будет обтекать текст. Поэтому больших профитов от модульности как-то не ощущается.
        • 0
          Разница в том, что модульная система разрабатывается один раз и учитывает множество шаблонов, а в текущих cms — каждый шаблон разрабатывается отдельно.
  • 0
    Советую не изобретать велосипед, а посмотреть друпал, модуль панели
  • 0
    Зачем огород городить? Нанимаешь контент-менеджера со знанием основ HTML+CSS и дело в шляпе.
    Всё равно к такому редактору ещё пару томов руководства написать придётся и человека обучить…
  • +3
    Спасибо за качественный перевод отличной статьи. Приятно осознавать, что CMS, с которой ты работаешь, идет в ногу со временем. Я говорю о Drupal, у которого есть замечательный модуль Panelizer (ревью модуля на английском). Также есть отличная сборка Panopoly, в основе которой лежит Panelizer. Она как раз и позволяет управлять кусочками страницы как модулями (в контексте Друпала — панелями) и переопределять заданые шаблоны для каждой уникальной страницы. Кому интересно поклацать это вживую, можно бесплатно установить эту сборку на Пантеоне или обратиться ко мне в личку, я выдам доступ к демо сайту.
    • 0
      Да, Panelizer крутая штука, но только как концепт. Отдавать пользователям её нельзя. Мы отказались от использования panelizer в качестве контент редактора по следующим причинам:
      — Нет нормального билдера сетки. В 8-ке пилят человечный grid builder, но он сырой. Для 7-ки — вообще никакой. Использовать свою сетку можно, но теряется половина преимуществ подобного редактирования контента.
      — Глючно. Нельзя просто взять и установить модуль. Для стабильной работы надо ставить кучу патчей или всю сборку панополи.
      — Проблемы при использовании панелей в панелях. По сути — так делать нельзя — у системы сносит башню, но тогда надо отключить такую возможность в принципе, а не надеяться, что пользователь этого делать не будет.
      — Меееееееедленно. Ну просто ужасно медленно. Подобные штуки должны работать на стороне клиента и быть мгновенными (смотрите для примера Sir Trevor, Smart Builder или Семантический редактор для сайта belonika.ru), а друпал всё это прогоняет через сервер, с выплёвыванием готовых html-форм, что не прибавляет живости.
      — Муторное добавление своих виджетов. Как бы ничего сложного, но ни нормальной документации, ни красивых примеров кода нет.
  • 0
    «Это CMS, а мы помним, что за созданием Snow Fall не стоит никакой CMS»

    Не соглашусь. В чем проблема создать шаблон для сноуфалл?
    Бэк-енд? Отдельный шаблон? Дополнительный JS? Большая форма для енд-юзера?

    Ну вот не вижу я проблем, добавить такой шаблон, который можно настраивать по любому «хочу». А выражение "
    Причины, по которым эти snowfalling служат плохим примером веб дизайна ..." это чисто — субъективное мнение.
  • 0
    Это самый оптимальный вариант, я его еще лет 7-8 назад «проталкивал», правда модули у меня именовались блоками. Никто ничего так тогда и не понял.
    А в студийной CMS реализовал. Очень удобно.
    При загрузке index контроллер определяет только тему и передает управление туда а там шаблон с блоками-якорями на которых повешены модули. Очень удобно делать шаблоны под такую CMS — главное очень быстро. Все это завязано на иерархии блоков и т.п. и нет такого понятия модуль для того-то. Есть понятие контент, а что там уже можно модулем «подвесить, будь то видео, или страница текста или еще чего. Заведует блоками всего ОДИН контроллер который ничего не знает о данных и дизайне и т.п. Он только производит контроль, т.е. триггер своего рода. Т.е. не нативный MVC (как у всех CMS сейчас) а самый настоящий. Экономия в запросах просто потрясающая, если opencart на список товаров тратит где-то более 400 запросов (кстати архитектура opencart просто ужасна (а про работу с БД это вообще отдельная история), но одна из лучших, из имеющихся), то данная система всего 20-30 при такой же функциональности. А про скорость и расширяемость я вообще промолчу, все блоки независимы и отлично масштабируются
    • 0
      За счёт чего меньше запросов?
      • 0
        За счет единого контроллера и иерархической системы
  • +1
    Ребята из FutureColors делали подобный редактор для сайта Вероники Белоцерковской — futurecolors.ru/belonika/ (смотрите видео). Если не ошибаюсь это Django. Но в open source этого нет — закрытая разработка.
    Надеюсь ребята из FC здесь отпишутся (призываю piumosso и Prophet).
    • +1
      Совершенно верно, делали.
      Была даже попытка сделать опен-сорс версию, но пока руки не доходят.
      • 0
        О, как вы быстро! Хорошее заклинание призыва :)
        Спасибо за ответ, и, если можно, опишите в двух словах как это было реализовано: это полностью кастомное решение или использовались какие-то готовые решения, как для сервера, так и для клиента? Сильна ли завязка на Django или это можно перенести на другие python-фреймфорки?
        В ближайшем будущем планируется сделать open source-версию? Или пока заморозили до лучших времён?
        • 0
          Это кастомное решение, состоящее 50/50 из фронтенда и бекенда. В том редакторе завязка сильная, но для опен-сорс версии её вообще не будет, редактор будет работать только на фронтенде и, вероятно, будет поддержка ноды.
          • 0
            То есть это будет a la sir trevor — клиентская библиотека с «выплёвыванием» JSON, я правильно понимаю?
            • 0
              Типа того
  • +1
    Автор формализовал все то, чем я мучаюсь последний месяц.
    Отличный перевод, отличный пост. Теперь понятно, как и куда двигаться.

    Отлично.
    Просто отлично.
  • 0
    Есть Craft CMS, в которой с ноября встроен блочный редактор «Matrix»:
    image

    CMS использует Yii, при этом не опен-сорс, со странной лицензией и дополнительным платным функционалом (а-ля Expression Engine). Но поглядеть интересно.
  • 0
    Ещё в конце 2009-го у меня была идея сделать нечто подобное habrahabr.ru/post/80835/ и даже что-то получилось, но со временем было заброшено.
  • 0
    Справедливости ради, добавлю ссылку на Django CMS 3.

    Screencast: http://vimeo.com/91516565

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Дизайн