Организация сайта с помощью методов информационной архитектуры


Оглавление (нажмите, чтобы открыть):

Информационная архитектура продукта: как сделать понятную карту сайта

Перевод материала соучредителя дизайн-студии пользовательского опыта EightShapes Дэна Брауна.

Информационная архитектура — это практика проектирования виртуальных структур, лежащих в основе цифровых продуктов. Цифровые продукты становятся всё более сложными и узкоспециализированными, поэтому проблемы информационной архитектуры сейчас наиболее актуальны.

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

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

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

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

Обучающая призма

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

Каждая призма сопровождается вопросами:

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

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

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

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

Соответствие концепту

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

Вопросы

  • Есть ли у команды общее понимание концепта, независимо от заголовка?
  • Соответствует ли заголовок концепту?
  • Не перебивает ли уже существующее значение заголовка сам концепт?
  • Как можно протестировать эффективность различных заголовков?

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

Общее название для троллей, драугров и монстров — враги. Это может создать путаницу во время игры, потому что слово «монстры» — это название, которое может описывать все три типа персонажей.

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

Принимая структурные решения, вы устанавливаете правила. Присваивая контенту некую категорию, вы не просто присваиваете её этому конкретному контенту: вы устанавливаете правило для этого и другого схожего с ним контента.


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

Вопросы

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

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

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

Призма отвлечения

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

Вопросы

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

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

Применение призм

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

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

Что это такое?

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

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

  • нотация Дж. Гарретта (применяется для создания информационной архитектуры приложений);
  • нотация Л. Розенфельда и П. Морвиль (применяется для создания информационной архитектуры сайтов).


Один из вариантов удаленного немодерируемого тестирования

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

Легенда к нотации Дж.Гарретта

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

Проектирование информационной архитектуры веб-сайта

Согласно модели элементов опыта взаимодействия ДжессаГарретта на данном этапе рассматриваются два направляющих фактора дальнейшего проектирования:

— концептуальная модель взаимодействия;

Концептуальная модель взаимодействия – это та модель (возможно взятая из реального мира), согласно которой пользователь взаимодействует с веб-сайтом.

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

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

— заинтересованные сотрудники и организации (партнёры, контролирующие органы).

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

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

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

Информационная архитектура, в понимании модели элементов опыта взаимодействия ДжессаГарретта, – это та структура, в которой хранится информация на сайте, в которой её оперирует веб-сайт с целью реализации потребностей пользователей. Стоит отметить, что информационная архитектура – это не в полной мере та структура информации, что видит пользователь, просматривающий страницы веб-сайта, поэтому стоит отличать информационную структуру (архитектуру) от структуры представления информации, проектирование которой производится на следующем уровне.

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

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

— информация оучебной пожарной части,

— новости и объявления,

Информация о партнёре должна включать в себя следующие данные:

— полное название компании с указанием формы собственности,

— контактные данные: юридический адрес, телефон, факс, веб-сайт, электронная почта,

— описание истории взаимодействия с партнёром: сроки взаимодействия, проделанная работа (характер и объём), общая характеристика совместной работы,

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

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

— краткая характеристика мероприятия, включая цель проведения;

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

— даты: дата новости или объявления, сроки актуальности объявления или события, о котором рассказывается в новости;

— содержание объявления или новости: краткое описание сути;

— целевая аудитория, для которой публикуется данная новость или объявление;

— ссылки на сопутствующие теме и сути новости или объявления источники подробной или дополнительной информации.


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

Вывод

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

Заключение по практике

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

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

Список литературы

1. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания. [Электронный ресурс]URL: https://www.rugost.com/index.php?option=com_content&view=article& >

2. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы. [Электронный ресурс]URL:https://www.rugost.com/index.php?option=com_content&view=article& >

3. Гарретт Дж. Веб-дизайн: книга ДжессаГарретта. Элементы опыта взаимодействия». – Пер. с англ. – СПб.: Символ-Плюс, 2008. – 192 с.: ил. ISBN-10: 5-93286-108-8 ISBN-13: 978-5-93286-108-0

4. Договор управления многоквартирным домом ООО «Управляющая компания «Родниковая долина» [электронный ресурс]URL: https://yk-rodnik-dolina.ru/raskritie/dogovor.pdf (дата обращения: 05.05.2014)

5. Исследование WorldWideWebFoundation: Рейтинг развития Интернета в странах мира в 2013 году. [Электронный ресурс] // Центр гуманитарных технологий. URL: https://gtmarket.ru/news/2013/11/25/6418 (дата обращения: 20.04.2014)

6. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. – Пер. с англ. – СПб.: Символ-Плюс, 2009. – 688 с., ил. ISBN 978-5-93286-132-5

7. Купер А. Психбольница в руках пациентов. – Пер. с англ. – СПб.: Символ-Плюс, 2009. – 336 с., ил. ISBN 978-5-93286-168-4

Дата добавления: 2015-11-23 ; просмотров: 669 | Нарушение авторских прав

Информационная архитектура в дизайне сайтов

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

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

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

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

Роль информационной архитектуры в дизайне

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

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

Информационная архитектура в дизайне сайтов

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

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

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

Компоненты информационной архитектуры

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

Мастер Йода рекомендует:  Устроиться работать джавистом быстро и без проблем

Организационные системы

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


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

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

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

Системы маркировки

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

Навигационные системы

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

Поисковые системы

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

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

Секреты юзабилити: разница между информационной архитектурой и навигацией сайта

Краткое резюме: информационная архитектура сайта (Information Architecture, IA) — это информационная основа любого многоуровневого веб-сайта.

Навигация веб сайтов (navigation) — набор элементов пользовательского интерфейса (UI, user interface), позволяющий посетителю найти и получить конкретную информацию на веб-ресурсе, вступить в маркетинговую интеракцию, совершить конверсионное действие.

Этот пост продолжает серию публикаций о юзабилити в блоге SaaS-платформы LPgenerator.

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

Структура навигации сайта зависит от IA — это безусловно, но «информационная архитектура» — гораздо более глобальное понятие, выходящее далеко за рамки просто навигации сайта.

Натаниэль Дэвис (Nathaniel Davis), специалист по оптимизации пользовательского опыта (UX) и проектированию пользовательских интерфейсов, еще в далеком 2011 году выложил в блоге UXmatters концептуальную статью «Основы практического использования информационной архитектуры» (Framing the Practice of Information Architecture), в которой предложил относиться к веб-навигации как видимой надводной части условного айсберга, имя которому — Information Architecture.

Содержание

Что такое информационная архитектура сайта?

Information Architecture любого веб-ресурса включает в себя 2 основных компонента:

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

Информационная архитектура (IA) не является частью пользовательского интерфейса, видимого на экране, — скорее, IA конфигурирует и обуславливает внешний вид и набор опций user interface.

Information Architecture состоит из электронных документов, таблиц, диаграмм, отнюдь не из макетов или прототипов веб-страниц.

Вот блок-схема, наглядно отображающая взаимосвязь между отдельными составляющими контента на ресурсе nngroup.com. Синие узлы представляют информационные объекты 1 уровня, зеленые — второго, желтые — третьего.

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

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

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

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

Для определения архитектуры веб-ресурса проводятся следующие мероприятия:

  • Инвентаризация контента (Content inventory): экспертное исследование сайта, которое проводят, чтобы найти и идентифицировать существующий контент.
  • Аудит контента (Content audit): оценка полезности, точности, тональности подачи и общей эффективности контента.
  • Группировка информации (Information grouping): определение степени клиентоориентированности соотношения «пользователь — контент».
  • Разработка и усовершенствование таксономии контента (Taxonomy development): определение стандартизированной терминологии для классификации и систематизации содержимого веб-ресурса (например, товарные категории для офферов интернет-магазина).
  • Создание описательной информации: определение метаданных, которые могут быть использованы для создания ссылок по теме, списков или других компонентов навигации, способствующих обнаружению необходимой информации, служащей активатором конверсионного действия.


  • Юзабилити пользовательского интерфейса

Определение и описание навигации сайта

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

Типы навигации сайта и ее компоненты:

  • глобальная навигацая (global navigation),
  • локальная навигацая (local navigation),
  • вспомогательная навигацая (utility navigation),
  • фильтры категорий, ценовых границ и т. п. (filters),
  • ссылки по теме (related links),
  • «толстый» футер (fat footer), дублирующий элементы глобальной, локальной и вспомогательной навигации в собственно «подвале» страницы,
  • и т. д.

Примеры навигационных компонентов: 1 — вспомогательная навигация; 2 — глобальная навигация; 3 — указатель местоположения («хлебные крошки», breadcrumb trail; буквально — «путь, помеченный рассыпанными хлебными крошками»); 4 — локальная навигация; 5 — ссылки по теме (в данном случае на статьи и сообщения в блоге); 6 — «толстый» футер.

Перед имплементацией элемента навигации на веб-страницу следует решить несколько вопросов.

Статистические приоритеты: сколько пользователей будут пользоваться этим навигационным элементом. Например, пользователи будут ориентироваться на ресурсе при помощи локальной навигации или предпочтут «привязанные» тематически ссылки?

Размещение: на каких страницах этот элемент должен располагаться? А где именно на макетной сетке: вверху, внизу, слева, справа?

Дизайнерский шаблон: что будет максимально способствовать юзабилити и положительному пользовательскому опыту — табы, выпадающие меню, «мегаменю» и т. д.?

Взаимосвязь между информационной архитектурой и навигацией

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

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

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

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

Если уже в ходе эксплуатации выяснится, что контент раздела превышает этот запас (при том, что 5 и больше уровней — это вполне обычная глубина информационной архитектуры для современных ресурсов типа интернет-магазинов), — то останется 2 выхода:

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

Определитесь с IA, прежде чем проектировать навигацию

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

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

Отметим, что при применении автономных целевых страниц, отличающихся простотой Information Architecture и «неглубокой» структурой при отсутствии глобальной навигации, все выше упомянутые проблемы грамотной иерархической организации контента просто не возникнут.

Информационная архитектура сайта и ее оптимизация

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


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

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

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

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

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

  • Располагайте ссылки непосредственно в теле основного текста, что является показателем, так называемого, логического расположения ссылки, а тексты, содержащие такие ссылки, расцениваются поисковыми системами как более релевантные запросу.
  • Для перехода на определенную внутреннюю страницу воспользуйтесь несколькими ссылками, состоящими из нескольких смежных ключевых слов. Это позволит значительно повысить показатель ранжируемости страниц вашего сайта, отобранных по объединенным ключевым фразам, отвечающим критериям запроса пользователя.
  • Для оформления внутренних ссылок используйте понятные для человека URL («человекопонятные» URL ), что также увеличивает шансы сайта на высокие позиции в процессе ранжирования результатов поиска роботами.
  • Если вы разрабатываете коммерческий проект, то старайтесь чтобы большинство ссылок вело на наиболее экономически выгодные страницы сайта. Там где пользователь может, не совершая какие-либо дополнительные переходы, оформить заказ на товар или воспользоваться определенной услугой.
  • Чем меньше степень вложенности ссылок, тем большую степень важности они получают во время анализа структуры сайта поисковыми системами. Ссылки, находящиеся на главной странице считаются наиболее важными.

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

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

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

Стоит ли проектировать информационную архитектуру?

В проектировании интерфейсов клиенты периодически ставят задачи по созданию «структуры продукта», «информационной архитектуры» или «карты сайта». Мой опыт работы в подобных проектах оставил впечатление хаоса из мнений и неформализованных понятий. Например, вот мнение, которое лежит в основе таких задач вообще: информационная архитектура — это некая абстрактная модель, которую можно спроектировать оптимальным образом и через это получить хороший пользовательский опыт. Действительно ли это так?

Начнём с позиции признанных знатоков о том, что вообще такое информационная архитектура и зачем она нужна. У Nielsen Norman Group есть статья на тему различий между информационной архитектурой и навигацией: https://www.nngroup.com/articles/ia-vs-navigation/. В ней Дженнифер Карделло (Jennifer Cardello) вводит эти два понятия и призывает их не путать. Информационная архитектура (ИА) определяется как номенклатура контента плюс его внутренняя организация. Навигация же — как интерфейсные элементы, которые позволяют найти нужную информацию или функциональность. Дженнифер советует в первую очередь проектировать ИА, а только потом навигацию, чтобы последняя соответствовала возможной сложности контента. В целом, звучит убедительно. Однако попытавшись на практике пользоваться этой моделью, я столкнулся с проблемами. Если номенклатура контента как часть ИА — это довольно очевидно, то его внутренняя организация — вопрос неоднозначный. Как один из видов активности для создания информационной архитектуры Дженнифер упоминает следующее:

  • Группировка информации — выявление человекоориентированных взаимосвязей в контенте.

Как я определю, что найденные взаимосвязи действительно человекоориентированы? А нужно ли искать другие, например, количественные закономерности? И вообще, существуют ли объективно какие-то связи между единицами контента? Не возникают ли они только в сознании пользователя, когда он взаимодействует с продуктом? Задаваясь такими вопросами, я пришёл к выводу, что информационная архитектура в вышеупомянутом представлении — понятние сложное и синтетическое, что заметно уже по двучастности его определения. Вдобавок, меня не покидает мысль, что любая группировка контента — это уже создание навигации, пусть и низкодетализированной. Ведь имеют значение лишь те группы и связи, которые выявит пользователь, а выявить их он может только опираясь на видимую составляющую — навигацию. Когда я пытался абстрагироваться от навигации и просто группировать контент человекоориентировано, результат чаще всего оказывался буквально моделью главного меню продукта. Таким образом, я нахожу полезным не вводить лишних сущностей и говорить лишь о проектировании навигации. А то, что коллегами из NNG называется проектированием информационной архитектуры, в моей модели является предварительной деятельностью, не имеющей самостоятельной ценности.

Мастер Йода рекомендует:  Полезные функции Android

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

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

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

Весь процесс проектирования навигации можно свести к четырём этапам.

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

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

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

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

Достижимость — необходимый критерий работающей навигации. Но чтобы навигация была не только функциональной, но и хорошей, важно обеспечить гладкий пользовательский опыт. Мне известны две помехи на пути к нему. Представьте, что вы знакомитесь с новым, неизвестным ранее продуктом. Вы не понимаете, как он устроен и, вот незадача, нет никаких подсказок. Мимо вас проносятся вереницы экранов. Вам остаётся цепляться за минимально подходящие к ситуации элементы, не понимая продукта в целом. Достижимость сохранена, но всё происходит субъективно неприятно. Это пример отсутствия обозримости продукта. Пользователи чувствуют себя лучше, когда понимают, что продукт обозрим и конечен. Хорошая навигация может им в этом помочь. Теперь представьте другую ситуацию: вы заходите на сайт в поисках товара. Вы переходите по подходящему разделу в главном меню и внезапно попадаете на совершенно другой сайт с новым меню. При этом на странице есть искомый товар, но ваше впечатление испорчено негладкостью. Вы спросите себя что-то вроде «Туда ли я попал?», «Какой в этом смысл?». Это пример отсутствия консистентности навигации. Хорошая навигация не допускает подобных «склеек».

Архитектура веба: основы для начинающих разработчиков


Рассказывает Jonathan Fulton, VP Engineering в StoryblocksCo

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

Пользователь ищет в Google «Strong Beautiful Fog And Sunbeams In The Forest». Первый результат отправляет его на Storyblocks. Пользователь нажимает на ссылку, которая перенаправляет его браузер на страницу с изображением. Тем временем браузер отправляет запрос на DNS-сервер, чтобы установить соединение со Storyblock, и, получив ответ, отправляет запрос на сайт.

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

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

9–10 ноября, Москва, беcплатно

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

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

1. DNS

DNS расшифровывается как «Domain Name System» (система доменных имён). Это базовая технология, которая делает возможной работу интернета. На самом базовом уровне DNS обеспечивает поиск пары из доменного имени и IP-адреса (например, google.com и 85.129.83.120), что позволяет компьютеру отправить запрос на соответствующий сервер. По аналогии с телефонными номерами разница между доменным именем и IP-адресом такая же, как и между вызовом Джону Доу и звонком по номеру 201-867-5309. Для поиска номера Джона нужна телефонная книга, а для поиска IP-адреса домена — DNS. Таким образом, можно считать DNS телефонной книгой интернета.

2. Балансировщик нагрузки

Прежде чем начать обсуждение балансировки нагрузки, нужно сделать шаг назад, чтобы обсудить горизонтальное и вертикальное масштабирование приложений. Что это и в чём разница? Эта тема хорошо объяснена в посте на StackOverflow: «горизонтальное» масштабирование характеризуется добавлением новых машин в пул ресурсов, тогда как «вертикальное» подразумевает, что наращивается мощность (например, увеличивается CPU или RAM) существующей машины.

В веб-разработке проект масштабируется горизонтально как минимум потому, что всё ломается. Серверы падают по непонятным причинам. Сети деградируют. В некоторых ЦОД-ах время от времени отключается свет. Несколько серверов позволит переживать незапланированные отключения без нарушения работы приложения. Другими словами, приложение становится «отказоустойчивым». Горизонтальное масштабирование позволяет минимально связывать разные части проекта (веб-сервер, базу данных и т. д.), потому что каждая из них запускается на разных серверах. Наконец, может наступить такой момент, когда вертикальное масштабирование более невозможно, так как в мире нет достаточно мощного компьютера для выполнения всех вычислений приложения. Поисковая платформа Google является типичным примером, хотя это относится и к компаниям с гораздо меньшими масштабами. Например, Storyblocks обычно использует от 150 до 400 AWS-машин EC2 в любой момент времени. Было бы сложно получить всю эту вычислительную мощность с помощью вертикального масштабирования.

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

Вот и всё. Концептуально балансировщики нагрузки довольно просты и понятны.

3. Серверы веб-приложений

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

Для реализации сервера приложений требуется выбрать конкретный язык (Node.js, Ruby, PHP, Scala, Java, C#, .NET и т. д.) и MVC-фреймворк для этого языка (Express для Node.js, Ruby on Rails, Play для Scala, Laravel для PHP и т. д.).

4. Сервер баз данных

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

Здесь стоит упомянуть SQL и NoSQL.

SQL расшифровывается как «Structured Query Language» (язык структурированных запросов). Он был изобретён в 1970-х годах, чтобы создать стандартный способ запросов к реляционным наборам данных, доступных широкой аудитории. SQL-базы данных хранят данные в таблицах, которые связаны между собой общими ключами. Такие ключи обычно представлены целыми числами.

Рассмотрим типичный пример хранения информации об истории адресов пользователей. Получатся две таблицы — user и user_addresses, — связанные друг с другом идентификатором пользователя (id в таблице user). Их можно увидеть на изображении ниже. Таблицы связаны, потому что столбец user_id в user_addresses является «внешним ключом» в столбце id в таблице users.

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

NoSQL расшифровывается как «не-SQL» и представляет собой более новый набор технологий баз данных. Он был разработан для обработки очень больших объёмов информации, которые могут генерироваться крупномасштабными веб-приложениями. Большинство вариантов SQL плохо масштабируются горизонтально, а масштабироваться вертикально могут только до определённого момента. Если вы ничего не знаете о NoSQL, рекомендуем начать знакомство со следующих статей:

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

5. Кэширование

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

  • Google кэширует результаты поиска для популярных поисковых запросов, таких как «собака» или «Тейлор Свифт», а не ищет их каждый раз заново;
  • Facebook кэширует большую часть данных, которые вы видите при входе в систему, например, списки постов или друзей. Подробнее, о технологии кэширования используемого в Facebook, можно почитать в этой статье на Medium;
  • Storyblocks кэширует HTML-страницы от React, результаты поиска и другое.

Двумя наиболее распространёнными технологиями кэширования являются Redis и Memcache.


6. Очереди задач

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

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

В очередях задач хранятся списки заданий, которые нужно выполнить асинхронно. Всякий раз, когда приложению нужно выполнить какую-то задачу, которая должна выполняться по расписанию или в соответствии с действием пользователя, оно добавляет её в очередь. Проще всего организованы очереди FIFO — «первым пришёл — первым ушёл», но большинство приложений в конечном итоге нуждаются в какой-то системе балансировки очередей.

Например, в Storyblocks очередь заданий используется для выполнения многих скрытых работ, необходимых для поддержания проекта: кодирование видео и фотографий, обработка CSV-файлов для тегов метаданных, агрегирование статистики пользователей, отправка писем с паролями для сброса и т. д. Со временем проект отказался от простой очереди FIFO в пользу приоритетной очереди, чтобы операции с фиксированным временем выполнения, такие как отправка писем о сбросе пароля, были завершены как можно скорее.

Сервера заданий выполняют задания из очереди. Они запрашивают её, чтобы определить, есть ли работа, и если есть, — приступают к выполнению.

7. Полнотекстовый поиск

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

В этом примере три заголовка документов преобразуются в инвертированные индексы, что облегчает поиск по определённому ключевому слову среди документов с этим ключевым словом в заголовке. Обратите внимание, что обычные слова, также называемые стоп-словами («in», «the», «with» и т. д.), обычно не включаются в инвертированный индекс.

В действительности можно выполнять полнотекстовый поиск непосредственно из некоторых баз данных (например, его поддерживает MySQL), но обычно принято запускать отдельную службу, которая вычисляет и сохраняет инвертированные индексы и предоставляет интерфейс для запросов. Самая популярная полнотекстовая поисковая платформа сегодня — Elasticsearch, хотя есть и другие варианты, такие как Sphinx или Apache Solr.

8. Службы

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

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

9. Хранилище данных

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

  1. Приложение отправляет данные в «firehose»-хранилище, которое обеспечивает потоковый интерфейс для поглощения и обработки данных. Как правило, это информация о действиях пользователей. Часто необработанные данные преобразуются или дополняются и передаются в другие «firehose»-хранилища. Наиболее распространённые технологии для этого процесса — AWS Kinesis и Kafka.
  2. Исходные, а также окончательно преобразованные и дополненные данные сохраняются в облачном хранилище. AWS Kinesis предлагает сервис под названием Firehose, который позволяет сохранять необработанные данные в облачном хранилище (S3), которое чрезвычайно просто в настройке.
  3. Преобразованные и дополненные данные загружаются в хранилище данных для анализа. Типичным примером является AWS Redshift, им пользуется большинство стартапов, хотя крупные компании предпочитают решения от Oracle или другие проприетарные технологии хранения. Если наборы данных достаточно велики, то для анализа может потребоваться технология NoSQL MapReduce, например, Hadoop.

На диаграмме не изображён ещё один шаг: загрузка данных из приложения и баз данных различных служб в хранилище. Например, Storyblocks каждую ночь загружает VideoBlocks, AudioBlocks, Storyblocks, службу учётных записей и базы данных портала разработчиков в Redshift. Это даёт аналитикам целостное представление, так как основные бизнес-данные и данные действий пользователей хранятся в одном и том же месте.

Мастер Йода рекомендует:  Основные принципы программирования императивное и декларативное программирование

10. Облачное хранилище

«Облачное хранилище — простой и масштабируемый способ для хранения и обмена данными через интернет». Такое определение дано AWS. Его можно использовать для хранения и доступа к чему угодно, что можно хранить в локальной файловой системе, пользуясь преимуществами RESTful API через HTTP. Решение от Amazon S3 на сегодняшний день является самым популярным облачным хранилищем, и его широко используют в Storyblocks для хранения видео-, фото- и аудиофайлов, CSS- и JavaScript-файлов, данных действий пользователей и многого другого.

11. CDN

CDN расшифровывается как «Content Delivery System» (система доставки контента). Эта технология позволяет намного быстрее, чем с исходного сервера, отправлять статические HTML-, CSS-, JavaScript-файлы и изображения. Она распространяет контент из многих «конечных» серверов по всему миру, чтобы пользователи загружали различные ресурсы из них вместо исходного сервера. Например, на изображении ниже пользователь из Испании запрашивает веб-страницу с сайта, серверы которого находятся в Нью-Йорке, но статические ресурсы для этой страницы загружаются с «конечного» сервера CDN в Англии, предотвращая медленные кросс-атлантические HTTP-запросы.

Для более полного понимания принципов работы современного веба вы можете также ознакомиться с другими нашими материалами:

Что такое информационная архитектура? В общих чертах, о самом важном

Эта сфера знаний пока относительно нова, и находится в стадии развития; следовательно определение информационной архитектуры зависит о того, кто его дает. Вот определение, которое нравится нам:

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

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

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

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

Каким образом хорошо продуманная информационная архитектура сайта может сделать сайт более удобным в использовании?

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

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

  • информационных потребностей посетителей сайта
  • материалов сайта
  • целей и бюджетных ограничений

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

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

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

Проектирование взаимодействия и информационная архитектура

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

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

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

Собственное представление пользователей о поведении созданных нами интерактивных компонентов называется концептуальной моделью. Возьмем, например, элемент контента: что это – место, которое посещает пользователь, или объект, который пользователь получает? На разных сайтах применяются различные подходы. Неважно, будет ли элемент контента местом или объектом, – важно, чтобы сайт вел себя последовательно, а не представлял элемент местом и объектом попеременно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Добавить комментарий