Текст книги "Корпоративный веб-сайт на 100%. Требуйте от сайта большего!"

71. Доменное имя

Доменное имя – это уникальная буквенно-цифровая композиция, которая служит для адресации веб-сайтов в Интернете.

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

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

Проверить, свободен ли домен и, при необходимости, зарегистрировать его, можно на www.nic.ru

Требования к выбору и использованию доменных имен:

♦ Принадлежность к стране (зоне) или тематике. В России наиболее эффективным будет использование доменов в зоне. ru (то есть доменов типа www.company.ru). Использование зоны. com разумно для международных компаний. «Тематические» доменные зоны (типа. net, org, info) рекомендуется использовать в случае, если сайт принадлежит к одной из специфических отраслей – государство, сетевая служба, образовательное учреждение и др.

♦ Понятность. Если при прочтении названия домена можно сразу догадаться о том, кому он принадлежит, – это существенный плюс. Например, www.beeline.ru, www.mts.ru.

♦ Настроенные алиасы. Системный администратор должен обеспечить идентичность попадания на сайт при наборе www.company.ru («полностью, с www») и company.ru («не полностью, без www»)

♦ Количество доменов. Здесь нет однозначного мнения. С одной стороны, во всей рекламе и маркетинговых материалах следует указывать один постоянный и четкий домен, который должен запомниться и приводить посетителей. С другой стороны, с целью поисковой оптимизации многие компании создают целые группы сайтов (клонов) с разными доменными именами, что приводит к ним дополнительных посетителей

♦ Уровень домена. Считается по количеству точек в имени. Домен. ru – первого уровня, company.ru – второго, promo.company.ru – третьего и т. д. Домены первого уровня заре ги стрировать нельзя, они ре гули руются организациями, управляющими доменными именами. Наилучший домен, который можно зарегистрировать, – второго уровня, company.ru. Обратите внимание, что www.company.ruтехнически является доменом третьего уровня, хотя обычно его называют доменом второго уровня (company.ru и www.company.ru, при этом, как правило, ссылаются на один и тот же сайт)

♦ Краткость. Домен должен быть максимально кратким и удобным для набора. Для компании «НефтеТрансУгольХолдинг», домен удобнее назвать www.ntugh.ru (или www.NTU-holding.ru), а не www.neftetransugolholding.ru

♦ Звуковая ясность. Корпоративный домен должен быть максимально простым, так как он часто используется в речи и диктуется по телефону. Выражения: «S как доллар», «Русская е», «i с точечкой» не вносят ясность в понимание, а, наоборот, могут запутать Клиента

♦ Однозначность. При написании домена важно, чтобы в нем нельзя было ошибиться. Например, попробуйте написать домен www.zhilishnoehozjaistvo.ru без ошибок. А теперь www.dom2.ru. Иногда этим приходится пренебрегать, например, если компания названа по имени ее отца-основателя (как, скажем, у одного из авторов этой книги, – www.sukhov.ru, где русская «Х» транслируется в «kh»)

♦ Принадлежность к отрасли. Если все варианты написания «корпоративного домена» заняты, то можно создать отраслевой домен (www.zhelezo.ru, www.stal.ru, www.derevo.ru, www.pupsik.ru); это будет лучше, чем сложный собственный домен. Английские слова надо использовать осторожно и только общераспространенные (например, www.book.ru)

♦ Несколько созвучных вариантов. Если ваша компания – Walmart, то регистрировать стоит домен www.walmart.ru и www.wal-mart.ru. В частности, и для того, чтобы на похожем домене не был образован враждебный сайт с антиинформацией о вашей компании. Таких случаев немало!

Домены, состоящие только из цифр

Иногда, компании принимают решение о регистрации доменного имени, состоящего только из цифр (например, www.322223.ru). Обычно прототипом таких имен выступают номера телефонов компании.

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

Кириллические домены

В настоящее время начаты работы по внедрению доменных имен на национальных языках (то есть доменов типа www.Магазин.su). Суть этой технологии в преобразовании имен на стороне пользовательского программного обеспечения перед отправкой запроса в систему DNS, а не в переводе всей глобальной интернет-системы на многоязычные домены. Данная технология получила название Punycode, и она рекомендована международной корпорацией ICANN. Ее поддержка уже реализована в наиболее распространенных интернет-браузерах: в Internet Explorer 7.0 и в семействе версий Mozila Firefox 2.x.

Многодоменность

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

• географическая или языковая распределенность компании. Пользователям привычней запоминать домен со «своим» доменом (.ru, kz, ua и т. д.). Кроме того, при прямом запросе «своего» домена можно сразу же выдавать локализованное представление сайта;

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

72. Система управления контентом

Система управления контентом (Content Management System, CMS) – это программный комплекс, предназначенный для управления веб-сайтом. Наибольшее распространение в России получили системы управления контентом: «1С-Битрикс. Управление сайтом», NetCat, UMI CMS.

Корпоративный сайт может работать:

• без системы управления контентом (такое сегодня встречается крайне редко);

• на самостоятельно разработанной системе управления контентом (то есть неком «движке», написанном собственными программистами компании);

• на «некоробочной» системе управления контентом (системе, созданной небольшой веб-студией для продажи ее собственным Клиентам);

• на промышленной системе управления контентом (то есть платформе, разработанной специализированной компанией и, как правило, имеющей более 500 внедрений);

• на базе веб-расширения, входящего в состав EPR-системы (например, Lotus Domino, Siebel, SAP).

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

Критерии выбора системы управления контентом

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

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

В Сети доступны демоверсии платных отчетов о характеристиках различных систем управления контентом, подготовленных CMSWatch

Мы рекомендуем учитывать следующие моменты:

♦ Набор программных модулей/функциональностей, входящих в систему

♦ Базовая платформа

♦ Принцип и схема лицензирования/стоимость при покупке или аренде (SaaS)

♦ Открытый исходный код

♦ Документация к CMS/система обучения/сертификации

♦ Интеграция с другими системами (1С, внутренние информационные системы компании, платежные системы)

♦ Политика и частота обновления системы

♦ Импорт/экспорт данных (поддерживаемые форматы файлов)

♦ Послепродажное гарантийное обслуживание (условия/сроки)

♦ Стоимость дальнейшей поддержки

♦ Распространенность продукта/партнерская сеть

♦ Количество и качество внедрений

♦ Примеры реализованных веб-систем данного типа

♦ Многосайтовость

♦ Язык бек-офиса

♦ Безопасность

♦ Система прав

♦ Производительность и масштабируемость

♦ Требования к хостингу

♦ Репутация компании-производителя

Западный подход к выбору и критериям сравнения различных систем управления контентом отражен на сайтах www.cmsmatrix.com, www.web2grow.com и www.cmswiki.com

Критерии выбора системы управления контентом, используемые отечественными и западными специалистами, довольно сильно различаются. Наши заказчики уделяют до 90 % внимания сравнению количества модулей, имеющихся в системах (разумеется, считается, что чем их больше, тем система «круче»).

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

На Западе числу модулей уделяется не более 30 % внимания. Основными считаются сервисные и репутационные характеристики как самой системы, так и ее производителя.

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

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

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

Документация

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

♦ Руководство пользователя

♦ Руководство разработчика

♦ Руководство администратора

♦ Лицензионное соглашение

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

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

Система управления контентом и взаимодействие с веб-разработчиком

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

Веб-разработчик использует систему управления контентом только как основу для создания сайта

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

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

73. Документооборот

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

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

♦ Настройки произвольного количества маршрутов или статусов при движении документа

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

♦ Синхронизация и, наоборот, блокировка работы над документами

♦ Поддержка различных кодировок (например, Win-1251, UTF-8 и др.)

♦ Сохранение истории всех изменений

♦ Настройка различных правил документооборота для разных типов данных (статей, файлов) или разных разделов данных (о компании, каталог продукции)

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

♦ Автоматическое создание версий документа на установленных этапах, возможность отката документа к определенному состоянию

♦ Использование специальных поисковых инструментов

74. Документация

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

Документы на стадии разработки

Обратите внимание, что еще при заказе веб-сайта вам должны быть предоставлены:

♦ Договор на разработку веб-системы

♦ Календарный план

♦ Бюджет

♦ Техническое задание

♦ Договор на поставку (лицензирование) программного обеспечения

Ключевыми являются два документа – договор и техническое задание.

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

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

♦ Предмет договора (наименование предоставляемой услуги, перечень приложений, условия вступления договора в силу и т. д.)

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

♦ Ответственность сторон и регламент (условия выплаты неустоек, механизмы пролонгации, условия расторжения договора и т. д.)

♦ Форс-мажор

♦ Стоимость и условия оплаты (стоимость исполнения работ, схема оплаты и т. д.)

♦ Терминология

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

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

♦ Реквизиты и подписи сторон

Вся истина в ТЗ

Техническое задание (ТЗ) на разработку веб-системы обычно оформляется как приложение к основному договору. Объем ТЗ, составляемого серьезным разработчиком, может доходить до 60–80 листов и включать несколько сотен параметров.

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

Структура технического задания может выглядеть следующим образом:

♦ Общая информация

• Общая информация о заказчике

• Общая информация о проекте

• Общие вопросы обслуживания

♦ Требования к информационной инфраструктуре

• Общее устройство системы

• Роли

• Доменные имена

• Карта фронт-офиса

• Объемы и форматы информации

• Многоязычность

• Учет требований поисковых систем

♦ Календарный план выполнения работ с указанием ответственности сторон

♦ Требования к технической инфраструктуре

• Требования к программноаппаратной платформе

• Требования к используемым технологиям

• Требования к хостинговой площадке

• Требования к производительности

• Требования к безопасности

♦ Требования к интерфейсу

• Требования к дизайнерскому решению

• Предоставляемые заказчиком визуальные компоненты

• Требования к навигации, шрифтам, сетке форматирования

♦ Требования к мультимедийным элементам

• Перечень

• Формат

• Условия работы

♦ Регламент выполнения работ на этапах проектирования, разработки, тестирования, документирования и обучения, запуска веб-сайта и гарантийного обслуживания

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

Документация на стадии поддержки и развития

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

♦ Договор о поддержке, определяющий условия предоставления соответствующей услуги

♦ Документ о передаче логинов и паролей

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

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

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

В среднем разработка документов может составлять 5-10 % от стоимости создания сайта

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

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

Из рецензий наших экспертов

75. Базы данных

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

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

Как выбрать СУБД

Мы рекомендуем учитывать следующие критерии выбора СУБД для веб-сайта:

♦ Соответствие параметров СУБД требованиям проекта (платформа, производительность и т. п.)

♦ Распространенность продукта

♦ Наличие ресурсов для администрирования и развития системы в рамках выбираемой СУБД

♦ Стоимость внедрения и поддержки

♦ Совместимость выбираемой СУБД с существующей технической инфраструктурой (включая наличие связующих интерфейсов и приложений)

Наиболее распространенные СУБД:

• MySQL

• MSSQL

• PostgreSQL

• Oracle

Реже используются СУБД Firebird, Interbase, Sybase и др.

Преимущества использования баз данных

Использование баз данных дает целый ряд преимуществ в сравнении с хранением информации непосредственно в HTML-формате:

♦ Поддержка структурированных (атрибутивных) типов данных

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

♦ Четкое разделение уровней хранения и представления данных (в частности, возможность хранения данных в «одном месте» и вывода их в любое количество фронт-офисов)

♦ Компактное представление данных в файловой структуре

♦ Возможность централизованного управления всеми настройками

♦ Реализация бизнес-логики с помощью специализированных языков для баз данных

♦ Поддержка связей между различными элементами базы данных с контролем целостности этих связей

♦ Поддержка журнала транзакций и возможность отката к предыдущим версиям

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