Project Description
Project overview
This project involved designing and building a fullscreen digital departures board web app inspired by a vintage railway station-board aesthetic. The goal was to create a visually distinctive public-facing display that could run in kiosk mode while showing live rail information.
The app was built as a modern Next.js application with a server-side API route, a Figma-led implementation workflow, durable local design assets and a layout tuned for 16:9 TV displays. It combines a heritage-style visual system with live Darwin rail data, automatic pagination, status highlighting, caching, fallback behaviour and a custom analog clock designed to match the board styling.
As the project evolved, the data layer moved beyond placeholder and fallback data into a live Rail Data Marketplace Darwin Kafka integration. The board now consumes Darwin Push Port JSON messages, normalises live updates and enriches partial train updates using compact timetable data generated from Darwin Timetable Files.
This kind of delivery sits closest to my work in front-end implementation, custom functionality development and ongoing technical support.
The challenge
The main challenge was combining pixel-accurate design work with operational live-data requirements. The interface needed to look refined and atmospheric, but also behave reliably as a live departures display with minimal maintenance and no user interaction.
The board had to closely match a stylised vintage Figma design, including ornamental details, typography, spacing and a custom station-style clock.
Darwin Kafka messages arrive as live operational updates rather than complete display-ready rows, so the app needed to normalise partial updates into a readable departures-board format.
Some live messages include only service IDs, timing and platform updates. To improve destination and operator display, the app needed a separate timetable lookup generated from Darwin Timetable Files.
Kafka polling had to stay inside the function timeout budget, with bounded polling, safe cleanup and fallback behaviour when upstream data is slow or unavailable.
The app needed to run fullscreen, rotate pages automatically, refresh without user input and remain usable during network or feed issues.
What was delivered
The project was delivered as a custom Next.js application using App Router, Tailwind CSS and TypeScript. The interface was implemented from a connected Figma file and refined through visual correction passes, then extended with a live Darwin Kafka data layer and timetable-based enrichment.
Built a 16:9, TV-ready board layout designed for fullscreen display with a dark heritage colour palette and strong long-distance readability.
Used Figma MCP context, screenshots and exported assets to align the live interface closely with the approved visual design.
Replaced temporary Figma MCP asset URLs with app-owned local assets for the clock face and ornamental details, avoiding broken production images.
Connected the server-side API to Rail Data Marketplace Darwin Push Port JSON via Kafka, SASL/SSL credentials and a station TIPLOC filter for Liverpool Street.
Added a parser for downloaded Darwin
PPtimetable and reference files, generating a compact lookup that enriches live Kafka rows by rid and uid.Added caching, stale-data handling, fallback rows, bounded Kafka polling and timeout protection to keep the API responsive on Vercel.
Added timed page rotation and periodic data refreshes so the board can run unattended on a public display.
Built a live updating analog clock styled to match the board, using local assets and visual alignment tuned to the Figma design.
Core functionality included
A bespoke vintage-inspired board designed for large-format TV or monitor display.
Server-side Darwin Kafka ingestion from the JSON Push Port topic, filtered for Liverpool Street TIPLOCs.
Compact JSON lookup generated from Darwin
PPtimetable and reference files to improve destination and operator names.A station-style analog clock integrated into the board header.
In-memory board state accumulates recent live updates so the API returns a fuller board rather than only the last few seconds of Kafka messages.
If the live feed fails or times out, the board continues to show cached or bundled fallback data instead of collapsing.
On-time, expected, delayed, boarding and cancelled services are normalised into board-friendly text.
The app supports fullscreen Chromium use on Raspberry Pi hardware with automatic refresh and page cycling.
Key architecture decisions
A key decision was to build the project as a compact custom application rather than a CMS-driven site or generic dashboard. That kept the codebase focused, made kiosk behaviour easier to control and allowed the board to remain visually precise.
The data layer is separated from the presentation layer. The board components render a clean departure model, while live Kafka consumption, caching, timetable enrichment and fallback handling live behind a dedicated API route.
The app was built around Figma as the visual source of truth rather than relying on generic dashboard patterns.
Presentation components and rail data logic were kept distinct to improve maintainability.
Kafka polling is capped so Vercel functions return within the runtime timeout instead of hanging.
Large Darwin timetable files are parsed into a compact JSON lookup so the live API can enrich train rows quickly.
The board was designed around a 16:9 TV ratio to maintain consistent fullscreen presentation.
Caching, fallback data and stale-state reporting help keep the display usable when live feeds are temporarily unavailable.
Results and outcomes
The result is a custom digital departures board that feels visually distinctive and purpose-built rather than template-driven. It reproduces the atmosphere of the original Figma design while now connecting to a real live rail data source.
The implementation supports live Darwin Kafka updates, timetable-assisted enrichment, automated page cycling, resilient fallback behaviour and a kiosk-friendly fullscreen layout. It also creates a reusable foundation for similar venue, hospitality or transport-themed display systems.
The interface was aligned closely to the supplied Figma layout, spacing, palette and ornamental details.
The board now consumes Rail Data Marketplace Darwin Kafka messages through a structured server-side route.
Timetable lookup data is used to improve destination and operator labels where Darwin live updates provide only service IDs.
Auto-refresh, page rotation and screen-friendly behaviour support long-running unattended display use.
Cached and sample data paths prevent the board from failing visibly when live data is temporarily unavailable.
The component and data structure can be extended for arrivals boards, branded venue signage or other live display systems.
Technology used
The project was built with Next.js App Router, TypeScript and Tailwind CSS, using a custom server-side API route for live data, caching and fallback handling. The live rail layer uses KafkaJS to consume Rail Data Marketplace Darwin Push Port JSON messages, with timetable enrichment generated from Darwin PPtimetable and reference files.
The visual layer was implemented against a connected Figma file using MCP-based design context and exported local assets, then prepared for Vercel deployment and Raspberry Pi Chromium kiosk usage.
The work overlaps most closely with theme and front-end implementation, custom development and technical support for long-term maintenance.
Next steps
The next step is to automate the timetable refresh process. At the moment, the compact lookup can be regenerated from downloaded RDM PPtimetable and reference files; a longer-term production setup would download the newest files on a schedule, parse them into a compact lookup and store the result in a durable location such as blob storage, KV or a small database.
From there, the same platform could be extended into arrivals boards, event signage, hospitality wayfinding or branded display systems for transport-adjacent venues. If you need a custom display interface, kiosk application or design-led front-end system, the most relevant starting points are usually front-end implementation, custom development and ongoing technical support.
Leave A Comment