Views bind to tool state, participant state, and session commands through MVVM view models.
Case File 01
Collaborative Screen AnnotationA shared visual layer for remote explanation.
A cross-platform desktop proof of concept that lets several participants draw, point, highlight, and explain within the same visual session.
01 / Product
What the application does
The application behaves like a lightweight collaborative overlay. A host creates a session, shares a join code, and controls whether other participants can draw, point, erase, or only observe.
Each participant sees locally rendered input immediately while the application synchronises vector-based annotation events through a small session relay. New participants receive a snapshot of the current canvas before live events continue.
Primary workflow
Create session → join session → annotate → review or clear → export session image.
Illustrative stack
C#, .NET 10, Avalonia, MVVM, ASP.NET Core SignalR, JSON message contracts.
Core features
Pen, highlighter, arrow, participant pointers, per-user undo, host lock, reconnect, snapshot sync.
Target users
Remote teachers, support staff, design reviewers, technical teams, and collaborative presenters.
HOST
USER B
02 / Problem
The problem behind the interface
Screen sharing gives everyone the same image, but not the same ability to point at or change that image. Verbal directions are slow and ambiguous when layouts move or several people need to contribute.
The application therefore needed to feel immediate for the person drawing, remain understandable when several cursors are active, and recover without losing context when a participant reconnects.
Primary design requirements
- Render local input without waiting for a network round trip.
- Preserve stroke ownership so undo and moderation remain predictable.
- Allow a late-joining participant to reconstruct the current shared state.
- Keep host controls visible without crowding the drawing surface.
- Handle temporary disconnection without silently discarding user input.
03 / Ownership
My role and responsibilities
As Project Lead and the studio’s only developer, I treated the project as both a software system and a product exercise. I owned scope, technical direction, interface behaviour, implementation, testing, prioritisation, and the final portfolio narrative.
- Defined the host and participant workflows and reduced the first release to one shared-session loop.
- Built the Avalonia shell, tool palette, overlay surface, participant list, and session-state views.
- Designed message contracts for strokes, pointers, permissions, snapshots, reconnects, and clears.
- Implemented local-first drawing and remote event application in C#.
- Created manual test scenarios for multi-client sync, delayed messages, reconnect, undo, and session lock.
04 / Architecture
How the proof of concept is structured
The proof of concept separates drawing, session state, and transport so the interface can be tested without requiring a live server.
A custom drawing surface stores strokes as vector point sequences with colour, thickness, tool type, owner, and sequence number.
A transport abstraction sends and receives strongly typed session messages and exposes connection state to the UI.
An ASP.NET Core SignalR hub distributes live events and stores the latest session snapshot for reconnecting or late-joining clients.
05 / Decisions
Technical decisions worth discussing
The proof of concept is intentionally small, but the decisions below show how the application would remain understandable and maintainable as it grows.
Vector events are smaller, replayable, attributable to a participant, and easier to undo than repeatedly transmitting images.
A stroke appears immediately on the local device, then the remote acknowledgement reconciles ordering without blocking the user.
The host owns session rules such as who can draw, clear, or lock the surface, reducing conflicting state changes.
A new participant loads the latest snapshot, then applies events that occurred after the snapshot sequence number.
06 / Validation
Sample proof-of-concept evaluation
For a portfolio demonstration, the application was evaluated with three desktop clients on one local network and under simulated delay.
The host and two participants could draw at the same time while strokes remained attributable to the correct user.
Local drawing remained responsive because rendering did not wait for the relay; remote movement became less fluid but remained understandable.
The client reconstructed the canvas from a snapshot and continued applying live events without visible ordering errors in the sample run.
A participant rejoined, received the current snapshot, and resumed drawing without manually restarting the session.
07 / Outcome
Result, limitations, and next steps
The proof of concept demonstrates the complete shared-annotation loop and the architectural boundaries needed for a larger collaboration product. Its main limitation is that the sample relay is suitable for demonstration, not production-scale identity, persistence, moderation, or security.
The project demonstrates interaction design and shared-state reasoning rather than presenting drawing as an isolated canvas feature.
The proof of concept does not include production authentication, encrypted session history, large-room scaling, or full screen-capture integration.
Add persistent accounts, session recording, screen-selection capture, load testing, and moderated guest access.
Show a two-minute multi-client demo, a message-flow diagram, reconnect tests, and one annotated code example.
What this project demonstrates
C# desktop development, Avalonia custom controls, MVVM, real-time state synchronisation, optimistic UI, failure-state design, and end-to-end ownership as a solo Project Lead.
Project links