In the first UX article we looked at the foundation concepts to follow, and in this article, let’s explore the base objects and primitives io.Connect provides + their strengths.
Different Window types
Interop-enabled apps run inside io.Connect Windows, and this unlocks advanced Window Management capabilities regular desktop managers and browsers simply don’t have.
io.Connect Desktop supports four window modes - flat, tab, html, and frameless, and you can choose the mode either in the app definition or when opening a window programmatically.
Once you treat windows as first-class platform objects, you can design for real desktop behavior:
-
Users can group windows so they move/maximize/minimize together (crucial for multi-monitor workflows).
-
You get structured behaviors like tabs, where users can tear off and regroup items, and you can attach/detach tabs programmatically if you want to enforce patterns.
-
You can enable user interaction patterns like sticking windows, controlling standard window buttons, and adding custom frame buttons
-
Web and native (from Windows apps) windows are treated as abstractions, so for end-users there’s no difference between the two
Dive into windows: https://docs.interop.io/desktop/capabilities/windows/window-management/overview/index.html
Window groups
You don’t always need to put everything in one workspace. Sometimes it’s better to keep apps as separate windows, but make them act like a single unit. That’s what Window Groups do: users can stick io.Connect Windows together into one frame so they can move, resize, minimize, maximize, restore and close the whole set together using the standard buttons on the group frame. The group also gets one taskbar icon (customizable), windows can be resized inside the group, and users can tear off windows when they want to break the structure. Tab windows can form tab groups, and those tab groups can still be stuck to other windows or groups.
From a UX perspective, Window Groups are a fast structuring primitive:
-
Great for multi-monitor traders/power users who want a stable wall of apps, but still need each app as its own window.
-
Great for one workflow, many windows patterns (charts + order ticket + blotter + news) where users want cohesion without forcing everything into a single container.
-
Grouped windows share a common outer border when aligned; users can resize the whole group from that border, or hold ALT to resize a single window instead. Holding ALT also prevents “Snap & Drop” while dragging (so users can position freely without snapping into a group).
Workspaces
A Workspace is where you turn “a set of apps” into “a working surface”.
In io.Connect Desktop, Workspaces let you arrange multiple apps inside the same visual window, either programmatically or via drag-and-drop. Each app is treated as a building block that can be added, removed, moved, or resized within the Frame, and Workspace Layouts can be saved and restored (including restoring into different Frames). A Workspace Layout can preserve the arrangement and can also save context, so users can resume where they left off.
UX implications worth designing for:
-
One “center of gravity” per workflow. Workspaces are ideal when you want a user to stay inside a bounded environment while executing a task (triage, exception handling, client review, order workflow). The Frame becomes a stable shell, instead of letting windows flood the desktop.
-
Tabs as workflow lanes. The Workspaces App can hold multiple Workspaces as tabs in one or more Frame instances, so you can map tabs to activities (“Morning prep”, “Client call”, “Execution”, “Post-trade”).
-
The default shell isn’t a limit. The Workspaces App is a system web app, and it’s possible to create your own custom Workspaces App if you need a stricter or more domain-specific workflow surface.
Drill down into workspaces: https://docs.interop.io/desktop/capabilities/windows/workspaces/overview/index.html
Layouts
Layouts offer a way to save the arrangements of all apps on all of your windows (monitors), with the exact bounds and position, and most importantly, with the context. We’ve seen users often run multi-monitor setups and create separate Layouts for different tasks, restore with a single click, and choose a default Global Layout that loads on startup.
If you want the default layout to not restore automatically on startup, that’s a deliberate UX choice that can be set using restoreDefaultGlobalOnStartup.
Layouts can be served remotely, polled for updates, and connected to an entitlement system, so different users get different layouts. They also expose events related to adding, removing, changing or saving Layouts. Layouts can be used as templates, backup artifacts, migration assets, or “golden” presets for roles.
Learn about Layouts: https://docs.interop.io/desktop/capabilities/windows/layouts/overview/index.html
Launchpad
The Launchpad can provide guided discovery for apps, Workspaces, and Layouts, including search and platform preferences. It’s a customizable web applications that acts as a central hub for apps, Workspaces, Layouts, notifications, preferences, and more.
More about the Launchpad: https://docs.interop.io/desktop/capabilities/launcher/index.html
Notifications
io.Connect Desktop normalizes and consolidates notifications from different apps and delivers them directly to users on the desktop as in a Notification Panel.
But it’s not just the simple notification toasts that can be closed or snoozed. The power comes when you combine notifications with actions (interop methods) and turn them into a smart guided workflow. Design your notifications so the next click lands users in the right app with the right context.
Discover the notifications panel: https://docs.interop.io/desktop/capabilities/notifications/overview/index.html
Map capabilities to journeys
In the next article, let’s think about the right mental model. Not just understanding interop capabilities, but mapping them to user journeys, so the orchestra plays like one.