Dev tooling · collaboration
Multiplayer editing that feels dull in the right way
Pairing works right up until two cursors land on one line and nobody trusts the save. I wanted "who owns what" to be obvious before anyone walked away from the keyboard.
My focus was operational clarity. Who edits what, which version wins, and how you recover after a disconnect. Predictable beats clever every time someone is mid-debug.
The sections below cover the constraints, the interface choices, and what I would measure if this moved past a prototype.
- Role
- UX for dev tools, systems thinking
- Stack lens
- Web editor, shared document model
- Type
- Course and team project at Purdue
- Status
- Prototype and documentation
If you open a demo, watch the latency and the conflict UI first, then jump back here for the reasoning.
Defining sync guarantees
Plain-language promises
I wrote guarantees a user could repeat back. Your caret stays yours, saves stay linear per file, and offline edits replay in view when you reconnect. Engineering could map that to CRDTs or locks later. The promise came first.
Ambiguity is what breeds mistrust. If two people can edit one line, the interface has to show precedence without anyone opening a manual.
1. List the failure cases
Simultaneous edits, disconnects, sleeping tabs, and huge pastes. I ranked them by how often they actually hurt.
2. Pair UX to recovery
Every failure needs a visible path. Retry, fork, or lock. Silent repair loses to a clear dialog when someone is deep in a bug.
Presence and attention
Avatars later, clarity first
Presence shows file focus, run state, and who executed last. The decorative avatars waited until the basics actually worked.
I left voice and huddle hooks out of scope. The loop I cared about was type, run, and read the output together.
Visual system in a dark workspace
Less glare, syntax that still reads
I kept the chrome near black with cool blue accents on the primary actions. Syntax colors target real contrast on the OLED laptops students actually use.
Chat and logs sit on slightly lifted surfaces, so you can tell at a glance where collaboration happens versus where code runs.
Performance posture
What "fast enough" meant here
I set human targets. Keystroke latency under a clear bar, streamed run output that never blocks typing, and a file tree that updates without going stale for more than a second.
I kept the profiling notes next to the UX stories, so the tradeoffs stayed visible to everyone, not hidden in a ticket.
What would ship next
The roadmap if this continued
Next up would be a conflict diff UI, session recording for grading, and template projects that load the same way every time.
The metrics I would watch are session length without errors, time to a first clean run, and whether people come back to it week over week without being told to.
What did I learn?
- Developer tools need copy that reads like a contract.
- Presence design is really 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.
- Product and interaction
- Laolu James
- Engineering partners
- As listed in the repository