Большая часть того, что вы читаете об информационной архитектуре и дизайне, предполагает несколько условий: вы создаете проект с нуля, вы свободны менять на экране все, что захотите, и проект не отягощен техническими или политическими кандалами. Ни одно из этих условий не выполняется, если речь идет о проектах по реорганизации веб-сайтов.
Очень скоро после того, как веб-сайт начинает работать, начинается и первый же проект по его реорганизации.
Под проектом реорганизации я понимаю внесение изменений в существующий веб-сайт или веб-приложение. Скорей всего вам не приходится в этом проекте иметь дело с созданием чего-то нового, влекущего за собой технические и организационные проблемы. Проект реорганизации может быть небольшим - например, добавление еще одной ссылки на странице, либо большим - например, реструктуризация всего веб-сайта. Для информационных архитекторов, работающих непосредственно в компании, владеющей веб-сайтом, такого рода проекты могут составлять львиную долю всего объема работ. Но все чаще и чаще (после коллапса Новой Экономики и в связи с отсутствием новых веб-проектов) такими вопросами приходится заниматься и сторонним консультантам.
Большинство проектов реорганизации включают в себя следующие задачи:
Проекты по реорганизации отличаются своей относительной краткосрочностью: большинство из них (за исключением проектов по полной реструктуризации сайта) длится не более двух недель, и очень часто - от одного до двух дней. Как правило требуется быстро оценить ситуацию и принять решение, не говоря уже о действии: быстро разработать прототип, эскиз, или новую карту сайта. Лишь в некоторых проектах вы можете себе позволить поразмышлять и потворить подольше.
Типичная задача проекта реорганизации может выглядеть так: кто-то создал новую функцию или новый материал, и их теперь надо поместить на веб-сайт. Задача информационного архитектора - решить, куда этот новый материал следует поместить, в каком месте какой конкретно страницы.
Начало проекту реорганизации могут положить протоколы посещения или результаты тестов на юзабилити (или вообще здравый смысл). Вы вдруг узнаёте, что сайт был структурирован неправильно, что посетители не могут выполнить нужную им задачу (найти информацию, купить товар и так далее). Задача архитектора - исправить это.
Существует два типа проектов по реорганизации веб-сайтов, которые я символически назвал "атомным" (atomic) и "нейтронным" (neutron). Каждый из типов имеет свои особенности. Начнем пожалуй с первого типа - с "атомного".
Атомные проекты реорганизации (atomic maintenance projects - AMP) - это такие проекты, которые позволяют вам полностью изменить страницы, разделы, приложения сайта и даже весь сайт целиком. "Атомные" проекты как правило требуются в тех случаях, когда новые требования бизнеса требуют от вас полностью переосмыслить весь веб-сайт. Подобно атомному взрыву ваши решения уничтожат все слои веб-сайта - его внешний вид (front end), программную логику (middleware) и базу данных (database). Атомные проекты - это все те же самые обычные веб-проекты, только задача у них не создать новый веб-сайт, а реорганизовать старый. И если вы уговорите свою команду заняться таким проектом, вам проще будет придерживаться своего отработанного цикла дизайна, чем в другом варианте реорганизации.
Например, вам при регистрации требуется запросить у посетителя еще какую-то информацию (скажем, номер телефона). Обычно для этого в форме требуется добавить еще одно поле. Но исследуя форму, куда это поле должно быть добавлено, вы вдруг обнаруживаете, что переделать надо гораздо больше: формат запрашиваемых данных слишком запутан, обязательные для заполнения поля в форме никак не обозначены, а добавление еще одного поля изуродует страницу еще больше.
Такого рода открытие, должен вам сказать, не редкость. Я гарантирую, что вы наткнетесь на кучу подобных улучшений, если критически посмотрите на любую страницу своего сайта. Но вот зато редко, когда удается убедить заказчика сайта или свою команду в том, что при редизайне той или иной страницы потребуется гораздо большее, чем пару нажатий клавиш.
Здесь уже начинается разговор об "объеме работ" (scope creep). И вам необходимо его определить. Иногда изменения приветствуются, потому что они обнаруживают, что что-то было неправильно или неточно сделано, или открывает какие-то новые невидимые ранее возможности. Но будьте готовы и к сопротивлению! Если временной фактор играет важную роль (а когда ж он не играет?) вся команда будет вас просить не поднимать эту проблему и сделать изменение как можно более простым, не таким объемным. И здесь мы переходим к другому типу проектов, которые мы называем "нейтронными".
Если атомные проекты реорганизации уничтожают все и начинают с нуля, нейтронные проекты реорганизации (neutron maintenance projects - NMP) оставляют "строения" (читай - все три слоя проекта) практически нетронутыми. Это наиболее частый случай, потому что, как мы уже видели выше, некоторые проекты, требующие атомной перестройки, вынуждены выполняться в нейтронном режиме. Таким образом, информационному архитектору приходится принимать решение в рамках существующих условий.
И тут то начинаются рифы. Часто архитектору приходится сражаться с решениями, которые были приняты задолго до его привлечения к проекту; с решениями, которые может быть и не нравились вашей команде, но все к ним привыкли. Или с решениями, в которые было вложено столько сил, что уже жалко что-то менять. Или, например, с решениями, которые были приняты под давлением каких-то других сил в компании (отдела информатики, маркетинга или юристов), и эти решения должны остаться неизменными даже в том случае, если они вам не нравятся.
Давайте для примера взглянем на случай с нашей формой. Нам дано задание - у посетителей требовать в форме указать еще и номер телефона. Поскольку номер телефона может быть и международным, вы решаете создать в базе данных поле с длинным текстом. Все просто, правда? Да, но вот тут вы узнаете от администратора БД, что в базе данных уже есть два текстовых поля: одно для международных телефонных номеров, а второе - для местных (речь идет о США). И он не будет менять структуру базы данных, чтобы слить эти два поля вместе. У Java-программистов вдруг не оказывается времени, чтобы написать скрипт, отправляющий одни номера в одно поле, а вторые в другое. А дизайнер вдруг заявляет, что два поля в форме для номера телефона растянут форму по высоте, страница выползет за нижний край экрана, а это противоречит политике компании. Упс.
Очень трудно работать с нейтронными проектами реорганизации в особенности, когда вы уверены, что они должны быть атомными. Но вот, как вы можете с этим совладать.
Вряд ли кому-то придется по душе заниматься проектами реорганизации. В них есть что-то сродни уборке, мытью посуды, то, чем занимаются как бы между делом, когда нет более интересной и крупной работы. Я не буду спорить на эту тему, но могу дать вам несколько советов, которые помогут вам справиться с этим тяжким бременем.
Мыслите в рамках задачи. Перво-наперво вам надо просмотреть требования задачи и выяснить, где именно требуется вносить изменения в проекте. Часто задачи бывают довольно просты: "Нам надо вот в этой анкете запрашивать еще и номер телефона", другие задачи бывают более абстрактными: "нам надо разместить на сайте биографии членов правления компании". Найти ответ на вопрос вам здорово поможет карта сайта или карта приложения. Если ее нет, набросайте простой эскиз. Найдите или создайте то логическое место на сайте, где будут производиться изменения.
Изучите страницу (часть 1). После того, как вы нашли место на сайте, где надо произвести изменение (это будет либо страница, либо ее часть), внимательно изучите страницу. Пройдитесь по всем ссылкам и нажмите все кнопки, что на ней присутствуют. Казалось бы, совет банален, но очень часто оказывается, что некоторые элементы страницы ведут себя вовсе не так, как ожидалось (или как следует). Недавно, например, в одном из нейтронных проектов, я слепо предположил, что подчеркнутые слова на странице - это ссылки на дополнительную контекстную справочную информацию. Оказалось, что это были не ссылки. При наведении на эти элементы на экране появлялся DHTML-слой, в котором выводилось краткое описание элемента. При изучении страницы вы часто будете сталкиваться с подобными вещами, и вы с трудом будет будете удерживать себя от желания превратить нейронный проект в атомный.
Изучите страницу (часть 2). Если у вас есть навыки в технологии (а они должны у вас быть), узнайте, на какой технологии работает веб-сайт. Создается ли он с помощью системы управления контентом (content management system)? Являются ли страницы динамическими? В какой среде создавались страницы (Flash, HTML)? Какой язык используется для программ на сайте (C++, Java)? Постарайтесь заглянуть в исходный текст страниц, если это возможно. Поговорите с разработчиками, которые делали эти страницы. Так вы узнаете, какие рамки накладывает технология на ваши решения по внесению изменений. Вполне возможно, вы обнаружите какие-то скрытые углы еще до того, как начнете планировать изменения.
Помните о подводных камнях. Очень часто оказывается, что в компании существуют какие-то скрытые от вас условия или политические интересы. Они разумеется нигде не будут написаны на бумаге. Просто в компании все об этом знают. В вашем случае лучше всего наладить дружеские отношения с теми работниками компании, кто может помочь вам выяснить эту информацию. Это могут быть члены команды разработчиков и в особенности менеджеры проектов. Они смогут сказать вам например, что президент компании ненавидит слово "корпоративный", или что начальник отдел маркетинга не выносит подчеркнутые ссылки.
Перед битвой осмотритесь. Если вы обнаруживаете серьезную проблему с какой-то страницей, погодите, прежде чем поднимать всех в атаку. Гораздо важнее оценить, каким образом это изменение отразится на пользователе. Взвесьте предполагаемый результат с теми усилиями, которые вам придется потратить для его достижения. Если результат значительно повысит эффективность работы пользователя, а для этого потребуется всего лишь отправить вежливое письмо программисту, без всяких сомнений, рвитесь в бой. Здесь приглашенный консультант имеет преимущество перед собственным работником компании. Работнику компании приходится оценивать свой шаг основываясь, на знаниях о внутренней организации компании, на опыте предыдущих проектов. Приглашенному консультанту же нечего терять. Максимум, что он в самом худшем случае получит, это раздражение тех людей, кто нанял его на работу (или даст ему следующую работу в будущем).
Эскизы и наброски. Если только вы не создаете новую страницу или не склонили компанию на атомную переделку веб-сайта, вам нет необходимости создавать эскиз/набросок существующей страницы. У вас на это уйдет слишком много времени, потому что изменение затронет лишь небольшую часть страницы. Вместо этого, сделайте снимок страницы (screenshot), откройте снимок в Photoshop-е или Illustrator-е, и внесите изменения прямо в изображение. Теперь перенесите это изображение в вашу программу для создания графиков и наложите поверх изображения ваши комментарии и заметки. Подобный набросок разработчикам легче будет понять.
Не забывайте о визуальной стороне дела. В новых проектах, создаваемых с нуля, информационный архитектор пользуется тем преимуществом, что создает сайт еще до того, как созданы визуальные элементы для него. В проектах же по реорганизации сайта особенно в нейтронных проектах, вам часто приходится добавлять что-то уже к существующей странице. Поэтому визуальная сторона дела играет здесь очень важную роль. Одна огромная уродливая кнопка, размещенная где попало, может разрушить весь внешний вид страницы, на создание которого были потрачены огромные силы и время. Возможно я сейчас скажу то, за что специалисты по юзабилити кричат на нас во все горло, но я считаю, что даже уродливая кнопка (пусть даже она правильно работает) - во много раз хуже, чем ее отсутствие.
Несмотря на то, что работа над реорганизацией сайта вряд ли может считаться мечтой любого веб-мастера, она помогает оттачивать навыки в информационной архитектуре. Она помогает вам понять, что будет с вашим решением после того, как оно перейдет в руки разработчиков. Она помогает вам понять, как сайт эволюционирует со временем, а значит при создании новых сайтов вы сможете предугадывать эту эволюцию. Эта работа позволяет вам узнать, какие технические и людские ресурсы влияют на дизайн сайта. Ну и кроме того, вы станете больше ценить работу над обычными проектами.
Информация взята с сайта webmascon.com
Автор: Dan Saffer
Перевод: Александр Качанов
Размер шрифта пусть выбирают сами пользователи
Мелкий текст тиранизирует пользователей чрезвычайно замедляя выполнение поставленной перед ним задачи. У броузера Internet Explorer 4 был прекрасный дизайн, который позволял пользователям менять разме...
Чем ссылка глубже - тем она лучше
Ссылки, которые ведут напрямую к внутренним страницам сайта, улучшают его юзабилити, так как в отличие от простых ссылок, они ведут посетителя непосредственно к цели. Веб-сайты должны использовать глу...
Берегите почтовый ящик вашего пользователя
Электронная почта - эффективное средство работы с клиентами, но излишнее усердие может только повредить. С самого начала давайте понять посетителям, что вы намерены уважительно относиться к их почтовы...
Как привлечь и удержать постоянных посетителей на вашем web-сайте
Электронная почта - эффективное средство работы с клиентами, но излишнее усердие может только повредить. С самого начала давайте понять посетителям, что вы намерены уважительно относиться к их почтовы...
Песня о слоганах: о чем сайт?
Слоганы (taglines) вебсайта должны объяснять, чем занимается компания..