Object oriented notepad

One Document, Several Ways to Work

A note can contain several kinds of information at once: a paragraph explaining an idea, a task that needs doing, a code example, and a heading that gives the whole thing structure. Treating all of that as an uninterrupted string makes writing straightforward, but leaves other operations dependent on interpreting the text again.

OOO explores a different starting point. The document has a title and a collection of typed blocks. A task carries its completion state, a heading has a level, and a code block keeps its language and content. The editor presents those objects as something to write in, while the other views expose different aspects of the same document.

The supplied demo makes that relationship visible. Change a paragraph and the preview reflects the edit. Switch to Source to work with Markdown, or Inspect to examine the document as JSON. The point is to make those transitions available without asking someone to maintain separate copies of their work.

Structure Without Leaving the Note

The block editor supports adding, selecting, converting, reordering, and deleting blocks. Tasks can be checked in the editor or preview, and an outline provides another way to move through the content. Compose, Architect, Source, Inspect, and Terminal offer different arrangements of these capabilities.

The structured representation is particularly useful when an operation concerns a specific kind of content. Completing a task changes a property of that block. Moving a paragraph changes its position in the collection. Those actions can then be reflected in the rendered view and Markdown representation.

There are trade-offs in moving between representations. The demo's Markdown parser supports the block types shown in the interface, rather than the full Markdown specification. Parsing the source rebuilds the block collection, so this is not a promise to preserve arbitrary Markdown formatting or block identity through every conversion. That boundary matters when assessing the experience as an editor.

A Small Command Interface

The terminal provides another route into document operations. Entering task Review the draft adds a task; outline lists the blocks, and stats reports the current counts. The help command lists the available operations, including changing the title and selecting a workspace.

These are document commands, not a system shell. They operate on the same in-memory data as the editor. Someone can add a task through a command, switch back to the document, and check it off there. The command interface gives the model another use without introducing a separate document format.

Try the Relationship Between Views

The embedded demo starts with a sample document and can be reset at any time. A useful way to explore it is to follow one piece of information through several views:

1. Edit a paragraph in Compose and check its preview.
2. Switch to Source and add a task using - [ ] Review the note.
3. Return to Compose, complete the task, and open Inspect to see its state.
4. Use Undo and Redo to revisit the change, or Reset demo to restore the sample.

On narrow screens, the editor and preview use a panel toggle so each can occupy the available width. Larger layouts show more of the document alongside its representation. The interaction remains centred on the same content rather than requiring a different mobile document.

What This Demo Demonstrates

This is a standalone snapshot supplied for the portfolio. Its HTML, styles, JavaScript, and sample data are contained in one file. It does not require an account, a backend, or external libraries, and document changes remain in memory. Reloading discards them. The technology labels on this page describe that demo, rather than an unverified production stack.

Undo and redo retain snapshots of the document, with a bounded undo history. That is a simple way to make experimentation reversible at this scale. A larger editor would need to consider document size, how typing is grouped into undo actions, and the cost of retaining those snapshots.

Persistence, collaboration, and complete Markdown compatibility are outside this snapshot. What it offers is a working interaction to evaluate: whether a shared document model makes it useful to move between writing, structure, source, and inspection. Visitors can explore that question directly in the embed above.