Наш курс Контент-менеджер на данный момент построен по принципу: КМ работает из публички. Создавая его мы уже понимали, что концепция не совсем верна, но до переделки курса добрались только сейчас.
Для нас ясно, что расширять курс необходимо, но не понятны пределы расширения.
Вот и хочу спросить:
- Что вы разрешаете КМ делать в админке?
- Что чаще всего приходится делать (типовые сценарии)?
- Что настраивают КМ в админке?
- Какими инструментами системы чаще пользуются ваши КМ?
- Какие трудности при освоении системы возникают у КМ?
P.S. Курс переделывается достаточно серьёзно: переписываются тексты, меняется структура, удаляется избыточная информация, появятся контекстные подсказки, будет сменён дизайн.
Чаще из админки всё делают не от того что из публички это совсем никак, а из-за того что наворотив большую сложность и логику, не удаётся впихнуть что-то похожее на эрмитаж без мата.
А вот КМ веб студии порой и php на странице правят, и веб формы создают, и шаблоны писем изменяют (если там поправить фразу всего лишь), и параметры компонентов порой.
Например при добавлении картинки через визивиг система ставит ей ширину и высоту, но данная функция является устаревшей и мешает правильному наполнению адаптивных сайтов. При добавлении картинки каждый раз приходится нажимать не указывать размер.
Все заголовки правит только наш внутренний отдел SEO. Они же настраивают теги, умные фильтры и ряд модулей написанных для более оптимального.
Экономически выгоднее не пилить универсальные конструкторы, а настраивать универсальное управления только для тех частей которые реально могу часто правиться. К примеру напрочь пренебрегаем визуализацией настроек кастомных компонентов - ну какой представитель клиента или КМ туда полезет? Это удел лишь небольшого количества. Сделайте опрос, мне кажется в этом убедитесь.
Так что бросайте дело документирования "для блондинок" и лучше сосредоточьтесь на том чтобы проще было создавать и поддерживать продукты на уровне кода. По сути, мне кажется, что не ошибусь что 90% времени партнеров по работе с платформой приходится на ее код, а не контент-менеджмент. Давайте правильно перераспределять усилия, которые у вас, очевидно и так достаточно не много)
Чего и говорить на сколько нужна документация возможностей ORM. К примеру что из коробки уже (или может давно) есть связки с Uts/Utm сущностями. Вот пипец сколько времени оказывается убил за год не зная этого, а вчера наткнулся в querychain и офигел.
В общем долой нужные инструкции для КМ, даешь больше документации ядра для разработчиков!
В 1% КМ должны редактировать некоторые инфоблоки, загружать картинки в галерею, редактировать публичные страницы и включаемые области.
Обычно делаем 1 общую группу на КМ с разрешением на загрузку картинок, сброс кеша и редактирование страниц.
Плюс по 1 группе на 1 инфоблок.
Далее каждого КМ добавляем в группу "КМ" и все группы-ИБ которые ему нужны.
1) Контент в нем из-за особенностей верстки всегда выглядит "не так" как на сайте.
2) Пользователи хотят "богатое" оформление, которого не добиться через сниппеты. А у многих есть опыт работы с вордпрессом где в текст легко вставляется галерея и т.д.
Такое ощущение, что правильнее было спросить: а что у студий остаётся за админом?
Есть админ серверов, который nginx, apach и т.п.
А есть разработчик, который вот все эти агенты, веб формы, права и т.п. если требуется. Ну и заодно кодит. Или кодит, а заодно вот это всё, если припрёт...