- Application: Research tool for managing and coding audio-visual media
- Project: Bluey (The Magic Xylophone artefact), 305 transcript segments
- Tab 0 (User A): javagrant@gmail.com (Owner)
- Tab 1 (User B): Same account (javagrant@gmail.com), second browser tab
- Key finding: Undo stacks are per-tab (in-memory), not shared across sessions
Action: Edit segment text → Press ⌘Z Result: ✅ Text reverted to original. Segment restored.
Action: Edit segment → Undo → Press ⌘⇧Z Result: ✅ Redo restores the edit. Standard undo/redo cycle works.
Action: Edit segment A (TEST3A), then segment B (TEST3B) → Press Undo twice Result: ✅ LIFO order — first undo reverts segment B, second undo reverts segment A.
Action: Edit seg6 → Undo → Edit seg5 → Redo
Result:
- Key difference from Google Docs: Google Docs clears redo stack on any new local edit. Scope 2 preserves it.
- Possibly due to per-segment undo architecture vs Google Docs' linear document undo.
Action: Select uncoded segment → Press D (Bandit hotkey) → Press ⌘Z Result: ✅ Speaker assignment reverted. Segment returned to unassigned state.
Action: Edit seg6 text → Assign Bandit speaker to seg5 → Press Undo twice Result: ✅ Each action type creates separate undoable entries.
- Undo 1: Reverted speaker assignment on seg5
- Undo 2: Reverted text edit on seg6
Action: Tab 0 edits seg5 (TAB7_A) → Tab 1 edits seg6 (TAB7_B) → Tab 0 presses Undo Result: ✅ Only seg5 (TAB7_A) reverted. seg6 (TAB7_B) preserved.
- Confirms each tab has its own undo stack scoped to that session.
- Tab 0 could NOT see Tab 1's edit in real-time (no websocket sync).
Action: Tab 1 edits seg6 → Tab 0 checks seg6 (without refresh)
Result:
- Key difference from Google Docs: Google Docs pushes changes via WebSocket/OT immediately. Scope 2 requires page refresh to see other sessions' edits.
Action: Tab 1 edits seg8 (PERSIST_TEST) → Refresh Tab 1 Result: ✅ Edit survived page refresh. Changes are server-persistent.
Action: Tab 1 makes edit → Refresh → Press ⌘Z Result: ❌ Undo stack cleared on page refresh. Only latest committed state loads from server. Undo history is client-side (in-memory) only.
- Key difference from Google Docs: Google Docs maintains undo history in session/OT context; Scope 2's undo stack is in-memory only.
Action: Tab 0 undoes seg5 → Tab 1 refreshes → Check seg5 Result: ✅ Tab 1 sees the undone state after refresh. Undo commits to server.
- Per-tab undo stacks — each browser tab maintains its own undo/redo history independently
- No real-time collaboration — Studio does not use WebSocket/OT; page refresh required to see others' changes
- Server persistence on every edit — each ⌘⏎ save commits to server immediately
- Undo stack is in-memory only — lost on page refresh; server tracks only latest state
- Redo stack survives new edits — unlike Google Docs, a new local edit does not clear the redo stack
- Undo commits to server — pressing ⌘Z triggers a server write; refreshed tabs see the undone state
- Speaker attribution is an undoable action — assigning a speaker via hotkey creates separate undo entry from text edits
- Segment-based editing — each segment is independent; editing one does not affect another's undo stack position
- Focus requirement — transcript list must be clicked before ⌘Z/⌘⇧Z works after tab switches (similar to Google Docs' hidden iframe focus requirement)
- Keyboard shortcuts — E (edit), ⌘⏎ (save), Escape (cancel), ⌘Z (undo), ⌘⇧Z (redo), D/N/B/M/O/P (speaker hotkeys), A (codes), C (comment), Space (play/pause), ⌘K (palette), H (help)
| Feature | Google Docs | Scope 2 Studio |
|---|---|---|
| Real-time sync | ✅ WebSocket/OT push | ❌ Page refresh required |
| Undo stack scope | Per-session/tab | Per-tab (in-memory) |
| Undo persists cross-tab | ✅ OT-transformed | ✅ After refresh |
| Redo survives new edits | ❌ Cleared | ✅ Preserved |
| OT transformation of undo | ✅ Full OT | N/A (no concurrent editing) |
| Typing burst grouping | ✅ 100ms threshold | N/A (segment-based edits) |
| Undo stack on refresh | ✅ Preserved in session | ❌ Lost |
| Multi-user concurrent edit | ✅ Full OT support | ❌ No concurrent mode |