reflow/Source on GitHub ↗

TIME IS A CONSTRAINT. YOUR PLAN ISN’T.

Schedules should move.
People should stay in sync.

INTERACTIVE CONCEPT / V0.2

Make room for a new priority.
See what changes. Bring everyone along.

Why an adjustable schedule? ↗
Scheduling studio/ single-day sandbox
Stored on this device

01 / THE DAY

Room to rearrange.

09:00—18:00 · fictional day7 events
FixedMovable meetingFlexible taskNew priority
Current plan EDITABLE
Proposed plan NOT CALCULATED
A new possibility
starts with a little movement.
Click an event to edit its rules. Existing durations are always preserved.

03 / KEEP PEOPLE IN THE LOOP

Changes are a conversation.

SIMULATED INBOX · NO EMAIL SENT

A proposal creates a local notification for every affected participant. Try accepting it, or asking for another window.

Find a plan, then preview the notifications. You play each participant in this demo.
ACTIVITY
No changes yet. Your original schedule is safe.

THE ORIGINAL IDEA

Your schedule should be adjustable.

A calendar usually treats every busy block as a wall. The idea behind Reflow is to treat a schedule as a living arrangement: some commitments stay fixed, others can move within agreed boundaries.

When something important arrives, rearrange the flexible parts, explain the trade-offs, and automatically notify the people affected. If someone needs a different time, let them ask—and reflow the plan again.

Rearrange the schedule.
Respect the people in it.

THE COORDINATION LOOP

Flexible, with ground rules.

  1. 01

    Propose

    Find a feasible change within time windows and priority rules. Keep the current calendar intact.

  2. 02

    Notify

    Show each affected participant what changes and why. This prototype simulates delivery locally.

  3. 03

    Adjust

    Accept, suggest another window, or keep an existing meeting in place. A new revision needs new approvals.

  4. 04

    Commit

    Apply only the agreed revision. Real calendar syncing and email delivery are future integrations.

What works today—and what is simulated?

The scheduling engine, constraint editing, before/after comparison, local saves, JSON import/export, participant responses, revision checks, and notification previews work in this browser. All people and example events are fictional. There is no shared backend, email delivery, push notification, account login, or Google/Outlook calendar connection. Participant actions are role-play controls, not authenticated responses.

How does Reflow choose a plan?

It searches a single 09:00–18:00 day on a 15-minute grid. Fixed events never move. Equal and higher priorities are protected by default. Every existing event keeps its duration. Moving a meeting costs more than moving a flexible task. The lowest-cost plan is selected when the search completes; a search limit is clearly reported when it does not.

Movement score = priority × type weight × (4 + minutes moved / 15). Type weight is 3 for movable meetings and 1 for flexible tasks. No movement costs 0. This is an illustrative comparison score, not money or a validated human disruption metric. The engine allows up to 12 total events and 250,000 search nodes.

Where is my data stored?

Your saved day and draft request stay in this browser’s local storage. Notification previews and approvals last only for this page session. Nothing you enter is sent to a server by the app. Export your plan before clearing browser storage or switching devices. Hosting infrastructure may process normal request logs.

Design references and source

Visual research included Schedule-X, coss UI, and trud-calendar. Reflow uses an original interface and scheduling engine; no source code or assets were copied from those projects.

Edit the ground rules

The allowed window must contain the current event. Saving invalidates any pending proposal.

Request another window

This changes the proposed meeting window. Earlier participants’ counter-requests remain binding. Everyone must approve the revised plan again.