AURA: Interactive Editorial Flipbook for Luxury Salon

A 22-page digital magazine you actually turn — built to give a luxury hair salon and apothecary the pacing and authority of print, in the browser.

AURA is a conceptual brand experience for a luxury salon: a 22-page editorial magazine rendered as a real, draggable flipbook. No infinite scroll, no hero-and-three-columns. I designed the spreads and engineered the page-turn mechanics, responsive scaling, keyboard access and edge delivery from scratch.

Almost every salon website is the same website: a full-bleed hero, a services list, a booking button, and a gallery you scroll past in four seconds. That layout is fine at selling a haircut. It is bad at selling a brand — because scrolling hands the visitor the remote control, and luxury depends on controlling the pace at which someone sees things. Print does the opposite. A magazine spread arrives whole. You finish it before you get the next one. That constraint is the entire reason editorial design feels expensive.

So I built AURA as a magazine — 22 pages, 11 spreads, with a cover you drag open — and made the browser honour the format instead of fighting it.

The spreads run the full editorial range: an opening philosophy page, a full-bleed interior shot, four priced service menus with dotted leaders (Cut & Style, Color Studio, Hair & Scalp, Beard & Shave), two long-form features — The Muse and The Gentleman — a mosaic gallery, a two-page Apothecary storefront, a manifesto spread, and a closing colophon with booking details. Playfair Display carries the display type; Inter carries anything you actually read. A single warm gold #cfa875) is the only accent in the palette, used against white spreads and near-black ones. Photography is sourced from Pexels and colour-selected to hold together as one shoot.

The visual design was the easy half. Making a book behave like a book in a resizable viewport was not. Five problems worth describing:

1. The book kept getting cut off. The flipbook library derives its height from its width — it sets a percentage bottom-padding to hold the spread ratio.

On a wide, short window that makes the book taller than the screen, clipping the bottom of every spread and the page corners with it. Its own shrink-to-fit clamp couldn't help, because the box it measures is the same width-derived box.

I inverted the dependency: I gave the outer frame the book's own aspect ratio and capped its width by what the viewport height could carry. Now height falls out of width, lands inside the viewport, and the book centres on both axes instead of hanging from the top.

2. The type didn't scale with the page. Every font size in a spread is an absolute pixel value, so as the window grew, the page grew and the text stayed put — the layout slowly fell apart. I laid every page out inside a fixed 550×750 design canvas and scale the whole canvas with a CSS transform, driven by aResizeObserver watching the rendered page element. Type, spacing and images now scale as one object, and the spread looks identical at every size. Observing the page rather than the frame also sidesteps a race with the library's own resize handler.

3. You could only read it by dragging. The library ships no keyboard handling at all, and click-to-flip is disabled in two-page mode — so on a laptop, dragging was the only way through 22 pages. I added arrow keys, PageUp/PageDown, and Home/End to jump to either cover, with the handler bowing out inside form fields and on modifier combos. A visually-hidden live region announces "Page 4 of 22" to screen readers on every turn.

4. Phones lost half the content. The Apothecary product cards revealed name, price and description on hover. On touch devices that hover never happens, so two full spreads of the shop degraded into unlabelled photographs. A(hover: none) media query pins the details open there. In the same pass I let a tap flip the page in single-page mode — the left 40% goes back, the rest forward — which restores the fold animation and gives phones a back gesture.

5. The page corner snapped instead of settling. This one is small and I enjoyed it most. The library times animations by distance — roughly one frame per pixel travelled, linear. A peeled corner only moves about 50px, so letting go gave it ~50ms of constant-velocity motion: it didn't settle back, it teleported. I wrapped the renderer's animation call, identified the corner return by its frame count and the state it animates from, and resampled those same frames onto an ease-out cubic curve over a 300ms floor. Page turns travel far enough to fall outside the threshold and are untouched. It's public API throughout, and if the library changes shape the wrapper quietly does nothing.

An image-led magazine is a payload problem before it is anything else. All 58 photographs are served as WebP. The cover is the LCP element, so it loads eager with high fetch priority while everything else is lazy — there is no sense deferring the one thing a visitor sees on arrival. It deploys to Cloudflare's edge as static assets with no Worker script at all. There's no server-side code in the project, so there's nothing to run:

assets are served straight from the edge, which means no Worker invocations to pay for and no cold starts. Unknown paths fall back to the app rather than a 404.

React 19 and Vite, Tailwind CSS v4 (with the design tokens declared in CSS rather than a config file), react-pageflip for the page mechanics, Lucide for icons, deployed on Cloudflare Workers static assets.

AURA is a self-directed concept piece, not a client engagement — the business doesn't exist, and the photography is licensed stock from Pexels. I built it to push on a question I find genuinely interesting: how much of what makes print feel expensive survives the move to a browser, and what you have to engineer yourself to get it back.

Answer: more than I expected, and quite a lot.