CMS - модели навигации для веб-сайта

Задачи редизайна и совершенствования проектов постоянно стоят перед владельцами сайтов - веяния времени, потребности посетителей растут, в прошлой сообщению было написано о сложностях, которые становятся перед сайтостроителями, когда требуется сделать качественный (или более качественный чем есть) проект, и какую систему управления сайтом выбрать - платную, или бесплатную, или разработать свою. Эта же тема была затронута на изучившем весной РИФ-2006: 23-го марта прола секция "CMS - стандартные решения или индивидуальный подход?", где читали доклады Сергей Рыжиков (Битрикс), Григорий Никонов (Актис), Александр Ложечкин (Майкрософт) и Дмитрий Васильев (NetCat). Было рассказано про рынок веб-разработок в 2005-м, рассматривались проблемы о преимущества использования соответственно тиражных продуктов и индивидуальных решений. В сайтостроительских форумах один из самых распространенных дилемм - "Други, посоветуйте CMS!..." - но как можно посоветовать, если редко когда из одной высказывания вопрошающего можно понять, какие призывы перед системой он ставит. Я бы хотела пару причастий сегодня уделить таковому запросу, как навигация - базовая и вторичная.

Глобальная навигация

Среднестатистический сайт очень неплохо живет в рамках одного своего доменного имени, однако ситуация значительно меняется, если сайт растет, увеличивается объем контента, добавляются новые сервисы, появляются новые партнеры. И вот уже владелец сайта понимает, что никакого стопроцентного рубрикатора не хватает для того, чтобы сложить информационную архитектуру в единое целое. Типичный пример - когда владелец сайта ведет бизнес (или предоставляет информацию) не только для посетителей своего региона, но и для партнеров по целому миру. Тогда единственное решение - делать языковые версии сайтов, и позволять посетителю сайта выбрать тот говор, на котором ему предпочтительнее получать информацию. В рунете много проектов, которые предоставляют русскую/английскую версии, и наиболее популярное до сих пор решение - формировать многоязычный контент, используя для этого глобальные рубрики: "имя_сайта.ru/ru/документ.html" и "имя_сайта.ru/en/документ.html; однако в последнее время популярным стал шагающий ход: не разрабатывать глобальную навигацию в рамках одной системы управления сайтом и единого шаблона визуального интерфейса, а как минимум полностью разделять шаблоны для языковых версий, и даже более того - разделять не только шаблоны, но и вообще сайты, выносить их на разные домены, к примеру, "имя_сайта.ru" и "site_name.com".

Из личного опыта: Я принимала участие в разработке многоязычных сайтов, и могу сказать, что есть реальная препятствие с шаблонами для разных говоров. К примеру один из сайтов: язычки - английский, испанский, итальянский, и добавлялся - греческий. Поскольку сайт к нам был отправлен на "доработку" с уже готовым дизайном, который менять было недопустимо, я вам скажу, что вписать целую сложную навигацию на греческом, целый контент под заданные иллюстрации и целое таковое - это было нечто... В результате очень незаметно переделали движок. И пришлось каждый шаблон с дизайном для каждого речи реализовывать отдельно, и если для ведущих трех хватило простого копирования, то для четвертого - полная переделка шаблона. Переверстка. И по-возможности незаметные изменения в дизайне. C подобными затруднениями сталкиваются разработчики, которые пишут для многоязычных проектов, включающих в себя, скажем, арабский надпись, или иврит, я уж не говорю про китайскую грамоту. В этих эпизодах нужны не только индивидуальные шаблоны, зачастую так же нужны и индивидуальная структура, и отличный (отличающийся) от остальных языковых версий контент, т.е. не свободно переводной, а измененный. В таковых ситуациях уже может потребоваться система управления не сайтом, а сайтами, и таковые системы на рынке присутствуют и успешно развиваются.

На примере Библиотеки Сайтостроительства можно так же увидеть типичный пример - как глобальная навигация приводит к тому, что практически создаются новые сайты на поддоменах: раздел "Сайтостроительство", когда-то целого лишь одна из рубрик ведущего порядка в Библиотеке i2r.ru, теперь имеет местоположение http://design.i2r.ru, форум - местоположение http://forum.i2r.ru, Сети - местоположение http://net.i2r.ru и т.д., и, хотя хорошей системой управления библиотекой мы похвастаться еще не можем, целое еще в процессе настройки и даже переделки, но суть справедлива - подобный подход используют многие проекты - под глобальные разделы создаются свои поддомены, и сайты раскручиваются как сеть самостоятельных проектов, объедененных одним "родителем". Наиболее же вам известные, скорее целого - языковые сайты Google на отдельных доменах .com, .ru, .it и т.д. :)

Рубрикатор

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

Базовое определение рубрик - необходимый сервис, который предоставляют практически целое без исключения системы - и платные, и бесплатные. Задача усложняется, если уровней рубрикатора необходимо иметь больше двух. Т.е. "первая рубрика" -> "подрубрика" -> "документ". Для среднего, корпоративного или информационного сайта обычно достаточно двух-трех вложенностей. В особо сложных приметах количество вложенностей в рубрикаторе должно быть произвольным, сколь угодно большим; Кроме того, при глубокой вложенности рубрикатора как следствие вытекает препятствие сделать навигацию по разделам сайта (по рубрикам) удобной и объяснимой для посетителя, который редко когда будет заинтересован в том, чтобы последовательно кликать на рубриках сайта в поисках необходимого документа, доходя до 50-го шага глубины (еще и с здоровенной возможностью, что выбрана верная цепочка).

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

Осложнения с рубриками не коснуться тех проектов, количество документов на сайте умеренно, последовательность действий пользователя на таковом сайте так же предсказуема вполне. Выбрать рубрику (первый раздел), увидеть конечное количество подрубрик, просмотреть документы в подрубрике, получить нужную информацию. Но если документов на сайте десятки тысяч? Сторублевки? Легко ориентироваться в кратком количестве рубрик или подрубрик, но за это приходится расплачиваться целое всякой меры длинными пейджингами.

Пейджинг

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

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

Поиск

Поиск на веб-сайте должен быть. И даже если это сайт совсем мелкий, даже если целого 10 страниц - сервис поиска - это типичный представитель "вторичной навигации", который позволит посетителю сайта получить нужную ему выборку (и, возможно, нужный ему документ) за один шаг. Посетитель-то не в курсе, что у вас целого 10 страниц сайта! Или 100, или 1000, или миллион. Анализ статистики Библиотеки Сайтостроительства показывает четкие цифры - из каждых 200 посетителей 35 пользуются формой поиска для того, чтобы найти нужную статью. При этом задача - как делать поиск по сайту - не стоит до тех пор, пока ваш сайт среднего объема; так же как и в событии рубрикатора, пейджинга и других типов навигации, загвоздки начинают вырисовываться с ростом сайта, по сути - те же. Результатом поиска может быть оглавление из сторублевок позиций, которые пользователю придется листать (рассмотренный выше пейджинг) по 10-20 штук, т.е. уже неверно, уже следует искать какое-то альтернативное решение.

Альтернативным решением может быть внедрение на сайте "продвинутого поиска", поиска по дополнительным критериям. Наиболее часто используемые, уже привычные дополнительные критерии - это ограничение:

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

Обоснованное дело, что выводить таковую сложную форму ни на первой странице сайта, ни на скрытых информационных страницах никто не будет. Как правило уже привычное и хорошее решение - оставлять на целых страницах сайта простую форму поиска (по ключевому паролю или же словосочетанию) и ссылку на страницу с сложным поиском. Альтернатива - использовать синтаксис для построения более сложных запросов в рамках простой формы поиска - операторные скобки, символы для объединения речей в запросе или исключения, метки и слова-команды. Можно рядом с блоком простого (да и продвинутого) поиска всегда держать ссылку на документ-хелп с описанием этого синтаксиса. Только кто таковым синтаксисом будет пользоваться? И если аудитория сайта - веб-разработчики или продвинутые пользователи (как, примеру, в деле нашего проекта - Библиотеки Сайтостроительства) - здесь можно хотя-бы предложить посетителю таковой сервис. А эсли это сайт по торгу бытовой техники (где хороший наглядный поиск свободно жизненно необходим)? Какова допустимость того, что посетитель захочет изучать таковой синтаксис для того, чтобы совершить одну покупку? Или не совершить...

Кроме того, внедрять реальность использования синтаксиса на сайте имеет смысл тогда, когда диалект запросов будет тщательно стандартизован, когда w3c.org опубликует убежденные стандарты, когда кроме интуитивно обоснованных операторов единый стандарт будет известен для построения любых сколь угодно сложных запросов. Когда в школах на ведущих уроках информатики (чем там детей грузят? Бейсиком по-прежнему?) школьники как таблицу умножения станут заучивать основные правила и механизмы поиска - для того, чтобы использовать в будущем не в рамках веб-разработки (вернее, разумеется, не только в рамках) - но и для простого бытового сёрфинга по сети, и каждая ведущая домохозяйка на автомате наберет сложный запрос в одном текстовом поле так же быстро, как и пересчитает сдачу в районном супермаркете.

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

Материалы по теме

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

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

    * в админке же задаем поиск по нескольким ключевым высказываниям из статьи, которая ставится (генерится) сейчас.
    * из полученного поиском реестра статей чекбоксами отбираем подходящие.
    * и одним движением десницы из выбранных чекбоксами позиций генерим ненумерованный (к примеру) перечисление статей с подзаголовком "статьи по теме"

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

Навигация из адресной строки

И раз уж заговорили про местоположения документов... Удивительно, как разработчики сопротивляются включению в системы управления осуществимости задавать те самые "безупречные урлы", которые так любят оптимизаторы и спецы по юзабилити веб-сайтов! И ведь вот что странно - в совместном объеме разработки системы подобный сервис не представляется настолько уж сложным, и документации много, и код не утяжеляет. И целое равно программисты выискивают пути, находят причины, поясняющие, почему этого не надо делать. Если раньше основная причина, по которой формирование справедливых урлов было свободно необходимо - тот факт, что поисковики плохо индексировали или не индексировали вовсе местоположения, содержащие динамически формируемые параметы, хоть как-то убеждала программеров в том, что напрячься таки придется, то сегодня - когда целое приличные поисковые системы индексируют документы с любым надписью в местоположении - первый козырь любители безупречных урлов утратили.

Дальше спор развивается так: программисты говорят "раз поисковики индексируют любые урлы, необходимость для SEO в подобном сервисе отсутствует". Однако исследования показывают, что наличие ключевых речений в урле влияет на плотность ключевых предлогов в документе и учитывается при подсчете релевантности документа запросу в том же Google. Программисты говорят: "местоположение формируется на латиннице, для русскоязычной аудитории русское глагол в транслитерации ключевиком не будет", однако подобное объяснение еще оправдано для, скажем, частных дневников, где ВасяПупкин делится откровениями из личной жизни - да, смысл формировать местоположение сорта "/Kak-Ya-Provel-Leto.html" или "Каk-My-Smotreli-s-Lenoi-Kino.html" большого нет. Но. Ситуация меняется для инфоресурсов, посвященных, к примеру, программированию, веб-разработкам, где большая отрывок ключевых словоформ в надписи, и по смыслу будет написана на английском речи. Никто не напишет в статье по-русски "Си плюс плюс" или "Айакс" - будет использоваться справедливое написание, которое вполне можно использовать в качестве имени документа. Программисты говорят "Навигацию через адресную строку пользователи не используют" - и приводят в качестве примера результаты исследований заокеанской аудитории (которая, по большей отделения, вообще не знает, что таковое местоположение документа). А вот, к примеру, я - использую. Многие знакомые мне веб-разработчики - используют. Открывая большое количество закладок в браузере по заданной теме поиска, в значительной ступени ориентируются на местоположение документа - какой сайт, какой раздел, какое имя страницы.

Что еще можно сказать по поводу этой малопопулярной "вторичной навигации" - через местоположение документа? Вот в форуме веб-разработчик получил консультацию по теме справедливых урлов: "Свободно наши оптимизаторы убедительно просят писать код не ссылками в обличьи GET запросов, а приводить их к сорту ЧПУ и потом разбирать скриптом или при помощи mod_rewrite, объясняют это тем, что гугль (к примеру) таковые сайты "лучше" индексирует и ранкует.." - что, как ему уже объяснили, не соответствует действительности. Однако. Есть незначительная разница меж "индексирует" и "лучше ранкует". Другое дело,что при ранжировании учитывается слишком много разных параметров. И при этом можно привести много примеров, когда документ, имеющий местоположение с т.наз. "справедливым надписью", но содержащий невостребованный контент,будет находится ниже в выдаче, чем полезный документ с надписью в местоположении с параметрами. Дмитрий Давыдов писал в блоге, что можно делать все-все правильно, но это не принесет ожидаемого результата. Правильно ли съедать по одному яблоку каждый день? Врачи рекомендуют, и вроде правильно. Но если вы будете так поступать, в вашей жизни НИЧЕГО НЕ ИЗМЕНИТСЯ. "Быстро, спросите жену, что лучше, мужчина в начищенных ботинках или в аморальных (кстати, надо будет рассказать, как администрация губернатора Егорова грозилась стереть меня в порошок, после того, как я сделал сюжет, о том, что министр Греф приехал в Калининград в задрипанных, стоптанных ботинках)? Женщины ответят, что в начищенных лучше. ОК, начистите штиблеты, выйдите их дома, подойдите к каждый женщине, и … и ничего."

Так и здесь. Можно не делать красивые урлы и раскрутить проект до вполне достойного состояния. Можно морочиться с валидной версткой и справедливыми урлами и... ничего. Ну, и чтобы не совсем пустынный получился у меня месседж - вот ссылка на статью о том, как разбирать те же урлы: ЧПУ и PHP (revisited)

Теги

Еще один пример вторичной навигации - назначать документу "метки", или "теги". Как правило, используется одна-две-три метки на один документ. На сайте каждый тег является ссылкой, при нажатии на которую посетитель получает выборку целых надписей, которым присвоен тег с тем же именем. Такая выборка в принципе будет отличаться от целых выше рассмотренных навигационных систем. Навигация через метки - более гибко формируемая, чем рубрикатор, т.е. нет необходимости во-первых переделывать дерево рубрик (для пользователя же лучше если система рубрик будет относительно стабильной и не сильно глубокой), и, кроме того, каждый из документов реестра, полученного через тег, может принадлежать разным рубрикам, т.е. выборка осуществится "перекрестная" - по целым рубрикам сайта. Будет отличаться такая выборка и от результатов поиска по сайту (по должному эллинизму) - т.к. в результатах поиска будут ссылки на целое документы, в которых это словоформа присутствует, в выборке же по тегу - только те, которым этот тег назначен. И, конечно же, будет отличаться от выборки "статьи по сайту" - ибо для больших проектов вы в любом случайности в этот перечень поставите конечное количество документов, как правило не более 10. Причем этот регистр редактор (тот, кто добавляет документ и подготавливает перечисление) целое равно модерирует вручную, укорачивая его по мере своего представления о соответствии своей статье. Назначение же тега (тегов) документу дает допустимость получить еще одну выборку, которая будет (возможно) более полной, чем каталог "статей по теме", при этом более релевантной конкретному причастию, чем выборка из одной рубрики (кроме того может быть и так, что документы таковой выборки будут из разных рубрик), и более удобной, чем результаты поиска.

Меж прочим, введение ТЕГов на сайте здорово может облегчить жизнь редакторам-модераторам. Типичный пример - создание FAQ`а на основании дискуссий на форуме: представьте себе, что в результате горячих споров и обменов опытом, усмотрениями как экспертами, так и новичками было открыто хорошее решение по какому-то проблеме. Проходит время. Приходит очередной новичок, который задает тот же дилемма. Рекация старожилов форума? "Учитесь пользоваться форумом!" и целое, и ответа на задача не дождешься. В живых форумах эта препятствие частично решается с помощью ручного создания FAQ`ов, однако если бы можно было самым значимым отчетам на форуме присваевать определенную метку и вес - и по этой метке автоматом генерился бы новый пост в теме для отысканных решений, то полезной информации в тех же форумах было бы больше, а ее нахождение - быстрее и удобнее (кст. идея навеяна сообщением Алексея Копылова "На успение форумов")

И последнее. Реальность генерировать урл в соответствии с тегом, который может индексироваться поисковиком. Вероятность эта может быть весьма приятна для владельца сайта, но есть возможность, что недобрые угольные оптимизаторы возьмут на вооружение таковой метод, что приведет к тому, что пользователи поисковиков будут возмущены результатами поиска, в которым им выдаются табели ссылок по ключевому клятве, типа результаты поиска с другого сайта вместо искомого документа. Что, кстати, может привести к тому, что сайт попросту забанят. щебень гранитный 5 20 . Трудоустройство в Салоны красоты: курсы парикмахеров . Парикмахер-стилист на дом.