Comments 73
Автор поста выразил мои сокровенные мысли.
Но лично хочу скрестить редактирование контента с работой с источниками данных. То есть есть 100 ссылок, а контент выглядел бы вот так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CMS использует Yii, при этом не опен-сорс, со странной лицензией и дополнительным платным функционалом (а-ля Expression Engine). Но поглядеть интересно.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 December 2011

Location

Россия

Website

genue.ru

Employees

2–10 employees

Registered

15 January 2014