Обычно, когда меня спрашивают, сколько будет стоить сайт, я ориентируюсь на месячную зарплату разработчика в районе $$ 1500—2000 ($ 1 = 30 руб.). При этом есть еще и минимальная планка где-то в $$ 1000—1200. Например, я говорю: «Сайт будет готов через пять недель, и будет стоить $ 1900». Заказчиков такой уровень детализации устраивает.

Недавно я попал в любопытную ситуацию.

Называю цену, а мне говорят: «Обоснуй». Ладно, пишу смету в таком ключе:
* установка и настройка движка — $ 250,
* рисование шаблонов — $ 300,
* верстка — $ 200,
* интеграция шаблона в CMS — $ 150
и т. д.

Меня спрашивают: «А что это за настройка движка? А что за интеграция шаблона в CMS?» Я в меру способностей объясняю, но чувствую, что выгляжу каким-то проходимцем. Но рассказать хочу не о том.

Когда я взялся за дело, в голове постоянно всплывали цифры по статьям. Ставлю движок, а сам думаю: «Так, на это у меня есть пара дней. Это делать не буду — не успею. А это буду делать в самом конце, поскольку никто всё равно не увидит и не оценит». Ну и в таком духе.

Хорошо ли сделал заказчик, разузнав так подробно, что и сколько стоит? Пошло ли это ему на пользу? Сложный вопрос.

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

Что думаете?

Ведущими PHP CMS я считаю Drupal и Joomla. У обеих сложные админки. Админки очень разные, но обе отвратительно неудобны. Почему так?

Ответ напрашивается — разработчики не ставили себе цель сделать удобные админки. То есть они позаботились о расширяемости через модули, о движке шаблонов, об автообновлении. А удобство админки почему-то не стало ключевой целью.

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

Если бы я оценивал Друпал и Джумлу по этим четырем критериями, каждая набрала бы в сумме что-то около 0,5—1 балла из 4 возможных. Получается, что о юзабилити много говорят, но в грош его не ставят.

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

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

Выборка респондентов часто нерепрезентативна. Голосующие могут быть заинтересованы в подтасовке результатов. Закрытые опросы излишне упрощают реальную картину. Авторитетные представители сообщества могут распространять свое влияние на остальных. Кто-то выбирает самый непопулярный вариант, чтобы показать свою обособленность.

Но все-таки опросы живут и здравствуют. Сейчас популярны голосования с двумя опциями для выбора: «+/-», «за/против», «ваау/феее». Это разные социальные сервисы.

Еще вариант — оценка чего-нибудь по пятибалльной шкале. В моде звездочки и Ajax.

Серьезная техническая проблема, связанная с опросами, — накрутка. Пикантность ситуации в том, что люди, занимающиеся накруткой в промышленных масштабах, обладают достаточными средствами для обмана изощренной защиты.

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

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

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

Статья о том, как устроить на сайте голосование так, чтобы

* посетители из баловства не голосовали по несколько раз,

* разработчик приложил минимум усилий.

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

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

Что важно? За одну условную сессию посетитель не должен проголосовать несколько раз.

Конечно, есть еще пожелания. Хорошо бы, человек, проголосовав на работе и придя домой, не кликнул бы еще разочек. То же относится и к счастливому обладателю модема, у которого на самом интересном месте разорвалось соединение. Два человека из-за одного компьютера в интернет-кафе не должны «склеиваться». И таких пожеланий много.

Соотношение между важным требованием и мини-пожеланиями — двадцать к одному.

Базовые решения

1. Никакой защиты можно не делать вообще. Вариант — мечта для программиста. Но доверие к результатам опроса исчезнет, если посетитель увидит, что голосовать можно сколько угодно раз. Поэтому хочется, чтобы человек кликнул и увидел, что второй раз не получится.

2. Делаем PHP-сессию и фиксируем факты голосования. В базу ничего не пишем. Что плохого? Если у администратора возникнут сомнения в достоверности результатов, расследования не получится. Да и сессия может закрыться, а посетитель вдруг вернется.

3. Есть еще подход без использования базы данных с куки. Здесь вообщее всё можно решить на клиентской стороне. Но у пользователя JavaScript и куки могут быть отключены. И расследования опять же не получится, случись что.

4. Записываем IP-адреса всех участников голосования и время. Делаем так, чтобы с одного адреса можно было голосовать раз в час. Недостатки? Никак не решается проблема с динамическими адресами. Зато нечистую игру уже можно разглядеть.

Именно так устроен модуль Drupal Voting. Для незарегистрированных посетителей других ограничений нет. Этот вариант я считаю сбалансированным — неплохой результат при небольших трудовых затратах. Дальше его можно улучшать.

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

Дополнительные меры

1. IP-адрес можно доставать не из $_SERVER['REMOTE_ADDR'], а похитрее.

2. Если работать и с IP, и с куки, ситуация с динамическими адресами немного улучшится.

3. При голосовании можно спрашивать у посетителя какой-нибудь идентификатор, например, email или OpenID. Это шанс решить проблему с несколькими компьютерами и одним пользователем. Минус — посетителю нужно заполнять дополнительное поле.

4. Голосование можно сделать на AJAX. Плюс — отсеются боты, неумеющие исполнять JavaScript. Недостаток — поддержка JavaScript у некоторых пользователей выключена. И да, есть браузеры типа Opera 7.

5. Денис Болтиков предлагает продолжать работу с IP, используя базы адресов с разбивкой по странам и городам. Можно закрыть доступ всем нерусским посетителям, и заодно большинству анонимных прокси. Еще есть mod_geo.

6. Денис также говорит, что существуют готовые недорогие базы адресов анонимных прокси. А Dead Krolik советует ничего не покупать, а завести собственный черный список.

Я бы начинал с варианта «IP + задержка по времени + AJAX» и по мере необходимости добавлял бы разные защитки.

Кстати, любые дополнения и замечания очень приветствуются.

На многих сайтах существует проблема, связанная с размещением широких рисунков и таблиц. Эти условно большие объекты попросту ломают шаблон: либо колонка с основным текстом неприятно растягивается, либо блоки расползаются.

Простое решение — выносить неформатные элементы на отдельные страницы. Так, например, поступают игровые сайты со скриншотами. Однако, в тех случаях, когда в основном тексте даются комментарии к картинке или таблице, лучше бы держать всё на одной странице.

Какую ширину может себе позволить сайт с точки зрения пользовательских ограничений? Что-то около 700 пикселей. А скоро, пожалуй, и все 900.

Что в действительности? Шаблон в три колонки обычно позволяет разместить картинку шириной в 400—450 пикселей. Та же история с блогами на WordPress/Kubrick.

Вывод: страницы с объемными статьями, проиллюстрированные рисунками и таблицами, должны верстаться в одну колонку. Причем ширина больших объектов не должна влиять на длину строк — текст не должен растягиваться на весь экран.

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

Кстати, я на днях защитил диплом.

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

Леха Скрипник подсказал одну идею: нужно читателей научить пользоваться RSS. Но дело в том, что тот, кто не знает об RSS, не хочет и узнавать. То есть статью «Что такое RSS» многие просто проигнорируют.

Решение: нужно сначала рассказать посетителю что-то ценное, а потом предложить подписаться на обновления блога по RSS с кратким объяснением технологии.

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

Залог успеха я вижу в размещении «рекламы» RSS только после очень удачных материалов. Попробую — расскажу.

Почему никто не любит заполнять длинные формы в интернете? Помимо очевидных особенностей, присущих всем длинным формам, можно выделить web-specific явление: в процессе ввода нельзя сохраняться. Чем больше в форме полей — тем больше шансов данные потерять и вводить всё еще раз.

Когда я заполняю длинную форму, есть какое-то ощущение нестабильности. Поэтому нередко весь текст пишу в ворде, а потом растаскиваю его по полям. Как сделать процесс надежнее?

1. На одной странице не должно быть много полей. Скажем, если это input type=text, то штук 5—6 максимум. Если это textarea, то вообще 1—2.

2. Если форма на самом деле длинная, то ее заполнение нужно разделить на шаги. Получается мастер. У разработчика есть возможность сделать промежуточное сохранение. Практика достаточно распространена, например, так делают Яндекс и headhunter.ru.

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

3. В ЖЖ есть автосохранение, которое меня как-то раз спасло. Но с тех пор доверия к этой штуке не прибавилось, и всё равно полагаюсь только на себя.

Когда человек заполняет форму и нажимает на кнопку «Отправить», может случиться всякое. Например, серверная часть может нормально отработать, а ответ клиенту не дойдет. Что мы (пользователи) тогда делаем? Ясное дело, нажимаем F5. Запрос отправляется еще разок с теми же данными. Серверная часть снова отрабатывает и на это раз возвращает ответ — страницу с продублированным комментарием (новостью, товаром, постом на форуме). Сталкивались с этим явлением?

Как же распространенную проблему решить? У меня четыре варианта.

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

2. Можно установить для пользователя ограничение по времени, скажем, одна запись в базу в течение 30 секунд. Всё равно нужно писать код.

3. Есть вариант с редиректом: сервер возвращает легкую страничку, с которой пользователь мгновенно куда-нибудь перенаправляется. Недостаток — если легкая страничка не дойдет, то дублирования не избежать.

4. Делаем UNIQUE-индекс в таблице. Можно по нескольким полям. Смотрим, если MySQL возвращает код ошибки 1062, значит, данные уже записались. На данный момент это мой выбор. Я правда не уверен, что использую этот тип индекса по назначению, но каких-то недостатков не замечал.

Кстати, по неизвестным причинам большинство популярных CMS не решают проблему повторной записи данных. WordPress получает плюсик.

Утреннее дополнение

Вариант с UNIQUE, как оказалось, отягощается парой недостатков.

Когда на сайте нужно выложить документ Word, передо мной встает дилемма:
* заархивировать файл и поставить ссылку на архив,
* оставить файл в формате DOC и поставить на него ссылку,
* преобразовать документ в HTML и сделать его полноценной частью сайта.

И что же я выбираю?

Мне очень нравится ZIP, и я бы даже не думал об остальных вариантах, если бы не нюанс. Архивы не индексируются поисковиками. То есть сайт теряет посетителей.

Чем характерен вариант с выкладыванием DOC и RTF? Документы индексируются, но посетитель получает к ним доступ, полностью минуя сайт. Это, например, может приводить к потере клиентов. Вот человек ищет информацию по ремонту компьютера, находит какой-нибудь бюллетень на сайте сервиса, видит, что самому ему не справиться, и идет опять искать. Не факт, что он опять попадет на сайт того же сервисного центра после повторного общения с поисковиком.

Перевод документа в HTML и размещение его на сайте в обрамлении шапки, меню, колонки с новостями и подвала выглядит лучшим решением. Но и здесь есть проблемы. Документ может содержать очень сложное форматирование не под силу среднему конвертеру. Или в нем может быть 100 страниц.

Описанная ситуация с выбором формата распространяется и на большие картинки, и на XLS-прайсы, и на презентации. Главная проблема — сайт недополучает посетителей только из-за выбора формата. И чем дальше формат от веба, тем больше.

Что в итоге?

1. Максимум документов нужно переводить в HTML и размещать на сайте как обычную страницу.

2. Файлы умеренного размера индексируемых форматов (DOC, RTF, PDF, XLS, PPT) не нужно архивировать. В этих документах нужно на видном месте писать адрес сайта и ставить на него ссылки.

3. Все названия файлов должны содержать адрес сайта. Что-то вроде dserg.com-mincing-machine-price-list.xls.

4. На картинках нужно в уголке писать адрес сайта.

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

Сладким речам менеджеров веб-студий о том, что новые клиенты хлынут, часто не верят. Не зная, как измерить прибыль от сайта, люди боятся переплатить. «Потратим немного денег, если ничего не получится — забудем». Классический подход.

Что делать разработчикам для повышения доверия к себе?

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

Как компания может узнать, что клиент пришел с сайта? Есть два пути: либо спрашивать, как он узнал об организации, либо сделать так, чтобы cам рассказывал.

Штук десять практических способов будут завтра.

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

Активными методами назовем разные опросы покупателей, в рамках которых выясняется, откуда они узнали о магазине. Подход затратный, но результаты могут быть интереснее.

Методы без особых хлопот

1. Выложить на сайте купон на скидку, который нужно распечатать и принести в магазин.

2. Написать на сайте, что, придя в магазин и сказав при покупке фразу «я узнал о вас из интернета», клиент получает скидку. Так когда-то было в Роллер-клубе. Впрочем, способ с распечатыванием купона лучше защищает от мошенничества

3. Сделать на сайте форму для ввода личных данных и генерацию из них договора. Если клиент пришел в офис с готовым для подписи документом — скорее всего повозился с сайтом. Так сделано в Ru-center. Кстати, ленивым придется заплатить несколько рублей за оформление бумажки.

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

5. Указать на сайте специальный телефон, которого больше нигде не будет. Кто позвонил — тот с сайта. Некоторые клиенты предпочитают письма, другие — формы заказов, третьи — просто телефонные переговоры. Из всего можно делать выводы об эффективности сайта.

6. Консультировать клиентов на форуме и там же назначать время сделок. Покупатель придет в магазин, и вы наверняка узнаете, что он с сайта.

Суетные методы

1. Научить продавцов спрашивать у клиентов, откуда они узнали о магазине. Персонал при таком подходе нужно дополнительно стимулировать.

2. Пойти в магазин и несколько часов поопрашивать покупателей.

Важно результаты исследования хранить аккуратно. Идеально было бы создать базу клиентов. Если человек говорит, что узнал о магазине от друга, то хорошо бы проверить друга — не пришел ли он с сайта. Механизмы могут усложняться, главное — не переборщить и не заиграться.

Оценка эффективности сайта заинтересует предпринимателей, потому как виден результат, причем в числах. Разработчик постарается не обманывать, а заказчик будет достойно платить.

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

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

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

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

Оптимизаторы могут аргументированно спорить, но, думаю, мысли правильные.

Мартин Фоулер называет два подхода разработчиков к оценке успешности проектов.

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

Подход выглядит здравым. Действительно, почему разработчика должно беспокоить что-то кроме исполнения собственных обязательств перед заказчиком?

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

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

Посмотрим на примеры, в которых веб-дизайнерской студии заказывается сайт.

1. Называется цена в $ 3000 и срок в месяц. Цель разработчиков — успеть вовремя и сделать приличный сайт. Цель заказчика — получить новых клиентов из интернета. Прогнозировать результат сложно, но вряд ли он будет блестящим.

2. Разработчиков просят сделать сайт, который привлечет новых клиентов. Называется минимальная цена в $ 3000. В случае увеличения продаж обещается еще $ 2000. У разработчиков и заказчика одна цель — сделать эффективный сайт. Результат должен быть лучше, чем в первом примере.

Понятно, что материальное стимулирование во главу угла можно не ставить. Суть в том, что разработчикам должны предлагаться адекватные метрики успешности проекта.

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

Скажем, такой вопрос: «Как будет выглядеть карта сайта этого блога?» Я вижу минимум пару решений: абстрактное и детальное. На абстрактной карте можно ограничится типами страниц. Детальное же решение подразумевает изображение реальных экземпляров страниц.

Похоже, что карта сайта почти всегда достаточно абстрактна. Либо мы оперируем классами объектов, либо — охватываем не все страницы.

Еще вопросы: «В какой степени карта сайта должна отражать реальные ссылочные связи? Мы рисуем только структуру или более сложные отношения между материалами?»

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

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

Я собираюсь выбрать для себя нотацию, а начну со страницы в iawiki про sitemap. Ссылок оттуда хватит на полжизни. Как только мое представление о правильных картах станет лучше, расскажу.

В прошлый раз я пытался разобраться с картами сайтов. Речь шла не об xml sitemap для поисковиков и не об оглавлениях сайтов для посетителей. Под картами сайтов подразумевались рисунки с подписанными квадратиками (страницами) и соединяющими их линиями (ссылочными связями).

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

Подсказка: по большинству квадратиков и кружочков на схемах по двум только что упомянутым ссылкам можно кликать.

Кстати, с точки зрения пользователя такое решение бесполезно.

Четких ответов на основные вопросы найти так и не удалось. Зато я заметил схожие мысли у других разработчиков: сложно сказать, что делать с большими сайтами, какие связи не рисовать.

Вывод из этой истории?

При проектировании не нужно сильно рассчитывать на карту сайта. На начальном этапе она помогает описать будущую систему, но долго поддерживать ее в актуальном виде смысла нет.

Как и что рисовать? Делайте, как подсказывает сердце

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

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

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

Во-вторых, ЖЖ отлично приспособлен под ведение дискуссий. В чем это заключается?

Древовидные комментарии и возможность сворачивать ветки — раз.

Извещения по email — два. Письма содержат не ссылки на новые комментарии, а сам текст комментариев. ЖЖ извещает только о том, что имеет к человеку какое-то отношение.

Нацеленные извещения сложно реализовать без древовидных комментариев.

Теперь посмотрим на разное ПО для дискуссий.

Форумы. Древовидные комментарии — относительная редкость. Существующие реализации неудобны. Лучшее из извещений по email — ответы в теме. Текст ответов почти никогда не присылается. Часто извещение высылается только одно, и пока не сходишь по ссылке, больше ничего не приходит. Общая идея: пользователь постоянно должен быть на форуме и откручивать баннерные показы.

Блоговые движки. Древовидные комментарии тоже не слишком популярны. Извещения по email — относительная редкость. Там, где они есть, присылаются все комментарии к заметке. Общая идея: блог — место для общения автора с читателями, автор — пишет заметки, читатели — комментируют, общения не нужно.

Я ищу идеал, который умеет поддерживать дискуссии на том же уровне, что и движок ЖЖ. Хорошо бы еще и предоставлять всю эту функциональность анонимным пользователям. Знаете что-нибудь такое?

В разное время пробовались WordPress, Drupal, Textpattern, b2evolution, Serendipity, Nucleus CMS, Typo3, PHPBB, Vanilla, vBulletin. Делать, как ЖЖ, никто из них не умеет.

На днях я попросил трех человек протестировать «почти готовый» сайт. Они наговорили много всего.

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

Больше других, мне запомнился такой комментарий: «Кажется, сайт понятен только тем людям, которым он принадлежит». Эта фраза, помимо досады, породила несколько мыслей.

1. Сайт кажется чуждым и даже враждебным из-за своей сложности. Слишком много информации на страницах, много ссылок, невозможность оценить масштабы сайта — в моем случае всё это отталкивает посетителей. У imdb вроде не так.

2. Сайт не приспособлен под первое впечатление. Он достаточно функционален, но чтобы почувствовать мощь, нужно учиться его использовать. Единицы новых посетителей согласятся потратить полчаса на исследование сайта. Похожие трудности есть у «Хабры» и «Моего круга».

3. Для решения вышеописанных проблем придется пожертвовать частью кода. Хоть и жалко, но в умеренных дозах полезно: быстро осознаешь важность проектирования. Когда выбрасываешь свой код, потом взвешиваешь всё как-то тщательнее.

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

Ну кто же не видел списков, элементы которых заканчиваются числами в скобочках. Посмотрите хотя бы на правую колонку — там, под заголовком «Основные темы», обосновался один из рода.

Иногда использование чисел оправдано. Например, изучая каталог товаров на сайте, человек вряд ли серьезно отнесется к категориям со скромным ассортиментом.

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

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

Первоначальный вариант такой:
Киров (17)
Кировск (16)
Воркута (5)
Челябинск (5)
Ижевск (3)

Числовые значения подходят для сортировки, но смысла особого не несут. Как можно список улучшить?

Можно числа убрать, а пару самых значимых пунктов выделить жирным:
Киров
Кировск
Воркута
Челябинск
Ижевск

Простое решение. Плюсом является расстановка акцентов на странице. Жирный шрифт привлекает внимание не к блоку, а к конкретным значениям.

Решение посложнее — сделать цветовую шкалу:
Киров
Кировск
Воркута
Челябинск
Ижевск

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

Если шагнуть еще дальше и поиграться с размерами шрифтов, получим облако тегов в виде списка.

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

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

Студии веб-дизайна любят рассказывать о том, что каждый сайт они разрабатывают с учетом индивидуальности заказчика. Слышали про ортопедические стельки?

Толковать «заточенность» сайта под конкретного заказчика можно очень по-разному. Кто-то в этом случае говорит о дизайне страниц, кто-то подразумевает способность сайта решать определенные задачи. Всё это в общем верно, а я выскажусь в другом ключе.

Итак, сайт должен отвечать возможностям владельца.

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

Пусть для ввода новости нужно будет заполнить только одно поле textarea. Дата может ставиться сама. Заголовки — удел журналистов. Ключевые слова и meta description пусть делаются как-нибудь автоматически.

Пусть по продукции из каталога хранятся два поля: наименование и характеристики в вольной форме. А картинка — опционально.

Не придумывайте таких экзотических форм материалов, как статьи или скажем отчеты о выставках. В пару к новостям не нужны никакие объявления.

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

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

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

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

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

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

1. Создание базового набора качественных текстов

Десяток статей для корпоративного сайта всё равно придется написать. Лучше этим заняться на этапе разработки. Можно даже нанять копирайтера. Важно показать, что сайт — не свалка ворованных материалов.

2. Сведение к минимуму написания собственных материалов

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

3. Сбор материалов для «обвеса» из внешних источников

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

4. Нацеленность на пользовательский контент

Пусть посетители пишут отзывы, комментируют тексты, задают вопросы о продукции. Соответственно, сайт должен быть гибким в плане приема всевозможных материалов от пользователей.

5. Мощная защита от спама

Модерировать сайт времени нет, значит, либо сайт будет завален мусором, либо потеряет часть качественного пользовательского содержимого. Для текущей задачи я бы пошел на маленькое преступление и сделал бы защиту пожестче. Из двух зол…

Советы достаточно очевидны, вся сложность заключается в том, чтобы своевременно распознать «ленивый» сайт и правильно расставить приоритеты при разработке.

Трудно сказать, что сложнее — разработать новый сайт или провести редизайн старого. При создании первой версии больше неопределенности и меньше ограничений. При редизайне нужно учитывать предыдущий опыт. И еще важно не впасть в одну из крайностей.

О первой я уже упоминал: достаточно часто старые версии отбрасываются без какого-либо анализа эффективности.

С другой крайностью недавно столкнулся впервые. Я слишком щепетильно отнесся к ранним наработкам и постарался перенести все материалы старого сайта на новый. Новости трехлетней давности и флейм на форуме — всё захотел сохранить.

Мотивы были простые: сайт уже при запуске будет неплохо наполнен, а лишние страницы — это дополнительные заходы с поисковиков.

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

Мораль: при редизайне сайта не становитесь рабом содержимого старой версии. Миграция — это хорошо, но этот процесс должен быть достаточно интеллектуальным.

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

Сейчас моё мнение изменилось: если заказчик не хочет нанимать копирайтера и не может подготовить материалы самостоятельно, разработчики должны предоставить первичный набор текстов.

Говорить вещи вроде «сайт наш — текст ваш» нехорошо. Нужно показать положительный пример, предоставить эталонные образцы и объяснить будущему владельцу ключевые принципы веб-писательства.

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

Я думаю, решение проблемы в частом прототипировании. Создавая готовую версию, волей-неволей приходится думать о разных мелочах. А ведь это и есть проектирование в деталях. Кстати, одним из ключевых принципов методологии RAD как раз является итерационное изготовление прототипов.

Бумажные прототипы хороши. Не нужно ни специальных инструментов, ни особых навыков. Рисуются они мгновенно. Их можно тестировать. На alistapart.com недавно была вдохновенная статья (англ.).

При необходимости с бумаги сайт можно перенести в Visio. Помогут штучки от Гаррета (Garrett Dimon).

Статичная версия сайта. Несмотря на то, что идея не так уж оригинальна, всерьез я задумался о статичных HTML-прототипах только после дискуссии на xpoint.ru.

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

Ну и, наконец, прототипы на движке. Здесь всё понятно. Это промежуточные версии сайта с ограниченной функциональностью.

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

К сожалению схемы разработки сайтов в реальной жизни редко похожи на идеальные. Иногда приходится первым делом рисовать главную страницу сайта, чтобы показать, на что ты способен. Даже если времени очень мало, не набрасывайтесь сразу на «Фотошоп». Сначала разработайте тему.

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

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

Для блоков подберите «рыбу» пореалистичнее. Порисуйте макет на бумаге. Если возникают трудности, воспользуйтесь какой-нибудь программой вроде «Визио».

А теперь тот момент, ради которого я затеял весь сегодняшний пост.

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

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

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

Будьте реалистичны даже в ваших «шаблонах за полдня». Не тратьте время на блок с новыми сообщениями на форуме, если форума на сайте не будет. Иначе полученный макет придется сильно перерабатывать. Вы уберете половину теоретически красивых блоков, и всё развалится.

P. S. — Я тут играюсь с оформлением блога. Что думаете? Не слишком ли нынешний вариант скучный?

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

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

Попробую, на основе вышеизложенных фактов, соорудить пользовательский сценарий.

Итак, грамотный директор говорит своему помощнику: «Давай-ка сайт делать. Для начала напиши техническое задание».

Парень включает Google и спрашивает: «Как писать техническое задание?» О чудо, одна из первых ссылок в выдаче — моя! Парень заходит на этот сайт, читает, что я написал на тему ТЗ и уходит по ссылкам на ГОСТы, примеры и большие статьи.

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

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

Например, на особенных страницах где-нибудь на видном месте можно написать: «Вам поручили сделать сайт? Никогда раньше этим не занимались? Возможно, пригодятся статьи о том, как правильно расставить приоритеты и на что обратить внимание».

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

Вуаля. Теперь мне нужно лишь подумать над реализацией фичи.

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

В комментариях уже не раз упоминалась книга Луиса Розенфельда и Питера Морвиля «Информационная архитектура в Интернете». Хороша она тем, что каждая глава вызывает желание испробовать описанные методы на практике.

Особенно понравилась одна идея для редизайна сайта: после сооружения первого прототипа предлагается провести его сравнительное тестирование со старой версией.

В чем соль?

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

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

Так вот авторы в главе о бенчмаркинге предлагают отличный способ вовлечения старого сайта в новый процесс.

Предположим, у вас есть старый сайт, который пока еще висит в интернете. А новый существует только в виде ранних прототипов. Вы берете потенциального пользователя и ставите перед ним конкретную задачу. Скажем, если сайт — это магазин фототехники, пусть выберет себе камеру в пределах $ 1200.

Задание может быть связано и с управлением содержимым сайта.

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

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

Если вы играли в Counter Strike с ботами (PODBot), то наверняка обращали внимание на происходящее в чате. Это меня занимает до сих пор.

Что интересного? Боты вполне осмысленно разговаривают в рамках словаря фраз. Часто реплики зависят от контекста. Например, если кто-то стреляет особенно удачливо, его называют читером.

В диалогах периодически проскакивают имена участников, название карты и разные другие признаки, характерные именно для текущей игры. Это добавляет жизненности. В репликах могут использоваться, например, такие значения:
# %f = Name of Player with the most frags
# %m = Mapname
# %v = Last Victim of this Bot

Движок, отвечающий за чат, помимо случайных фраз выдает реплики, привязанные к событиям. Выглядит это так:
[KILLED]
Sorry, %v. You got in my way.
I had to do it, %v. You understand.
I’ve always been better, %v. Always.
Sorry %v, my Headshot Script is better than yours.
[BOMBPLANT]
Jeeesuzzz Christ, not again!
Say, is it the red or the blue wire ?

Помимо этого, реплики выстраиваются в цепочки на основе употребленных ключевых слов:
@KEY «CAMPER», «CAMPING»
I really hate those campers!
Camping sucks!
Don’t you camp

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

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

Комбинируя два этих аспекта, получаем четыре возможных сочетания. Интернет-проектов, в которых всё более или менее хорошо, мало. Сайтов на устаревших движках с хорошей командой тоже совсем немного. Прослойка ресурсов, с технической точки зрения имеющих всё, что нужно для успеха, несколько больше. Остальное — серая безликая масса.

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

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

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

Итак, вы получили заказ, обсудив за час будущий сайт. Сразу же спросите, кто им будет заниматься после сдачи. Постарайтесь познакомиться с этим человеком. Попробуйте пробудить в нем искорку любопытства. А может, запланируйте для него небольшую премию. Расспросите его подробнее, ведь у руководства времени нет.

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

Но дело в том, что шансы получить что-то приемлемое с первого раза невелики. Именно поэтому с будущим редактором вы познакомились так рано. Уделите ему немного времени, расскажите об основных недостатках работы, дайте ссылки на статьи о том, как писать в интернете. Пусть человек подумает о ключевых словах, привлекательных заголовках, текстах без «воды». Время-то есть. Возможно, всё это будет больше похоже на игру, но проект запустится более плавно.

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

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

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

Нашлось два распространенных варианта:
* закрыть доступ к папке с администраторскими скриптами средствами Apache с помощью .htaccess и .htpasswd,
* воспользоваться PHP-сессиями и хранением пароля в базе данных.

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

Плюс варианта с базовыми средствами Apache? Приемлемый уровень надежности с минимальными временными затратами.

Потом я постепенно стал знакомиться с разным web based ПО, и первое время с удивлением отмечал, что множество разработчиков пользуется сложными схемами с PHP-сессиями. Понемногу я стал понимать, в чем дело.

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

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

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

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

При использовании .htaccess процесс будет выглядеть по-другому: администратор увидел опечатку, создал в браузере новую вкладку, там загрузил администраторскую панель, нашел там товар, отредактировал, вернулся на первую вкладку и посмотрел, всё ли теперь в порядке.

С точки зрения безопасности оба варианта вполне приемлемы.

Резюме

Если структура сайта простая, администраторов мало — меньше проблем доставит вариант с .htaccess.

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

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

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

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

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

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

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

В следующем посте пофантазируем о том, что же нашей целевой аудитории нужно.

Дополнение от 08.03.2007

В книге Прайсов про веб-писательство аудиторию сайтов делят по целям на пять групп. Цели такие:
* развлекаться,
* познавать,
* учиться,
* действовать,
* общаться.

Зачем на сайт компании, занимающейся проведением праздников, заходят потенциальные клиенты? Чтобы определиться, подходит ли она им.

Критерии могут быть разными. Кому-то нужна вечеринка с «играми для пьяной компании», а кому-то — изящная свадьба. Очевидно, всем не угодишь. Поэтому клиентов нужно сегментировать. Чем глубже вы копнете, тем яснее будет картина. Не бойтесь глубины и остерегайтесь формулировок, вроде «задача сайта — информирование потенциальных клиентов о деятельности компании». Для каждого самого маленького кусочка сайта найдите целевую группу. Если ничего не выходит, возможно от реализации «кусочка» стоит отказаться.

Я же не буду выписывать портреты посетителей. В общем случае заказчикам интересен опыт команды и портфолио. Услуги лучше подавать именно в этом контексте.

Что входит в «опыт»? Образование (диплом об окончании циркового училища), стаж (работа ведущим игр региональной лиги КВН на протяжении пяти лет), участие в каких-то мероприятиях, занимаемые должности, хобби.

Если в «каких-то мероприятиях» человек участвовал в качестве организатора, это уже можно отнести к портфолио. Что там? Громкие имена довольных клиентов, их отзывы, количество заказов, качество исполнения работы, интересные детали.

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

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

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

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

Рассказы о том, что никто не знает, как правильно писать техническое задание на разработку сайта, немного преувеличены. Есть ГОСТы, есть профессиональные технические писатели, есть требования, которые вполне можно выразить в письменном виде. Обычно нет времени и желания писать нудную бумажку.

Я могу себе представить три подхода к написанию технического задания.

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

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

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

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

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

Этот вариант плох тем, что разработчики обманывают сами себя, растрачивая время на бессмысленную писанину. Заказчикам тоже плохо — за составление технического задания они платят отдельно.

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

3. Заказчик и исполнитель пишут техническое задание вместе, незаметно проектируя будущий сайт. Люди учатся. Они читают ГОСТы, форумы, примеры реальных технических заданий на похожее ПО. На написание документа отводится хотя бы две-три недели. Работа нормально оплачивается.

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

Такой подход на практике я видел раза три. Остальное — за вторым вариантом.

Основой технического задания (далее по тексту — ТЗ) на разработку сайта могут стать ГОСТы, кто бы что ни говорил. Спешу развеять главный миф: ГОСТы — это вовсе не длиннющие пыльные манускрипты, которые невозможно читать из-за устаревшего формального языка. Их сочиняли разумные люди. Что важно — они избегали «воды».

Структуру и содержание ТЗ на сайт можно почерпнуть из двух ГОСТов:
* для информационной системы с богатой функциональностью подойдет ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» (15 страниц),
* для «обычных» сайтов без ярко выраженной автоматизации каких-то процессов есть ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» (3 страницы).

Замечу, что пятнадцатистраничный стандарт интереснее. Я им периодически пользуюсь и вполне доволен.

ГОСТы по сути являются костяком ТЗ. В них описаны основные разделы и подразделы ТЗ и даны небольшие комментарии по их наполнению.

Главная проблема ГОСТов, по-моему, в том, что из-за попытки охватить всё ПО в целом, в них не отражена специфика разработки сайтов. Это потому что в те времена, когда стандарты составлялись, и сайтов-то, наверное, не было.

Еще раз повторюсь: шаблон из ГОСТов получается очень даже хороший. Структура документа продумана и поддается расширению.

Как-то раз мне на глаза попалась статья «Как писать техническое задание?!». Она больше ориентирована на технических писателей, составляющих серьезные документы с тонким подтекстом, да и не про сайты, но любому, кто пишет ТЗ, почитать полезно.

В комментариях ко вчерашнему посту про подходы к написанию ТЗ ARKAN щедро поделился ссылкой на коллекцию ТЗ на разработку сайтов. Я просмотрел несколько штук — они далеки от совершенства.

Но если держать под рукой оба ГОСТа, прочитать вышеуказанную статью и изучить несколько примеров, у вас вполне может получиться дельное ТЗ.

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

Прокрутка

Прокрутка — это плохо. Наверняка каждый сталкивался со страницами, которые приходится прокручивать «туда-сюда» несколько раз для того, чтобы составить мнение о предмете или выполнить действие.

Посмотрели в одном месте. Запомнили или записали на листочек. Прокрутили страницу. Что-то сопоставили. Вернулись назад. Уточнили. И так далее. Проблема в отсутствии целостной картины.

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

Скрытые области

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

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

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

SelectBox или просто Select

Так уж вышло, что выпадающие списки Select органично сочетают в себе оба описанных выше недостатка. Во-первых, не видно, что внутри. Во-вторых, чтобы выбрать нужную позицию, нередко приходится список прокручивать. Говорят даже, что Select — самый неэффективный GUI control.

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

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

Главная проблема выпадающих списков Select

Не раз видел выпадающие списки колоссальной длины. Посмотрите хотя бы на PHPMyAdmin с прописанными внешними ключами.

Главной проблемой выпадающих списков я считаю сложность работы с длинными списками. Например, в 200 позиций. Конечно, для таких случаев сделан поиск по первой букве. Но вот поиск уже по двум буквам в Internet Explorer 6 не работает. Приходится искать элемент по первому символу, а потом прокручивать с помощью стрелок, поскольку полоса прокрутки дает слишком неточные результаты.

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

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

Вот так выглядят списки, формирующиеся стихийно и без правил:
«Кочубей»
ЗАО «Карат»
Калининградские авиалинии
карбонат-д
ОАО «Карборунд»
фонд «КРУЧИНА»

1. Названия элементов списка должны быть приведены к единому стилю. Нужно сделать так, чтобы по первому слову можно было идентифицировать элемент.

2. При сортировке в алфавитном порядке названия всех элементов списка должны начинаться либо только с прописных, либо только со строчных букв.

3. Первый символ должен быть значащим. Это не должны быть кавычки.

4. Малозначащие слова можно отбросить.

Список из «улучшенных» значений:
Калининградские авиалинии
Карат
Карбонат-Д
Карборунд
Кочубей
Кручина

Стало лучше, но если в списке 200 позиций, и названия всех начинаются на букву «к», выбирать всё равно неудобно.

Длинный список можно превратить в несколько коротких

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

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

Множество клиентов можно разбить на группы по количеству заказов, давности последнего обращения, направлениям деятельности компании.

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

Когда элементы списка уложены в какую-то структуру, выбор значения можно организовать с помощью каскада выпадающих списков Select или самодельных разворачивающихся списков с флажками, используя AJAX.

Список групп значений
Зоопарки
Питомники (Клик! Подгружаются элементы второго уровня)
Заповедники
Зверофермы

Список конечных значений
Зоопарки
Питомники
[ ] Моржовники
[ ] Мышатники
[ ] Тигрятники
Заповедники
Зверофермы

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

Список значений с синонимами-дубликатами
Зоопарки
Питомники
[ ] Моржовники
[ ] Мышатники
[ ] Тигрятники
Заповедники
Зверофермы
Коровьи фермы
Фермы с дикими животными (Ссылка на группу «Питомники»)

Варианты с укладкой значений списка в структуру подходят для поиска заранее неизвестных значений.

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

Иногда имеет смысл комбинирование поиска по подстроке и «жесткую» реализацию структуры. Опытным пользователям предлагается поиск, возможно с ограничением области, неопытным — хождение по категориям. Вопрос в том, какие средства целесообразно вложить в разработку механизма.

Резюме

1. Выпадающие списки Select плохо подходят для работы с большими множествами. Плюсами являются компактность и возможность поиска значения по первым буквам.

2. Определив взаимоотношения между элементами списка, можно сделать поиск значений по структуре. Проблемы выпадающих списков стоят не так остро, минус — сложность качественной реализации.

3. Можно развивать динамическое формирование списка по наличию подстроки в названиях элементов. Минус — не все пользователи смогут пользоваться таким механизмом.

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

Неинтересная работа утомляет. Создание сайта, длящееся месяцами, превращается в рутину. Эффективность труда разработчиков значительно снижается. Поэтому сайт должен делаться быстро.

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

Главная проблема продолжительных проектов — усталость разработчиков. Другая причина избегать длительных сроков — возможность значительных изменений требований к системе «в процессе».

Rapid application development (RAD) — методология разработки программного обеспечения с высокой частотой цикличности, подразумевающая обильное создание прототипов и применение CASE-средств. При этом функциональность приносится в ущерб времени разработки, необходимости постоянно выпускать работающие версии.

При интенсивной разработке повышаются требования к планированию. Особенно важной задачей становится расстановка приоритетов. Умение отделить ключевую функциональность от забавных фич — ключ к успеху RAD.

В английской Википедии можно узнать о RAD побольше.

Мои знания о RAD, к сожалению, не слишком глубоки, поэтому в ближайшее время собираюсь почитать книгу «Rapid Application Development» Джеймса Мартина (James Martin).

Автоматическое формирование облака тегов на основе частоты употребления слов в текстах на сайте — идея, которая лежит на поверхности. Сложности в реализации: «шум», создаваемый незначащими словами вроде союзов и предлогов, и осмысленное объединение разных словоформ. Впрочем, при относительно небольшом объеме текста проблему можно решить, внося коррективы вручную.

Чираг Мехта (Chirag Mehta), судя по зоне «ag» из Антигуа и Барбуда, написал такой скрипт для английского языка. Традиционно, чем чаще используется слово, тем крупнее оно выводится. Необычно добавление в облако параметра «свежесть» тега. Слова, популярные в последнее время, выводятся ярким цветом, тусклым — слова, употреблявшиеся давно.

Алгоритмы вычисления «свежести» тега можно посмотреть в коде. Интересна сама идея добавления второго смыслового измерения в облако. Так «восходящая звезда» (средний шрифт, яркий цвет) будет выглядеть заметнее «древнего мастодонта» (огромный шрифт, тусклый цвет). Думаю, этому эффекту можно найти применение.

Но и это не всё. Чираг сгенерировал облака для каждого месяца, начиная с ноября 2001 года. Он приделал к конструкции слайдер (ползунок) на JavaScript, и теперь можно смотреть, как изменялось употребление слов в динамике.

Что рассказывать, смотрите и сами всё поймете.

В этом блоге я совсем недавно упомянул о RAD. При поверхностном взгляде на эту методологию можно упустить ключевую деталь. Без нее окажется, что почти все сайты создаются по RAD.

— Как расшифровывается «RAD»?
— Rapid application development.
— Быстрая разработка приложений?
— Да.
— Сайт за два месяца — это ведь быстро?
— Достаточно быстро.
— Так значит все, кто делает сайт быстрее двух месяцев — RAD-разработчики. При этом большинство из них об этом даже не догадывается. Можно подсказать им использование звучной аббревиатуры в маркетинговых целях. Ха-ха!

Так где же зерно?

Идею с итерационным изготовлением прототипов легко вписать в любой проект: всё равно заказчику показывается несколько версий сайта. «Квалифицированная команда» и «толковый менеджмент» — также расплывчатые составляющие RAD.

Ключевой вопрос: «Почему сайт разрабатывается так быстро?»

Программисты быстро печатают? Работают по четырнадцать часов в сутки? А может, время экономится на стадии проектирования за счет ее исключения из процесса? Это всё не RAD.

По-моему самым ощутимым элементом RAD является активное использование специализированных инструментов. Понятие «RAD tools» тесно связано с «CASE tools», но не уверен, что это одно и то же.

Идеальная сторона методологии предполагает рисование диаграмм и разработку правил, из которых генерируются прототипы ПО. А потом полученный код лишь тонко настраивается. То есть всё проектируется настолько детально, что даже программа способна сгенерировать приложение по составленному описанию.

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

В скором времени планирую рассказать о некоторых инструментах. В результате попробую собрать комплекс RAD tools для разработки сайтов.

А пока советую почитать статью «Rapid Application Development» на blueink.biz. Из нее можно, например, узнать о том, что такое «time boxing».

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

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

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

Как вариант — превращение главной страницы в витрину с новыми материалами сайта. Этот подход учитывает интересы постоянных пользователей.

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

В результате, по-моему, приходится делать болезненный выбор: с одной стороны — ручеек новых посетителей, с другой — их же удобство.

Может всё не так уж плохо, и существует компромисс? Например, даст ли эффект заключение всех динамических блоков в тег noindex?

Вопросы не праздные, ведь в некоторых случаях обращения к главной странице могут составить 30—40 % общего поискового трафика сайта.

У проектировщика есть преимущество перед другими разработчиками: он знает, как устроен сайт «на глубине». Работая с моделями данных, он замечает такие особенности будущей системы, которые могут не разглядеть даже программисты при написании кода. Это качество позволяет подбирать платформу и компоненты веб-приложения на ранних этапах разработки.

Я говорю о вполне конкретных вещах: если проектировщик знает возможности современных систем управления контентом (CMS), форумов (BBS), блоговых движков, фреймворков, библиотек, шаблонов, даже языков программирования и систем управления базами данных (СУБД), он нередко поможет команде сэкономить месяцы(!).

Когда я был начинающим PHP-программистом, мне казалось, мир у моих ног, и за год—два я напишу «с нуля» собственный форум, и свою CMS, и даже генератор веб-интерфейсов для управления базами данных, чем-то похожий на PHPMyAdmin. В те времена английский Интернет казался мне совершенно ненужным.

Я знал о форуме PHPBB и что-то слышал о Smarty. Этого казалось достаточно. Но однажды «выглянул из русского угла», и с тех пор на меня сыплются всевозможные PHP-фреймворки и web-based CRM-системы.

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

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

Нужен блог с полноценным форумом? Так это же WordPress + BBPress.

Хорошей практикой для веб-разработчика по-моему является постоянное изучение существующих продуктов. Что-нибудь вроде «два новых инструмента каждый месяц».

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

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

Постановка задачи
Скажем, мы делаем коллективный блог. В него пишут несколько авторов-экспертов. Есть главная лента со всеми свежими записями. И есть множество лент, которые «режут» контент по годам, по авторам, по тегам. Кстати, история основана на реальных событиях.

Базовое решение
site.ru/ — главная страница сайта.
site.ru/blog/ — блог.
site.ru/blog/2004/ — записи в блоге за 2004 год.

site.ru/blog/2004/
if-it-can-be-fixed.html — постоянный адрес записи, permalink.

site.ru/blog/2004/
it-can-be-fixed-12-june.html — снизим шансы появления в течение года еще одной записи с таким же названием, добавив в импровизированное имя файла дату.

Проблема нескольких плоскостей
Теперь придумаем структуру адреса отдельных авторских лент. Одного из наших блоггеров зовут Athabaska Dick (привет Reno Jimmy). Итак, какой же у ленты адрес?

site.ru/blog/authors/athabaska-dick/ — может так? Нет, плохо. Обычно так выглядят адреса страниц с информацией об авторе.

site.ru/blog/athabaska-dick/ — вроде хорошо.
site.ru/blog/athabaska-dick/
it-can-be-broke-12-june.html — резонно постоянный адрес записи сделать таким.

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

site.ru/blog/2004/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/
it-can-be-fixed-12-june.html

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

Вот и четыре наших альтернативы.

site.ru/blog/2004/
it-can-be-fixed-12-june.html
site.ru/blog/2004/athabaska-dick/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/
it-can-be-fixed-12-june.html
site.ru/blog/athabaska-dick/2004/
it-can-be-fixed-12-june.html

Если критериев будет больше, программист сойдет с ума.

Решение для простых случаев
site.ru/blog/
it-can-be-fixed-12-june-2004.html — в постоянных ссылках на самом деле не существует никаких каталогов. Уберем их из адресов страниц. И добавим в дату год.

Если нужна фильтрация максимум по одному критерию, сделаем так.

site.ru/blog/athabaska-dick/
site.ru/blog/2004/
site.ru/blog/PHP+MySQL/

Если хотим облегчить жизнь программисту, делаем как-то так.

site.ru/blog/by-author/athabaska-dick/
site.ru/blog/years/2004/
site.ru/blog/tags/PHP+MySQL/

Решение для крупных систем
site.ru/blog/?author=athabaska-dick&
year=2004&category1=PHP&category2=MySQL — классический вариант с километром переменных. Супернедружественный и супергибкий.

site.ru/blog/author:athabaska-dick+
year:2004+categories:PHP,MySQL/ — можем уделить этому внимание и сделать очень внушительно. Оправдано ли?

Постраничный вывод
Постраничный вывод лент делаем в самом конце, либо с переменными, либо с дополнительным фальшивым каталогом.

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

Какой адрес страницы лучше: состоящий из английских слов или из русских транслитерированных? Посмотрим на проблему с разных сторон.

Для посетителей лучшими адресами будут короткие и удобочитаемые. Вот варианты адреса статьи «Как сверстать три колонки с подвалом div’ами»:
…/sverstat-3-kolonki-s-podvalom-divami.htm
…/tri-kolonki-divami.htm
…/3-kolonki.htm
…/3-columns-and-footer-using-div.htm
…/3-columns.htm

Подумайте, какие из них вам понравились бы, если бы увидели их в адресной строке?

В этом раунде побеждают названия на английском, поскольку транслитерация русского слова «вопиющий» может выглядеть как «vopiuschiy» или «vopijushchij», а английские варианты — «scandalous» и «crying».

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

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

Еще одна конкурирующая группа — оптимизаторы. Страницы должны выглядеть релевантными определенным запросам.

Специалисты по SEO балансируют между русскими и английскими словами в названиях. С одной стороны в словаре Яндекса может не быть слова «mincing-machine». В этом случае английское название не выполняет свою роль.

Кстати, по моим ощущениям этот «словарь английских слов, влияющих на образ русских страниц» невелик.

С другой стороны в русском языке есть несколько забавных букв, которые транслитерируются неоднозначно. Например, «щ» может быть «sh», «sch», «shh», «shch». Пара таких букв в слове, и робот уже не распознает его. И опять усилия оптимизатора напрасны.

В такой ситуации хороший эффект даст разумное комбинирование.

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

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

Так каких же специалистов выбрать, если денег на большую команду нет? У меня есть рецептик.

Представьте, что вы едете на море поездом. Без него туда не попасть. Но вот в чем штука: если поезд вас довезет, куда нужно, это совсем не гарантирует хороший отдых.

То же самое с веб-программистами: технический специалист необходим, но на успех предприятия практически не влияет.

Он всё написал, настроил, протестировал, зарплату получил. Что ему еще? Если заметите недостаток в работе механизмов, он подправит. А нездорового энтузиазма по-поводу подшипников, которые вы продаете в Кировске, у него нет.

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

Итак, программист — второстепенная фигура, а на первых ролях — «писатель». Это харизматичный персонаж, который делает текст для сайта. От его творчества зависит, как посетители будут воспринимать вашу идею.

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

Вторая фигура — тот, кто будет сайт продвигать. На самом деле он будет раскручивать не ресурс, а писателя. Но за сайтом посетители могут не разглядеть писателя. То есть требуется эдакий рекламный агент.

Лучше бы это был не теоретик маркетинга, а специалист по SEO и, внимание, хороший писатель. По совместительству он может быть и программистом-веб-мастером, который установит и настроит CMS, а в случае чего, подкрутит ее.

Резюме

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

Три года назад я написал форум и установил его на небольшой сайт. Ни регистрации, ни извещений по email там не было. Сегодня я посчитал количество людей, оставивших по одному комментарию. Это 60% всех посетителей. Еще 24% написали не больше пяти сообщений.

Вчера я столкнулся с тем, что архитектура интересной BBS Vanilla не может обеспечить возможность писать незарегистрированным пользователям.

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

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

Однажды кто-то пошутил, написав от имени другого пользователя.

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

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

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

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

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

Читал, что при разработке Excel 5 разработчикам до безумия хотелось сделать развитый мастер создания макросов. И естественно еще тысячу «совершенно необходимых» вещей. Потом они взяли себя в руки, отбросили все интересненькие штучки и выпустили продукт вовремя.

А через некоторое время, размышляя над тем, какой должна быть шестая версия, список фич, которые раньше казались такими ценными, удивлял проектировщиков своей бестолковостью. Об этом в тринадцатом пункте статьи Painless Software Schedules.

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

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

Не спешите реализовывать незапланированную функциональность. Сделайте пометку и вернитесь к ней через пару дней.

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

20% идей со второго-третьего раза кажутся бессмысленными, еще 10% оказываются уже реализованными (за всем не уследишь, хех). 50% — никогда не воплощаются, хотя и выглядят неплохо. Только 20% проходят проверку временем, и им находится место.

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

Например, посмотрим на контент-менеджера, этого человека со странно звучащей должностью. Помимо прочего он добавляет на сайт новости. Попробуем разобраться с процедурой «Сбор и добавление новостей».

Новости в этом примере будут двух сортов: внутренние и внешние.

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

Как же эти внутренние новости попадают в руки нашего героя? Вариантов немало: по email или ICQ, через FTP-сервер, в устной форме по телефону и при личных встречах.

Внешние новости контент-менеджер может собирать, регулярно просматривая список тематических сайтов. Есть варианты с email-подписками и RSS-потоками.

Раз в неделю из всех новостей отбираются те, что поинтереснее, и вводятся через веб-форму на сайт.

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

Из пучины нам поможет выбраться полуфиктивная дисциплина под названием «Реинжиниринг бизнес-процессов».

Для начала приведем все новости к единому формату. Это будет RSS. В админку сайта добавим агрегатор фидов. Забьем в настройки список внешних источников новостей. Сделаем вывод всех обновлений в одной ленте.

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

Фиды внешних и внутренних новостей в свою очередь также объединим. В общей ленте у каждой новости сделаем кнопку «Разместить новость на сайте».

В течение месяца я рассказывал о базовых шагах на начальном этапе разработки веб-ресурсов. Материалов в блоге накопилось достаточно для написания краткого руководства «С какой стороны взяться за создание сайта». Поехали.

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

1. Начните с размышлений о целесообразности старта интернет-проекта. Определитесь, что вы планируете получить от сайта, и чем он сможет заинтересовать посетителей.

Например, для меня этот блог является прежде всего training grounds. Статьи я пишу сам, ими и стараюсь привлечь читателей. А Google бесплатно предлагает блоггерам уникальные мощные инструменты.

Почувствуйте значение смыслового обоснования. Все последующие шаги сверяйте с выработанными на этом этапе тезисами.

2. Попробуйте оправдать существование сайта с экономической точки зрения.

Совсем недавно я попытался проиллюстрировать этот шаг, обосновывая создание веб-представительства магазина постельного белья в Калуге. Результаты получились не слишком оптимистичными.

3. Набросайте бизнес-план. Распишите, как вы планируете достигать цели и решать задачи. Бизнес-план — не пустая формальность и не вода. Сделайте его для себя, а не для инвесторов.

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

5. Всё, что у вас получилось запишите в блокнотик. Это будет основа технического задания. С этими записями можно идти к веб-разработчикам и обсуждать будущий сайт.

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

Попробовав самостоятельно организовать облако тегов, я обратил внимание на некоторые нюансы. О них и расскажу.

У современных облаков есть пара очевидных проблем. Самая заметная заключается в том, что популярные теги, выводимые крупными размерами шрифта, дают худшие результаты при поиске. Возможные способы решения:
* специализация облака,
* ручная модерация,
* возможность искать по наборам тегов. Формировать их можно, например, используя классический прием с зажатым Shift, или организовав «пошаговый набор», как на swik.net.

Другая проблема — порядок вывода тегов в облаке. Сейчас широко распространена сортировка в алфавитном порядке. Но такой подход годится лишь для тех случаев, когда человек ищет в облаке конкретное известное ему слово. Например, для массива на главной странице blogs.yandex.ru сортировка в алфавитном порядке, по-моему, не подходит.

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

При такой организации в облаке
* теги будут сгруппированы по предметным областям,
* синонимы будут выводиться рядом.

Примеры:
* рисунки 7 и 9 на страницах 8 и 10 в «Utilizing Folksonomy: Similarity Metadata from the Del.icio.us System»,
* рисунок 2 на странице 5 в «Improving Tag-Clouds as Visual Information Retrieval Interfaces».

Математическая модель вычисления релевантности между тегами приводится в «Improving Tag-Clouds as Visual Information Retrieval Interfaces».

Как отобразить облако в виде графа с дугами описано в Semidefinite Embedding Applied to Visualizing Folksonomies.

Я пока что не искал готовое ПО для рисования «умных» облаков на сайтах, но, думаю, оно существует. Был бы признателен, если бы кто-нибудь поделился ссылкой на хороший freeware open source модуль.

Долгое время у меня в голове не было четкого разделения понятий «структура сайта» и «система навигации». Дело не в том, что это какой-то большой секрет или высокая материя, нет. Просто я никогда об этом не задумывался. Подобное случается сплошь и рядом: мы не берем в расчет очевидные вещи из-за того, что в голове нет четкого образа.

То же самое со структурой и навигацией. Важно понять, что навигация прикручивается к структуре, а не наоборот.

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

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

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

Через некоторое время я попробую рассказать о том, как я понимаю «конструирование абстрактной системы навигации».

Нередко на посещаемых веб-страницах под заголовками «Популярные записи», «Featured articles» или даже «Cool stuff» публикуются списки лучших материалов. Идея отличная, но есть и обратная сторона: существует проблема отбора действительно стоящего контента.

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

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

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

Совершенствование алгоритмов поисковых систем похоже на эволюцию механизмов формирования рейтингов. Рамблеровская «примесь», «эффект новичка» Яндекса, Google page rank — всё может найти отражение в вашем алгоритме. Разработка формул, по которым рассчитываются позиции в топах мне кажется очень интересным занятием. В случаях с поисковыми системами это может быть головной болью для разработчиков, а для создателей небольшого сайта — это fun.

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

При формировании локального рейтинга можно учитывать
* количество комментариев,
* пользовательские оценки (нужна система голосования),
* авторские оценки,
* количество внешних ссылок.

В правой колонке этого блога тоже есть блок «Популярные записи». Изначально туда попадали, на мой взгляд, не самые лучшие посты. Я немного изменил алгоритм, и теперь там появляются самые читаемые материалы за последние две недели. Так обеспечивается ротация. Через месяц я планирую усложнить механизм. Есть предложения, в какую сторону его развивать? Предлагаю поиграть в инженеров Гугла

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

Нарисовать кусочек сети на бумаге не составляет труда. Организация динамической генерации схем не так проста, но тем и интересна. Основная проблема — рисование связей. Возможностей с технологической точки зрения немало. Вот самые очевидные:
* flash,
* картинки, сделанные с помощью библиотеки GD,
* VML (да-да, он жив),
* даже HTML+CSS.

Я не стал искать готовые веб-решения для графического отображения сетей, а посмотрел в сторону деревьев. Очень быстро нашлись три варианта. Все используют heavy JavaScript. Самый красивый работает с VML. VML — это язык разметки, с помощью которого можно описывать векторные изображения в браузерах Internet Explorer.

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

Можно обойтись и без VML. Посмотрите на знаменитый dTree или на его горизонтальный вариант.

Если бы я серьезно занялся доработкой какого-нибудь из перечисленных решений, то в первую очередь переделал бы деревья в сети, потом добавил бы связывание объектов с помощью drag’n’drop, а также возможность редактирования связей. Это заняло бы пару-тройку дней.

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

Слышали вы о ТЭО?

Чаще всего в русском Интернете встречается такое определение: «Технико-экономическое обоснование (ТЭО) — это расчет экономической целесообразности осуществления проекта, основанный на сравнительной оценке затрат и результатов, эффективности использования, срока окупаемости вложений».

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

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

Итак, до начала разработки должен появиться документ, ясно показывающий выгоду от сайта. Прибыль необязательно должна быть финансовой, нематериальные активы тоже требуют вложений. Но нужно четко уяснить, что «построение сообщества лояльных постребителей» или «формирование положительного образа компании» — слишком общие формулировки.

Необходим здравый, пусть и очень условный расчет. Спросите себя: «Действительно ли сообщество из двадцати лояльных потребителей вернет 5000 $, вложенных в сайт?» И попробуйте честно себе ответить.

Чтобы не быть голословным, в ближайшее время покажу пример.

Обновление от 21.02.2007. Как писать технико-экономическое обоснование (ТЭО)

Допустим, открывается магазин постельного белья в Калуге. Ассортимент неширокий, но товар качественный, подобранный со знанием дела. У владельца магазина появляется мысль сделать сайт. Он сам себе удивляется, потому что идея бредовая, но всё же решает прикинуть, что выходит «по деньгам». Оригинальный предприниматель не умеет делать сайты, но является вполне опытным пользователем Интернета. Итак, он начинает не с расходов, а с доходов.

Изучив статистику запросов «Яндекса» по фразам «купить одеяло в Калуге», «купить наволочку в Калуге», «купить простыню в Калуге», «купить постельное белье в Калуге» бизнесмен понимает, что поисковое продвижение не даст ему сколько-нибудь ощутимого количества клиентов.

Ловкий делец прикидывает, что можно дать бесплатные объявления на калужских сайтах, зарегистрироваться в городском каталоге kaluga.ru, рассказать на местных форумах, каким хорошим подарком молодоженам является качественное постельное белье. Все эти манипуляции займут немного времени, но при аккуратном подходе дадут, скажем, 5 клиентов в год. Это те люди, которые придут в магазин и что-нибудь реально купят. Прибыль составит 1000 рублей.

Можно придумать еще что-то и получить больше покупателей «из Интернета».

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

Предположим, у владельца магазина постельного белья есть еще идеи и за год у него получилось 7000 рублей дохода.

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

Вчера получилось, что благодаря сайту за год в магазин постельного белья придут всего 35 человек. Пусть это будет 2% от всех посетителей веб-ресурса. В этом случае 1750 человек за год увидят сайт. Это более чем скромный показатель, но всё же кое-что: некоторые посетители запомнят магазин и при случае расскажут своим знакомым.

Предположим, сайт понравится сотне посетителей, и они его приметят. За год они встретят много людей, и расскажут про магазин, только в том случае, если их спросят. Итак, 50 заинтересованных человек узнают о том, где можно купить постельное белье. Пятеро доберутся до магазина и сделают покупки на 1000 рублей.

Допустим, 100 человек будут помнить о том, где продается хорошее постельное белье, дольше года. Можно посчитать, какая выгода от этого будет в следующих периодах.

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

Пусть за год появится 2 корпоративных клиента, а прибыль составит 7000 рублей.

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

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

Важно понять, что с сайтом нужно возиться. Если заниматься этим никто не будет, то даже дорогой сайт не сможет поддержать бизнес.

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

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

Сегодня дам несколько ссылок на материалы, более или менее освещающие вопросы моделирования данных.

Схему, показанную в прошлый раз, принято называть «ER-моделью» (Entity-relationship model — модель «сущность-связь»). Подробно и на русском в лекции «Проектирование реляционных баз данных с использованием семантических моделей: ER-диаграммы» на intuit.ru.

Немного по-другому выглядит отображение предметной области с помощью UML (Universal Markup Language – универсальный язык разметки). Об этом в лекции «Проектирование реляционных баз данных с использованием семантических моделей: диаграммы классов языка UML» того же курса «Введение в реляционные базы данных».

В английской «Википедии» есть небольшой список инструментов для рисования ER-диаграмм.

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

Одна из таких нотаций — IDEF1X. Конечно, есть и «IDEF1X entity-relationship diagram notation quick reference» на английском.

На citforum.ru есть пособие по проектированию баз данных с примером.

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

Сегодня я предпринял вторую попытку рассортировать уже 16 записей этого блога. Результат — в правой колонке появился блок «Категории». Удивительно, но уже в процессе работы почувствовал: «Что-то идет не так». Мне не нравились ни категории, ни то, как я распределил по ним материалы. Это притом, что изначально каждая запись снабжалась одной—двумя метками. То есть сегодня я не выдумывал классификацию с нуля, а взял за основу свои ранние примечания, и всё равно потратил целый час на такую ничтожную работу.

Вообще эти категории в блогах — сплошная головная боль. Одни блоггеры используют их как теги. В этом случае получается от двадцати категорий, в основном по две—три записи в каждой. Другие помечают свои записи почти всеми доступными метками. А почему бы и нет? Если есть категория «Интернет», в нее ведь всё пойдет. В конце концов, блог ведется не где-нибудь, а в Интернете. Ага.

Не помню, чтобы когда-нибудь нажимал на «блоги» или «Google». Очевидно, что каждая категория должна показывать какой-то пласт материала на сайте; группировка должна быть продумана, к тому же представлять практический интерес для пользователя. Разрабатывая свои категории, я постоянно думал о смысловой нагрузке, но этого недостаточно.

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

Помещать одну запись в разные категории допустимо и даже вполне разумно. Главное — не перестараться. Я связываю один материал максимум с тремя категориями, хотя в местных масштабах даже это перебор.

Вскоре собираюсь продолжить навигационную тему.

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

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

Очевидно, чем масштабнее проектируемая система, тем сильнее последствия ошибок разработчиков.

Жизненный цикл программного обеспечения предусматривает постоянную всестороннюю корректировку продукта. То есть функции пересматриваются, тексты переписываются, интерфейсы улучшаются, код рефакторится. Между стадиями концептуального и техно-рабочего проектирования нет четкой границы. Разработчики постоянно возвращаются на предыдущие этапы, чтобы что-то изменить. Хороший пример — непрекращающаяся корректировка модели данных.

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

Насколько я знаю, ученые давным-давно снабжают свои работы наборами ключевых слов. Веб-мастера описывают страницы с помощью конструкции еще со времен Парижской Коммуны. Задумывалось, что ключевые слова помогут обеспечить релевантный поиск: если в тексте документа встречается какая-то фраза, да к тому же в ней есть keyword, значит, автор действительно хотел указать читателям: «Да, статья именно об этом».

В какой-то момент практика разметки стала необычайно модной. Пользователи стали размечать тегами всё, что только можно. Тут не обошлось без мировой закулисы, но об этом лучше спросите у старушек в очереди за молоком.

Я же скажу, что большинство пользователей плохо понимают смысл разметки, как таковой. Они генерируют километры слишком абстрактных и нерепрезентативных тегов, и в результате на blogs.yandex.ru мы видим симпатичное, но бесполезное облако. Попробуйте кликнуть по слову «фото».

Облако тегов — просто eye candy, если жестко не ограничивать его контекст. Например, массив профессий на сайте, посвященном поиску работы, или облако тегов за последние два дня, из которого умный модератор исключает бестолковые метки, могут быть достаточно интересными.

С технической точки зрения категории и теги — это одно и тоже. Сходство становится полным, если один материал размещается сразу в нескольких категориях. И всё же различие есть.

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

— Дима, а вот что самое главное в контент-проектах?
— Интересные материалы, которые легко будут находиться поисковиками, и которые читатели будут рекомендовать своим друзьям и знакомым.
— Ладно, не юли. Хотелось бы услышать какую-нибудь идею, а не очевидный ответ.
— Мне кажется, здорово было бы позаботиться о формировании страниц, насыщенных действительно релевантными материалами. То есть человек в центральной колонке получает статью, а справа и слева ему показывают ссылки по теме, фотографии с места событий, связанные новости, информацию об участниках, похожие случаи, комментарии экспертов, прогнозы развития ситуации…

Мысль не нова. Google AdSence давно пытается показывать релевантную рекламу. Новостные сайты дают возможность проследить историю событий, выводя список материалов по теме.

Реклама Google всё же часто не вписывается в контекст. Подборки новостей обычно точны, потому что их составляют люди. Затрат больше — релевантность выше.

На мой взгляд, в небольших и средних проектах вполне реально описать связи между материалами «вручную». Живые люди смогут подобрать релевантные материалы так, как не сможет ни один робот. Дело лишь в понимании человеком важности своей задачи, в его адекватности и ответственности. Несомненно, для разметки отношений между информационными объектами нужен и удобный инструмент.

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

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

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

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

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

Что же помогает посетителю составить представление о содержимом ресурса?

Название

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

Если с понятным названием проблемы, подойдет и абстрактное, что-нибудь вроде «Two biscuits».

В любом случае название лучше пояснить одним-двумя предложениями и поместить их на видном месте.

Блок с коротким рассказом о сайте

Посмотрите, как это сделано на lifehacker.com. Идея проста и эффективна. Если есть необходимость пояснить сущность сайта, воспользуйтесь этим способом.

Если хочется красивый блок, его можно нарисовать.

Графический дизайн

Например, сайт знаменитого «Сталкера». Я знаю, о чем речь и считаю, что графическое и даже звуковое оформление вполне уместно с точки зрения создания атмосферы. Но новый посетитель хоть и почувствует что-то такое, не сразу разберется, в чем дело.

Вообще сайты, посвященные компьютерным играм, часто грешат этим: не понятно, насколько игра «реальна» (возможно ли в нее поиграть сейчас или в ближайшем будущем, или это замороженный проект трехлетней давности) и ее тип (онлайн-проект вселенских масштабов или «single player»). Но если атмосфера привлекает, хочется разобраться.

Содержание сайта

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

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

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

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

Если вы просмотрели заголовки первых постов, то заметили, что там говорится об общеизвестных основах. Я планирую постепенно углубляться в специфические области. Есть мысли о web-based системах управления знаниями, онтологиях, реализации ассоциативных сетей и механизмах формирования релевантных страниц, необычных моделях данных, проектировании пользовательских интерфейсов, способах организации больших массивов данных в администраторских панелях. Буду всё это с удовольствием с вами обсуждать.

Вчера я разбирался с тем, как объяснить пользователю, на какой крутой сайт он попал. Сегодня еще одна несложная мысль: «главная страница» должна давать представление посетителю о предлагаемых возможностях. Представьте, что вы чуть-чуть приоткрыли шкатулку с драгоценностями вашей бабушки-графини, а оттуда вам слепит глаза нестерпимый блеск золота и драгоценных камней. Так вот эта щелочка — «главная страница».

Посмотрите, как устроена «стартовая страница» blogs.yandex.ru. Так и хочется на что-нибудь нажать, обязательно какая-нибудь ссылочка заинтересует.

У technorati.com «первая» не такая сочная, зато они показывают популярные запросы. У «Яндекса» нельзя узнать, что ищут в блогах, а на technorati можно.

Это были два хороших примера. Теперь о грустном.

Слишком часто на сайтах, сделанных на PHPNuke, Mamba или других CMS, по умолчанию центральная колонка заполняется новостями. А простодушные веб-мастера верят, что так и нужно. В сумме с десятком блоков в правой и левой колонках получается пестро и празднично, но за этой завесой не видно сути.

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

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

В разделе «новости» (обычно в центральной колонке) сиротливо тоскует заметка о семилетнем юбилее фирмы. Пара счетчиков, логотип, невнятное «у нас очень дружный коллектив и мы ТАК ЛЮБИМ своих клиентов». Зато достаточно ветвистое для такого ресурса меню. Здесь вам и «контакты», и «о компании», и «схема проезда», и «реквизиты». Ведь нужно же меню. Какой может быть сайт без меню минимум из пяти пунктов?

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

Мораль такова: на «главной» нужно показывать кусочки самого важного, полезного и интересного из того, что есть на сайте. Если у вас живой форум — показывайте последние сообщения, если дельные статьи — заголовки и аннотации. Разве не логично?

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

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

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

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

Итак, два сильно связанных критерия размещения элементов на главной странице: их качество и «интересность» для целевой аудитории. В самом начале проекта представьте себе несколько человек, которым может понадобиться ваш сайт. Подумайте, что им нужно, и сможете ли вы им это дать.

В следующий раз пост будет ближе к практике, собственно к проектированию сайтов в явном виде.

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

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

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

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

После того, как базовые сущности «утрясутся», займитесь выявлением отношений между ними. Например, статьи пишут авторы. Автор может написать сотни статей. У статьи могут быть несколько авторов и рецензент. Авторы и рецензенты — это люди, которые участвуют в конференциях и ведут семинары. Конференции и семинары — это события. И так далее. Крутя этот кубик, вы посмотрите на предметную область с разных сторон. Полезный опыт.

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

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

Кстати, вопрос: кому-нибудь интересно «копнуть поглубже», или все об этом знают? А может считаете всё это не заслуживающим внимания. Need some feedback.

Однажды я делал систему для организации, занимающейся тренингами. Устройство получилось сложным, опишу его лишь в общих чертах. Получилось больше похоже не на сайт в привычном понимании, а на web-based информационную систему.

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

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

Итак, что же мы делали? Прежде всего, выделили сущности предметной области. Как вы могли заметить, в системе присутствует вполне очевидная иерархия объектов, то есть «люди» — это верхний уровень, а «тренеры» и «участники» — нижний («люди» — родители, «тренеры» и «участники» — потомки).

Затем определили свойства объектов. Это не совсем поля таблиц базы данных, скорее, их прообразы. Свойства – это характеристики сущностей. У каждого человека есть имя, которое и является примером свойства.

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

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

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

Кстати, я зря пошутил в названии лекции: это отвлекает и увеличивает шансы что-то пропустить.

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

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

Я же не буду мучить вас своими каракулями, а сразу покажу схему, изготовленную в Sybase PowerDesigner.

Если внимательно рассмотреть эту картинку, то даже неподготовленному зрителю многое станет понятно. Такая логическая схема в этом средстве называется Conceptual Data Model (CDM). Потом из нее можно получить графическое изображение физической структуры базы данных. Дальше можно, например, экспортировать эту структуру в какую-нибудь СУБД.

На моей схеме изображены три сущности и их атрибуты, а также отношения, на которых остановимся поподробнее. Обратите внимание на отношение между «event» и «program»: со стороны программ связь представлена одной линией, а со стороны событий она ветвится. Это означает, что по одной и той же программе могут проводиться несколько тренингов, но тренинг всегда проводится по одной программе.

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

Обратите внимания и на подписи связей.

При щелчке правой кнопкой мыши по любой сущности или отношению появляется контекстное меню. В нем около десятка пунктов, многие из которых вызывают формы с 5—8 вкладками, так что, как видите, недостатка в настройках не ощущается. На этих формах настраиваются параметры объектов, а схема изменяется с их учетом.

Итак, как же нам помогла эта схема при проектировании помимо очевидного ее развития в физическую модель? Изначально на сайте планировались несвязанные страницы: «события», «тренеры», «программы» и т. д. После изучения полученной модели появилась, например, идея на странице конкретного события выводить не только его непосредственное описание, но и списки участников, организаторов, тренеров, ссылку на описание программы и автора программы. Теперь пользователь получает больше релевантного содержимого. Разве не здорово?

Вообще, PowerDesigner — мощный-премощный инструмент, из всех возможностей которого я знаю 10%. На сайте есть trial-версия и горы документации, так что рекомендую ознакомиться.

Словосочетание «проектировщик сайтов» режет слух. Оно очень неуклюжее. Но какие есть альтернативы?

Термин «веб-дизайнер» («web-designer») давно и прочно дискредитирован. Хотя мне кажется, что именно проектирование изначально подразумевалось главной функцией веб-дизайнера («design» – проектирование). К сожалению, раньше под веб-дизайнерами подразумевали вообще всех разработчиков сайтов, а сейчас их постоянно путают с графическими дизайнерами.

Как-то неприятно становится, когда какой-нибудь прилизанный хлыщ: «Да… Надо напрячь своих веб-дизигнеров». Ведь он говорит совсем не о тех людях, правда?

«Web-engineer» в английском используется достаточно часто. Но по-русски «веб-инженер» звучит совсем непривычно. Даже комично. Не лучше звучит и производный термин «веб-инжиниринг» («web-engineering»). Кстати, монструозное «реинжиниринг бизнес-процессов» вполне прижилось.

«Веб-разработчик» («web-developer» и даже «веб-девелопер») слишком общая категория.

Еще варианты: «инженер сайтов», «архитектор сайтов», «проектировщик веб-приложений», «инженер веб-прилодений».

Ваши предложения?

Если просмотреть объявления, например, на free-lance.ru, то можно выделить целый класс «Нужен дизайн для сайта за 100—200 $$». Иногда к этому прибавляют пару слов о предметной области, что-то вроде «фирма делает ножницы из дамасской стали уже 7 лет, лидер на региональном рынке». И всё.

Десятки охотников начинают рисовать шаблоны. А что на нем рисовать-то? Конечно же ножницы, острые лезвия или какую-нибудь hi-tech абстракцию в 3d. С графической частью ясно.

Теперь наполнение шаблона. Сайт корпоративный? Ага, значит, «Новости», «Наши клиенты», «Контакты», «Продукция», «О компании». И хватит. На «главной» новости в центральной колонке. Меню в левую колонку, а то пустовато получается. Что-то в правой колонке пустовато… Форму поиска туда и делов-то.

Всё, проект готов. И никто не будет кардинально менять разделы и расположение элементов на странице (да и сами элементы).

Только дело в том, что «главная» с новостями в центральной колонке посетителям совсем не интересна, если это не новостной сайт

Интересно, когда объявления типа «Нужен проект сайта» с прилагаемыми требованиями, пожеланиями и описанием сферы деятельности станут обычным делом?

Лет десять назад сайты были совсем простыми, и всех, как-то связанных с разработкой и поддержкой, называли «веб-дизайнерами» и «веб-мастерами». Но постепенно стала появляться специализация. Сегодня в команду разработчиков могут входить графические и информационные дизайнеры, верстальщики, всевозможные программисты, юзабилисты, писатели, фотографы, оптимизаторы. Для такой команды нужен и координатор — менеджер проекта.

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

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

В этом блоге я буду освещать вопросы проектирования сайтов.

Что делать после того, как вы ознакомились с предметной областью? Придумывать разделы будущего сайта? Рисовать шаблон на бумаге? А может покупать доменное имя? Думаю, нет.

После появления «первичной идеи» сайта полезно ответить на два вопроса.

1. Что сайт может дать вам?

2. Что сайт может дать посетителям?

Вопросы не так просты. Итак, что с первым?

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

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

Получение отдачи критически важно для создания хорошего сайта. Формы отдачи могут быть самыми экзотическими, но она должна быть.

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

Что я рассчитываю получить от этого блога? Надолго ли хватит запала? Зачем мне писать сюда, ведь это отнимает время, а результаты не впечатляют? Я об этом, конечно же, думал.

Итак, я хотел бы развивать свои навыки веб-разработки. При этом меня мало интересуют технические вопросы вроде конкатенации строк при GROUP BY. Хотелось бы не просто владеть инструментами, а уметь делать с их помощью качественные вещи.

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

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

Если, например, посещаемость будет человек 200 в день, то попробую повесить рекламу.

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

Хорошо. Подумали-подумали и решили, что идея сайта не разонравится через неделю и сил хватит. Можно начинать разработку проекта? В принципе, да. Можно убедить себя в том, что количество посетителей не важно, а главное, чтобы было интересно сайтом заниматься (или чтобы деньги заплатили).

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

Из всего вышесказанного заключаю, что нужно подумать не только о себе, но и пользователях. Это сложнее, чем искать «собственный интерес», но интереснее с точки зрения творческого аспекта проектирования.

О том, что же нужно пользователям, писали много. В принципе все просто: они ищут либо информацию (развлекательную или полезную), либо услугу (сервис), либо точку приложения своих космических сил (сюда включим любые «активности», возможные в Интернете).

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

Моё убеждение, что проектировщик должен здорово придумывать, чем же сайт сможет зацепить человека. Как представить обычную компанию, продающую нечто, живо и привлекательно? Вот вопрос.

Можно свалить всё на маркетингового писателя или вообще забить, но это не путь героев. Примеры в следующий раз.
Все объявления
ЯндексДирект
Дать объявлениеСоздание своего интерне

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

В качестве примера расскажу немного о beta.blogger.com.

У Google есть своя площадка для блогов — blogspot.com. Их платформа была хороша и до этой осени, но в сентябре они предложили блоггерам сервис, выделивший их среди популярных блог-хостингов.

Ребята из Google сделали графическую систему управления шаблонами. То есть на экране веб-редактора (страница, открывающаяся в окне браузера) видно все блоки блога: RSS-фиды, группы ссылок, информацию об авторе, архив, шапку. Управлять их расположением на странице можно, перетаскивая элементы (JavaScript реализация drag’n’drop не такая уж и новинка). Более того, можно создавать новые блоки, причем, ассортимент достаточно велик.

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

Похоже устроены «домашние страницы», которые Google предлагает настроить при заходе на google.com. Разница в том, что при редактировании блоговых шаблонов типов наполнения много (например, можно создавать элементы для HTML и JavaScript кода third-party решений), а на «домашних страницах» разрешается размещать только фиды.

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

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

Список можно продолжать. Можно сказать, что проектировщик должен обладать всесторонними знаниями о разработке сайтов, но в меньше объеме, чем эксперты в своих областях.

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

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

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

Восточная мудрость гласит: «Когда ученик готов, находится учитель». Тим Бернерс-Ли, автор HTML, оказался в состоянии стать последователем Чарльза Гольдфарба, с именем которого связано создание языка SGML — вероятно, самого мощного инструмента для разметки текстов. Но в самой этой идее ничего нового нет. Специальные символы для разметки текстов издавна использовали корректоры, элементы разметки можно обнаружить в командах roff, nroff и troff, призванных обеспечить вывод текста независимо от типа устройства печати. Несколько раньше, в 1967 году, канадским полиграфистом Уильямом Танниклифом была разработана концепция GenCod, которая впервые позволила решить важнейшую задачу, отделить содержание документа от его формата. Позже для этой цели стали использоваться языки разметки. Аналогичные работы вел американец Стенли Райс. (С появлением языка XML был сделан следующий шаг, интерпретация содержания, но это особая тема.)

язык Standard Generalized Markup Language стал первоосновой современной Паутины

язык Standard Generalized Markup Language стал первоосновой современной Паутины. Второй ее первоисточник — гипертекст

С момента появления самых первых систем работы с текстами на компьютерах все электронные документы содержали те или иные символы для управления печатью (CR, LF и др.). Однако их возможности были весьма ограниченны, методы разметки были привязаны к определенным принтерам, а с появлением новых устройств с более широкими возможностями (такими, скажем, как принтер с шариковой головкой) потребовались новые средства для управления печатью. Поэтому исследовательская группа корпорации IBM, возглавляемая Гольдфарбом, в состав которой входили также Эдвар Моше и Пэймонд Лурье, разработала — изначально для юридических приложений — язык Generalized Markup Language (аббревиатуру GML еще можно расшифровывать по именам авторов). При разработке GML были использованы достижения полиграфистов Танниклифа и Райса. Вскоре GML получил корпоративное признание, был реализован на мэйнфреймах IBM. С тех пор более 90% документов корпорации было подготовлено с использованием этой технологии.

Последующие исследования в области структуризации документов Гольдфарб вел самостоятельно; в конечном итоге они привели его к созданию языка Standard Generalized Markup Language (SGML). В период с 1978-го по 1985 год язык проходил сложный процесс стандартизации. В конечном итоге он был принят и American National Standards Institute (ANSI), и европейским агентством Computer Office of Official Publications. На следующем этапе SGML попал в европейский центр исследований физики элементарных частиц (CERN). Здесь первое средство для использования SGML разработал Андерс Берглунд, а Эрик ван Эрвиген написал одно из первых руководств по использованию SGML. В CERN была разработана и технология CERNDOC на основе SGML, которая в последующем оказалась столь успешной, что была принята американской ассоциацией издателей American Association of Publishers. Одним из активных пользователей этой технологии был Бернерс-Ли, поэтому нет ничего удивительного в том, что при разработке HTML он использовал свой опыт работы с SGML.

Впрочем, развитием SGML занимались многие. Одной из самых заметных персон был Юрий Иванович Рубинский, писатель и основатель канадской компании SoftQuad Software, которая первой в 1994 году выпустила коммерческий продукт HoTMetaL для поддержки HTML, основанный на ее предыдущем продукте Author Editor, поддерживавшем SGML.

Таким образом, SGML стал первоосновой современной Паутины. Второй ее первоисточник — гипертекст. Этот термин был предложен в 1965 году Тедом Нельсоном, который определил его следующим образом: «Массив текстов или графики, объединенных сложными связями, которые с достаточной полнотой не могут быть представлены в бумажной форме. Связи могут включать карты контента, ссылки, аннотации, комментарии и другие инструменты для указания». Гипертекст может быть полноценно реализован только в электронной форме, однако предпосылки к его возникновению обнаруживаются задолго до появления компьютеров. Впервые аннотирование использовали в Александрийской библиотеке за 300 лет до нашей эры, а из 37 томов Естественной истории Плиния (79 год) Книга первая представляла собой оглавление. С появлением книгопечатания способы доступа к информации совершенствовались; вершиной этих работ стали грандиозные, но так и не реализованные проекты бельгийского библиографа Пола Отле.

Приблизился к созданию гипертекстовых решений Ванневар Буш. В своей эпохальной статье As We May Think, опубликованной в Atlantic Monthly, представляя гипотетическую машину memex и предвосхищая Нельсона, он писал: «Появятся новые типы энциклопедий, где фрагменты будут объединены ассоциативными связями, которые могут обрабатываться средствами memex». Задуманная Бушем машина должна была хранить книги и другие документы, обеспечивать доступ к ним и таким образом расширять творческие возможности человека.

Эта статья была прочитана Дагом Энгельбартом и стала стимулом для его долговременных исследований в области систем, расширяющих интеллектуальные возможности человека. Эти работы в конечном итоге привели его к созданию лаборатории Augmentation Research Center, где была построена уникальная для своего времени система NLS (oNLine System). Она стала стимулом для последовавших за ней работ по персонализации вычислительных систем; компьютерная мышь оказалась самым знаменитым отпрыском этого проекта. Сейчас Энгельбарт возглавляет свой собственный, частный институт и работает над «открытой системой гипердокументов» — структурой, построенной на основе стандартов и открытых кодов и предназначенной для коллективной работы и управления знаниями. В качестве хранилища в ней используется «динамический репозитарий знаний» (Dynamic Knowledge Repository), а процессором служит инструмент, названный «гиперскопом». По замыслу гиперскоп должен позволять просматривать разнородные документы и устанавливать между ними связи.

В 1967 году Энди ван Дам и Тед Нельсон создали систему Hypertext Editing System (HES), которая использовалась при подготовке документации в рамках космической программы «Аполлон». Позже ван Дам разработал еще одну систему, File Retrieval and Editing System (FRESS), заимствовавшую интерактивные подходы из NLS. В этой системе впервые была реализована функция отката, без которой не мыслится ни один современный текстовый процессор.

Позже Нельсон загорелся идеей проекта, названного им Xanadu. Сказочная страна Ксанаду пригрезилась в конце XVIII века английскому поэту Сэмюэлу Колриджу под влиянием опиумного опьянения; с тех пор это название используют для обозначения несбыточной мечты. Происхождение названия Нельсон описал в книге Literary Machines («Ученые машины»), опубликованной в 1981 году. В следующей книге, Dream Machines (1988 год, «Машины мечты»), Нельсон описал три вида гипертекста, из которых нам в наибольшей степени известен первый — простые ссылки (links). Расширенные ссылки (expansion links) и параллельное представление текстов известны меньше. Проект Xanadu, начатый в 1972 году, был написан на двух самых популярных языках программирования того времени, Алголе и Фортране, и содержал целый ряд нововведений по части структур данных.

Чарльз Гольдфарб

Чарльз Гольдфарб получил высшее образование в Гарвардском университете, который закончил в 1964 году с дипломом юриста. Спустя два года он впервые узнал, что такое компьютерная программа, от своих единомышленников, разделявших с ним одно хобби — организацию бостонского спортивного ралли. Составляемые Гольдфарбом описания маршрутов очень напоминали компьютерные программы. Гольдфарб принял решение решительно изменить свою карьеру и вскоре поступил на работу в корпорацию IBM. В 1969 году IBM предложила ему интересный проект — создание компьютерной системы обслуживания юридических контор. Перед ним была поставлена задача организовать хранение юридических документов так, чтобы юристы могли легко запрашивать и получать информацию. Гольдфарб использовал в качестве основы так называемые типографские соглашения, применяемые наборщиками при оформлении печатных текстов. Результатом работы стал первый язык разметки документов GML (Generalized Markup Language). GML не зависел ни от марки компьютеров, ни от ОС, и IBM удалось перевести 90% своей документации в этот формат. Сам Гольдфарб в течение многих лет работал в исследовательском центре IBM Almaden Research Center.

Теодор Холм-Нельсон

Теодор Холм-Нельсон родился в 1937 году. В 1959 году он получил диплом бакалавра по философии в высшей школе Swarthmore College, в 1963 году — степень магистра социологии в Гарвардском университете. В 1960 году он начал работу над проектом Project Xanadu по созданию компьютерной сети с простым пользовательским интерфейсом. Результаты работы он отразил в своих книгах, вышедших в 1974 и 1981 годах. Фактически большую часть жизни Нельсон посвятил своему проекту и его защите. В то же время сам проект фактически провалился по целому ряду причин. Часть заложенных в него идей нашла воплощение в принципах WWW. Кроме того, Нельсон работал над новой информационной структурой ZigZag, с описанием которой можно познакомиться на сайте проекта Project Xanadu. Сейчас Нельсон занимается философией и читает лекции в Оксфордском университете по специальностям, связанным с информацией, компьютерами и человеко-машинным взаимодействием. Вклад Нельсона в современные ИТ-технологии носит концептуальный характер: в 1963 году он предложил термин «гипертекст», он также является автором таких слов, как, например, гипермедиа и виртуальность.

Юрий Рубински

Юрий Рубински (1952 — 1996) родился в Ливане; когда ему было три года, семья переехала в Канаду. Рубински закончил университет Brock University, кроме того, он обучался архитектуре в Университете города Торонто. После окончания университета он перепробовал довольно много занятий, пока не остановился на издательской деятельности. В 1978 году Рубински прошел обучение на курсах издателей Radcliffe Publishing в Гарвардском университете. В 1984 году с тремя товарищами он основал небольшую технологическую компанию SoftQuad, заняв пост ее президента. SoftQuad разработала и вела успешную продажу нескольких вариантов инструментов SGML, в том числе первый коммерческий продукт для авторов на базе HTML, который назывался HoTMetaL. Рубински приложил много усилий к объединению всего SGML-сообщества, чем завоевал всеобщее уважение. Кроме того, он специально занимался вопросами доступности программных продуктов и информации людям с физическими недостатками, например пытался применить SGML для разработки средств доступа для слепых. В Канаде Рубински известен также как один из основателей и директоров влиятельного издательства Banff Publishing Workshop.

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

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

Думаете, когда вы размещаете свою страничку (или сайт) в Интернете, о трафике можно не задумываться? Увы, о нем-то как раз и приходится задумываться, но, как и в случае с домашними пользователями, — не сразу. Сначала вы просто делаете свою страничку и выкладываете ее на какой-то хостинг. На нее приходит пара-тройка друзей, а трафик с этой странички (текст и картинки, которые автоматически скачивают любые посетители, зашедшие на сайт) составляет такие жалкие величины, на которые не стоит даже обращать внимания. При этом вы платите за хостинг копейки и больше ни о чем не задумываетесь.

Но страничку же хочется развивать, правильно? И тогда вы начинаете над ней, во-первых, плотно работать, создавая новые разделы, а кроме того, стараетесь наполнять сайт различным содержимым. Понятно, что одними своими текстами наполнять страничку получается далеко не у всех. И тогда в ход идет тяжелая (во всех смыслах) артиллерия: музыка формата MP3, картинки, архивы программ и так далее. А уж если вам захочется поставить какой-нибудь новомодный, хотя и очень громоздкий форум, и если туда, не дай бог, начнет каждый день приходить серьезная тусовка — тогда трафик, исходящий с этой страницы, начнет измеряться довольно солидными величинами, после чего хостер вам скажет: «Дружок, какого черта?».

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

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

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

Что интересно, до недавнего времени такая парадоксальная ситуация действительно имела место: провайдеры получали деньги за трафик и с пользователей, и с владельцев серверов. Конечно, можно возразить, что часть пользователей платит только за время, проведенное в Интернете, однако с чего они там время-то проводят? С того, что мы, создатели интернетовских страниц, эти страницы выложили в Интернете. Поэтому не должны вебмастера платить за трафик, не должны! В этом я глубоко убежден.

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

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

Изюминка, обязательно должна быть изюминка, которая запомнится, при виде которой и дети и взрослые будут вспоминать называние Вашего проекта, и никак иначе. Это может быть какой-то символ, уникальный, нигде не используемый, но который бросится в глаза и запомнится народным массам быстро и надолго, и будет для них постоянным напоминанием о Вашей фирме. Возможно, это будет что-то конкретное, а может быть — абстрактное. Возможно — необычное сочетание определенных цветов, придумать можно что угодно. Главное чтоб во всех элементах фирменного стиля был эта «изюминка» или как минимум — что-то похожее, явно и четко связанное с основной деталью. Иначе — восприятие будет расплывчатое и нечеткое, примерно так: «да… где то это я видел… а где — не помню…. ну да и ладно, черт с ним», а должно быть: «О!!! Да это же _________! Надо зайти, как раз мимо иду. Да, обязательно зайду!». Результативность — небо и земля. А четко подобранный элемент может к тому же принести свои плоды в двойном объеме. Предположим в фирменном стиле вашей компании таким элементом является кокосовый орех. Если все сделано правильно, и в сознании ваших потенциальных клиентов кокос ассоциируется с вашей фирмой — значит при виде кокоса к примеру на прилавке магазина, многие непроизвольно вспомнят о вас.

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

Но вернемся к дизайну. Изюминка есть. Должно быть и общее цветовое решение. Грамотно подобрать цветовое решение — непросто. Во-первых, все цвета уже используются в самых разнообразных вариациях. Во-вторых, цвет должен сочетаться с деятельностью фирмы, быть не слишком «пустым», не раздражающим человеческий глаз. Цветовая гамма должна переходить плавно от одного цвета к другому (в промежутке возможен еще какой-то цвет, но использовать много цветов ни к чему, дабы не рассеивать внимание). На мой взгляд, идеальный вариант — использовать два цвета — один нейтральный, не очень броский, но приятный, мягкий, второй — более яркий, несущий в себе эмоциональное содержание всего стиля и в общем то и фирмы тоже. При этом не стоит забывать, что есть холодные и теплые цвета, которые воспринимаются соответствующим образом; черно-белое уже давно истоптано вдоль и поперек, а серый — цвет пустой и без информационный, хотя хороший дизайнер в силах исправить это, придав серому цвету жизненности и зарядив позитивом, все зависит от фантазии и творческо-философского взгляда на мир Опять же главное — идея, оригинальность, и никогда НИКАКОГО ПЛАГИАТА!

Что же входит в фирменный стиль? Да все что угодно. Оформление офиса, дизайн различной рекламы, наклеек, воблеров, рекламных блоков газетах, журналах, на ТВ. Если сотрудники работают в торговом зале — возможно у них будет какая то одежда единого стиля с фирменной символикой. Разнообразные канцелярские мелочи — блокноты с логотипами, ручки, подставки и т.п. Везде, где есть визуальное представление — должно быть то, что свяжет это представление именно с вашей фирмой и натолкнет человека на необходимость воспользоваться вашими услугами, а не чьими то еще. Кстати очень полезно дарить подарки (те же ручки-блокноты) с фирменной символикой, потому что эти предметы служат долгое время и действительно используются людьми в повседневной домашней и трудовой жизни. А поводов найти для того чтобы устроить акцию с подарками и призами можно огромное количество: приближающийся новый год, день рождения фирмы, день всех влюбленных, 8 марта, 23 февраля — да сколько угодно!

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

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

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

Типы ссылок

1. Текстовые ссылки – наиболее простая форма навигации. Обычно это 1-3 слова, которые описывают то, куда приведет данная ссылка. Например: карта сайта, связь с нами, ссылки, гостевая книга и т.д.

Преимущества:

Высокая скорость загрузки. Читаемость во всех броузерах. Легкая масштабируемость и редактирование. Помогают в ранжировании запросов с поисковых систем.

Недостатки:

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

Мысли:

Можно добавить дополнительную информацию (в строку состояния, например) к текстовым гиперссылкам средствами JavaScript (команда OnMouseOver), однако следует иметь в виду, что некоторые сёрферы не очень любят, когда строка состояния не показывает реальные ссылки. К тому же, большинство современных броузеров позволяют отключить строку состояния.

2. Графические ссылки – разобъем их на две категории: графические карты (image maps) и кнопки.

2.1. Графические карты – отдельный графический элемент, разделенный на несколько участков, которые, в свою очередь, являются гиперссылками.

Преимущества:

Карты могут выглядеть достаточно эффектно. Они удобны для установки одного графического элемента вместо нескольких. Служат довольно сильным средством коммуникации с пользователем.

Недостатки:

Самый большой недостаток в том, что при отключении пользователем загрузки графики в своем броузере, карта бесполезна! Скорость загрузки графики играет немаловажную роль. Труднообновляемы (скорее всего придется переделывать всю карту). Пользователи иногда должны «поиграть мышкой», пытаясь найти ссылку. Для поисковых машин картинка мало что значит…

Мысли:

Правильно сделанные карты могут заставить пользователя «ахнуть» при заходе на сайт. Однако, вы НЕ МОЖЕТЕ полагаться на карты изображения, как на единственное средство передвижения по сайту. На некоторых сайтах я стал жертвой графических карт, пытаясь найти ссылки, и больше туда не вернулся… Также, ожидать карту размером в 100КБ – самоубийство. Это явно не поможет привлечению посетителей на сайт.

2.2. Графические кнопки

Преимущества:

Привлекают внимание пользователя (не всегда конечно). Могут быть более описательными (визуально), нежели простые текстовые ссылки. Могут дать визульное ощущение пользователю где он находится в данный момент (то есть кнопка для текущей страницы слегка отличается от других кнопок). Более гибки, чем графические карты. Более быстрая загрузка, чем у карты. Нет необходимости «нащупывания» ссылок.

Недостатки:

Время загрузки. Часто, кнопки менее описательны (наглядны), чем простой текст. Небходимость делать новую кнопку для любых дополнительных разделов сайта. Плохо применимо для больших сайтов. Без ALT аттрибутов, незагруженные кнопки не пригодны для навигации. Не очень полезны в достижении высокого положения в запросах поисковых серверов.

Мысли:

Графические кнопки, содержащие только текст, должны, вероятно, быть заменены текстовыми ссылками, менее загружащими траффик. Помните, что если вы собираетесь использовать OnMouseOver с вашими кнопками, то это удваивает скорость загрузки. Если ваш сайт нуждается в 20 кнопках для навигации, – о графических кнопках можете забыть, вместо этого используйте текстовые ссылки. Использование аттрибута ALT для описания ваших кнопок должно быть обязательным!

О месторасположении…

Ссылка1 | Ссылка2 | Ссылка3 | Ссылка4 | Ссылка5

Ссылка2

Ссылка3

Ссылка4

Ссылка5 | Ссылка4 | Ссылка3 | Ссылка2 | Ссылка1

От месторасположения навигационной панели зависит то, насколько эффективна навигация по сайту как таковая.

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

Если панель внизу – это удобно, так как чтение страницы обычно заканчивается именно там. Однако, эта область остается невидимой пока страницу не прокрутят до конца вниз. Хорошая новость для любителей навигации снизу: большинство людей знают о такой системе навигации спустя лишь несколько часов сёрфинга в интернете и пытаются найти такую панель внизу страницы.

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

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

Мысли:

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

Не удивляйте пользователя «вдруг» новой навигационной панелью. Посетитель, который нажимает кнопку и внезапно находит на открывшейся странице абсолютно новую навигационную панель, будет очень запутан тем, где же он все-таки находится. Он может подумать, что попал на другой сайт или же, что неожиданно для него был введен новый раздел. Почему он не был предупрежден об этом на предыдущей странице?

«Навигационная удовлетворенность» посетителя от сайта напрямую зависит от скорости достижения необходимой ему информации, поэтому:

Старайтесь быть описательными: вкладывайте как можно больше информации в вашу навигационную систему. Вы помните загадочную схему кнопок Майкрософта в их программах? Все мы потратили пару дней, для того чтобы узнать, что кнопка с пустой страницей это «Новый Документ» и что две страницы, одна над другой, это «Копирование». Это – НЕ интуитивная навигация. Добавляйте текст к графическим кнопкам. Используйте текстовые ссылки с открытым смыслом, будьте описательными настолько, насколько это позволяет место.

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

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

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

gimp
Изначально разработанный под linux, а позднее скомпилированный под windows-платформу, gimp получил популярность именно из-за того, что он бесплатный.

Этот мощный профессиональный графический редактор — прямая альтернатива photoshop и по возможностям мало в чем ему уступает.

Хороши расширенные настройки стандартных фильтров (например, первое, чем начал пользоваться я, — размытие по Гауссу, где можно отдельно указывать радиус размытия по горизонтали и вертикали). Есть некоторые опции, облегчающие работу, — так, к примеру, тонирование фотографии выполняется из отдельного меню. Стандартные операции, такие, как регулировка уровней, кривых, тона/насыщенности, баланса цветов, аналогичны используемым в photoshop. Также есть и автонастройки: они вынесены в отдельное меню «авто» — это правильный ход.

Программа поддерживает большое число графических форматов — даже формат psd, правда, с ограничениями.

Теперь о недостатках. К ним можно отнести, например, невозможность применения корректирующих слоев для обработки фотографий. По крайней мере, это кажется недостатком после работы в photoshop. c помощью наложения таких слоев в photoshop можно очень тонко осуществить всю основную коррекцию изображения, и при этом любые параметры этой коррекции всегда можно изменить. В gimp при открытии файлов формата psd с такими слоями картинка, естественно, интерпретируется по-другому, чем в photoshop.

Не очень понравился интерфейс. Опять же, после photoshop приходится привыкать к другой организации меню, другим «горячим» клавишам, хотя, если начинать с нуля, это не недостаток. Расположение диалогов — на любителя. При небольшом разрешении экрана они закрывают собой все изображение. Нельзя прятать их в меню быстрого доступа, как это сделано в photoshop, чтобы очистить рабочее пространство. Хотя стоит отметить, что можно обрабатывать изображение, расположив соответствующее окно поверх диалогов, — это может быть вполне удобно, дело привычки.

Программа работает медленнее, чем photoshop (для сравнения использовалась 7-я версия), на старых машинах это обстоятельство может причинять неудобства.

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

serif photoplus 6,0
Программа бесплатная, но требует обязательной регистрации на сайте разработчика, иначе работать отказывается.

Что здесь можно отметить, так это классический интерфейс и возможность полноценной работы со слоями (корректирующих слоев здесь также нет). Имеется минимальный набор фильтров, который можно расширять, этот набор идентичен набору фильтров photoshop. Также присутствует всенародно любимая функция удаления эффекта красных глаз. Условно программу можно охарактеризовать как «photoshop в миниатюре»: организация меню, эффекты, настройки — все здесь напоминает о «старшем брате». Для сохранения результатов работы используется собственный формат файлов с расширением spp. Для сохранения в другом формате следует пользоваться функцией экспорта, которая, в свою очередь, поддерживает достаточно много разных форматов. Не может не радовать оптимизатор изображения при экспорте в jpeg и другие форматы файлов (для этого специально вызывается экспорт с оптимизацией). Это удобно для подготовки изображений к публикации в интернете. Скорость работы программы можно охарактеризовать как среднюю.

Да и вообще, программа представляет из себя инструмент со «средними» возможностями — умеет куда больше многих, но до уровня корифеев не дотягивает.

image forge
Самый старый редактор в обзоре. Версия 3,6 датируется 2004 годом. Возможности программы не впечатляют, кроме того, программа имеет ряд особенностей. Например, вызвав одно меню «effects», можно выполнить сразу несколько операций над изображением, выбирая последовательно различные действия. Еще одна особенность — наличие меню часто используемых основных и последних использованных в работе цветов, это очень удобно, и порой такой функции не хватает в более серьезных редакторах. Слои не поддерживаются (как и во всех последующих программах этого обзора). Для рисования есть несколько стандартных кистей — круглой, овальной и более сложной формы. Интересный момент: при сохранении в формат tiff, не спрашивая, выбирает сжатие «packbits». Это странно и может показаться неудобным (например, автор предпочитает сжимать с использованием алгоритма lzw или не сжимать совсем).

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

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

image analyzer
Этот редактор достаточно интересен. Уже из названия ясно, что он предназначен для анализа изображений. Такой редактор наверняка будет интересен людям с «техническим» складом ума. Из полезных особенностей программы можно выделить jpeg filter (предназначенный для борьбы с артефактами от сжатия в формате jpg), а также adaptive noise reduction (для подавления шумов). Из автоматики имеются функция автоцвета с тремя режимами работы (идентична команде «автоуровни» в photoshop для автоматического регулирования цвета и баланса белого, и режимы те же) и функция удаления эффекта красных глаз. Интересно также, что в программе есть возможность подстановки цветового профиля монитора. Список эффектов достаточно стандартен, фильтры напоминают джентльменский набор photoshop. В то же время существует несколько особенностей в реализации стандартных возможностей. Так, например, инструмент под названием «color mapper» — это нечто среднее между инструментами «кривые» и «уровни» в photoshop, предназначенными для точного регулирования яркости и контраста как всего изображения, так и отдельно его цветовых составляющих. Здесь при редактировании кривых показывается еще и гистограмма уровней — это очень удобно. А вот инструмент «color balance» разочаровал — его возможности минимальны. Хотя после «color mapper» он, наверное, и не потребуется — все равно неприятно. Очень интересная функция — «characterize». Помните изображение Моны Лизы из «Служебного романа», выполненное при помощи единиц и нолей? Создатели image analyzer пошли дальше: все изображение под действием этого фильтра преобразуется в сочетание специально подобранных символов.

Этот редактор вполне пригоден для несложной обработки фото и предоставляет широкие возможности для экспериментов.

photofiltre
Для характеристики этого редактора более всего подходит определение «маленький да удаленький». Размер программы невелик, а функциональность достаточна для обработки фотоизображений.

Для простейшей коррекции фотографий начинающими фотографами — в самый раз.

В программу встроен так называемый image explorer для простого и быстрого выбора изображений из заданных папок, поддерживает работу с несколькими изображениями одновременно (это удобно, когда при обработке приходится часто смотреть на оригинал). Из цветовых режимов поддерживаются только rgb и indexed color (индексированный цвет, один из методов описания изображения), но обладателям простых фотоаппаратов большего и не требуется.

Несмотря на англоязычный интерфейс [язык интерфейса может быть и русским, и турецким, и эстонским, и другим тоже - нужно только скачать крохотный "языковой" файл. Прим. softodrom.ru], photofiltre удобен в работе, основные, часто используемые эффекты доступны из основной панели инструментов, яркость, контраст, насыщенность и другие параметры регулируются здесь кнопками «+» и «-», за ними не надо лезть в меню, к тому же все регулировки отмечены пиктограммами, что не может не радовать новичка. Единственное, что не понравилось при таком подходе, — излишняя чувствительность этих кнопок: когда нужно более тонко провести коррекцию, приходится вызывать из меню различные диалоги. Для ретуши предусмотрено всего 2 инструмента — это dust reduction (аналогичен инструменту для удаления пыли и царапин в photoshop) и штамп. Что не понравилось в инструментах для ретуши да и вообще в кистях, так это невозможность визуального контроля размера кисти, это неудобно — легко можно промахнуться.

Понравилось, как photofiltre делает из цветного фото черно-белое. Никаких настроек этого процесса нет, но результат вполне приемлем. Также можно нажатием одной кнопки мыши сделать стилизацию под старое фото. Создатели программы потрудились над заготовками рамочек и текстур, накладываемых на фото. Правда, они маленького размера, но для интернета будет в самый раз — в конце концов, можно сделать свои или найти заготовки в интернете. А еще для создания рамок есть отдельный фильтр. Вообще, набор фильтров стандартен и также включает в себя «артистические» фильтры, как в photoshop. Настройка фильтров проще, чем в photoshop.

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

А вот повышение/понижение резкости, наоборот, упрощено до предела: доступны только предустановки, ручная регулировка не предусматривается — это, конечно, минус. Перед сохранением картинки в формат jpeg можно предварительно посмотреть результат и размер файла на выходе. Это особенно удобно при подготовке фотографий к web-публикации. Если в photoshop и в photoplus для этого существует отдельная функция оптимизации, то здесь все реализовано намного проще. При тестировании у программы выявилась одна особенность — иногда она отказывалась сохранять снимки в tiff-формате. После перезагрузки все вставало на свои места. В целом можно смело рекомендовать этот редактор для новичков в цифровой фотографии.

Несмотря на отдельные недостатки, главный его плюс — простота использования.

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

Многие вебмастера не представляют себе дизайна без огромного количества картинок (или без flash-заставок, что еще хуже). На дизайн без графики они просто не обращают внимания.

Это просто ужасно. Дизайнеры забывают главное правило дизайна — сделать так, чтобы пользователю было удобно. Если пользователю будет неудобно (а я думаю, что грузить страничку в полмегабайта никому не интересно), то он просто уйдет с сайта. И не вернется — ведь сайтов в интернете немало.

Интернет — это особая среда. Здесь все возможные конкуренты находятся на расстоянии одного щелчка мышкой. Поэтому неудобные сайты быстро вытесняются их более удобными конкурентами.

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

Сегодня я не претендую на понимание искусства, но я точно знаю, что мои ранние представления имели мало общего с природой искусства, а лишь опирались на чисто визуальные ощущения. Для меня искусство было зрелищем, таким же как Диснейленд или цирк. Но ведь только накатавшись на каруселях до головокружения, и объевшись сахарной ватой до тошноты, начнешь понимать реальную суть вещей. От ощущений я перешел к стилю. Человек-паук Стива Дитко (Steve Ditko). Обложки альбомов рок-, потом соул-, а потом панк-групп. Я помешался на Стиле. Я не мог отличить плохое от хорошего, зато точно знал, что круто, а что — нет.

Многие молодые Web-дизайнеры — а возраст большинства Web-дизайнеров, что скрывать, не превышает 30 лет — смотрят на свои таланты так же, как я смотрел на поп-культуру. Либо это круто, либо это мусор. Они ошибочно принимают Стиль за Дизайн, в то время как это две совершенно разные вещи. Дизайн обеспечивает общение на всех уровнях. Он говорит вам, где вы находитесь, подсказывает вам, что вы можете сделать, и помогает вам это сделать. Стиль же тавтологичен по природе; он свидетельствует об отсутствии стиля. В визуальном смысле, стиль — один из аспектов дизайна; в коммерческом смысле, стиль может служить средством передачи фирменных отличий.

Но в то же время он может выдать презрение дизайнера к самому предмету своей работы. «Так, вот тут страница выглядит скучновато, добавим парочку линий, а тут меню, что бы знали, что я могу придумать что то и получше, чем написано в задании». На этом уровне стиль выступает как специфический жаргон, принятый в тусовке, но мало понятный посетителю сайта и не имеющий отношения к назначению самого сайта. Естественно такой стилистический подход может только повредить цели создания сайта. Вот тут-то и появляются специалисты по пользовательскому интерфейсу и утверждают, что сайт потерпел неудачу из-за падкости на крутой стиль.
Дизайнеры, для которых Стиль — важнее всего, могут преуспеть лишь в случае, когда жизнь позволяет им роскошь выбирать заказы, к которым подходят их стилевые вкусы. Большинство web-дизайнеров не имеют такого счастья. Но это не останавливает их от искушения применить стилистические изыски ведущих дизайнеров к тем проектам, над которыми им приходится работать. Вот так и появляются на свет сайты электронной коммерции похожие на крутую кислотную дискотеку, информационные сайты разукрашенные порой ослепительно красивыми, но чаще всего просто сбивающими с толку и неуместными заставками.

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

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

Все дело в том, что мы живем в обществе, где властвует поверхность (и где страшатся заглянуть под поверхность). В культуре потребления, когда мы готовы выложить 200 долларов за теннисные туфли потому, что они круто выглядят, а песни Джефа Бека используются в рекламе, самыми главными товарами являются блестки и мишура.

В течение последнего года работа во Flash стала синонимом web-дизайна. Если ваша страница не поет и не пляшет, значит она не достаточно хороша — а уж не крута, так это точно. Во Flash (SWF) создаются великолепные работы, и они получают должное признание на различных конкурсах — в особенности на традиционных конкурсах высокого ранга, где «цифровые клипы» предшествуют многомиллионным телевизионным рекламным роликам. Судьи на таких конкурсах ожидают увидеть в тв-рекламе яркую идею и профессиональную работу, предъявляя к ним требования более высокие, чем к обычным коммерческим фильмам. Не удивительно, что они ожидают такого же сногсшибательного эффекта и от web-сайтов.

Громоздкие, вычурные эксперименты с DHTML и Flash будут получать призовые премии до тех пор, пока судьи будут продолжать смотреть на них в самых новейших броузерах на широких экранах своих Mac G4 или PC Pentium, подключенных к Интернету по скоростным линиям T1. И естественно, они будут получать призы, если только они их достойны по качеству дизайна и программирования. Здесь речь не о плохом дизайне. Мы говорим о самом качественном дизайне — но о дизайне лишь определенного типа.

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

Я беспокоюсь потому, что молодые дизайнеры, путающие стиль с дизайном, учатся копировать приемы и стилистические изыски своих кумиров, но забывают о приемах передачи информации, присущих Web. Спецэффект «замедленной пули» прекрасен для «Матрицы», но не для документального фильма. А так как по большей мере Web-дизайн — это информационный дизайн (или во всяком случае это так подразумевается), прививка графических стилистических наворотов к информационным сайтам не идет на пользу всему Web-у, более того — Web от этого становится еще более сложным и запутанным.

Я беспокоюсь потому, что есть дизайнеры, которые не стремятся создать свой собственный индивидуальный стиль, не говоря уже о том, чтобы создать стиль специально для конкретного проекта. Потому что люди, набирающие дизайнеров на работу, не обладают достаточным критическим подходом, и привлекают тех, чье портфолио демонстрирует владение «крутыми» эффектами, к проектам, где их эквилибристика будет выглядеть просто жалко. («Да с вашим талантом мы всех поставим на уши»). Потому что со временем традиционные дизайнеры, которые действительно понимают, что такое фирменный стиль и информационный дизайн, и которые действительно понимают разницу между Стилем и Дизайном, придут на этот рынок и вытеснят тех немногих молодых дизайнеров, которые так и не смогли понять суть ремесла, которым они занимаются.

Я беспокоюсь за Web, потому что слишком мало дизайнеров работает в той широкой нише, что расположена между сайтами-конфетками и сайтами-скелетами, то есть там, где и должен развиваться Web. И все меньше и меньше остается стимулов для web-дизайнеров оставаться в этой нише. Ведь несмотря на то, что их работа нравится web-пользователям, она не получает абсолютно никакого признания со стороны клиентов, разве что в виде оплаты за работу. («Господи, сайт загрузился так быстро и прекрасно работал даже в IE3, что установлен на старушке Dell моего папы». Вы когда-нибудь слышали, чтобы члены жюри всяческих web-конкурсов такое говорили? Я тоже нет).

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

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

Сайты создаются не просто так, а с определенной целью. Это (что встречается чаще всего) – развитие бизнеса, электронное его представительство и расширение территориального действия и круга аудитории. Соответственно, «лицо» сайта должно соответствовать задачам сайта. Иначе – эффекта не будет никакого.

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

Чтобы вы могли грамотно и профессионально создать дизайн из заказчика так или иначе придется вытянуть следующее: общую задачу сайта, примерную структуру, объем и характер информации. Естественно, должно быть в наличии название, слоган и прочие фирменные «детали». Если будущий сайт – электронное представительство реально существующей фирмы, у которой есть сложившийся и укоренившийся фирменный стиль, то дизайн надо делать в соответствии с ним.

Дизайн сайта должен гармонировать с имиджем компании-заказчика. Тут важно учесть какие товары или услуги предлагает заказчик своим клиентам; на какую аудиторию рассчитана его деятельность. Причем аудитория сайта может характеризоваться по разным признакам: по социальному статусу, возрасту, даже полу. Полезно будет составить (вместе с заказчиком) образ, «картинку» фирмы и аудитории. Подобрать смысловой и символьный ряд, и метко характеризующие фирму и целевую аудиторию прилагательные.

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

Соответственно, дизайн этого сайта (интернет-магазина) должен соответствовать образу целевой аудитории и стилю компании. То есть важно показать динамичность, свободолюбие и любовь к адреналину присущую экстремальным видам спорта. Это позволяет сконструировать приблизительно стиль будущего сайта, а дизайнеру позволяет увидеть направление, в котором ему следует развивать идею, которая должна уже созреть в его творческой голове.

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

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

Конечно, хорошо, когда информации много и она представлена в виде качественно написанного и сверстанного текста с подзаголовками, выделенными ключевыми словами и ссылками. Но этого недостаточно. Должна быть продумана четкая структура сайта. Это конечно в основном зависит от заказчика, но вы как профессионал в своем деле просто обязаны хотя бы попытаться объяснить заказчику, что длинные списки меню трудно воспринимаются пользователем. И если уж разделов требуется вынести в навигационный блок много, то следует разбить его на группы (или даже отдельные блоки) по категориям, тематике, важности. Главное – так организовать информацию, чтобы пользователь при всем желании не запутался в иерархии разделов, каталогов и подразделов и мог сразу сориентироваться, где ему искать FAQ, где прайс, а где контакты или информацию о фирме. Так же поможет указание на странице, где находится пользователь в данный момент, с последовательным указанием ссылок на вышестоящие разделы.

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

Очень плохо смотрится сайт, когда используется много разноцветных заголовков. Это нарушает единый стиль и общую «читабельность» страницы. Также и количество используемых шрифтов строго ограничено одним — двумя шрифтами. Причем вся информация на сайте должна быть оформлена одним шрифтом. Использование дополнительных шрифтов уместно для названия сайта и заголовков. Кстати, подбирая шрифт для заголовков и названия, не забудьте о том, что шрифт тоже должен гармонировать со стилем сайта. И высокохудожественные шрифты, подходящие для одной тематики, будут смотреться глупо на сайте с другой тематикой. Особенно это касается шрифтов стилизованных под готику, рукописные и шрифты в стиле граффити.

Помните, что продуманный дизайн и структура сайта – одна из самых главных задач web-дизайнера. От этого зависит, останется ли посетитель на сайте или отправится бороздить пространство Интернета. Хотите вы этого или нет, первое впечатление о компании складывается, как только человек попадает на сайт, а потому, он должен отражать сферу деятельности Вашей компании, и, несомненно, вызывать доверие. Некоторые компании пытаются «завоевать» клиента, внедряя на сайте сложные механизмы заказа или публикуя достаточно много необходимой и востребованной информации, но при этом внешний вид интернет-представитьельства имеет неказистый вид. Именно это зачастую отпугивает посетителей, которые могли бы стать потенциальными клиентами. Следовательно, подход к дизайну сайта должен быть грамотным и обеспечивать как общую презентабельность сайта, так и удобство сайта, формировать приятное впечатление о сайте, и ни в коем случае не раздражать взгляд.

Если можешь не заниматься веб-дизайном – не занимайся, это не для тебя.

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

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

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

Отличай причину от следствия, свет – от его отражения, дух закона от его буквы. Не пренебрегай стандартами.

Будь верен тому, кому служишь. Знай: дизайнер служит своему посетителю, заказчик лишь платит за это.

Милосердие – ключ к пониманию. Пусть твой сайт поймет даже самый убогий броузер.

Знание – единственная вещь, делясь которой ты становишься богаче. Делись знанием с другими.

Хороший дизайн всегда стоит дорого, но его стоимость не всегда измеряется деньгами. Помни об этом.

Проторенные тропы не для тебя. Когда есть только два способа сделать что-либо, дизайнер найдет третий.

Любой сайт делай как последний в твоей жизни. Сделай все, что собирался, сразу – нет ничего более постоянного, чем временные решения.

1. «Анимация» — одна из самых распространенных черт таких сайтов. Огромные анимированные изображения на главной странице, несколько бегущих строк перемещающиеся в 2 разные стороны и при этом резко мигающие вызывают мгновенный уход посетителя с такого сайта. Можно быть уверенным, что он не вернется.
2. «Широкие изображения» — большие по формату изображения медленно загружаются, особенно это понятно жителям стран СНГ, где быстрый доступ еще редкость.
3. «Кнопки» — начинающие веб-строители любят вешать на главную страницу до 10-20 кнопок — счетчики, топы, эмблемы каталогов, ссылки на дружественные сайты. Подумайте, может что-то из этого бесполезное увеличение обьема графики.
4. «Длинные тексты» — иногда видишь «сайт» целиком умещающийся в одном большом файле. Большая ошибка! Пользователь не должен прокручивать экран больше чем на 2,5-3 экрана.
5. «Фон» — классическая ошибка начинающих — это использование цветистых, а зачастую и разных типов фона в пределах сайта. Старайтесь создать единую атмосферу на сайте, и фон не должен выпячиваться вперед, показывая свою важность. Попробуйте использовать классику — черный текст на белом фоне.
6. «Ошибки» — всегда проверяйте свою орфографию. Ошибки зачастую прокрадываются незаметно и портят все впечатление от сайта.
7.»Выпадающие окна» — использование pop-up окон является нарушением Нетикета, самой обычной реакцией на появление таких окон при каждом клике на ссылке будет уход с такого сайта.
8. «Горизонталь» — часто при жестком дизайне (все расстояния указываются в пикселях) появляется горизонтальная полоса прокрутки, если веб-строитель имеет хороший монитор и видео-карту. Обязательно проверьте свой сайт при разрешении 800*600 при 256 цветах.
9. «Разные шрифты» — при создании сайтов применяйте правило «Не более 5-ти шрифтов на странице» — при этом жирные шрифты считаются за отдельный шрифт, тоже касается и их размера.
10. «Under Construction» — самая бесполезная надпись из всех. Если Вы переделываете раздел, лучше убрать ссылки на него. Как правило, на сайтах обьема больше среднего (>50 файлов) целесообразно перейти на использование SSI или вставок на JavaScript’ах. Это позволит Вам быстро менять общие элементы, в частности меню.

Дизайн – не искусство

Задача искусства не давать ответы, его задача, скорее, в обратном – ставить вопросы. В отличие от искусства — дизайн создается для ответов. Главные вопросы, на которые посетитель должен получить ответы:
- зачем сайт нужен;
- как сайтом пользоваться.

Главное в дизайне

Каждый сайт что-то «делает»: поисковики – ищут; магазины продают; сайты знакомств — знакомят. Дизайн – это соединительное звено между набором функций сайта и посетителем. Главная задача дизайна подать эти функции максимально просто и доступно. У посетителя не должно возникать ощущения запутанности и сложности управления. Если же на сайте «всё под рукой» – это хороший дизайн.

Дизайн и красота

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

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

Дизайн и слово

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

Дизайн и стереотипы

Не бойтесь стереотипов. Стереотип — основа, которая дает возможность оттолкнуться и шагнуть вперед. Другими словами стереотип – это кирпич, из которого можно построить что угодно.

Стереотипы бывают разные. Например, поведенческие – посетитель знает, что подчеркнутый текст – это гиперссылка, если на нее нажать — откроется некое продолжение.

Дизайн и банальность

Бойтесь банальности! Избитость – враг хорошего дизайна! Долой надерганные из фотобанков картинки! В помойку шаблонные улыбки явно «заграничных» людей! Ура!

Дизайн и люди

Запомните — дизайнер не проститутка, а заказчик не меценат.

Другими словами — дизайнер не должен исполнять все «хотелки» заказчика. Задача дизайнера вникнуть в суть задачи и решить ее, а не исполнять прихоти босса.

Что должен делать дизайн:

привлечь внимание
сделать сайт непохожим на другие
донести информацию в полном объеме
Рассмотрим подробнее вышеперечисленные способы.

Привлечение внимания.

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

Сайт должен быть непохож на другие.

Дизайн должен обеспечивать узнаваемость вашего сайта. Например закусочную Макдональтд можно узнать за несколько сот метров. То же самое можно сказать про заправки Лукойл. Очевидно, что такая узнаваемость приносит немалые прибыли этим фирмам. Так почему бы и в нашем случае не использовать этот прием.
Подчеркнуть индивидуальность своего сайта можно необычной компоновкой, оригинальным цветовым решением. Стиль сайта может быть консервативным, современным, романтическим.
Интерфейс страниц должен быть одинаковым на всех страницах сайта. Во-первых это позволит посетителя без труда находить нужную ему информацию, а во вторых страницы с одинаковой компоновкой будут восприниматься как «старые знакомые». Как известно, любой человек предпочитает знакомое незнакомому. Узнаваемость сайта в конечном итоге станет немаловажным аргументом в борьбе с конкурентами за привлечение новых потенциальных клиентов.

Эффектный дизайн доносит информацию в полном объеме

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

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

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

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

И это не требует сверхсовременного оборудования, все компоненты можно достать в обычном компьютерном магазине. Как сообщают авторы программы UDC, всего за 1000 долларов можно собрать “домашний кластер” из стандартных рабочих станций, позволяющий перебирать миллиард паролей за 40 секунд.

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

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

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

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

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

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

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

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

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

Появлению языка HyperText Markup Language и его наследников предшествовали великие работы в области языков разметки и гипертекстов

Восточная мудрость гласит: «Когда ученик готов, находится учитель». Тим Бернерс-Ли, автор HTML, оказался в состоянии стать последователем Чарльза Гольдфарба, с именем которого связано создание языка SGML — вероятно, самого мощного инструмента для разметки текстов. Но в самой этой идее ничего нового нет. Специальные символы для разметки текстов издавна использовали корректоры, элементы разметки можно обнаружить в командах roff, nroff и troff, призванных обеспечить вывод текста независимо от типа устройства печати. Несколько раньше, в 1967 году, канадским полиграфистом Уильямом Танниклифом была разработана концепция GenCod, которая впервые позволила решить важнейшую задачу, отделить содержание документа от его формата. Позже для этой цели стали использоваться языки разметки. Аналогичные работы вел американец Стенли Райс. (С появлением языка XML был сделан следующий шаг, интерпретация содержания, но это особая тема.)

язык Standard Generalized Markup Language стал первоосновой современной Паутины

язык Standard Generalized Markup Language стал первоосновой современной Паутины. Второй ее первоисточник — гипертекст

С момента появления самых первых систем работы с текстами на компьютерах все электронные документы содержали те или иные символы для управления печатью (CR, LF и др.). Однако их возможности были весьма ограниченны, методы разметки были привязаны к определенным принтерам, а с появлением новых устройств с более широкими возможностями (такими, скажем, как принтер с шариковой головкой) потребовались новые средства для управления печатью. Поэтому исследовательская группа корпорации IBM, возглавляемая Гольдфарбом, в состав которой входили также Эдвар Моше и Пэймонд Лурье, разработала — изначально для юридических приложений — язык Generalized Markup Language (аббревиатуру GML еще можно расшифровывать по именам авторов). При разработке GML были использованы достижения полиграфистов Танниклифа и Райса. Вскоре GML получил корпоративное признание, был реализован на мэйнфреймах IBM. С тех пор более 90% документов корпорации было подготовлено с использованием этой технологии.

Последующие исследования в области структуризации документов Гольдфарб вел самостоятельно; в конечном итоге они привели его к созданию языка Standard Generalized Markup Language (SGML). В период с 1978-го по 1985 год язык проходил сложный процесс стандартизации. В конечном итоге он был принят и American National Standards Institute (ANSI), и европейским агентством Computer Office of Official Publications. На следующем этапе SGML попал в европейский центр исследований физики элементарных частиц (CERN). Здесь первое средство для использования SGML разработал Андерс Берглунд, а Эрик ван Эрвиген написал одно из первых руководств по использованию SGML. В CERN была разработана и технология CERNDOC на основе SGML, которая в последующем оказалась столь успешной, что была принята американской ассоциацией издателей American Association of Publishers. Одним из активных пользователей этой технологии был Бернерс-Ли, поэтому нет ничего удивительного в том, что при разработке HTML он использовал свой опыт работы с SGML.

Впрочем, развитием SGML занимались многие. Одной из самых заметных персон был Юрий Иванович Рубинский, писатель и основатель канадской компании SoftQuad Software, которая первой в 1994 году выпустила коммерческий продукт HoTMetaL для поддержки HTML, основанный на ее предыдущем продукте Author Editor, поддерживавшем SGML.

Таким образом, SGML стал первоосновой современной Паутины. Второй ее первоисточник — гипертекст. Этот термин был предложен в 1965 году Тедом Нельсоном, который определил его следующим образом: «Массив текстов или графики, объединенных сложными связями, которые с достаточной полнотой не могут быть представлены в бумажной форме. Связи могут включать карты контента, ссылки, аннотации, комментарии и другие инструменты для указания». Гипертекст может быть полноценно реализован только в электронной форме, однако предпосылки к его возникновению обнаруживаются задолго до появления компьютеров. Впервые аннотирование использовали в Александрийской библиотеке за 300 лет до нашей эры, а из 37 томов Естественной истории Плиния (79 год) Книга первая представляла собой оглавление. С появлением книгопечатания способы доступа к информации совершенствовались; вершиной этих работ стали грандиозные, но так и не реализованные проекты бельгийского библиографа Пола Отле.

Приблизился к созданию гипертекстовых решений Ванневар Буш. В своей эпохальной статье As We May Think, опубликованной в Atlantic Monthly, представляя гипотетическую машину memex и предвосхищая Нельсона, он писал: «Появятся новые типы энциклопедий, где фрагменты будут объединены ассоциативными связями, которые могут обрабатываться средствами memex». Задуманная Бушем машина должна была хранить книги и другие документы, обеспечивать доступ к ним и таким образом расширять творческие возможности человека.

Эта статья была прочитана Дагом Энгельбартом и стала стимулом для его долговременных исследований в области систем, расширяющих интеллектуальные возможности человека. Эти работы в конечном итоге привели его к созданию лаборатории Augmentation Research Center, где была построена уникальная для своего времени система NLS (oNLine System). Она стала стимулом для последовавших за ней работ по персонализации вычислительных систем; компьютерная мышь оказалась самым знаменитым отпрыском этого проекта. Сейчас Энгельбарт возглавляет свой собственный, частный институт и работает над «открытой системой гипердокументов» — структурой, построенной на основе стандартов и открытых кодов и предназначенной для коллективной работы и управления знаниями. В качестве хранилища в ней используется «динамический репозитарий знаний» (Dynamic Knowledge Repository), а процессором служит инструмент, названный «гиперскопом». По замыслу гиперскоп должен позволять просматривать разнородные документы и устанавливать между ними связи.

В 1967 году Энди ван Дам и Тед Нельсон создали систему Hypertext Editing System (HES), которая использовалась при подготовке документации в рамках космической программы «Аполлон». Позже ван Дам разработал еще одну систему, File Retrieval and Editing System (FRESS), заимствовавшую интерактивные подходы из NLS. В этой системе впервые была реализована функция отката, без которой не мыслится ни один современный текстовый процессор.

Позже Нельсон загорелся идеей проекта, названного им Xanadu. Сказочная страна Ксанаду пригрезилась в конце XVIII века английскому поэту Сэмюэлу Колриджу под влиянием опиумного опьянения; с тех пор это название используют для обозначения несбыточной мечты. Происхождение названия Нельсон описал в книге Literary Machines («Ученые машины»), опубликованной в 1981 году. В следующей книге, Dream Machines (1988 год, «Машины мечты»), Нельсон описал три вида гипертекста, из которых нам в наибольшей степени известен первый — простые ссылки (links). Расширенные ссылки (expansion links) и параллельное представление текстов известны меньше. Проект Xanadu, начатый в 1972 году, был написан на двух самых популярных языках программирования того времени, Алголе и Фортране, и содержал целый ряд нововведений по части структур данных.

Web 2.0 (определение Тима О’Рейли) — методика проектирования систем, которые путём учета сетевых взаимодействий становятся тем лучше, чем больше людей ими пользуются.Особенностью веб 2.0. является принцип привлечения пользователей к наполнению и многократной выверке. Определение Тима О’Рейли нуждается в уточнении. Говоря «становятся лучше», имеют в виду скорее «становятся полнее», то есть речь, как правило, идёт о наполнении информацией, однако вопросы её надёжности, достоверности, объективности не рассматриваются.

Словосочетание Веб 2.0 не является научным.

Появление названия Веб 2.0 принято связывать со статьей «Tim O’Reilly — What Is Web 2.0» от 30 сентября 30 сентября 2005 года, впервые опубликованной на русском языке в журнале «Компьютерра» (№ 37 (609) и 38 (610) от 14 и 19 октября 2005 года соответственно) и затем выложенной под заголовком «Что такое Веб 2.0» веб-сайтом «Компьютерра online». В этой статье Тим О’Рейли увязал появление большого числа сайтов, объединённых некоторыми общими принципами, с общей тенденцией развития интернет-сообщества, и назвал это явление Веб 2.0, в противовес «старому» Веб 1.0. Несмотря на то, что значение этого термина до сих пор является предметом многочисленных споров, те исследователи, которые признают существование Веб 2.0, выделяют несколько основных аспектов этого явления. Первым, кто употребил словосочетание Web 2.0, стало издательство O’Reilly Media, специализирующееся на информационных технологиях. Произошло это в 2004 году. Немного позже глава издательства Тимоти О’Рейлли сформулировал часть принципов Web 2.0. За прошедшее время сфера Web 2.0 расширилась, вытесняя традиционные Web-сервисы, получившие название Web 1.0.

Web 2.0 не является технологией или каким-то особым стилем Web-дизайна. Для определения сути подходит определение Web 2.0 как комплексного подхода к организации, реализации и поддержке Web-ресурсов. Предлагаю рассмотреть наиболее известные «проявления» Web 2.0, с которыми, так или иначе, встречался каждый пользователь Интернета.

В январе 2008 года в России вступает в силу 4 часть Гражданского Кодекса, именуемая как Права на результаты интеллектуальной деятельности и средства индивидуализации. Целью нового закона будет ужесточение мер наказания за незаконное использование (плагиат и копирование) объектов интеллектуальной собственности, к которым приравниваются произведения науки, литературы и искусства, программное обеспечение, книги, статьи и прочие публицистические материалы, базы данных, элементы дизайна, фонограммы, секреты производства, товарные знаки организаций, коммерческие обозначения, «фирменные» слоганы и девизы. Так как все объекты Интернета (проекты, книги и программы) относятся к интеллектуальной собственности, владельцам веб-сайтов есть над чем задуматься. Как правильно разместить на сайте авторские материалы возможно ли использование материалов без согласия автора, и если да, то в каких случаях? Прочитав статью, вы получите ответы на эти, а также на многие другие вопросы, так или иначе связанные с авторским правом и интеллектуальной собственностью.

Кого можно считать автором?

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

Какими правами обладает автор?

Право на публикацию произведений под своим полным именем или псевдонимом.

Право на внесение изменений, распространение, а также передачу прав собственности на материалы.

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

Владелец интеллектуальной собственности. Кто он?

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

Является ли правомерным использование объектов интеллектуальной собственности без согласия автора?

Согласно Федеральному закону №72-Ф3 от 20 июля 2004 года допускается публикация авторских произведений без согласия самого автора и выплаты вознаграждения, но с условием обязательного указания имени автора, оригинального названия и первоисточника.

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

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

Для чего нужен знак ©?

Знак © или (С) выступает в роли своеобразной голограммы, гарантирующей принадлежность объекта к интеллектуальной собственности. Был установлен в 1952 году решением Всемирной Конвенции об авторском праве.

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

Один из наиболее часто задаваемых вопросов: «я хочу заниматься веб дизайном. С чего мне начать?»

1. Знайте свои сильные и слабые стороны

Знайте свои слабые стороны — это поможет сэкономить время и энергию на занятиях которые лучше оставить кому-нибудь другому.

Знайте в чем вы лучший — это подскажет чем вам заниматься.

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

Разделите лист бумаги пополам. Левую часть озаглавьте «Сильные стороны», а правую «Слабые стороны». Будьте максимально честны сами с собой. Для начала вы можете рассмотреть следующие области:

• Дизайн
• Верстка (X)HTML/CSS
• Копирайтинг
• Программирование PHP/JavaScript
• Брендинг
• Разработка ТЗ
• Разработка баз данных
• Коммуникабельность
• Разрешение конфликтов
• Лидерство
• Бухгалтерские и юридические знания

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

2. Определите свою рыночную нишу

Ваша главная рыночная ниша:

• Вам нужно как можно лучше понимать своих клиентов. Это поможет вам представлять, что они хотят увидеть и восхищать их своей работой.
• Помните, что вы оказываете услуги людям, а не компаниям. Даже если заказ делает компания, всегда есть человек, который принимает решение нанять именно вас.
• Постарайтесь представить вашего потенциального клиента, который ищет дизайнера, проникните в его сознание и представьте:
• Размер его организации
• Цели, которые сейчас стоят перед его бизнесом.
• Цену, которую он готов заплатить.
• Его предпочтения.
• Слова, которые заставят его выбрать именно вас.

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

3. Определите вашу специализацию

Определите какие продукты или услуги вы будете предлагать исходя из своих сильных и слабых сторон. Постарайтесь представить работы в которых нуждается ваш рынок и которые вы будете выполнять с удовольствием.

• Как вы хотите работать?
• Вы хотите делать большие проекты для крупных заказчиков, или небольшие для местных?
• Как сильно вы готовы рисковать?
• Вы злитесь, когда не можете справиться с задачей, или вы готовы ответить на вызов?
• Как много денег вы хотите заработать и как быстро это сделать?
• Если вы разрабатываете небольшие сайты по низким ценам для мелких клиентов, вы будете мало привлекательны для крупных заказчиков, действительно и обратное. Заранее определите свой рынок, это позволит вам добиться на нем лучших результатов.
• Какой тип оплаты вы предпочитаете, сдельную или почасовую?
• Если вы предпочитаете гарантированную оплату по дням или часам, возможно, вам стоит поискать вакансию на удаленную работу. Конечно, вы можете брать оплату за выполненную работу (сайт полностью, или макет, если не занимаетесь версткой).
• Вы хотите отвечать за создание сайта в полном объеме, или только за часть процесса?
• Чтобы быть ведущим разработчиком вы должны уметь вести переговоры с клиентами, хладнокровно реагировать на их проблемы и пожелания.
• Возможна ситуация, когда вы не можете самостоятельно выполнить требования клиента, в таком случае вам нужно будет обратиться к другим разработчикам чтобы решить эту проблему.
• Вы хотите самостоятельно договариваться с клиентами?
• Если вы предпочитаете дизайн или кодинг менеджменту, возможно вам стоит найти партнера который будет отвечать за связи с клиентами.
• Что нужно вашим заказчикам?
• Проект «под ключ» или работа на договорной основе?
• Может быть, они хотят начать с недорогого проекта и постепенно развивать его или хотят получить законченное решение?
• Хостинг, домен и продвижение проекта входят в вашу работу или этим будет заниматься заказчик?
• Будет ли заказчик самостоятельно управлять содержанием сайта, или вы будете делать это для него.
• Насколько оперативная поддержка нужна заказчику.

Подытожьте все вышесказанное

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

4. Продвигайте себя

Не очень хорошая идея пытаться предоставлять услуги «все в одном», особенно если у вас небольшая веб студия или вы работаете в одиночку

Почему? Потому что множество разработчиков пытаются делать именно так. Чтобы преуспеть, вы должны выделяться любым способом — вы должны быть неповторимы.

Рекламируйте свои сильные стороны и постарайтесь сделать свои слабости своими преимуществами.

Если хотите, сосредоточьтесь на низкой цене.

Если вы новичок, клиенты должны видеть, что вы стараетесь как можете и получать то, что они хотят на 100%.

Если вы не дизайнер, продвигайтесь как специалист в юзабилити или SEO (Search engine optimization).

Если вы не сильны в программировании, сосредоточьтесь на дизайне и брендинге.

5. Правильно оценивайте свои услуги

Очень важно чтобы ваша цена соответствовала качеству услуг и поддержки.

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

Сколько стоит разработка сайта

На этот вопрос очень трудно ответить. Цены на дизайн и программирование могут очень сильно варьироваться в зависимости от вашего опыта, местности в которой вы работаете, бюджета клиента, даже времени года. Ориентировочно, цена может быть в пределах от $1200 до $9000 за сайт. Очевидно, что более дорогие сайты подразумевают значительную работу в области программирования. Конечно, некоторые некоммерческие проекты могут быть выполнены бесплатно. Хороший способ определиться с ценой, посмотреть какие услуги предоставляют другие компании в вашем секторе и по какой цене. Но не следуйте безоглядно за ценами в других компаниях, ведь ваши услуги могут отличаться. Если вы правильно оцениваете свои преимущества и недостатки, вы сможете правильно регулировать цены на ваши услуги.

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

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

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

Если вы уверены в ценности ваших услуг, вы не будете втянуты в обсуждение цены. Чем лучше вы сможете объяснить клиенту, что вы делаете для него, тем более значимыми будут казаться ваши услуги.

6. Создавайте сеть поддержки

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

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

У меня есть сеть фрилансеров, которым я доверяю и всегда могу связаться с ними для выполнения некоторых видов работ, таких как:

Найдите себе наставника

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

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

Очень важно найти кого-то, у кого есть нужные знания, но кто не является вашим прямым конкурентом.

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

Если вы не спросите, вам ничего не ответят.

7. Создайте свой сайт

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

Что можно разместить на сайте?

Отзывы заказчиков

Я думаю, иногда они на вес золота. Каждый раз, когда вы сделали работу попросите клиента написать, что он думает о ней, так вы будете знать, на что следует обратить внимание в следующем проекте.

Создайте хорошее портфолио

Не бойтесь показывать ваше портфолио. Если кто-то захочет украсть ваши идеи, он все равно украдет их, ведь все они представлены в Интернете.

Убытки от того, что вы не показываете вашу лучшую работу могут быть значительно больше чем затраты на защиту интеллектуальной собственности.

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

Делитесь своими знаниями

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

Пишите все, что вы знаете о дизайне, программировании или маркетинге, пишите о современных тенденциях, ловушках, юзабилити, программном обеспечении, хостинге, CSS, AdWords, стандартах, опыте, поисковых машинах, о том, что вам нравится и не нравится…

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

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

Какие у меня есть доказательства вышесказанного?

Сайт мой единственный маркетинговый канал — и все свои заказы я получаю через него.

8. Постоянно изучайте новые технологии

Интернет технологии никогда не стоят на месте. Стандарты постоянно движутся вперед и вы должны двигаться вместе с ними. Это значит, что каждый дизайнер или программист должен постоянно учиться.

Обычно обучение это часть вашей работы: вы изучаете новое в программировании или дизайне, чтобы решить конкретные проблемы, возникающие в процессе работы.

Соберите свой набор ссылок на сайты, где обсуждаются вопросы CSS, JavaScript, дизайна и т. д. и посещайте их хотя бы раз в неделю.

Очень часто мне задают вопрос, полезно ли пройти курс веб дизайна?

Обычно, мой ответ «Нет», потому что обычно на таких курсах даются только базовые знания, а также, потому что вы должны научиться получать знания самостоятельно, иначе вам не преуспеть в этой области.

Конечно, если вы совсем не знаете с чего начать, нет ничего страшного в том, что вы пройдете онлайновый или реальный курс по вашей специальности.

9. Ваши клиенты должны вами восхищаться

Я не могу выразить насколько это важно. Стремитесь к тому, чтобы каждый клиент был в восторге от вашей работы. Клиенты не просто должны быть удовлетворены, они должны быть в восторге. Если вы хотите получать как можно больше отдачи от вашей работы, вы должны стараться для клиентов.

Заказчики, которые очень довольны вашей работой, дают вам много преимуществ:

• Хорошие отзывы, чтобы привлекать других клиентов.
• Повторные заказы.
• Они расскажут о вас своим знакомым.
• Полезная обратная связь.
• Ссылки.

Не старайтесь сделать работу «по быстрому» — спешка, последнее, что вам нужно, используйте все доступное вам время, чтобы работа была основательной и безупречной.

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

10. Просто сделайте это!

Вперед, чего вы ждете?

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

Что такое цвет

Что же такое цвет? Мы смотрим на предметы и, характеризуя их, говорим примерно следующее: он большой, мягкий, светло-голубого цвета. При описании чего-либо в большинстве случаев упоминается цвет, так как он несет огромное количество информации. На самом деле тело не имеет определенного цвета.
Если говорить о дневном освещении, то это белый свет. Попадая на предмет, он частично поглощается, а частично отражается, так вот именно отраженный спектр и видит человек.
Видимыми являются волны, лежащие в диапазоне от 760 до 380 миллимикрон, хотя некоторые животные видят и в областях ультрафиолетовых и ультракрасных волн. Зависимость цвета от длины волны представлена в таблице 1.
Первый, кто сумел разложить свет на различные составляющие, был Ньютон. Он заметил, что при пропускании света через призму он раскладывается на лучи разных цветов, после чего снова собирается воедино.
Основным заблуждением человека является то, что он видит то, что привык видеть, а именно если смотреть на хорошо знакомый красно-белый объект, освященный лишь зеленым светом, то мы все равно увидим два цвета — красный и белый, — хотя в мозг через глаз поступает иной сигнал, который игнорируется, точнее, преобразовывается в соответствии с тем, что он знает, а не с тем, что видит.
Дело в том, что зеленый свет не содержит красных лучей, следовательно, и отразить их предмет не может, а поэтому он поглощает весь спектр лучей, и оттого приобретает темный, близкий к черному, цвет. Что же касается белого, то он полностью отражает все падающие на него лучи и потому будет выглядеть зеленым.

Цветовой круг

Наука о цвете — это довольно сложная и широкомасштабная наука, поэтому в ней время от времени создаются различные цветовые модели, применяемые в той либо иной области. Одной из таких моделей и является цветовой круг, о котором уже неоднократно упоминалось в статьях, опубликованных ранее, и принцип которого заложен в таких операциях, как Invert — инвертировать (все цвета заменяются на те, которые находятся напротив в цветовом круге), Hue/Saturation — Цвет/Насыщенность (вращение происходит все по тому же кругу) и другие.
Многим известно о том, что существует 3 первичных цвета, которые невозможно получить и которые образуют все остальные. Основные цвета — это желтый, красный и синий. При смешивании желтого с красным получается оранжевый, синего с желтым — зеленый, а красного с синим — фиолетовый. Таким образом, можно составить круг, который будет содержать все цвета. Он представлен на рис. 1 и называется большим кругом Освальда.
Наряду с кругом Освальда есть еще и круг Гете, в котором основные цвета расположены в углах равностороннего треугольника, а дополнительные — в углах перевернутого треугольника. Схема такого круга представлена на рис. 2.
Друг напротив друга расположены контрастные цвета.

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

Цветовая модель RGB
Это одна из наиболее распространенных и часто используемых моделей. Она применяется в приборах, излучающих свет, таких, например, как мониторы, прожекторы, фильтры и другие подобные устройства.
Данная цветовая модель базируется на трех основных цветах: Red — красном, Green — зеленом и Blue — синем. Каждая из вышеперечисленных составляющих может варьироваться в пределах от 0 до 255, образовывая разные цвета и обеспечивая, таким образом, доступ ко всем 16 миллионам. При работе с графическим редактором Adobe PhotoShop можно выбирать цвет, полагаясь не только на тот, что мы видим, но при необходимости указывать и цифровое значение, тем самым иногда, особенно при цветокоррекции, контролируя процесс работы.
Данная цветовая модель считается аддитивной, то есть при увеличении яркости отдельных составляющих будет увеличиваться и яркость результирующего цвета: если смешать все три цвета с максимальной интенсивностью, то результатом будет белый цвет; напротив, при отсутствии всех цветов получается черный.
При наложении отдельных каналов результат получается не совсем такой, как если бы смешивались краски, поэтому для того, чтобы внести ясность, остановимся на каждом из сочетаний подробнее.
При смешении красного и зеленого результатом будет желтый. Зеленого и синего — голубой, что ближе результату, получаемому на палитре. Синего и красного — фиолетовый, причем при изменении пропорций смешиваемых цветов можно получать как розовые, так и пурпурные оттенки.
Несомненными достоинствами данного режима является то, что он позволяет работать со всеми 16 миллионами цветов, а недостаток состоит в том, что при выводе изображения на печать часть из этих цветов теряется, в основном самые яркие и насыщенные, также возникает проблема с синими цветами.

Цветовая модель HSB
Здесь заглавные буквы не соответствуют никаким цветам, а символизируют цвет, насыщенность и яркость. Все цвета располагаются по кругу, и каждому соответствует свой градус, то есть всего насчитывается 360 вариантов (красный — 0, желтый — 60, зеленый — 120 градусов и так далее).
Насыщенность определяет, насколько ярко выраженным будет выбранный цвет. 0 — серый, 100 — самый яркий и чистый из возможных вариантов.
Параметр яркости соответствует общепризнанному, то есть 0 — это черный цвет.
Такая цветовая модель намного беднее рассмотренной ранее RGB, так как позволяет работать всего лишь с 3 миллионами цветов.

Цветовая модель CMYK
Это еще одна из наиболее часто используемых цветовых моделей, нашедших широкое применение. Она, в отличие от аддитивной RGB, является субтрактивной моделью. Работа ее основана на том, как раскладывается на составляющие и видится нами свет и цвет. Как уже говорилось ранее, видимым является отраженный спектр, остальные же составляющие поглощаются. Аналогично образовываются цвета на бумаге при рисовании красками. То есть, проведя красную полосу, мы сделаем синюю и зеленую составляющие поглощенными. Если поверху наложить зеленую краску, то результат будет грязным (из-за того, что цвета не совершенны, то есть несколько отличаются от эталонных красного и зеленого) и очень близким к черному.
Основные цвета в субтрактивной модели отличаются от цветов аддитивной. Cyan — голубой, Magenta — пурпурный, Yellow — желтый. Так как при смешении всех вышеперечисленных цветов идеального черного не получится, то вводится еще один дополнительный цвет — черный, который позволяет добиваться большей глубины и используется при печати прочих черных (как, например, обычный текст) объектов.
Цвета в рассматриваемой цветовой модели были выбраны такими не случайно, а из-за того, что голубой поглощает лишь красный, пурпурный — зеленый, желтый — синий.
В отличие от аддитивной модели, где отсутствие цветовых составляющих образует черный цвет, в субтрактивной все наоборот: если нет отдельных компонентов, то цвет белый, если они все присутствуют, то образуется грязно-коричневый, который делается более темным при добавлении черной краски, которая используется для затемнения и других получаемых цветов. При смешивании отдельных цветовых составляющих можно получить следующие результаты:
Голубой + Пурпурный = Синий с оттенком фиолетового, который можно усилить, изменив пропорции смешиваемых цветов.
Пурпурный + Желтый = Красный. В зависимости от соотношения входящих в него составляющих он может быть преобразован в оранжевый или розовый.
Желтый + Голубой = Зеленый, который может быть преобразован при использовании тех же первичных цветов как в салатовый, так и в изумрудный.
Несмотря на большие различия в цветовых моделях RGB и CMYK, следует освоить обе, так как каждая применяется в своей области, и если вы занимаетесь графикой, то столкновения с ними вам не избежать. Следует помнить, что если вы готовите изображение к печати, то следует все-таки работать с CMYK, потому что в противном случае то, что вы увидите на мониторе, и то, что получите на бумаге, будет отличаться настолько сильно, что вся работа может пойти насмарку.

Начнем с того, что ваша дизайн-студия, в первую очередь, должна иметь профессионального дизайнера. Здесь важно отметить, что дизайнер и художник — две разных ипостаси. Дизайнер, в отличие от художника использует в своей работе, а нередко и кладёт в её основу не им созданные художественные ценности. Норма в профессиональном дизайне сегодня — использование покупных фотографий и заказной графики, не говоря уже о шрифтах. Дизайнер должен владеть передовыми профессиональными графическими пакетами для обработки и создания растровой, векторной графики, а нередко и специализированным программным обеспечением для рендеринга трёхмерных объектов. Т.е. для дизайнера ярко выражен его синтез с компьютерными технологиями.

Web-дизайн и другие схожие с ним направления всё ещё не достаточно хорошо изучены и находятся в стадии развития. Мне часто задают один и тот же вопрос: «Как стать веб-дизайнером?». Ответ не прост. Существует множество различных способов стать профессиональным веб-дизайнером, и каждый столь же индивидуален, сколь непохожи люди, составляющие сообщество веб-дизайна.

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

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

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

Каждый год Джейкоб Нильсен (Jacob Nielsen), признанный специалист в области Web-технологий, проводит конференцию User Experience, на которой представители интернет-индустрии обсуждают основные проблемы развития Всемирной Паутины.

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

Прежде всего Нильсен обратил внимание читателей своей рассылки Alertbox на исследование компаний Yahoo! и eBay, посвященное самым неприемлемым тенденциям в области Web-дизайна. Фундаментом финансовой состоятельности как Yahoo!, так и eBay являются те миллионы пользователей, которые ежедневно посещают их ресурсы. В случае Yahoo! основной доход получается за счет размещаемой на страницах рекламы, для eBay же важно упростить процесс продажи и покупки товаров на своей площадке.

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

Тотальная ненависть пользователей к всплывающим окнам неудивительна. Так, к сентябрю 2004 г. 69% из них на своих домашних ПК установили один из многочисленных блокираторов. Подобная функция сегодня внедрена и в панели таких популярных поисковиков, как Google, Yahoo! и т. д.

Отсутствие теплых чувств у пользователей к самостоятельно открывающимся рекламным окнам оказало влияние и на разработчиков — браузер Firefox от неприбыльного фонда Mozilla Foundation после выпуска версии 1.0 (в которой есть возможность блокировки) имеет постоянно пополняющуюся армию поклонников, и на момент написания этой статьи число его загрузок превысило 10 млн!

Браузер содержит встроенную защиту от всплывающих окон, а расширение SingleWindow, доступное для загрузки на сайте Firefox, позволяет освободиться и от ненужных окон, открываемых вследствие щелчка мышью. По данным компании OneStat, которая отслеживает пользовательские предпочтения в Интернете, к ноябрю этого года доля сторонников Web-браузеров семейства Mozilla превысила 7%. Лидер — Microsoft Internet Explorer — по-прежнему занимает весьма значительный сегмент рынка — 89%, однако миграция в направлении нового браузера налицо. Кроме блокиратора всплывающих окон, Mozilla Firefox содержит расширение AdBlock, с помощью которого можно заблокировать загрузку изображений с определенного сервера (чаще всего в черный список попадают серверы рекламных агентств).

Влияние новых браузеров на рынок интернет-рекламы осенью 2004 г. попыталась оценить немецкая компания AdTech AG, которая в октябре — ноябре этого года на основе Web-браузеров отслеживала рекламные предпочтения. Оказалось, те, кто выбирает Firefox, реагируют на рекламные блоки значительно реже, чем те, кто рассчитывает на Internet Explorer. Средний процент щелчков по рекламным баннерам составил 0,11% для пользователей Firefox и 0,5% — для обладателей Internet Explorer.

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

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

Поскольку баннер является графическим элементом в формате GIF для размещения его на страницах сайта создается специальный код. В результате, нажав на приглянувшийся баннер, пользователь переходит на сайт рекламодателя.
Главный параметром, на который ориентируются при создании баннера – это CTR (показатель эффективности баннера), вычисляемый по формуле: отношение числа пользователей, перешедших по нему, к общему числу посетителей видевших страницу с данным баннером.

CTR зависит от нескольких факторов:
Во-первых – расположение баннера. Понятно, что у баннера, размещенного на видном месте, да еще и на главной странице сайта больше шансов быть замеченным посетителем. Соответственно «кликов» (переходов) по нему будет гораздо больше, чем, если бы тот же баннер затерялся бы где-нибудь в конце страницы. Также стоит обращать внимание на содержание веб-страниц, на которых предположительно будет находиться баннер. Если страница переполнена различными ссылками и рекламой, вероятность привлечения внимания именно к вашему баннеру заметно снижается. Поэтому для размещения баннеров лучше выбирать страницы, содержащие исключительно текстовую информацию. Наиболее выигрышными считается размещение баннера вверху страницы.
Во-вторых, чтобы добиться наибольшей эффективности, баннеры должны размещаться на ресурсах, близких по тематике рекламодателю. Простой пример: баннер, предлагающий чудо-крем от морщин, вряд ли может рассчитывать на внимание посетителей, если он находится на сайте, посвященном проблемам ипотечного кредитования.
В-третьих, баннер, содержащий качественный и релевантный текст, способен привести на сайт рекламодателя потенциальных потребителей его товаров или услуг. Другими словами, если человек нажимает на баннер, в первую очередь, обращая внимания на его содержание, значит, он действительно заинтересован в той информации или товарах, которые ему обещают в рекламе.
В-четвертых, дизайн баннера. Напрямую зависит от вида рекламируемых услуг. Если баннер принадлежит развлекательному порталу, он выполняется в ярких, агрессивных цветах. Целью такого дизайна, прежде всего, является привлечение как можно большего числа пользователей. Солидные компании, при изготовлении своих баннеров, большое значение уделяют текстовой составляющей, расположенной на нейтральном фоне. Кроме того, на баннере могут размещаться логотип и прочие атрибуты индивидуального стиля компании.

Форматы баннеров
Существует пять стандартных размеров (форматов) баннеров:
480х60 – Самый большой по размеру баннер. Чтобы не было проблем при его размещении на сайте и не пришлось в срочном порядке перекраивать структуру ресурса, еще на этапе верстки необходимо предусмотреть место для такого рода баннеров.
400х40 – Мини-баннер, обладающей значительной длиной. Как и в случае с предыдущим форматом, для баннера 400х40 требуется заранее предусмотреть площадь размещения.
234х60 – Для экономии места на сайте, веб-мастера располагают подобные баннеры парами.
120х60 — «Рекламный» кирпич». Размещается в вертикально расположенных элементах веб-страницы.
88х31 – Баннер – «кнопка», названный так из-за небольших размеров. Является самым распространенным в Интернете. Помещается на любом сайте.

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

Итак, какие элементы должны присутствовать на баннере?

• Краткое содержание рекламируемого сайта.
• URL-сайта, контактные данные компании, логотип.
• Запоминающийся текст или слоганы.

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

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

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

Дизайн – не искусство

Задача искусства не давать ответы, его задача, скорее, в обратном – ставить вопросы. В отличие от искусства — дизайн создается для ответов. Главные вопросы, на которые посетитель должен получить ответы:
- зачем сайт нужен;
- как сайтом пользоваться.

Очень важный вопрос — с чего начать создание сайта? У Вас есть огромное желание и впереди наполеоновские планы, но есть небольшое затруднение — Вы не знаете с какого конца к этому подступиться. Тем более, если делаете это в первый раз. Возможно, у Вас уже есть опыт создания простенькой домашней странички, но достаточно большой и законченный сайт требует к себе иного подхода.

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

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

Структурирование информации

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

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

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

1. Новости компании
2. Информация о фирме
3. Услуги фирмы
4. Каталог товаров
5. Контактная информация

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

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

Для того, чтобы этого избежать и используется иерархическое построение меню. Правильное структурирование информации позволяет нам выделить основные разделы сайта, а все второстепенные разделы будут доступны после выбора одного из основных. Описанное замечание относится также и к меню 2-го уровня — при большом количестве пунктов, имеет смысл ввести меню 3-го уровня. Но не более! Будет уже слишком.

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

Подготовка текстов

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

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

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

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

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

Структура готова, тексты написаны — вот теперь, пожалуй, и можно приступать к созданию набросков дизайна. На этой стадии очень важно выбрать инструмент, с которым Вы будете работать. Первоначальный вариант можно набросать и карандашом на листке бумаге, но его придется переносить в электронный вид. Многие web-дизайнеры предпочитают использовать для целей макетирования растровые или векторные редакторы, которые позволяют свободно манипулировать объектами на будущей страничке. Результатом этого этапа должна быть готовый эскиз.

История возникновения

Кодировка представляет собой таблицу символов, где каждой букве алфавита (а также цифрам и специальным знакам) присвоен свой уникальный номер — код символа.

Стандартизирована только половина таблицы, т.н. ASCII-код — первые 128 символов, которые включают в себя буквы латинского алфавита. И с ними никогда не бывает проблем. Вторая же половина таблицы (а всего в ней 256 символов — по количеству состояний, который может принять один байт) отдана под национальные символы, и в каждой стране эта часть различна. Но только в России умудрились придумать целых 5 различных кодировок. Термин «различные» обозначает то, что одному и тому же символу соответствует разный цифровой код. Т.е. если мы неправильно определим кодировку текста, то нашему вниманию предстанет абсолютно нечитаемый текст.

Кодировки появились исторически. Первая широко используемая российская кодировка называлась KOI-8. Ее придумали, когда адаптировали к русскому языку систему UNIX. Это было еще в семидесятых — до появления персоналок. И до сих пор в UNIX это считается основной кодировкой.

Потом появились первые персональные компьютеры, и началось победное шествие DOS. Вместо того чтобы воспользоваться уже придуманной кодировкой, Microsoft решила сделать свою, ни с чем не совместимую. Так появилась DOS-кодировка (или 866 кодовая страница). В ней, кстати, были введены спецсимволы для рисования рамок, что широко использовалось в программах написанных под DOS. Например, в том же Norton Commander-е.

Параллельно с IBM-совместимыми развивались и Macintosh-компьютеры. Несмотря на то, что их доля в России очень мала, тем не менее, потребность в русификации существовала и, разумеется, была придумана еще одна кодировка — MAC.

Время шло, и 1990 году Microsoft явила на свет первую успешную версию Windows 3.0-3.11. А вместе с ней и поддержку национальных языков. И снова был проделан такой же фокус, как и с DOS. По непонятным причинам они не поддержали ни одну, из уже существовавших ранее (как это сделала OS/2, принявшая за стандарт DOS-кодировку), а предложили новую Win-кодировку (или кодовая страница 1251). Де-факто, она стала самой распространенной в России.

И, наконец, пятый вариант кодировки связан уже не с конкретной фирмой, а с попытками стандартизации кодировок на уровне всей планеты. Занималась этим ISO — международная организация по стандартам. И, догадайтесь, что они сделали с русским языком? Вместо того, чтобы принять за «стандартную русскую» какую-нибудь из вышеописанных, они придумали еще одну (!) и назвали ее длинным неудобоваримым сочетанием ISO-8859-5. Разумеется, она тоже оказалась ни с чем не совместимой. И в настоящий момент эта кодировка практически нигде не применяется. Кажется, ее используют только в базе данных Oracle. По крайней мере, я ни разу не видел текст в этой кодировке. Тем не менее, ее поддержка присутствует во всех броузерах.

Сейчас идет работа над созданием новой универсальной кодировки (UNICODE), в которой предполагается в одну кодовую таблицу запихнуть все языки мира. Тогда точно проблем не будет. Для этого на каждый символ отвели 2 байта. Таким образом, максимальное количество знаков в таблице расширилось до 65535. Но до момента, когда все перейдут на UNICODE, остается еще слишком много времени.

Web-дизайн и кодировки

А теперь о том, как все эти кодировки связаны с web-дизайном. Проблема заключается как в web-серверах, так и в броузерах. Обе составляющие должны общаться на одном языке и в одной кодировке, и только в этом случае броузер будет понимать то, что ему посылает сервер.

Со стороны сервера мы должны установить систему, которая умеет предварительно посылать сообщение о том, в какой кодировке будет прислана страница. А броузер это сообщение должен принять и, соответственно, настроиться на нужное отображение. Если все сделано корректно, то проблем не возникает. Но действительность вносит свои коррективы и неправильная настройка web-сервера может привести к тому, что, послав сообщение о том, что сейчас будет страничка в кодировке win-1251, сервер присылает ее в KOI-8. Разумеется, броузер путается, ведь он не в состоянии самостоятельно определить кодировку страницы. Он всего лишь пользуется указаниями сервера и, соответственно, показывает страничку неправильно.

Имеется способ указать кодировку странички не на сервере, а непосредственно в HTML-коде. Для этого используется специальная версия META-тега с параметром charset, задающим нужный язык. Например, для странички написанной в кодировке Win1251, соответствующий код будет выглядеть так:

<meta http-equiv="content-type" content="text/html;
charset=Windows-1251">

Но, к сожалению, с этим тегом связано несколько проблем. В России очень распространен способ, при котором web-сервер автоматически определяет, в какой кодировке приходит запрос от клиента и отдает страничку web-броузеру уже перекодированной. Вот тут нас и поджидает небольшой подводный камень. META-тег может сыграть плохую шутку. Дело в том, что указания на страничке имеют приоритет по сравнению с командами, присылаемыми web-сервером и правильно перекодировав страничку, сервер, тем не менее, не может изменить содержимое тега META. Происходит несовпадение реальной кодировки, в которой пришла кодировка, и указаниями в теге META. Такую страничку нельзя будет нормально просмотреть и перекодировать средствами броузера. Выбор кодировки вручную в данном случае не поможет, т.к. тег META имеет приоритет и над установками броузера. Единственный способ сделать это — сохранить страничку и удалить злосчастный тег.

В связи со всеми этими проблемами в РУНЕТ-е не рекомендуется применять данный тег вообще. В таком случае просмотр будет осуществляться в той кодировке, на которую настроен броузер, если сервер не пришлет уведомление о кодировке документа. В случае несовпадения ее можно достаточно легко переключить. Кроме того, если по умолчанию выставлять кодировку Win-1251, то у 95% Ваших посетителей страничка сразу же будет показана правильно.

Проблемы с таблицами стилей

В последнее время в связи с широким распространением DHTML, CSS и 4-х версий броузеров возникла новая проблема, связанная с кодировками. И причиной ее появления служит использование каскадных таблиц стилей (CSS).

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

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

Каковы же эти ограничения?

Первое и основное заключается в том, чтобы использовать только стандартные шрифты, поставляемые с Windows и гарантированно находящиеся на машине клиента. А этих шрифтов, как известно всего три. Вот их список: «Arial», «Times New Roman», «Courier».

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

<style type="text/css">
<!--
.serif { font-family : "Times New Roman", "Geneva", "serif"; }
.sanserif { font-family : "Arial", "Helvetica", "sans-serif"; }
.mono { font-family : "Courier", "monospace"; }
-->
</style>

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

Почему же так происходит, что счетчик на Вашей странице почти не увеличивается? Все просто — о Вас пока никто ничего не знает. Пора заняться раскруткой сайта — увеличением ежедневного количества посетителей. Есть несколько способов достижения этого:

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

Сегодня мы разберемся с самым простым, но эффективным способом раскрутки — регистрацией в поисковых системах и каталогах. Как это сделать правильно? И вообще, что понимать под «правильной» регистрацией? По-моему мнению, «правильно» обозначает, что в ответ на запрос по теме Вашего сайта, вы получаете список ссылок, в которых Ваш сайт находится одним из первых.

Определимся с терминологией. Есть поисковые системы, а есть интернет-каталоги. Начнем с поисковых систем. По сути, это очень большая база данных, которая хранит в себе полные тексты всех зарегистрированных сайтов. Необходимым компонентом поисковых систем являются роботы. Робот это небольшая программа, которая ходит по ссылкам на сайте и индексирует все встреченные по пути странички. Для регистрации, мы должны сообщить роботу адрес нашего сайта. Поисковые системы достаточно загружены работой, ведь ежедневно приходят десятки тысяч запросов. По этой причине, после того как Вы послали запрос на регистрацию, пройдет порядка 1-2 недель, прежде чем сайт реально проиндексируется поисковым роботом.

Интернет-каталоги — списки ресурсов, распределенные по категориям. Бывают специализированные и общие. Основное отличие их от поисковых систем заключается в том, что все запросы просматриваются людьми, которые оценивают ценность сайта, выбирают для него категорию в каталоге и корректируют предоставленное Вами описание.

Перед тем, как регистрировать сайт, нужно немного подготовиться — впоследствии это сэкономит нам много времени. И начать нужно с поиска ключевых слов и составления вразумительного описания сайта.

Ключевые слова

К подбору ключевых слов стоит подойти серьезно. Правильный их выбор позволяет сильно повысить позицию сайта при запросах.

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

Нужно подобрать порядка 20-30 ключевых слов. А потом проверить их, набрав в поисковой системе. Список, каких сайтов возвращается? Связаны ли они с тематикой Вашего сайта? Если да, то хорошо — значит, Вы уже более-менее подобрали основные слова. В качестве примера, посмотрите какие ключевые слова используются в найденных страничек.

Описание сайта

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

При составлении описания не нужно указывать название сайта, оно и так будет проиндексировано. Также постарайтесь избегать общих фраз типа: «Здесь Вам будет интересно», «На этом сайте есть все», «Заходи, не пожалеешь!» и т.п. Опишите именно содержание сайта, посетитель сам разберется, нужно ли ему идти на Вашу страничку. Ведь Вам нужен не просто посетитель, а именно Ваш посетитель! Какая радость с того, что страничку покинут, едва взглянув на нее и убедившись, что она не соответствует описанию?

Подготовка к регистрации

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

Название сайта:
URL сайта:
Описание сайта: Дизайн и изготовление web-сайтов, их поддержка и раскрутка в сети. Статьи и ссылки по web-дизайну, полезные рекомендации.
Ключевые слова: дизайн, design, web-design, веб-дизайн, web-мастеринг, web, веб, www, поддержка, раскрутка, реклама, баннер, баннерик, кнопка, оптимизация, статьи по веб-дизайну, ссылки по web-дизайну, gif, jpg, HTML, JavaScript, CGI, SSI, ASP, вишня, cherry.
Контактное лицо:
E-mail регистрации:

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

Благодаря такой схеме, мы теперь сможем заполнять поля в формах, используя обычный способ «копирования и вставки» (Cut&Paste), что сильно ускоряет процесс.

Осталось найти список поисковых систем и приступить к регистрации. Для удобства, я уже давно создал такой список. Каждая ссылка в нем открывается в новом окне, что позволяет зарегистрировать сайт «не сходя с места». Если у Вас русскоязычный ресурс, то достаточно зарегистрироваться только в первой части списка.

Давайте вспомним. Что лежит в основе Web-страничек? Верно, язык HTML, и определятся он как текст в формате ASCII со вставкой специальных разметочных кодов (или тэгов). И когда броузер отображает страничку, то он находит эти коды и выполняет соответствующие им действия (например, встречая тэг <b> начинает вывод последующего текста полужирным шрифтом, а встречая </b> — прекращает это делать). Полный набор таких тэгов называется спецификацией и поддерживается WWW-консорциумом, в который входят все основные компании, разрабатывающие программное обеспечение для Internet (в том числе, и Microsoft с Netscape). В идеале, все броузеры должны удовлетворять данным спецификациям, но, к сожалению, реальная жизнь и конкуренция между ведущими производителями броузеров вносят свои коррективы.

Напомню, что первоначально HTML позиционировался как язык логической разметки текста, независимый от устройства вывода. То есть тэги воспринимались как указание к выделению части текста некоторым образом. Отсюда в языке имеется множество т.н. логических тэгов типа <strong>, <em>, : , к сожалению, редко применяющихся. Фраза «независимый от устройства вывода» обозначает, что результат интерпретации HTML-кода может быть выведен не только на экран, но и, к примеру, на звуковую карту (когда компьютер сам будет читать Вам содержимое HTML-странички) или на специальное устройство, воспроизводящее содержимое странички кодом Брайля. Но получилось так, что язык HTML, в конце концов, превратился в язык описания страниц на экране компьютера.

В настоящий момент имеются два броузера, особенности которых должен учитывать web-дизайнер при изготовлении страничек. Это «Netscape Navigator» и «Microsoft Internet Explorer» (а вдруг кто не знает На самом деле броузеров гораздо больше, но они все вместе занимают всего около 1% рынка и, как правило, стремятся к совместимости с одним из двух лидеров. Между собой лидирующие броузеры делят рынок в соотношении примерно 75/25 (на данный момент лидирует Internet Explorer). Так что, в дальнейшем будут рассматриваться только эти программы.

Первое правило профессионального web-дизайна

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

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

Второе правило профессионального web-дизайна

Кроме этого, приходится также учитывать тот факт, что пользователи имеют компьютеры с различной аппаратной конфигурацией. Я не имею ввиду, что кто-то ходит по Web на 286 машине (а вдруг правда? , но есть много вполне современных компьютеров, которые обладают низкой разрешающей способностью. За примерами далеко ходить не надо — ноутбук. Большое их количество выпускается с черно-белым экраном, а цветные ноутбуки чаще всего ограничены палитрой в 256 цветов. Или, например, палмтопы (становящиеся популярными карманные компьютеры) под управлением Windows CE — они изначально были черно-белыми.

Вот, добрались и до второго правила — профессиональный Web-дизайнер должен просматривать странички при различном количестве цветов. И в случае необходимости делать странички с использованием только безопасной палитры.

Третье правило профессионального web-дизайна

Все странички принадлежат одной большой объединенной сети (WWW называется , и в этой сети находятся совершенно разные компьютеры: IBM PC-совместимые, Apple Macintosh, различные версии UNIX, Amiga, : Да и все что угодно. И все эти платформы, так скажем, немного отличаются при выводе графики на экран. Вряд ли шрифт в Linux будет точно таким же, как в Windows, да и палитра цветов по умолчанию может отличаться, и алгоритм дизеринга при выводе на экран, и : В общем, если сайт важный и представляет интерес для широкого круга пользователей, то обязательно протестируйте сайт на разных платформах и под разными операционными системами. Это было третье правило профессионального Web-дизайнера

И не забывайте про текстовые броузеры, самым известным представителем которых является Lynx. Сайт может быть сколь угодно красив, но что от этого толку, если его не увидят! Поэтому всегда думайте о том, как сайт будет выглядеть в текстовом варианте. Навигация должна оставаться простой и понятной. И достигается это простыми способами: если у вас меню в виде картинки, то не поленитесь снабдить все картинки подписями, а если не получается, то продублируйте меню текстовыми ссылками внизу страницы. Владельцы текстовых броузеров будут счастливы И заметьте, что ни один из текстовых броузеров не отображает таблицы, а текст внутри ячеек выводит сплошным потоком (слева направо и сверху вниз). То же самое с фреймами.

Стильность web-сайта достигается несколькими приемами. Можно выделить следующие элементы, участвующие в создании стиля:

• шрифт — в пределах публикации он должен иметь одинаковые характеристики — такие, как гарнитура (начертание), кегль (высота), цвет.
• абзац — желательно, чтобы преобладал какой-нибудь один из видов выравнивания на страничке, например, публикация сделана с отступом от левого края и выравниванием влево.
• цветовая схема web-сайта — она начинается с выбора тех трех цветов страницы, которые используются для представления обычного текста, ссылок и посещенных ссылок. Все эти параметры указываются в тэге <body>. Ниже, для примера, приведена строчка, задающая цвета на этих страничках: <body bgcolor=»#669900″ text=»#333333″ link=»#669900″ vlink=»#666666″ alink=»#000000″>Цветовая схема должна повторяться на всех страничках публикации, это создаст у посетителя ощущение связности сайта. Цвета ссылок старайтесь выбирать таким образом, чтобы, с одной стороны, читатель видел, что это ссылка, а с другой стороны, она бы не мешала ему читать основной текст. По поводу ссылок есть два полезных замечания: первое — как бы Вам не хотелось сделать цвета ссылок и посещенных ссылок одинаковыми (без веских на то причин), постарайтесь перебороть себя и придать им немного различия, для этого просто сделайте цвета уже посещенных ссылок чуть темнее; и второе — так уж получилось, что подчеркнутый текст в Web символизирует ссылку, поэтому поборите искушение использовать подчеркнутый текст в публикации, воспользуйтесь другим способом выделения. Вы ведь знаете, что очень неприятно, если, допустим, Ваша рука потянулась к ссылке с целью прочитать подробности, а мышка на нее ноль внимания .
• графическое оформление сайта — во-первых, оно должно укладываться в общую цветовую схему; во-вторых, Вы должны продумать общую концепцию графического оформления. Все графические элементы можно разделить на два больших класса: рисованные и фотореалистические. Постарайтесь не смешивать эти два типа в оформлении. Кроме этого, в случае, если Вы используете на сайте фотографии в качестве иллюстраций, то перед использованием обработайте их — сделайте в случае необходимости тоновую и цветовую коррекцию, кадрирование, выберите примерный размер фотографий в публикации, найдите способ обработать края фотографии. А потом используйте данное оформление по всей публикации. И всегда пишите пояснения к фотографиям в параметре ALT тэга IMG — это будет восприниматься как подпись к фотографии и, кроме того, избавит пользователя от ожидания в случае, если его не интересует данная страничка.
• навигация по сайту — именно она не дает посетителю запутаться в дебрях Вашего сайта. Всегда оставляйте для посетителя возможность перехода на главную страничку публикации. Кроме этого, не забывайте, что очень много людей попадают на Ваши странички через поисковые системы, т.е. не на первую страницу, и хороший сайт должен позволить читателю перейти на первую страничку; попросту говоря, дублируйте навигационную систему на всех страничках или сделайте так, чтобы они, по крайней мере, имели переход на основную страницу. В случае, если Вы выполняете навигационную панель графическими средствами, то обязательно сделайте ее текстовую копию и поместите где-нибудь снизу (текст в любом случае загружается быстрее графики .

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

Я попробовал выделить основные причины, которые, по моему личному мнению, влияют на популярность сайта:

• Содержание или контент — является одной из самых важных составляющих. Если на сайте нет полезной информации, способной заинтересовать определенный круг людей, то можно ставить вопрос о необходимости существования сайта как такового. Вспомните, как много полезных страничек Вы видели в последнее время по сравнению с общим количеством посещенных Вами мест?
• Дизайн — вторая по важности составляющая хорошего сайта. От дизайна зависит, насколько привлекательны будут странички, т.е. в конечном счете, сколько людей дополнительно захотят прийти и посмотреть на Ваш сайт. Ведь если Вам очень понравился дизайн сайта, то Вы, наверняка, расскажете о нем своим друзьям. Не забывайте, что встречают-то по одежке.Для того, чтобы сделать хороший сайт, не обязательно даже использовать графику. Есть полезные сайты с минимумом графики (или даже без оной) и масса бесполезных, забитых мегабайтными картинками. Для web-сайта, как впрочем, и для других дизайнерских проектов, очень важным является стиль сайта, придающий ему собственное лицо и узнаваемость. В последующих статьях я опишу основы и принципы создания стильных web-страничек.
• Скорость загрузки Ваших страничек — НИ ОДИН НОРМАЛЬНЫЙ ЧЕЛОВЕК НЕ БУДЕТ ЖДАТЬ ЗАГРУЗКИ ВАШИХ СТРАНИЧЕК В ТЕЧЕНИЕ ЧАСА. Отсюда следует вывод — странички нужно оптимизировать для получения наименьшего их размера (разумеется, в пределах разумного). Давайте посчитаем максимально допустимый объем средней WEB-странички.Принимая к рассмотрению тот факт, что подавляющее число людей (и небольших организаций) имеют доступ к Internet через коммутируемую связь, т.е. по телефону (и, к тому же, немаловажный факт — за повременную оплату) и средняя скорость доступа по модему в России составляет 14400 бит/c, можно посчитать время, затрачиваемое на перекачку одного килобайта (это без учета того факта, что большинство людей держат открытыми одновременно 2-3 или более копий броузера — в этом случае просто разделите среднюю скорость доступа на количество открытых броузеров).

  Следовательно, средняя скорость перекачки равна 14400 бит/с / 8 =1800 байт/с — это в идеальном случае, на самом деле немного меньше из-за повторных передач ошибочно принятых блоков. Поэтому примем среднюю скорость равную 1200-1500 байт/с. Только не путайте данную скорость, которая является скоростью до провайдера, со скоростью перекачивания Вашей странички, она может оказаться намного меньше, так как информация, достигшая Вашего компьютера, проходит через несколько компьютеров (как правило, 10-15), и скорость определяется самым узким звеном в цепи.

  Допустим, днем загруженность маршрутизаторов (компьютеров, передающих информацию из одной сети в другую) больше, чем ночью. Кроме этого, если Ваш сервер находится на компьютере, который соединен с провайдером по коммутируемой (или выделенной) линии на скорости 14400 бит/с, то человек, сидящей по другую сторону Internet, ни за что не добьется скорости выше этой (я исключаю случаи с Proxy-сервером, т.к. на них, в основном, хранится часто запрашиваемая информация — например, странички поисковых систем). Я принимаю допустимым время загрузки одной странички не более 40 секунд (эта величина взялась из личного опыта , отсюда — 40*1200= 48Кб — это и будет тот максимальный объем, который может иметь страничка вместе со всей графикой, находящейся на ней. Если Вам требуется разместить информацию большего размера, то предупредите об этом пользователя или распределите информацию по нескольким страничкам.

• Раскрутка web-сайта — включает в себя не только регистрацию Вашего сервера во всех возможных Поисковых системах мира, но и такие средства, как размещение информации в средствах массовой информации (URL — в газете), а также упоминание о Вашем сайте на визитках, рекламках, в газетных и журнальных статьях и т.д. Кроме этого, на web-сайте обязательно должен быть упомянут E-mail для связи с Вами или, в случае его отсутствия, хотя бы номер телефона.
• Ясная и логическая структура размещения информации на Вашем сервере — ничто так не утомляет при поиске нужной информации, как плохо структурированные сервера.
• Отсутствие орфографических и грамматических ошибок — этот пункт я включаю сюда ввиду громадного количества ошибок на свежепоявляющихся web-сайтах. Ведь это просто — набивайте текст в редакторе с проверкой орфографии и перечитывайте то, что Вы написали перед выставлением Вашего сервера на всемирное обозрение.

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