Notes, Colla, and Planny: Building Apps for Writing and Studying

Notes, Colla, and Planny address three parts of the same activity: write something down, read it with someone else, and decide when to work on it. Each application has its own interface and state model, even though their deployed APIs share supporting infrastructure.

The separate apps keep the entry points clear. A shared note opens an editor. A PDF invitation opens a reading room. A planner account opens a schedule. Each experience can focus on the decisions its user actually needs to make.

To explore the differences, try one small study task in each app: draft a revision checklist in Notes, discuss a few PDF pages through Colla, and place the follow-up work into Planny. This is a workflow across independent apps; the projects do not currently transfer your material automatically between them.

Notes Begins With a Document

Notes is an account-free collaborative rich-text editor built with React, TipTap, and Yjs. Documents have shareable links, and the editor supports formatting, lists, and tables. A browser-held list of recent links makes it easier to return to earlier work.

TipTap provides the editing surface. Yjs represents collaborative document state, while the deployed collaboration service uses Hocuspocus over WebSockets. The Go API and Firestore handle session records, document metadata, and versioned Yjs state.

These responsibilities are related but distinct. Rendering a toolbar is a frontend problem. Coordinating changes from multiple editors is a collaboration problem. Recovering the document later is a persistence problem.

The interface puts the document first: an editing area, a name, a share action, and awareness of other participants. Account-free access reduces the steps needed to begin, while the document link becomes an important access boundary.

Coordinating Edits Without Replacing the Whole Document

Yjs uses conflict-free replicated data types to merge collaborative changes. The application works with shared document state instead of treating every keystroke as an authoritative replacement of the entire text. That is the relevant distinction when two people edit different parts of a note at nearly the same time. The Yjs documentation explains the synchronization model.

TipTap supplies structured rich-text editing, and Hocuspocus provides the collaboration transport. The editor's formatting commands, synchronization updates, and persistence all meet at the same document, but they are different responsibilities. Readers can follow that boundary through the TipTap collaboration overview.

Presence is another kind of state. A participant's current cursor or connection status is useful while they are online, while the written content needs to remain after they leave. Yjs awareness documentation describes how awareness is kept separate from durable shared document content.

For a hands-on check, open a shared note in two browser windows and type in different paragraphs. Observe whether both views converge and whether it is clear who else is present. Then return through the saved document link. These actions test collaboration, awareness, and recovery as separate user experiences.

Colla Makes Reading Shared

Colla creates a PDF study room for two people. One person uploads a document and sends an invitation link to a partner. The room supports live presence, partner cursors, independent page controls, and jumping to the partner's current page.

Independent navigation is a useful distinction. Two readers may be studying the same material while checking different sections. Colla can show where the other person is without requiring every page turn to move both viewers.

The React frontend communicates with a Go API. Cloudinary stores PDFs, and Firestore stores session state. The interface also includes theme, background, split-view, and zoom controls, because the reading environment matters during a longer session.

A room needs to make connection changes visible. A partner joining, disconnecting, or returning should have an understandable effect on presence. The PDF remains the shared reference, while cursors and page indicators provide lightweight context around it.

Page State and Cursor Movement Take Different Paths

Colla polls session metadata every second for page positions and presence changes. Cursor motion uses a separate temporary stream from the Go service, and cursor positions are not written to Firestore. This avoids turning every pointer movement into a persistent database update.

The distinction also explains the feel of the room. A page or presence change follows the polling interval, while pointing at a diagram follows the cursor stream. These mechanisms should not be described as one universal real-time channel.

There is a deployment consequence: both readers need to reach the same API instance for live cursors when the backend has multiple replicas. Durable session records are shared through Firestore, but the temporary cursor stream has an instance boundary. Scaling the HTTP service alone does not automatically scale that ephemeral state.

Host and guest use different update tokens. The browser retains the active token for the session and stores a rejoin copy locally. That supports returning after an interruption, while the invitation link remains something to share intentionally with the reading partner.

Try a PDF with a diagram: navigate independently, point at a detail, and use Jump to Partner to compare the same page. The interaction makes the purpose of presence visible. A cursor becomes useful when it helps two people refer to the same material.

Planny Gives Work a Place in the Week

Planny is a student planner built with React and Vite. Users create color-coded notes, move them between days, reorder them, and edit their details. A month view provides another way to inspect upcoming work.

Accounts hold notes and preferences. The supporting API uses Firebase Auth and Firestore, with Cloudinary handling profile-image uploads. The private planner and public schedule are separate views of that data.

That separation is central to the app. Public sharing is off by default. The public page exposes selected schedule information rather than every detail stored in a student's private notes. Paid weekly access, where used, remains subject to the student's sharing preferences.

Dragging a note across a week looks simple, but it represents an actual data change. The interface needs to preserve the note's identity, date, order, and editable content as the user moves between weekly and monthly views.

Sharing Is a Selected View of Private Data

Planny separates private note storage from its public schedule output. Today's public view exposes selected titles, types, and dates; it does not publish all additional note details or student IDs. A student's sharing preference still controls access when paid weekly access is used.

This is a data-boundary problem as well as a screen-layout problem. The public page needs an intentionally limited representation. Merely hiding fields with CSS would leave those fields available in the browser's response data.

The weekly planner, month view, and public schedule also serve different return habits. A weekly view helps decide what to do next; a month view helps inspect upcoming work; a public schedule communicates what the student has chosen to share. Their value depends on consistent dates and note identity across those views.

For a practical check, create one study note, move it to another day, and inspect its new position in month view. If you choose to enable public sharing, compare the public page with your private note and confirm that the published information matches your intent. Return sharing to the preference you want afterward.

Three Different Meanings of Sharing

In Notes, sharing means allowing collaborators to work on the same document. In Colla, it means joining a temporary reading session. In Planny, it means publishing a chosen view of a private schedule.

Those differences shape the applications. They need different permissions, persistence rules, and ways to show other people. A universal share button would hide important distinctions that the individual interfaces can explain directly.

The portfolio therefore lists these as three projects. Shared backend infrastructure supports them, but it does not turn their user experiences into one application.

What Engagement Would Mean for Each App

The useful engagement event differs by product. For Notes, it might be two participants completing an edit and successfully returning to the document. For Colla, it might be both readers joining and using page awareness during a study session. For Planny, it might be a student moving from entering a task to finding it again when the work is due.

These are evaluation goals, not measured growth results. I would test the invite and rejoin paths, ask users to identify what is public, and observe whether they can recover from a disconnect or misplaced note. A longer session is only valuable when it supports the user's writing, reading, or planning.

Readers who want to compare the collaboration architecture with local media processing can continue to the Pyvi toolkit article. The shared design question is where state belongs and how the interface makes that ownership understandable.

Try the Applications

Open Notes to write, Colla to start a shared PDF session, or Planny to explore the academic planner. Their archive pages provide Notes, Colla, and Planny screenshots and implementation summaries.

Together, the apps cover a practical sequence: capture ideas, study material with another person, and arrange the work ahead. Their common ground is making that next action easy to find.