Back home

Boilersync

Shared editing with rules people can trust

Dev tooling · collaboration

Multiplayer editing that feels dull in the right way

Pairing works until two cursors land on one line and nobody trusts the save. I wanted “who owns what” to be obvious before anyone walks away.

The focus was operational clarity: who edits what, which version wins, and how to recover after a disconnect. Predictable beats clever merge drama.

The sections below cover constraints, interface choices, and what we would measure if this moved past a prototype.

Role
UX for dev tools, systems thinking
Stack lens
Web editor, shared document model
Client
Course / team project
Status
Prototype and documentation

If you open a demo, watch latency and conflict UI, then jump back here.

01

Defining sync guarantees

Plain-language promises

We wrote guarantees users could repeat: your caret stays yours, saves stay linear per file, offline edits replay in view. Engineering mapped that to CRDTs or locks later; UX came first.

Ambiguity breeds mistrust. If two people can edit one line, the UI shows precedence without opening a manual.

  1. 1. List failure cases

    Simultaneous edits, disconnects, sleeping tabs, huge pastes. Rank by how often they hurt.

  2. 2. Pair UX to recovery

    Each failure needs a visible path: retry, fork, or lock. Silent repair loses to a dialog when someone is mid-debug.

02

Presence and attention

Avatars later; clarity first

Presence shows file focus, run state, and who executed last. Decorative avatars waited until basics worked.

Voice or huddle hooks stayed out of scope; the loop is type, run, and read output together.

03

Visual system in a dark workspace

Less glare, syntax that still reads

Chrome stays near black with brass accents on primary actions. Syntax colors target contrast on OLED laptops.

Chat and logs sit on slightly lifted surfaces so depth shows where collaboration lives versus execution.

04

Performance posture

What “fast enough” meant here

Targets were human: keystroke latency under a bar, streamed run output without blocking typing, file tree updates debounced but not stale for more than a second.

Profiling notes lived next to UX stories so tradeoffs stayed visible to everyone.

05

What would ship next

Roadmap if this continued

Next: conflict diff UI, session recording for grading, template projects that load the same way every time.

Metrics: session length without errors, time to first clean run, voluntary reuse week over week.

What did I learn?

  • Developer tools need copy that reads like a contract.
  • Presence design is workload design.
  • Prototype the unhappy path before you sell the happy one.

Feedback from lab sessions

When I could see who owned the buffer, I stopped hoarding the keyboard.
Lab participant, Student developer
Product and interaction
Laolu James
Engineering partners
As listed in repository