Zebra Skimmers · Redesign Plan

Mock S · Component plan — Skeleton, Horizon, manufacturing-new

The full component inventory for the redesign. Every UI piece across the fourteen page mocks, classified by where it comes from — what Skeleton ships ready-to-use, what we adapt from Horizon's architecture, and what's brand-new for the manufacturing vertical. Plus the naming convention, the design token contract every component reads, and a callout for the one new page that emerged this session.
§ 01

Three sources, roughly forty components.

The redesign is a fork of Shopify's Skeleton theme, with architectural patterns referenced from Horizon (rebuilt from scratch in Skeleton — Horizon is proprietary and Horizon-derived themes are barred from the Theme Store). The third column is everything new — the manufacturing-vertical pieces that make this theme distinctively industrial rather than generically commercial.

Column A
12
Skeleton ships as-is
Used unchanged or with light theming. Layout primitives, basic content sections, structural components.
Column B
8
Horizon-referenced, Skeleton-built
Architectural patterns Horizon pioneered — variant picker modes, media stack, facet groups. Rebuilt from scratch in Skeleton.
Column C
19
Manufacturing-new builds
Spec tables, document lists, compatibility matrices, compare, FYF wizard, quote form, volume pricing, video gallery, sticky nav, distributor map — the vertical-specific pieces.

Roughly thirty-nine components total. Counts are approximate — some Column A pieces could be lightly extended into Column B if we find Horizon does them substantially better, and some Column C pieces share enough structure that they collapse into one component with variants. The numbers are useful for scoping not committing.

§ 02

Naming convention & design-token contract.

Two things every component honors. First, the custom-element tag follows a stable naming pattern so the registry is predictable. Second, every component reads colors, typography, and spacing exclusively from CSS custom properties — never hardcoded — so the twenty-five color × type combinations from Mock Q work across the entire component library without per-component overrides.

Web-component tag naming

Skeleton's convention is unprefixed custom elements (<product-card>, <variant-picker>). For a sellable Theme Store theme this is fine — themes don't load alongside each other, so there's no real collision risk. We follow Skeleton's pattern: unprefixed for general-purpose components, prefixed only for ones where the prefix adds clarity.

PatternExamplesUse when
<noun-noun> <product-card>, <variant-picker>, <spec-table> General-purpose components. Default pattern.
<noun-noun-modal>
<noun-noun-drawer>
<quote-request-modal>, <quick-view-drawer> Components that open as overlays. Suffix signals the rendering pattern.
<noun-noun-form> <contact-form>, <quote-request-form>, <warranty-registration-form> Form components. Suffix matches Shopify section names.
<noun-noun-section> <hero-section>, <featured-product-section> Top-level page sections, especially when there's a non-section equivalent component with a similar name.

Design token contract

Every component reads only from these CSS custom properties. No literal colors, no hardcoded fonts, no fixed pixel values for spacing where the scale applies. This is what makes the twenty-five Mock Q combinations work — swap the values at :root, every component updates automatically.

Color tokens
  • --paper/ page background
  • --paper-soft/ alt-row, cards
  • --ink/ primary text
  • --ink-soft/ secondary text
  • --rule/ borders, dividers
  • --rule-soft/ inner dividers
  • --brand/ primary accent
  • --accent/ secondary accent
  • --safety/ warning state
  • --ok/ success state
  • --danger/ error state
Typography tokens
  • --font-heading/ display + h1-h3
  • --font-body/ body copy, UI
  • --font-mono/ specs, SKUs, labels
  • --font-editorial/ italic accent type
  • --size-display/ 56px / 4rem
  • --size-h1/ 36px / 2.5rem
  • --size-h2/ 28px / 2rem
  • --size-h3/ 22px / 1.5rem
  • --size-body/ 15px / 1rem
  • --size-small/ 13px / 0.875rem
  • --size-mono/ 12px / 0.75rem
Spacing tokens
  • --space-1/ 4px
  • --space-2/ 8px
  • --space-3/ 12px
  • --space-4/ 16px
  • --space-6/ 24px
  • --space-8/ 32px
  • --space-12/ 48px
  • --space-16/ 64px
  • --gutter/ section gutter, responsive
  • --page-padding/ horizontal page pad
Border & radius tokens
  • --border-hairline/ 1px solid --rule
  • --border-rule/ 2px solid --rule
  • --border-accent/ 2px solid --accent
  • --radius/ 2px (square house style)
  • --radius-pill/ 999px for stat pills
Non-token rule · Components may use additional internal CSS custom properties for layout-specific values that don't belong in the global token set (e.g., --card-image-aspect, --filter-rail-width). These get defined on the component's host element and don't propagate. The global tokens are the contract; component-internal properties are implementation detail.
A

Skeleton ships as-is — twelve components, lightly themed

12 components

Used straight from Skeleton with palette + typography swapped through the design token contract. No structural changes, no Liquid edits beyond schema/settings hookups. These give us the layout primitives, basic content sections, and structural pieces we don't need to differentiate on.

ComponentSourceWhat it doesUsed on
<header-section> SKELETON Site header skeleton — logo slot, nav slot, utility slot. We swap content via blocks but keep the structure. All pages
<footer-section> SKELETON Footer with column blocks, newsletter block, social block. Standard pattern. All pages
<cart-drawer> SKELETON Cart drawer with line items, totals, checkout CTA. Skeleton's implementation is solid. All pages
<breadcrumb-nav> SKELETON Breadcrumb trail. We restyle to match hairline-rule aesthetic, no behavior change. All collection & product pages
<pagination-nav> SKELETON Collection pagination. Standard prev/next + page numbers. E collection, H Learn hub, J FAQ
<newsletter-form> SKELETON Email signup with Klaviyo/Shopify Email handoff. Standard pattern. Footer, A homepage
<image-with-text> SKELETON Image-left / text-right or reversed editorial block. Used for the homepage "Why Zebra" sections. A, N, M
<multi-column> SKELETON 2-, 3-, or 4-column block for value props, features lists, partner logos. A, N, O
<rich-text-section> SKELETON Long-form WYSIWYG content section. Used wherever the merchant needs a free-form block. A, M, N, P, I article body
<collage-section> SKELETON Mixed image grid for editorial pages. Used on the About / Made in USA pages. N
<collection-list> SKELETON Grid of collection cards. Used as the entry into the catalog from homepage and from Find Your Fit results. A, G results
<announcement-bar> SKELETON Top-of-page rotating announcement strip. Free shipping thresholds, trade-show promos, etc. All pages, optional
B

Horizon-referenced, Skeleton-built — eight architectural patterns

8 components

Horizon (released alongside the new Shopify editor) pioneered several web-component patterns we want — chip/dropdown/swatch variant picker modes, media stack for galleries, facet groups for filtering. Horizon is proprietary and themes derived from it can't ship to the Theme Store. We read Horizon's source for architectural reference (how they structure the custom element, how state is passed, what events fire) and reimplement in Skeleton from scratch.

ComponentSourceWhat it doesUsed on
<variant-picker>modes: chip · dropdown · swatch · combined HORIZON Variant selector that supports per-option-axis presentation. Color axis = swatches, size axis = chips, voltage axis = dropdown. Horizon's mode-per-axis pattern is the right architecture; Skeleton's default picker is single-mode. D PDP, F compare
<product-gallery>media stack with thumbs & deep-link HORIZON Image + video media stack with thumbnail strip, variant-aware filtering, swipe-on-mobile, fullscreen zoom. Horizon's deep-linking pattern (URL fragments for specific media) is the keeper. D PDP
<filter-sidebar>facet groups, collapsible, count badges HORIZON Collection filter rail with collapsible groups, facet count badges, "clear all" affordance, mobile bottom-sheet variant. Horizon's facet-group architecture handles spec-driven filters cleanly. E collection
<mega-nav>desktop drop, mobile drawer HORIZON Header navigation with mega-menu drops on desktop, accordion drawer on mobile. Horizon's keyboard navigation and focus management is best-in-class for theme code. All pages
<faq-accordion>anchor URLs, expand state in URL HORIZON FAQ-style disclosure with deep-linkable anchors — landing on ?q=installation opens that question. Horizon's URL-state-sync pattern is the architectural keeper. J FAQ, D PDP FAQ block, E collection FAQ
<hero-section>media background, content overlay, CTA HORIZON Hero with image or video background, content overlay with type system support, dual CTAs. Horizon's overlay-darkening pattern reads better than Skeleton's default. A homepage, N, H
<quick-view-drawer>PDP-lite without leaving collection HORIZON Open a product preview in a side drawer from the collection grid without navigation. Useful for spec comparison without committing to PDP. E collection
<product-card>enhanced with spec pills & stock state HORIZON Collection card. Skeleton ships a basic version; we extend to add spec pills (key comparable specs), lead-time/stock pill, badge for Made-in-USA. Horizon-style hover state with secondary image. A, E, G, H
On the rebuild discipline · We read Horizon's source files but never copy code verbatim. The web-component class structure, the CustomEvent patterns, the URL-state-sync approach — those are architectural decisions we adopt. The actual Liquid markup, the CSS class names, the JS implementation — those we write from scratch. A theme derived from Horizon source is barred from the Theme Store; a theme that re-implements patterns Horizon also uses is not.
C

Manufacturing-new builds — nineteen vertical-specific components

19 components

The pieces that distinguish a manufacturing theme from a fashion or supplement theme. These read from the Mock R data layer — spec tables read product_spec_row, document lists read product_document, FAQs read faq_item. Every one is new code. The eleven highest-priority ones get detail cards below; the remaining eight are scoped here.

ComponentPriorityWhat it doesUsed on
<spec-table> detail ↓ P1 Structured specifications grouped by category, US/metric toggle, variant-aware row visibility, mobile horizontal-scroll table. D PDP, E quick-view, F compare
<document-list> detail ↓ P1 Document cards with type icon, file size, language, audience tags. Grouped by document type with collapsible groups. D PDP, L install, M warranty, Mock T
<compare-table> detail ↓ P1 2-4 product side-by-side comparison with structured spec rows. Sticky first column on mobile, sortable, exportable to PDF. F compare
<compatibility-matrix> detail ↓ P1 Variant-level parts-fitment grid. Reads product_relationship + fits_products on the part side. D PDP parts block, K parts-by-model
<find-your-fit-wizard> detail ↓ P1 Multi-step guided product finder. Reads from config metaobjects, narrows candidates per answer, lands on filtered collection. G Find Your Fit
<sticky-page-nav> detail ↓ P1 In-page anchor nav for long PDP pages. Sticky left sidebar on desktop, horizontal scroll-spy on mobile. Reads section IDs from the page. D PDP, I article, M warranty, N Made in USA
<quote-request-form> detail ↓ P1 Quote-only product flow that creates a Shopify Draft Order rather than a normal cart. For high-MOQ or configured products. D PDP, P contact
<volume-pricing-table> detail ↓ P1 Tier-pricing table — 1-9 units / 10-49 / 50-99 / 100+. Reads volume tiers from a product metafield. D PDP, K parts-by-model
<video-gallery> detail ↓ P1 Video cards with type filter, duration badge, transcript expand. Reads product_video. D PDP, L install, H Learn, Mock T
<product-resources> detail ↓ P1 Combined videos + documents block organized by product. The core of Mock T. Mock T (new), L install
<predictive-search> detail ↓ P1 Predictive search with SKU exact-match, compatibility-aware results, document and FAQ inclusion. All pages via header
<stock-state-pill>in-stock · limited · lead-time · pre-order · out P2 Inline pill component showing availability state. Variant-aware. Reads from inventory + lead_time metafield. D PDP, E collection cards
<bulk-order-entry>SKU + qty paste, CSV upload, line edit P2 B2B-style bulk order entry — paste SKU/qty pairs or CSV upload, validates against catalog, builds cart in one action. K parts-by-model, separate bulk-order page
<print-spec-sheet>trigger only — print stylesheet handles render P2 "Print spec sheet" button on PDP. Loads a print stylesheet variant of the page with logo, header, full specs, no nav. D PDP
<faq-section>filtered by attachment P1 Section that reads faq_item attached to the current product, collection, or globally. Renders as <faq-accordion> instances grouped by category. D PDP, E collection, J FAQ
<glossary-index>A–Z scroll-spy, category filter, deep links P2 Glossary page index — alphabetical or category grouping, anchor scroll-spy, deep-link to specific term. Reads glossary_term. J FAQ+glossary page
<distributor-map>map + list, country/region filter, near-me P2 Map + list dual-view of distributors. "Find a distributor near you" by zip lookup. Reads distributor metaobject. O distributors
<application-guide>article template variant with TOC P2 Long-form technical article template with TOC, inline product callouts, reviewer credit, related-products at foot. Variant of the basic article template. I Learn articles
<made-in-usa-badge>inline + standalone variants P2 Branded badge for US-manufactured products. Inline on PDP, standalone block on About / Made in USA page. D PDP, N Made in USA, E collection cards
§ 06 · DETAIL

The high-priority new components, specified.

Eleven of the nineteen Column C components get specified in depth here — the ones with non-trivial data dependencies, multiple variants, or behavior worth pinning down before code. The remaining eight (stock-state pill, print trigger, bulk order, glossary, distributor map, application guide, made-in-USA badge, faq-section) follow simpler patterns and don't need detail cards at this stage.

COMPONENT 01 · MANUFACTURING-NEW

<spec-table>

Structured specifications presented as a grouped table. Replaces the prose-spec paragraphs in current product descriptions with comparable, filterable, machine-readable rows. The defining content type of a manufacturing PDP — every product has one, every buyer reads it.

P1 PDP · COMPARE
DATA DEPENDENCIES
Reads fromKeyHow it's used
product theme.specs List of product_spec_row metaobject references. Primary data source.
variant theme.specs Variant-level spec overrides. Render-time merge: variant rows replace product rows matching by key.
product_spec_row group → product_spec_group Each row references a group; rows render in their group's section.
VARIANTS & STATES
  • fullDefault — all rows, grouped headers, US/metric toggle.
  • comparable-onlyOnly rows where comparable: true. Used in Compare and quick-view drawer.
  • compactInline summary — six most important rows, no group headers. Used on product cards (Column B).
  • printAll rows, no interactive controls, optimized for letter-sized PDF. Used by <print-spec-sheet>.

State: a unit-system toggle (US ↔ Metric) at the top right; selected state persisted to localStorage as preferred-unit-system. Variant-aware: when the variant picker changes, rows with applies_to_variants mismatching the current variant disappear; rows with a variant override re-render with the override value.

EVENTS
  • spec-table:unit-changedFires when user toggles US ↔ Metric. Other spec-table instances on the page sync. Bubbles to document.
  • spec-table:row-highlightedFires when user clicks a row to deep-link / share. Optional anchor scroll behavior.
Implementation note · Mobile: horizontal-scroll table preserves label column as sticky-left. Above 760px: stacked label/value rows. At 960px and up: two-column label/value grid. Group headers always span full width. WCAG 2.2: <table> semantics with <caption> per group; toggle is role="radiogroup".
COMPONENT 02 · MANUFACTURING-NEW

<document-list>

Cards for downloadable documents — manuals, datasheets, drawings, certifications. The visible end of the Mock R product_document metaobject. Replaces the current pattern of 46 scraped PDFs per product with a curated, typed, sized, dated list.

P1 PDP · SUPPORT · MOCK T
DATA DEPENDENCIES
Reads fromKeyHow it's used
product theme.documents Primary list of product_document references on PDP.
variant theme.documents Variant-specific documents (e.g., 220V variant gets a different install guide). Merged with product-level at render.
shop theme.shop_documents Site-wide documents — used on support hub Mock L and as the source for the global "Documents" section.
VARIANTS & STATES
  • grouped-by-typeDefault — collapsible groups by document_type (Manuals, Datasheets, Drawings, Certifications, etc.).
  • grouped-by-audienceAlternative — groups by who needs it (Installers, Engineers, Maintenance). Used on the support hub.
  • flat-listNo grouping — simple chronological-by-revision-date list. Used in compact contexts.
  • filter-barAdds a horizontal filter chip row at the top — toggle by type, audience, language. Used on Mock T.
CARD ANATOMY
  • type iconSVG icon matching document type (manual / sheet / drawing / cert / SDS).
  • titleFrom document.title. Heading for the card.
  • descriptionFrom document.description, ~80 chars.
  • file size + format"PDF · 2.4 MB" from file_size_bytes + file extension.
  • version + revision date"Rev 3.2 · Aug 14, 2025" from version + revision_date.
  • language pillEN / ES / FR / DE etc. from language. Hidden when EN-only and merchant config disables.
  • audience tagsFrom audience list. Optional, configurable per merchant.
  • download CTAPrimary button — direct file link or external_url. Opens in new tab.
  • preview thumbnailFrom thumbnail if set, or auto-generated from PDF page 1 at render.
Print-friendliness · The <document-list> renders cleanly under print stylesheet — preview thumbnails drop to 1-bit, download CTA becomes a full URL printed beneath the title, file sizes and dates preserved. Lets the merchant print a "what comes with this product" reference sheet.
COMPONENT 03 · MANUFACTURING-NEW

<compare-table>

Two-to-four product side-by-side spec comparison. The buyer journey on Mock F. Reads spec rows from each compared product, aligns matching key values across columns, surfaces the differences. Print/PDF export so engineers can attach the comparison to a vendor approval form.

P1 MOCK F
DATA DEPENDENCIES
Reads fromKeyHow it's used
product (n) theme.specs Spec rows from each compared product. Rows with same key align into one comparison row.
product (n) price, title, featured_media, handle Native Shopify fields for the column headers.
URL ?ids=A,B,C,D Comma-separated product IDs in query string. URL is shareable and supports up to 4.
VARIANTS & STATES
  • desktopN-column grid, first column is row labels. Up to 4 products at a time.
  • mobileHorizontal scroll. First column (row labels) sticky-left.
  • differences-only filterToggle to hide rows where all compared products have the same value. Surfaces only the differentiators.
  • printLandscape letter, optimized for vendor approval submission. Header includes product images and SKUs.
CONTROLS
  • add columnSearch-as-you-type product picker. Adds to URL query string.
  • remove column×-button per column header. Removes from URL query string.
  • unit toggleUS ↔ Metric, syncs with <spec-table> via shared event.
  • share URLCopy-to-clipboard with the current state encoded.
  • export PDFTriggers print stylesheet with comparison layout.
Empty state · Landing on the compare page with no products yet shows a product-picker chooser asking the buyer to select 2-4 products. With one product, prompts to add another. The component handles the empty and partial states inline rather than hiding behind a separate route.
COMPONENT 04 · MANUFACTURING-NEW

<compatibility-matrix>

Variant-level parts fitment. Answers "does this replacement tube fit my ZVA8-08?" without forcing the buyer to read prose. Two data sides — parent-curated relationships and child-declared fits_products — render into one unified matrix.

P1 PDP · MOCK K
DATA DEPENDENCIES
Reads fromKeyHow it's used
parent product theme.related_products Curated relationships — product_relationship entries grouped by relationship_type.
storefront query products(query: "metafield:theme.fits_products contains variant_id") Reverse lookup — find all products declaring the current variant in their fits_products.
part product theme.fits_products List of variant references this part fits. Used for the reverse lookup above.
VARIANTS & STATES
  • grouped-by-relationship-typeRequired accessories first, then optional accessories, then replacement parts, then consumables. Default on PDP.
  • flat-gridSingle grid of part cards, sorted alphabetically. Used on Mock K parts-by-model where relationship type is less relevant.
  • matrix-with-modelsFor Mock K — rows are parts, columns are parent variants, cells indicate fitment. Cross-product compatibility view.

Variant-aware on PDP: when the parent variant picker changes, the matrix re-queries to show only parts that fit the new variant. Implemented via a debounced fetch with a brief loading state on the matrix region.

Performance note · The storefront API query is fine for current catalog scale (~120 products). If the catalog grows past ~1,000 products with dense compatibility relationships, the query becomes slow enough to warrant a build-time JSON of variant-to-parts mappings served from theme assets or R2. Decision deferred until measured.
COMPONENT 05 · MANUFACTURING-NEW

<find-your-fit-wizard>

Multi-step guided product finder. The whole of Mock G. Buyer who doesn't know the right product answers 3-6 questions and lands on a filtered collection with the matching candidates. The structured alternative to scrolling the catalog for buyers who don't know exact terminology.

P1 MOCK G
DATA DEPENDENCIES
Reads fromKeyHow it's used
shop theme.fyf_intent_paths A list of intent paths (e.g., "I have a CNC machine sump"). Each path has steps; each step has options that narrow candidates. Phase 1 hardcodes the paths; Phase 2 promotes to a metaobject (finder_intent_path).
collection products Final step lands on a collection-page route with filters pre-applied via URL params.
STEPS & STATE

Three-to-six step flow per intent path. Each step asks one question with 2-5 answer chips. Selected answer either advances to next step or branches to a different sub-path. Final step shows candidate count and "See n matching products" CTA, which navigates to the collection with filters applied.

State persists in URL query string — ?path=cnc-sump&step=2&a1=oil&a2=large — so deep-linking to a mid-flow state works, and bookmarking partial progress is viable for buyers who pause to grab specs from their shop floor.

VARIANTS & STATES
  • card-gridEach step renders as a grid of large answer cards with icon + label + description.
  • chip-rowCompact alternative for steps with 2-4 simple answers.
  • progress-railTop-of-component breadcrumb showing path + steps completed. Click any prior step to revise.
  • results-previewLive count of matching products updates as buyer narrows. "37 products match → 12 match → 4 match" feedback.
Editorial care · The wizard's value depends entirely on the quality of the intent paths and the answer copy. A bad path is worse than no path — it tells the buyer the brand doesn't understand its own products. The intent paths need editorial review by someone who talks to customers, not just defined in admin and shipped.
COMPONENT 06 · MANUFACTURING-NEW

<sticky-page-nav>

In-page anchor navigation for long pages — PDP, articles, warranty page, Made in USA. Sticky left sidebar on desktop with scroll-spy; collapses to horizontal scroll-spy on mobile. The pattern that makes a PDP with eight stacked sections feel navigable rather than overwhelming.

P1 PDP · LONG-FORM PAGES
DATA DEPENDENCIES

None directly — the component scans the page for sections matching a configurable selector (default section[data-page-nav]) and reads each section's id and data-page-nav-label attribute. No metaobject data required. Section authors opt in by adding the attribute when they want a nav anchor.

VARIANTS & STATES
  • desktop-left220px wide left sidebar, sticky from top of content. Section labels with scroll-spy highlight.
  • mobile-barHorizontal scrollable chip row sticky-to-top below header. Same scroll-spy logic.
  • collapsedSingle "On this page" disclosure that expands on click. Used when vertical space is constrained.

State: current section highlighted as the user scrolls (IntersectionObserver). Click on a nav item smooth-scrolls to the section and updates the URL hash without a page reload.

WCAG note · Nav is a real <nav> landmark with aria-label. Click targets meet 44×44px touch target minimum. Scroll-spy doesn't trap focus — keyboard users tabbing through sections never get stuck. Skip-link to main content remains on the page above this nav.
COMPONENT 07 · MANUFACTURING-NEW

<quote-request-form>

Quote-only flow that creates a Shopify Draft Order rather than a normal cart. For high-MOQ products, configured products, products with negotiated pricing. The buyer fills the form with their specs, the merchant gets a draft order in admin with the buyer's company info, the merchant adjusts pricing and sends an invoice.

P1 PDP · CONTACT
FIELDS
  • product + variantAuto-filled from PDP context. Hidden if launching from contact page.
  • quantityNumber, defaults to 1.
  • company nameRequired.
  • contact nameRequired.
  • emailRequired, validated.
  • phoneOptional.
  • timelineSelect — "ASAP / 1-2 weeks / 1 month / 3 months / 6+ months". Required.
  • notesFree-text, optional. Custom requirements, special configurations.
SUBMISSION FLOW

On submit: POST to a theme app proxy endpoint that creates the Draft Order via Admin API draftOrderCreate. Buyer info goes to the order's customer field; product/qty goes to line items; notes go to order note. Merchant receives email notification, sees order in admin, adjusts price as needed, sends invoice — buyer pays via the Shopify invoice flow.

Confirmation: post-submit, show success state with "We'll respond within one business day" copy. Send buyer a confirmation email via Shopify Email or transactional service. The buyer's email is opted in for transactional follow-up only, not marketing.

Admin API scope · Requires write_draft_orders on a custom app token. The app proxy approach keeps the token server-side rather than exposing it client-side. The merchant configures the token once in theme settings (Mock Q has a hidden settings group for this).
COMPONENT 08 · MANUFACTURING-NEW

<volume-pricing-table>

Tier-pricing table on the PDP — 1-9 units at full price, 10-49 at 5% off, 50-99 at 10% off, 100+ at 15% off. Common for parts and consumables where buyers stock up. Tier discounts apply automatically at cart time via Shopify Functions; the table is the customer-facing presentation.

P1 PDP · MOCK K
DATA DEPENDENCIES
Reads fromKeyHow it's used
product theme.volume_tiers JSON metafield — array of {min, max, discount_pct} tiers. Source of truth for both display and cart-time calculation.
product theme.volume_tiers_enabled Boolean. Merchant can flip off display without removing tier data.
VARIANTS & STATES
  • inlineCompact 3-4 row table inside the PDP buy-box area. Default.
  • expandedFull table with per-tier price, savings amount, "you save $X" call-out. Used as a stacked section below buy-box.
  • current-tier-highlightAs buyer changes quantity, the active tier highlights. Real-time savings number updates above the cart button.
Cart-time discount · The table presents discounts; the actual discount is applied by a Shopify Function (Discounts API) reading the same metafield. The visual and the transactional logic share one source of truth, so the table can never lie about what the buyer will pay.
COMPONENT 09 · MANUFACTURING-NEW

<video-gallery>

Video cards with type filter, duration badge, transcript expand. The visible end of the Mock R product_video metaobject. Used in three contexts: PDP video section (per-product), Learn hub featured videos (curated), and the new Mock T video library page (full catalog).

P1 PDP · LEARN · MOCK T
DATA DEPENDENCIES
Reads fromKeyHow it's used
product theme.videos List of product_video on the PDP.
variant theme.videos Variant-specific videos. Merged with product-level at render.
shop theme.featured_install_videos Curated featured list for the Learn hub and support hub.
storefront query metaobjects(type: "product_video") Full catalog query for the Mock T library page.
CARD ANATOMY
  • thumbnailFrom thumbnail field or fetched from platform.
  • duration badgeBottom-right overlay, "3:07" from duration_seconds.
  • type pillTop-left overlay — Install / Demo / Tutorial / Troubleshooting.
  • titleFrom title.
  • descriptionFrom description, 1-2 lines.
  • audience tagsFrom audience. Optional, configurable.
  • transcript expandIf transcript set, a "Read transcript" disclosure expands inline. Critical for SEO and accessibility.
  • chapter markersIf chapters set, render as a clickable list below the video. Clicking jumps to the timestamp.
PLAYER VARIANTS
  • thumb-then-embedDefault — thumbnail with play overlay. Click loads the iframe embed (saves load time, avoids YouTube cookie load on initial render).
  • modal-playerClick opens video in a modal overlay. Used in dense grids.
  • inline-autoplayHero variant for featured videos — autoplays muted on viewport entry. Used sparingly.
JSON-LD emission · Each video card emits its own VideoObject structured data with title, description, thumbnail, uploadDate, duration. With transcript and chapters, the rich result eligibility improves substantially. Critical infrastructure for being surfaced in Google video carousels.
COMPONENT 10 · MANUFACTURING-NEW

<product-resources>

The combined videos + documents block organized by product. The core of the new Mock T page. Each product section shows the product's videos (via <video-gallery>) alongside its documents (via <document-list>) so a buyer or installer has every reference in one view.

P1 MOCK T · L INSTALL
DATA DEPENDENCIES
Reads fromKeyHow it's used
product theme.videos · theme.documents Both lists per product, rendered side-by-side or stacked.
storefront query products(...) For the Mock T library page — query all products with at least one video or document attached. Phase 1 strategy: paginate by collection. Phase 2: dedicated collection-of-collections route.
LAYOUT VARIANTS
  • stackedVideos section, then documents section, stacked vertically. Default for narrow viewports and individual product views.
  • two-colVideos left, documents right. Used at wide viewports when both lists are substantial.
  • tabsVideos tab and Documents tab. Used when one or the other is very long. Tabs share URL state for deep-linking.
  • library-listFor Mock T — products listed alphabetically by family, each with its videos+docs section. Filterable by product family at the top.
FILTERING (LIBRARY VARIANT)

On Mock T, a sticky filter rail at the top of the page lets the user narrow by product family (Tube skimmers, Belt skimmers, Coalescers, Refractometers, etc.), by resource type (Videos only, Documents only, Both), by audience (Installer, Engineer, Maintenance), and by language. Filter state is in URL query string so the page is shareable and search-engine-crawlable in pre-filtered states.

SEO design · The library page is a high-value landing page for terms like "Zebra tube skimmer install video" or "ZVA8 datasheet PDF". Each filtered state needs a clean URL and a unique page title. Rendering happens server-side via Liquid so all states are crawlable; client-side JS only handles the filter transitions.
§ 07

Page × component matrix.

Where each component appears across the fourteen page mocks. Helps with build sequencing — components used on the most pages get built first; components used on only one or two get scoped later. Also surfaces the page-by-page complexity gradient.

Component ADEFGHIJKLMNOPT*
COLUMN A · SKELETON
header-section
footer-section
cart-drawer
breadcrumb-nav
pagination-nav
newsletter-form
image-with-text
multi-column
rich-text-section
collage-section
collection-list
announcement-bar
COLUMN B · HORIZON-REFERENCED
variant-picker
product-gallery
filter-sidebar
mega-nav
faq-accordion
hero-section
quick-view-drawer
product-card
COLUMN C · MANUFACTURING-NEW
spec-table
document-list
compare-table
compatibility-matrix
find-your-fit-wizard
sticky-page-nav
quote-request-form
volume-pricing-table
video-gallery
product-resources
predictive-search
stock-state-pill
bulk-order-entry
print-spec-sheet
faq-section
glossary-index
distributor-map
application-guide
made-in-usa-badge

● used · ○ optional / merchant-configurable · T* = Mock T pending

Hottest components · The components on every page (header, footer, cart drawer, mega-nav, predictive search) are the ones that need to ship first and ship right — every other page depends on them. The lowest-traffic components (collage section, distributor map, glossary index) can ship later in the build sequence without blocking other work.
§ 08 · NEW DELIVERABLE

Mock T — Product Resources Library.

A new page surfaced this session — a library where users can view all videos and documents organized by product. The data layer for it already exists (Mock R defines product_video and product_document); the components for it are specified above (<product-resources>, <video-gallery>, <document-list>); the page itself is the deliverable that's still to come.

Mock T · upcoming

Product Resources Library / pages/resources

A single library page showing every product's videos and documents in one place. Filterable by product family, resource type, audience, and language. Each product gets its own section with both videos and documents stacked together. The single canonical reference page when a buyer or installer asks "what do you have on the ZVA8?"

Where it lives in the IA
Under Support, alongside parts-by-model (Mock K), install-hub (Mock L), warranty (Mock M), contact (Mock P). The fifth support page in the 5-top-level IA.
Page structure
  • Hero with page title, search input scoped to this library
  • Sticky filter rail — product family · resource type (videos / docs / both) · audience · language
  • Per-product-family sections, each with a small header (family name + product count) and a <product-resources> instance per product showing its videos+docs
  • "On this page" sidebar nav (uses <sticky-page-nav>) listing product families
  • Empty/loading states for each filter combination
Components needed (all in this Mock S)
  • <product-resources> — the combined videos+docs block (specified)
  • <video-gallery> — for the video portion (specified)
  • <document-list> — for the document portion (specified)
  • <sticky-page-nav> — for the family index sidebar (specified)
  • <predictive-search> — scoped to this library page (specified)
  • <filter-sidebar> — for the filter rail (Column B, Horizon-referenced)
Data layer
Already specified in Mock R. product_video entries (~250 projected), product_document entries (~60 projected), attached to products via theme.videos and theme.documents respectively. No new metaobjects required for this page.
SEO opportunity
High-value landing page for searches like "Zebra ZVA8 install video", "tube skimmer datasheet PDF", "coalescer manual download". Each filtered state needs server-side rendering for crawlability — Liquid does the heavy lifting; client-side JS only handles state transitions.

I'll build Mock T as the next deliverable after this. It's a single-page mock — same density as Mocks A, D, E — and reuses components already specified here, so the work is the page layout and the filter behavior rather than new data layer or new components.

§ 09

Build sequence — what ships in what order.

Components have dependencies — predictive search needs header to host it; spec table needs product_spec_row metaobjects to exist; sticky page nav needs sections marked up correctly to anchor to. The build sequence respects those dependencies and front-loads the components that unlock the most pages.

  1. Foundation — design tokens, layout primitives
    CSS custom property contract from § 02 set up in the Skeleton fork. Layout primitives — page-padding, gutter system, section spacing scale — established. Theme settings from Mock Q wired up so swapping color schemes and type stacks works end-to-end before any component-level work.
    ~1 week · no component blockers · enables all subsequent stages
  2. Header / footer / nav — the chrome everywhere
    Skeleton header and footer with the 5-top-level IA hookup. <mega-nav> rebuilt from Horizon reference. <predictive-search> built with product+article+document+FAQ+glossary results. <cart-drawer> styled but unchanged structurally. <announcement-bar> configurable.
    ~2 weeks · blocks all pages · highest visibility
  3. PDP core — the highest-value page
    <product-gallery>, <variant-picker>, <spec-table>, <document-list>, <stock-state-pill>, <sticky-page-nav>. The full PDP layout from Mock D with all eight stacked sections. Quote-request and volume-pricing land in this stage too if their metafield data is seeded.
    ~3 weeks · depends on metaobjects existing · unlocks Mock D
  4. Collection & compare — the path to PDP
    <filter-sidebar> with spec-driven facets. <product-card> with spec pills and stock state. <quick-view-drawer>. <compare-table> with full export support.
    ~2 weeks · depends on spec data quality · unlocks Mocks E and F
  5. Find Your Fit + parts-by-model — guided paths
    <find-your-fit-wizard> with editorially-curated intent paths. <compatibility-matrix> in its full grid form. <bulk-order-entry> for the parts-by-model bulk path.
    ~2 weeks · depends on editorial review · unlocks Mocks G, K
  6. Learn + library — content surfaces
    <video-gallery> in all three deployment contexts (PDP / Learn hub / library page). <product-resources> for the library page. <application-guide> article template. <faq-section> driven by faq_item. <glossary-index>.
    ~2 weeks · depends on content review · unlocks Mocks H, I, J, L, T
  7. Support + about — editorial pages
    Warranty, Made in USA, About, distributor map, contact. Mostly reuses earlier components; the only new piece is <distributor-map> if we choose that over a static list-only approach.
    ~1 week · low component dependency · unlocks Mocks M, N, O, P
Critical-path observation · Stages 1-3 are the long pole — about six weeks to get to a PDP that can be looked at. Everything else parallelizes once the foundation, the chrome, and the PDP are in place. Stages 4-7 can overlap heavily; if there's a second person on the build, they can pick up Stage 4 (collection/compare) while Stage 3 (PDP) is finishing.