-
-
After: Option A confirmed; B and C released; unrelated Product sync preserved. Undo protects newer edits. Synthetic data.
-
Before: three candidate times form one decision. Preview shows which time stays and which holds leave. Synthetic data.
Existing app upgraded
Google Calendar. Independent recreation of the relevant calendar screen; no affiliation, endorsement, account access or live Google integration.
Problem statement
When people negotiate a meeting, several tentative calendar events can represent alternatives to one decision. Treating them independently leaves the person to clear abandoned holds and notice when availability changes before confirming.
Before and after
Before: separate tentative holds require manual cleanup and a fresh availability check. After: an option group shows which time stays, which alternatives leave, and why confirmation must stop when the calendar changes or a conflict exists.
What it does
Create a meeting option group with two or three candidate times. Preview and confirm one; its siblings leave the active calendar without removing unrelated meetings. Undo restores the alternatives only while the revision is still safe. A built-in late-arrival demonstration shows why a stale preview and an actual conflicting time both cause refusal, while another free alternative can still succeed.
How we built it
HTML, CSS and JavaScript ES modules; a pure immutable scheduling engine separated from the interface. Node's built-in test runner checks seven state-transition scenarios. Python's standard-library server serves the unchanged static files locally. No dependency install, paid API, Google OAuth or private user data is needed.
Challenges
A preview can be correct when displayed but stale by the time it is confirmed. The prototype therefore checks both its revision and current overlaps at commit time, and protects newer edits from undo. It checks other groups' alternatives as well as confirmed and busy events.
Accomplishments
Seven behavioral tests passed. Actual browser checks covered confirmation, sibling release, undo, late-arrival refusal, conflict refusal, alternate-time success, new two-option groups and a 390px responsive viewport. These are prototype validation results, not a user study or production scalability claim.
What is next
Explore a permission-scoped Calendar adapter with server-side transactional confirmation and durable state, after validating the interaction with users. The current single-tab revision counter is not a distributed locking system.
Tools and AI disclosure
HTML, CSS, JavaScript, Node test runner, Python local HTTP server, Pillow and FFmpeg for the captioned walkthrough. Codex assisted with concept, implementation, tests and copy. OpenAI's built-in image generation produced the design reference only. The application is fully code-native; it does not use a generated screenshot as its interface.
Run the prototype
Clone the linked public repository and follow README.md. The complete prototype uses synthetic data in a local browser tab; no Google account, Calendar permissions, paid API, or external package installation is required. The current revision counter protects in-memory operations within that tab; it is not a distributed calendar transaction.
Demo format
The prepared 90-second walkthrough uses screenshots captured from actual browser interactions, with English captions and no audio. It is an edited walkthrough, not a continuous real-time screen recording.
Log in or sign up for Devpost to join the conversation.