За обновлениями можно следить в telegram-канале https://t.me/quasiart

Привет.

Недавно на проекте появилась задача реализовать сториз. Под сториз я имею в виду тот формат подачи информации, который существует более 10 лет: есть определённые темы («последние 24 часа», «Мурзик ♥» и так далее), и на каждую тему есть определённое количество слайдов. Порядок просмотра обычно с поздних до ранних.

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

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

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

Собственно, об этих правилах я и хотел написать эту статью:

  • О чём подумать при разработке сториз.
  • Как улучшить UX сториз.

1 Анатомия сториз

Сториз состоит из следующих частей:

  • кружочки
  • слайдер
  • таймлайн

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

1.1 Кружочки

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

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

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

1.2 Слайдер

В один момент отображается только один слайд. При клике по правой части слайда происходит переход к следующему слайду, а если слайд был последним, то происходит переход к следующей теме (к следующему кружочку). Каждый слайд отображается какое-то время: 10-20 секунд. Если в слайде видео, то слайд отображается пока не закончится видео.

1.3 Таймлайн

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

2 Навигация

Есть общепринятый подход к навигации по сториз.

  • Клик по левой части слайда: возврат на предыдущий слайд или тему. Можно добавить управление клавишами-стрелками.
  • Клик по правой части слайда: переход на следующий слайд или тему. Можно добавить управление клавишами-стрелками.
  • Нажатие и удерживание (тач-н-холд) по слайду: пауза.
  • При свайпе влево и вправо происходит смена темы.
  • Escape на десктопе или «Назад» на мобильном устройстве — закрытие слайдера.

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

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

3 Адаптивность

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

Какие моменты здесь стоит для себя решить:

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

4 Формат хранения

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

Давайте для начала я разделю формат условно на два вида: описательный и свёрстанный (обещаю придумать названия получше).

4.1 Описательный

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

Плюсы:

  • Контент генерируется гибко под каждого пользователя.
  • Не требуется пересборка фронта.

Минусы:

  • Нужно тщательно согласовать контракт для представления сториз.
  • Возможно, нужно придумать инструмент для создания/редактирования сториз на стороне админки или личного кабинета.
  • Нужно написать обработчик этого формата на фронте.

Как бы мог выглядеть ответ от сервера? В простом виде могло быть что-то вроде этого:

[
  {
    "title": "Заголовок первого слайда",
    "text": "Текст первого слайда",
    "background": "/images/1.png",
    "duration": 15000
  },
  {
    "title": "Заголовок второго слайда",
    "text": "Текст второго слайда",
    "background": "/images/2.png",
    "duration": 13000
  }
]

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

<Slider data={slides} />

4.2 Свёрстанный

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

<Slider>
    <Slide>
        <Title>Заголовок первого слайда</Title>
        <Text>Текст первого слайда</Text>
    </Slide>
    <Slide>
        <Title>Заголовок второго слайда</Title>
        <Text>Текст второго слайда</Text>
    </Slide>
</Slider>

Плюсы:

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

Минусы:

  • Нельзя подстроить контент индивидуально под каждого пользователя.
  • Требуется пересборка фронтенда при каждом обновлении сториз.