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

Таблица 11.1. Результаты наблюдений в разных подкатегориях

Наблюдение

Заключение

Последствия для архитектуры сайта

Локальная организация и содержимое

Пользователи заявили, что сначала хотят видеть погоду для своего города. (Интервью с пользователями)

Локальная, локальная, локальная.

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

Общая организация и содержимое

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

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

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

Навигация

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

(Интервью с пользователями&контрольные измерения)

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

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

Предметизация и именование

Многие обозначения неточно описывают скрытое за ними содержание. (Контрольные измерения)

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

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

Функции

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

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

Взять Amazon как точку отсчета. Создать такие функции, как «10 самых популярных рассказов о погоде» или «5 покупок, самых популярных у пользователей из Мичигана». Сделать на них ссылки со страниц местной погоды.

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

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

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

Таблица 11.2. Примеры описаний элементов каркаса

Буква

Элементы

Описание

Следствия (из «Полученных уроков»)

А

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

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

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

Буква

Элементы

Описание

Следствия (из «Полученных уроков»)

B

Найти

местную

погоду

(поиск,

карта,

«хлебные

крошки»)

Пользователи могут щелкнуть по ссылке «Browse for local weather» рядом с окном поиска, щелкнуть по карте или ссылкам справа, чтобы попасть в некоторый регион, либо щелкнуть по ссылке «World» и подняться на уровень выше. Это дает пользователям возможность переходить к погоде на всех уровнях. Если есть карта, она не отвлекает внимание от окна поиска - главного метода доступа.

[То же.]

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

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

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

Эта архитектурная диаграмма обращает внимание на частоту возврата на сайт Weather.com. Она утверждает, что более вероятен приход пользователей на Weather.com с тематических веб-сайтов и общих порталов, чем со встроенных программных приложений (например, отображаемого с помощью Java индекса жары в Miami) или с беспроводных устройств (Palm Pilot, сотовых телефонов).


Информационная архитектура



Новости за месяц

  • Август
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс