Implementing an Interactive Demo

Back in late August, I started building a new product¹ named Mezzi. Unlike other projects I’ve taken on, I started with the belief that I should build this to be a free service for developers.

I plan to keep Mezzi in ‘beta’ for a while, but it’s already a usable piece of ‘beta’ software. And every hour I get to put into it rewards me for the effort. I like these sorts of projects.

Writing about what I’ve learned should be something I do more of, and in that spirit, I gave up on writing and started with a video instead. Here’s what I recently worked on.

No long preamble in this short 8-minute video. I walk through the feature and show some code.

Adding a ‘Live Demo’ Page

I don’t plan to push or market Mezzi until a few key features are there, but some folks have discovered it already. One key feature is to showcase what Mezzi does before you sign up, and what better way to do this than to let people try it out with one click?

There is much about Mezzi that requires a user account to sync state between the client and server. Still, the biggest sticking point was my choice to use ActionCable for all the real-time behavior running over WebSockets, which encompasses two big parts:

1. To build a responsive experience while keeping the front-end simple, I use Hotwire. For an anonymous user, this means Mezzi must suppress updates which depend on user state.
2. Document editing relies on Yjs and I do this without requiring a separate WebSocket server process. ActionCable processes awareness (i.e., “cursor”) updates, and this means supporting users lacking any account or identity.

There’s a lot to talk about each of these in separate posts, but suffice it to say while providing a “live demo” of any app for a single-user has its quirks, doing so for a real-time collaboration tool is challenging.

Another Feature: Privacy Settings!

Building the ‘demo’ functionality forced me to think about how users can invite others to collaborate on an incident report. It is already possible to access other incidents in your account, but what about cross-account access or allowing temporary access to a single document to another user?

The setting below solves that.

Because incident reports often contain sensitive details, it’s unlikely that people will make all their documents public. It is more likely that a user will invite others to create an account within their “org .“But the idea of guest access is reasonable (i.e., if you are in the middle of a review meeting and someone wants to follow along, it’s better to share the link than demand the person creates an account right then and there).

Similar to how Google Docs allows you to control access to users on a per-document level, I would want Mezzi to do the same. And while what you see above is a simple case, I expect the ’lock’ to stick around.