Редаговані продавцем сторінки кави на Shopify metafields

Уявіть покупця, який порівнює дві кави single-origin. Він не зважає на ціну. Він читає походження, обробку, висоту вирощування, профіль обсмаження та смакові ноти й вирішує, з якою чашкою хоче прокидатися. Універсальна комерційна тема не має уявлення про ці атрибути specialty coffee. Вона дає базові комерційні примітиви, але поля, специфічні для кави, усе одно доводиться проєктувати та підключати до товару.

Саме цю прогалину мала закрити ця частина проєкту Boxwood. Specialty coffee це інформаційний продукт не менше, ніж фізичний, і вітрина мала подавати цю інформацію так, щоб команда мерчандайзингу могла редагувати її для кожного нового релізу, без зміни коду теми щоразу.

Цей розбір розширює кейс Boxwood Coffee. Ось як було змодельовано дані.

Два види інформації

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

Вибір, що впливає на покупку

Помел і вага. Вони змінюють те, що потрапляє в кошик, ціну та кількість на складі.

Описові атрибути

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

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

Варіанти лишаються варіантами, атрибути стають metafields

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

Описові атрибути зберігаються як metafields товару, тож вони живуть разом із товаром у Shopify, а не всередині розмітки теми. Їх згруповано у чотири багаторазові sections сторінки товару.

Coffee data

Читає: походження, регіон, висоту, сорт, обробку, профіль обсмаження

Виводить: структуровану сітку характеристик

Tasting note

Читає: смакову ноту

Виводить: помітний рядок зі смаковими нотами

Origin story

Читає: зображення історії та текст історії

Виводить: зображення та коротку розповідь про товар

Product information

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

Виводить: практичні поради у згортному блоці

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

Sections, які читають дані, а не зберігають їх

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

01 · Читати з товару

Section дістає metafield з поточного товару й виводить його; контент не вписують у сам section. Саме це дозволяє одному section обслуговувати кожну каву в каталозі.

02 · Коректний запасний варіант

Кожне поле спершу перевіряє metafield товару, потім налаштування section, тож товар, який ще не заповнили, усе одно виглядає правильно в редакторі теми й ніколи не виводить порожню мітку.

Спрощений патерн Liquid. Назви полів і потік керування спрощено для читабельності.

{%- liquid
  assign brewing = product.metafields.custom.brewing_recommendations.value
  assign brewing_title = product.metafields.custom.brewing_title.value
    | default: section.settings.brewing_title
-%}
{%- if brewing != blank -%}
  {% render 'accordion', title: brewing_title, content: brewing %}
{%- endif -%}

03 · Виводити лише за наявності даних

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

Ще одна деталь, яку варто назвати: згортний section повторно використовує власний компонент акордеона теми, а не винаходить його заново. Власний код постачає дані та структуру; перевірений нативний UI відповідає за відкривання й закривання.

Одного template недостатньо

Не кожен товар це пакет кави. Товар за підпискою та передзамовлення потребують іншої сторінки, ніж партія single-origin. Замість накопичувати умови за типом товару в одному дедалі складнішому template, магазин використовує окремі product templates, які призначають кожному товару в адмінці.

• Товар-кава → повний набір sections із даними про каву
• Товар за підпискою → простіший макет підписки
• Товар передзамовлення → окремий макет передзамовлення

Призначення template це випадне меню в адмінці товару, тож команда мерчандайзингу керує тим, який макет отримає товар, без зміни коду. Описові sections призначені лише відповідним product templates, що не дає їм виводитися на непов'язаних типах товарів.

Що насправді отримує продавець

Виграш це робочий процес, а не окрема функція. Щоб запустити нову сезонну каву, команда Boxwood:

1. створює товар
2. додає варіанти помелу та ваги
3. заповнює metafields кави (походження, обробка, обсмаження, смакові ноти, заварювання тощо)
4. призначає відповідний template та колекцію
5. публікує

Це звичайний шлях запуску. Коли новий реліз вписується в наявні sections та metafields, зміна коду теми не потрібна. Обмежений реліз і цілорічний бленд використовують ті самі sections і коректно виводяться на власних даних. Поля, які лишили порожніми, просто не зʼявляються. Рутинні сезонні релізи стали робочим процесом із контентом, а не повторюваною інженерною зміною.

Де проходить межа

Ця модель чесна щодо своїх обмежень, і я краще назву їх, ніж перехвалю.

Додати цілком новий вид атрибута, скажімо, поле «діапазон висоти», якого раніше не існувало, не можна самотужки. Це означає додати поле в section та визначити metafield, а це робота розробника. Повсякденний контент і нові релізи кави, які вписуються в наявну модель, можна робити самостійно. Зміна форми моделі свідома й контрольована.

Контент належить продавцю. Зміни самої структури полів лишаються інженерною роботою.

Висновок

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

Зробіть так, і тема перестане бути місцем, де живе контент, і повернеться до того, чим має бути: тим, що виводить контент. Для specialty-бренду, який запускає каву протягом усього року, ця різниця відділяє рутинний робочий процес із даними товару від повторюваної зміни теми.