Skip to main content

Data-Focused Design

The most fundamental decision in Ideal is that data belongs to the user, not to applications. The user decides how to organize their information — folders, projects, collections, whatever structure they see fit — and applications adapt to that organization instead of imposing their own.

The Problem with Application-Centric Desktops

In conventional desktop environments, applications own your data. Your email client stores messages in its own database. Your calendar app keeps events in its own format. Your note-taking app uses its own storage engine. This creates several problems:

  • The user adapts to applications, not the other way around. You don't organize your information — you organize it the way each application demands. Your email is wherever the mail client puts it. Your notes are wherever the note app stores them. Your calendar is inside the calendar program.
  • Context is fragmented. Working on a project might involve emails, documents, calendar events, and code. But each lives in a different application, so the user becomes the integration layer — switching between windows, copying references, mentally keeping track of where everything is.
  • Vendor lock-in. Switching from one tool to another requires exporting and importing data — if the export is even complete or accurate. Your data is hostage to the application's continued existence.
  • Opaque storage. Users can't easily inspect, back up, or version-control their data without going through the application's interface.

Data as Files, Organized by the User

In Ideal, user data lives as files in folders. Email messages are files. Calendar events are files. Documents, notes, images, music — all files, organized in a directory structure that the user controls.

This doesn't mean the user has to think in terms of raw files. When you navigate to your mail folder, you see an inbox — not a list of filenames. When you open a calendar folder, you see events on a timeline. The applications handle presentation. But underneath, the data is always files that the user owns, can move, can back up, and can organize however they want.

The critical difference is who decides the structure. In a traditional desktop, the email client decides where your mail goes and how it's organized. In Ideal, you can put your mail folder inside a project folder, next to the related documents and code. You can reorganize freely — the mail application adapts because it works with the data wherever it finds it, not from a fixed location it controls.

Standard Formats as a Means

Ideal converges on established open formats where they exist — Maildir for email, ICS for calendars, VCF for contacts, Markdown for text. This is not an end in itself, but a practical choice:

  • Interchangeability. When data is in a known format, any application that understands that format can work with it. You can swap one mail application for another without migrating data.
  • Longevity. Standard formats outlive individual applications. Your data remains accessible even if the application that created it disappears.
  • Inspectability. Files in standard formats can be opened, searched, and manipulated with generic tools when needed.

Where no established standard exists, the format used is an implementation detail of the applications that handle that data type. The principle is not "everything must be a standard format" — it's "data must not be trapped inside an application."