Шар sections на Dawn, редагований продавцем

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

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

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

Команді вітрини потрібно оновлювати зображення, тексти, заклики до дії та FAQ, не відкриваючи код теми й не чекаючи на розробника заради кожної сезонної зміни. Але повний no-code контроль ані реалістичний, ані бажаний: певні речі, як-от поведінка навігації та форма базових даних, мають лишатися в руках інженерів, щоб магазин не ламався непомітно. Завдання полягало в тому, щоб провести цю межу свідомо, аби контент і структура мали різних, чітких власників.

Обмеження

• Контент і структура, це різні задачі. Рутинний контент має бути в режимі самообслуговування. Структурна зміна має бути перевіреною роботою інженерів. Змішування їх, це шлях, яким тема перетворюється на некерований конструктор сторінок.
• Повторне використання замість одноразових рішень. Секція, побудована, щоб відтворити один точний дизайн один раз, це тягар. Секції мали бути придатними до повторного використання між товарами й колекціями.
• Редагування має лишатися у вбудованому редакторі. Команда вже знає редактор теми Shopify. Правильною поверхнею керування був саме цей редактор, а не власна адмінка.
• Жодних крихких посилань у повторно використовуваних частинах. Повторно використовувана секція, яка жорстко зашиває конкретний товар чи колекцію, перестає бути повторно використовуваною тієї миті, коли змінюється каталог.

Як побудовано шар секцій

Шар контенту побудований із повторно використовуваних секцій Shopify OS 2.0. Для читачів, які вперше стикаються з Shopify: секції OS 2.0, це конфігуровані blocks сторінки, які продавець може додавати, видаляти та переставляти в редакторі теми. Кожна секція тут відкриває налаштування (текст, зображення, посилання), повторювані blocks (для списків на кшталт FAQ чи рядків переваг) та пресет, щоб вона з'являлася в меню редактора «add section». Секції обирають товари й колекції через вбудовані засоби вибору Shopify, а не через жорстко зашиті handles, і несуть розумні спільні значення за замовчуванням, тож нова сторінка виглядає завершеною ще до того, як хтось її налаштує. Там, де товару потрібна власна версія спільного контенту, секція читає перевизначення через product metafield.

Власність над контентом: хто що редагує

Межа між двома власниками, це суть усього дизайну.

Редагується продавцем, розробник не потрібен:

• Зображення, тексти та заклики до дії
• FAQ та подібний списковий контент
• Конкретні товари й колекції, які показує секція
• Опції підбірника та цільова колекція, на яку вказує кожна опція
• Перевизначення контенту для конкретного товару

Належить інженерам:

• Поведінка навігації
• Домовленості щодо даних і сама схема metafield
• Структурні макети
• Поведінка, що впроваджується застосунками
• Нові контент-примітиви, тобто нові типи секцій

Коротка версія і правило, яке варто сказати прямо: рутинні зміни контенту, це самообслуговування. Структурні зміни лишаються роботою інженерів.

Потік перевизначення через metafield

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

Shared section defaults       (authored)
        |
        v
Product metafield override    (merchant data, optional)
        |
        v
Product-specific content      (rendered output)

  no override present:
        |
        v
  falls back to the shared default

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

Ланцюжок запасних варіантів банера

Та сама логіка запасних варіантів проходить крізь банер колекції, тож сторінка колекції виглядає завершеною ще до того, як хтось її торкнеться.

Collection-specific image (set in the theme editor)
   -> else a collection metafield image
   -> else the collection's own image
   -> else a shared default image

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

Налаштування підбірника

Підбірник товарів теж є частиною цієї редагованої поверхні. Команда може керувати його підписами, його опціями та цільовою колекцією, куди спрямовує кожна опція, і все це як контент секції.

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

Редактор теми як поверхня керування

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

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

Редагування на десктопі, відтворення на мобільних

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

Що лишилося структурним

Це лишилося роботою інженерів, а не налаштуваннями редактора:

• Доповнення схеми та схема metafield
• Нові типи секцій
• Логіка навігації
• Зміни в системі макетів
• Поведінка, впроваджена застосунками

Перевірка

На рівні реалізації, не бізнес-результат:

• Шар контенту, це повторно використовувані секції OS 2.0.
• Секції відкривають пресети та blocks.
• Секції використовують вбудовані засоби вибору товарів і колекцій.
• Перевизначення через product metafield керують контентом для конкретного товару.
• Запасний контент відтворюється, коли перевизначення відсутнє.
• Шар повторно використовуваних секцій не містить жорстко зашитих посилань на товари.
• Рутинний контент можна змінювати в редакторі теми.

Компроміси

• Перекривні патерни секцій. Кілька банерних і навчальних секцій мають спільним більшість свого макета й могли б бути об'єднані в меншу кількість параметризованих секцій.
• Частина навчального тексту зафіксована в коді. Певний порівняльний контент міститься в шаблоні, а не в налаштуваннях, тож зміна цього формулювання потребує розробника.
• Розростання секцій і складність схеми. Більше типів секцій означає більше поверхні для підтримки, а налаштування можуть розростися за межу зручності користування.
• Об'єднання, це робота на майбутнє. Повторно використовуване ядро надійне; дублювання, це борг, який треба погасити.

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

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

Назад до повної історії: кейс Absolute Support.