How the Swan Bend Brewing Co. demo was made.

Concept

Swan Bend Brewing Co. is a fictional working brewery on the bend of the Swan at Bassendean that hosts functions in its barrel room, on the taproom floor or across the whole venue — 20 to 120 guests on tasting paddles, shared feasts or a plated long table. The audience is the Guildford couple planning a 40th, the Midland office Christmas organiser and the Maylands wedding party; the page has one job: a function enquiry that arrives with the space, guest count, day, package and extras already priced, and the weekend whole-venue minimum spend declared honestly before anyone rings.

The signature element is the Function Booker: a drawn SVG taproom that lights the zone you pick, fills the tables with guests as you step the count, changes the windows with the day, draws what's on the tables for each package, and chalks the estimate onto a board hanging over the bar — the board carrying a second line only when the weekend minimum actually applies.

Palette — copper and stout

Argued from a copper brew kettle, a pint of stout, a paper beer label and fresh hop cones: a brown-black ground, paper-cream ink, copper for the calls to action and hop-green for lines, tap handles and chip outlines. Every figure below was measured from the shipped tokens with WCAG arithmetic during Pass 1 (not estimated) and matches the spec's computed hypotheses to the decimal.

Because this is a dark site, the two-token remedy runs the other way: the argued copper stays for fills and marks, and the lighter copper-ink carries small copper text. The copper CTA carries dark, ground-coloured labels rather than white (white on #C8803A would measure under 3:1).

Type

Bricolage Grotesque 700/800 for display — a characterful grotesk with the slightly squared bowls of a can label, set tight (−0.015em) for the headline, the chalkboard figure and the display line over the taproom. Karla for everything else: a workhorse humanist sans that stays legible at 13–15px in the ledger and chips and holds 17px body comfortably on a dark ground. Display moment: the rest-state line "60 GUESTS · BREWER'S TABLE · $5,950" set uppercase over the drawn room — it is live, re-deriving from the booker state, so the figure can never drift from the board.

Techniques

• Inline SVG taproom (800×470 viewBox) — walls, clerestory windows, a barrel pyramid, the bar with eight tap handles, the copper kettle behind glass (linear-gradient copper, glass gradient, diagonal highlight), three pendants with radial-gradient glow discs, long tables drawn as shallow trapezoids with a front edge so back-row guests sit behind and front-row guests sit over the table.
• Procedural guests — seats are generated per table (centre-out order so small groups sit together), zone lists round-robin across tables, and whole-venue interleaves the floor and barrel lists. The scene draws at most 40 figures; the tag prints the true count and, when capped, "40 drawn".
• State via CSS classes, never presentation attributes — day/night swaps pane gradients and wall fills through .scene.day rules; zone dimming is a class-toggled opacity on overlay rects; figure entrances transition on an inner group while the outer group carries the SVG transform (the W16/W17 split).
• Ambient rAF loop — kettle steam (two re-parameterised cubic paths plus two rising puffs) and pendant pulses, driven by a zero-clamped, capped delta; paused on document.hidden; not started under reduced motion (which renders a settled room with the glows at their base level).
• Dual-speed redraw — first draw staggers figures at 26 ms (1.5 s cap); every later change rebuilds at 11 ms (520 ms cap). A token is bumped in the control handler before the state swap, so an in-flight reveal or settle timer from a previous click can never land on a rebuilt scene.
• HTML chalkboard over the SVG — sized with container-query units (cqw/cqh) so it scales with the scene; on-scene at ≥641 px, docked beneath the room (with the figure tag) at ≤640 px.
• Procedural service-area map — SVG river on a grid pattern, labelled suburbs, a dashed reach ring and a textPath river label.
• No libraries; CSS and JS inline; Google Fonts only.

How the Function Booker is priced

State is a single object (guests, space, explicit space, day, package, tour, acoustic). resolveSpace() applies the capacity locks: a space is disabled when guests exceed its cap; if the current space no longer fits, the selection is forced to the smallest fitting space; and the user's last explicit chip choice is restored the moment it fits again — a forced intermediate is never restored, which is what makes the 20 → 120 → 60 rapid-fire end on the whole venue and only return to the barrel room at 40. compute() then bills package = guests × per-head, clamps that line alone to $6,000 for Friday–Saturday whole-venue bookings, and adds the room fee, the tour (actual guests × $15, outside the minimum) and the acoustic set. The badge, the ledger, the display line, the visually-hidden text mirror, the form pre-fill and the window.__brewery probe all read from that one result.

Worked examples asserted against an independent oracle

The harness reimplements the pricing from the anchors above (not from the page's code) and asserts the badge, ledger, display line and text mirror for every row, including note absence. Grid floors cross-check: barrel $1,100, taproom floor $1,350, whole venue $1,900 — the same figures the services grid prints.

Conversion decisions

• Above the fold at 375 px: business name in the masthead, the value proposition naming trade and area as the h1, the "Enquire about a date" primary CTA, a tel: button and three trust chips — all visible without scrolling; the sticky call/enquire bar sits beneath.
• Two CTAs, one primary. Function organisers want a date held, so "Enquire about a date" leads and the phone is secondary — but the number is a tap away in the header, the hero, the enquiry section and the sticky bar, because a Friday-night organiser rings.
• The booker sits beside the hero, not below it, so the 1200×750 capture shows the drawn room and the $5,950 chalkboard with the headline. Its "Enquire with this function" button pre-fills the form and moves focus to the name field.
• Form fields: name, phone, suburb, occasion (birthday / work function / wedding / other), preferred date as free text (organisers have "a Friday in March", not an ISO date), and the function textarea pre-filled from the booker and left editable. Front-end validation with per-field messages, aria-invalid, focus to the first error, v-flag-safe patterns. The confirmation panel is hidden on load and on an empty submit and appears only after a valid submit; copy stays in the "thanks / received / we'd call" family and says plainly that the demo sends nothing.
• Honest minimum spend. The $6,000 weekend whole-venue minimum is on the booker (badge + ledger + mirror), in the whole-venue space card, in the services grid and in the FAQ — the same sentence everywhere, so the page never argues with itself. Public holidays are a designed price-less "quoted" line in the FAQ only.
• Locks that explain themselves. Over-capacity spaces disable with "seats up to 40 — 90 guests won't fit" rather than silently no-op, and the forced selection is visible on the chips, the tag and the ledger line.

Local SEO we'd implement for the real business

The demo page ships only WebPage / WebSite / BreadcrumbList JSON-LD naming itself a demonstration — fictional business data in a real index would be dishonest markup. For the real brewery we would ship a Brewery entity (the exact schema.org subtype under FoodEstablishment) with opening hours, geo, the function-enquiry action, and real reviews fed from the review platform, plus Google Business Profile categories "Brewery" and "Function room facility", an events feed and a tap-list page. The shape:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Brewery",
  "name": "Swan Bend Brewing Co.",
  "image": "https://www.swanbendbrewing.example/taproom.jpg",
  "url": "https://www.swanbendbrewing.example/",
  "telephone": "+61 8 9000 0364",
  "priceRange": "$$",
  "servesCuisine": "Modern Australian",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "(real street address)",
    "addressLocality": "Bassendean",
    "addressRegion": "WA",
    "postalCode": "6054",
    "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -31.9, "longitude": 115.94 },
  "openingHoursSpecification": [
    { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Wednesday","Thursday"], "opens": "16:00", "closes": "22:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Friday", "opens": "12:00", "closes": "00:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "11:00", "closes": "00:00" },
    { "@type": "OpeningHoursSpecification", "dayOfWeek": "Sunday", "opens": "11:00", "closes": "20:00" }
  ],
  "areaServed": ["Bassendean","Guildford","Midland","Maylands","Bayswater","Morley","Ascot","Eden Hill"],
  "amenityFeature": [
    { "@type": "LocationFeatureSpecification", "name": "Function room", "value": true },
    { "@type": "LocationFeatureSpecification", "name": "Brewery tours", "value": true }
  ],
  "potentialAction": {
    "@type": "ReserveAction",
    "target": "https://www.swanbendbrewing.example/functions#enquire",
    "name": "Enquire about a function"
  },
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.9", "reviewCount": "184" },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "(real reviewer)" },
      "datePublished": "2026-06-14",
      "reviewRating": { "@type": "Rating", "ratingValue": "5" },
      "reviewBody": "(real review text pulled from the review platform)"
    }
  ]
}
</script>

Alongside the schema: a functions landing page per space with its own h1 and FAQ, suburb pages only where the brewery genuinely draws from (Guildford, Midland, Maylands), Core Web Vitals kept green by keeping the scene SVG inline and fonts to two families, and the review feed wired so the on-page reviews and the markup come from the same source.

What changes for the real client

• Their photos and their room. The drawn taproom is the demo's way of showing the spaces without stock photography; the real build would redraw it to the actual floor plan (their capacities, their table count) and pair it with their photography.
• Function management: the enquiry would post into iVvy or Tripleseat (the function-management platforms venues of this size run), carrying the booker's structured scenario — space, guests, day, package, extras, estimate — so the functions manager replies with a proposal, not a question.
• Taproom tables: Now Book It for walk-in and small-group reservations, kept separate from the functions flow.
• The bar tab and the minimum spend: Square or Lightspeed POS reporting the night's spend against the package, with the minimum-spend gap reconciled on the tab.
• Accounts: Xero for invoicing the room fee and package deposit.
• The tap list: an Untappd feed for the eight taps, so the "what's a tasting paddle" answer always names what's actually pouring.
• Reviews: their Google review feed replaces the three demo reviews, and the same feed populates the Review markup above.

Iteration log