Terra /
A travel journal that begins with a feeling.
A cinematic alpine arrival, expressive serif typography and a selectable journey story turn the site into an outdoor editorial experience. The field guide preserves the practical planning path.
- Practice
- Immersive websites
- Built by
- Lumia Digital
- Application
- Independent source & workspace
- Current release
- Local / September 2026
A travel journal that begins with a feeling.
A cinematic alpine arrival, expressive serif typography and a selectable journey story turn the site into an outdoor editorial experience. The field guide preserves the practical planning path.
Vue itinerary daybookThe problem worth solving.
A visually appealing travel page can make a proposed itinerary feel more settled than it is. The dates may not fit an activity, the displayed total may omit how guest-based pricing was applied, and an enquiry may look like a confirmed booking. Terra connects discovery, itinerary construction and an explicit operator response while preserving the boundary between a local request and an external reservation.
An operator creates the stay and activity inventory with prices, timezone, images and credits. A traveller selects dates and guests, places activities inside the stay, inspects the estimate and saves the journey. Requesting that journey captures a snapshot for review. The operator can then record confirmed, declined or needs-information locally, with a note explaining the decision.
The observed journey used a synthetic woodland stay, an original generated landscape and a fictional forest walk. It produced an exact-price itinerary, a downloaded PDF and a persisted local operator response. These results establish the product flow with QA data; they do not demonstrate a real property, live availability, a payment, a supplier contract or an actual traveller booking.
Designed for: Independent stay operators and small travel teams that curate their own inventory and want an enquiry-led itinerary workflow. Terra is suited to offerings where a person reviews dates and details before confirming availability through the operation's actual booking process.
From input to a useful result.
Create the field guide inventory
Add a stay with its description, timezone, supported currency, nightly price and illustrative map position. Upload an owned image and its credit when using photography or artwork. Add activities with a duration and per-guest price in the stay's currency. The evaluated inventory mode is operator confirmed, so listing a stay does not establish live availability.
Choose the stay, dates and guests
Select the stay using the field-guide controls, then enter arrival, departure and guest count. The terrain can be rotated and reset as an exploratory visual. Its markers are illustrative positions; the tested selection flow uses the field-guide buttons rather than clicking pins on the scene.
Build a valid activity schedule
Place activities at explicit times within the stay's local dates. Inspect duration and avoid overlapping entries; adjacent activities are permitted. Review the lodging and activity amounts before saving. The estimate uses the entered nightly price, number of nights and per-guest activities, without silently adding transport or other applicable charges.
Request and record an operator response
Save the itinerary, export its PDF if useful and request the current version with contact details. The operator reviews the frozen request and records a response with a note. Reload the saved journey to inspect that response. A local confirmed state does not charge the traveller or create a reservation in another system.
What the software actually did.
These results come from internal workflow testing of the local product. The records are controlled test inputs; customer deployments and commercial impact have not been measured.
Ten HTTP groups passed across 69 requests
The acceptance run covered owned image files and credits, adjacent and overlapping activities, stay-timezone boundaries, invalid dates, zero nights, currency mismatch, map bounds, oversized totals, stale request digests, contact validation, request snapshots, response replay and workspace isolation. An edit to the working estimate did not rewrite the previously submitted request.
A complete synthetic operator and traveller flow ran in the browser
The UI created a woodland stay at ₹3,500 per night, uploaded the original fictional landscape with its credit and added a ninety-minute forest walk at ₹750 per guest. The itinerary selected two nights, two guests and one walk. Its estimate displayed ₹7,000 lodging and ₹8,500 total, and the downloaded PDF preserved the exact total.
Request, response and reload were observed
The mobile interface created a local request and displayed its pending operator state. The operator then recorded confirmation with a note explicitly identifying the synthetic QA context. After a full reload, the saved journey retained its dates, guest count, activity, total and local response. The request did not send email or initiate payment.
Make the boundary clear.
- Inventory is operator confirmed and local. There is no verified supplier availability feed, reservation hold or external booking write. A local operator-confirmed response must not be represented as a paid or supplier-issued booking.
- The estimate covers entered lodging and activity amounts. Transport and other applicable additions are assumptions to clarify with the operator, not silently included services or a final externally accepted price.
- The terrain is illustrative, with operator-placed coordinates in a bounded scene. It is not a geographic navigation service; markers did not act as selectable inventory controls in the observed implementation.
- The showcased QA stay, activity and landscape are fictional. The run verified local functionality, not property quality, real traveller demand, supplier response time or a completed trip.
Questions before you start.
Does requesting an itinerary reserve the stay?
It creates a local request for an operator to review. The inventory is operator confirmed, and the tested application does not create an external reservation hold or payment. Any real availability and booking commitment must be established through the operator's verified process.
How is the estimate calculated?
Lodging is nightly price multiplied by nights. Each selected activity adds its per-guest price multiplied by the guest count. The browser fixture used two nights at ₹3,500 and one ₹750 activity for two guests, giving ₹8,500. Review the stated exclusions with the operator.
Why was an activity outside the stay even though its timestamp looked correct?
The server checks the activity's whole interval against the stay's local dates and timezone. An offset or a long duration can move part of it beyond those boundaries. Use the displayed local time and confirm its end, not just its starting calendar date.
Can I select a stay by clicking its terrain marker?
In the observed implementation, the terrain supports rotation and reset, while field-guide buttons select stays. The markers are illustrative. They should not be described as a geographic search or selectable booking map without an additional implemented and tested interaction.
More from this practice.
All fifteen products
Nexus
Terracotta product photography, expansive typography and a warm editorial rhythm introduce Nexus. A separate interactive studio collection lets visitors inspect the original interface geometry.
Explore the case study
Aura
An oversized editorial masthead and cinematic coastal architecture lead into spatial thinking, interiors and material studies. The journey moves from atmosphere to a concrete room brief.
Explore the case study