"Я знаю AJAX, ЧПУ, CMS и много других страшных слов"

Немного перефразированную шутку из названия я часто вспоминаю, когда посещаю многие сайты, популярные и не очень. Web-мастера, начитавшись умных слов и получив в свое распоряжение готовые CMS сайтов и фреймворки, облегчающие разработку, начинают их активно использовать. И в результате очень часто в жертву приносится такая важная составляющая сайтов, как юзабилити. Если единственное, для чего вам нужен сайт - это завешать его порнушными баннерами и поп-апами в три слоя, разместить стыренный контент исключительно на платных файлообменниках, чтобы любыми средствами срубить бабла, то валите отсюда подальше, мне с такими мразями говорить не о чем. Эта статья для немногочисленных web-мастеров, которые стремятся к тому, чтобы на их сайт посетителям хотелось вернуться, чтобы от результатов их труда все получали только удовольствие. Я никого не хочу ни в чем убеждать, но если кто-нибудь после прочтения задумается, значит моя цель достигнута. Мало знать современные технологии, надо уметь их грамотно применять. Вполне возможно, что какие-то вещи будут для вас очевидными, просто наболело :)

В современном web-строительстве очень популярно использование так называемых ЧПУ - "человекопонятных УРЛ". Это красивые, интуитивно понятные ссылки, формируемые из названия раздела и статьи. Например:

http://www.site.ru/category/subcategory/article_name
При обращении к такой ссылке она разбирается средствами сервера на отдельные параметры и дальше обрабатывается как обычная ссылка. Один из основных принципов формирования ЧПУ заключается в том, что при обрезании ссылки до последнего слеша, посетитель должен попадать на вышестоящий раздел сайта. Это хорошо и правильно, но до тех пор, пока в ссылке не начинает присутствовать дата:

http://www.site.ru/2009/01/25/article_name
По логике вроде бы все правильно: дата добавления статьи, название статьи. При обрезании ссылки до дня получаем все статьи за день, до месяца - за месяц и т.д. Проблема в том, что такая система формирования ссылок хорошо подходит для новостных сайтов, но категорически не годится для основного контента порталов. Информация на новостных сайтах привязана ко дню, когда случилось это событие и после публикации на сайте вряд ли когда изменится. А в популярных портальных движках (названий не указываю, кому надо и так поймет) дата публикации обычно равна дате последнего редактирования статьи, и вот тут начинаются косяки. Реальный случай из жизни: на каком-нибудь сайте выложили какую-то нужную мне информацию. Я зашел на сайт, добавил ссылку в закладки браузера или послал ссылку товарищу в аську. На следующий день пользователь, разместивший статью, отредактировал ее. В результате дата изменилась, ссылка, соответственно, тоже, а сохраненная ранее ссылка становится недействительной. Приходится заново тратить время, искать нужную статью, что никак не добавляет положительного отношения к сайту. Аналогичная ситуация складывается, если идентификация в ЧПУ жестко завязана на полном названии статьи. Удобно? Нет.

Отсюда мысль номер один.

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

Пример ссылки, сформированной по этому правилу:

оригинальная ссылка:
http://www.site.ru/category/subcategory/id34_article_name

она же после редактирования даты и/или содержимого статьи:
http://www.site.ru/category/subcategory/id34_article_name

она же после редактирования названия статьи:
http://www.site.ru/category/subcategory/id34_renamed_article
Как видите, в любом случае извлечь уникальный идентификатор новости из ссылки не составит труда, а посетитель сразу же попадет к запрошенной странице.

Теперь немного о формировании самого ЧПУ в вашем движке. С идентификатором разобрались, его лучше ставить сразу перед названием статьи и отделять каким-нибудь символом, например подчеркиванием "_". А как в большинстве движков обрабатывается название статьи? Русские названия статей переводятся в транслит, в полученном названии символы, не являющиеся буквами и цифрами, заменяются на другие, например на то же подчеркивание. Обычно на этом обработка и заканчивается. В результате из названия статьи "Наш девиз: 'Партия - ум, честь и совесть эпохи!'" получается такой шедевр:

http://site.ru/id1917_nash_deviz___partiya_-_um__chest_i_sovest_epohi__
Уже узнали десяток популярных сайтов? Да. Красиво? Нет. Давайте тогда определим порядок формирования красивых ЧПУ из названия статьи: транслитерация, перевод символов в нижний регистр, замена всех без исключения символов, не являющихся латинскими буквами и цифрами, на символ подчеркивания, замена двух и более идущих подряд подчеркиваний на одно, удаление начального и конечного подчеркивания (если они есть). Сформированный ЧПУ выглядит так:

http://site.ru/id1917_nash_deviz_partiya_um_chest_i_sovest_epohi
Еще одна популярная технология web-строительства - это RSS-каналы. Они используются на многих новостных сайтах и информационных порталах, но и тут не все гладко. По стандартам формирования RSS в них обязательно должна присутствовать дата и время публикации новости. При редактировании новости в некоторых CMS обновляется дата и время ее публикации, и эти данные передаются в RSS-канал сайта. RSS-агрегаторы (программы и сервисы для чтения RSS-каналов) добросовестно получают обновленные данные, и видя, что время изменилось, считают, что новость не отредактирована, а добавлена новая. Как результат, в агрегаторе накапливается целая пачка практически одинаковых новостей, их количество ограничено только количеством редактирований и частотой обновления канала. Удобно? Нет.

Мысль номер два.

Если на сайте допускается изменение времени публикации хотя бы одной статьи, то в RSS-канал должны попадать только даты публикации статей, а время подставляется одинаковое и фиксированное для всех статей.

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

http://site.ru/frameset.php?page=magazin
Скрипт frameset.php генерирует фреймовую "обертку" сайта и открывает в нужном фрейме нужную страницу. К тому же такая реализация ссылок очень положительно скажется на индексации сайта поисковыми роботами.

Аналогичная ситуация с AJAX. Это бесспорно очень полезная технология, которая позволяет обмениваться данными с сервером через JavaScript и обновлять только нужную часть страницы без перезагрузки всей страницы. Плюсов много: это и экономия трафика, и скорость обновления страниц, и интерактивность. Но для навигации использовать AJAX надо с осторожностью. Вполне допустимо использовать навигацию без перезагрузки страницы для постраничного листания краткого содержания новостей внутри категории, для подгрузки списка статей в карту сайта, для поиска, фильтрования статей и т.п. Но! Категорически недопустимо подгружать без обновления так называемые страницы нижнего уровня, то есть те страницы, с которых не предусмотрен переход к просмотру более подробной информации. К таким страницам относятся, например, полный текст статьи, комментарии к картинке в галерее, развернутые результаты голосования. Причина простая. Когда посетитель хочет передать товарищу ссылку на материал с сайта или занести страничку в закладки, то в подавляющем большинстве случаев он просто копирует содержимое адресной строки браузера. Всякие решения с отдельными полями типа "Постоянная ссылка на новость" и "Чтобы передать новость другу скопируйте эту ссылку" обычно не срабатывают, пользователи не обращают на них внимания.

Мысль номер три.

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

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

http://www.site.ru/page#block_name
При переходе по такой ссылке JavaScript обрабатывает имя якоря и показывает запрошенный блок или загружает его через AJAX. С отключенными скриптами полученный результат будет ошибочным.

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

Комментарии

Добавить комментарий

Для вставки цитаты выделите текст и нажмите сюда

Имя*:

Текст комментария (не более 2000 символов)*:

*Все поля обязательны для заполнения.

Комментарии, содержащие рекламу, ненормативную лексику, оскорбления и т.п., а также флуд и сообщения не по теме, будут удаляться. Нарушителям может быть заблокирован доступ к сайту.