Comments 15
Да, нужно сначала задуматься о целях CMS, которую хочешь приобрести. Какая CMS нужна web-студии, которая держит много проектов? Большинство делают сайты на одной и той же системе. А может быть стоит подумать в сторону «разные cms для разных целей»? То есть иметь арсенал(ну это грубо сказано, штуки 2-3) cms для проектов разных размеров?
Почему я так мыслю: чем универсальнее система, тем сложнее с ней справляться как в пользовательском отношении, так и в программном.
Почему я так мыслю: чем универсальнее система, тем сложнее с ней справляться как в пользовательском отношении, так и в программном.
Вообще говоря, если не рассматривать проекты вроде яндекса или гугла (то етсь проекты действительно большие и не то, чтобы относящиеся к категории сайтов, создаваемых на CMS), все прочие проекты, фактически, маленькие. И, посему, если есть в наличии CMS (а правильнее — framework для быстрого — в течение, скажем, пары рабочих дней, как максимум — создания кастомизированной CMS), способной потянуть достаточно сложный из этих «маленьких» проектов — тогда, вероятно, нет прямого смысла заморачиваться на 2 -3 cms, которые будут уметь меньше, чем основная.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.
Сам ты хабрик!
А цмс от задач зависит. При мелочи проще самому наваять мини-движочек, от среднего уровня стоит решить, что проще, либо привинчивать цмс к своим задачам, либо использовать наработки, либо писать с нуля. Всегда есть несколько вариантов и, в зависимости от конкретных задач, всегда есть из чего выбрать. ЦМС проще всего пользовать при стандартных бложеках/магазинчиках, когда начинаются специфические задачи, бывает оказывается, что написать свой движок проще, чем дописывать модуль/плагин к готовой ЦМС. Это, кстати, еще один критерий для таких систем — расширяемость/документированность/etc…
А цмс от задач зависит. При мелочи проще самому наваять мини-движочек, от среднего уровня стоит решить, что проще, либо привинчивать цмс к своим задачам, либо использовать наработки, либо писать с нуля. Всегда есть несколько вариантов и, в зависимости от конкретных задач, всегда есть из чего выбрать. ЦМС проще всего пользовать при стандартных бложеках/магазинчиках, когда начинаются специфические задачи, бывает оказывается, что написать свой движок проще, чем дописывать модуль/плагин к готовой ЦМС. Это, кстати, еще один критерий для таких систем — расширяемость/документированность/etc…
Вопрос про другую историю, если можно:
Какой WYSIWYG Вы собираетесь использовать в проектируемой CMS?
Какой WYSIWYG Вы собираетесь использовать в проектируемой CMS?
Скорее всего основная часть инфы вбиваться будет без WYSIWYG. (каталоги-описания-контакты)
А там где нужны будут средства выделения будут добавлены именно они. Никаких «Size +3» или «Font: Tahoma».
А сам скрипт, попробуем поискать опен-сурс, для того чтобы лечить и изменять. Но если ничего толкового не найдём, слепим свой.
А там где нужны будут средства выделения будут добавлены именно они. Никаких «Size +3» или «Font: Tahoma».
А сам скрипт, попробуем поискать опен-сурс, для того чтобы лечить и изменять. Но если ничего толкового не найдём, слепим свой.
По поводу WYSIWYG мое мнение такое — лучше для клиента либо написать кастомный небольшой свой, либо обрезать по функционалу стандартный, таким образом, чтоб всякие font и т.д. не прописывались напрямую в страницу… да и вообще запретить их прописывать (проверку на теги тоже сделать не сложно)
В css уже должны быть стили для всех h1/2/3… strong и т.д. а так же кастомные стили для различного рода контента и ОБЯЗАТЕЛЬНО приучить клиента ими пользоваться…
ИМХО если контент будет добавлять человек, который хоть как умеет работать в Word, то тут ничего сверхсложного не будет для него, ну а если не способен работать в Word, то и тут ему не место заниматься добавлением контента…
В css уже должны быть стили для всех h1/2/3… strong и т.д. а так же кастомные стили для различного рода контента и ОБЯЗАТЕЛЬНО приучить клиента ими пользоваться…
ИМХО если контент будет добавлять человек, который хоть как умеет работать в Word, то тут ничего сверхсложного не будет для него, ну а если не способен работать в Word, то и тут ему не место заниматься добавлением контента…
Вопрос про другую историю, если можно:
Какой WYSIWYG Вы собираетесь использовать в проектируемой CMS?
Какой WYSIWYG Вы собираетесь использовать в проектируемой CMS?
>> По-сути, конечно, цель одна — ускорить разработку сайта.
мне кажется, это роковая ошибка. страница делается для клиента. и цель внедрения CMS имхо должна быть «максимально облегчить клиенту управление содержанием».
мне кажется, это роковая ошибка. страница делается для клиента. и цель внедрения CMS имхо должна быть «максимально облегчить клиенту управление содержанием».
Все указанные автором заметки цели – частный случай. Со стороны разработчика.
Вы бы лучше посмотрели на CMS со стороны владельца сайта. На то ведь она и _CMS_ (content management system, т.е. система управления контентом), а не система создания сайтов.
Вы бы лучше посмотрели на CMS со стороны владельца сайта. На то ведь она и _CMS_ (content management system, т.е. система управления контентом), а не система создания сайтов.
Вы точно внимательно читали заметку?
То что вы говорите, есть пункт первый. Это маркетинговое преимущество, типа «с нашими сайтами оооочень удобно работать, потому что они использую НашаSuperCMS, там можно делать то-то и то-то, так-то и так-то».
И даже тут, лучший вариант изменения сайта владельцем, это не админ панель вовсе, а хитроумный AJAX JavaScript. Когда нет необходимости обучатся админ-панеле, а можно менять свой сайт на своём сайте.
А автоматизация процесса всё равно нужно, потомучто увелечение производственной мощности только с помощю увелечения персонала, не есть хороший тон ведения бизнеса…
То что вы говорите, есть пункт первый. Это маркетинговое преимущество, типа «с нашими сайтами оооочень удобно работать, потому что они использую НашаSuperCMS, там можно делать то-то и то-то, так-то и так-то».
И даже тут, лучший вариант изменения сайта владельцем, это не админ панель вовсе, а хитроумный AJAX JavaScript. Когда нет необходимости обучатся админ-панеле, а можно менять свой сайт на своём сайте.
А автоматизация процесса всё равно нужно, потомучто увелечение производственной мощности только с помощю увелечения персонала, не есть хороший тон ведения бизнеса…
«А зачем Вам CMS?»
удобно с ними… как ни крути...)
удобно с ними… как ни крути...)
Sign up to leave a comment.
А зачем Вам CMS?