Власний UI фільтрації на Shopify Search & Discovery

Сторінка колекції, це місце, де покупець звужує каталог до тих кількох товарів, які справді може купити. Інтерфейс для цього може бути повністю власним. Рушій під ним таким бути не зобов'язаний, і в Absolute Support він таким не був. Ось як власна мобільна фільтрація лишалася підключеною до нативного рушія facet-ів Shopify, замість того щоб замінювати його.

Це другий із трьох поглиблених розборів кейсу Absolute Support. Він іде після поглибленого розбору про компресійний PDP і веде до розбору про секції, редаговані продавцем.

Проблема, в одному абзаці

Покупці приходять до каталогу компресійного одягу з різних відправних точок. Хтось мислить типом виробу (шкарпетки, панчохи до стегна, колготки, рукави). Хтось мислить рівнем компресії. Хтось мислить категорією стану чи застосування. Хтось мислить статтю або загальною категорією каталогу, а хтось просто хоче відсортувати за ціною. Сторінка колекції мала подати власну, специфічну для бренду фільтрацію для всіх цих випадків, спершу на телефоні, не перетворюючи саму фільтрацію на власний код, який міг би розсинхронізуватися з Shopify.

Обмеження

• Фільтрацією вже володіє Shopify. Search & Discovery від Shopify обчислює й застосовує facet-и та зберігає стан фільтра в URL колекції. Facet, для тих, хто вперше зустрічає цей термін, це один вимір фільтрації, наприклад розмір, колір чи ціна.
• URL колекцій мають лишатися змістовними. Відфільтрована колекція, це URL, яким можна поділитися і який індексується. Власний рушій, що вигадав би власний стан, це зламав би.
• Сортування та результати, це поведінка платформи. Порядок сортування та відрендерена сітка товарів надходять від Shopify. Власний шар має їх подавати, а не переобчислювати.
• Один рушій фільтрації, а не два. Ризик будь-якого власного інтерфейсу фільтрації, це непомітно збудувати друге джерело істини для того, «що відфільтровано». Саме цього треба було уникнути.

Ремарка щодо власності перед реалізацією: таксономія каталогу тут, це частково конфігурація Shopify, а частково власна подача. Facet-и, які показує колекція, налаштовуються в адмінці Shopify. Тема їх рендерить і перестилізовує. Я налаштовував і подавав; я не будував рушій facet-ів.

Рішення: власна оболонка, нативний рушій

Інтерфейс створений вручну. Стан фільтрації та результати лишаються нативними для Shopify.

Custom mobile filter UI      (authored presentation)
  filter bar · price slider · view toggle
        |
        v
Native facet form            (Shopify)
        |
        v
Search & Discovery           (Shopify engine)
        |
        v
Updated collection results   (Shopify-rendered)
  product URLs · sorting · filter state

На мобільному це вертикальна передача. На десктопі той самий зв'язок може розташовуватися горизонтально. У будь-якому разі власні елементи керування стоять поверх нативної facet-форми й передають свої дії в неї.

Як з'єднуються частини

Власні елементи керування не виконують власної фільтрації. Вони оновлюють поля вводу facet-форми Shopify й дають Shopify зробити роботу.

Власні елементи керування пишуть у нативну форму. Коли покупець змінює фільтр у власному інтерфейсі, ця дія оновлює відповідне нативне facet-поле. Далі facet-механізм Shopify запитує відфільтровані результати й перерендерює сітку. Результати, лічильники та URL, це вихід Shopify.

Перерендеринг обробляється після кожного оновлення. Оскільки при зміні фільтрів область результатів замінюється, власні елементи керування переініціалізуються після кожного оновлення, щоб лишатися прив'язаними до свіжо відрендереної facet-розмітки, а не до застарілої копії.

Самі facet-и налаштовуються в адмінці. На робочій вітрині facet-и колекції охоплюють стать, тип за висотою чи довжиною, деталь стопи на кшталт закритого чи відкритого носка, розмір, колір, ціну та наявність. Рівень компресії виражається через структуру колекцій і навігації, а не як facet усередині колекції, і це свідомий вибір таксономії, що вартий згадки.

Частини власного інтерфейсу

Створений вручну шар, це невеликий набір частин:

• Мобільна панель фільтрів, що відкриває елементи керування фільтрами.
• Панель фільтрів, що містить опції facet-ів.
• Повзунок діапазону цін із двома бігунками, накладений поверх нативних полів ціни.
• Перемикач вигляду «сітка або список» для карток товарів.
• Запам'ятоване налаштування вигляду, збережене на клієнті, щоб вибір покупця «сітка чи список» зберігався між відвідуваннями.
• Подача сортування, що виводить нативні опції сортування Shopify у власному інтерфейсі.

Повзунок ціни, це та частина, що потребує найбільше уваги, бо це власний елемент керування, що стоїть перед нативними полями мінімуму й максимуму. Його завдання, рухати ці поля, а не ставати авторитетом щодо ціни. Перемикач вигляду навмисно є протилежним видом стану: це налаштування подачі, і він ніколи не повинен поводитися як друге визначення відфільтрованого каталогу.

Пошук товарів на основі тегів

Окремо від фільтрів колекції вітрина містить пошук товарів. Варто точно окреслити, що це таке.

Покупець обирає стать чи категорію каталогу, рівень компресії та стиль. Далі пошук будує або маршрутизує до відповідного URL колекції, використовуючи структуру тегів магазину. Це весь механізм.

Це навігаційний швидкий доступ до каталогу. Це не опитувальник. Це не ШІ. Це не рушій рекомендацій, і це не медична порада. Називати його якимось із цього означало б видавати маршрутизатор «тег-до-колекції» за те, чим він не є.

Mobile-first UX фільтрації

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

Частина поведінки реалізована й перевіряється у збірці:

• Елементи керування фільтрами відкриваються з мобільної панелі фільтрів, тож фільтрація досяжна в межах великого пальця, а не захована.
• Повзунок ціни дає прямий спосіб задати діапазон на малому екрані замість введення у два поля.
• Налаштування «сітка або список» запам'ятовується між відвідуваннями.
• Виправлення видимості шухляди тримає повний список facet-ів відкритим на мобільному, коригуючи стандартну поведінку, що могла його згортати.

Іншу поведінку я вважаю цілями дизайну та відкритими пунктами для перевірки, а не твердженнями, бо її формально не тестували:

• Області дотику, що відповідають комфортному мінімуму, для панелі фільтрів, бігунків повзунка та перемикача.
• Збереження позиції прокручування під час зміни фільтра там, де це підтримує платформа.
• Уникнення вкладених пасток прокручування всередині панелі фільтрів.
• Чіткий, очевидний шлях повернення з панелі фільтрів назад до результатів.
• Передбачувана поведінка кнопки «назад» у браузері з огляду на те, що стан фільтра зберігається в URL.
• Читабельна кількість активних фільтрів і видимі дії «застосувати» чи «скинути», де вони є.

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

Що лишилося нативним

Власний шар ніколи не брав у володіння цього:

• Рушій facet-ів Search & Discovery
• Стан фільтрації, що зберігається в URL колекції
• Сортування
• Рендеринг колекції
• URL товарів
• Пошук

Перевірка

На рівні реалізації, не бізнес-метрика:

• Власні елементи керування передають свої дії в нативну facet-форму.
• Фільтрація та сортування лишаються нативними для Shopify.
• Мобільна подача власна.
• Налаштування «сітка або список» запам'ятовується на клієнті.
• Пошук маршрутизує через логіку колекцій на основі тегів, а не через якесь оцінювання чи рекомендації.

Компроміси

• Виявлення на основі тегів залежить від чистих даних. Оскільки пошук маршрутизує за тегами, непослідовне тегування може відправити запит до порожнього результату. Це гігієна даних, а не дефект інтерфейсу.
• Повзунок із двома бігунками потребує ретельної синхронізації. Власний елемент керування перед нативними полями має тримати їх точно в унісон, інакше видимий діапазон і застосований діапазон можуть не збігатися.
• Зміни в Search & Discovery можуть потребувати узгодження. Власний шар лежить поверх facet-розмітки Shopify, тож зміна платформи там потребує ручного проходу.
• Запам'ятоване налаштування вигляду, це стан клієнта. Як налаштування подачі воно нормальне, але має ним і лишатися. Воно ніколи не повинно вирости в друге визначення каталогу.

Що я поліпшив би далі

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

Далі: Шар секцій, редагованих продавцем, на Dawn, це те, як решта вітрини лишається редагованою, не перетворюючи тему на конструктор сторінок.