Making Of

Building a browser-native scene is not the same as building a web page. The tools overlap - HTML, CSS, JavaScript, WebGL when the situation justifies it - but the intent is different. A page delivers content. A scene creates a place. This essay covers the production thinking behind that distinction, from early concept framing through composition, pacing, atmosphere, and the technical tradeoffs that shape every decision along the way.

If you have come from The Journey, what follows is the craft conversation behind what you experienced. If you have arrived here directly, the principles apply to any browser-native project where atmosphere and narrative structure matter as much as information delivery.

Concept framing

Every scene starts with a question: what should this feel like? Not what it should look like, not what technology it should use, not how many interactions it should support. The feeling comes first, because the feeling is what the visitor will remember.

For the work on this site, the answer has always been the same: it should feel like a route through a landscape. Not a dashboard, not a gallery, not a presentation. A route - something with direction, with pacing, with a sense that you are moving through space rather than consuming a stack.

That framing decision eliminates a huge number of options immediately. Grid layouts feel wrong, because grids are spatial organisers, not directional ones. Sidebar navigation feels wrong, because sidebars imply browsing, not travelling. Modals feel wrong, because modals interrupt the route.

What remains is a single-column flow with controlled width, vertical progression, and visual chapters. That is the chassis. Everything else - typography, colour, spacing, motion - is fitted to that chassis.

Pacing and composition

Pacing in a browser scene is controlled by three things: content density, vertical rhythm, and scroll speed. Content density is a design choice. Vertical rhythm is a CSS choice. Scroll speed is a browser behaviour that you cannot control, but you can influence by managing how much distance the reader covers per visual unit of change.

Dense sections slow the reader down. Open sections speed them up. The deliberate alternation between density and openness creates the feeling of movement through varied terrain, which is exactly the metaphor the site is built on.

Composition within each section follows a simple rule: one dominant element per viewport. If there are two equally weighted elements competing for attention at the same scroll position, the composition is broken. The eye does not know where to go, and the pacing stutters.

This is the same principle that film uses for shot composition, translated into a scroll context. The dominant element might be a heading, an image, a pull quote, or an illustration. It does not matter what it is, as long as it is singular. Supporting elements exist in service of the dominant one, not in competition with it.

Movement and restraint

Motion in a browser scene is the most powerful tool and the most dangerous one. A well-timed transition can orient the reader, reveal structure, and create emotional resonance. A poorly timed one - or simply too many of them - creates visual fatigue and the sense that the page is performing rather than communicating.

The rule here is that motion must justify itself. Every animated element must answer a question: what does this movement tell the viewer that stillness could not? If the answer is nothing, the motion is decoration. If the answer is something specific - this element is entering the scene, this section is connected to the previous one, this interaction has been acknowledged - then the motion earns its place.

Restraint also means respecting the browser’s capabilities honestly. CSS animations that run on the compositor thread are effectively free. JavaScript-driven animations that trigger layout recalculations on every frame are expensive. The difference is not theoretical. On a mid-range phone, one of these approaches produces smooth motion. The other produces a slideshow.

The practical framework is to start with no motion, add it where it genuinely helps, test on the slowest device you intend to support, and remove anything that causes a visible stutter. A page with three smooth transitions is always better than a page with twelve stuttering ones. This philosophy is explored further in Designing Browser Scenes with Restraint.

How atmosphere is built

Atmosphere is the cumulative effect of colour, spacing, typography, and timing working together. You cannot add atmosphere with a single element. You can only create conditions where atmosphere emerges from the coherence of many small decisions.

Colour is the most immediate atmospheric lever. The palette for this site uses muted, warm tones - parchment backgrounds, graphite structure, mulberry depth, sand accents. These choices are not arbitrary. They are calibrated to feel like natural materials rather than digital surfaces. The goal is warmth without sentimentality, seriousness without sterility.

Spacing is the second lever. Generous whitespace signals confidence and editorial control. Tight spacing signals urgency or density. The alternation between the two creates rhythm, and rhythm is what separates a composed page from a dumped one.

Typography is the third. The combination of a clean sans-serif for interface and navigation with a warm editorial serif for emphasis and chapter markers creates a tonal contrast that maps to the content hierarchy: the sans-serif handles the functional, the serif handles the expressive.

Timing is the fourth, and the hardest to get right. How long a transition takes. How quickly an element appears after the viewport reaches it. How much delay separates the entrance of one element from the next. These are micro-decisions, but they compound. A page where every entrance happens at the same speed feels mechanical. A page where the timing is carefully varied feels alive.

Structure and narrative clarity

A common mistake in immersive web design is sacrificing clarity for atmosphere. The page feels moody and distinctive, but the reader cannot figure out where they are or what the content is actually about. Atmosphere without structure is just confusion with better lighting.

Structure in a scene-based page means clear chapter boundaries. Each section needs a visible entrance that tells the reader: you are now in a new part of the experience. That entrance can be typographic, spatial, chromatic, or kinetic - but it must exist.

Internal navigation helps. The journey rail on the flagship page gives the reader a persistent map of their position. It does not demand attention, but it is always available. On mobile, it scrolls horizontally. On desktop, it sits in a compact sticky bar below the main header.

The fallback version of every section must also be clear. If all animation is disabled, the content must still read correctly. If images fail to load, the text must still make sense. Structure is what survives when everything decorative is stripped away. If the structure is not clear on its own, the atmosphere will not save it.

Technical implementation tradeoffs

Every production choice involves a tradeoff, and the most important tradeoffs in browser-native scene design are between visual richness and rendering performance.

WebGL enables effects that CSS cannot achieve - genuine 3D environments, complex particle systems, shader-driven visual processing. But WebGL also demands a GPU pipeline, adds significant JavaScript weight, and creates accessibility challenges that are genuinely difficult to solve. Three.js makes the WebGL authoring experience substantially better, but it does not eliminate the fundamental cost.

For most of the work on this site, the tradeoff resolves in favour of CSS and progressive enhancement. The visual effects that matter most - colour transitions, spacing shifts, opacity changes, transform-based movement - are achievable without WebGL, without heavy JavaScript, and without excluding visitors on older hardware.

Where WebGL is justified, it should be loaded conditionally. Check device capability, respect data-saver preferences, provide a static fallback that does not feel like a punishment. The fallback should be a considered alternative, not a blank space with a message saying your browser does not support this experience.

Image handling is another critical tradeoff. High-resolution images create visual richness. They also create weight. The discipline is to treat every image as a cost that must be justified by its contribution to the scene. If an image does not add atmosphere, information, or compositional structure, it should not be on the page.

The build process for this site uses Hugo for static generation, with careful attention to output size. No client-side framework. No build-time bundling beyond what Hugo Pipes provides for CSS. JavaScript is limited to search initialisation and a small amount of interaction handling. The result is a site that loads fast enough to feel instant on a reasonable connection, which is the minimum standard for any project that claims to care about craft.