Skip to main content

Lessons Learned

Every project described in Prior Art attempted some version of what Ideal aims to do. None fully succeeded, but each left behind insights that inform Ideal's design. This section distills what we've learned from studying their approaches, their failures, and the few things they got right.

The Idea Was Never Wrong — the Timing Was​

OpenDoc and NeXTSTEP failed in the 1990s, but not because document-centric computing was a bad idea. The hardware couldn't support the overhead of component editors running simultaneously. Developer tooling was primitive. There was no ecosystem of open formats to build on — every vendor had their own proprietary format, and interoperability was an afterthought.

Today, the landscape is fundamentally different. Hardware is abundant. Established open formats exist for most common data types. Version control, indexing, and sandboxing are mature technologies. The barriers that stopped the 1990s attempts are largely gone.

Lesson: Don't dismiss an idea because previous attempts failed. Examine why they failed and whether those conditions still hold.

Don't Require a Clean Break​

Plan 9 is arguably the most technically elegant operating system ever designed. It's also almost unused. The reason is simple: it required users and developers to abandon everything they knew and start over. No matter how good the destination, if the migration path is "rewrite everything," adoption won't happen.

Ideal must be usable from day one, even before a rich ecosystem of integrated applications exists. The desktop should work as a competent file explorer on its own. Each integrated application adds value incrementally. Users should never face a moment where the system is less capable than what they had before.

Lesson: Design for incremental adoption. The system must be useful at every stage, not only when fully realized.

Abstraction Must Match the User's Mental Model​

Nepomuk's RDF-based semantic model was powerful in theory — any piece of data could be related to any other through typed relationships. In practice, users couldn't see or understand the semantic graph. The abstraction was too far removed from how people actually think about their information.

People think in terms of folders, documents, and spatial organization — not triples and ontologies. Ideal uses typed folders as its organizing abstraction precisely because folders are already universally understood. The type system adds capability without adding conceptual overhead: a folder that looks like an inbox is still a folder.

Lesson: The abstraction layer must be immediately comprehensible. If users can't build a mental model of how the system works, they won't trust it or use it effectively.

File-Level Metadata Is Not Enough​

Haiku demonstrated that enriching files with queryable attributes is powerful — you can find all emails from a specific sender, or all music by a specific artist, directly from the filesystem. But Haiku's model operates at the individual file level. There's no way to say "this entire directory is a mail account" and have the desktop respond accordingly.

Ideal's typed folders operate at the directory level, which is where the user's organizational intent lives. A folder marked as a mail account tells the desktop everything it needs to know: which application renders it and what actions are available. Individual file metadata is still useful, but the folder is the meaningful unit.

Lesson: The organizing unit must be the folder, not the file. That's where user intent and application behavior meet.

Ecosystem Matters More Than Technology​

Every one of these projects had sound technical foundations. What they lacked — or couldn't build fast enough — was an ecosystem of applications, formats, and developer tools to make the vision practical.

Ideal addresses this in several ways:

  • Leveraging existing formats instead of inventing new ones reduces the amount of work needed to support a data type.
  • Supporting existing command-line tools as action providers means the ecosystem isn't starting from zero.
  • The desktop is useful as a file explorer even before specialized applications are available, so there's no minimum threshold of ecosystem size for the system to be worth using.

Lesson: Technology is necessary but not sufficient. The ecosystem strategy is as important as the architecture.

Security Must Be Invisible​

A system where applications share access to user data needs a security model that doesn't depend on user vigilance. Android and iOS have shown that when you ask users to make granular security decisions, they accept everything without reading. The security model becomes theater.

Ideal's security must work through intelligent defaults and infrequent, clear decisions — not through permission dialogs that users learn to dismiss. A music application shouldn't need to ask for access to music files; that should follow naturally from its declared scope. Explicit consent should be reserved for genuinely unusual requests.

Lesson: Security that depends on user decisions will be bypassed by users. Design the model so that the safe path is the default path.