Introduction

Since it reached MVP maturity, I have been using Scheda exclusively for my note taking, gathering ideas and thoughts, and making sense of them. While gathering information (creating cards) was mostly smooth from the beginning (some limitations in the respective card editors aside), it became quickly evident that processing the information needed much more support.

It now reached a maturity where I consider it—for the time being—feature complete, in the sense that I haven't spotted any major gaps anymore and don't have anything on the list I would want it to be able to do. This will change rather sooner than later, I assume, as I use it, there sure will be features I would like to have that are not yet part of Scheda.

Requirements

In the first article I stated a list of requirements I want Scheda to fulfill. Let's go through them and take a critical look at each.

Always available without getting in my way

Requirement

Scheda cannot take over the screen, pull me out of my actual context when taking notes or looking them up. Taking a note has to be straightforward and hassle-free.

Evaluation

• Minimal screen footprint: the small file window per opened Scheda file, the individual card windows both make it sit comfortably on my desktop alongside whatever applications I am using;
• No need for filing etc. when creating a note, I don't even have to put a title to a card, I can just use Scheda like sticky notes to quickly gather some thoughts;
• Scheda is swift, no clunky, slow, cumbersome interface, smooth, adheres to the platform, and switching from an application to Scheda and back is barely noticeable;

I am running Scheda 24x7, without it ever getting in my way, but having it at my fingertips all the time really integrates it into my thinking. As a matter of fact, it already has significant influence: instead of keeping disparate notes or having to drop out of my thinking to deal with a note taking application that is more demanding, I use it much more than other applications I ever used, to the point of becoming kind of lazy: "Put a note in there and forget about it for the time being". When I feel like it, I can go over the collected material, notes not fleshed out are clearly marked with pending changes, search also allows me sorting by most recently added or changed.

Peace of mind

Requirement

I don't want to feel a constant fear in the back of my head that I might loose the information I stored in a Scheda file.

Evaluation

Scheda instantly stores every change, makes periodic backups, copies them to an external drive, and periodically checks the backups for integrity.

As said above, I run Scheda 24x7, never closing it (unless forced to because I added/changed code or an OS update requires a reboot), never have to safeguard the file or backups manually, never have to explicitly save a Scheda file.

I can also export information stored in Scheda as Markdown, thus even if I should stop using it, I can always take with me whatever I stored in it. In the same lines, I am not tied to a specific platform or OS, should I change my mind about them, I can take Scheda with me.

Even though I started using it as my daily driver before it was fully fleshed out, I never lost a single bit of information.

Future-proof

Requirement

It must always be possible to access my information, no matter how old or what version of Scheda it was written with.

Evaluation

Despite the rather stormy initial phase with many features added in a not necessarily organized and planned out way (using it was my driver, not a fully worked out plan and design specification), it still holds up this promise: no matter what Scheda file I open, old or new, information is always conserved.

Information stored in Scheda can always be exported to common "standard" formats, like Markdown (and from there via Pandoc to most everything), SVG, etc. Neither am I locked into a given platform, as long as Qt and SQLite are available (and some basic OS facilities), I can take Scheda with me.

Extensibility

Requirement

It must be reasonably simple to extend Scheda.

Evaluation

I started using Scheda when it had but (limited) text, file box, sketch and browser cards. Reference, search, and document cards were added only later, without causing any ripples through the code base: modules that could be written without having to touch the Scheda core, much less other card type implementations.

Functionality, like complex search queries, export formats, etc. could be added easily, too. Export formats required touching the different card type implementations, as only they know how their contents are to be represented or printed, but there is no way around this.

With the research/experimental approach some technical debt was incurred, the most significant one was printing and exporting: the different formats were added independently, leading to several independent code paths that duplicated functionality. A cleanup round was needed there, consolidating and refactoring the code. Not only for the sake of maintainability and code simplicity, but more importantly because the different paths did things slightly different, thus resulting in an inconsistent user experience, even if only minimal. Consolidating the code into ane path with hooked in special functionality to handle intrinsics of the different formats solved this and increased maintainability (and extensibility).

There is no public API or scripting provided with the current version of Scheda. I do plan on both, but until I gain more experience using it and seeing what would actually make sense (without, for example, potentially compromising data integrity), it is on ice. The main challenge will be finding a balance between end-user accessibility (simple enough for non-programmers) and programmers, who want to have more powerful interfaces.

Thought process support

Albeit not stated as a requirement originally, Scheda is obviously supposed to provide its main goal: support me in my thought process, be an extension to my brain.

So far, it holds up, the functionality it provides already helps me significantly, and it is a smooth extension of my processes, not a different context I have to switch into.

As of the presentation goals of Scheda's process support: All these articles about Scheda were written as cards in Scheda, assembled into documents then generated by Scheda, exported as Markdown and imported here, a straightforward "publishing" process that takes less than a minute. But most importantly, being able to work with cards, with small pieces of (self-contained) information is a godsend, made it orders of magnitude easier than having to work with an entire document, scrolling around, moving text, trying to keep things properly ordered.

Undoubtedly there will be more things I will discover and want, but so far extending Scheda's functionality has been reasonably straightforward, the main challenge was most of the time the GUI part, editors for cards, etc.—not the Scheda core, formats, or architecture.

Scheda building blocks

Scheda builds on two simple concepts: cards and links:

• Cards hold information, static or dynamic;
• Links connect cards.

Scheda cards

Cards hold the information present in Scheda, independently of their type, all cards have at least:

• a type that determines some of the functionality of a card and in particular its substance, i.e. what can be put into it; each Scheda card type has an associated icon used to indicate a card's type in references to it (file window and links);
• a unique identifier (a UUID), thus can be managed without dependency of their contents or title (the title can be changed any time and will automatically be reflected in any reference to the card);
• a title telling you what the card is about that shows wherever a card is referred to (e.g. the file window);
• file boxes they are filed in (if filed in any); a card can be filed in as many boxes as you see fit;
• attributes: key value pairs (the value is optional) which can help you classify cards; attributes can also be searched for, i.e. show me all cards that have a certain attributes (presence) or a certain attribute with a given value or value range;
• a substance, the "main" part of the card (the text in a text card, the drawing in a sketch card, etc.).

Scheda card types

Scheda (currently) offers these card types:

• Text cards, the most commonly used, holding some rich text;
• Sketch cards that hold a diagram or drawing;
• Reference cards that point to an extern resource (outside Scheda); it holds an URI pointing to the resource and a text are for you to put information about the resource (a description, etc.);
• File boxes (or boxes for short) hold collections of cards and other boxes, allowing you to build hierarchies of cards; they are text cards, too, you can add text to them (between the links to the cards they contain), e.g. titles to separate the cards into sections, or comments on what cards this box contains, etc.; a card can be filed in any number of boxes simultaneously or in none at all;
• Browser cards show the relationship between cards graphically; they contain a query specification (root cards, link types to follow, link direction, and depth) and show dynamically show the cards and their relationships that match the query;
• Search cards hold a query expression like the search field in the file window's All Cards tab; they dynamically list all cards that match the query expression and behave like file boxes in the file window, i.e. they pretend that the matching cards are filed in them (to make the distinction between filed cards and found cards clear, the latter are shown in an italic font); search cards can also be created directly from the All Cards tab in the file browser to allow you saving a query you often use;
• Document cards lay out documents to be assembled from cards; you can write text as in a text card and include links to cards you want to be part of the document; Scheda can then generate you the complete document (following the links in the document card and the linked to cards), ready for export or printing; you can define the rules how each link type is treated (included in-place, and appendix, footnote, etc.); links are preserved and clickable in the export formats that support links (e.g. HTML, PDF) and a table of contents is created for PDF files.

You can freely define your own card attributes and their values (with the exception of a few system defined ones). Scheda keeps track of attributes used and the values for it (so you don't have to). For example, say you have an attribute Status, and you want the values to be draft, finished, or published, you don't have to remember these values, Scheda will suggest them when you set the attribute making it easy to use consistent values. You can manage attributes under the file window's Tools menu menu (see all cards that have a certain attribute, with or without a given value), rename an attribute, or remove it.

Scheda links

Links in Scheda establish relationships between cards, and all links have:

• a direction, i.e. one card points to another, the source and target are distinguished;
• a type indicating the type of relationship between the two cards: See, Comment, Supports, Refutes, and so on.

Scheda automatically establishes backlinks: a link from the target card of a link to the source card; you always see the link on both of its ends, i.e. you see which cards link to a given card. Backlinks are not stored in the file (they are cached, though), the source card of the link is the only source of truth, there is no room for inconsistencies.

A link can either be embedded in the substance of a card (text, drawing, etc.), or it can have the entire card as its origin. Why the distinction? Links within the substance are meant to guide the reader while reading the text: explanation of terms used, references, etc. Links on cards are referring to the topic of the card as a whole, e.g. Comments, Further Reading, etc.

Links always point at cards as a whole, not to a location inside the card substance. As Scheda cannot know where inside a card you want the link to point, you would have to manually create endpoints: this is not only tedious but also error prone—and you don't need it either. Scheda can assemble collections of cards into a document, at which point it will establish links within the complete document automatically, no need for you to define them manually.

Links are shown in Scheda as "blue bubbles", indicating the link type, target card type (with an icon), target card title, and in the case of reference cards, a direct link to the external source (without having to make the detour of opening the reference card):

Wherever in Scheda you see such a blue bubble, you can click on it and it will open (or bring to the front) the target card's window.

Links can be added to the substance of a card by pressing ⌘L (⌃L on Windows or Linux) or selecting the Link icon in the card's toolbar. This opens a pop-up where you can: search for and select the target card or create a new one and specify the link type from the already existing link types or create a new link type. To delete an in-substance link, simply delete it with like you delete any other text. The links can also be cut/copied/pasted like any other text. Note that inserting links is not limited to text cards, sketch cards, for example, can include links as well, browser search cards actually consist of nothing but links, etc.

At the bottom of each cards, at the right side of the Card links field, you can use the Add button to add a card emanating from the card as a whole, giving you the same pop-up and options as with in-substance links, and remove links you don't want any longer.

Scheda keeps track of all link types used in a file (so you don't have to) and in the file window's Tools menu you can see all the defined links, rename them, or remove them.

Thought processing areas

Scheda observes four thought processing areas:

As the diagram tries to show, there is overlap between these areas, and they are not visited in a strict sequence, but rather visited and revisited throughout your thought process.

Collect thoughts and information

Collect thoughts and information. This is the "acquisition" phase, so to speak: gather information, your own thoughts and ideas, contributions from your family, friends, colleagues, reviewers, online information, books, papers, etc. Make an individual card for each item, don't put them all in a single card—or if you do, split them up into individual cards later on, large cards that contain many pieces of information or thoughts severely limit your flexibility to relate and arrange information. But as always with Scheda, the decision is yours and yours alone, if that is your preferred way to work, Scheda will not put up any hurdles or try to force you into a different approach.

If you spot connections, relationships, etc. between these cards, add them right away, spotted and added is always better than spotted and forgotten. Add comment cards linked to them if you want to clarify, have questions, further ideas, etc.

The principal Scheda card types you are likely working with in this area:

• Text cards for rich text notes
• Sketch cards for drawings and sketches
• Reference cards for references to external resources

Don't forget about the reference cards: if a card comes from somewhere else than your own brain, add a reference card pointing to the source. Not only does that help you finding that information again, or related information around that source, but it may also be a requirement, e.g. for an academic paper (which expects you to list all your sources). You can also include direct links into your cards, instead of writing reference cards, but the latter are usually much more helpful: you can link to them (i.e. multiple cards can share a reference instead of each one having the direct link), it gives you a place to describe the source, e.g. an abstract of a paper, a summary of a book (which you can then use with Scheda's full text search).

Create a network and new ideas, gain insights

This is probably the heart and soul of Scheda: it is not ment to merely store information, but to make something out of it: gain insights, leran, create a network of ideas and from it new ideas.

Central to this are links, of course: link your collected ideas together, make extensive use of link types to indicate how things relate, use different views on your information, etc.

Scheda helps you in this process with two card types that allow you inspecting your information;

• Browser cards let you visualize your information network.
• Search cards (or the All Cards tab in the file window) let you find related information you might not have been aware of or to just drill down on aspects you are interested in.

As always with Scheda, you don't have to keep track yourself of whatever you discover: add new cards, comments, notes, etc. as you go, and link them to what is already there.

Browser cards {#browser-cards}

Browser cards let you visualize your network of cards. A browser card holds a query and displays its result graphically. Conceptually, a browser takes a set of cards and link types to follow and shows you all the cards it can reach by these two. The query consists of:

• Root cards, the cards the browser should start from
• Link types, the link types it should follow
• Direction tells it whether to look at incoming or outgoing links, or both
• Depths limits how far it should look (the distance from the cards shown to the root cards, the number of successive links to follow).

This is a screenshot of a browser window as it showed while writing this article:

Below the card metadata, you see the query specification:

• Follow all link types
• Only look at links emanating from cards
• Gather cards up to three hops away from the root cards.

As this view can get very dense for heavily linked card sets (and very generic queries), you can hoover with your mouse over cards and they will be highlighted together with their links and the target cards of these. Clicking on a card makes this highlighting stick, so you can scroll around without loosing it. While a card is marked, hovering over another card will still trigger highlighting it the same way, moving out of the card reverts to the sticky card, or the global view if there is none.

Besides this basic functionality, a browser card also allows you to:

• Move cards around, laying them out differently to your taste; even though the contents of the card are generated and updated by Scheda, if you save the browser card, the positions of cards you changed will persist, i.e. next time you open the card, the moved cards (if they are still part of the picture) will be kept where you put them;
• Add (or remove) start cards: you can look at the network from several start cards together, for example, to see how two parts of your network connect or overlap;
• Add (or remove) links between cards;
• Zoom in and out, and make the entire graph fit the window;
• Clean up the graph (freshly layout the cards), either because you moved them or because you added or removed links.

You can also change the query parameters at any time and Scheda will adjust the cards shown correspondingly. Saving the card stores but the query parameters (and if cards have been moved, their location).

Mentioned in references

In the card links section at the bottom of card windows (underneath the Card links and Linked from fields), Scheda automatically adds a Mentioned in field (if there is any cards to be shown). Scheda lists cards that contain the title of the current card but without a link to it, in other words, it shows you card relationships you might have missed, not been aware of. As with any link, clicking on it opens the respective card. A right button menu on a card in this field lets you add a link to it.

Search cards

In the file window's All Cards tab you can search for cards with complex search terms. You can store such search terms in search cards, so you don't have to retype them over and over again.

A search card holds but such a search query, and automatically populates its substance with a list of matching cards. Furthermore, search cards appear in the file windows akin to file boxes, listing underneath them all the matching cards. To make clear that these are searched for cards and not cards filed in the search cards, the titles of the matches are rendered in italics.

As an example, a search card I use to find "island" cards, cards that are not linked with any other card (in either direction). The query is:

-links: -kind: box -kind: browser -in: Templates -IgnoreIsland:

Spelled out:

• -links: means that the card does not have any links; alternatively, one could, for example, set another minimum with -links: < 3 would list any card that has less than three links;
• -kind: box -kind: browser excludes file boxes and browser cards;
• -in: Templates excludes cards filed under the Templates box (directly or indirectly in a nested box);
• -IgnoreIsland: excludes cards that have the IgnoreIsland attribute set; this allows me to filter cards that I am ok with they are islands, I don't want them to clutter the list.

The list of cards matching the search query is dynamic, i.e. it is always up to date with the current state of affairs. The cards (in the search card and the file window) can be manipulated like any other card, though: you can open them, or you can drag them to file them, allowing you to persist the selection. For example, you can search for all cards that contain a certain string and then file them all in a box; from there you could arrange them in sub-boxes, etc.

Organize cards into (nested) contexts

Scheda handles two aspects of your knowledge network: relationships between cards and contexts.

As an example, assume you are very interested in France and have collected a thousand cards on it: Flora, fauna, society, geography, history, economics, you name it. Some of these cards have relationships, for example, some geographic topics may have direct connections to economic ones, it makes perfect sense to connect such cards directly. But what about you want to focus on France's economy? How do you get a view of all the cards that are related to it? So far, you would have two options:

1. Create some Economy of France card and link related cards to it;
2. Add a card attribute in the lines of Context and set it to Economy of France.

Both work, of course, but both have significant drawbacks:

• The network of linked cards is a flat graph; if you wanted to subdivide Economy of France into several sub-topics, you would have to create additional cards to link to; this eventually leads to a jungle of cards that do not necessarily have any content of their own (Economy of France is likely an empty card, its "contents" come from the linked cards);
• Say, you are also interested in Spain: you would have to rebuild a corresponding set of empty cards for Spain; but more gravely, this gives you two independent hierarchies, one for France and one for Spain; what if you wanted to look at the economy of Europe in general? you would need to either collect all the individual attributes or create even more empty cards to tie them together.

What we are looking for is to define contexts, views on the network, topics. The linking and card attributes make it awkward to map or model this: empty cards as references and no nesting. That is where file boxes come in: they allow you to group cards by whatever criteria you choose, form nested contexts.

Consider the above example of France and Spain: you can create file boxes that give you different views on the relevant cards:

But more importantly, you can have at the same time:

This gives you two different contexts to look at your cards: by topic then country or by country then topic. Note that the respective cards are the same ones, only filed in different boxes (remember, a card can be filed in as many boxes as you like). This allows you to form contexts, areas of focus, different views on your cards.

This is a way you can organize your cards, a structural access path to your network.

Unlike many other tools and applications that force you into working out a hierarchy before adding any information, this is completely optional in Scheda. If you so like, you can leave all your cards un-filed, you are not forced into coming up with a hierarchy before you actually want or need one. Only then, once you see suitable ways to organize your cards, once you want such organization, you do so. You do not have to plan a structure for years to come, and nothing is ever set in stone: should a structure you built turn out to be inadequate or awkward later on, it is straightforward and easy to refactor, rearranging cards (including boxes) is simple in Scheda.

In short: contexts are easiest modelled with hierarchies of file boxes, they give you the flexibility, easy of refactoring, and diversity (several views onto the same set of cards).

Present thoughts and insights in documents

At some point you might want to share information and thoughts you gathered, insights gained, things learned. Of course, you can share your respective cards, but that requires the receiver to use Scheda. More often you will want to write a document on your thoughts.

Scheda helps you there, too. You don't have to go to a document editor outside of Scheda and painfully copy/paste information over. Scheda has document cards for this purpose. At their core, they are text cards, but with a twist: you can write text in them and include links to cards you want to refer to at a given location in your final document. From these "templates", Scheda can generate a complete document by replacing your card links with the actual card contents. The generated document is a Scheda card you can export or print like any other card. If you have specific requirements on the document format (one that Scheda does not handle itself, like a Word document, LaTeX, etc.), you can export the document as Markdown and convert it to most any other format using Pandoc.

Document cards employ a ruleset that can be individually tailored. This ruleset defines how the generation of the document should treat each link type. For each link type in your Scheda file you can replace the link with:

• the target card's contents (with or without title);
• an appendix or footnote containing the target card's contents
• the target card's title only
• nothing, i.e. ignore the link

When generating a document from a document card, Scheda automatically adjusts heading levels of linked cards: a card included in another card gets its top level heading one below the enclosing cards current heading level; you don't have to worry about where a card will be included in a document (or various documents) to determine the heading level, you can always just start with a heading 1.

The generated document, when exported to a format that supports links, is fully linked, i.e. links in the cards are clickable links in the generated document (references to cards/sections, footnotes, appendices, references, etc.). For exported PDF files, a proper table of contents is also created in the PDF file.

This article was entirely written in Scheda and then generated with a single button click from this document card:

As you can see, the document card does not mention each and every card that makes up the document, but the rules are applied recursively to each included card and theirs.

Opening a Scheda file

When a Scheda file is opened it is represented by a small File Window. Cards opened are their own windows, there is no canvas that takes over the entire screen hiding what you are working on. Whatever applications you are using, you can easily position card and file windows next to them and write down thoughts, without even noticing that you are actually switching applications when doing so. You can have as many files and cards open at any time in Scheda as you like. When you quit, Scheda remembers the files you have open and will reopen them (if they still exist) when you start it again; it also keeps a Open Recent... menu listing recently opened files.

The file window gives you three views (tabs) on the cards in your file:

• Fileboxes: A hierarchical view of your file boxes and cards; cards can be rearranged (and duplicated) via drag and drop.
• All Cards: A flat (non-hierarchical) view of all your cards (including boxes); you can enter a search term and it will reduce the list to matching cards as you type.
• Pending: Shows all cards that have pending changes.

The file window is also the place to access functionality that is not related to individual cards, like your font settings, attribute and link type management etc.

Creating and opening cards

To create a new card, either:

• press ⌘N (⌃N on Windows or Linux), or
• press New at the top of the file window (this creates a text card; use the drop-down menu to select a different card type), or
• right-click in the Fileboxes tab of the file window and select New Card Below... (the card is inserted inside the selected box or next to the selected card if it is not a box), or
• press ⌘L (⌃L on Windows or Linux) in a card; this will insert a link to another card, and instead of picking an existing one you can create a new card.

A new card window will pop up with an empty new text card (or of the card type you selected). The cursor is positioned in the card title field (which defaults to Untitled), ready for you to type. Pressing Tab takes you to the card substance (for a text card the main text area where you write down your thought).

To open a card, double-click on a card in the file window (any of the tabs/views) or on a link to a card.

Pending changes

Whenever you type (or draw, etc.), Scheda immediately stores your changes to the file as pending changes, thus even if you should loose power or the like, you loose at most a few seconds of work—no need to worry about hitting save every few seconds, as a matter of fact, you're strongly encouraged no to do so: Scheda keeps a history of all your saved versions of a card, you can go back in time and see what a previous card version looked like or what changed between two versions of a card.

Once you are satisfied with the current card contents—at least for the time being—you save it as a new version of the card. Scheda doesn't care whether you save a new version of the card after every little change, but it will make it hard for you to make sense of the card history if each version only differs by a word or two from the previous one.

When you close a card window with pending changes, Scheda will ask you whether you want to keep the pending changes, save them as a new version, or discard them (forget about them and go back to the last saved version). Scheda will ask you the same question when you close a file, but this time for all cards in the file with pending changes. If you close Scheda, it will ask you in turn for each open file that has cards with pending changes.

If you discard pending changes, they are gone for good, but remember, Scheda keeps periodic backups: you can resort to the latest backup in case you accidentally discarded pending changes; with the default backup configuration, you would loose at most fifteen minutes of work.

Versioning aside, keeping pending changes has another benefit: all cards with pending changes are marked with a well visible black bullet (in the file window and the card window's title) and they are also listed in the file window's Pending tab. You can use this as an automatic to-do list, a list of cards you are still working on or intend to work on.

Remember: pending changes are not just held in memory and gone if you close Scheda, loose power, etc. They are stored in your file (and backups), no need to worry about keeping a card with pending changes for any timespan that suits you. As a matter of fact, while I am writing this article, most of the cards that compose it are still with pending changes, until I see that I filled all the gaps and they all fit together.

One special case: If you never saved a card, it has no version to revert to when you discard the pending changes; the card will be deleted without a trace.

Anatomy of a card

All cards in Scheda have the same basic characteristics and layout. The different card types only vary in their main substance (text, drawing, graph, etc.).

Scheda offers two categories of cards: those users put their thoughts in (text cards, sketch cards, etc.) and cards that get their contents from Scheda, for example browser cards and search cards. This categorization only applies to the card substances (text, drawing, graph, list, etc.); the cards as a whole are all the same, have a title, attributes, etc.

Comfort and hints

Before we dive deeper, a few global features Scheda offers that are not particular to any of the process activities.

Tooltips

Scheda has tooltips for most things it displays. When you move your mouse over any button or field on any of Scheda's windows and wait a moment, a tooltip will pop up at the mouse location explaining what you are pointing at.

Right-button menus

In many places Scheda offers menus on a right mouse button click. Those are context-sensitive, that is, they represent operations or options particular to where you pressed the mouse button.

Safety first—continuous saving and backups

As long as you don't loose the Scheda file itself, it is close to impossible to loose any information, Scheda continuously saves any changes you make. You can work comfortably and relaxed, no need to constantly hit Save to ensure you are not loosing too much information in case of a power loss or the like. As soon as you briefly pause typing or complete an action, the changes are stored in your file.

Scheda provides scheduled backups to a local folder and copies to an external or cloud drives. Both are configurable to your taste. You can also opt in for Scheda to periodically verify that all backups made and kept are still good, i.e. did not suffer any damage (transmission, storage, etc.). The integrity of a Scheda file is verified before writing to it. If a file corruption is detected, Scheda offers rescue options depending on the severity of the corruptions and the backups available.

Instant display updates

Whenever anything is changed that affects a displayed card (or the file window), the change is noticed and the view updated accordingly. As a matter of fact, if you keep an eye on the file window (and your first card's window title), you will notice that both update while you type the title. If you missed it, just go, open your card and edit the title; observe the file window and the card's window title change as you type. You can rely on displayed information always being up-to-date (with a tiny delay).

Spell checking

Scheda checks the spelling of everything you type. On Windows and MacOS, the respective OS's spell checking system is used and the languages configured for it. On Linux, Hunspell is used and the dictionaries and configuration for it.

If you want to disable/enable spell checking, you can do so in the file window's Tool menu.

Full text search

Scheda provides full text search over all cards (including sketches, etc.). You can also search for card attributes (just presence or specific values). This gives you another way to access your cards besides the links and boxes. The full text database, like everything else in Scheda, is always kept up to date while you work.

You can save your searches as Search cards that will look similar to file boxes but their content is dynamic depending on your query. The cards themselves show the list of matching cards (as always with Scheda, updated as soon as something changes that affect them), and they appear in the file window as expandable "folders" like file boxes, listing the matches underneath them.

Version history

Scheda keeps a history of every saved version of all cards. You can browse through previous versions and either look at what they said back in time or look at the changes between two versions (including sketch cards).

Scheda never physically deletes a card, it only marks it as deleted. You can always bring back a deleted card ("un-delete" it).

Duplicating cards and templates

At any time you can create a duplicate of a card. The original and the duplicate are linked together, but otherwise completely independent. If you put cards in a box named Templates in the Table of Contents, those cards will show at the top of the list when copying a card is requested.

Templates are regular cards of any kind, their contents (card substance) is duplicated as are its attributes. This allows for making "standardized" cards of many kinds.

Templates can make good use of attributes: Any attribute on a template is copied to the duplicate (if it has a value, including it, if not, just the blank attribute). If at a later point you want to add attributes (or default values), you can do so and ask Scheda to automatically update all duplicates made from it (attributes set on the duplicate are not overwritten, unless they are blank and the template now provides a default value). Contents of a duplicate cards are never changed by this, only attributes.

Fonts

You will be spending a lot of time looking at text while working with Scheda. It is important that you feel comfortable doing so. To this end, the fonts being used in Scheda can be set in the file window's Tool menu, allowing you to pick fonts you are comfortable with.

There are two pairs of settings: for display and for printing (including PDF export). They both allow you to specify their respective text and code (monospace) fonts. Fonts that look good on paper do not necessarily look good on a screen and vice versa.

For all fonts you can individually specify the font size, allowing you independent configuration for printing and on-screen viewing, and you can tune regular vs monospace font as they often do not align despite claiming the same size.

Scheda desktop screenshot

To give you an impression what it feels like when all this comes together, here a (partial) snapshot of my Scheda desktop while I was writing this article:

Outlook

This gives a first idea of how one interacts with Scheda and what it looks like. Next up a deeper dive into how Scheda sees thought processing and what tools and functionality it offers to support you.

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.