Anyone who has worked on an embedded display project has experienced the moment when the gap between a design on screen and a working device in the real world feels enormous.
It happens when, on the one side sits a polished Photoshop mockup, while on the other sits a physical product that needs to respond to data, animate smoothly, and survive whatever it has been installed on.
Two recent community projects illustrate how 4DS’ technology can solve the gap. The first was a custom speedometer UI for an electric bike, built around the Pixi LCD 2.5″ display. The second was a full treadmill interface running on the Pixi LCD 3.9″ capacitive touch display.
On the surface, they are different products for different contexts. Underneath, they follow the same three-stage workflow that defines the 4D Systems development experience: design in Photoshop, program in Workshop4, deploy to hardware.
Stage One: Design Where You Already Work
Both projects begin not in an embedded development environment but in Adobe Photoshop. This was a deliberate choice by the designers in both cases. By setting the Photoshop artboard resolution to match the target display from the outset, the designers could build the full UI at pixel-perfect scale, plan layer structure, and prototype animations before writing a single line of code.
For the bike speedometer, this meant constructing the gauge face, needle, road animation frames, and supporting text elements as discrete Photoshop layers, each exported individually to give Workshop4 independent control over them. For the treadmill interface, the same logic applied to a more complex layout featuring dual custom gauges, LED digit widgets, and two separate looping animations. In both cases, the Photoshop file served as a living reference document throughout programming, open on a second monitor so the designer could match placement and proportions at a glance.
The discipline of completing the visual design before touching Workshop4 pays dividends later. It forces decisions about what moves, what stays static, and how data will be represented graphically. It also means that when assets are imported into the programming environment, they drop in correctly sized and positioned, removing one of the most time-consuming friction points in embedded UI development.
Stage Two: Program Without the Overhead
Workshop4 is where the visual design becomes a functioning display program. Both projects made heavy use of the Smart Gauge widget, one of the more powerful tools in the Workshop4 Pro environment. Smart Gauges allow developers to build fully custom animated widgets from their own graphics, assigning each layer its own rotation range, frame count, and reference point. The needle on the bike speedometer rotates across 100 frames. The treadmill’s step counter runs across 1,000 frames, with a linked numeric part that surfaces the exact value to the user at all times.
The User Images widget handled the looping animation sequences in both projects, cycling through exported frame sets to create the illusion of movement. Static text labels, LED digit widgets, and background imports rounded out the toolset. None of this required deep knowledge of display drivers or graphics rendering pipelines. The environment abstracts that complexity away, letting developers focus on what the interface should do rather than how the hardware should do it.
The code that drives these displays is correspondingly lean. Both projects use a straightforward loop structure: initialise the display, show the form, enter an infinite animation cycle that updates gauge frames and image sequences. For the treadmill, this also updated the LED digit values continuously. The logic is compact enough to read in a few minutes, which matters when the same codebase may need to be adapted, handed off, or scaled across product variants.
Stage Three: Into the Real World
Deploying a display UI is not the end of the project. It is the point at which software meets the physical constraints of a real product. The bike speedometer project made this dimension explicit. Rather than treating the display as a standalone unit, the developer designed a custom 3D-printed housing to mount the Pixi LCD into an existing phone mount on the handlebars. The housing was modelled to fit within the mount’s boundaries, with a dedicated exit point for the flex cable, and printed in black filament to match the bike’s existing components.
This step is often treated as an afterthought in embedded display development, something to be figured out after the software is working. The 4D Systems ecosystem encourages the opposite. Because display dimensions, step files, and datasheets are documented and accessible from the outset, physical integration can be designed in parallel with the UI. The result is a cleaner product and a shorter path from prototype to deployment.
The Same Workflow, Infinitely Repeatable
What is most instructive about these two projects is not the technical detail but the structural consistency. A fitness tracking interface and a cycling speedometer are different products with different audiences, different data sources, and different physical constraints. Yet both were built using the same three-stage process, the same core widgets, and the same underlying programming environment.
That repeatability is the real value proposition. Engineers and designers working across multiple product lines do not want to relearn a development pipeline for every new display project. They want a workflow that is consistent enough to be efficient and flexible enough to accommodate different hardware, different UI requirements, and different deployment contexts. The 4D Systems ecosystem delivers that through the combination of the Pixi display range, the Workshop4 IDE, and a design philosophy that treats the journey from concept to casing as a single continuous process.
