How Latitude South Travel was made

Palette — horizon-white departure morning

The wave's cool blue-white light site, argued from the studio's wall chart: pale sky off the morning ocean, deep water, inked routes, and one lei-coloured pin on arrival. The line/mark accent (ultramarine) and the secondary (coral) both fail 4.5:1 as small text on this ground, so body copy never uses them — the ink/line split gives text its own tokens and keeps the bright colours for routes, rules and pins.

Type

• Space Grotesk (display) — chart-room letterforms with just enough instrument character; the "32° south" masthead moment.
• Figtree (body, UI) — a warm workhorse that stays legible at 16px+ on a phone in one hand.
• Azeret Mono (figures) — every fare, night-count and total is tabular mono, because the whole page is an argument about honest arithmetic.

The signature — the Trip Sketcher

Destination chips (Bali / Japan / Europe / South Pacific cruise ex-Fremantle), travellers and nights steppers, and comfort chips drive a procedural SVG chart of the Indian Ocean rim. The chart is built entirely in JS at runtime: a 20° graticule, ~19 hand-set coastline polylines, a dashed 32°S latitude line through Perth, and routes that are true great circles — each is a spherical slerp between Perth and the destination sampled at 64 points, projected equirectangular (lon −12°→158°, lat 62°→−46°). The route dash-draws with butt caps (the W15 round-cap dot lesson), one tide-mark per night is placed with getPointAtLength, and the coral pin drops with a one-shot ring pulse when the arc completes. The cruise renders the coastal leg north-west out of Fremantle instead of a flight arc — illustrative of "it leaves from home", with itineraries quoted exactly at booking.

The planning card prints the full maths line by line in mono under a declaration that is part of the card, always visible: "Planning figures from recent bookings, not quotes — fares move daily; we quote exact at booking." Dual-speed redraw per the W21 rule: the load entrance takes 1.4s and rests at two-thirds arced (pin not yet dropped, a marker patrolling the drawn portion so the demonstration is alive at any capture instant); every subsequent state change animates in 520ms. Reduced motion renders the route complete with the pin down, no patrol. State probe window.__travelagent carries dest, travellers, nights, comfort, total, rooms, drawn and a settled flag; QA gates on state, never on seconds. A second-read detail: all four routes Latitude South inks are on the chart wall faintly the whole time — choosing a destination just inks one of them boldly.

Pricing model — shape and derivation

Per-person flights + per-room accommodation + per-person daily allowance, each pinned per destination and comfort tier. Rooms are 1 room per 2 travellers, rounded up — stated on-card, so a family of three sees the second room appear in the maths, not in the fine print. The cruise has no flights line ("it leaves from home — that's the point"); fares are per person twin-share per night, the comfort chips relabel to inside / balcony / suite, and the shore allowance is deliberately flat at $45 pp/night whatever the cabin — a documented pricing statement (the ship feeds you either way), not an invented gradient. The $180 trip-design fee sits outside the band (credited in full at booking), which is why the sketcher's cheapest outputs equal the services grid's "from" floors exactly.

Zero spec corrections — all worked examples were pure anchor arithmetic and every one matched the implemented model to the dollar.

Conversion decisions

• The sketcher lives in the hero and shares the 1200×750 thumbnail viewport with the masthead — the signature is the pitch, and its declaration line does the honesty work before anyone scrolls.
• The $180 fee is stated three times (hero note, services grid, card footnote) with the same sentence — "credited in full when you book" is the objection-killer, so it never hides.
• Pre-fill happens only on the explicit "take this sketch" button, not on load — the enquiry starts honest (and the empty-submit validation probe stays meaningful, LEARNINGS W15).
• The date field is optional with a "dates flexible" checkbox — travel briefs are soft-dated; requiring a date loses the "sometime in spring" family. Name, phone and email are required because rebooking-at-2am is a phone product.
• "The trip, in one sentence" replaces a job-description textarea — it matches how people actually brief an agent and gives the callback a script.
• Mobile sticky bar = Call + Plan my trip, both ≥44px; the header keeps the tel: link at every width.

Local SEO we'd implement for the real business

This demonstration page ships only WebPage schema naming it a demo — fictional structured data in a real index would be dishonest markup. A real Latitude South would ship TravelAgency + review schema like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TravelAgency",
  "name": "Latitude South Travel",
  "url": "https://latitudesouthtravel.com.au",
  "telephone": "+61 8 XXXX XXXX",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "…", "addressLocality": "Subiaco",
    "addressRegion": "WA", "postalCode": "6008", "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -31.949, "longitude": 115.826 },
  "openingHoursSpecification": [{ "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00", "closes": "17:30" }],
  "priceRange": "$$",
  "areaServed": "Perth, Western Australia",
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.9", "reviewCount": "187" },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "…" },
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "reviewBody": "…"
  }]
}
</script>

What would change for the real client

• Live planning bands — the sketcher's rates fed from GDS/consolidator fares (Sabre/Amadeus-style) and supplier-direct APIs instead of pinned constants, refreshed nightly.
• Mid-office & client account — Tramada/TravelWorks-style back office, so the "who's been paid what, when" ledger on the page is a real screen, not a promise.
• Itinerary delivery — Axus/Travefy-style branded trip apps replacing the demo confirmation.
• Payments — Stripe deposits for the $180 session, credited automatically at booking; Xero behind it.
• Reviews — a review request timed to the flight home, feeding the schema above; real photography of the studio and the chart wall.

Iteration log

Techniques

• Procedural SVG only — the ocean chart, coastlines, routes, metro map and every mark are runtime-built SVG; no raster, no libraries, fast on 4G.
• Great-circle slerp — routes are real spherical interpolations, so the Japan arc bows exactly as the chart wall in a real studio would show it.
• Dash-draw with state probe — stroke-dasharray reveal driven by rAF with an eased 0→target fraction, settled flag exposed for QA, paused when the tab hides.
• System honesty — reserved (08) 9000 0282 phone pattern, suburb-level address, placeholder ATAS/ABN, WebPage-only schema, reviews as declared demo copy.