Ссылка на оригинал статьи: 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*. Хотя по моему мнению, оптимальная система - это такой же миф, как и философский камень или вечный двигатель. Оценка "оптимальности" всегда будет субъективной. Зависимость от платформ и технологий, непропорциональный рост сложности в настройке и адаптации при росте функциональности, избыточность используемых техник при попытке эмулировать простоту - это только немногое "зло", которое будет накапливаться в процессе "совершенствования" системы. Проблемы скорее философского и психологического характера: для того, чтобы средний типичный, "непродвинутый" пользователь системы должен легко подключить к работе любой интересный ему сервис и легко им воспользоваться, разработчику системы придется на порядки усложнить функциональность движка, следствие - бесконечный рост возможностей приводит к бесконечному усложнению и утяжелению готового движка. Среди известных мне развитых систем управления наблюдается два подхода:
Теперь по поводу собственно требований. Собрать, перечислить их тоже не так просто, здесь тоже нужен опыт, и, желательно, не по одному движку и не по одному заказчику.
Вот так, казалось бы, все просто. Все сложности начинаются, когда есть разные типы контента, когда информационная архитектура становится сложноупорядоченной, а количество желаемых сервисов растет. Проще говоря, все сложности начинаются, когда вы начинаете работу над реальным проектом. Попробуем о реальном: Кто управляет сайтомМы сейчас не говорим о директорах или владельцах проекта. Мы будем считать, что управляет сайтом любой человек, который может внести какие-бы то ни было изменения на сайте - от оптимизации движка и совершенствования дизайна до работы с контентом. В контексте темы разработки CMS это определяется для того, чтобы заранее сформировать группы доступа к сайту, определить права доступа, создать систему авторизации. В типичном требовании типичного заказчика как правило это звучит так: "чтобы секретарша, которая не имеет представления о верстке, могла добавить выданную ей в текстовом документе новость, а некий администратор (свой или кто-то из саппорта) поправить глюки или ошибки, этой секретаршей допущенные". Действительно, так тоже бывает. Попробуем рассмотреть более сложный проект и более сложную систему доступа. Возьмем типичный информационный новостийный сайт, хорошо посещаемый, на котором не только можно почитать интересные новости или посмотреть хорошую графику, но и оставить комментарий к просмотренному, обсудить что-то в форуме и т.д.
Кстати в качестве небольшого отступления - по поводу примера прав доступа для простого зарегестрированного пользователя каталога сайтов, который может редактировать информацию о своем сайте. Здесь получается палка о двух концах. С одной стороны - да, хороший современный движок для каталога сайтов уже трудно представить без такой функции. Однако большинство владельцев каталогов сайтов искренне заинтересованы в том, чтобы каталог был чистенький и не заспамленный. Именно для этого каталог тщательно модерируется, осуждаются описания сайтов, избыточно содержащие *ключевые слова* вместо внятного и лаконичного (и честного) текста. Не проходят модерацию сайты, не соответствующие указанной рубрике, или по другим причинам, как правило указанным в т.наз. privacy policy, в правилах, определяющих политику каталога. Однако если уж пользователь получает права на редактирование (в последствии) информации, то что ему мешает указать при регистрации аккуратные валидные данные, а после зайти под своим аккаунтом и поменять описание на перечень ключевых слов, то же самое сделать с названием сайта, а для некоторых каталогов - даже изменить адрес ссылки на сайт, указав в качестве исходного - очередной раскручиваемый дорвей? Это же на сколько порядков усложняется работа модератора каталога, которому, дабы соблюсти красоту в своем проекте, придется ежедневно пролистывать все рубрики, все страницы в поисках таких нарушителей? Куда проще по-старинке, когда права на запись были только у модератора, и пользователь не мог ничего изменить, только написать в саппорт слезную просьбу о внесении изменений, кои тоже сначала должны пройти проверку. И это только начало. Теперь в краткой форме следует собрать все требования к информационному сайту, к наличию всех возможных сервисов, к формированию интерфейса - для посетителей, для зарегестрированных пользователей, модераторов и администраторов. Повторюсь, собрать ВСЕ требования, которые и реализовать в некоей абстрактной оптимальной системе практически не возможно, хотя бы потому, что часть из них все равно будет противоречить друг другу. И все же я обращаюсь к читателям, к начинающим и опытным разработчикам - пишите в блог или на - хотелось бы выделить группу традиционных требований, а так же обсудить заказываемые нестандартные функции и сервисы. А к тем, кто все же выберется на семинар Сатина - великая просьба, вы задайте вопрос по поводу оптимального интерфейса для "админской части" информационного сайта, для модераторов. Очень хочется услышать по этому поводу мнение авторитета, профессионала, да. Ссылка на оригинал статьи: http://www.nundesign.com/st/cms.html Читайте также: Расчет от Amiro.CMS:
|
|