авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |

«Келли Гото и Эмили Котлер Веб-редизайн: книга Келли Гото и Эмили Котлер Перевод Г. Нифонтовой Главный редактор ...»

-- [ Страница 6 ] --

Puc. 6.11. Экран метагенера mopa Dreamweaver 4 облегча ет создание и внедрение МЕ ТА-тегову становясь частью технологии Puc. 6.12. TITLE- атрибуты могут подробнее описать кон кретную гиперссылку, устра няя необходимость угадыва ния, и/или помочь пользова телю принять решение - на жимать или не нажимать.

Здесь показана простая текс товая гиперссылка на сайте www.zeldman.com, снабжен ная атрибутом TITLE, кото рый быстро и наглядно пока зывает, что откроется пос ле щелчка по гиперссылке:

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

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

Понимание важности контроля качества (QA) Сайт сформирован;

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

точно так же сайт не следует запускать без всестороннего просмотра.

Рекомендуется отвести в бюджете на контроль ка чества приблизительно 10% от общего времени и ресурсов. Здесь необходимо отследить и исправить все недочеты: орфографические ошибки, осиротев шие и некорректные гиперссылки, неправильно расположенное содержимое и так далее (рис. 6.13).

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

Рис. 6.13. Типичный простой дефект: не загружается изображение (вверху). Быстрая проверка каталогов и перезагрузка изображения решили проблему (внизу). Примером более серьезной ошибки могло бы служить искажение выпадающего меню DHTML в некоторых броузерах (это труднее проиллюстрировать) Фаза 4: Производство и контроль качества Однако во многих проектах редко остается время и средства на проверку ка чества, которую часто совмещают с запуском сайта при сдаче его клиенту. Не редко также крайние сроки производства отодвигаются (обычно из-за задержек с поставкой контента и технических неполадок), и времени на QA не остается.

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

2) каковы критерии приемлемости - насколько совершенным должен быть сайт при запуске и 3) насколько гибко оговорена дата запуска.

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

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

Создание плана контроля качества (QA) С самого начала проекта известно, что необходимо провести проверку качества (QA) и требуется составить план этого мероприятия. Не исключено, однако, что весь план контроля качества ограничивается единственной строкой в бюджете, которая выглядит примерно так: QA = 12 часов. Или 5 часов. Или 20+ часов.

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

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

упрощенный/неформальный, полуформальный и формальный. Выберите тот уровень, которого требует ваш проект.

Ответственный за контроль качества ных навыков в тестировании и запуске любого про В фазе 1 обсуждался спектр задач и обязанностей дукта гораздо более ценно, чем приспосабливание к ролей в проекте, одна из которых - роль ответствен этому. Превосходный обзор принципов и стратегии ного за контроль качества (QA). В зависимости от раз контроля качества есть на www.philosophe.com.

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

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

Фаза 4: Производство и контроль качества РАСШИРЕННЫЕ/ОФИЦИАЛЬНЫЕ ПРОЦЕДУРЫ ПРОВЕРКИ Проверка модулей Проверка отдельных компонентов веб-страницы для подтверждения их правильного функционирования. Проверка модулей - это подтвержде ние запланированной функциональности и откликов перед окончательным встраиванием проверяемого кода.

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

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

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

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

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

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

все больше внимания следует уделять интеграции.

Глава б Неформальная проверка очень проста и выполня Проблема с фреймами ется самой проектной группой. Формальная про верка обычно предполагает наем внешней, квали Если сайт содержит фреймы, имейте в виду* что контроль ка- фицированной группы. Полуформальная - соот чества займет, по крайней мере, ветственно, что-то между этими двумя. Большин вдвое больше времени. Вложен ство сайтов с бюджетом веб-проекта ниже 30 тысяч ные фреймы? Тогда еще боль долларов может обойтись неформальной провер ше. Как правило, чем больше кой. Сайты со сложными функциональными воз имеется фреймов, тем больше можностями и прикладным уровнем обычно тре проверок необходимо. Кроме то буют проведения формальной или, по крайней ме го, фреймы срывают поисковые ре, полуформальной проверки.

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

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

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

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

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

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

группы: проверить сайт и выдать Руководитель проекта должен отслеживать также распечатки с ясно перечисленны список дефектов, так называемый «bug list», кото- ми ошибками и комментариями рый при неформальном испытании представляет по поводу совместимости с тре буемыми броузерами и платфор собой просто пачку распечаток с отмеченными мами. При любом уровне испы ошибками. Заметная красная пометка будет ука таний клиент должен проверить зывать на обнаруженную ошибку, а сопроводитель контент. Только клиент может до ные пометки «Устранено» или «Отложено на потом»

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

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

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

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

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

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

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

лица Excel, или распечатки).

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

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

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

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

При формальном контроле качества для проверки сайта на соответствие требованиям и проверки страниц с заданными броузерами и платформами используется всесторонняя система отслеживания ошибок и специальный квалифицированный штат Рис. 6J4. Таблица, подобная этой, поможет проследить все комбинации пар плат форма-броузер целевой ауди тории. В ней можно отра зить установки испыта тельного стенда. Данная ти повая аудитория не включает пользователей броузеров 3. или платформ UNIX Фаза 4: Производство и контроль качества испытателей QA (да, именно штат). Формальное Инструментальные сред тестирование включает план испытаний, инстру ства обнаружения ошибок ментальные средства, типичные ситуации, испы Хотя автоматизированные програм тания на стенде и отчеты. Для иллюстрации масш мные системы не могут полностью табов процесса формального контроля качества заменить фактическую проверку ка рассмотрим типичный пример: нужно определить, чества сайта человеком, существу по крайней мере, 10 различных маршрутов через ет много доступных инструмен сайт и каждый из них проверить на трех платфор- тальных средств, которые помогут мах (MAC, WIN, UNIX);

с каждой платформой в этом процессе. Для комплексного проверить работу трех броузеров (IE, Netscape, тестирования HTML на предмет со AOL), каждый броузер испытать во всех его вер- ответствия стандоту, корректности сиях (от 3.0 до 6.0;

заметим, что Netscape пропус- гиперссылок, правильности право тил версию 5.0). Таким образом, данный пример писания, времени загрузки и т. п.

воспользуйтесь www.netmecha содержит приблизительно 450 различных тестов nic.com. Цены варьируются от 35 до (10x3x3x5) для выбранных маршрутов. Ошелом 200 долларов за проверку до ляет? Да. Невозможно? Возможно. А в условиях страниц HTML неформального тестирования? Невозможно. Нуж Есть ли другие онлайновые инстру ны такие испытания крупным сайтам с существен ментальные средства? Их очень ной внутренней инженерией и обширными функ много. Для проверки МЕГА-инфор циональными возможностями? Безусловно.

мации посетите www.scrubthe web.com. Сайт mw.w3.org/People/ Расстановка приоритетов Raggefytidy поможет привести в по радок HTML Превосходный инстру и устранение ошибок мент для отслеживания ошибок предлагает www.alumnLcaftech.edu/ Решите, какие ошибки следует устранить немед- dank/gnafchtml. Хотите больше уз ленно. Это заметные, вопиющие дефекты. Продол- нать об ошибках? Поинтересуйтесь жите список и расположите остальные ошибки по на wm.mwMxxg/bugs. Кроме то приоритетам, явно характеризуя их: вопиющие, го, Mozilla - удобный ресурс для проверки качества.

высокий приоритет, средний приоритет и низкий ЗАМЕЧАНИЕ: Для проектов с бюджетом до 10 тысяч долларов лишь 100-долларовые затраты времени и ресурсов, конеч но, недостаточны. Все равно вам потребуется проверять весь сайт.

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

размером с большой палец).

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

пример, главная страница не правильно загружается;

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

ты, располагайте их по приори тетам. Какие из них вопиющие?

Заключительная проверка Какие можно устранить итераци онным подходом в первую неде лю запуска? Иногда дата запус- Всей проектной группой проведите заключи ка «высечена на камне», и нет тельную проверку. Удостоверьтесь, что все систе времени на исправление всех мы работают. Следует проверить пять ключевых ошибок. Расставьте приоритеты аспектов:

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

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

Фаза 4: Производство и контроль качества Рис. 6.15. Сбой изображения (вверху), проявляющийся на броузере AOL 4.0 в ходе процес са QA, но бессистемно: только на некоторых портативных компьютерах. Причиной по служила установка конечного пользователя: неотмеченная опция «Использовать сжатые изображения» («Use compres sed images» ). Затем сброс кэ ша броузера исправил сбой и отобразил нормальное изобра жение (внизу). Ошибки, вызы ваемые конечными пользова телями, в основном вне конт роля QA-тестирования шая группа QA-тестирования никогда бы не обратила внимание. Текст HTML может быть размещен неправильно или что-то не так с обработкой фотогра фий. Пусть арт-директор или дизайнер просмотрят весь сайт и на Мае и на PC, чтобы гарантировать качество.

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

После QA-тестирования и устранения ошибок группа HTML должна убедить ся еще раз, что сайт визуально работает и на MAC и на PC. Иногда при устра нении ошибок нарушается код.

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

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

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

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

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

Резюме фазы Фаза производства, вероятно, наиболее прямая и очевидная в Базовом процес се. Идет фактическое формирование сайта. Для импровизации здесь не так мно го места. Производство - прямой этап от начала до конца: опросить клиента, составить ведомость клиентских технических требований, проконсультировать визуальных и информационных дизайнеров относительно выполнимости (фазы 2 и 3), сформировать протосайт и проверить функциональные возможности (фаза 3), принять графические шаблоны от визуальных дизайнеров, разрезать на части и оптимизировать графику, сформировать шаблоны HTML и интегри ровать облегченные сценарии, сформировать и заполнить индивидуальные страницы, интегрировать сложные функциональные возможности и внутрен ние приложения и/или разработки и все протестировать. Затем вздохнуть. По том сформировать руководство по стилю оформления HTML и подготовиться к передаче сайта (фаза 5).

Почему производственная группа участвует на протяжении всего процесса? До вольно ясно: без расширенной проверки, тестирования и перепроверки к фазе компоновки переходить опасно. Это все равно, что, выйдя с лыжами из подъем ника, покатиться вниз по любому склону, не проверив, насколько он крут. По думайте о возможных проблемах, иначе может оказаться, например, что когда вы формируете шаблоны HTML, ваши выпадающие меню блокируют место для рекламы, обозначенное в договоре, или вы пытаетесь разрезать на части и опти мизировать объект, который вообще не может быть преобразован в HTML. Лю бая из этих ситуаций привела бы к потерянным впустую многим часам, к нап расному программированию. Группе пришлось бы возвращаться назад, и если дата запуска определена твердо, на проект не хватило бы времени.

Не волнуйтесь, однако. Базовый процесс настроен так, чтобы производство про ходило с минимальными сбоями. Несомненно, ошибок не избежать - каждый сайт их имеет. Радуйтесь, что этап производства завершен! Ну, почти. Сайт сфор мирован. Он логично организован и будет прост в эксплуатации благодаря хо рошо продуманному HTML. Сайт не содержит ошибок. Он дружествен по отно шению к пользователю. Выглядит точно так, как задумано визуальными ди Фаза 4: Производство и контроль качества зайнерами. Группа готова позаботиться о запуске и дальнейшей судьбе сайта.

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

Теперь готовьтесь его подать.

Учебный пример Janus Клиент: Janus Capital Corporation URL: www.janus.com Проектная группа: Sapient Эксплуатационная группа: внутренняя, Janus ПРЕДЫДУЩИЙ JANUS.COM [ПРЕЖНИЙ] В ПРОЦЕССЕ ПОДГО ТОВКИ К ЗАПУСКУ НОВОГО JANUS.COM [ПЕРЕ ПРОЕКТИРОВАННОГО] еще до запуска предоставил своим пользователям возможность предварительного JANUS.COM [ПРЕЖНИЙ] представляет собой тип просмотра нового сайта, позволяя им участвовать в ин сайта, строго подчиненного основной цели. Целью сай- вестициях уже на этом этапе. (2000 г.) та всегда было круглосуточное онлайновое самообслу живание.

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

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

СОВРЕМЕННЫЙ JANUS.COM [ПЕРЕПРОЕКТИРОВАННЫЙ] использовал результа ты социологических исследований, чтобы лучше понять мотивацию ин весторов. Введена более интуитивная и действенная для пользовате лей навигация. Внешнее оформление сайта изменено с целью более эффектного позиционирования бренда компании.

Результат: Большая продуктивность при меньших издержках. В янва ре 2001 г. через Janus.com корпорация приобрела 62% инвесторов по сравнению с 32% в январе 1999 г.

См. цветную вклейку, стр. 350- Фаза 5: Запуск и сопровождение Запуск сайта - важная, даже праздничная веха.

Но это только этап;

веб-сайт всегда находится в развитии.

Фаза 5: Запуск и сопровождение В сегодняшнем мире веб-разработок этот момент - запуск - вовсе не конец ра боты;

это переход к совсем другой технологии: эксплуатационной поддержке.

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

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

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

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

Передача сайта Любой дизайнер скажет, что проект завершен, только когда кто-то другой видит, что он завершен.

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

В большинстве проектов одна команда отвечает за формирование и запуск сайта, а другой команде Глава поручается его сопровождение. Даже при разра Кто это сломал? ботке сайта внутренней группой состав эксплуата Кто должен решать проблемы, ко- ционной команды часто бывает отличным от ко торые возникают в первые не- манды разработчиков. Но независимо от того, кто сколько дней/недель после пере- и кому передает проект, данный этап - это время, дачи сайта? Вот реальная ситуа- когда следует утрясти несколько вопросов, чтобы ция: команда веб-разработчиков эксплуатационная группа могла справиться со сдала полностью протестирован своей задачей.

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

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

менении HTML-страниц или графики.

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

Задолго до передачи сайта твердо установите, что запрашиваемая после запус ка техническая помощь и поддержка, начиная с определенного срока после пе редачи, будет платной. Установите срок в 30, 45, 60 или 90 дней. Укажите его в письменном виде и постарайтесь подписать этот документ у клиента. (Лучшее место для этого документа - в разделе «Детали и уточнения».) 252 Глава Производственная часть руководства по стилю оформления должна включать коды для HTML-тегов, атрибутов и определения графических элементов. Для справки воспользуйтесь приведенным перечнем рекомендуемых компонентов.

Уровень детализации зависит от конкретного проекта. По стилю производствен ная часть должна соответствовать формату всего руководства. Рекомендуется сделать этот документ и наглядным и информативным (рис. 7.1). Некоторые проекты могут быть достаточно простыми и не нуждаться в вызываемых кодах.

Фаза 5: Запуск и сопровождение Другие, наоборот, могут потребовать дополнительных элементов (например, схе мы фреймов). Если используемые фреймы требуют определенного усилия в по нимании логики, включите схему, отражающую соответствие между фрейма ми и файлами (рис. 7.2).

Рис. 7.1. Фрагмент произ водственной части руко водства по стилю оформ ления для newriders.com 254 Глава Рис. 7.2. В схеме фреймов необходимо четко указать, на какой фрейм направляют гиперссылки Создание пакета передачи Рассматривайте пакет передачи как эстафетную палочку: передается то, что не обходимо поддерживать в рабочем состоянии. Пакет передачи - это подборка всех материалов и документации проекта. Он включает все исходные файлы, изображения, шаблоны и спецификации, необходимые другой команде или ли цу для сопровождения сайта после начального запуска.

Соберите все файлы, необходимые для производства сайта. Четко обговорите со все ми членами проектной группы, какие файлы - как дизайнерские, так и HTML стоит архивировать. Вероятно, есть много промежуточных файлов, возможно, названных layout_01, layout_02, layout06, final, final_2, final-final и так да лее. Тщательно произведите отбор. Приведите в порядок файлы, подлежащие сохранению, дайте им понятные имена и заархивируйте каждый.

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

• Все файлы Photoshop/Fireworks (по слоям, текст неотрендеренный) • Шрифты (или информация о том, где приобретать шрифты) • Все фотографии/иллюстрации (включая информацию об авторских правах не забудьте о правах на использование!) • HTML-страницы и шаблоны Фаза 5: Запуск и сопровождение • Руководство по стилю оформления (дизайн и План юзабилити производство) в HTML-формате тестирования • Технические спецификации Проведение юзер-тестов на ра • Корневой каталог сайта и другие необходимые ботающем сайте - первая воз файлы можность увидеть, как взаимо действуют с сайтом реальные Этот пакет передачи должен быть одобрен руково пользователи. Один из лучших дителем проекта, ведущим дизайнером производ- сравнительных методов для по ства и арт-директором. Передача пакета знамену- лучения поддающихся оценке ет передачу сайта. С этого момента сопровождение результатов заключается в про сайта возлагается на эксплуатационную команду. ведении юзабилити-тестирова ния на существующем сайте и на Поскольку никто не знает сайт так хорошо, как только что стартовавшем пере его создатели, передача материалов почти всегда проектированном сайте и в после должна сопровождаться обучением и инструкта- дующем сравнении полученных жами. При планировании обучения группы экс- результатов. Если какие-то раз плуатационной поддержки сайта заранее оговори- делы еще трудно использовать, те общую продолжительность инструктажей, ина- включите соответствующие из че это может превратиться в бесконечный процесс. менения в план эксплуатацион Не задерживайте пакет передачи: эксплуатацион- ной поддержки и повторите юза ная поддержка сайта начинается сразу же. билити-тестирование после пол ной модификации сайта.

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

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

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

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

Каждый проект - накопление опыта. Некоторые проекты выполняются глад ко;

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

Планирование инструктажей по сопровождению сайта На большинстве сайтов в ходе эксплуатации наблюдается печальная тенденция:

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

Фаза 5: Запуск и сопровождение Четко ставьте задачи, объясняйте (с помощью ру ководства по стилю оформления) графику и HTML стандарты, а также технические цели сайта. Счи тайте это профилактикой для перепроектирован ного сайта.

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

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

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

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

9 Зак 258 Глава Текущая аудитория и ее зона комфорта Мягкий запуск Представьте себе график, напол- Облегчить принятие вашей текущей аудиторией нового облика сай- | ненный свободными паузами. Во- та поможет ее заблаговременное оповещение о редизайне. Соз образите, что имеете роскошь за- дайте страницу, объявляющую о редизайне и ясно объясняющую пускать сайт на действующем сер- новые особенности и навигацию. Свяжите ее непосредственно с вере и неторопливо тестировать главной страницей. Сделайте своих пользователей участниками на- его там, не испытывая давления чавшегося редизайна. В качестве руководства воспользуйтесь сле со стороны внешних факторов, дующими предложениями:

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

спокойный перенос сайта на • Новые возможности. Перечислите новые особенности кон действующий сервер. Иногда мяг тента. Добавляется ли новый тип информации? Расширяется ли I кий запуск означает также готов предметная область FAQ (часто задаваемых вопросов)? Если ре ность сайта не в полном объеме, дизайн происходит в несколько этапов, что намечено на бли например: «1 октября мы произ жайший из них?

водим мягкий запуск с 85% кон • Новая навигация. Сообщите аудитории о произведенных из- I тента. Остальное содержимое пла менениях. Например: «Мы реструктурировали наш сайт и вве нируется подготовить к 1 декабря ли больше связей между страницами, чтобы стало проще пе и тогда же начать рекламу пере ремещаться и получать наиболее часто отыскиваемую инфор проектированного сайта». Жесткий мацию. Мы разбили на части длинные страницы, требующие запуск - просто ситуация с жест много прокрутки, и добавили вверху страниц путеводные «хлеб ким крайним сроком, с незыбле ные крошки», чтобы всегда было понятно, в какой части сайта мой датой, которая обычно об вы находитесь».

условлена внешними ограниче • Обратная связь. Стимулируйте обратную связь. Например, ниями по времени. Всегда изна напишите так: «Понравился ли вам перепроектированный сайт?

чально планируйте мягкий запуск.

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

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

Не заказывайте оплачиваемую рекламу, по крайней мере* на Регистрация в поисковых системах первые две недели после наме ченной даты запуска. Что-то мо Согласно информационному бюллетеню NetMec жет не сложиться. Процесс QA hanic.com, 85% пользователей Интернета для тестирования может обнаружить отыскания сайтов используют поисковые механиз больше недочетов, чем ожида мы. Факт регистрации вашего сайта в популярных лось. Проектная группа может не поисковых системах не означает, что на этом мож- справиться с исправлением всех но успокоиться и просто ждать пользователей, хо- ошибок к запланированному сро тя в конечном счете и это работает (слегка). Веб- ку. Если можно, дайте несколько сайты запускаются ежедневно, и конкуренция за недель на послестартовые испы место в первой десятке результатов поиска посто- тания, чтобы гарантировать на янно растет. дежную работу сайта на посто янном сервере (мягкий запуск), Регистрация в поисковых системах не столь прос- а после этого начинайте внеш та, как звучит в некоторых объявлениях: «За 99 нюю маркетинговую кампанию.

долларов зарегистрируем ваш сайт во ВСЕХ ЛУЧ- Подумайте, стоит ли платить за ШИХ ПОИСКОВЫХ СИСТЕМАХ!». Остерегай- рекламу, которая приведет но тесь подобных предложений, которые похожи на вых пользователей на недорабо танный сайт. У вас только один объявления о продаже подержанных автомобилей.

шанс произвести хорошее впе Хотя они действительно обеспечат регистрацию ва чатление. Учтите это.

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

В исследовании, проведенном www.workz.com, бы ло опрошено 37 владельцев сайтов с целью выяс нить, какие методы они используют, чтобы повли ять на рейтинг сайта в поисковых механизмах, сколько времени они тратят на это в неделю и ка ких видимых результатов добиваются. Опрос яс но показал, что лучшие результаты достигаются при непосредственной ручной регистрации в ключевых поисковых системах и при еженедель ной затрате одного часа на изменение и улучше В Сети существует множество ресурсов, которые помогут эффек тивнее представить ваш сайт. Мы рекомендуем www.searchengi newatch.com, www.selfpromotion.com и www.workz.com - хоро шие источники, богатые полезной информацией.

262 Глава Регистрация через платную регистрационную Теги TITLE компанию. Существуют сервисы (некоторые из Теги TITLE - это гораздо больше, них хороши, другие - не очень, третьи - просто чем просто заголовки в верхней потеря времени), ценность которых в том, что части окна броузера, но часто они они, как утверждается, знакомы с отраслью и недооцениваются и неправильно имеют автоматизированные системы, позволя используются. Это один из наи ющие легко и быстро произвести представление более важных факторов, связан и регистрацию в поисковых системах. Ставка ных с эффективностью результа за сервис Submitit.com - минимум 59 долларов тов поисковых механизмов. При за два URL. Registerit.com - бесплатный сер создании заголовка имейте в ви вис с регистрацией в 12 поисковых системах.

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

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


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

страницы, а также автоматически регистриро вать их в поисковых системах в надежде удер жать ваш сайт в первой десятке. Программа Web Position Gold (www.webposition.com) полу чила благоприятные отзывы и относительно не дорога.

Незаполненный бланк инструмента для создания МЕГА-данных можно загрузить с www.web-redesign.com. Фаза 5: Запуск и сопровождение Этот инструмент поможет вам создать МЕГА-информацию: прежде всего, ключевые слова. Пожалуйста, не пу тайте это инструментальное средство с инструментами для представления сайта в поисковых системах или инстру ментами для обеспечения лучшего положения в результатах поиска. Данное пособие - скорее, перечень сведе ний, которые следует учитывать при генерировании МЕГА-информации, используемой поисковыми системами.

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

264 Глава Здесь приведены два примера МЕТА-информации.

Сравните и скопируйте: Найдите компании, которые предлагают аналогичные сервисы, и посмотрите их ключевые слова. Нечестно? Возможно, но все так делают.

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

Фаза 5: Запуск и сопровождение Важная часть запуска - незамедлительное QA-тес Расставляйте устраняемые тирование на постоянном сервере. Если вам уда дефекты по приоритетам лось запланировать мягкий запуск, то внешнего Можно не успеть сделать до за давления нет и тестирование можно провести в от пуска все до последней мелочи.

носительно неторопливом режиме (в течение не Следует составить список распо скольких дней от момента запуска, но желательно ложенных по приоритетам изме не затягивать). Если же сайт запускается в строго нений и подлежащих устранению установленный момент, возможно, придется по- ошибок на послестартовый пери спешить, чтобы провести тестирование на посто- од. Достичь совершенства сайта янном сервере. Обеспечьте возможность вернуться очень трудно, даже проведя пол к старому сайту, если вдруг всплывут вопиющие ное QA- и юзабилити-тестирова ошибки. ние. Вполне допустим некоторый приемлемый уровень недостат Запуск - это большое черное пятно на сером фоне ков. В первую очередь поза в период между разработкой и сопровождением ботьтесь о вопиющих ошибках ~ сайта. Клиент и команда разработчиков должны ошибках, которые должны быть прийти к полному согласию о готовности сайта к устранены до запуска - и запус возрождению. Это может казаться простым делом, кайте сайт. Исправьте следую но часто приходится долго топтаться взад и впе- щие по важности недочеты, а за ред между устранением недочетов и усовершенст- тем все остальное. Если вы вованиями, пока, наконец, будет достигнута готов- внешняя команда, готовящаяся к передаче сайта, определите, с ность к запуску. Потенциальная проблема кроет чем сможет справиться эксплуа ся также в передаче сайта клиенту без возможнос тационная команда. Передайте ти проверить его на клиентском сервере. В этот сайт, когда все будет готово над момент могут всплыть любые проблемы. А кто дол лежащим образом.

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

Когда наконец придет время возрождения сайта, возрождайте его. Вуаля! Сайт уже в эксплуатации.

Отпразднуйте это событие и готовьтесь оценить плоды своих трудов.

Откат - это последняя сохраненная и проверенная версия сайта, Запаситесь откатной версией старого сайта на случай, если что то не заладится с запуском.

Глава Эрик Уорд (Eric Ward) о том, как сделать сайт достойным ссылки на него Что касается ссылок из поисковых сис Почему некоторые сайты связаны ссыл тем, тут все определяет суровая действи ками, кажется, со всем Интернетом, в то тельность. При тысячах новых веб-стра время как другие сайты почти невиди ниц, добавляющихся к Сети ежедневно, мы? Почему поисковые системы ставят приходится конкурировать с постоянно один сайт выше другого?

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

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

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

факторов, которые могут быть присущи Сайт ставит ссылку на другой сайт по вашему сайту:

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

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

только три уровня глубины.

Фаза 5: Запуск и сопровождение • Удостоверьтесь, что каждая страница нескольких минут на чтение материалов на вашем сайте имеет теги TITLE и теги по этой теме обогатит ваши знания и даст МЕТА-описаний и ключевых слов, а некоторую перспективу.

также теги ALT для всех изображений.

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

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

жением списков «Кто есть кто в мире • При наличии карт ссылок добавьте где- онлайновых брендов», включая первона нибудь на той же странице и текстовое чальные запуски сайтов Amazon.com, навигационное меню. Virtual Vineyards, OnSale, Link Exchan Это всего лишь несколько штрихов из ge, Microsoft, Rodney Dangerfield, AMA, BBC, Kellogg's и Weather Channel. В множества, но они демонстрируют слож г. его сервисы получили награду Tenagra ность вопроса. Самое лучшее, что мож Award For Internet Marketing Excellen но сделать, - пойти на сайт, подобный ce, а журнал Websight причислил его к сайту Дэнни Салливана (Danny Sullivan) 100 наиболее влиятельным людям Сети.

Search Engine Watch (www.searchengine Кроме того, Эрик пишет для ClickZ и watch.com), целиком посвященному Advertising Age.

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

Глава Эксплуатационная поддержка сайта Эксплуатационная поддержка - горючее, которое сохраняет сайт функционирующим. Ваша страте гия анонсирования может заманить посетителей на сайт однажды, а дважды? А как насчет регуляр ного посещения? В недавнем исследовании Forres ter Research Inc. опрошено 8600 семей, имеющих доступ в Интернет, с целью выяснить, почему лю ди повторно возвращаются на веб-сайты (рис. 7.6).

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

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

Эксплуатационная поддержка, однако, не должна быть произвольной. Необходимо иметь план неза медлительных действий и проверок после запуска сайта и продолжающегося, долгосрочного, регу лярного обновления. Хорошо иметь эксплуатаци онный план на 1-2 года. Включите в него меры по Рис. 7.6. Forrester Rest arch Inc. опрошено 8600 семей, имеющих доступ в Интер нет, с целью выяснения, поче му люди повторно возвраща ются на веб-сайты. Диаграм ма отражает системные концепции (www.system-con cepts, com /articles /forres ter.html) Фаза 5: Запуск и сопровождение устранению сбоев, аспекты юзабилити и график об Наблюдайте за своим новлений. Не забудьте о получении отзывов поль сервером зователей и юзабилити-тестировании - сразу пос В случае если вы не можете наб ле запуска сайта и через несколько месяцев. Обрат людать за своим сервером ежед ная связь с пользователями поможет дальнейше невно и круглосуточно, вос му формированию перепроектированного сайта.


пользуйтесь специальными сер висами: Мониторинг сервера ме Оценка возможностей группы нее чем за 10 долларов в месяц сопровождения того стоит, если есть подозрение на сбои сервера, но непонятно, В большинстве случаев команда разработчиков пе- когда они происходят. Один из редает сайт уже имеющейся в компании группе со- сервисов уведомления серверов, провождения. На вопрос разработчиков: «Кто бу- называемый Server Check Pro (через NetMechanic на www.net дет заниматься сопровождением сайта?» клиент mechaniccom/monitor.htm), при нередко с гордостью отвечает: «Чарли из отдела обнаружении проблемы посыла маркетинга немного знает HTML. Он шесть меся ет сообщение на пейджер или по цев публиковал наши пресс-релизы. Мы считаем электронной почте. Его роботы его великолепным работником и планируем пору- проверяют ваш сайт каждые чить ему также заботу о новом сайте». минут. Это очень здорово и не требует больших человеческих Существует простая истина: от личности, ответст усилий.

венной за обновление сайта, требуется достаточно высокий уровень навыков эксплуатационной под держки перепроектированного сайта. Команда веб-разработчиков должна оценить возможности группы сопровождения в соответствии со сложнос тью нового сайта. Для «Чарли из отдела маркетин га» будет явно проблематично сразу взяться за со провождение динамически управляемого сайта или сложной конструкции вложенных фреймов, если он имеет только поверхностные знания Front Page. Либо нужно затратить десятки тысяч дол ларов на обучение Чарли, либо посоветовать кли енту нанять одного-двух специалистов, а Чарли поручить менее техническую работу.

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

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

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

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

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

это имеет смысл с нескольких точек зрения: технической, административной и фи нансовой.

Фаза 5: Запуск и сопровождение 272 Глава Разработка плана эксплуатационной поддержки В первой фазе веб-разработки (фаза 1: Определение проекта) мы рекомендовали, чтобы клиент заполнил эксплуатационный опрос, который поможет согласовать и сформулировать окончательные цели редизайна. Вы использовали собранную информацию, чтобы структурировать перепроектированный сайт с расчетом на его будущий рост в процессе продуманной эксплуатационной поддержки.

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

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

Рис. 7.7. Простая электронная таблица послужит руководством для плановых работ Фаза 5: Запуск и сопровождение 274 Глава Оценка успешности сайта Собирайте отзывы пользо вателей В связи с быстро изменяющейся экономикой Ин тернета и эволюционирующей природой Сети сей Один из лучших способов оце нить успех сайта при запуске - час более важно, чем когда-либо, проследить ус сделать это через обратную пех сайта после его запуска. Главная цель реди связь с пользователями. Обес- зайна сайта — не просто изменить его, но и достичь печьте на своем сайте оператив конкретные бизнес-цели. Эти цели, заявленные в ность и легкость обратной свя креативном брифе, могут включать повышение ис зи, чтобы собирать все коммен пользуемости/трафика, рост онлайновых продаж, тарии, жалобы и одобрения. Ус уменьшение количества обращений заказчиков в тановите заметный индикатор технические службы, повышение популярности кнопку - обратной связи на каж сайта и так далее. Понимание этих целей как ка дой странице. Особенно проси чественно, так и количественно очень важно для те пользователей комментиро определения лучших методов оценки успешности вать новые возможности пере проектированного сайта. Коли- перепроектированного сайта.

чественные данные собрать Часто значимость сайта оценивается по трафику, непросто. Некоторые сайты име а успех измеряется количеством хитов. 2 Продажи, ют расширенные опции получе особенно прямо с веб-сайта, являются еще одним ния обратной связи. Продукт показателем успеха. Но поскольку рекламирова компании OpinionLab (www.opi ние является еще одним источников дохода ком nionlab.com) - OnlineOpinion обеспечивает постраничную паний, становится все более важным понимание рейтинговую систему, которая трафика сайта и хитов страниц, а также демогра позволяет сайтам получать мгно- фии пользовательской базы. Это поможет не толь венную оценку (рис. 7.11). Глав ко обеспечить рекламодателей необходимыми дан ное преимущество здесь в том, ными, чтобы они смогли достичь собственных вы что от пользователя не требует год, но также поможет компаниям понять, какие ся ничего, кроме щелчка мышью.

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

Некоторые компании тратят много денег и време ни, анализируя файлы журналов сервера, в кото рых регистрируется, кто приходит на сайт (и от куда), как долго находится на сайте, какие основ ные маршруты выбирает и где обычно заканчива ет сеанс. Это было бы прекрасной информацией, Рис. 7.11. OnlineOpinion если бы соответствующие данные можно было дос используют adobe.com, товерно собрать со страниц, а страницы отражали netscape.com, dell.com и бы истинные пользовательские регистрационные другие Хит (от англ. hit) - один показ веб-страницы сайта. Примеч. науч. ред.

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

Рис. 7.12. Какие страницы на вашем сайте наиболее по пулярны? Можете ли вы оха рактеризовать поведение и модели пользователей? Эта типовая диаграмма сгенери рована из обычного файла журнала сервера и показыва ет наиболее посещаемые страницы (см. цветную вклейку, стр. 360) Глава Укрепление безопасности сайта Обнаружение хакеров Безопасность, как правило, не входит в круг задач Как узнать, что сайт подвергся внешней команды веб-разработчиков, так как вторжению? Это может быть ужасно: не останется никакого обычно никто в команде не имеет соответствующей сайта или весь ваш текст может квалификации. Однако это может быть задачей быть внезапно заменен мусо- внутренней группы - нравится ей это или нет. В та ром. Это может быть оскорби ком случае желательно иметь в штате специалис тельно: все изображения сайта та по безопасности, чтобы предохранять сайт от могут быть заменены порногра вторжений хакеров и контролировать поврежде фическими картинками (реаль ния в случае нарушения безопасности.

ная история, такое случалось).

Это может быть более тонко и Грустная действительность состоит в том, что ха разрушительно: внезапное, не керов великое множество и они неустанны и агрес объяснимое увеличение или сивны. Для Интернета они являются эквивалентом уменьшение типичного трафика разбойников, которые пачкают краской из баллон может свидетельствовать о втор чиков дома и автомобили, врываются в здания и жении. Чем больше вы наблюда магазины или просто неприятно шумят. А хакеры ете за своим сайтом, тем скорее крадут персональную информацию, вызывают ха заметите, когда что-что идет ос и их почти невозможно поймать. Так или ина неправильно. Оставайтесь осве че, вы теряете доверие пользователей и доходы, домленными!

когда хакеры вынуждают вас выводить сайт из Се ти (рис. 7.13).

В этом разделе мы говорим о безопасности на очень элементарном уровне;

это не должно быть воспри нято как всесторонний обзор с практическими ре Рис. 7.13. В декабре 2000 г. ха кер ворвался в онлайновый магазин The Gap и нанес не мало вреда, вынудив его за крыться на время устране ния проблем Фаза 5: Запуск и сопровождение комендациями по безопасности сайта. Используйте этот раздел, скорее, как пе речень вопросов, над которыми следует подумать.

Резюме фазы Поздравляем! Перепроектированный сайт запущен и перешел от разработки к сопровождению. Если вы - внешняя команда, это момент расставания. Пере дайте сайт и оцените успех проекта. Сработал для вас Базовый процесс? Какие этапы прошли гладко? Где наблюдались сбои? Оцените, откорректируйте Базо вый процесс, чтобы приспособить его к вашей собственной технологии разра ботки, и переходите к следующему проекту. Это будет редизайн? Нет проблем вы обогатились опытом, выполнив этот проект. Вы успешно завершили пять фаз разработки редизайна сайта: «Определение проекта», «Разработка струк туры сайта», «Визуальное оформление и тестирование», «Производство и конт роль качества (QA)» и «Запуск и сопровождение». Не останавливайтесь здесь.

Следующие две главы - глава 8 «Юзабилити-тестирование» и глава 9 «Анализ конкуренции» - описывают чрезвычайно полезные процессы, которые можно добавить к технологии, если позволяют время и ресурсы. Мы настоятельно ре комендуем их.

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

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

Тогда долго не придется снова заниматься редизайном.

Фаза 5: Запуск и сопровождение 280 Учебный пример Food.com ПРЕДЫДУЩИЙ F00D.COM [ПРЕЖНИЙ] подавал себя в цветах и тематике своей маркетинговой кампании и старомодном стиле 1950-х.

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

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

СОВРЕМЕННЫЙ F00D.COM [ПЕРЕПРОЕКТИРОВАННЫЙ] развил ся в продовольственный портал с дополнительными разделами (обеды, кулинария и новости) и новым, простым и ясным имиджем бренда. Цели редизайна были больше ориентированы на аудиторию в отличие от прежнего подхода, сфокусированного на рестораны и управляемого технологией. (2000 г.) Результат: Улучшение юзабилити благодаря ясным указателям и понятным пользовательским маршрутам.

Количество онлайновых заказов возросло.

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

Юзабилити-тестирование Каким образом сайт перепроектируется? Чаще всего группа людей собирается вместе и предпринимает «мозговой штурм»: «На новом сайте нам нужно это»

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

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

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

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

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

Юзабилити-тестирование Для всестороннего и глубокого проникновения в понятие юзабилити самым по дробным источником из существующих является книга Якоба Нильсена (Jakob Nielsen) «Веб-дизайн: книга Якоба Нильсена», пер. с англ., «Символ-плюс», («Designing Web Usability», New Riders, 1999) и его онлайновые статьи (www.use it.com). Мы не вдаемся так глубоко в предмет юзабилити. Мы оставляем теорию в стороне и просто объясняем, как можно встроить юзабилити-тестирование в вашу привычную технологию.

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

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

Глава Якоб Нильсен (Jakob Nielsen) о значении сокращенного юзабилити-тестирования Сейчас ситуация в веб-разработке очень цесса. Мой стандартный совет - все-таки отличается от той, которая была в сере- тестировать, но в сокращенном варианте.

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



Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

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