Building OS

Context

Connecting equipment
data and people.

A Building Automation System (BAS) connects and controls systems such as HVAC, lighting, and security. On-site JACE controllers bring equipment from different manufacturers into Niagara, a shared software environment. Continual’s web interface translates that live data into a browser-based workspace where building teams can monitor operations, respond to issues, adjust controls, and manage schedules.

Equipment

Equipment. HVAC units, lighting, meters, sensors and security devices continuously generate operational data and respond to control commands.

JACE controller

JACE controller. Connects equipment from different manufacturers and communication protocols, bringing their data into a shared Niagara environment.

Niagara network

Niagara network. Structures equipment, points, schedules and control logic across the project, creating the operational foundation behind the interface.

Web interface

Web interface. Browser-based interface translates live Niagara data into navigation, graphics, controls, alarms, trends and schedules.

What began as a new interface for one client became an opportunity to rethink how Continual’s BAS products could work across every project. I led the building-based navigation model, interface design and interaction system, then implemented much of the experience in ECLYPSE Designer using live Niagara data.

Existing

Inherited System.

Previous interfaces reflected how each Niagara station was configured, not how operators understood and used the building. Because every station was organized differently, navigation and page structure changed from one project to another. Operators could reach the data and controls they needed, but only after learning how each system had been assembled.

Mixed organizing models

Locations, building systems, equipment groups and page types appeared within the same expanding navigation structure.

Navigation required memory

Finding equipment meant scanning long lists, opening multiple branches and remembering where individual pages had been placed.

Inconsistent across projects

Navigation labels, page layouts and location controls varied according to how each project had been configured.

Mixed structure

Systems, equipment types, locations and utility pages shared one tree.

Floor-based structure

Equipment was organized beneath a long list of building floors.

Organizing idea

Building became the navigation model.

I replaced the project-specific navigation tree with a consistent spatial hierarchy based on how operators locate equipment in the real world. The same model could be applied across projects regardless of how the underlying Niagara station was configured.

CAMPUS

Start at the Campus level to understand context.

BUILDING

Drill into each building for a systems overview.

FLOORS

Navigate by floors, roofs, basement and exterior

SYSTEMS

Move laterally between systems without losing context.

EQUIPMENT

Access equipment details without losing your place.

Design. Refine. Repeat.

Developed in collaboration with Continual’s engineering and building-operations teams, the interface evolved through weekly reviews with operators and technicians. Across four iterations, each round reduced navigation complexity, strengthened spatial context and focused the experience around the operator’s active task.

Version 01

System-first navigation

Retained the familiar equipment tree, but locations remained buried and large projects required extensive scrolling.

Version 02

Separating navigation layers

Separated Locations, Systems and Equipment, but the card-based layout fragmented the workflow.

Version 03

Connecting selection to context

Synchronized navigation, breadcrumbs and preview content, though the panels still competed for attention.

Version 04

Prioritizing the workspace

Integrated system filters into Equipment and expanded Preview, establishing the final left-to-right workflow.

Guided when needed.
Direct when known.

Users unfamiliar with a building can progressively narrow the interface by location, system and equipment. Experienced operators can select a known system or equipment entry directly without completing the full sequence.

Context stays
with the user.

The navigation menu disappears after a destination is opened, but the building hierarchy remains visible through an interactive breadcrumb. Users can understand where they are and move laterally without returning to the beginning.

One workspace from monitoring to scheduling.

Selecting equipment opens a consistent workspace to review live status, understand behaviour, adjust controls, inspect trends and confirm schedules without losing location context. The same structure keeps actions predictable across equipment types.

[data-wf-bgvideo-fallback-img] { display: none; } @media (prefers-reduced-motion: reduce) { [data-wf-bgvideo-fallback-img] { position: absolute; z-index: -100; display: inline-block; height: 100%; width: 100%; object-fit: cover; } }

Visual system.

Structure stays neutral

Dark surfaces, restrained radii and thin dividers organize dense information without turning every region into a separate card.

Colour carries meaning

Blue indicates navigation, selection and primary actions. Violet identifies manual overrides, while green, amber and red are reserved for operational conditions.

Patterns remain consistent

Typography, icons and interaction states repeat across navigation, equipment, trends and scheduling, reducing the amount operators need to relearn.

Implementation.

Built in DGLUX5/ECLYPSE Designer, the interface uses BQL and Dataflow to connect Niagara data with search, filtering and navigation. Reusable Page Includes and equipment templates keep the experience consistent across equipment types and projects, while breadcrumbs preserve the operator’s building, floor, system and equipment context.

Niagara Data

Niagara provides the live operational data behind the interface, including equipment status, temperatures, setpoints, alarms and schedules. Metadata identifies what each point represents and where it belongs within the building.

User Context

Each selection establishes the operator’s current context. That context determines which equipment, data and controls should appear while preserving their location within the broader building

Data + Logic

BQL queries retrieve the relevant Niagara points, while dataflows organize, filter and prepare the results for the interface. This layer translates raw station data into information the interface can consistently display.

Interface System

A shared interface system connects the processed data to reusable page structures and predictable interaction patterns. The same foundation can support different buildings and equipment types without rebuilding every screen.

Page includes + components

Shared page includes and components define the structure of navigation, equipment pages, status panels and controls. Updates can be made once and carried across the interface instead of being recreated for every system.

Interaction States

Interaction states manage what operators see as they search, filter and move through the building. Breadcrumbs and selected states preserve context, helping users understand where they are and how they arrived there.

Operator Experience

The final interface brings navigation, live status and equipment controls into one consistent workspace. Operators can move between buildings and systems without relearning how each Niagara station was assembled.

From one project to a shared system.

What began as a project-specific interface became a shared product system that can adapt across buildings while maintaining a consistent operator experience.

Release Milestone

V1 Deployed

V1 was deployed for its first client in April 2026 and established a reusable interface foundation for future Continual projects.