Intralox 2026
A custom video player application deployed across Surface Pro kiosks and brand ambassador tablets on the trade show floor. Built to handle large video files on unreliable show Wi-Fi, with integrated engagement logging that feeds a post-show analytics report for the client.
| Client | Intralox via Kubik |
| Role | Interaction Designer — Concept, UX, UI Design, Front-End Development, Deployment |
| Deliverable | Electron video player app — kiosk and floater modes, engagement analytics, multi-show deployment |
| Venue | IPPE 2026, Aquasor 2026 — Global Seafood upcoming |
Overview
Intralox manufactures factory conveyor systems and brings a characteristically large, high-energy presence to industry trade shows — including live product demos and working machinery on the floor. Their shows in 2026 span food processing, aquaculture, and seafood sectors, each with its own audience and product focus.
The brief was a tight-budget interactive for the show floor. After a conversation with the Intralox team about how the booth actually operated — what sales staff needed, what visitors would encounter — a single solution emerged that served both: a custom Electron video player with two distinct operating modes, deployable on both fixed kiosks and handheld brand ambassador tablets.
Pitched the concept directly to Intralox, built it from scratch, and deployed at two shows in 2026 with a third on the schedule. The same codebase has run at every show without modification — only the content changes.
The Challenge
Video at show-floor quality
Large, high-quality video files needed to load and play instantly. Streaming over trade show Wi-Fi was not a viable option.
Two audiences, one app
Visitor-facing kiosks and brand ambassador floater tablets had different access requirements — both handled by a single configurable codebase.
Tight budget, high expectations
The solution needed to deliver a premium interactive experience without the scope of a fully custom multi-app build.
Proving ROI
Intralox needed quantitative data after each show to justify the investment — app engagement alone wasn’t the full picture.
Approach
Concept & Pitch
The pitch started with questions — what does a brand ambassador actually do during a show, and what does a visitor stopping at a display actually want to see? The answers pointed to a shared content library of product videos, accessed in two different ways depending on who was holding the tablet.
A visitor-facing kiosk needed a guided, locked-down experience — specific content, no navigation out of bounds. A brand ambassador needed on-demand access to any video in the library to respond to client questions in real time. One app, one codebase, one configuration screen to set the mode.
Building analytics into the app from the start — rather than retrofitting it — was a deliberate decision made at the pitch stage. If the client was going to invest in an interactive, they should leave the show with data that proved it was worth it.
App Architecture
The app opens to a configuration screen where an operator selects the current show and assigns the tablet a role — kiosk display or brand ambassador floater. Once set, the app locks into that mode. A hidden button sequence, invisible to show visitors, returns the device to the config screen if a role change is needed.
In kiosk mode, the interface is locked down to a defined content set relevant to that display position. In floater mode, brand ambassadors have access to the full video library and can pull up any video on request during a conversation with a prospect.
All video assets are bundled inside the .exe installer. Nothing streams — every file is local. Load times are instant, playback is unaffected by venue Wi-Fi, and there is no dependency on the show floor network at any point during operation.
Content & Deployment
Video assets and show content are bundled at build time and packaged into the .exe installer. For each new show, updated content is compiled into a fresh installer and pushed to each Surface Pro remotely via ScreenConnect before the show opens.
The codebase itself has not changed between shows — the app that ran at IPPE is the same app running at Aquasor and will run at Global Seafood. Getting the architecture right on the first build meant nothing needed to be revisited. Each deployment is a content update, not a redevelopment.
Remote support during each show is available throughout. ScreenConnect provides access to any tablet on the floor if an issue arises, without requiring on-site technical presence.
Analytics Integration
The app logs engagement events to a local SQLite database throughout the show — videos played, completions, timestamps, and device identifiers. At the end of each show, the data is exported to CSV and handed to Kubik’s account and management team, who assemble it into a client-facing report alongside footfall sensor data.
Footfall sensors are deployed in areas of the booth away from the tablets — tracking total visitor flow through the space rather than device interactions. The two data sources together answer a question app analytics alone cannot: of everyone who came through the booth, how many engaged with the interactives, and how many didn’t?
This combination — app engagement data correlated with total booth traffic — became the client’s favourite feature of the deliverable. It gave Intralox a quantitative story to take back to their stakeholders after each show.
Outcome
The app ran without incident at IPPE and Aquasor. No bugs, no on-site failures, no codebase changes required between deployments. A third show — Global Seafood — is on the calendar using the same build.
Intralox left each show with clean, structured engagement data and a combined analytics report that demonstrated ROI against their KPIs — including videos viewed to completion and total attendees across all tablet positions. The footfall data provided the wider context that made those numbers meaningful.
A complex multi-mode application with analytics, multi-show deployment, and remote support requirements — built in a matter of weeks, delivered with no flaws, and still running on the original codebase.