Distributed User Interfaces

Coordinate interface units and shared state across devices.

Made for teams exploring multi-device experiences.

Overview

This engineering project is under active development. The scope below describes its intended design; deployment readiness and supported capabilities must be confirmed for each engagement.

A collaborative experience can use different devices for different jobs. A phone can hold controls while a larger display presents shared content; a personal screen can show an individual workspace within a group session. Those arrangements require more than broadcasting the same page everywhere.

The framework treats a distributable interface unit as an explicit object with state, capabilities, constraints, and lifecycle. A session records which devices participate and where units are assigned. Applications can then describe how the interface should be distributed through defined operations rather than maintaining a collection of ad hoc device messages.

What it provides

Distribution core

Define what moves

Distributable units declare their required capabilities, state schema, permissions, and lifecycle hooks. A registry tracks them, while a distribution engine validates requested operations against the relevant unit and device context.

The operation vocabulary includes migration, cloning, extension, splitting, merging, and pinning. These concepts let an application distinguish moving a unit from creating another surface for it, or preventing a unit from leaving a particular device. Per-unit operation queues provide a defined order for competing requests.

Sessions and topology

Coordinate participants

The session model records devices, roles, assignments, and topology changes. Host, peer, observer, and guest roles describe participation, while device capabilities include display and input characteristics.

A coordinator shares changes with participating devices so the experience can respond when a participant joins, leaves, or changes an assignment. Interface location becomes session state that an application can inspect, not an assumption hidden in a local component tree.

Synchronisation

Share state through suitable channels

Adapters provide in-memory, WebSocket, WebRTC, and Yjs-based synchronisation paths. WebSocket coordination connects participants through a server. The WebRTC adapter can carry state patches over peer data channels and fall back to the relay when that path is unavailable.

Yjs integration supports shared-state scenarios using CRDT techniques. The adapter boundary lets an application select its synchronisation model while keeping distribution concepts separate from a single network transport.

Bindings, examples, and inspection

React bindings provide a distributable-unit hook and session context, connecting unit state and operations to application components. A Web Component surface provides another integration path. Developer tools and topology displays help explain which devices and units are participating.

The reference demo includes a sketch canvas, colour palette, note board, and operator controls. These surfaces make it possible to explore a shared experience in which the controls and content can have different device assignments.

Integration example

A host opens a drawing session on a larger display and a peer joins from a phone. The application registers its palette and canvas as separate units with validated state. An allowed distribution operation assigns the palette to the phone, and synchronised changes connect the control surface to the shared drawing experience.

The example illustrates the framework's intended composition pattern. The application defines who may join, what each device is permitted to do, and how its drawing data is represented.

Built with

Baobab translated academic distributed-interface concepts into typed developer primitives, lifecycle handling, device constraints, adapters, and working demonstrations. The implemented reference coordinator uses a Node HTTP/WebSocket server, alongside browser bindings and peer-channel logic.

This project demonstrates a different kind of interface architecture: the application's structure spans devices, and its state and topology need to remain coherent as that arrangement changes.

Questions

Is this available for deployment?

Deployment readiness has not yet been verified for this catalogue entry. Contact us to discuss current scope, release gates, and your requirements.

Who owns this software?

This is owned engineering work from The Baobab, a brand of Fortezza Nuova Enterprise. Deployment and licensing terms are agreed for the relevant product.

Back to all engineering

Use Distributed User Interfaces in your product

Discuss the capabilities you need, deployment environment, and integration responsibilities. We will confirm current readiness and agree a scope before committing to a release.