БИБЛИОТЕКА CАЙТОСТРОИТЕЛЬСТВА

новости, статьи, обзоры по веб-дизайну и графике, разработке, оптимизации и продвижению веб-сайтов

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

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

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

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

---

Н O B O C T И

:: Сайтовладелец как козел отпущения
Ответственность владельца сайта за действия пользователей: с ростом популярности ресурса — будь то СМИ, форум или блог — контролировать комментаторов становится все труднее. ...>>

:: Самые дорогие слова в AdWords, "Директе" и "Бегуне"
Компания Google выпустила инструмент Keyword Tool для поиска синонимов среди ключевых слов, а также для просмотра статистики по ним и сравнения цен. ...>>

:: Создатель Jabber работает над системой идентификации контента
Джереми Миллер разрабатывает новую систему под названием MicroID, которая должна упростить процесс идентификации авторов онлайновых публикаций или лиц, владеющих правами на контент. ...>>

:: Google разрабатывает новый интерфейс для поисковика
Пока обновлённая страница Google не доступна непосредственно после загрузки поисковика, да и изменения на ней по сравнению с традиционным представлением минимальны. ...>>

:: Суточная аудитория рунета увеличилась на 29 процентов
Доказательством того, что веб становится все более серьезным игроком на рынке рекламы, является усилившееся в последнее время внимание телекомпаний к своим представительствам в Сети. ...>>

:: Photoshop CS2 на кончиках пальцев. Виртуозная техника
Обучайтесь работе в Photoshop на реальных задачах! Мы представляем первое полное руководство по Photoshop CS2, полностью построенное на практических заданиях. ...>>

:: Бесплатный семинар по анализу, оптимизации, продвижению и управлению ресурсом
На семинаре будут рассмотрены вопросы оптимизации сайтов для поисковиков и продвижения в Интернете, анализа аудитории сайта и оценки эффективности рекламных кампаний. ...>>

:: Microsoft готовит инструменты для Ajax-программирования
Новый инструментарий под кодовым названием Atlas предназначен для создания веб-приложений нового поколения, с использованием асинхронного JavaScript и XML. ...>>

:: AjaxWrite: онлайновый аналог MS Word
Новый текстовый веб-редактор AjaxWrite является практически полным аналогом Microsoft Word. Даже по внешнему виду их трудно различить. ...>>

:: Этот одноразовый РИФ
Юбилейный РИФ вызывает смешанные чувства. Железной поступи нового спонсора в лице государства почти не было слышно, если не считать выходки РБК. ...>>

:: РИФ 2006, день третий. Удовлетворение синтетических потребностей в убийстве традиционных СМИ
Третий день РИФа организаторы почему-то обозвали "Днем регионов". При этом региональную специфику, видимо, нужно было слишком внимательно разглядывать....>>

:: "Британника" опровергает сравнение с "Википедией"
Как известно, во время сравнительного исследования эксперты изучили избранные научные статьи из двух энциклопедий. Оказалось, что количество ошибок в "Британнике" и "Википедии" практически одинаково. ...>>

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

:: Понравился ли Рунету РИФ-2006?
На прошлой неделе состоялось знаковое мероприятие для Рунета — Российский Интернет Форум. Этот РИФ стал юбилейным, 10-ым по счету. В этой связи мы решили опросить участников мероприятия. ...>>

:: РИФ 2006, день второй. Правильное мнение от Microsoft и мастер-класс по дорвеям. О засланных блоггерах и навязчивых кредитках.
Второй день на РИФе начался как-то сонно, что совсем не удивительно, если вспомнить праздничный банкет по случаю десятилетия. Однако посмотреть Владимира Долгова на утренней секции собралось немало народу. ...>>

:: Статистика: у веб-новостей становится все больше читателей
Согласно отчету, опубликованному организацией Pew Internet & American Life Project, в 2005 году свыше 50 млн американцев использовали интернет в качестве своего основного источника новостей. ...>>

:: Adobe Fully Loaded — заряд вдохновения для творческих людей!
В течение 2006 г. Adobe Systems проводит в Европе рекламную кампанию Adobe Fully Loaded. 21 февраля в рамках этого мероприятия в Москве прошла однодневная конференция. ...>>

:: В PHP появится возможность генерации отчетов
В компании Zend Technologies, являющейся разработчиком языка сценариев PHP, собираются реализовать в нем средства интеграции с системой генерации XML-отчетов BIRT 2.0 ...>>

:: Новый инструмент быстрой проверки знаний в области Интернет-рекламы
Агентство интернет-маркетинга "Артон консалтинг" совместно с группой экспертов разработало и представило широкой общественности "Тест Интернет-рекламиста". ...>>

:: Mozilla будет платить разработчикам
Организация Mozilla Foundation планирует использовать часть из своих миллионных доходов для оплаты труда активных членов сообщества разработчиков. ...>>

:: Выходит альфа-версия Firefox 2.0
Версия Firefox 2.0 для разработчиков предназначена для тестирования внутренней инфраструктуры браузера, поддерживающей новые возможности закладок, или "мест" (Places). ...>>

:: Russian Flash Awards "The Past", первый русский конкурс флэш-проектов
"Russian Flash Awards" - Первый в России конкурс flash-сайтов, flash-игр и роликов номинированных по категориям "art", "анимация", "коммерция" и др. ...>>

:: РИФ-2006, день первый. "Яндекс" — продавать, поведенческий таргетинг — исследовать!
Десятый РИФ начали сопровождать пессимистические ожидания еще до его открытия. Причина крылась в позиции игроков "большой тройки", которые решили проигнорировать юбилейное мероприятие в этом году. ...>>

:: Изменяется структура настроек в рекламных кампаниях Яндекс.Директа
В связи с ростом Рекламной сети Яндекса с 22 марта 2006 года изменяется структура настроек в рекламных кампаниях Яндекс.Директа. ...>>

:: Организаторы eTarget об итогах конференции
В Москве состоялась конференция "Управление аудиторией и реклама в интернете" (eTarget). Организаторы - компании "Ашманов и Партнеры", "Бегун", Mail.ru, Subscribe и "Яндекс". ...>>

---

С Т A T Ь И

:: Черновой стайлинг [веб-дизайн]
Показывать неподготовленному зрителю нестилизованный HTML нельзя. Но и дизайнера нельзя заставить приводить в человеческий вид, когда половины системы еще не существует, а то, что существует, может кардинально поменяться. ...>>

:: На смерть форумов [управление сайтом]
Практически всякий уважающий себя интернет-ресурс несет на своем борту форум, где постоянные посетители сайта обсуждают содержание, обмениваются опытом, знакомятся, треплются, но даже идеальный форум обладает недостатками, которые и рассмотрены в статье. ...>>

:: Как я раскрутил форум [раскрутка сайта]
Как показывает практика даже довольно опытные вебмастера, первый раз занимаясь форумом сайта допускают ряд ошибок. Часть моментов, которые я упомяну, ранее в подобных статьях я не встречал, поэтому решил их осветить. ...>>

:: SEO-специалист делится своими секретами [оптимизация сайта]
Вы наверняка слышали о таком явлении как раскрутка сайта, но что это означает на самом деле? ...>>

:: Adobe Illustrator для профессионалов: советы на любой вкус [веб-графика]
Подборка полезных советов — продолжение статьи "Adobe Illustrator для профессионалов" в журнале Publish. Начинающие узнают некоторые тонкости, а специалисты проверят себя и, возможно, почерпнут что-то новое. ...>>

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

:: Искусственные клики вызывают все больше беспокойства у рекламодателей [интернет-реклама]
Фальсификация кликов все больше беспокоит как рекламодателей, так и агентства - об этом говорят данные Организации профессионалов по поисковой оптимизации (SEMPO). ...>>

:: Изменения блогов: управление развитием [контент для сайтов]
Блоги развиваются постоянно. Они подвергаются изменениям даже когда мы думаем, что они не меняются никоим образом. Давайте проанализируем несколько путей развития блогов и возможные причины этих изменений....>>

:: Search Engines Here to Convert You [интернет-реклама]
Задумывались ли Вы о том, что пользуясь поисковыми сайтами Вы можете стать объектом действий рекламодателей по привлечению Вас в ряды своих клиентов? ...>>

:: Поведенческий фактор в целевой рекламе: взгляд в 2006 [интернет-реклама]
В своей статье от 21 декабря 2005 г. Энди Чен пишет о тенденциях развития рекламы, ориентированной на целевую аудиторию по поведенческому фактору и делает прогнозы ее развития на будущий год. ...>>

Большее количество новых материалов вы найдете на сайте Библиотеки

---

Ф О Р У М Ы [горячие темы]

:: peanch: Re: Каждый уважающий себя дизайнер дожен знать! [веб-дизайн]
"без применения таблиц везде где ни попадя" оно как бы правильно, и на будущее хорошо.. но если требование - первая строка файла <DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> и нельзя использовать table, а только div , то это такоооой геморой......»

:: nun: Векторная графика - кто где и сколько лет? [веб-графика]
Интересно бывает заглянуть в старые архивы чего-бы то ни было. Рисунки старые свои посмотреть. Вот этот, к примеру, рисунок был нарисован в пятом Corel Draw. А дома, на одном из первых архивных дисков есть серия-клипарт векторов, рисованных еще в четвертой версии. Интересно - кто в чем рисует вектора и с каких версий? P.S. почему-то макеты собираются в Иллюстраторе, а вот когда хочеться просто порисовать - тогда комфортнее Corel. А у вас?...»

:: nun: сss-метод скругления углов [css]
...нашлась ссылка на легкий и красивый css-метод скругления углов (улучшенный по сравнению с предыдущей версией), который позволяет: задать диаметр углов одного слоя; двум слоям; задать прозрачность и градиент; сделать красивое меню – закладку; нарисовать кнопки; закрасить любое количество симпатичных боксов; сделать фон, заголовки, контуры; и просто оформить всю страницу целиком – хоть маленькую, хоть большую. ...»

:: nun: Всплывающие окна (Java Script) [верстка]
Класс Java Script, с помощью которого можно реализовать прикольные всплывающие окна - всплывают они очень оригинально, с уже загруженным содержимым, при закрытии - не менее оригинально "растворяются". Основные параметры (размеры, положение на экране) и дополнительные - эффекты проявления и исчезания, прозрачность окон - настраиваются довольно просто. Информация с сайта Prototype Javascript Window. ...»

:: gnum: CMS для сайта "статейной" направленности [cms]
Какие есть хорошие, желательно апробированные CMS для создания сайтов-библиотек. Нужен многоуровневый каталог, поиск и т.п. Обязательно - PHP, MySQL, OpenSource, Freeware ...»

:: gnum: FAQ раздела. [веб-программирование]
Текст постоянно дополняется и обновляется. Если у вас есть замечания, пожелания и дополнения к этому тексту - выносите своё предложение на обсуждение. ...»

:: minaton: Поисковики и ЧПУ [оптимизация сайта]
...Может быть поисковики научились склеивать страницы с параметром sessionid (sid как у этого форума), но все остальное , если это разные страницы, то они разные и в индексе. Вообще уже нет такой серьезной проблемы с параметрами в URL у современных поисковиков. Вроде бы у Рамблера было ограничение на количество страниц, которые забирает робот с одного сайта, если они динамические. Но сегодня, если в URL есть два-три параметра – это не проблема. Посмотрите выдачу того же Яндекса, все форумы прекрасно индексируются. ...»

:: nun: Веб-обзор от Алекса Экслера [Интернет-реклама]
Обзор от 21 марта 2006 посвящен интернет рекламе, контекстной рекламе, и называется "Контекстная реклама, LiveTV, I2R, аватары, будильники". Помимо прочего, что очень порадовало, в обзоре упомянута наща библиотека = всего один абзац со ссылками на основные разделы, с превьюхой скриншота с главной страницы. Это приятно и правильно. ...»

:: gnum: Регистраторы доменов [Продвижение веб-сайтов]
Какие есть регистраторы для интернациональных зон? Чтобы цены у них были подешевле. А ещё - желательна возможность оплаты через WM. ...»

:: minaton: Список званий для форума [Обсуждение Библиотеки i2r и форума]
Предлагаю такое: бит -> байт -> кило -> мега -> гига -> терра. Можно еще попробовать с уровнями знания компьютера: юзер -> пользователь -> программер -> девелопер -> админщик -> кул хакер. А можно простыми словами: интересующийся -> разбирающийся -> знающий -> продвинутый -> спец -> гуру. Или вот так для тех кто понимает: header6 -> header5 -> header4 -> header3 -> header2 -> header1. ...»

:: gnum: Анекдот [Пофлеймить и поговорить за жизнь]
Гаишник отчитывает водителя: - Ну как же так? Перестроились через ряд, превысили скорость в два раза! Я ещё понимаю "Мерседес" - но вы! Вы! Водитель трамвая!!! ...»

---

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

---

::: рассылку ведет:     Татьяна Вукс      http://www.i2r.ru     2006 :::