2009:

• Февраль #234

2008:

• Август #233
• Июнь #232
• Март #231
• Февраль #230
• Февраль #229
• Январь #228

2007:

• Ноябрь #227
• Октябрь #226
• Октябрь #225
• Сентябрь #224
• Сентябрь #223
• Июнь #222
• Июнь #221
• Май #220
• Апрель #219
• Апрель #218
• Февраль #217
• Январь #216

2006:

• Декабрь #215
• Ноябрь #214
• Октябрь #213
• Октябрь #212
• Октябрь #211
• Сентябрь #210
• Сентябрь #209
• Сентябрь #208
• Август #207
• Июль #206
• Июль #205
• Июль #204
• Июнь #203
• Июнь #202
• Май #201
• Май #200
• Апрель #199
• Апрель #198
• Апрель #197
• Март #196
• Март #195
• Март #194
• Февраль #193
• Февраль #192
• Февраль #191
• Январь

2005:

• Декабрь
• Ноябрь
• Октябрь
• Сентябрь
• Август
• Июль
• Июнь
• Май
• Апрель
• Март
• Февраль
• Январь

2004:

• Декабрь
• Ноябрь
• Октябрь
• Сентябрь
• Август
• Июльские выпуски
• Июньские выпуски
• Майские выпуски
• Апрельские выпуски
• Мартовские выпуски
• Февральские выпуски
  
• Январские выпуски

Архив на Subscribe.ru

• 2003
• 2002
• 2001

cтатьи по теме:

• обзор пособия для авторов рассылок
  
• эффективная рассылка

Библиотека Сайтостроительства. Октябрьские выпуски.

• 27.10.05. Bыпуск #183

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

  Как мило прозвучала фраза одного веб-разработчика о том, что слишком много времени мы проводим за компьютером – от 6 до 8; и как верно дополнено вторым – и от 8 до 12 – в сети.

  Сетевая жизнь затягивает, становится нормой. Новости из Интернета легкодоступны, причем в большем объеме, да еще с оперативными комментариями и обзорами от значимых личностей. Сложно пропустить хоть какое-то достойное внимания событие – онлайновые друзья и знакомые всегда побеспокоятся о том, чтобы прислать нужную ссылку или сообщить по почте/аське. Самые смешные анекдоты, самые достойные рассказки или прикольные картинки – все становится известным онлайновому сообществу за считанные минуты-часы.

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

  Но она есть – оффлайновая жизнь; и обычные, нормальные люди ходят по улицам, смотрят телесериалы и читают детективные романы, спорят, ругаются и мирятся, любят и ненавидят друг друга. Среди таких нормальных людей есть умницы и глупцы, есть дауны и гении, есть просто – интересные люди, они живут и работают, получают информацию привычными для них способами. Ну и что, что они знают о том, что такое *Интернет* только в общих чертах? Этого уже не мало, они знают, что сеть – есть, что в сети можно найти информацию, что в сети можно разместить информацию.

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

  Дальше события могут развиваться совершенно непредсказуемо – многое будет зависить от того, насколько серьезно наш заказчик относится к своему будущему проекту, насколько отчетливо он осознает необходимость в сайте; проанализировал ли он рынок, оценил ли наличие сайтов-конкурентов; насколько ясно видит, сколько денег следует в проект вложить и какую прибыль от этого вложения ожидать.

  Зачастую ясного видения целей и задач проекта у клиента нет, в большинстве случаев – неопределенность, желание получить "что-то эдакое...", однако если человек появился на пороге дизайн-студии и объявил о желании разработать себе сайт, здравая политика сотрудников студии, менеджеров – удержать его, сделать своим клиентом; в этом случае на такого "неопределившегося" заказчика как правило тратится приличное количество времени – не только выяснить, что же ему нужно, но и прочитать некоторое количество лекций о том, что из себя представляет интернет-рынок, какие бывают сайты (имиджевые, презентационные, информационные, коммерческие электронные магазины), какие сервисы желательно внедрить в структуру сайта, какие особенности поддержки сайта могут возникнуть уже после того, как сайт разработан и запущен, и как зависит качество разработки с последующими затратами на эту поддержку.

  Достаточно сложно вести такую "просветительскую" беседу в том случае, если заказчик совсем "нулевый" и неподготовленный. Рассказывать приходится о совершенно разных вещах, показывать, приводить примеры, оценивать статистику, писать планы расчетов на различные типы разработки. Конечно, можно проще – заказчик объявляет: "У меня есть 800 долларов, мне нужен простенький сайт..." - разработчик отвечает: "Давайте ваши деньги, через неделю будет вам сайт"... Однако в большинстве случаев лекционное "окучивание" клиента приводит к тому, что тот готов увеличить бюджет проекта ради разумного вложения в такую разработку, которая не будет являться бесполезной тратой денег.

  Разработчику от такого решения выгода двойная: с одной стороны, над денежным проектом всегда приятнее работать :), с другой – когда проект изначально не мертворожденный, развивающийся и востребованный, через пару-тройку-пятерку лет уже известный в рунете (а то и в мире) – как же приятно разработчику слышать: "А вот сайт такой-то, такой весь крутой проект – это же ж твое детище? Круть..." И действительно, с ростом значимости разработанных проектов растет и значимость портфолио разработчика, его статус и известность.

  И это не единственная выгода для разработчика от успешного (не только в плане дизайна или движка, скорее – в плане востребованности и развития) проекта. Не редкая ситуация, когда заказчик, вполне удовлетворенный грамотной разработкой предыдущего проекта, возвращается к тому же разработчику с новой своей идеей (и здесь – опять по новой: анализ, выбор оптимальной стратегии, обсуждение рациональной ценовой политики – аккуратно, чтобы и клиента, с одной стороны, не оттолкнуть, и проект исполнить не менее качественный и способный жить/развиваться), или же рекомендует именно этого разработчика своим коллегам по бизнесу, друзьям, родственникам и знакомым кролика.

  И все же очень, очень сложно проводить такое окучивание, если клиент не готов, когда нет у него достаточно знаний о технологиях, которые он намерен внедрить, нет уверенности в необходимости разработки, нет *намерения* СДЕЛАТЬ. Когда приходит очередное наивное чудо и озвучивает ненавидимую всеми разработчиками фразу: "А мне нужен *простенький* сайт, сколько это будет стоить?"

  Сколько стоит разработать сайт? Для того, чтобы ответить на этот вопрос, нужно задать клиенту изрядное количество вопросов – большинство начинающих владельцев сайтов имеют весьма искаженное представление о том, что такое "простенько". В некоторых, особо запущенных случаях проще сразу задать встречный вопрос: "Какой бюджет вашего проекта? Сколько вы готовы потратить на ваш сайт?"

  И вот, к примеру, клиент готов озвучить сумму: "Мне друзья сказали, что хороший дизайн сайта будет стоить не больше 500 некоторых условных едениц, а можно и подешевле – вот такому-то моему знакомому и за 100 сделали..." - "Неплохо, неплохо... так что – только за дизайн 500 – или все же это весь бюджет на весь проект?" - "А что вы ИМЕЕТЕ ВВИДУ??"

  Начинается следующий этап – расписываем базовую затратную часть на сайт:

  1. Оплата хостинга под сайт (цену определить можно только после того, как будет известно о уровне сложности проекта).
  2. Оплата доменного имени.
  3. Разработка дизайна сайта.
  4. Разработка (собственно сборка) сайта
  5. Работа контент-менеджера по наполнению сайта
  6. Услуги по его продвижению, регистрация в поисковиках, интернет-маркетинговый этап.

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

  "Итак, мне нужен очень-преочень простенький сайт-книжный магазин..." - "Оп-па, а это планируется именно электронный магазин, с возможностью оплаты с сайта, доставка и все такое?" - "Нет, что вы... нет. Там просто будут книги, которые покупатель сможет выбрать и заказать. Заказ отсылается на почту или даже совершается просто по телефону, который также будет указан на сайте. Для ленивых, но проживающих в умеренной удаленности от физического "склада" книг – возможность оплатить WebMoney – ладно, привезу я им эту книгу домой, не жалко... Стоимость книг – в среднем около 100 тех же самых условных едениц за штуку... хотя есть и подороже. Общее количество книг на сегодняшний день, информацию о которых придется разместить на сайте – около 1000".

  Из дальнейшего разговора становится ясно, что в рамках нашего простенького сайта необходимо будет эти книги распихать по трем базовым темам/рубрикам. В каждой рубрике, видимо, список книг придется разбивать на постраничные блоки (не давать же 300 инфоблоков на одной странице?), отсортированные в произвольном порядке, к примеру, просто по времени добавления (первые добавленные – дальше). Так же клиент желает видеть на сайте простенькие же фишечки, очень полезные и удобные, такие как *поиск*, *возможность оставить комментарий*, еще другие мелочишки...

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

  Вот так, в процессе общения вырисовывается картина "простенького" сайта – оптимальным решением и для разработчика, и для заказчика будет не разработка элементарного html-проекта, а вполне себе скромная и лаконичная система управления контентом. Которая, в свою очередь, решает следующие проблемы:

  1. Позволяет использовать "шаблоны".
  2. Позволяет разработать интерфейс для удобного добавления новых данных (в данном случае – книг), а так же их редактирования, удаления (или – скрывания).
  3. Позволяет реализовать более гибкую систему визуализации данных (сортировка по рубрикам, формирование пейджинга – постраничных списков).
  4. А уж поскольку все равно есть необходимость в использовании серверных скриптов – позволяет добавить некоторые ненавязчивые, но такие привычные сервисы – тот же поиск, уже не самый простой – поиск по автору, по издательству, и т.д.

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

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

  Читать полный выпуск...»

• 18.10.05. Bыпуск #182

  И снова здравствуйте, уважаемые подписчики!
  Очень славное время года - на улице красиво, холодно и мокро. Буйство красок радует дизайнерский глаз, контрасты, оттенки, тона очаровывают и печалят. В теплом офисе хорошо работается, клиенты подкидывают задачи - одна другой интереснее. Любопытный факт из практики: все больше заказов не на разработку сайта с нуля - на редизайн. "Сделайте нам конфетку" - чтобы креативненько, легонько, правильно, и чтобы для поисковых систем оптимизированно.

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

  В последнее время и в рунете, и в западном интернете много спорят о том, что же такое - услуги SEO/SEM специалистов, является ли SEO злом? Говорят о мусоре в выдаче - как пользователи поисковых систем, так и сами оптимизаторы. Однако означает ли это, что нужно продолжать делать неоптимизированные сайты? В недавнем интервью с сотрудником :) Google Маттом Каттсом (Matt Cutts) была озвучена следующая фраза: "Можно ли назвать SEO спамом? Ни в коем случае – когда-нибудь я сделаю заявление об этом в моем блоге. Перед нами множество примеров оптимизации в поисковых системах, которые относятся к разряду доброкачественных, и не являются спамом. Я имею в виду настройку сайта для лучшей его читаемости поисковыми роботами; подбор слов на сайте, исходя из того, что пользователи вводят в строке поиска, или основываясь на данных логов вашего сервера; сбор ссылок путем генерирования полезных идей или сервисов, чтобы люди ссылались на вас естественным образом. Для меня (как и для Google) спам - это оптимизация в поисковой системе, которая выходит за рамки наших требований качества - скрытый текст, скрытые линки, страницы-дорвеи, наполненные абракадаброй, которые еще и выполняют Javascript-редирект, и так далее."

  Но ведь даже простые вещи современные разработчики сайтов зачастую не учитывают! Буквально на днях звонил из Нью-Йорка один мой знакомый - его дизайнер нарисовал удивительно "креативный" эскиз, который уже утвержден боссом, только... а как же сделать из этого сайт? Вернее, эскиз уже разрезан, но каким образом можно в рамках утвержденного дизайна решить такие-то и такие-то задачи?! Перебрали несколько технических решений, простое (с использованием таблиц стилей) всем понравилось, однако вылезли кривости в визуализации при некоторых состояниях страницы (в частности, при смене языка - на некоторых языках названия и термины значительно длиннее оригинального английского написания, в результате чего креативный, но требуюший допиксельной состыковки модулей дизайн расползался). Предлагались и более технически сложные решения, и в определенный момент времени этот разработчик, осознав, что сложность реализации вырастает неконтролируемо, и даже избыточно, убедил босса (и дизайнера, соответственно) перерисовать эскиз. Уже с новыми тех-требованиями. В рамках всех задач, в том числе и той самой оптимизаторской. Дизайнеру пришлось прочесть несколько лекций о поисковых системах, об управлении содержанием, через двое суток эскиз был переделан полностью (он не стал менее креативным, однако не может дизайнер разработать эскиз проекта, если он не знает всех требований к нему и задач, перед ним стоящих).

  ---

  Ко мне обратился мой добрый знакомый; сказал, что в последнее время у него появляются периодически заказы на редизайн и оптимизацию сайтов для se, на продвижение веб-сайтов и т.д. Как правило он (и его руководство) эти предложения игнорировали, сейчас же стоит вопрос о том, что нужно эти заказы брать и под эту работу сформировать свою команду специалистов. Спрашивают ребята следующее: на первом этапе, для начинающей SEO-команды

  - Сколько человек брать в команду и чем каждый из них должен заниматься?
  - Какие работы по оптимизации/продвижению предпочтительнее отдавать на аутсорсинг (когда не рационально брать своего, но посредственного, лучше отдать чужому, но профи)?
  - Какая затратная часть на первом этапе для организации такой работы (имеется ввиду, что *не компьютеры* покупать, а специальные инструменты для профессиональной работы - анализаторы seo, статистики, и т.д.) - и какие это должны быть инструменты?

  1. маркетинговая составляющая команды - аналитик
  - стратегия маркетинговой раскрутки, аналитик должен предоставить бизнес план на проект с маркетинговой точки зрения.
  - уметь проанализировать сайт (определить его нишу, его ЦА и конкурентов), составить базу ключевых слов.
  - знать (хотя бы в своей основе) алгоритмы индексирования поисковиков (причем поскольку у конкретного человека заявки на "оптимизацию" в основном с буржуйских сайтов, то в большей степени интересует поведение Google, Yahoo, MSN...)
  - вести документацию по проекту, отслеживать статистику, готовить отчеты для клиентов (за время работы с вашем сайтом рейтинг вырос настолько-то, траффик - на столько-то, количество проиндексированных страниц наконец-то правильное , мы вышли на такие-то позиции по таким-то запросам, и т.д.)

  2. копирайтер (со способностями психоаналитика и пониманием SEO) - уметь писать текст для страниц с заданной плотностью ключевых слов, уметь написать пресс-релиз для рассылки на тематические ресурсы и т.д.

  3. линк-менеджер, должен "уметь" терпеливо сидеть и регестрить сайт в каталогах, обмениваться ссылками, писать в форумы и доски объявлений, сказали ему - зарегестрировать такой-то сайт в такой-то баннерной сети - пошел, зарегестрировал, отправить такие-то письма с предложением сотрудничества - пошел отправлять и т.д.

  4. верстальщик/дизайнер/программист. Очень сложная позиция, поскольку "три в одном" - таких чудес не бывает, а брать разных специалистов на одну позицию - для начинающей команды - не окупится. Однако какие могут вставать задачи перед этим специалистом:
  - править верстку страниц, модифицировать html-код, таблицу стилей, упорядочить загрузку элементов html-документа.
  - как минимум уметь дать консультации, если используемая на сайте cms генерит плохие для поисковика страницы, сессиями или кривыми урлами - в зависимости от бюджета на раскрутку - даже модифицировать движок cms
  - возможно, переделать некоторое количество элементов оформления страниц сайтов типа чтобы ускорить загрузку страниц
  - в случае необходимости - нарисовать баннеры (в сотрудничестве с аналитиком-копирайтером придумать слоган на баннер, чтобы тот был кликабельным и интересным).
  Видимо, единственное решение для начала - в штате держать такого "и швец, и жнец, и на дуде что-то может...", а в случае, если задача серьезная и бюджет позволяет - приглашать профессионального программиста (профессионального дизайнера) "со стороны", freelance- вовсе не зло, многие и разработчики, и подрядчики сотрудничают таким образом годами.

  Да, конечно, уровень работ над оптимизируемым и продвигаемым сайтом будет во многом зависеть от бюджета, который заказчик предлагает (не уровень качества, а, скорее, количество сервисов, объем работ). Многие западные (да и наши) фирмы, предоставляющие такие услуги, разделяют объем работ на "пакеты" - типа "basic" - самый дешевый, видимо, включающий косметическую работу над сайтом (типа титлы прописать) и базовую регистрацию в каталогах; дальше - "стандарт" - уже больше услуг, но и пакет - дороже, дальше - "голд", "премиум" - здесь уже и цены разумные, и степень работы над сайтом круче, дальше можно придумать совсем уже хитрый "элит", дорогой и качественный, то самое шаманство, технологию, которую клиентам и не описывают.

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

  Читать полный выпуск...»

• 09.10.05. Bыпуск #181

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

  Основные изменения в версии 3.2. коснулись модуля "HTML-анализатор", который позволяет определять вес и плотность ключевых слов, фраз и словосочетаний на HTML странице и, таким образом, с одной стороны, анализировать и оптимизировать содержание собственного Интернет-проекта, а с другой стороны, производить мониторинг сайтов конкурентов.

  В новой версии программы Semonitor улучшены настройки для работы с контентом сайта – например, введены правила анализа словоформ и групп слов, настройки путей анализа, возможность редактирования и обозначения стоп-слов. Введение этих функций принципиально важно при работе с русскоязычными сайтами. В отличие от английского языка, в котором слово обычно имеет одну словоформу, а словообразование ограничено относительно небольшим набором правил, морфология русского языка очень сложна, а потому работа с контентом требует особенно тщательного подхода. Благодаря использованию перечисленных возможностей новой версии Semonitor, пользователи смогут эффективно и удобно анализировать HTML-страницы, как на английском, так и на русском языках.
  Подробнее узнать о программе вы можете на сайте www.semonitor.ru.

  ---

  Webprojects.Ru проводит исследование рынка услуг по оптимизации сайтов и приглашает всех принять участие в данном экспертном опросе.

  Всем ответившим предоставляется скидка на оплату услуг проекта SeМастер (http://www.semaster.ru/) в размере 50% в течение сентября-ноября 2005 года.

  Исследование рынка проводится во 2-й раз. Прошлое исследование проводилось год назад, и его результаты были представлены на конференции по оптимизации сайтов в ноябре 2004 года в Москве.Ознакомиться с результатами прошлогоднего исследования можно здесь: http://www.webprojects.ru/publications/research/27/

  Цели исследования

  Исследование рынка услуг по оптимизации проводится с целью дать объективную картину его состояния на 2005 год. В рамках исследования будут изучены следующие аспекты:

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

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

  Фокус-группа

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

  Результаты исследования

  Результаты исследования в статистически обработанном виде будут опубликованы на сайте www.webprojects.ru в декабре 2005 года. Ссылки на конкретных экспертов будут указываться по их желанию. Конфиденциальность персональных данных гарантируется.

  Форма исследования

  Исследование проводится в форме анкетирования. Анкетирование проводится до 1 ноября Анкету для организаций можно заполнить он-лайн (http://www.webprojects.ru/research/r2005/anketa_org/) или скачать здесь (http://www.webprojects.ru/files/anketa_org.doc). Анкету для частных лиц можно заполнить он-лайн (http://www.webprojects.ru/research/anketa_freelancers/) или скачать здесь (http://www.webprojects.ru/files/anketa_freel.doc).
  Заполненные анкеты вы можете отправить по е-mail: ivan@webprojects.ru

  Исследование проводится в форме анкетирования. Анкетирование проводится до 1 ноября. Анкету для организаций можно заполнить он-лайн (http://www.webprojects.ru/research/r2005/anketa_org/) или скачать здесь (http://www.webprojects.ru/files/anketa_org.doc). Анкету для частных лиц можно заполнить он-лайн (http://www.webprojects.ru/research/anketa_freelancers/) или скачать здесь (http://www.webprojects.ru/files/anketa_freel.doc).
  Заполненные анкеты вы можете отправить по е-mail: ivan@webprojects.ru

  По всем вопросам просьба обращаться в оргкомитет
  Контактное лицо: Иван Севостьянов
  Телефон: 8 (095) 551-62-92
  Email: ivan@webprojects.ru

  ---

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

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

  В irc канале webmascom (интересующимся – искать на irc.ircinfo.ru) один из участников дискуссии озвучил следующую информацию: "нет большого смысла ждать от браузеров корректной реализации display: table, поскольку нет смысла в его использовании". Имелось ввиду, что для вывода табличных данных должно использовать стандартный html-тег table, и, с другой стороны, использовать для визуального дизайна, в частности, к примеру, для злополучной 3-колоночной верстки display: table – это тот же самый возврат к табличной верстке (имитации табличной верстки), т.е. - неправильно с точки зрения семантики web, типа - "назвали таблицы дивами и радуемся".

  Тогда и стал вопрос по поводу того, что же такое "семантика в web". Тем же участником дискуссии было предложено официальное такое определение: "(от греч . semantikos - обозначающий),1) значения единиц языка.2) То же, что семасиология, раздел языкознания, изучающий значение единиц языка, прежде всего слов.3) Один из основных разделов семиотики." О как! Не то, чтобы не понятно, но хотелось услышать более... близкое к css определение. Попыталась сформулировать нечто следующее (просто поток сознания):

  "Я так понимаю, что если не путаться в терминах (семасиология, семиотика) - то, к примеру, если я закрою глаза и *прослушаю* открытую страницу, озвученная информация будет достоверной. Так? Т.е. если мне браузер говорит: Таблица, а в ней - заголовок (в th) - Прайс - то дальше будут табличные данные - название, цена... Описания стилей или назначенные id/class в этом случае браузер мне надиктовывать не будет. Вот. Т.е. если он дойдет до дива, в котором назначен display:table, он прочтет только содержимое этого дива, но диктовать мне табличную структуру не будет, так? Тогда где нарушение семантики?"

  Что же касается злополучного вопроса о трехколоночном футере, стабильном и кроссбраузерном, без использования display: table; - было предложено использовать метод "отрицательных полей" (по статье на вебмасконе http://webmascon.com/topics/coding/43a.asp). Однако. Отрицательные поля - такой же обман браузера, как и в случае использования стилевых свойств типа display:table! Поэтому - выбор между двумя нарушениями логики - типа по вкусу как мне кажется.

  В рамках семантических реализаций был супер главным оператором канала озвучен вывод урока: "сегодняшний урок: не важно, что мы там напишем в CSS, главное, чтоб ul был списком" (в первоначальной реализации звучало так: "сегодняшний урок: не важно, что мы там напишем в CSS, главное, чтоб ul выглядел как список", что не соответствует тем требованиям, которые предъявляются к семантической разметке – она не должна выглядеть, она должна быть – ее можно озвучить словом, словами).

  Semantic Web - это вообще интереснейший проект, продвигаемый директором w3c.org, одним из основателей Web, и более внятно и подробно (определение, цели и задачи, плюсы и минусы) лучше прочесть на официальном портале семантической паутины на сайте консорциума или же в русскоязычной википедии. Однако великое и прекрасное будущее сети, видимо, еще достаточно далеко от нынешних разработчиков. Давайте немного поговорим об основах - стандартном html.

  По определению HTML — Hypertext Markup Language (Язык Разметки Гипертекста) - это язык, предназначенный для описания форматирования текста, задания ссылок и других элементов веб-страниц. В нём используются стан­дар­ти­зи­ро­ван­ные "тэги", такие как и , смысл и способ интерпретации которых задан универсально WWW-Консорциумом. К сожалению, современные разработчики, зачастую, не стремятся к изучению и соблюдению стандартов (не забывая при этом обижаться и злобить на разработчиков браузеров, которые так же не в полной мере те же стандарты блюдут, что, мол, "кривой браузер неверно отображает мою страницу", и старая больная тема - сделать кроссбраузерный, не разваливающийся и не расползающийся сайт). Более того, некоторые, довольно матерые интернетчики демонстративно игнорируют осовные требования к разметке страницы, намеренно рекомендуя новичкам "не возиться" с правильным, но трудно форматируемым документом, "не морочиться" с изучением документации, а сделать "как все" - поскольку главное - чтобы документ отображался в сегодняшних браузерах прилично, а начинающий дизайнер при этом - не переутомился, побыстрее сдал проект и забыл как о заказчике сайта, так и о его пользователях.

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

  Код был примерно следующим: в блоке (div с длинным и сложным описанием стиля) располагался тег параграфа P, внутри которого - картинка, т.е. примерно следующее:

  <div id="Layer8" style="xposition:absolute; left:161px; top:-410px; width:141px; height:598px; xz-index:1;">
<p align="left"><img src="images/shvarz.jpg" width="138" height="600"></p>
</div>

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

  Однако что говорит консорциум о правильном использовании тега параграфа?

  P - это строчный (inline) элемент. Элемент P представляет параграф. Он не может содержать элементы уровня блока (включая сам P). в рамках стандарта допустимо заключать картинку в тег абзаца (поскольку она не является блочным элементом, а определена как empty - т.е. пустой объект, до тех пор, пока этому объекту не заданы дополнительные атрибуты и значения), картинку вообще можно ставить куда угодно :), однако вовсе не обязательно заключать ее в тег параграфа; при этом простое решение для конкретного вопроса - убрать обрамляющий и не нужный тег параграфа и поставить перенос строки после картинки, т.е.

  ...
<img src="images/shvarz.jpg" width="138" height="600"><br>
...

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

  И вот ведь странно... я не являюсь фанатом css и блочной верстки, и настаивать на какой-то конкретной модели не буду - да верстайте как хотите, однако странно - даже если не говорить о semantic web, зачем же рекомендовать начинающему разработчику использовать лишние теги для верстки параграфы/таблицы, усугубляя изрядным стилевым описанием, когда достаточно сделать по стандарту, (как в приведенном выше примере - добавить перенос строки после иллюстрации)? Решение, которое является избыточным, не может быть правильным.

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

  Читать полный выпуск...»

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

наверх

• главная |
• сервисы |
• статьи |
• рассылка |
• портфолио |
• галерея |