**Note** from Bead: Wedtech Beads 2026 07 08 · [canonical source](https://redfish.acequia.io/guerin/.agents/9d343253-c279-47ac-a066-cc31ce505782/2026-07-08/notes/09-sketches-in-redfish-uxui.md) · session 2026-07-08 · discussion: Talk: Wedtech Beads 2026 07 08
New talk topic (Stephen, 2026-07-08): the importance of sketches in Redfish team user-centered design. Buxton's argument, as practiced here: sketches lead the work, rendered rough on purpose, foregrounding questions and alternatives instead of polish. The team's design loop runs sketch, question, decide, then build. The talk itself demonstrates the practice: near the beginning, a gsd-style pen-and-ink sketch of the facets of a bead, minimal labeling. Drafted at [sketch-bead-facets.html](https://redfish.acequia.io/guerin/.agents/9d343253-c279-47ac-a066-cc31ce505782/2026-07-08/artifacts/sketch-bead-facets.html) in two compositions with a questions dock.
## Facets the sketch must carry (Stephen's list) - inbox / outbox. **Outbox needs to be added**: beads today have inbound docks (`uploads/`, `request/`, and the working-docs bead added `inbox/`) and a correlated `response/` lane, but no general efferent outbox. The sketch draws the outbox dashed, as a proposal. - upload (the `uploads/` dock, immutable inbound provenance). - mjs (the bead's executable module face). - handler.js (the bead as WebDAV handler; prior thread in bead [fe7fbaf5](https://redfish.acequia.io/guerin/.agents/fe7fbaf5)). - chat links (the `chats/` path of light). - links to other beads: **links as primitives**, the first-class edges of the network. - README.md for deployments that reference the bead: the deployed app's front door gives the app's context and points back to the bead and the git repo. - git repo view (the `repo/` in-bead git with the source-viewer pattern from [git-source 85fb7f54](https://redfish.acequia.io/guerin/.agents/85fb7f54-b77a-4025-a2b2-733f0130ad9c/)).
## Decided (Stephen, checkbox round two) - **Composition: A (bead as cell), iterated.** Stephen's direction: "just label the different facets around a bead like a hubler bead. the request / response with handlers and inbox/outbox are the 'polarity' that forms the least action compute and data sync matrix of richard forman." v0.2 redraws the bead as a Hubler bead with a polarity axis: afferent pole (inbox: request + uploads, with a handler on the rim) and efferent pole (outbox, with its handler), mjs and repo inside, chats trailing, polarized links to neighbor beads, README arrow from the deployed app, faint Forman patch-matrix hatching behind. - **Outbox semantics (Stephen, verbatim):** "when a bead processes an inbox it puts it in the outbox. the message package has the 'hey you its me' header with the uri of the other agent/bead's inbox. the comms may be async, or websocket or other." So the outbox is the staging lane the step fills while draining the inbox; each package is addressed by destination-inbox URI; transport is pluggable (async PUT, websocket, other). - The Forman frame: polarized links between beads act as corridors, beads as patches, the commons as the matrix; traffic settles into least-action compute and data-sync paths. Connects the Hubler wires thread (structure persists where flux flows).
## Open questions - [ ] Does the v0.2 polarity axis read correctly (− inbox pole, + outbox pole)? - [ ] Should neighbor beads sit inside drawn patches with links as corridors, making the Forman matrix explicit rather than background hatching? - [ ] Does the sketch stay pen-ink in the final deck, or get a rendered twin for the facets section?
## References (bead cross-links) - Bead: Git Source · [canonical](https://redfish.acequia.io/guerin/.agents/85fb7f54-b77a-4025-a2b2-733f0130ad9c/)