Anatomy of a Block: Time, Place, Action, Story
Most of an itinerary is blocks — one per moment, dozens per trip. Here's the ten-field anatomy that distinguishes a block that reads as airport signage from one that reads as editorial.
A working seven-day itinerary has somewhere between twenty and forty blocks. A block is one moment: a meal, a transfer, a tour, a check-in, an activity, a free-time window, a flight, a note. The cover and the welcome note set the tone, but the blocks are where the traveler actually spends time reading the document.
Most premium itineraries fail in the blocks. Not because the blocks are wrong — the times are correct, the addresses are right — but because every block is rendered at the same density. A 09:00 pickup is given the same visual weight as a three-Michelin-star dinner. The reader's attention is flattened. The trip stops having a shape.
The fix is not to write more. The fix is to know what each block is doing and use only the fields that do it.
The ten fields
A myDMC block carries up to ten fields. Five are structural (time, type, title, description, location). Three are type-specific (metadata, photo, wear/bring). One is editorial (pull-quote). One is operational (contingency / Plan B). The order they render in is the order they should be written:
- Time. Specific (09:30), windowed (15:00–17:00), or labeled (Evening). The right format depends on the block — see the section below.
- Type. 10 options: meal, tour, pickup, transfer, check-in, check-out, activity, flight, free-time, note. The type drives the metadata grid.
- Title. Short, italic on the rendered page. 4–7 words. "Lunch at Konoba Astarea" — not "Group lunch reservation at the family-run Konoba Astarea restaurant".
- Description. 1–3 sentences. What's happening, framed as the traveler will experience it. Not what the DMC arranged.
- Type-specific metadata. Restaurant + dress code for meals. Driver + plate + duration for pickups. Hotel + room count for check-ins. The metadata grid only renders fields you set — empty fields produce no row.
- Inline photo. 16:9, optional. Only for blocks where the photo is doing work the description can't (the specific dish, the specific boat, the specific view).
- Wear / bring. Optional tag rows. "Smart-casual; closed-toe shoes" or "Sun hat; reef-safe sunscreen; cash for the lunch stop." Don't pad this — the words 'optional' and 'recommended' aren't useful.
- Pull-quote. Optional italic side-rule. One sentence from a writer's voice. Used sparingly — pull-quotes only land if they're scarce.
- Location. Google Maps share URL + place label. Single line on the rendered page; click-through opens the map on the traveler's phone.
- Plan B / contingency. Optional. One line. "If the swell is over 1.5m, the boat day moves to Mljet's interior trail instead." Shows as a quiet accent line in the in-app preview, and the whole trip re-renders around it under ?variant=plan-b. Not yet carried by the Generate PDF pipeline.
Not every field is used on every block. A 09:00 hotel pickup on the way to the airport: time, type, title, location. Four fields. A welcome dinner at a Michelin restaurant: time, type, title, description, metadata (restaurant + dress code + reservation name + chef's tasting menu), pull-quote, photo, location. Eight fields.
Time: which format for which block
- Specific time (09:30). Anything booked at a fixed time — pickups, restaurant reservations, museum entry tickets, boat departures. The traveler reads the specific time and the block becomes binding.
- Window (15:00–17:00). Anything that has a soft start and soft end — free time at the beach, browsing in town, a tasting that takes 'a couple of hours.' The window signals flexibility without being vague.
- Labeled (Morning, Afternoon, Evening). Used sparingly. Mostly for free-time blocks where the time slot is genuinely undefined. 'Evening' is the right label for 'we'll figure out dinner together once we see how the day lands.'
The most common time mistake is specific times applied to windowed activities. "11:30 — beach time" makes the reader think they need to be on the beach at 11:30 specifically. The window — "11:30–14:00 — beach time" — communicates the same plan without manufacturing anxiety.
Type: choosing the right one
The block type drives the metadata grid: each type has its own set of fields the renderer surfaces. Picking the wrong type usually shows up as missing metadata.
- meal
- Restaurant, reservation name, dress code, chef's recommendations. Used for any booked meal — breakfast, lunch, dinner, tasting.
- tour
- Guide name + phone, meeting point, duration. Used for guided activities — old town walks, museum tours, wine tours.
- pickup / transfer
- Driver + phone, vehicle + plate, duration. The two are visually identical; pickup is hotel→destination, transfer is destination→destination.
- check-in / check-out
- Hotel, room count, time, reservation name. Bookends each city stay.
- activity
- Guide or captain, optional boat field for water activities. Used for self-led or loosely-led activities — sailing, hiking, kayaking.
- flight
- Flight number, gate (if known), arrival time, terminal. International or domestic — the renderer handles both.
- free-time
- No metadata. Renders as a quiet block with the time window. Resist the temptation to fill it with suggested activities; free time is for the traveler to make their own choices.
- note
- No metadata. A short paragraph that doesn't belong to a time slot — a 'before you arrive in Hvar...' aside. Used sparingly; most things that feel like a note are better written into another block's description.
Title: the 4-7 word rule
The block title renders in italic display weight — it's the biggest typographic element on the page after the day numeral. A short, punchy title reads as confident. A long title spills across two lines, fights the time stamp, and deflates the visual rhythm.
Examples that work:
- Lunch at Konoba Astarea
- Four words. Names the place. Type is implied by 'lunch.'
- Boat day to the Blue Cave
- Five words. Names the activity arc.
- Pickup, Pjaca Sq.
- Three words. The block type is 'pickup' so the title doesn't need to say 'pickup.'
- Sunset oysters at Mali Ston
- Five words. Specificity in the location.
Examples that don't:
- Group reservation for dinner at the family-run Konoba Astarea restaurant
- 13 words. Three quarters of it is redundant — "restaurant" doesn't need to be in the title of a block whose type is 'meal'.
- 09:00 transfer pickup from Hotel Bellevue to Dubrovnik airport via private vehicle
- 13 words AND the time AND the type — all of which the renderer puts elsewhere on the block. Title: "Airport transfer" (2 words).
Description: 1-3 sentences, told from the traveler's POV
The description is the block's prose. It's where the trip's voice comes through. Two rules:
- Frame it from the traveler's perspective, not the DMC's. Bad: 'We have arranged a private boat charter departing Dubrovnik old harbor.' Better: 'Your boat leaves the old harbor a little before nine — Marin will be on the dock with coffee.' The second version has the same information and a person in it.
- Resist marketing adjectives. Words that signal sales-copy energy: 'exquisite,' 'breathtaking,' 'world-class,' 'unforgettable,' 'iconic.' If the experience is genuinely those things, the specifics will convey it. If it isn't, the adjectives won't compensate.
Type-specific metadata: only what's needed
The metadata grid is the most common over-filling site in the document. Every field that exists has a default empty state; the renderer skips empty fields. So the temptation is to fill them all "for completeness." Resist this.
A guide tour where you don't know the guide's phone yet (it'll be sent the night before) is better rendered with the phone field empty than with "TBD" or "Will be confirmed." The traveler reading "TBD" wonders why; the traveler reading a clean metadata grid without the row sees a finished block.
The density question
A premium itinerary varies block density deliberately. The rough mental model:
- Spacious (4–10 fields). Headline blocks: the welcome dinner, the boat day, the chef's table, the helicopter transfer. Photo, pull-quote, full metadata. One or two per day.
- Compact (3–5 fields). The bread-and-butter blocks: a regular meal, a museum tour, a transfer with one interesting stop. Time, title, description, metadata. The majority of the document.
- Minimal (2–4 fields). Operational blocks: hotel pickup, airport drop, in-room breakfast. Time, type, title, location maybe. One line on the rendered page.
A reader scanning a day with one spacious block, four compact blocks, and two minimal blocks sees the trip's rhythm: here's the moment to dress for, here are the things we're doing, here are the logistics. A reader scanning a day where every block is rendered at the same density sees a timetable.
Photo: only when it's doing work
An inline block photo is 16:9, sits at the top of the block on the rendered page, and competes with the day-intro hero photo for attention. Use it only when:
- The dish, vessel, view, or subject is specific to this block
- A photo of the chef's signature plate on the welcome dinner block. A photo of the specific boat on the boat day. Not a generic restaurant interior.
- The block is a headline block
- Headline blocks earn the photo. Operational blocks don't — a photo of a generic taxi for the airport transfer adds visual noise without information.
- You have an actually-good photo
- A blurry phone shot of a dish at night is worse than no photo. Empty space reads as confident; a bad photo reads as filler.
Pull-quote: the editorial voice
The pull-quote renders as an italic side-rule under the description — a single sentence, a writer's voice, the kind of line that would belong in a travel essay.
Used right, pull-quotes are the surface that takes the document from "competent" to "editorial." Used wrong (every block has one, half of them are forced), they're filler that actively cheapens the register.
Rule of thumb: one pull-quote per day, maximum two. They should feel scarce. The pull-quote on the welcome dinner is memorable; the pull-quote on the third meal of the day is noise.
Location: always include it
The Google Maps share URL is the cheapest single field that adds traveler value. The renderer turns it into a tap-through link on every block that has one — a traveler in a taxi arriving at the wrong street can pull up the document, tap the location, and get directions in their native maps app.
The only blocks that don't need a location: free-time windows that aren't tied to a place, notes that aren't tied to a place, and check-outs (the traveler already knows where the hotel is).
Plan B: the new operational primitive
A contingency line on a block is the DMC's answer to "what happens if it rains / the boat captain is sick / the venue closes." One sentence. It shows as a quiet accent line in the main itinerary preview, and becomes the primary action when the trip is re-rendered under the plan-b variant.
Most blocks don't need a contingency. Use it where the original plan has a genuine failure mode: weather-dependent outdoor activities, boat days in shoulder season, anything dependent on a single supplier whose backup isn't in the main flow. Five to eight blocks per trip is typical.
The block, end to end
Once you've written ten or twenty blocks across two or three trips, the structure becomes muscle memory. Time and type first, title and description second, metadata as the type demands, photo + pull-quote sparingly, location always, contingency only where the failure mode is real. Each block takes 90 seconds; the trip takes an afternoon.
The DMC who builds blocks this way ships an itinerary that reads with shape: dense where it should be dense, breathing where it should breathe, premium throughout. The reader reads each block at the right speed because the document paced them.
