Сайт cms: Какую лучше выбрать / Хабр

Ссылка на оригинал статьи: http://www.nundesign.com/st/cms.html

Многочисленные советы по оптимизации и продвижению веб-сайтов в сети в конечном счете сводятся к одному: содержание, уникальный и востребованный контент рулит. Визуальный дизайн, стерильная верстка, бэклинки — это вторично. Как следствие — более ясное понимание и заказчиками, и самими разработчиками того факта, что любой проект, будет это новостийный, корпоративный или личный сайт — он должен быть прежде всего *информационный*, т.е. должна быть система, которая позволяет быстро и легко вносить изменения и добавления на сайт.

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

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

Так же многих в готовых решениях более чем устраивает тот факт, что большая часть известных на сегодняшний день блог-сервисов является еще и хостингом для блогов — тот же livejournal успешно решает за своих пользователей проблему с выбором — где, у кого и как , на каких условиях арендовать площадку для своих дневников. Это понятно.

Уже частично отличается ситуация, когда владельцы сайта осознают необходимость в хостинге, в аренде своего пространства для проекта — тогда есть три варианта:

• берется бесплатный движок для сайта
• покупается готовое решение
• разрабатывается своя система управления.

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

Освоить самые азы сетевых технологий — php, asp, xml способен даже начинающий программист, студент. Но знать все тонкости и особенности любой из них — для этого нужно уже иметь неслабую практику. То же касается аналитической группы проекта — если уж вы собираетесь разрабатывать свою систему управления, вы должны быть четко уверены в том, что ваш аналитик имеет реальное представление о том, что из себя может представлять хорошая система управления содержанием, т. е. иметь опыт работы с довольно большим количеством других движков, как пользователь и администратор, ясно представлять себе цели вашего проекта, все функции, который этот проект должен выполнять на момент выпуска его в сеть и в ближайшем будущем. Какая нагрузка планируется на систему? Какой объем контента, какой объем траффика? Имеет смысл закладываться под миллион статей за небольшой промежуток времени (что есть совершенно реально, вот и Wikipedia недавно объявила, что за пять последних лет как раз миллион статей и набралось, а пять лет — это очень немного, это очень быстро). Будет проект исключительно информационный, или же в ближайшем или не очень ближайшем будущем все же планируется коммерческое подразделение, продажи, электронный магазин и SSL-сертификат 🙂 и возможно ли будет адаптировать и совершенствовать такой движок по мере роста проекта и его потребностей?

Да и технологии… если, к примеру, рассматривать PHP+MySql, то здесь и специалистов можно найти без особого труда, и консультации получить, на русском причем языке, благо славный http://phpfaq. ru всегда доступен, есть что почитать и у кого спросить. А если новомодная связка XML+AJAX — много ли вы знаете разработчиков, которые реально представляют себе все возможности, а, с другой стороны — все сложности и тонкости этой технологии? Хотя, впрочем, информация появляется, с каждым днем… но специалистов все же мало, очень мало. И они, естественно, дорого стоят. И еще один пункт, о котором придется задуматься до начала работы над проектом — сколько вы планируете тратить времени и денег на поддержку вашего сайта? Опять же, если речь идет о скромном сайте компании, где раз в пол-года обновляется блок новостей, нет большого смысла уделять серьезное внимание детальной проработки проекта, но если задачи стоят более серьезные? Чем сложнее задачи, тем сложнее и система управления, и понятно, что нет большого смысла в том, чтобы пытаться сложнейший комплекс сделать с настолько примитивным интерфейсом (всмысле, простым в управлении), чтобы школьники и неподкованные в интернет-технологиях пресс-секретари без проблем разруливали весь процесс. Здесь как и в любой другой системе — чем сложнее поставленная задача, тем более подготовленным должен быть человек, эту задачу реализующий.

В качестве примера в одном из блогов приводились машины и самолеты. Простой планер — он тоже летает, и не нужно учиться очень долго для того, чтобы освоить технику полета, однако дабы управиться с боингом, нужно учиться годы, причем в специальных учреждениях, сдавать экзамены на профпригодность и «накатать» предварительно опыт на симуляторах и тренировочных полетах, прежде чем самому выполнять задачу. Так же и с сайтами — все равно придется обучать специалиста, контент-менеджера, который будет заниматься информацией на сайте — добавлением, контролем, обработкой. И чем сложнее задачи — тем больше придется обучаться такому специалисту, а значит — тем дороже он вам будет обходиться по ходу работы. Т.е. тот самый аналитик, который планирует все этапы разработки, должен предусмотреть все возможные в процессе использования (пока еще будущего) движка трудности. Выбрать оптимальную для данного проекта стратегию. Оптимальную технологию. Оптимальную команду программистов и разработчиков интерфейса. И озвучить вам бюджет на разработку и дальнейшую поддержку вашего сайта :):) включая оплату его, аналитика, интеллектуальных затрат. И если вы доверяете ему, и если вас еще не напугали и вы все еще не передумали, если реально оценили требуемый бюджет и ожидаемые сроки разработки — можно только пожелать удачи и похвалить за смелость.

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

Совсем недавно (незадолго до нового года) сотрудники фирмы, в которой я работаю дизайнером, как раз столкнулись с проблемой поддержки продуктов сторонних разработчиков. Мы использовали хитрую утилиту, которая решала в общем-то для нашего проекта глобальные проблемы. Но оказалось, что утилита всем хороша, для узкого круга задач, но проект развивается, а значит — хочется больше возможностей от всех модулей проекта. Обратная связь с саппортом этой утилиты была на удивление прекрасная, причем ребята не только оперативно отвечали на вопросы, они внимательно прислушивались к просьбам и даже, кажется, были довольны тем, что мы были недовольны :):) потому что мы подкидывали им практически изо дня в день новые идеи — что можно еще добавить в их сервис, усовершенствовать работу утилиты, и пофиксить заодно нетривиальные глюки, которые выползали на сложных задачах (на которых разработчикам даже в голову не приходило обкатывать свой проект). Такая связь с саппортом приятна и, как вы сами понимаете, взаимовыгодна.

С другой стороны — так же некоторое время назад возникла потребность в некоем сервисе (не буду озвучивать название, может, владельцы еще очухаются и вернутся в работу, зачем добивать отрицательными комментариями), но помимо многих хвалебных отзывов встретились несколько негативных, именно о том, что саппорт не отвечает. Не рискнули, не купили. После еще пару месяцев были волнения — всякие крики о том, что оплаченный коммерческий продукт не работает — т.е. клиенты зря потеряли хоть и небольшую, но все же ощутимую сумму. Впрочем, такие проблемы встречаются чаще с разработчиками очень мелких и очень дешевых программок, если же речь идет о солидном проекте — здесь таких проблем быть не может. Как показывает практика, есть ряд компаний, которые настолько стабильно ведут свой бизнес, что риски могут быть только с вашей стороны — а именно выбрать тот продукт, который действительно оптимально соответствует вашим задачам.

Я, к примеру, не знаю ни одного бесплатного или условно бесплатного движка, который бы устраивал меня полностью, если знаете вы — пожалуйста, поделитесь информацией. Большинство же разработок — достаточно глючные, дырявые и негибкие, т.е. переводя на русский язык — соглашаясь на использование халявы, вы должны быть готовы к тому, что в любой момент в любом месте может произойти сбой, или же обнаружится уязвимость в безопасности, или — самая распространенная проблема — вы просто не можете оптимизировать готовое решение под свои нужны. Впрочем, если вы не слишком придирчивы, почему нет? Поликарпов Роман на cвоем сайте опубликовал хороший обзор бесплатны cms, можете ознакомиться.

Что касается коммерческих решений — есть много интересных разработок, довольно гибких, многофункциональных, разработчики которых постоянно совершенствуют свое детище, саппорт уведомляет своих клиентов о новых апдейтах — некоторые из известных мне CMS действительно хороши, их можно было бы успешно использовать для ваших (моих) информационных проектов, но… цена. Как правило хорошая CMS, как вы и сами знаете, изрядно стоит. Настолько дорого, что первая мысль, которая приходит в голову — разработать СВОЮ систему управления содержанием, СВОЙ движок, при этом он будет заточен именно под конкретные задачи проекта (правда конкретные задачи у большинства информационных проектов чаще всего одинаковые), разработать самому (или в соавторстве с соседом-программистом) или же заказать. И тут…
И тут начинается изобретение велосипеда.

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

Кто сталкивался с заказчиками подобных систем, знают, что на первом этапе запросы у них довольно скромные. Нужно что-то простенькое, ну, вы знаете — чтобы секретарша легко могла добавить новость в соответствующий раздел. Однако дальше запросы растут, и это еще хорошо, если растут они в процессе планирования, до утверждения ТЗ, так же не плохо, если необходимость в новых функциях обнаруживается после сдачи проекта — главное — отследить, где заканчивается обещанная «поддержка» движка (в случае мелких непринципиальных глючков), и где начинается разработка новой версии системы (которая чаще всего бывает совсем новой, в корне измененной, грубо говоря не модифицированной, а разработанной заново) — с новым ТЗ, новым бизнеспланом и другими деньгами. Значительно печальнее, когда новые требования вдруг озвучиваются в процессе, когда заказчик «внезапно» вспоминает, что ему совершенно необходим еще какой-то важный сервис, без которого его будущий проект просто-таки теряет смысл : и здесь требуется тот самый опорный документ, на базе которого разработчик озвучил стоимость проекта, к примеру, опираясь на предполагаемое время разработки.

Техническое задание формируется на основании требований, озвученных заказчиком. Даже если вы собираетесь создавать такой движок для своих нужд — в садитесь в кресле с листочком в руках, или проще — перед компьютером, открываете текстовый документ, и конспектируете — что хочется, что будет нужно, явные требования, потенциальные возможности, чтобы не упустить что-то важное. Вы можете обратиться к аналитику, вы можете сами себе быть аналитиком, но в любом случае ваш этап проектирования начнется с перечисления требований.

Интересное наблюдение: начинающие программисты зачастую смело берутся за работу, считая, что ясно видят, что и как нужно делать. А вот те, кто создавал или участвовал в создании таких систем не один и не два раза, значительно чаще задумываются о том, насколько все же сложно сделать универсальный проект, продуманную, гибкую структуру, которая сможет удовлетворить самого что ни на есть придирчивого заказчика, систему, которую легко можно модифицировать под разные задачи, под разных клиентов. Задумываются о том, что такое *оптимальная CMS*.

Хотя по моему мнению, оптимальная система — это такой же миф, как и философский камень или вечный двигатель. Оценка «оптимальности» всегда будет субъективной. Зависимость от платформ и технологий, непропорциональный рост сложности в настройке и адаптации при росте функциональности, избыточность используемых техник при попытке эмулировать простоту — это только немногое «зло», которое будет накапливаться в процессе «совершенствования» системы. Проблемы скорее философского и психологического характера: для того, чтобы средний типичный, «непродвинутый» пользователь системы должен легко подключить к работе любой интересный ему сервис и легко им воспользоваться, разработчику системы придется на порядки усложнить функциональность движка, следствие — бесконечный рост возможностей приводит к бесконечному усложнению и утяжелению готового движка.

Среди известных мне развитых систем управления наблюдается два подхода:

1. Прямая последовательность: Увеличение количества сервисов и одновременное упрощение интерфейса управления этими сервисами приводит (как раз как и сказано выше) к усложнению и утяжелению ядра системы. Подход наиболее распространенный: для того, чтобы имитировать гибкий подход к заказчику, формируются типы решений, к примеру, «light», «professional», «expert» — или как-то еще формируются пакеты предложений, отличающиеся количеством доступных сервисом, упрощенным или усложненным интерфейсом, и, главное — ценой.

2. Более грамотное распределение в цепочке «ядро» -> «функциональность» -> интерфейс, которое позволяет для каждого конкретного случая формировать свою систему, в рамках которой уже распределять уровни сложности и совершенствовать функциональность под заданные требования.

Теперь по поводу собственно требований. Собрать, перечислить их тоже не так просто, здесь тоже нужен опыт, и, желательно, не по одному движку и не по одному заказчику.
Самое минимальное требование к системе — шаблонизация сайта.
Даже самый простой, не пересыщенный информацией проект можно разложить по типам данных, по элементарным модулям. Попробуем самый простой :.

1. Информация. Текст, или графика, или даже музыка, что угодно, все, что называется «контент». Контент, который нужно упорядочить, для чего нужно или иметь интуитивное представление о том, что такое информационная архитектура, или же уделить время изучению известных руководств по теме.

2. Навигация. Как только на сайте имеется больше одной страницы, требуется минимальный навигационный элемент — гиперссылка для того, чтобы иметь возможность переходить от одной страницы к другой. В простейшем случае мы можем представить, что каждая страница сайта — это и есть *раздел*, в котором содержится блок контента: «приветствие» на главной, текст о компании в разделе «о компании», список проектов в разделе «проекты» и доступная контактная информация в разделе «контакты» — пример простейшего навигационного блока будет состоять из четырех гиперссылок. А сложные, многоуровневые и многопорядковые навигационные модели можно описывать бесконечно.

3. Визуальный дизайн, оформление. Современные дизайнеры с большой неохотой отказываются от разумного подхода — максимально отделять оформление страниц от логики, хотя современные средства разработки предоставляют все возможности для реализации более здравой модели. Соглашусь, я наблюдала мегакреативные дизайнерские разработки, красивые, и, хотя с точки зрения логической верстки очень убого реализованные, с нарушением всех возможных стандартов, заточенные под конкретно взятый браузер и ни-ни открыть такой документ в любом альтернативном, все же только ради уникального визуального решения достойные. Но нужно понимать, что это скорее исключение из правила; нарушающие же логику сети разработчики сайтов с убогим дизайном нелепы.

4. Логическое форматирование документа. Об этом и в Библиотеке, и в сети пишут все время, бесконечная тема для споров и выяснения отношений с пеной у рта. Если вы веб-дизайнер, попробуйте собрать хотя бы один сайт, в каждом документе которого будет соблюдаться ЛОГИКА, не будет ни одного избыточного html-тега, и, напротив, будут использоваться необходимые теги там, где они по логике и должны использоваться. Да, речь о том же — ключевое заглавие документа — в теге h2, перечисление чего-бы то ни было — в нумерованных и ненумерованных списках, в таблицах — табличные данные И ТОЛЬКО. Оглянитесь на свои, уже сделанные проекты — есть среди них хотя бы один, о котором вы можете сказать, что все html-документы вашего сайта ЛОГИЧНЫ? И если у вас еще нет такого проекта, воспользуйтесь озвученной выше рекомендацией, проведите эксперимент, создайте такой проект, пусть он будет простой, не это важно.

5. Механизмы. Знаю, слово подобрано не очень удачно — речь идет именно то тех самых частях движка, которые будут каким-либо образом обрабатывать контент (п.1), делать его доступным со страниц сайта с помощью элементов навигации (п.2), с необходимым соответствующему контенту оформлением (п.3), предоставлять в конечном счете в виде собранного html-документа (п.4)

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

Мы сейчас не говорим о директорах или владельцах проекта. Мы будем считать, что управляет сайтом любой человек, который может внести какие-бы то ни было изменения на сайте — от оптимизации движка и совершенствования дизайна до работы с контентом. В контексте темы разработки CMS это определяется для того, чтобы заранее сформировать группы доступа к сайту, определить права доступа, создать систему авторизации. В типичном требовании типичного заказчика как правило это звучит так: «чтобы секретарша, которая не имеет представления о верстке, могла добавить выданную ей в текстовом документе новость, а некий администратор (свой или кто-то из саппорта) поправить глюки или ошибки, этой секретаршей допущенные».

Действительно, так тоже бывает. Попробуем рассмотреть более сложный проект и более сложную систему доступа. Возьмем типичный информационный новостийный сайт, хорошо посещаемый, на котором не только можно почитать интересные новости или посмотреть хорошую графику, но и оставить комментарий к просмотренному, обсудить что-то в форуме и т. д.

1. Есть первый администратор, главное управляющее лицо сайта. Полный доступ к сайту (и не только через веб-интерфейс, но в том числе и). Все права на запись, редактирование, удаление любой информации на сайте, управление подключением-отключением и настройкой сервисов, управление более младшими группами с меньшими правами доступа — создание (модификация, удаление) аккаунтов, создание (модификация, удаление) всех групп пользователей.

2. Администратор сайта (или группа администраторов сайта) — полный доступ к сайту через веб-интерфейс (и только), полный доступ к управлению и т.д.

3. Модератор (группа модераторов). Управляет контентом своей рубрики. Не может управлять группами модераторов, возможно (если по-правильному) не может управлять всем, что доступно другой группе модераторов. К примеру, модератор, назначенный на ведение определенной рубрики, может управлять только контентом своей рубрики. Может управлять аккаунтами пользователей (группами пользователей младше модераторской). Бедные модераторы… на новостийных сайтах работы у них невпроворот — публиковать новости и статьи по теме своей рубрики, следить за комментариями к статьям посетителей — дабы пресечь возможный спам, мат, разжигание национальной или гендерной 🙂 вражды, курировать форум, обрабатывать кучу информации ежедневно… Собственно и движок-то на новостийных сайтах разрабатывается именно для них — они в основном формируют контент сайта.

4. Пользователь. Может создать и управлять своим аккаунтом, права ограничивают возможности управления контентом. К примеру, зарегестрированный пользователь на форуме может добавить сообщение на форум. На современных, достаточно развитых форумах — отредактировать или даже удалить свое сообщение. Но не может управлять — редактировать или удалять сообщения других пользователей группы. Многие популярные каталоги сайтов дают доступ зарегестрированным пользователям, и они могут добавлять в каталог сайт, изменять в случае необходимости описание сайта и другую информацию, удалить сайт, но не имеют доступа к изменению информации других пользователей.

5. Посетитель. Будем считать, что посетитель — это *незарегестрированный* пользователь сайта. На большинстве информационных проектов даже не зарегестрированный пользователь может добавить контент, к примеру, если сервис «оставить комментарий к новости» или «проголосовать», или «участвовать в опросе» не требует авторизации — все равно посетитель так или иначе управляет содержанием сайта (вы же согласны с тем, что резуальтаты голосования или статистика по опросу, а тем более выводы и аналитические измышления на основании этих выводов — это так же контент сайта?). А статистика сайта? Многие инфопроекты внимательно отслеживают статистику и даже меняют содержание и структуру (и оформление, и т.д.) на основании детального анализа статистики, следовательно, даже если ваш посетитель вообще никак не поучаствовал в жизни сайта, пришел, сделал один переход по ссылке и закрыл сайт — вы уже будете анализировать его поведение и причины — почему? Может, неинтересная заметка, которую стоит убрать подальше с глаз? или чрезмерно сложная форма для заполнения, которую нужно упростить? Или слишком тяжелый блок с презентационным флешевым роликом, который лучше заменить комбинированным (текст+графика) облегченным вариантом?

Кстати в качестве небольшого отступления — по поводу примера прав доступа для простого зарегестрированного пользователя каталога сайтов, который может редактировать информацию о своем сайте. Здесь получается палка о двух концах. С одной стороны — да, хороший современный движок для каталога сайтов уже трудно представить без такой функции. Однако большинство владельцев каталогов сайтов искренне заинтересованы в том, чтобы каталог был чистенький и не заспамленный. Именно для этого каталог тщательно модерируется, осуждаются описания сайтов, избыточно содержащие *ключевые слова* вместо внятного и лаконичного (и честного) текста. Не проходят модерацию сайты, не соответствующие указанной рубрике, или по другим причинам, как правило указанным в т.наз. privacy policy, в правилах, определяющих политику каталога. Однако если уж пользователь получает права на редактирование (в последствии) информации, то что ему мешает указать при регистрации аккуратные валидные данные, а после зайти под своим аккаунтом и поменять описание на перечень ключевых слов, то же самое сделать с названием сайта, а для некоторых каталогов — даже изменить адрес ссылки на сайт, указав в качестве исходного — очередной раскручиваемый дорвей? Это же на сколько порядков усложняется работа модератора каталога, которому, дабы соблюсти красоту в своем проекте, придется ежедневно пролистывать все рубрики, все страницы в поисках таких нарушителей? Куда проще по-старинке, когда права на запись были только у модератора, и пользователь не мог ничего изменить, только написать в саппорт слезную просьбу о внесении изменений, кои тоже сначала должны пройти проверку.

И это только начало. Теперь в краткой форме следует собрать все требования к информационному сайту, к наличию всех возможных сервисов, к формированию интерфейса — для посетителей, для зарегестрированных пользователей, модераторов и администраторов. Повторюсь, собрать ВСЕ требования, которые и реализовать в некоей абстрактной оптимальной системе практически не возможно, хотя бы потому, что часть из них все равно будет противоречить друг другу. И все же я обращаюсь к читателям, к начинающим и опытным разработчикам — пишите в блог или на — хотелось бы выделить группу традиционных требований, а так же обсудить заказываемые нестандартные функции и сервисы. А к тем, кто все же выберется на семинар Сатина — великая просьба, вы задайте вопрос по поводу оптимального интерфейса для «админской части» информационного сайта, для модераторов. Очень хочется услышать по этому поводу мнение авторитета, профессионала, да.

Ссылка на оригинал статьи: http://www.nundesign.com/st/cms. html

Читайте также: Расчет от Amiro.CMS: CMS — выбрать или разработать? Финансовая сторона медали.

Автор: Татьяна Вукс 

Источник: www.nundesign.com