In his work on NLS, Douglas Engelbart envisioned computers to augment human intellect, to amplify human cognitive abilities—such as perceiving, reasoning, analyzing, and communicating—through interactive computing.

He wanted the computer to be an extension of your brain and thought process, not a mere isolated tool.

There are a lot of applications for note taking, organizing information, etc. But they aim at constructing a second brain, a detached entity: They require a context switch, you have to leave your thinking context to enter the application's. This is, of course, very disrupting to your thought process, and Scheda aims at remedying exactly that barrier.

Scheda does not reinvent the wheel (at least not completely): it draws heavily on the ideas and concepts of NoteCards, the hypertext system Randall Trigg, Thomas Moran and Frank Halasz built at Xerox PARC in the 1980s, leveraging modern technologies that were unavailable back then. Cards, typed links, browsers and fileboxes are its ideas. Scheda also takes into consideration the experiences and observations made by users of NoteCards.

For an overview of NoteCards, see https://doi.org/10.1145/29933.30859. https://doi.org/10.1145/317426.317451 is the paper in which Halasz looked back on it.

This leads to fundamental requirement that were part of Scheda from the very beginning.

Fundamental requirements

Always available, never stand in my way, no context switching

No matter what I do, what applications I use, Scheda has to always be at my fingertips, without pulling me out of my thought process and context. Taking a note, finding a note, augmenting one has to be seamless and imperceivable . Yes, I am switching applications, of course, but I should not notice. Scheda is not to be an application taking over, it has to act like an extension to whatever other applications I am using.

This implied that it cannot be a web application with a large canvas (actual browser or embedded) taking over your screen real estate. Instead, Scheda is a desktop application, every note (card) is displayed in its own window I can size and position freely alongside my other applications' windows.

Peace of mind

Scheda must be reliable and never loose information, without me having to worry. To this end, everything I do in Scheda is instantly stored as pending changes in my files. Additionally, Scheda can automatically make periodic backups (with user configurable frequency and retention policy). Backups are created locally on my computer but can optionally be copied to an external or cloud drive automatically. To round the backup strategy up, backups are periodically tested for integrity: a corrupted backup (hardware issue, network, etc.) is detected, avoiding giving me a false sens of security—having a backup only helps it it can actually be restored.

I do not have to worry about changes I make or even deleting notes (cards): Scheda keeps a complete history of every change I saved, allows me to go through the history and see what things looked like at some point in time, or see what changed between two versions of a card. Scheda never deletes a card either, it only marks it as deleted, I can bring it back (un-delete it) at any point in time.

With these mechanisms, I can truly focus on my thoughts, worry-free, arrange and change them as I like, I can always go back in time if I took a turn I wish I hadn't.

Future-proof

It must always be possible to access my information, no matter how old or what version of Scheda it was written with. Any future version of Scheda must handle every past one's storage model and formats. It must also be possible to extract the information from Scheda should I ever decide to no longer use it.

Scheda must run on all common platforms, it cannot lock me into a single one, losing everything should I switch.

To ensure that things not just work but stay usable across platforms, Scheda strictly uses semantic tagging for card substances: there are no fonts or their sizes per card (there is a global setting to allow you selecting fonts you are comfortable with, for display and printing), as their look will depend heavily on the underlying graphics substrate (display vs printer, resolution, scaling, etc.). Semantic tagging (header 1,2,3..., bullet list, etc.) also allow Scheda to understand the structure of your cards (it cannot know that 14 point bold Helvetica means a level 1 title). For example, when generating documents from cards, Scheda automatically adjusts the heading level of nested cards to be below the enclosing card's, thus allowing you to write cards without having to worry about how they will be assembled.

To ascertain that everything is always readable in the future, dependencies on third-party formats and frameworks must be minimal, as they are outside of Scheda's control, and it thus cannot guarantee anything around them. Scheda uses its own serialization formats, and it has but two external dependencies: SQLite for storage and Qt for the GUI. Both are time-proven and unlikely to go away anytime soon (and if they do, Scheda will likely be the least of my concerns).

Extensibility

It must be easy (or at least as easy as possible) to extend Scheda (new functionality, new card types, etc.). This implies a sound architecture, modularization, and encapsulation. Adding or changing functionality cannot send waves of destruction through the entire code base.

Scheda consists of a small core that handles cards and their storage, versioning, etc. The cards themselves are implemented as clients of and services to the core. As a matter of fact, Scheda's core does not know about the different card types, each card type provided has to explicitly register with the core to become available.

Contracts are established between the core and the cards (or any service) on what each other's responsibilities are and what interfaces they have to provide (e.g. serialization, export to other formats, printing).

Outlook

Enough theory. Next up is a what Scheda looks like, what working with it feels like.