proview.ruКонструирование сайтов → CMS - модели навигации для веб-сайта

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`ов, однако если бы можно было самым значимым сообщениям на форуме присваевать определенную метку и вес - и по этой метке автоматом генерился бы новый пост в теме для найденных решений, то полезной информации в тех же форумах было бы больше, а ее нахождение - быстрее и удобнее (кст. идея навеяна заметкой Алексея Копылова "На смерть форумов")

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

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

Популярное