Rama Herbin — Track Record
In Five Volumes
A catalogue of five projects, presented as a bound collection — front-end architecture, interaction design and the initiative behind each one.
Fleur de Papier
Turn cultural collections into touch-driven installations for national institutions and museums.
- Key initiative
- Treated Flash-to-web migrations as redesigns, preserving narrative value while improving interaction and feedback.
- Shipped
- 6 productions across 5 institutions, including BnF Richelieu, La Contemporaine and an interactive comic.
Collections visitors can touch
For five cultural institutions across France, collections became something visitors could touch, zoom into and follow as a story — not just look at through glass.
The output
- 6 productions across 5 institutions
- Creative Developer, 2020–2023, Paris
- Stack: Vue · Nuxt · GSAP
- More than 40 interactive cultural and museum devices over the period
BnF Richelieu · La Contemporaine · Terre Adélice · L’Atrium de Rouen · Auberge des Dauphins.
More than a Flash port
Flash-to-web migrations weren’t literal ports. Each rebuild preserved the story’s narrative value, and I proposed the animations and interactions that carried it into the modern web.
- Migrated legacy Flash / ActionScript 3 experiences to standards-based JavaScript and Vue.js
- Flash → modern web migrations — role row tagged LEGACY, alongside front-end architecture on ALL PROJECTS
- Migrations were not literal ports — narrative value was preserved while interaction and feedback improved
I
- Proposed treating Flash migrations as redesigns rather than literal ports
- Designed the interaction and animation layer with GSAP and Canvas
- Implemented the front-end architecture across all six productions
WE
- Explored how each story should read on shared gallery touchscreens
- Iterated the migrated interfaces with designers, illustrators and the institutions
- Shipped rebuilt experiences for the BnF, museums and exhibitions
Rama played a key role in the transition of our interactive projects from Adobe Flash (ActionScript) to modern web technologies (JavaScript / Vue), bringing both technical initiative and a strong sensitivity to design and user experience. He was not only focused on code quality but also contributed creatively by proposing animations and interactions that enhanced the immersive experiences we built for cultural institutions such as the BnF, museums and exhibitions.
Working for every kind of visitor
Public installations had to work on modest kiosk hardware, gallery networks and for visitors from children to first-time museum-goers — with zero instruction.
- Public installations must work for everyone: children, seniors and first-time visitors alike
- Smooth motion on modest kiosk hardware and fast loads on gallery networks: performance is part of the design
- A multi-language idle attract screen (DÉBUT · START · INICIO) invites passers-by without a word of instruction
- Touch-first gestures with generous hit targets for one visitor or several at once
- Shared large-format screens
- Kiosk & touch-table deployment across venues
Built alongside designers and illustrators
Every production moved from prototype to on-site installation with designers, project managers, illustrators and the institutions themselves — not built alone.
- Terre Adélice credits: illustration by Nicolas (@nicolart_dumanoir), design by Elia (@pierrrenoire)
- Content shaped together with curators and institutions, interfaces designed for visitors of every age
- Took productions from prototype to on-site installation alongside designers, project managers and illustrators
Six productions, five institutions
Six productions shipped for five institutions — from BnF Richelieu’s touch tables to an interactive comic set in the Ardèche.
- BnF Richelieu — touch, zoom, FR/EN/ES attract screen
- La Contemporaine — editorial web, exile testimonies and the Chilean dictatorship, accessibility-focused
- Terre Adélice — interactive comic; illustration by Nicolas, design by Elia
- La Contemporaine touch tables, L’Atrium de Rouen, Auberge des Dauphins
I
- Proposed and built the interaction layer for the BnF Richelieu attract screen
- Implemented touch and zoom interactions on shared gallery hardware
- Designed the animation timelines for the Terre Adélice interactive comic
WE
- Explored the multi-language attract experience with the BnF team
- Iterated production media with illustrators and designers over three years
- Shipped six productions across five cultural institutions
FancyUI
Build a reusable, maintainable Svelte 5 component system without losing each interaction’s personality.
- Key initiative
- Noticed motion experiments needed a system: treated motion as part of a component’s identity, not decoration.
- Shipped
- 132 components, 2,900+ unit tests, published to npm as fancy-ui-svelte with a live docs site.
Motion experiments needed a system
Nobody assigned FancyUI. It grew out of motion experiments that needed somewhere to live as a reusable, maintainable component system rather than one-off demos.
- Self-initiated — Rama owns concept, visual direction, implementation, APIs and docs
- 132 components: core primitives (forms, navigation, overlays) alongside buttons, text animations, backgrounds and effects
- MIT license, author Rama Herbin, published to npm as fancy-ui-svelte
- Svelte 5 runes
- SvelteKit 2
- Tailwind CSS 4
- TypeScript 5
- Vitest 4
- bits-ui 2
- GSAP 3
Motion as identity, not decoration
Nobody assigned this. I treated each component’s motion as identity, not decoration — then built a system to keep that promise at scale.
- The challenge: preserve each interaction’s personality inside a reusable, maintainable system
- 2,900+ unit tests with Vitest and Testing Library
- Initial public release 0.1.0 (2026-03-13): 50 components across 10 categories
- Now 132 components in the repo (published npm README at 0.9.1 still lists 61 components / 600+ tests)
I
- Proposed treating motion as a first-class part of each component’s identity
- Designed the component APIs, visual direction and documentation site
- Implemented the WebGPU/WebGL renderers behind FluidCursor and FireworksHdr
WE
- Explored which interactions were worth generalising into reusable primitives
- Iterated the library from 50 components at 0.1.0 to 132 today
- Shipped fancy-ui-svelte to npm with a live docs site and llms.txt
- apps/main — hero FluidCursor, skins engine
- apps/hdr — FireworksHdr fireworks engine
Reusable, yet still full of personality
The hard part wasn’t building 132 components — it was keeping each one’s personality intact while making the system predictable, typed and testable enough to reuse anywhere.
- Components named in the brief: FluidCursor (WebGL fluid simulation following cursor), ImageTrailCursor (cursor-following image trail, 8 variants), LiquidGlass (liquid glass morphism effect)
- CI gates: pnpm check:registry (component registry parity) and pnpm check:i18n (i18n catalog parity)
- Full TypeScript typing for props and events across all components
- 2,900+ unit tests (Vitest + Testing Library)
- Playwright end-to-end suite
- svelte-check strict type checking
- Registry + i18n parity gates in CI
Built for other developers, and agents
FancyUI serves two audiences at once: developers browsing the docs site, and AI coding agents reading structured llms.txt references before they write a line of code.
- Documented for AI agents via llms.txt and llms-full.txt (full props reference)
- Part of the "Claude for Open Source" program
- Used in production by apps/main (hero FluidCursor, skins engine) and apps/hdr (FireworksHdr)
- Inspired by Inspira UI, Aceternity UI and Magic UI
132 components, live and versioned
From 50 components at the first public release to 132 today, with almost 3,000 tests behind them — versioned, documented and shipped to npm.
- 0.1.0 — 2026-03-13: initial public release, 50 components across 10 categories
- 132 components, 2,900+ unit tests, at 0.9.1
- MIT licensed, npm package fancy-ui-svelte
I
- Proposed and designed the component APIs and visual direction
- Implemented the renderer behind FluidCursor and FireworksHdr
- Wrote the documentation and the llms.txt reference
WE
- Explored contributions and issues from the open-source community
- Iterated the release process with Changesets-driven versioning
- Shipped ten minor and patch releases from 0.1.0 to 0.9.1
Ansys Digital Safety Manager
Build intuitive, high-performance UIs for safety engineers planning, executing and monitoring safety cases.
- Key initiative
- Presented his Claude Code workflow at a team workshop to make AI-assisted development concrete and reproducible.
- Shipped
- Enterprise-scale safety applications built with Angular, used internally to plan, execute and monitor safety cases.
UIs for safety-critical engineering work
Ansys Digital Safety Manager gives safety engineers one interface to plan, execute and monitor safety cases — enterprise-scale software built with Angular.
- Front-End & UI Engineer at Ansys (part of Synopsys Inc.), current, Lyon
- Enterprise-scale safety applications built with Angular: UI/UX for safety engineers planning, executing and monitoring safety cases
- Tags: Angular · TypeScript · Enterprise
- Confidential project · no public visuals
DETAILS UNDER NDA — this volume speaks in the shape of the work, not its screens.
A workshop on AI-assisted development
I presented my Claude Code workflow at a team workshop, turning a personal habit into something colleagues could reproduce on their own safety-critical codebase.
- Presented his Claude Code workflow at a team workshop to make AI-assisted development concrete and reproducible
- Worked on comparison logic, filters, indicators and baseline-difference experiences
- SonarQube quality expectations applied to the codebase
I
- Proposed presenting a live Claude Code workflow instead of just describing it
- Designed the workshop format to make AI-assisted development concrete
- Implemented comparison, filter, indicator and baseline-diff features on the team’s roadmap
WE
- Explored how AI-assisted workflows could fit safety-critical development
- Iterated the workshop format based on the team’s questions
- Shipped features under the same SonarQube quality bar as the rest of the codebase
consistently delivers clean, maintainable interfaces and approaches problems with both technical rigor and creativity.
Making dense differences legible
Comparing safety cases means surfacing what actually changed in dense engineering data — filters, indicators and baseline-diffs that make a difference legible at a glance.
- Comparison logic, filters, indicators and baseline-difference experiences
- SonarQube quality expectations
- Confidential project · no public visuals
- Angular
- TypeScript
- Enterprise-scale safety application
Trusted by the platform team
None of this was built in isolation — a colleague led the platform side while this volume covers the front-end, reviewed and shaped alongside the rest of the team.
Rama worked on full-stack tooling used by more than 200 engineers to manage Kubernetes deployments, combining Angular frontends with CI/CD pipelines built with GitHub Actions.
- Presented his Claude Code workflow at a team workshop, in front of colleagues
- Tags: Angular · TypeScript · Enterprise
Two different roles — platform engineering and R&D — recommending the same collaborator.
In production, details withheld
Ansys Digital Safety Manager is live, enterprise software used daily by safety engineers — the work is real and current, even where the screens can’t be shown.
- Confidential project · no public visuals
- Enterprise-scale safety applications built with Angular
- Current role, Lyon, France
I
- Proposed and presented the Claude Code workshop that made AI-assisted development reproducible for the team
- Built comparison, filter, indicator and baseline-diff features for safety-case review
- Held the same SonarQube quality bar as the rest of the codebase
WE
- Explored how the platform and front-end sides of the product should meet
- Iterated the interface with safety engineers who use it daily
- Shipped and maintain Ansys Digital Safety Manager in production
Is My Screen HDR?
Answer one hardware question in five seconds: can your display actually paint brighter than white?
- Key initiative
- Separated what the screen can do from what the browser allows, with a four-case verdict matrix.
- Shipped
- Live at is-my-screen-hdr.rama.app with WebGPU HDR fireworks, a WebGL2 fallback and mobile support.
One question, five seconds, fireworks
A five-second answer to one question: can your display actually paint brighter than white?
- WebGPU fireworks burn the question into the sky, then a verdict separates what the screen can do from what the browser will allow
- Four-case verdict matrix: true-hdr · browser-clamped · screen-sdr · no-hdr
- Display signals read via matchMedia: dynamic-range: high, color-gamut: p3
- WebGPU float16 + display-p3 + extended tone mapping
- WebGL2 fallback
- Svelte 5
- Vercel Analytics
Separating screen truth from browser limits
Most displays can go brighter than white; most browsers won’t let a page prove it. I built a verdict that keeps the two questions separate.
- Four-case verdict: true-hdr, browser-clamped, screen-sdr, no-hdr — computed from display signals and the actual render level achieved
- "Your screen can. Your browser won’t." — verdict copy for the browser-clamped case
- Only WebGPU with extended tone mapping actually paints above white — every other render level is SDR output regardless of screen capability
I
- Proposed separating "can the screen do it" from "will the browser allow it" as two independent signals
- Designed the four-case verdict matrix and its copy
- Implemented the WebGPU float16/display-p3 path and its WebGL2 fallback
WE
- Explored how to phrase a verdict a non-technical visitor would understand in five seconds
- Iterated the fireworks engine until the visual made the question felt, not just answered
- Shipped the matrix as the product’s one and only screen
Rendering real HDR inside a browser
Proving HDR inside a browser meant a WebGPU float16 pipeline in display-p3 with extended tone mapping — and a WebGL2 fallback for every device that can’t run it.
- WebGPU path: float16 + display-p3 + extended tone mapping
- WebGL2 fallback for devices without WebGPU HDR support
- Proof strip: SDR · 100 nits / HDR · 1000+ nits
- Mobile adaptation: safe areas, touch copy, tap targets
- Liquid-glass UI redesign
- Vitest test suites
- Deployed on Vercel via adapter-vercel
A fireworks engine, shared back
The fireworks engine that answers the HDR question didn’t stay locked inside one app — it shipped as a MIT-licensed FancyUI component anyone can reuse.
- Fireworks engine shipped as a fancy-ui component (MIT license)
- FireworksHdr: WebGPU path (float16 + display-p3 + extended tone mapping) with a WebGL2 fallback
- Mobile adaptation: safe areas, touch copy, tap targets
Shipped: one page, one verdict
Is My Screen HDR? is live: WebGPU fireworks, a four-case verdict, a WebGL2 fallback and full mobile adaptation, all in one page.
- Live at is-my-screen-hdr.rama.app
- Tags: WebGPU · WebGL2 · HDR · Shaders · Svelte 5
- Deployed on Vercel via adapter-vercel, with Vercel Analytics
I
- Proposed splitting the screen question from the browser question
- Designed the four-case verdict matrix and its copy
- Implemented the WebGPU/WebGL rendering pipeline and the liquid-glass UI
WE
- Explored how the fireworks should read on both HDR and SDR screens
- Iterated the mobile experience for safe areas and touch targets
- Shipped the app live on Vercel with analytics
Selected Experiments
Keep a live bench of ideas — skins, shaders, playgrounds — that feed back into the real work.
- Key initiative
- Shipped alternate runtime skins and a dithered hero fluid as a live design-system test bed.
- Shipped
- Retro OS and Brutal skins, a bitmap-dithered hero, a language tree, a photo scatter home, a carbon page.
A monorepo as a live bench
This monorepo doubles as a bench: apps and pages built to test an idea quickly, then feed whatever works back into the real portfolio.
- Retro OS and Brutal runtime skins for rama.app
- Bitmap-dithered hero fluid under the skins
- apps/langtree — interactive Tree of World Languages
- apps/photo — scatter home, image-trail cursor, WebGPU test-motion playground
- This 3D bookshelf (apps/shelf)
- A carbon-footprint page (~45KB gzipped, ~0.2g CO₂/visit, <1.2s first paint, 95+ Lighthouse)
Skins as a design-system stress test
I built Retro OS and Brutal as full alternate skins for the same portfolio — one codebase, one content layer, three completely different looks.
- Retro OS and Brutal runtime skins for rama.app (#38, #40)
- Bitmap-dithered hero fluid under the skins (#39)
- Real LinkedIn testimonials modal reused across skins
I
- Proposed the skins as a way to stress-test the content layer, not just a visual gimmick
- Designed the Retro OS and Brutal art direction on top of the same data
- Implemented the bitmap-dither treatment for the hero fluid under both skins
WE
- Explored how far the same content could stretch across different visual systems
- Iterated each skin against the same real production content
- Shipped both skins live on rama.app alongside the standard design
Fast experiments, still production quality
Every experiment still has to ship clean: a carbon page under 45KB gzipped, sub-1.2-second first paint, and a 95+ Lighthouse score.
- ~45KB gzipped bundle, ~0.2g CO₂ per visit, <1.2s first paint, 95+ Lighthouse score
- Lazy loading and code splitting for animations and interactive elements
- Modern image formats (WebP, AVIF) with fallbacks for compatibility
- Server-side rendering and intelligent caching
- Efficient CSS via Tailwind’s purge system
- Optimized vector graphics and compressed assets
Roots at Gobelins, l’École de l’Image
The habit of building and testing ideas fast started at Gobelins, l’École de l’Image, in Paris.
- Gobelins Paris, l’École de l’Image
- Real, verbatim LinkedIn testimonials modal, reused across the standard and Retro OS design trees
- Logos shown on site: Angular, Gobelins, Nvidia, Synopsys, Fleur de Papier, Ansys, Claude for Open Source
I had the pleasure of working with Rama on our final-year project at Gobelins, and can attest to his professionalism and his front-end skills. Our collaboration was smooth and efficient.
A working bench, always current
Retro OS, Brutal, the dithered hero, langtree, the photo scatter home and this shelf itself are all live, shipped experiments from the same bench.
- Retro OS and Brutal runtime skins, live on rama.app
- Bitmap-dithered hero fluid under the skins
- apps/langtree — interactive Tree of World Languages, live
- apps/photo — scatter home, image-trail cursor, WebGPU test-motion playground
- Carbon-footprint page: ~45KB gzipped, ~0.2g CO₂/visit, <1.2s first paint, 95+ Lighthouse
I
- Proposed the skins as a stress test for the content layer, not decoration
- Designed the Retro OS and Brutal art direction and the bitmap-dither treatment
- Implemented the language tree, the photo scatter home and this bookshelf
WE
- Explored how far one data layer could stretch across different visual systems
- Iterated the carbon page until it hit its own performance budget
- Shipped every experiment listed here live on rama.app or its sibling apps