Статьи (создание, оптимизация и продвижение сайтов)

В моей последней статье для ALA я обратил внимание на следующую проблему:

«Некоторые сайты являются нагромождением недостатков»

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

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

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

Проблема: прыжок не глядя

Во многих проектах я вижу следование приведенному ниже процессу и охотно следую ему сам:

1. Осознание целей
2. Дизайн
3. Разработка шаблонов и таблиц стилей
4. Написание кода
5. Тестирование представления и поведения
6. Публикация

Является ли этот процесс подходящим для вас? Для небольших проектов, разрабатываемых опытными людьми, - это так.

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

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

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

Когда вы должны планировать тщательнее

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

• Широкая/большая аудитория: известные бренды, сайты с национальным или интернациональным (вместо регионального) фокусом, зрелищные продукты, сайты коммунальных услуг.
• Увеличенные потоки: только он-лайновые коммерческие проекты, направления рекламных ссылок, событийные рекламные сайты.
• Ответственные временные шкалы: проекты, в которых ожидания владельца [сайта] не имеют отношения к задачам проекта.
• Сложные или критичные по назначению приложения: финансовые транзакции, временное управление, цепочки поставок или управление покупателями, пользовательские системы управления контентом, системы, включающие генерируемый пользователями контент или расширенная персонализация.
• Большие информационные системы: сайты, предназначенные для публикации тысяч документов.
• Ожидания больших цифр: проекты, владельцы которых верят, что они будут Следующей Большой Штучкой.

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

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

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

Упрощенная оценка проекта

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

Да, именно так.

Шесть слов, которые определяют процесс оценки, учат все школьники мира. В английском языке они называются вопросительными: Кто? Что? Где? Почему? Когда? Как?

Эти вопросы, заданные в процессе создания сайта, могут звучать так:

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

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

Значение создания руководства по поддержке браузеров заранее

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

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

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

В данном случае, - это не игра: сценарии, персоны и ролевые игры

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

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

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

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

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

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

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

Каркасы и модуляризация макета

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

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

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

Альтернатива сценариям: коридорное тестирование юзабилити

Если вы переведете каркасы в обычные страницы, которые только позиционируют элементы макета, вы можете протестировать его на реальных пользователях вместо воображаемых. В защиту этого способа, коллега по WaSP Томас Вандер Вал (Thomas Vander Wal) предлагает следующее умозаключение:

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

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

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

Руководство по стилям: документирование настоящего лица сайта

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

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

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

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

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

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

Каркасы и руководства по стилям не заменяют композиции

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

На самом деле, ничто не может быть так далеко от правды.

Композиции представляют собой:

• Полностью детализированные снимки (snapshots): при всех их преимуществах, каркасы и руководства по стилям требуют квалифицированную аудиторию для осмысления всей их потенции. Композиция же может быть приложена к e-mail, не требуя квалификации для этого, и послана спонсору, даже неквалифицированному, для утверждения.
• Архивирование проектов без потерь: многие магазины, с которыми я работал, создают композиции в виде документов Photoshop, которые используются не только для создания снимков, представляемых спонсорам проекта, но также доставляются производителям сайта. Мощь пользовательского интерфейса Photoshop дает дизайнерам возможность создавать и описывать визуальные аспекты макета сайта, одновременно обеспечивая возможность использования любой фотографии, сгенерированного типа или произведения искусства, составляющих проект. Я мог бы сказать больше, но Adobe не платит мне за эту статью.
• Создается только дизайнером: у каждого члена команды есть своя ответственность и команда, избегающая композиций, лишает дизайнера возможности продемонстрировать [его] возможности в хорошо выполненном проекте. Кроме того, композиция – лучшее средство для оценки качества дизайна при беглом взгляде, что как раз и нужно дизайнеру, чтобы сделать свою работу хорошо.

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

Рассмотренный процесс: свежий взгляд и новые преимущества

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

1. Оценка целей и требований
2. Руководство сценариями
3. Создание каркасов (и определение архитектуры сайта)
4. Создание эскизов, композиций и (если необходимо) прототипов
5. Эскиз руководства по стилям
6. Создание шаблонов и таблиц стилей
7. Написание кода
8. Тест представления и поведения
9. Согласование результатов теста, если возможно
10. Публикация

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

В то время, как дополнительные этапы требуют большего времени, они дают следующие преимущества:

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

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

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

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

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

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

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

В заключение

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

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

Благодарности

Автор хотел бы поблагодарить Steph Troeth и Thomas Vander Wal за их помощь в приведении этой статьи в нужную форму.

(Translated with the permission of A List Apart Magazine and the author.)