Каким образом будет выглядеть типовая схема работы с web: Основные этапы работы над веб-проектом // Дизайн в цифровой среде

Разное 

Содержание

Структура документа и веб-сайта — Изучение веб-разработки

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

Необходимые знания:Базовое знакомство с HTML, описано в разделе Начало работы с HTML. Форматирование текста в HTML, описано в разделе Основы текста в HTML. Как работают гиперссылки, описано в разделе Создание гиперссылок.
Задача:Изучить, как структурировать документ с помощью семантических тегов и как разработать структуру простого веб-сайта.

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

Заголовок (колонтитул)
Обычно это большая полоса вверху страницы, с крупным заголовком и / или логотипом. Здесь указывается общая информация о веб-сайте, не меняющаяся от страницы к странице.
Навигационное меню
Ссылки на основные разделы сайта; обычно в виде кнопок, ссылок или вкладок. Также как и заголовок, навигация остаётся неизменной на всех страницах сайта — наличие непоследовательной навигации на вашем сайте запутает и разочарует пользователей. Многие веб-дизайнеры считают панель навигации частью заголовка, а не отдельным компонентом, но это не является обязательным требованием; на самом деле, некоторые также утверждают, что их разделение на отдельные компоненты улучшает доступность, поскольку раздельная структура будет понятнее для людей, пользующихся считывателями экрана.
Основное содержимое
Большая область в центре страницы, содержащая, в основном, уникальный контент данной веб-страницы, например видео, которое вы хотите посмотреть, или рассказ, который вы читаете, или карту, которую вы хотите просмотреть, или заголовки новостей и т. д. Это одна из частей сайта, которая определённо будет меняться от страницы к странице!
Боковая панель
Как правило, содержит некоторую второстепенную информацию, ссылки, цитаты, рекламу и т. д. Обычно она относится к содержимому в основном контенте (например, на странице со статьёй, боковая панель может содержать биографию автора или ссылки на связанные статьи), но в некоторых случаях здесь размещают и другие элементы, например, вторичную навигационную систему.
Нижний колонтитул (футер)
Полоса в нижней части страницы, которая обычно содержит уведомления об авторских правах или контактную информацию. Это место для размещения общей информации (например, заголовка), но обычно эта информация не является критичной или вторична для самого веб-сайта. Нижний колонтитул также иногда используется для SEO целей, предоставляя ссылки для быстрого доступа к популярному контенту.

«Типичный веб-сайт» может быть структурирован примерно так:

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

использовать правильный элемент для правильной работы.  

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

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

Для реализации такой семантической разметки HTML предоставляет выделенные теги, которые можно использовать для создания таких разделов, например:

  • Заголовок: <header>.
  • Навигационное меню:
    <nav>.
  • Основное содержимое: <main>, с различными подразделами содержимого, представленными элементами <article>, <section> и <div>.
  • Боковая панель: <aside>, обычно располагается внутри <main>.
  • Нижний колонтитул: <footer>.

Активное обучение: исследование кода для нашего примера

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

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">

    <title>Заголовок моей страницы</title>
    <link href="https://fonts. googleapis.com/css?family=Open+Sans+Condensed:300|Sonsie+One" rel="stylesheet" type="text/css">
    <link rel="stylesheet" href="style.css">

    
    
  </head>

  <body>
    

    <header>
      <h2>Заголовок</h2>
    </header>

    <nav>
      <ul>
        <li><a href="#">Домашняя страница</a></li>
        <li><a href="#">Наша команда</a></li>
        <li><a href="#">Проекты</a></li>
        <li><a href="#">Контакты</a></li>
      </ul>

       

       <form>
         <input type="search" name="q" placeholder="Search query">
         <input type="submit" value="Go!">
       </form>
     </nav>

    
    <main>

      
      <article>
        <h3>Заголовок статьи</h3>

        <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit. Donec a diam lectus. Set sit amet ipsum mauris.
 
 
  Maecenas congue ligula as quam viverra nec consectetur ant hendrerit. Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur.</p>

        <h4>Подраздел</h4>

        <p>Donec ut librero sed accu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipisicing elit. Aenean ut gravida lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor.</p>

        <p>Pelientesque auctor nisi id magna consequat sagittis. Curabitur dapibus, enim sit amet elit pharetra tincidunt feugiat nist imperdiet. Ut convallis libero in urna ultrices accumsan. Donec sed odio eros.</p>

        <h4>Ещё один подраздел</h4>

        <p>Donec viverra mi quis quam pulvinar at malesuada arcu rhoncus. Cum soclis natoque penatibus et manis dis parturient montes, nascetur ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi at sem facilisis semper ac in est.
 
 </p>

        <p>Vivamus fermentum semper porta. Nunc diam velit, adipscing ut tristique vitae sagittis vel odio. Maecenas convallis ullamcorper ultricied. Curabitur ornare, ligula semper consectetur sagittis, nisi diam iaculis velit, is fringille sem nunc vet mi.</p>
      </article>

      
      <aside>
        <h3>Связанные темы</h3>

        <ul>
          <li><a href="#">Мне нравится стоять рядом с берегом моря</a></li>
          <li><a href="#">>Мне нравится стоять рядом с морем</a></li>
          <li><a href="#">Даже на севере Англии</a></li>
          <li><a href="#">Здесь не перестаёт дождь</a></li>
          <li><a href="#">Лаааадно...</a></li>
        </ul>
      </aside>

    </main>

    

    <footer>
      <p>©Авторские права никому не принадлежат, 2050. Все права защищены.

 
 


 </p>
    </footer>

  </body>
</html>

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

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

  • <main> предназначен для содержимого, уникального для этой страницы. Используйте <main> только один раз на странице и размещайте прямо внутри <body>. В идеале он не должен быть вложен в другие элементы.
  • <article> окружает блок связанного содержимого, который имеет смысл сам по себе без остальной части страницы (например, один пост в блоге).
  • <section> подобен <article>, но больше подходит для группирования одной части страницы, которая представляет собой одну часть функциональности (например, мини-карту или набор заголовков статей и сводок). Считается хорошей практикой начинать каждый раздел с заголовка. Также обратите внимание, что в зависимости от контекста вы можете разбить <article> на несколько <section> или, наоборот, <section> на несколько <article>.
  • <aside> содержит контент, который не имеет прямого отношения к основному содержимому, но может содержать дополнительную информацию, косвенно связанную с ним (словарь, биография автора, связанные ссылки и т. д.).
  • <header> представляет собой группу вводного содержимого. Если он дочерний элемент <body>, то он определяет глобальный заголовок веб-страницы, но если он дочерний элемент <article> или <section>, то определяет конкретный заголовок для этого раздела (постарайтесь не путать его с titles и headings). 
  • <nav> содержит основные функции навигации для страницы. Так же часто в нем можно увидеть логотип и / или название сайта или компании. Вторичные ссылки и т. д. не входят в навигацию.
  • <footer> представляет собой группу конечного контента для страницы.

Несемантические обёртки

Иногда вы будете сталкиваться с ситуацией, когда вы не можете найти идеальный семантический элемент, чтобы сгруппировать некоторые элементы вместе или обернуть некоторый контент. Иногда вам просто нужно будет сгруппировать несколько элементов вместе, чтобы применить к ним, как к единой сущности, CSS или JavaScript. Для таких случаев в HTML есть элементы <div> и <span>. Вам следует использовать их с подходящим значением атрибута class или id, чтобы можно было легко получить к ним доступ.

<span> — это строчный несемантический элемент, который стоит использовать только если вы не можете подобрать более подходящий семантический текстовый элемент для обёртывания контента или если не хотите добавлять какие-либо конкретные значения. Например:

<p>Пьяный Король возвратился в свою комнату в 01:00
и всё никак не мог войти в дверь: хмель мешал <span>[Примечание редактора: В этот момент
свет на сцене должен быть приглушён]</span>.</p>

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

<div> — это блочный несемантический элемент, который следует использовать только если вы не можете подобрать более подходящий семантический блочный элемент или если не хотите добавлять какие-либо конкретные значения. Например, представьте виджет корзины в интернет-магазине, который вы можете открыть в любой момент нахождения на сайте:

<div>
  <h3>Корзина</h3>
  <ul>
    <li>
      <p><a href=""><strong>Silver earrings</strong></a>: $99.95.</p>
      <img src="../products/3333-0985/thumb.png" alt="Серебряные серьги">
    </li>
    <li>
      ...
    </li>
  </ul>
  <p>Итого: $237.89</p>
</div>

Ему не подходит <aside>, поскольку это не обязательно относится к основному содержимому страницы (Вы хотите, чтобы его можно было просматривать из любого места). Также не подходит и  <section>, т. к. это не часть основного содержимого страницы. Поэтому <div> подходит в этом случае. Мы включили заголовок в качестве указателя, чтобы помочь пользователям программ чтения с экрана в его поиске.

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

Перенос строки и горизонтальный разделитель

Два элемента, которые вы будете периодически использовать или захотите узнать о них: <br> и <hr>:

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

<p>Жила-была девчушка Нелл,<br>
Любившая писать HTML:<br>
Её семантика ужасна была — <br>
Она и сама прочитать ничего не могла.</p>

Без элемента <br> абзац  разместится в одну длинную линию (как было сказано ранее, HTML игнорирует переносы строк), а с ним в коде — разметка будет выглядеть следующим образом:

Жила-была девчушка Нелл,
Любившая писать HTML:
Её семантика ужасна была —
Она и сама прочитать ничего не могла.

<hr> создаёт горизонтальный разделитель в документе, это означает тематическое изменение текста (например, изменение темы или сцены). Визуально он просто похож на горизонтальную линию. В качестве примера:

<p>Рон был зажат в углу адскими тварями. Он боялся, но твёрдо решил защитить своих друзей, поднял свою волшебную палочку и приготовился к битве, надеясь, что справится со своим несчастьем.</p>
<hr>
<p>Тем временем Гарри сидел дома с раскрытым указом и размышлял о том, когда выйдут новые серии спин-оффов; в это время зачарованное письмо пархнуло в окно и приземлилось у него на коленях. Он прочитал его и подскочил на ноги; он подумал: "Думаю, самое время вернуться к работе".</p>

Будет выглядеть примерно так:

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

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

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

  1. Имейте в виду, что у вас будет несколько элементов, общих для большинства (если не всех) страниц — например, меню навигации и содержимого нижнего колонтитула. Например, для сайта компании хорошая идея разместить контактные данные в нижнем колонтитуле на каждой странице. Составьте список элементов, общих для всех страниц.
  2. Теперь набросайте структуру страниц (можно взять за образец наш простой дизайн, приведённый раннее). Что находится в этих блоках?
  3. Теперь составьте список остальной (уникальной для каждой страницы) информации, которую вы разместите на сайте.
  4. Сгруппируйте информацию по темам. Какие части можно разместить на одной странице? Это похоже на метод Card sorting.
  5. Составьте карту сайта. Обведите каждую страницу рамкой, и продумайте перемещения пользователя между ними. Обычно в центре оказывается главная страница, с которой можно быстро перейти на все остальные. На небольшом сайте большинство страниц помещают в главную навигацию, но не обязательно класть туда все ссылки. Также можете пометить, как выглядят элементы страниц — ссылками, списками, карточками.

Самостоятельная работа: создайте свою собственную карту сайта

Применить наш метод к своему сайту. О чем он будет?

Примечание: Сохраните свой код, он вам ещё понадобится.

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

  • Using HTML sections and outlines: Продвинутый справочник по семантическим элементам и алгоритму выделения разделов (outline algorithm) в HTML5.

Общие архитектуры веб-приложений | Microsoft Docs

  • Чтение занимает 8 мин

В этой статье

«Если вы считаете хорошую архитектуру слишком дорогой, попробуйте использовать плохую». — Брайан Фут (Brian Foote) и Джозеф Йодер (Joseph Yoder)

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

Что собой представляет монолитное приложение?

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

Комплексные приложения

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

Любой создаваемый в Visual Studio или из командной строки проект ASP.NET Core изначально будет представлять собой комплексный монолитный проект. В нем будет заключено все поведение приложения, включая презентацию данных, бизнес-логику и логику доступа к данным. На рис. 5-1 показана файловая структура приложения, состоящего из одного проекта.

Рис. 5-1. Приложение ASP.NET Core, состоящее из одного проекта.

В сценарии с одним проектом разделение задач реализуется с помощью папок. Используемый по умолчанию шаблон включает отдельные папки для обязанностей шаблона MVC (модели, представления и контроллеры), а также дополнительные папки для данных и служб. При такой организации детали презентации данных в максимально возможной степени размещаются в папке представлений (Views), а детали реализации доступа к данным должны быть ограничены классами, содержащимися в папке данных (Data). Бизнес-логика при этом размещается в службах и классах, находящихся в папке моделей (Models).

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

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

Что представляют собой слои?

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

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

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

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

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

Разделение на логические слои широко распространено и помогает упорядочить код приложений предприятия. Сделать это можно несколькими способами.

Примечание

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

Традиционные приложения с N-слойной архитектурой

Общепринятая организация логики приложения по слоям показана на рис. 5-2.

Рис. 5-2. Слои типового приложения.

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

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

На рис. 5-3 показан пример решения, в котором приложение разделено на три проекта (или слоя) в соответствии с определенными обязанностями.

Рис. 5-3. Простое монолитное приложение, состоящее из трех проектов.

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

Рис. 5-4. Простое развертывание веб-приложения Azure

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

Рис. 5-5. Развертывание веб-приложения в службе приложений Azure

Разбиение этого проекта на несколько проектов на основе обязанностей позволяет повысить удобство поддержки приложения.

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

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

Рис. 5-6. Масштабирование плана службы приложений в Azure.

Чистая архитектура

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

Эталонное приложение eShopOnWeb использует подход на основе чистой архитектуры для организации кода в проекты. Вы можете найти шаблон решения, который можно использовать в качестве отправной точки для собственных решений ASP.NET Core в репозитории ardalis/cleanarchitecture на GitHub.

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

Рис. 5-7. Чистая архитектура (многослойное представление)

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

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

Рис. 5-8. Чистая архитектура (горизонтальное представление слоев)

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

На рис. 5-9 показано более подробное представление архитектуры приложения ASP.NET Core, построенного с соблюдением этих рекомендаций.

Рис. 5-9. Схема чистой архитектуры ASP.NET Core.

Поскольку ядро приложения не зависит от инфраструктуры, для этого слоя легко писать автоматические модульные тесты. На рис. 5-10 и 5-11 показано, как эти тесты вписываются в такую архитектуру.

Рис. 5-10. Изолированное модульное тестирование ядра приложения.

Рис. 5-11. Интеграционное тестирование реализаций инфраструктуры с внешними зависимостями.

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

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

Рис. 5-12. Пример архитектуры приложения ASP.NET Core во время выполнения.

Упорядочение кода в рамках чистой архитектуры

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

Ядро приложения

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

Типы ядра приложения
  • Сущности (сохраняемые классы бизнес-модели)
  • интерфейсов,
  • Службы
  • Объекты передачи данных
Инфраструктура

Как правило, проект инфраструктуры включает реализацию доступа к данным. В типовом веб-приложении ASP.NET Core эта реализация включает Entity Framework (EF) DbContext, любые определенные объекты Migration EF Core, а также классы реализации доступа к данным. Наиболее распространенный подход к абстрагированию кода реализации доступа к данным заключается в использовании конструктивного шаблона репозитория.

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

Типы инфраструктуры
  • Типы EF Core (DbContext, Migration)
  • Типы реализации доступа к данным (репозитории)
  • Службы, связанные с инфраструктурой (например, FileLogger или SmtpNotifier)
Уровень пользовательского интерфейса

Слой пользовательского интерфейса в приложении MVC ASP.NET Core выступает в качестве точки входа для приложения. Этот проект должен ссылаться на слой ядра приложения, а его типы должны взаимодействовать с инфраструктурой строго через интерфейсы, определенные в ядре приложения. В слое пользовательского интерфейса не должны разрешаться прямое создание экземпляров для типов слоя инфраструктуры, а также их статические вызовы.

Типы слоев пользовательского интерфейса
  • Контроллеры
  • Фильтры
  • Представления
  • Модели представлений
  • Запуск

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

Примечание

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

Монолитные приложения и контейнеры

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

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

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

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

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

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

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

Монолитные приложения в Microsoft Azure можно развертывать с использованием выделенных виртуальных машин для каждого экземпляра. С помощью масштабируемых наборов виртуальных машин Azure можно легко масштабировать виртуальные машины. Службы приложений Azure также могут выполнять монолитные приложения и легко масштабировать экземпляры, и вам не придется управлять виртуальными машинами. Службы приложений Azure также могут выполнять отдельные экземпляры контейнеров Docker, упрощая развертывание. С помощью Docker вы можете развернуть одну виртуальную машину на узле Docker и выполнять на ней несколько экземпляров. Для управления масштабированием можно использовать систему балансировки Azure, как показано на рис. 5-14.

Развертыванием на различных узлах можно управлять с помощью традиционных методов развертывания. Узлами Docker можно управлять с помощью вводимых вручную команд вида docker run или автоматизированно, например с помощью конвейеров непрерывной поставки (CD).

Развертывание монолитного приложения в контейнере

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

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

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

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

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

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

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

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

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

Гораздо более простой пример приложения eShopOnWeb поддерживает использование одного монолитного контейнера. Приложение включает одно веб-приложение с традиционными представлениями MVC, веб-API и Razor Pages. Это приложение может запускаться из корня решения с помощью команд docker-compose build и docker-compose up. Эта команда настраивает контейнер для веб-экземпляра с помощью Dockerfile из корневого каталога веб-проекта и выполняет контейнер в указанном порте. Вы можете скачать исходный код этого приложения из GitHub и запустить его в локальной системе. Даже такое монолитное приложение выигрывает от развертывания в контейнерной среде.

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

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

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

Поддержка Docker

Проект eShopOnWeb работает в .NET. Поэтому его можно запускать как в контейнерах Linux, так и в контейнерах Windows. Обратите внимание на то, что для развертывания Docker необходимо использовать тот же тип узла для SQL Server. Контейнеры на основе Linux требуют меньше ресурсов и более предпочтительны.

Вы можете использовать Visual Studio 2017, чтобы добавить поддержку Docker в существующее приложение, щелкнув проект в обозревателе решений правой кнопкой мыши и выбрав Добавить > Поддержка Docker. Таким образом вы добавите необходимые файлы и внесете изменения в проект для их использования. В текущем примере eShopOnWeb эти файлы уже есть.

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

version: '3'

services:
  eshopwebmvc:
    image: eshopwebmvc
    build:
      context: .
      dockerfile: src/Web/Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "5106:5106"

networks:
  default:
    external:
      name: nat

Файл docker-compose.yml ссылается на Dockerfile в проекте Web. С помощью Dockerfile можно указать, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. Dockerfile``Web:

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /app

COPY *.sln .
COPY . .
WORKDIR /app/src/Web
RUN dotnet restore

RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS runtime
WORKDIR /app
COPY --from=build /app/src/Web/out ./

ENTRYPOINT ["dotnet", "Web.dll"]

Устранение неполадок с Docker

После запуска контейнерное приложение продолжает работать, пока его не остановят. Используйте команду docker ps, чтобы посмотреть, какие контейнеры выполняются. Вы можете остановить выполняющийся контейнер с помощью команды docker stop и идентификатора контейнера.

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

Если вы хотите добавить поддержку Docker в приложение с помощью Visual Studio, убедитесь, что Docker Desktop при этом запущен. Если при запуске мастера средство Docker Desktop не выполняется, мастер будет работать неправильно. Кроме того, мастер проверяет выбранные контейнеры, чтобы правильно реализовать поддержку Docker. Чтобы добавить поддержку контейнеров Windows, необходимо запускать мастер при запущенном инструменте Docker Desktop с настроенными контейнерами Windows. Чтобы добавить поддержку контейнеров Linux, запускайте мастер при запущенном инструменте Docker с настроенными контейнерами Linux.

Ссылки — общие архитектуры веб-приложений

Веб-клиент

Веб-клиент — это одно из клиентских приложений системы «1С:Предприятие 8». В отличие от «привычных» клиентских приложений (толстого клиента и тонкого клиента), его не нужно предварительно устанавливать на компьютер пользователя. У веб-клиента нет исполняемого файла. Веб-клиента вы не найдете ни в меню, ни среди исполняемых файлов. Потому он и веб-клиент, что ему для начала работы не нужно иметь никаких файлов на компьютере пользователя.

Веб-клиент, в отличие от толстого и тонкого клиентов, исполняется не в среде операционной системы компьютера, а в среде интернет-браузера (Windows Internet Explorer, Mozilla Firefox, Google Chrome или Safari). Поэтому любому пользователю достаточно всего лишь запустить свой браузер, ввести адрес веб-сервера, на котором опубликована информационная база, — и веб-клиент сам «приедет» к нему на компьютер и начнет исполняться.

Веб-клиент использует технологии DHTML и HTTPRequest. При работе веб-клиента клиентские модули, разработанные в конфигурации, компилируются автоматически из встроенного языка «1С:Предприятия 8» и непосредственно исполняются на стороне веб-клиента.

Таким образом, независимо от клиентского приложения (толстый, тонкий, веб-клиент), вся разработка прикладного решения ведется полностью в конфигураторе 1С:Предприятия, серверный и клиентский код пишется на встроенном языке «1С:Предприятия 8».

Работа в интернет-браузере без установки системы на компьютер пользователя

Для работы в режиме веб-клиента требуется веб-сервер, настроенный на работу с «1С:Предприятием 8». Браузер клиента взаимодействует с веб-сервером по протоколу HTTP или HTTPS. Веб-сервер, в свою очередь, взаимодействует с «1С:Предприятием 8» в файловом или клиент-серверном варианте работы.

В качестве веб-сервера используется Apache или IIS.

Progressive Web Apps

В веб-клиенте реализована поддержка технологии PWA (Progressive Web Apps). Эта технология поддерживается браузерами (как настольными, так и мобильными). Она позволяет создавать веб-приложения, которые выглядят как нативные приложения и работают почти так же быстро, как нативные приложения.

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

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

Аутентификация OpenID Connect

В веб-клиенте реализована поддержка провайдеров OpenID Connect. Для аутентификации в «1С:Предприятии 8», дополнительно к имеющимся способам, пользователи могут использовать свои учётные данные на других сайтах, поддерживающих OpenID Connect аутентификацию.

Веб-клиент на мобильных устройствах

Реализована ограниченная поддержка работы веб-клиента на мобильных устройствах — в браузере Google Chrome под ОС Android и в браузере Safari на iPhone/iPad. Доступны только основные функции веб-клиента.


Правильная структура веб сайта под SEO: примеры, виды и 15+ рекомендации по разработке структуры

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

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

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

Что такое структура сайта и в чем ее важность

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

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

Хорошая структура = эффективное СЕО-продвижение

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

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

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

Хорошая структура = доверие поисковой системы к сайту

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

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

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

Типы структур сайтов: уровни иерархии и классификация

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

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

  1. Главная;
  2. Товары для кухни;
  3. Мелкая бытовая техника;
  4. Электрические чайники;
  5. Товарная карточка.

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

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

Алфавитная организация структуры

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

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

Хронологическая организация

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

Географическая организация

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

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

Тематическая организация

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

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

Организация, ориентированная на целевую аудиторию

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

Менее популярные организации

Более редкие и менее встречаемые организации структуры при работе с SEO сайтами — основанная по задачам и метафорическая.

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

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

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

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

Гибридная организация

Представляет собой комбинацию из разных способов организации информации на одном сайте.

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

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

Основные требования к структуре сайта

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

3 правила разработки правильной и удобной для пользователя структуры

  1. Структура должна быть максимально понятной посетителю. Градация всех товаров по их предназначению должна быть интуитивно доступна. Предположим, потенциальный клиент посетил ваш интернет-магазин одежды для всей семьи с целью покупки куртки для своего ребенка. Если схема ресурса не предусматривает категорию «Детская одежда», то клиент попросту потеряется между другими категориями, например «Одежда» и «Товары для детей», где будут размещены сопутствующая продукция по уходу за ребенком;
  2. Вложенность страниц каталога должна быть максимально оптимизирована и логична. Не создавайте дополнительные мини-каталоги, запутав посетителя и заставив его выполнить с десяток кликов для поиска необходимого. Логическая и правильная оптимизация — залог успеха;
  3. Простая навигация. Разместите меню, навигационные цепочки (хлебные крошки) и вспомогательные блоки (например, сопутствующие товары). Это поможет пользователю сориентироваться в ассортименте, а также быстро переходить с одной страницы на другую.

Требования разработки схемы сайта для поисковых систем

Мы уже знаем, что логичная и простая структура быстрее и легче просматривается поисковым алгоритмом, что приводит к хорошим результатам с точки зрения индексации. Чтобы страница проще ранжировалась и выходила в ТОП по определенным запросам, необходимо проработать ЧПУ. Человекопонятные URL помогут пользователю сориентироваться на странице.

Пример неправильного урла: mysite.com.ua/index.php?docid=17_88UaWp8hXtvMnFA-4P-e8Vj8MQItEPbk&ln=ru

Пример правильного: mysite.com.ua/catalog/divany/uglovoy

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

Проектирование структуры сайта в зависимости от вида и целей

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

Структура сайта визитки

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

Структура коммерческого сайта компании

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

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

Структура сайта интернет магазина

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

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

Структура информационного портала

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

Как сделать структуру сайта

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

Семантическое проектирование сайта

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

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

Обобщение категорий

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

Расставление приоритетов в навигации

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

Раскрытие потребностей для разных групп ЦА

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

Это поможет потребителю быстрее найти информацию в зависимости от его запросов.

Добавление возможности масштабирования

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

Распространенные ошибки структуры web сайта, которые не следует делать

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

1. Детальная разбивка ассортимента и, как следствие, большая вложенность страниц на ресурсе

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

2. Неточное или непонятное название категорий

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

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

3. Использование в названии категории сразу несколько слов-синонимов одного термина

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

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

4. Использование в категории отдельных групп товаров с указанием бренда

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

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

5. Ограниченное количество фильтров и их параметров

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

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

6. Дублирование товаров и категорий

Желательно, чтобы URL товара не зависела от категории, в которой расположен данный товар. А товары, которые могут быть сразу в нескольких категориях очень много. Например, есть категория «плойки», а есть «утюжки», но есть товар «плойка-утюжок» и кто-то подобное ищет в «плойках», а кто-то, напротив, в «утюжках» и надо показывать товар и там, и там. И то же самое с категориями, если их ищут в двух разных разделах, то показываем их в меню и там, и там, а по URL это все должно находиться только по одному адресу, чтобы не создавать дубликатов для поисковых систем. Это является одной из серьезных ошибок при разработке коммерческого сайта. Хотите узнать больше об этом? Читайте подробнее о распространенных 20 ошибках новичков при создании сайта.

7. Недостаточная классификация товаров

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

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

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

Так какая же ты, правильная продающая структура сайта?

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

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

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

Следующий проект:Правильные сочетания и подбор цвета для сайта: рекомендации для новичковПредыдущий проект:Какой домен выбрать для сайта? Правила по выбору доменного имени сайта для развития бизнеса в Интернет

как масштабироваться на постоянно растущем проекте

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

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

Рост проекта и сопутствующие сложности

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

Вот основные вызовы, с которыми может столкнуться агентство на таком проекте:

  • Проблема масштабирования — перестроение структуры команды при росте объёмов.
  • Необходимость понимания продукта и бизнес-задач — без сильной продуктовой аналитики невозможно эффективно работать на крупном проекте.
  • Сложная программная и серверная архитектура — рука об руку с ростом объёмов выработки по проекту идёт и рост посещаемости, ведущий к усложнению архитектуры и необходимости использовать highload-решения.
  • Высокие требования к качеству.
  • Необходимость обеспечивать бесперебойную работу 24×7 и высокая скорость реакции на инциденты в том числе в неурочное время.
  • Высокая степень ответственности за остановку продаж.
  • Мониторинг и контроль бизнес-показателей.

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

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

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

Роли на небольшом проекте и зачем нужно масштабирование

Схема ролей выглядит в общем случае следующим образом: 

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

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

На проекте две ключевых роли: руководитель проекта (РП) и тимлид.

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

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

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

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

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

Структура менеджерской команды

Одна из самых сложных для масштабирования единиц — РП.

По мере роста проекта имеет смысл внедрять классическую парную схему account manager — project manager, когда один РП берёт на себя клиентский сервис, включая продуктовые вопросы, а второй организует процесс производства внутри компании. 

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

Поэтому идеальная с точки зрения дальнейшей масштабируемости схема выглядит следующим образом:

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

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

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

Каждый РП в команде отвечает за свой «кусок» проекта, беря под контроль все текущие задачи по ряду продуктов (в идеале это должны быть смежные области). В зону его ответственности входят сроки и качество всех задач в рамках развития подотчётных продуктов.

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

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

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

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

  • За 10 рабочих дней до начала месяца каждый РП сам выделяет от трех до пяти своих ключевых задач на следующий месяц.
  • За 5 рабочих дней до начала месяца GH выделяет из них по две—четыре для каждого менеджера и выставляет сроки: 1 — клиентский срок (50%), 2 — внутренний срок (100%) и вносит в таблицу.

Условия получения бонусов (по итогам месяца):

  • Менеджер получает 100% бонусов, если все его задачи выполнены во внутренний срок.
  • Менеджер получает 50% бонусов, если хотя бы одна его задача уехала из внутреннего срока, но была выполнена в клиентский срок.
  • Ни один из менеджеров не получает бонусы, если хотя бы одна задача из общего списка не была выполнена в клиентский срок.

Данная схема позволяет всей менеджерской команде работать эффективно и корректно управлять ожиданиями клиента.

Тестировать не только конечный код — QA-команда

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

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

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

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

Тимлиды — эффективность или взаимозаменяемость?

Уже при вводе второго тимлида на проект сразу же всплывает вопрос — какую схему распределения обязанностей применить?

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

Оба варианта хороши с точки зрения утилизации ресурсов, но несут большие риски с точки зрения взаимозаменяемости. 

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

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

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

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

Отдельно имеет смысл подключать тимлидов на отчуждаемые деятельности: на продукт, архитектурно оторванный от основной части проекта, или деятельность, которой можно заниматься параллельно. Например, вполне можно выделить отдельно тимлида вёрстки, который полностью возьмёт на себя контроль всех фронтовых работ; отдельно выделяются роли тимлида QA, проектирования, аналитики.

Взаимозаменяемость членов команды

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

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

Дизайн-система 

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

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

Использование такого инструментария требует большой траты ресурсов на разработку и поддержку. Также зачастую много моральных сил уходит на объяснения клиенту, почему необходимо придерживаться этой системы и по какой причине предложения вроде «Добавьте на этой странице новую зелёную кнопочку, как на сайте N, которая так красиво выглядит» будут отвергнуты. 

Документация

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

Документацию на проектах имеет смысл разделять на 4 типа:

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

Вся документация должна быть агрегирована в базе знаний онлайн (Wiki) и поддерживаться в актуальном виде.

GIT

Для ускорения подключения новых разработчиков с других проектов компании внедряется стандартный подход к GitFlow. В AGIMA мы используем подход «работа с двумя основными ветками». 

Вместо использования ветки master применяются две основные ветки истории проекта: master для релизов и develop для слияния разрабатываемого функционала из веток feature.

Workflow

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

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

В workflow непременно должен быть вовлечён и клиент — в одностороннем порядке такая система работать не может.

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

Поддержание осведомлённости членов команды

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

1. Продуктовые встречи

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

2. Инфраструктурные срезы

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

3. Ретроспективы и планирование работ

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

Выводы

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

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

Как построить успешное сотрудничество дизайнера и веб-разработчика

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

В статье я рассмотрю:

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

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

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

ОСНОВЫ ЭФФЕКТИВНОГО СОТРУДНИЧЕСТВА

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

Уважение

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

Рабочие отношения

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

Раннее вовлечение в проект

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

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

Гибкость разработки

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

Понимание

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

Открытая коммуникация

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

Введение в контекст

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

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

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

УСПЕШНАЯ ПЕРЕДАЧА ДИЗАЙНА В РАЗРАБОТКУ

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

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

РУКОВОДСТВО ПО СТИЛЮ ИНТЕРФЕЙСА (UI STYLE GUIDE)

Составляя для команды «шпаргалку» по построению дизайна по определенным правилам, важно обращать внимание на то, чтобы документация дизайн-компонентов касалась только важных аспектов. Это должен быть актуальный и понятный каждому члену команды инструмент, который можно использовать быстро и легко. Основные части обычно содержат: схемы типографики, палитру цветов, дополнительные компоненты пользовательского интерфейса и так называемые “do’s and don’ts” (примеры правильных и неправильных элементов интерфейса и их соответствующего применения).

ДИЗАЙН-СИСТЕМА

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

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

Стандарты наименования

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

Экономия времени на работу с вопросами и предложениями

Чтобы к дизайнеру было меньше вопросов и его не отвлекали слишком часто, стоит выделить отдельное время на вопросы, обзоры, другие внутренние уточнения и согласовать его с разработчиком. Интерактивные прототипы нужны не во всех проектах и на них не всегда есть время. Однако они экономят много времени на разработку — с ними специалист работает быстрее, чем со статическими прототипами. Также нередко сайты (особенно landing pages) содержат анимационные эффекты. Для удобства и более четкого понимания не помешает поделиться с разработчиком ссылками на платформы, где реализовано что-то подобное.

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

Готовый набор элементов интерфейса (UI Kit)

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

Запланированная встреча для передачи дизайна

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

Вопросы к дизайнеру могут быть такие:

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

Ключевые принципы передачи дизайна в разработку

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

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

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

НЕЛОВКИЕ КЕЙСЫ ИЗ ЖИЗНИ ВЕБ-РАЗРАБОТЧИКА ПРИ РАБОТЕ С ГОТОВЫМ ДИЗАЙНОМ

Адаптивный и резиновый дизайны

Если вы разрабатываете дизайн и продукт для нескольких расширений, то можете на финальном этапе обнаружить скачки во время изменения размеров экрана. На то есть много причин, но разработчик должен уточнить, какой подход ему выбрать к созданию верстки продукта с хорошим адаптивом — от самого маленького до самого большого экрана (mobile first) или наоборот (desktop first). Кроме этого, существует элементный подход (element first), когда мы фокусируемся не на расширении, а на элементах дизайна и том, как они будут выглядеть на экранах разного размера.

Подробнее о плюсах и минусах таких подходов читайте здесь.

Состояние наведения

Состояние hover показывают на кнопках, однако нередко забывают показать на отдельных элементах дизайна. Это могут быть цитаты и другие поля текста или картинок. Лучше всего демонстрировать все состояния динамических интерактивных элементов. И не забывайте о скорости и виде перехода (transition) из одного состояния в другое.

Индикатор фокуса

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

Организация слоев

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

Ширина контента

Иногда ширина текстовых полей, заголовков и т. п. должна быть разной для разных размеров экрана. Такие размеры следует указывать отдельно, отмечая максимальную и минимальную ширину для этого контента. Если разработчик будет сразу знать о разной ширине некоторых элементов контента, то будет использовать правильные инструменты. Например, есть такие варианты grid-template-columns.

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

Темная тема

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

Фиксация

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

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

Нетипичные случаи

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

Мультиязычность

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

Состояния полей форм

Очевидно, что в дизайне нужно показывать все состояния полей форм. Однако, как показывает практика, многие об этом забывают. Главное — помнить о всех видах состояний. Самые популярные: normal, errors, mandatory, focused, typing, disabled.

Анимация

Не стоит недооценивать анимацию и микровзаимодействия. Они не только персонализируют продукт с помощью финальных штрихов, но и улучшают UX. Удобный инструмент для дизайнеров — Lottie от Airbnb. Он позволяет работать с анимацией в AfterEffects, экспортировать в .json и главное — просматривать готовый результат перед передачей дизайна в разработку.

ЗАКЛЮЧЕНИЕ

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

Вопросы и ответы по Amazon EC2 – Amazon Web Services

Вопрос. Что такое спотовый инстанс?

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

Вопрос. Чем отличается спотовый инстанс от инстанса по требованию или зарезервированного инстанса?

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

Дополнительную информацию о спотовых инстансах см. здесь.

Вопрос. Как приобрести и запустить спотовый инстанс?

Спотовые инстансы можно запускать с помощью тех же инструментов, которые в настоящее время используются для запуска инстансов, включая Консоль управления AWS, группы Auto Scaling, команду запуска инстансов и спотовые группы. Кроме того, запуск спотовых инстансов поддерживают многие сервисы AWS, например EMR, ECS, Datapipeline, Cloudformation и Batch.

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

Дополнительную информацию о запросе спотовых инстансов см. здесь.

Вопрос. Сколько спотовых инстансов может запросить пользователь?

Количество запрашиваемых спотовых инстансов должно быть в рамках лимита инстансов, установленного для каждого региона. Следует отметить, что для новых клиентов AWS установленное ограничение может иметь меньшее значение. Дополнительную информацию о лимитах для спотовых инстансов см. в Руководстве пользователя Amazon EC2.

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

Вопрос. Какая плата будет начисляться за использование спотовых инстансов?

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

Вопрос. Что такое пул спотовых ресурсов?

Пул спотовых ресурсов – это набор неиспользуемых инстансов EC2 с тем же типом инстанса, операционной системой, зоной доступности и сетевой платформой (EC2-Classic или EC2-VPC). Цены разных пулов спотовых ресурсов могут отличаться в зависимости от предложения и спроса.

Вопрос. Какие существуют рекомендации по использованию спотовых инстансов?

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

Вопрос. Как узнать состояние запроса на спотовые инстансы?

Состояние запроса на спотовые инстансы можно узнать с помощью кода состояния запроса на спотовые инстансы и соответствующего сообщения. Доступ к информации о состоянии запроса на спотовые инстансы можно получить на странице спотовых инстансов консоли EC2 в Консоли управления AWS, API и интерфейсе командной строки. Дополнительную информацию см. в Руководстве по Amazon EC2 для разработчиков.

Вопрос. Есть ли возможность заказывать спотовые инстансы любых семейств и размеров в любых регионах?

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

Вопрос. Какие операционные системы доступны на спотовых инстансах?

В список доступных систем входят Linux/UNIX, Windows Server и Red Hat Enterprise Linux (RHEL). Windows Server с SQL Server в настоящее время недоступна.

Вопрос. Можно ли использовать спотовый инстанс с платным AMI для стороннего программного обеспечения (например, программных пакетов IBM)?

В настоящий момент нет.

Вопрос. Могу ли я остановить запущенные мной спотовые инстансы?

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

Вопрос. Как остановить спотовые инстансы?

Можно остановить свои спотовые инстансы, вызвав API StopInstances и предоставив идентификаторы для спотовых инстансов. Эти действия похожи на те, которые предпринимаются для остановки инстансов по требованию. Перевести инстанс в спящий режим можно в Консоли управления AWS, указав нужный инстанс, а затем выбрав «Actions > Instance State > Stop – Hibernate».

Вопрос. Как запустить остановленные спотовые инстансы?

Можно запустить остановленные спотовые инстансы, вызвав API StartInstances и предоставив идентификаторы для спотовых инстансов. Эти действия похожи на те, которые предпринимаются для запуска инстансов по требованию. Можно возобновить работу инстанса в Консоли управления AWS, указав нужный инстанс, а затем выбрав «Actions > Instance State > Start».

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

Вопрос. Как узнать, остановил ли я свой спотовый инстанс или его работа была прервана?

Узнать, был спотовый инстанс остановлен или все же его работа была прервана, можно с помощью кода состояния запроса на спотовые инстансы. Информация отображается как состояние запроса на спотовые инстансы на соответствующей странице в Консоли управления AWS или посредством ввода команды DescribeSpotInstanceRequests API в поле «status-code».

Если код состояния запроса на спотовые инстансы – «instance-stopped-by-user», это означает, что вы остановили свой спотовый инстанс.

Вопрос. Как будет начисляться плата, если работа моего спотового инстанса остановлена или прервана?

Если работа спотового инстанса будет прервана или остановлена Amazon EC2 во время первого часа работы инстанса, это время его использования оплачиваться не будет. Однако если вы завершите или остановите работу спотового инстанса самостоятельно, будет начислена плата с округлением до ближайшей секунды. Если работа спотового инстанса будет прервана или остановлена Amazon EC2 в любое время в течение любого последующего часа работы инстанса, будет начислена плата за фактическое время использования с округлением до ближайшей секунды. Если вы используете ОС Windows или Red Hat Enterprise Linux (RHEL) и при этом завершите или остановите работу спотового инстанса самостоятельно, будет начислена плата за полный час.

Вопрос. Когда работа моего спотового инстанса может быть прервана?

За последние 3 месяца 92 % прерываний работы спотовых инстансов происходили на стороне клиентов, которые вручную останавливали работу инстансов после завершения работы приложений.

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

Вопрос. Что произойдет со спотовым инстансом, когда его работа будет прервана?

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

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

Вопрос. В чем разница между остановкой и спящим режимом?

При переходе инстанса в спящий режим данные оперативной памяти сохраняются. В случае остановки инстанс отключается, а данные оперативной памяти удаляются.

В обоих случаях данные из корневого тома EBS и любых подключенных томов данных EBS сохраняются. Неизменным остается как частный IP‑адрес, так и эластичный IP‑адрес (если такой используется). Поведение на сетевом уровне будет аналогично тому, что описано для рабочего процесса EC2, связанного с остановкой‑запуском. Остановка и спящий режим доступны только для инстансов на базе Amazon EBS. Локальное хранилище инстансов не сохраняется.

Вопрос. Что делать, если объем корневого тома EBS недостаточен для сохранения состояния памяти (ОЗУ) для спящего режима?

Для записи данных из памяти на корневом томе EBS должно быть достаточно места. Если места на корневом томе EBS недостаточно, попытка перехода в спящий режим завершится ошибкой, при этом инстанс будет выключен. Убедитесь, что том EBS имеет достаточный объем для сохранения данных памяти, прежде чем выбирать спящий режим.

Вопрос. В чем преимущество перевода инстанса в спящий режим при прерывании его работы?

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

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

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

Вопрос. Будет ли взиматься плата за использование спящего режима для спотовых инстансов?

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

Вопрос. Можно ли возобновить работу инстанса, находящегося в спящем режиме?

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

Вопрос. Какие инстансы и операционные системы поддерживают спящий режим?

В настоящее время спящий режим для спотовых инстансов поддерживается для образов Amazon Linux AMI и операционных систем Ubuntu и Microsoft Windows, работающих на любом типе инстансов семейств C3, C4, C5, M4, M5, R3 и R4 с объемом памяти (RAM) до 100 ГиБ.

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

Вопрос. Как начисляется плата, если спотовая цена изменяется во время работы инстанса?

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

Вопрос. Где получить информацию об истории использования спотовых инстансов и платежах?

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

Вопрос. Будет ли прерываться работа блоков спотовых инстансов (спотовых инстансов фиксированной продолжительности)?

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

Вопрос. Что такое спотовая группа?

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

Вопрос. Взимается ли дополнительная плата за запросы на спотовые группы?

Нет, дополнительная плата за запросы на спотовые группы не взимается.

Вопрос. Какие существуют ограничения по запросам на спотовые группы?

Ознакомьтесь с разделом Ограничения для спотовых групп Руководства пользователя Amazon EC2, чтобы узнать о существующих ограничениях по запросам на спотовые группы.

Вопрос. Что происходит, если запрос на спотовую группу пытается запустить спотовые инстансы и при этом превышается ограничение на спотовые запросы для данного региона?

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

Вопрос. Есть ли гарантия, что запросы на спотовые группы будут выполнены?

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

Вопрос. Можно ли подать запрос на спотовую группу в нескольких зонах доступности?

Да. Ознакомьтесь с разделом Примеры спотовых групп Руководства пользователя Amazon EC2, чтобы узнать, как подать запрос на спотовую группу в нескольких зонах доступности.

Вопрос. Можно ли подать запрос на спотовую группу в нескольких регионах?

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

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

API RequestSpotFleet позволяет воспользоваться одной из трех стратегий распределения: capacity‑optimized, lowestPrice и diversified. Стратегия распределения с оптимизацией ресурсов пытается выделить спотовые инстансы из пула с наибольшей доступностью, анализируя метрики ресурсов. Эта стратегия хорошо подходит для рабочих нагрузок с высокой стоимостью прерывания, к которым относятся большие данные и аналитика, рендеринг изображений и мультимедийного контента, машинное обучение и высокопроизводительные вычисления.

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

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

Вопрос. Возможно ли с помощью тега отметить запрос на спотовую группу?

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

Вопрос. Как посмотреть, к каким спотовым группам принадлежат мои спотовые инстансы?

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

Вопрос. Можно ли изменить запрос на спотовую группу?

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

Вопрос. Можно ли указать различные образы AMI для каждого типа инстанса, который будет использоваться?

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

Вопрос. Можно ли использовать спотовую группу вместе с сервисами Elastic Load Balancing, Auto Scaling или Elastic MapReduce?

Спотовую группу можно использовать с такими возможностями сервиса Auto Scaling, как отслеживание целевых значений, проверка работоспособности, метрики CloudWatch и т. д. Кроме того, можно подключать инстансы к балансировщикам нагрузки сервиса Elastic Load Balancing (как к Classic Load Balancer, так и к Application Load Balancer). В Elastic MapReduce есть функция под названием «Группы инстансов», которая предоставляет возможности, подобные возможностям спотовой группы.

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

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

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

Да. Остановка-запуск и спящий режим-возобновление работы поддерживаются спотовой группой при включенном параметре «maintain» группы. 

10 принципов хорошего веб-дизайна — Smashing Magazine

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

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

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

Обратите внимание, что вас могут заинтересовать статьи по юзабилити, которые мы публиковали ранее:

Принципы хорошего веб-дизайна и рекомендации по эффективному веб-дизайну

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

Как думают пользователи?

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

Большинство пользователей ищут что-то интересное (или полезное) и интерактивное; как только будут найдены перспективные кандидаты, пользователи щелкнут.Если новая страница не соответствует ожиданиям пользователей, нажимается кнопка «Назад» и поиск продолжается.

  • Пользователи ценят качество и надежность. Если страница предоставляет пользователям высококачественный контент, они готовы скомпрометировать контент с помощью рекламы и дизайна сайта. Это причина того, почему не очень хорошо спроектированные веб-сайты с высококачественным контентом с годами набирают много трафика. Контент важнее дизайна, который его поддерживает.
  • Пользователи не читают, они сканируют. Анализируя веб-страницу, пользователи ищут какие-то фиксированные точки или якоря, которые будут вести их по содержимому страницы. Пользователи не читают, они сканируют. Обратите внимание на то, как «горячие» области резко переходят в середину предложений. Это типично для процесса сканирования.
  • Интернет-пользователи нетерпеливы и настаивают на немедленном вознаграждении. Очень простой принцип: если веб-сайт не может соответствовать ожиданиям пользователей, значит, дизайнер не справился со своей работой, и компания теряет деньги.Чем выше когнитивная нагрузка и чем менее интуитивно понятна навигация, тем более охотно пользователи покидают веб-сайт и ищут альтернативы. [JN / DWU]
  • Пользователи не делают оптимального выбора. Пользователи не ищут самый быстрый способ найти нужную информацию. Они также не сканируют веб-страницу линейно, последовательно переходя от одного раздела сайта к другому. Вместо этого пользователи удовлетворены; они выбирают первый разумный вариант. Как только они находят ссылку, которая, как кажется, может привести к цели, очень высока вероятность того, что по ней сразу же нажмут.Оптимизация сложна и занимает много времени. Удовлетворение более эффективно. [видео] Последовательное чтение не работает в Интернете. Правый снимок экрана на изображении внизу описывает путь сканирования данной страницы.
  • Пользователи следуют своей интуиции. В большинстве случаев пользователи бредут, вместо того чтобы читать информацию, предоставленную дизайнером. По словам Стива Круга, основная причина этого в том, что пользователям все равно. «Если мы находим что-то, что работает, мы придерживаемся этого.Для нас не имеет значения, понимаем ли мы, как все работает, если мы можем их использовать. Если ваша аудитория будет вести себя так, как будто вы разрабатываете рекламный щит, тогда создавайте отличные рекламные щиты ».
  • Пользователи хотят иметь контроль. Пользователи хотят иметь возможность управлять своим браузером и полагаться на единообразное представление данных на всем сайте. Например. они не хотят, чтобы новые окна открывались неожиданно, и они хотят иметь возможность вернуться с помощью кнопки «Назад» на сайт, на котором они были раньше: поэтому рекомендуется, чтобы никогда не открывала ссылки в новых окнах браузера. .

1. Не заставляйте пользователей думать

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

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

Рассмотрим пример. Beyondis.co.uk утверждает, что находится «за пределами каналов, продуктов, распространения». Что значит ? Поскольку пользователи склонны исследовать веб-сайты в соответствии с шаблоном «F», эти три утверждения будут первыми элементами, которые пользователи увидят на странице после ее загрузки.

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

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

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

Больше после прыжка! Продолжить чтение ниже ↓

Встречайте Smashing Email Newsletter с полезными советами по интерфейсу, дизайну и пользовательскому интерфейсу. Подпишитесь и получите «Контрольные списки интеллектуального проектирования интерфейсов» — бесплатных PDF-презентаций с более чем 150 вопросами, которые нужно задать себе при проектировании и создании почти любых .

2. Не теряйте терпение пользователей

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

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

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

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

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

3.Умейте привлечь внимание пользователей

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

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

Humanized отлично использует принцип фокусировки. Единственный элемент, который напрямую виден пользователям, — это слово «бесплатно», которое выглядит привлекательно и привлекательно, но все же спокойно и чисто информативно. Тонкие подсказки предоставляют пользователям достаточно информации о том, как узнать больше о «бесплатном» продукте.

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

4. Стремитесь к раскрытию особенностей

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

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

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

5. Используйте эффективное письмо

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

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

Eleven2.com сразу переходит к делу. Никаких милых словечек, никаких преувеличенных заявлений. Вместо этого цена: именно то, что ищут посетители.

Оптимальное решение для эффективного письма —

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

6.Стремитесь к простоте

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

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

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

7. Не бойтесь белого пространства

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

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

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

8. Эффективное общение с помощью «видимого языка»

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

  • Организуйте : предоставьте пользователю ясную и последовательную концептуальную структуру.Согласованность, компоновка экрана, взаимосвязи и возможность навигации — важные концепции организации. Ко всем элементам следует применять одни и те же соглашения и правила.
  • Экономьте : максимально используйте минимальное количество подсказок и визуальных элементов. Следует учитывать четыре основных момента: простота, ясность, различимость и акцент. Простота включает в себя только самые важные для общения элементы. Ясность : все компоненты должны быть спроектированы таким образом, чтобы их значение не было неоднозначным. Самобытность : важные свойства необходимых элементов должны быть различимы. Акцент : самые важные элементы должны быть легко различимы.
  • Общайтесь : сопоставьте презентацию с возможностями пользователя. Пользовательский интерфейс должен сохранять баланс разборчивости, удобочитаемости, типографики, символики, нескольких представлений, а также цвета или текстуры для успешного взаимодействия. Используйте макс. 3 шрифта максимум 3 кеглем — максимум 18 слов или 50-80 символов в строке текста.

9. Конвенции — наши друзья

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

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

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

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

10. Тестируйте раньше, тестируйте часто

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

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

Некоторые важные моменты, о которых следует помнить:

  • по словам Стива Круга, тестирование одного пользователя на 100% лучше, чем тестирование отсутствия , а тестирование одного пользователя в начале проекта лучше, чем тестирование 50 ближе к концу.Согласно первому закону Бема, ошибки наиболее часты при разработке требований и при проектировании и тем дороже, чем позже они устраняются.
    • Тестирование
  • — это итерационный процесс . Это означает, что вы что-то проектируете, тестируете, исправляете, а затем снова тестируете. Могут быть проблемы, которые не были обнаружены во время первого раунда, поскольку пользователи были практически заблокированы другими проблемами.
  • юзабилити-тесты всегда дают полезные результаты . Либо вам укажут на проблемы, которые у вас есть, либо укажут на отсутствие серьезных недостатков в дизайне, что в обоих случаях является полезным пониманием для вашего проекта.
  • согласно закону Вайнберга, разработчик не подходит для тестирования своего кода . Это касается и дизайнеров. Проработав несколько недель над сайтом, вы больше не можете смотреть на него с новой точки зрения. Вы знаете, как он устроен, и поэтому точно знаете, как это работает — у вас есть мудрость, которой не хватило бы независимым тестировщикам и посетителям вашего сайта.

Итог: если вам нужен отличный сайт, вам нужно его протестировать.

9 Рекомендаций и передовых практик для исключительного веб-дизайна и удобства использования

Когда дело доходит до разработки или редизайна веб-сайта, легко зацикливаться на эстетике.Правильно ли выглядит этот оттенок синего? Должен ли логотип быть на правой стороне экрана или слева? Что, если мы поместим гигантский анимированный GIF посередине страницы?

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

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

Рекомендации по дизайну веб-сайтов

  1. Простота
  2. Визуальная иерархия
  3. Судоходство
  4. Консистенция
  5. Ответственность
  6. Доступность
  7. Условные обозначения
  8. Доверие
  9. Ориентация на пользователя

1.Простота

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

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

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

  • Цвета: В основном, не используйте много. Руководство по взаимодействию компьютера и человека рекомендует использовать в вашем дизайне максимум пять (плюс-минус два) разных цвета.
  • Гарнитуры: Гарнитуры, которые вы выбираете, должны быть хорошо читаемыми, поэтому ничего излишне вычурного и очень минималистичных шрифтов, если таковые имеются.Что касается цвета текста, опять же, сделайте его минимальным и всегда убедитесь, что он контрастирует с цветом фона. Обычная рекомендация — использовать максимум три разных шрифта максимум трех разных размеров.
  • Графика: Используйте графику только в том случае, если она помогает пользователю выполнить задачу или выполнить определенную функцию (не просто добавляйте графику волей-неволей).

Вот отличный пример простого, но эффективного дизайна домашней страницы от HERoines Inc:

Источник изображения

2.Визуальная иерархия

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

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

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

Источник изображения

3. Судоходство

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

Вот несколько советов по оптимизации навигации по вашему сайту:

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

Источник изображения

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

Это хорошо подводит нас к следующему принципу …

4. Последовательность

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

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

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

Источник изображения

5. Отзывчивость

По данным Statista, 48% глобальных просмотров страниц приходилось на мобильные устройства, такие как смартфоны и планшеты. Согласно нашему исследованию, 93% людей покинули веб-сайт, потому что он некорректно отображался на их устройстве.

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

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

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

Источник изображения

Помимо удобства для мобильных устройств, стоит потратить время на проверку кросс-браузерной совместимости вашего сайта. Скорее всего, вы просматривали свой сайт только в одном браузере, будь то Google Chrome, Safari, Firefox или что-то еще.

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

6. Доступность

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

Как и отзывчивость, доступность распространяется на весь ваш сайт: структуру, формат страницы, визуальные эффекты, а также письменный и визуальный контент. Руководство по обеспечению доступности веб-контента (WCAG), разработанное Инициативой веб-доступности и Консорциумом World Wide Web, устанавливает руководящие принципы доступности веб-ресурсов.В широком смысле эти рекомендации гласят, что веб-сайты должны быть:

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

Для более глубокого погружения в эту тему см. Наше полное руководство по веб-доступности.

7. Условность

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

  • Размещение основной навигации вверху (или слева) страницы.
  • Размещение логотипа вверху слева (или в центре) страницы.
  • Делаем логотип кликабельным, чтобы посетитель всегда возвращался на главную страницу.
  • Наличие ссылок и кнопок, меняющих цвет / внешний вид при наведении на них курсора.
  • Использование значка корзины покупок на сайте электронной торговли. На значке также есть числовой значок, обозначающий количество товаров в корзине.
  • Обеспечение наличия кнопок на слайдерах изображений, которые пользователи могут нажимать для поворота слайдов вручную.

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

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

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

8. Доверие

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

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

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

Вот пример эффективной страницы с ценами на сайте Box:

Источник изображения

9.Ориентация на пользователя

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

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

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

Вот несколько инструментов пользовательского тестирования, с которых можно начать:

  • Website Grader : Наш бесплатный инструмент оценивает ваш сайт по нескольким факторам: мобильность, дизайн, производительность, SEO и безопасность. Затем он предлагает индивидуальные предложения по улучшению. Вы можете узнать больше о Website Grader в нашем специальном сообщении в блоге.
  • Crazy Egg : Отслеживайте несколько доменов под одной учетной записью и получайте информацию о производительности вашего сайта с помощью четырех различных интеллектуальных инструментов — тепловой карты, карты прокрутки, наложения и конфетти.
  • Loop11: используйте этот инструмент, чтобы легко создавать тесты удобства использования, даже если у вас нет опыта работы с HTML.
  • Пользователь пьян : Заплатите Ричарду Литтауэру, чтобы он напился и просмотрел ваш сайт. Не верите мне? Мы попробовали.

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

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

Рекомендации по дизайну веб-сайтов

  1. Выберите типографику, удобную для чтения и беглости.
  2. Выберите цветовую схему, соответствующую вашему бренду.
  3. Используйте пробел для разделения текста и других элементов.
  4. Используйте текстуру, чтобы добавить индивидуальности и глубины.
  5. Добавьте изображения, чтобы заинтересовать и информировать читателей.
  6. Упростите навигацию.
  7. Сделайте ваши призывы к действию особенными.
  8. Оптимизация для мобильных устройств.
  9. Ограничьте возможности, предоставляемые пользователям.

1. Выберите типографику, удобную для чтения и беглости.

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

В идеале вам нужен шрифт:

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

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

Источник изображения

2. Выберите цветовую схему, соответствующую вашему бренду.

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

  • усилить индивидуальность вашего бренда
  • упростите чтение и навигацию по вашему сайту
  • вызвать эмоции
  • хорошо выглядеть

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

Источник изображения

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

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

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

Например, Eb & flow Yoga Studio использует пробелы, чтобы вести пользователей к определенному действию: записаться на трехнедельные занятия. Обратите внимание, что пробел не означает отсутствие цвета или изображения. Вместо этого это означает, что каждый элемент на странице расположен стратегически, с большим пространством между ними, чтобы не ошеломить или сбить с толку посетителей.

Источник изображения

4.Используйте текстуру, чтобы добавить индивидуальности и глубины.

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

Взгляните на текстуру на главной странице ресторана Mony’s Tacos в Санта-Барбаре ниже. Похоже, что нарисовали мелом на доске, не так ли? Не знаю, как вы, но я почти чувствую мел на пальцах, просто глядя на него.Это идеальный вид для ресторана, который стремится стать предпочтительным выбором в калифорнийской фанк-зоне для мексиканских деликатесов.

Источник изображения

5. Добавьте изображения, чтобы заинтересовать и информировать читателей.

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

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

Источник изображения

6. Упростите навигацию.

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

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

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

Источник изображения

7. Сделайте ваши призывы к действию особенными.

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

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

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

Источник изображения

8. Оптимизация для мобильных устройств.

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

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

Источник изображения

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

9. Ограничьте возможности, предоставляемые пользователям.

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

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

Источник изображения

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

Требования к дизайну веб-сайтов

  1. Верхний и нижний колонтитулы
  2. Навигация по меню
  3. Панель поиска
  4. Брендинг
  5. Цветовая палитра
  6. Заголовки
  7. Очистить этикетки
  8. Визуальные материалы и медиа
  9. Призывы к действию
  10. Пробел

1.Верхний и нижний колонтитулы

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

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

2. Навигация по меню

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

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

3. Панель поиска

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

4. Брендинг

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

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

5. Цветовая палитра

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

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

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

6. Заголовки

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

7. Очистить ярлыки

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

Например, кнопка, указывающая на страницу с ценами, должна просто читать «Цены» — все остальное (например, «Посмотреть наши цены», «Проверить страницу с ценами для сделки») излишне. Панель / кнопка поиска нуждаются только в значке окна поиска (🔍) и, возможно, также в слове «Поиск», чтобы обозначить ее назначение.

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

8. Визуальные эффекты и средства массовой информации

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

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

Источник изображения

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

9. Призывы к действию (CTA)

Хороший веб-сайт — это здорово, но как узнать, действительно ли посетители делают то, что вы хотите? Они взаимодействуют с вашим контентом? Вот тут-то и вступают в игру CTA.

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

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

10. Пробел

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

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

Дизайн, ориентированный на пользователя

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

По данным Amazon Web Services, 88% посетителей веб-сайтов с меньшей вероятностью вернутся на веб-сайт после неудовлетворительного опыта. И как вы могли их винить? Мы все наверняка там были.

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

Что такое URL? — Изучите веб-разработку

В этой статье обсуждаются унифицированные указатели ресурсов (URL), объясняется, что это такое и как они структурированы.

С гипертекстом и HTTP, URL — одно из ключевых понятий Интернета. Это механизм, используемый браузерами для получения любого опубликованного ресурса в Интернете.

URL означает Uniform Resource Locator . URL-адрес — это не что иное, как адрес данного уникального ресурса в Интернете.Теоретически каждый действительный URL-адрес указывает на уникальный ресурс. Такими ресурсами могут быть HTML-страница, CSS-документ, изображение и т. Д. На практике есть некоторые исключения, наиболее распространенным из которых является URL-адрес, указывающий на ресурс, который больше не существует или который был перемещен. Поскольку ресурс, представленный URL-адресом, и сам URL-адрес обрабатываются веб-сервером, владелец веб-сервера должен тщательно управлять этим ресурсом и связанным с ним URL-адресом.

Вот несколько примеров URL:

 https: // разработчик.mozilla.org
https://developer.mozilla.org/en-US/docs/Learn/
https://developer.mozilla.org/en-US/search?q=URL

Любой из этих URL-адресов можно ввести в адресную строку браузера, чтобы указать ему загрузить связанную страницу (ресурс).

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

Наконечник

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

Примечание

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

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

Далее следует центр , который отделен от схемы шаблоном символов : // . Если присутствует, то полномочия включают в себя как домен (например, www.example.com ), так и порт ( 80 ), разделенные двоеточием:

  • Домен указывает, какой веб-сервер запрашивается.Обычно это доменное имя, но также можно использовать IP-адрес (но это редко, так как это гораздо менее удобно).
  • Порт указывает технический «шлюз», используемый для доступа к ресурсам на веб-сервере. Обычно его опускают, если веб-сервер использует стандартные порты протокола HTTP (80 для HTTP и 443 для HTTPS) для предоставления доступа к своим ресурсам. В противном случае это обязательно.
Примечание

Разделитель схемы и полномочий — : // .Двоеточие отделяет схему от следующей части URL-адреса, а // указывает, что следующая часть URL-адреса является авторитетом.

Одним из примеров URL-адреса, в котором не используются полномочия, является почтовый клиент ( mailto: foobar ). Он содержит схему, но не использует авторитетный компонент. Следовательно, за двоеточием не ставятся две косые черты, а только как разделитель между схемой и почтовым адресом.

/path/to/myfile.html — это путь к ресурсу на веб-сервере.В первые дни Интернета такой путь представлял физическое расположение файла на веб-сервере. В настоящее время это в основном абстракция, обрабатываемая веб-серверами, без какой-либо физической реальности.

? Key1 = value1 & key2 = value2 — это дополнительные параметры, предоставляемые веб-серверу. Эти параметры представляют собой список пар ключ / значение, разделенных символами и . Веб-сервер может использовать эти параметры для дополнительных действий перед возвратом ресурса. Каждый веб-сервер имеет свои собственные правила в отношении параметров, и единственный надежный способ узнать, обрабатывает ли конкретный веб-сервер параметры, — это спросить владельца веб-сервера.

#SomewhereInTheDocument — это привязка к другой части самого ресурса. Якорь представляет собой своего рода «закладку» внутри ресурса, давая браузеру указания для отображения содержимого, расположенного в этом «отмеченном закладкой» месте. Например, в документе HTML браузер будет прокручивать до точки, в которой определена привязка; в видео- или аудиодокументе браузер попытается перейти к моменту времени, который представляет якорь. Стоит отметить, что часть после # , также известная как идентификатор фрагмента , никогда не отправляется на сервер с запросом.

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

В языке HTML, который будет обсуждаться позже, широко используются URL-адреса: