Покупатель открывает несколько электрических чайников и переключается между карточками: у одного описан материал корпуса, у другого — объём, у третьего — уход за фильтром. Чтобы выбрать, приходится запоминать сведения. На этом учебном примере рассмотрим, что владелец магазина готовит перед добавлением сравнения товаров в WooCommerce.
Таблица сравнения собирает выбранные модели рядом. Фильтр каталога решает другую задачу: убирает товары, которые не подходят по заданному условию. Покупатель сначала сокращает список, а затем сопоставляет оставшиеся чайники. Если в магазине уже есть фильтр, новая таблица всё равно требует отдельного выбора характеристик.
По какому отличию покупатель выбирает чайник?
Владелец начинает с вопросов, которые продавцу задают о товаре. Для нашего примера это материал корпуса, полезный объём и возможность снять фильтр. Такие сведения меняют выбор: человеку, который очищает чайник вручную, важен доступ к деталям. Рекламные слова о качестве не объясняют, чем отличаются соседние модели.
- Объём у сравниваемых чайников записывают в одинаковых единицах.
- Материал корпуса указывают отдельно от материала ручки.
- Съёмный фильтр и отсутствие сведений о фильтре показывают как разные состояния.
Это набор полей для учебного каталога, а не характеристики реальных моделей. В рабочий магазин менеджер переносит данные поставщика. Если источник не подтверждает свойство, в таблицу не добавляют догадку. Пустая ячейка с пояснением о недостающих данных честнее выдуманного преимущества.
Сравнивать весь каталог или одну категорию?
Одна общая таблица требует полей, подходящих всем товарам. Для магазина с разными категориями она быстро теряет предметный смысл: параметр чайника ничего не говорит о кухонном полотенце. Ограничение сравнения одной категорией сужает выбор, зато оставляет сопоставимые строки.
Если владелец разрешает сравнивать товары из разных категорий, он заранее выбирает общие поля и способ показа неприменимых свойств. Разработчик проверяет, позволяет ли выбранное расширение задать такие правила. Универсальную таблицу со всеми данными нельзя обещать только на основании наличия кнопки сравнения.
Показывать все строки или только различия?
Полная таблица сохраняет общий контекст: покупатель видит и совпадающие, и разные свойства. Режим различий сокращает число строк, но способен скрыть параметр, который человек считает обязательным. Выбор зависит от задачи покупателя, а не от желания сделать экран короче.
Для чайников из примера менеджер проверяет, не исчезает ли важное совпадение вместе с одинаковыми строками. Отсутствие строки не должно означать отсутствие свойства. Если магазин предлагает переключатель между режимами, его действие проверяют на данных, где часть характеристик совпадает, а часть не заполнена.
На телефоне покупатель сталкивается с другой трудностью: название параметра и значение могут оказаться далеко друг от друга. В проверочном варианте он прокручивает таблицу, возвращается к названию чайника и удаляет одну модель. Владелец смотрит, сохраняется ли связь между заголовком столбца и каждой характеристикой.
Что входит в результат доработки?
Помимо кнопок добавления, результат включает саму таблицу, правила выбора моделей и отображение неполных данных. Менеджер открывает её с карточки и из каталога, меняет набор чайников и проверяет пустой список. Исчезновение выбранной модели после обычного перехода тоже относится к проверке, если сохранение выбора входит в задачу.
Наполнение характеристик и программирование таблицы — разные работы. Разработчик настраивает вывод согласованных полей; владелец отвечает за подтверждённые сведения о моделях. Без этого разделения внешне готовая таблица остаётся пустой или сопоставляет несопоставимые значения.