Tonight I pushed Owen Display through the part of the journey that separates a cool local dashboard from something I can actually depend on.

Earlier phases were about making the system useful on one screen. These four phases were about making it feel like a real control surface: multiple displays, configurable audio alerts, custom modules without writing code, and a portal that works cleanly on iPhone as a PWA.

That sounds like a checklist. It wasn’t. It was a systems problem.

From one display to many

The first big shift was multi-display support. Instead of treating Owen Display like one giant app window, I moved to independent per-display state. Each monitor gets its own screen, theme, rotation, and module routing. That matters because different displays serve different jobs.

One screen might be showing the current time and weather. Another might be dedicated to project health. Another might be a large status board. If they all share one state blob, the system gets rigid fast. If each display owns its own config, the whole thing becomes much easier to reason about.

Hot-plug support was the other important piece. Displays should not require a restart every time a monitor appears or disappears. The app now creates and destroys windows at runtime as the display topology changes. That’s the difference between “works in a demo” and “works in a room with real hardware.”

Alerts that are useful, not noisy

Phase 27 added audio alerts for critical notifications. I kept it simple: a Web Audio chime with a volume control, not a giant text-to-speech system.

That choice was deliberate. For this kind of app, alerts need to be immediate and predictable. A short chime gets attention without becoming part of the product’s personality. I also added quiet hours, because the whole point of alerts is to be useful when I’m available, not annoying when I’m not.

The portal now exposes the basics I actually need:

  • enable / disable
  • quiet hours start and end
  • volume slider
  • test button

That’s enough control to make alerts feel intentional instead of spiky.

Custom modules, but without making users write code

Phase 28 is the one I’m most interested in long-term: custom module authoring through JSON config.

I don’t want every new dashboard tile to require a bespoke code path. That scales badly. So I built a small config-driven module system where users define a module in ~/.owen/custom-modules/*.json and the runtime handles the rest.

Here’s the shape of one of the configs:

{
  "id": "crypto-price",
  "name": "BTC Price",
  "enabled": true,
  "refreshIntervalMs": 300000,
  "dataSource": {
    "type": "http",
    "url": "https://api.coinbase.com/v2/prices/BTC-USD/spot",
    "timeoutMs": 10000
  },
  "layout": "counter",
  "displayFields": {
    "value": "data.amount",
    "unit": "$",
    "label": "BTC / USD"
  },
  "theme": {
    "color": "amber",
    "scale": 2
  }
}

That buys a lot:

  • HTTP, file, and process-backed data sources
  • multiple render layouts like counter, list, grid, and status
  • preview/test support from the portal
  • screen routing with custom:module-id

In practice, that means I can add something like crypto prices, system stats, or a health check without touching the renderer every time. The portal becomes a module manager, not just a settings page.

The portal finally works like a real remote app

Phase 29 was the final step: make the portal work properly as a PWA on iPhone.

That means the control surface is not just “a webpage I can open in Safari.” It can live on the home screen, launch full-screen, and behave like a proper standalone app.

Conceptual screenshot: the Owen Display portal icon sitting on an iPhone home screen, opening full-screen in standalone mode.

The mobile work mattered more than the badge on the feature list suggests. If I can’t reliably control the system from my phone, it’s not truly remote-controllable. Once the portal had a manifest, service worker, touch-friendly layout, safe-area handling, install support, and offline-aware behavior, it stopped feeling like an admin page and started feeling like a product.

What the tests told me

By the end of Phase 29, the suite was at 160 tests passing.

That number matters because this wasn’t a one-off demo sprint. The changes touched display lifecycle, alerts, module loading, portal behavior, PWA assets, and mobile UX. If the test count had stayed flat, I’d be nervous. Instead, the coverage kept pace with the feature growth.

What changed, really

The bigger story is not that Owen Display got four more features. It’s that the architecture crossed a threshold.

It went from:

  • one display
  • one experience
  • one fixed set of screens

to:

  • many displays
  • configurable behavior
  • extensible modules
  • remote control that works on the device in my pocket

That’s the point where a system stops being “finished” and starts being usable in the real world.

That’s the kind of finish line I like.

React to this post: