The latest articles on DEV Community by Barsham Sotoudeh (@barsham). https://dev.to/barsham https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4061617%2Fdb651bb2-fa14-4c55-b605-8ce3d7f1664d.jpg https://dev.to/barsham en Barsham Sotoudeh Tue, 04 Aug 2026 03:41:20 +0000 https://dev.to/barsham/can-you-break-this-open-source-real-time-coordination-tool-in-seven-minutes-18f https://dev.to/barsham/can-you-break-this-open-source-real-time-coordination-tool-in-seven-minutes-18f <p>I maintain <a href="https://chantlive.online/" rel="noopener noreferrer">ChantLive</a>, a free and open-source tool for coordinating short, live messages at demonstrations and community events.</p> <p>An organizer prepares a list and pushes one item at a time. Participants open a public link, without creating an account, and see each update in real time. The source is on <a href="https://github.com/barsham/ChantLive" rel="noopener noreferrer">GitHub</a>.</p> <p>The stack is React, TypeScript, Express, PostgreSQL, Drizzle ORM, and Socket.IO. The interesting part is not the stack, though. It is whether the participant flow survives the messy conditions of a real event.</p> <h2> The seven-minute break test </h2> <p>You can do this alone with two browsers or devices.</p> <ol> <li>Open ChantLive and create a fictional event called <code>Community Test</code>.</li> <li>Add three harmless sample messages: <code>Welcome everyone</code>, <code>Together we can</code>, and <code>Thank you for being here</code>.</li> <li>Open the ordinary participant link in a second browser or device. No participant account is required, and you do not need to use the QR code.</li> <li>Change the current message three times from the organizer view.</li> <li>Refresh, briefly lock and unlock the participant device, or close and reopen the participant page.</li> </ol> <p>Please do not use a real event name, personal information, confidential material, or sensitive chants.</p> <h2> What I want to learn </h2> <p>A useful result is not "looks good." I would value one concrete failure or hesitation:</p> <ul> <li>Where did either role need an explanation?</li> <li>Did an update arrive late, disappear, or recover badly?</li> <li>What is the biggest reason you would not trust this at a real event?</li> <li>What one change would make it more useful or accessible?</li> </ul> <p>If browser, device, keyboard-only navigation, zoom, or assistive technology affected the result, please mention it. A short comment is enough.</p> <h2> Why I am asking here </h2> <p>Earlier outreach asked organizations to recruit two people and evaluate an unfamiliar product. That produced conversation but no completed tests. This version removes most of that work: one person, two browser windows, harmless sample data, and a focused failure-finding task.</p> <p>ChantLive is MIT-licensed. There is no paid plan, endorsement request, mailing-list requirement, or partnership pitch. I am looking for evidence about what breaks and what should be improved before anyone relies on it.</p> <p>Live app: <a href="https://chantlive.online/" rel="noopener noreferrer">https://chantlive.online/</a></p> <p>Source and issue tracker: <a href="https://github.com/barsham/ChantLive" rel="noopener noreferrer">https://github.com/barsham/ChantLive</a></p> <p>If you try it, please leave one specific observation below or open a GitHub issue. I will report back on what changes as a result.</p> opensource testing webdev a11y