Почему бы не воспользоватся возможностью коллеционировать качественные шаблоны секций для лендингов и сайтов визиток для их продажи в SAAS?
Просто организовать разработку и хранить в одном месте.
В итоге новые услуги клиентам:
— конструктор сайтов (проще чем описанный в статье на рынке нет) по сниженной цене
— подписка на шаблоны от студии (подписываться могут другие студии даже)
думаю много можно придумать новых услуг.
У какойто студии это малая часть, какието только и делают сайты за 1000р.
С одним из моих вариантов реализации PMS (основанном на проекте в github) можно познакомится тут: Azexo Composer Site Builder for HTML Templates
Наверно главным приемуществом моей системы является использование WordPress как фреймворка для реализации ситстемы подписки на сервис — конкуренты разработывают это своими силами и как следствие дела идут медленно. Установка тривиальная — нужно в чистую WordPress инсталляцию установить тему. А также в моем варианте помимо описанных в статье средств редактирования есть много элементов которые настраиваются и редактируются в стиле WordPress shortcodes — наверно которые понравятся продвинутым конечным пользователям.
пару десятков будет наверно — но это зависит от того что мы под редактором имеем ввиду.
например если учитывать редакторы в составе вордпрес-тем то может сотня будет.
мне кажется тут так:
— если это инструмент для конечного пользователя то он требует слишком мелкие действия в результате которых очень легко ошибится — а значит конечный пользователь не увидит выгоды.
— если это инструмент для дизайнера/верстальщика то им может показатся что это слишком слабый инструмент.
поищите чтонибуть подобное на envato — увидите как реагируют пользователи на такое.
еще я давно обдумываю вариант фильтрации data атрибутов для анонимуса — для решения проблемы трафика.
думаю буду фильтровать по признаку нужен ли он только для функции рендеринга виджета — придется создать такое поле у параметра.
Можно их всех собирать в один большой data-атрибут в виде json массива. Джквери как раз автоматически разбирает массивы, записанные в data-атрибуте и при выхове .data('my-attr') сразу возвращает массив, а не строку.
Тут надо разделить:
1) есть data-атрибуты которые описывают структуру модели — которая нужна во фронтенде некоторым виджетам для активации. CMS и тотже Visual Composer добавляет невостребованные классы по которым по сути можно востановить модель документа — т.е. это частое явление на сайтах.
2) а есть data-атрибуты которые нужны были для рендерига HTML и по сути несут дублирующуюся информацию во фронтенде, просто в более формальном виде. они понадобятся только в режиме редактирования.
Осюда я думаю, что такой поход кажется некрасивым больше не изза того, что смешивается модель с видом а изза подобного дублирования информации и увеличения трафика. Даже если сохранить эти данные в JSON и положить кудато в одно место — это не избавит от настоящей неприятности. Как вариант можно сделать чтобы виджеты востанавливали эти параметры не из атрибутов а из имиже отрендереного HTML — это трудности для программиста — временные затраты на не очень эффективный код — для каждого виджета свой парсер.
Получается, что смешивается модель с видом.
В общем я тоже чувствую что-то не так изза этого смешивания. Но конкретную проблему сформулировать не могу. Только проблема трафика, которую я написал выше, и вижу возможное решение ее не через выделение атрибутов в JSON.
Похоже чтобы JS билдеру избавится от этой проблемы надо больше заставить программиста программировать — а проблема то пару % от веса страницы.
В этой демке много осталось не нужных атрибутов изза того что старые версии небрежно их плодили. Кстати может быть и текущая версия не все поддирает ненужное. Это все легко поправить — поэтому я поставил не высокий приоритет этому.
То есть вы данные виджетов сохраняете в data-атрибуты, а при последующей загрузке достаете их оттуда? Правильно я понял предназначение этих атрибутов?
Да. Для 2х задач:
— для запуска JS виджетов во фронтенде.
— для их редактирования в режиме редактирования
Я детально анализировал исходники Visual Composer. В JS части там активно используется Backbone. То ли разработчик не владеет Backbone, то ли Backbone неудобный — но исходник разорванный с многочисленными перекрестными зависимостями — разбиратся в нем было трудно. Мне кажется одной из причин медленного развития этого проекта является неудачная архитектура — возможно изза слепой веры в могущество общепринятого фреимворка Backbone. Функционал который разработчик Visual Composer делал все эти годы (около 3х) я повторил за месяц (ну еще месяц на тестирование и багофиксы). Я решил вначале ключевую архитектуру сделать руками а потом если увижу выгоду добавлю Backbone (или Angular или чтото еще) — пока выгоду не увидел может быть проект слишком неизкоуровневый. Но как ни ругай архитектуру Visual Composer у него десятки тысяч продаж — все прощается — разработчик крут — с этим не поспоришь.
По поводу открытых вопросов, где у вас используются «data» аттрибуты?
можете увидеть их если откроете исходник страницы azexo.com/azexo_composer и подсветите строку «data-az».
Основным вариантом прорыва в этой проблеме вижу супер умный генератор JS загрузчика, чтобы он почти посимвольно строил исходник.
Но как подобратся к такой архитектуре — посмотреть на нее сверху — чтобы просто и компакто все звучало — пока не знаю.
В codecanyon у вас все неплохо вроде как идет, и продажи есть. Вы продвигали решение каким то образом? Или просто выложили, и само пошло?
Продвижением не занимался. Недавно только привел исходник в нормальный вид и исправил основную массу багов. Продвижением попробую еще позаниматся когда исправлю баги в моем таск/трекере. И хотелось бы чтобы вордпресную версию приняли на codecanyon — пока отказывают изза неуникальности набора фич — кстати это одна из причин почему в моем проекте туча фич — постоянно отказывают.
Спасибо за предложения.
Вообщето ваш проект очень близок к моему.
Я ставил целью делать редактор и для лендингов тоже.
Едиственное в чем различие, что я ставил еще цель делать редактор для специалистов тоже: дизайнеров, верстальщиков и программистов.
Я сейчас уберу нагромождение кнопок и скоро будет новая фича слайдер-презентация на основе Impress.JS (как обычно с визуальным редактором).
И может быть вас заинтересует мой проект :)
Стабильность поддержки можно оценить анализируя рынок codecanyon codecanyon.net/user/azexo/portfolio
Вы очередной раз подвердили что мне надо срочно занятся этой проблемой. Ставлю высший приоритет в моем плане.
«Uncaught TypeError: Cannot read property 'getContext' of null» «Uncaught TypeError: Cannot read property 'children' of undefined»
Спасибо. Сейчас займусь.
После удаления всего, что я сумел удалить, у меня все равно остались 2 контейнера, которые я не знаю, как удалить, а если нажать «Toggle editor», то они скрываются, и вернуть их уже нельзя — остается пустая белая страница.
Демка доменстрирует немного не ту версию которая на github. Это демка редактора HTML шаблонов сайтов визиток — разработчик HTML шаблона указывает в какой части шаблона можно редактировать контент, вставляя туда контейнеры, пользователь редактирует/сохраняет и HTML файл обновляется на сервере. На счет исчезновения — после массы обновлений исходника периодически старое начинает не работать — раньше не исчезало — добавил в план.
Тут очень не хватает какого-то тулбара для управления всем этим добром, сейчас выглядит все разбросано и разрозненно.
Вот эти тулбары контейнеров изначально и предназначались как корневой тулбар.
Я бы посоветовал ввести больше служебной разметки, чтобы посмотрев на страницу, можно было понять, где что находится, и какая у этого всего структура. Сейчас мне нужно поводить курсором мышки по страничке, чтобы понять, как она собрана.
Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
Если можете сказать хотя бы одну идею как это все можно сократить то устраивающего вас размера — я с удовольствием готов обсудить. Я про это так и написал в конце статьи — это открытый вопрос.
Просто организовать разработку и хранить в одном месте.
В итоге новые услуги клиентам:
— конструктор сайтов (проще чем описанный в статье на рынке нет) по сниженной цене
— подписка на шаблоны от студии (подписываться могут другие студии даже)
думаю много можно придумать новых услуг.
У какойто студии это малая часть, какието только и делают сайты за 1000р.
С несколькими проектами конкурентов можно познакомится тут:
SiteBuilder Lite — Drag&Drop site builder and CMS
Architect — Site and HTML builder
WebRock — Page Builder Framework for HTML5
С одним из моих вариантов реализации PMS (основанном на проекте в github) можно познакомится тут:
Azexo Composer Site Builder for HTML Templates
Наверно главным приемуществом моей системы является использование WordPress как фреймворка для реализации ситстемы подписки на сервис — конкуренты разработывают это своими силами и как следствие дела идут медленно. Установка тривиальная — нужно в чистую WordPress инсталляцию установить тему. А также в моем варианте помимо описанных в статье средств редактирования есть много элементов которые настраиваются и редактируются в стиле WordPress shortcodes — наверно которые понравятся продвинутым конечным пользователям.
перспективы SAAS в рамках такого подхода?
например если учитывать редакторы в составе вордпрес-тем то может сотня будет.
— если это инструмент для конечного пользователя то он требует слишком мелкие действия в результате которых очень легко ошибится — а значит конечный пользователь не увидит выгоды.
— если это инструмент для дизайнера/верстальщика то им может показатся что это слишком слабый инструмент.
поищите чтонибуть подобное на envato — увидите как реагируют пользователи на такое.
думаю буду фильтровать по признаку нужен ли он только для функции рендеринга виджета — придется создать такое поле у параметра.
Тут надо разделить:
1) есть data-атрибуты которые описывают структуру модели — которая нужна во фронтенде некоторым виджетам для активации. CMS и тотже Visual Composer добавляет невостребованные классы по которым по сути можно востановить модель документа — т.е. это частое явление на сайтах.
2) а есть data-атрибуты которые нужны были для рендерига HTML и по сути несут дублирующуюся информацию во фронтенде, просто в более формальном виде. они понадобятся только в режиме редактирования.
Осюда я думаю, что такой поход кажется некрасивым больше не изза того, что смешивается модель с видом а изза подобного дублирования информации и увеличения трафика. Даже если сохранить эти данные в JSON и положить кудато в одно место — это не избавит от настоящей неприятности. Как вариант можно сделать чтобы виджеты востанавливали эти параметры не из атрибутов а из имиже отрендереного HTML — это трудности для программиста — временные затраты на не очень эффективный код — для каждого виджета свой парсер.
В общем я тоже чувствую что-то не так изза этого смешивания. Но конкретную проблему сформулировать не могу. Только проблема трафика, которую я написал выше, и вижу возможное решение ее не через выделение атрибутов в JSON.
Похоже чтобы JS билдеру избавится от этой проблемы надо больше заставить программиста программировать — а проблема то пару % от веса страницы.
В этой демке много осталось не нужных атрибутов изза того что старые версии небрежно их плодили. Кстати может быть и текущая версия не все поддирает ненужное. Это все легко поправить — поэтому я поставил не высокий приоритет этому.
Да. Для 2х задач:
— для запуска JS виджетов во фронтенде.
— для их редактирования в режиме редактирования
Я детально анализировал исходники Visual Composer. В JS части там активно используется Backbone. То ли разработчик не владеет Backbone, то ли Backbone неудобный — но исходник разорванный с многочисленными перекрестными зависимостями — разбиратся в нем было трудно. Мне кажется одной из причин медленного развития этого проекта является неудачная архитектура — возможно изза слепой веры в могущество общепринятого фреимворка Backbone. Функционал который разработчик Visual Composer делал все эти годы (около 3х) я повторил за месяц (ну еще месяц на тестирование и багофиксы). Я решил вначале ключевую архитектуру сделать руками а потом если увижу выгоду добавлю Backbone (или Angular или чтото еще) — пока выгоду не увидел может быть проект слишком неизкоуровневый. Но как ни ругай архитектуру Visual Composer у него десятки тысяч продаж — все прощается — разработчик крут — с этим не поспоришь.
можете увидеть их если откроете исходник страницы azexo.com/azexo_composer и подсветите строку «data-az».
Основным вариантом прорыва в этой проблеме вижу супер умный генератор JS загрузчика, чтобы он почти посимвольно строил исходник.
Но как подобратся к такой архитектуре — посмотреть на нее сверху — чтобы просто и компакто все звучало — пока не знаю.
Продвижением не занимался. Недавно только привел исходник в нормальный вид и исправил основную массу багов. Продвижением попробую еще позаниматся когда исправлю баги в моем таск/трекере. И хотелось бы чтобы вордпресную версию приняли на codecanyon — пока отказывают изза неуникальности набора фич — кстати это одна из причин почему в моем проекте туча фич — постоянно отказывают.
Локализация — там все готово для локализации просто в этой версии не доделано.
Спасибо за приятный отзыв!
Вообщето ваш проект очень близок к моему.
Я ставил целью делать редактор и для лендингов тоже.
Едиственное в чем различие, что я ставил еще цель делать редактор для специалистов тоже: дизайнеров, верстальщиков и программистов.
Я сейчас уберу нагромождение кнопок и скоро будет новая фича слайдер-презентация на основе Impress.JS (как обычно с визуальным редактором).
И может быть вас заинтересует мой проект :)
Стабильность поддержки можно оценить анализируя рынок codecanyon
codecanyon.net/user/azexo/portfolio
Вы очередной раз подвердили что мне надо срочно занятся этой проблемой. Ставлю высший приоритет в моем плане.
Спасибо. Сейчас займусь.
Демка доменстрирует немного не ту версию которая на github. Это демка редактора HTML шаблонов сайтов визиток — разработчик HTML шаблона указывает в какой части шаблона можно редактировать контент, вставляя туда контейнеры, пользователь редактирует/сохраняет и HTML файл обновляется на сервере. На счет исчезновения — после массы обновлений исходника периодически старое начинает не работать — раньше не исчезало — добавил в план.
Вот эти тулбары контейнеров изначально и предназначались как корневой тулбар.
Я пока не знаю как лучше сделать. Если вставлять различные рамки — они могут портить разметку самого документа и их нагромождение может создавать путаницу. Если много использовать прозрачность то все начинает тормозить.
Держу в актуальном состоянии трело: trello.com/b/2oSG0c9U/azexo-composer
У вас какой проект если не секрет?