|
Павел Гращенко
11 февраля 2015
|
Есть архитекторы сайта, а есть операторы. Проблема всех систем управления сайтом в том, что они плохо разделяют сценарии этих персонажей.
Архитекторы — это, как правило, разработчики. Они определяют структуру, состав шаблонов оформления, правила масштабирования разных типов контента. Грубо говоря, ответственность за то, что очередная новость должна обязательно оказаться в определенной ветке структуры, подцепить определенный шаблон оформления и выдать на редактирование определенный набор свойств, лежит на архитекторе. Архитектор — это профессионал, знающий всю подкапотную кухню.
Операторы — это, как правило, представители заказчика. Люди, для которых слова «аштиэмель», «шаблон», «парент», «эфтипи» — филькина грамота. Простые дяди и очень простые тети. Они будут каждый день выполнять строго детерминированные действия: добавлять, удалять и редактировать новости, товары, акции, курсы, слонов, термоусаживаемые муфты, турбины атомных подводных лодок, или чем там они занимаются.
Так вот, я убежден, что оператору нельзя давать в руки инструменты архитектора. Это 1) не нужно ему; 2) сложно для понимания; 3) просто опасно для работоспособности сайта. Поясню.
Это не нужно ему. 99,999% задач оператора однообразны. Если это блог, то человек добавляет посты. Если магазин — товары и акции. Если фотогалерея — фотографии. Если сервис подбора недвижимости — карточки квартир. Ситуация, когда оператор вдруг захочет уложить именно эту квартиру в другую ветку структуры с другим шаблоном оформления — фантастическая. Видимо, это уже не оператор.
Это сложно для понимания. Я думаю, все присутствующие не раз имели разговор с тетей, представителем клиента, которая «теперь будет заниматься сайтом», что, мол, внимательно выберите выберите родителя новой страницы и примените к ней шаблон оформления, а вот это поле не трогайте, а то все сломается. «Ой, так сложно! А мне всего-то нужно новость добавить». Работать с ЦМСками (особенно общего назначения) — сложно для большинства людей. Чтобы проверить это попробуйте научить свою маму работать в Джумле.
Это опасно для работоспособности сайта. Да, действительно, не ограничивая возможности оператора, вы оставляете ему возможность по ошибке снести целую ветку структуры, случайно перенести страницу туда, где «её не должно быть» (новость в товары, или контакты в проекты), выбрать не правильный шаблон оформления, создать ветку структуры, которая никак не была предусмотрена дизайном (вот эти вот разговоры «ну мы же сможем самостоятельно в любой момент добавить новый раздел на сайт?»), или удалить какой-то критический файл без которого всё просто развалится к чёртовой матери.
Поэтому когда мы начали разрабатывать свою ЦМС, то дали себе обещание, что операторы клиентов никогда не увидят ни строчки HTML и CSS, не будут выбирать парентов страниц и шаблоны. А будут оперировать понятными сущностями в их собственном мире. В терминологии нашей системы эти сущности называются «Типы контента»: для них архитектором определено положение в структуре, шаблон и набор специфичных свойств.
Тут выше Евгений Арутюнов говорил, что не нужно пытаться создать идеальную ЦМС, а нужно создавать свою под каждый проект и со временем, возможно, выделить какие-то общие моменты.
Но, по мне так, лучше сделать «конструктор индивидуальных систем управления», как пытаемся мы.
|
|
|
|
