Source: ViewEdit

Black-box service map

A black-box service map is a dashboard layout model in which each service’s master page is drawn as a function diagram: an input box on the left, a large black box named for the service in the middle, and an output box on the right. Every setting sits where it belongs in that picture. Things that shape what goes in sit on the input. Things that change how the service behaves sit on the box. Things that shape what comes out (delivery, retention, alerts, exports) sit on the output.

In plain language: the page looks like what the service does, so you know where a setting lives before you look for it.

This is a concept note, not a finished pattern. It records Ryan Johnson’s proposal, the open questions, the research it draws on, and some possible demos.

The model

One service, one diagram

Most service dashboards are a tab strip of nouns: Overview, Deployments, Logs, Settings, Integrations. The black-box model swaps the tab strip for a single spatial frame that matches how an engineer already thinks about the service: something goes in, something happens, something comes out.

Input Black box (service name) Output

Sources, triggers, credentials, ingress rules, webhooks in

Runtime, scaling, region, version, behaviour flags

Destinations, logs, metrics, alerts, webhooks out, exports

Clicking a region opens it with an animated transition that keeps the diagram visible as context. The preferred design below says what each click opens.

Directories of services, nested recursively

A multi-service platform starts at a directory of its services and products. Each entry opens into its own input/box/output view, and the nesting continues:

  • Top level: the directory, plus global settings only (billing, identity, org-wide policy).

  • Workspace or team level: the services in that workspace, each as a black box, with workspace-scoped settings on the workspace’s own frame.

  • Project level: the project’s services and their wiring, then the single service view.

Each level is the same shape, so a user who has learned one level has learned them all. Settings never float across levels: a project setting cannot appear on the team page. That is the direct fix for location overloading, where one sidebar slot means a team page or a project page depending on hidden filter state.

A uniform, white-label dashboard

Taken all the way, the model is a uniform management dashboard: one frame that any platform could fill with its own services and white-label. Companies would stop rebuilding the same dashboard chrome, and users would carry one spatial habit from vendor to vendor.

Preferred design: box-anchored overlays and a breadcrumb

Ryan’s refined design keeps the function-model page as the stable base and opens everything from it:

  • Input or Output box: clicking it opens that box’s settings as a semi-transparent overlay on top of the function-model page, anchored to the box. The diagram stays visible underneath, and closing the overlay returns you to the same page.

  • Black box: clicking it opens an overlay for picking a sub-item (a workspace, project, or child service). Picking one clears the view and loads a new page with the same input/box/output model at that level.

  • Navigation: a simple breadcrumb at the top, possibly centered (for example, Org › Workspace › Project › Service). Each crumb loads that level’s function-model page. With levels this uniform, the pseudo-3D footprint may not be needed. It is kept below as an alternative.

Summonable nav map (tree trace)

The breadcrumb stays the always-visible navigation. For the whole hierarchy at once, this note proposes a summonable nav map: a new tree trace of the levels, with one node per page.

  • Trigger: a simple minimize button in a fixed spot on the page. It never moves and never changes meaning.

  • Off screen by default: the map takes no space until it is summoned.

  • Minimize: clicking the button shrinks the current page into its own node in the tree-trace map, which then fills the view.

  • Restore: clicking that node (or any other node) grows the page back out of it. Clicking another node loads that level’s function-model page.

  • Animated both ways: the shrink and the grow are animated, so the user sees exactly where the page went and where it comes back from. Because the transition shows the state change, the map is not a hidden mode, which keeps it consistent with Location overloading.

The tree trace is a new proposed map, not existing work. It is modeled on the Map Edge variant of Context Edge, which summons a wireframe ecosystem map from the screen edge (Map Edge demo). The tree trace takes that summoned-map idea and adds the minimize-into-node transition. For a related reference, Path Edge draws the edge as a trace of the hops you took (Path Edge demo).

Why this avoids location overloading

Location overloading happens when one screen location does different jobs depending on hidden context. Here each overlay comes from its own box: the input overlay only ever holds input settings, the output overlay only output settings, and the black-box overlay only ever picks the next level down. A location’s meaning stays fixed. Scope changes only by loading a new page, and the breadcrumb names that page, so scope is never a hidden filter on the same slot.

Alternative: navigation footprint

Instead of the breadcrumb, the top of the page could carry a navigation footprint: a pseudo-3D stack drawn as a 2D projection. The base level (the directory) is the widest layer at the bottom. Each deeper level is a smaller layer above it. Each child connects to its parent with lines, or with a translucent trapezoid that reads as a projection from the parent’s slot, the way a zoomed region links to its source in an overview+detail view.

Open questions:

  • Canvas or DOM? Canvas or WebGL gives smooth projection and animation. DOM keeps links, find-in-page, text selection, and the accessibility tree.

  • Zoom and pan? Should the footprint itself zoom and pan (a small ZUI), or stay a fixed breadcrumb picture?

  • Overflow: wide directories could scroll horizontally inside their layer, but horizontal scroll is easy to miss. It needs a visible affordance.

Is separating navigation from content the problem?

The preferred design gives one answer: the breadcrumb is the only separate navigation, and the diagram itself is the way in, with overlays keeping content on the same surface. The question stays open for the alternatives below.

Most dashboards put navigation (sidebar, tabs, breadcrumbs) in one place and content in another. The black-box model hints that they could be one surface: the diagram is both the map and the page.

If they merge, the page has to stay clean while you work in it. Some options:

  • The diagram shrinks to a thin strip (or into the footprint) while a region is open, and expands again on exit.

  • Focus+context: the open region gets most of the space, and its neighbours stay visible but compressed, like a fisheye view.

  • Explicit modes ("map" and "work") are tempting, but a mode is exactly what the location-overloading research warns about. Any mode must be visible at the point of action.

Toward windowing inside web apps

A further direction is real windowing inside a web app: inputs, the box, and outputs as movable, dockable windows, as in the egui web demo (egui.rs), where many floating windows share one browser canvas. egui is an immediate-mode Rust GUI that renders through WebGL, so its web build gives up the inspectable DOM. Its README notes that web accessibility relies on an experimental built-in screen reader rather than the browser’s own (egui README). That trade suggests a research question: what would a DOM model for windowed apps look like? It would need a semantic tree that knows about windows, z-order, docking, and focus, so that windowed web apps keep inspection, links, and assistive technology. See Spatial web windows and Contained tiling for the org’s existing work on windows in the browser.

Research background

Spatial memory and the method of loci

People remember where things are, and stable locations become fast to reach. The method of loci, which places items along an imagined route, was the strategy most used by the world-class memorisers that Maguire et al. (2003) scanned. They showed no structural brain difference from controls but did show heavier use of spatial-memory regions, including the hippocampus. The hippocampus’s role in place goes back to O’Keefe and Dostrovsky’s (1971) place-cell recordings. In interfaces, Robertson et al. (1998) found that people could retrieve web pages by their spatial position on Data Mountain, and Scarr et al. (2012, 2013) showed gains from spatially stable command layouts. A black-box map gives every setting a fixed place in a picture that is the same at every level, which is the condition these studies reward.

Zoomable user interfaces

Pad (Perlin & Fox, 1993) and Pad++ (Bederson & Hollan, 1994) put information on an infinite plane you move through by zooming, rather than through windows and pages. Raskin’s The Humane Interface (2000) proposes ZoomWorld (chapter 6, "Better Navigation: ZoomWorld"), where navigation is zooming into a single space instead of opening applications and files. The recursive service directory is a ZUI with fixed levels: zooming into a box reveals its own input/box/output.

Focus+context and overview+detail

Furnas (1986) proposed generalized fisheye views, which show the local focus in detail and distant items according to a degree-of-interest function. Card, Mackinlay, and Shneiderman’s Readings in Information Visualization (1999) collects the classic focus+context and overview papers. Cockburn, Karlson, and Bederson (2009) review overview+detail, zooming, and focus+context designs and the evidence for each. Their review is the closest guide to choosing between a footprint (overview+detail), a zoom transition, or a compressed fisheye neighbourhood.

Dataflow and node UIs

Diagrams of boxes with inputs and outputs are the native picture of dataflow programming. Johnston, Hanna, and Millar (2004) survey dataflow languages, including visual dataflow environments where programs are drawn as nodes and wires. The black-box model borrows that picture for configuration rather than computation. A service is a node, its settings are its ports, and a project view is a small dataflow graph of the services in it.

Relation to existing HCI-Nerdz work

  • Context Edge and Context rails move ecosystem travel to thin edge rails. The navigation footprint is a vertical, stacked cousin of the same idea: show where you are in the hierarchy without spending the content area.

  • Context-bound settings argues that a setting belongs next to the thing it affects. The input/box/output layout gives that rule a fixed geometry.

  • Scoped UX architecture separates global, workspace, and project scopes. Here each scope becomes one nesting level.

  • Spatial web windows, Contained tiling, and Agent Canvas explore windows and desks in the browser, the starting point for the windowing direction.

  • The Pipeline composer demo (hci-nerdz.github.io/pipeline-composer) already draws a typed processing map with insert-between sockets and nested composites. It is the closest existing piece to a service drawn as a box with ports.

  • Location overloading names the problem this model is meant to remove.

Possible demo directions

  1. Preferred design, single service. One fake service (for example, a hosting deployment) as an input/box/output page. Input and Output open box-anchored, semi-transparent settings overlays. Test: can a user predict where a named setting lives before opening anything?

  2. Preferred design, recursive levels. The black-box overlay picks a sub-item and loads the next level’s page, with a centered breadcrumb. Org → workspace → project → service, global settings only at the top. Compare against a Vercel-style unified sidebar on the same task set, measuring wrong-scope edits.

  3. Overlay variants. Anchored popover, larger anchored sheet, and centered modal, all at the same transparency. Measure whether the anchor keeps the "which box am I editing" link and whether the dimmed diagram distracts during long edits.

  4. Breadcrumb vs footprint. The preferred breadcrumb (centered and left-aligned) against the alternative footprint with lines or translucent trapezoids. Build the footprint once in DOM/SVG and once in canvas to compare inspection, accessibility, and animation.

  5. Windowed regions (alternative). Inputs, box, and outputs as tear-off windows on a desk, reusing the Spatial web windows desk, with a prototype "window tree" exposed to the accessibility tree.

  6. Summonable nav map (new). Build the proposed tree-trace map, modeled on Map Edge, and add the fixed minimize button to the preferred-design demo. The page animates down into its node in the map, and clicking a node restores it or loads another level. Reuse the Context Edge Map Edge tree (src/lib/org-tree.ts). Test whether users can say where the page went and get back without help, and compare against the breadcrumb alone.

  7. White-label skin. The same frame filled with two different vendors' service catalogs, to test whether the spatial habit transfers.

References