From charlesreid1

Main: Zettelkasten

Up: Zettelkasten/Patterns

Overview

The way that pages are organized on a wiki is central to the way the entire wiki is structured. While it may seem like a trivial topic that anyone can figure out as they go, a zettelkasten is intended to hold notes accumulated over many years, and as pages accumulate more information they can start to become inconsistent, crowded, and messy.

We use a couple of patterns when creating new pages, to help the pages stay organized over many years and be useful for many purposes. The two patterns are:

  1. Reserving top-level headers for meta-level page organization.
  2. Keeping notes chronological.
  3. Moving information to sub-pages when it starts accumulating or requiring multiple levels of subheaders

The Problem

Suppose you have your MediaWiki zettelkasten, and you start a single note that is on a broad topic. The note might start with a simple structure, have its own internal logic, and be organized consistently. Easy as that!

But now suppose you come back to that same topic three months later, with a different perspective and a different purpose. Maybe you're starting a new project, and re-using some information from the note but also adding new information. Or maybe you learned some new information that changes the way the page should be organized.

With a page in place, with its own structure and organization and logic, it can be difficult to know where to incorporate new information down the road. The ideal note-taking system eliminates that kind of internal friction, and makes it as easy as possible to capture new information, without the cognitive burden of having to reorganize the page again and again.

Example Scenario

Let's start by looking at an example scenario that will have the kind of problem we're trying to solve.

We run our zettelkasten on a Linux desktop server. When we started up the zettelkasten, we created a page with some information about the desktop server - the IP address, some configuration notes, the locations of important files. That's one way that the page about the server is used: as a reference.

But when we start working on a task that involves the server, like creating a new startup service or modifying a configuration file, we keep track of what we're doing by using notes - chronological notes. That way, we know what we did on what day, and we can refer back to that record if we have to fix something or repeat the steps again. That's another way of using the page: as a place to keep a daily record of work done.

The important thing here is, one page serves many uses.

It's also important to note that most of the time, the logical way to organize information in notes is chronologically.

Pattern 1: Reserve Top Level Sections

This strategy is a small and easy-to-implement change in how new pages are created, that keeps the page flexible for multiple different uses.

The strategy is this: when creating a page, the initial version of the page should only use second-level or deeper section headers, so any section like =Specifications= would become ==Specifications==.

Here's an example page about a server:

=Specifications=

* 500 GB HD
* 2x2.4 GHz CPU
* 8 GB memory

=Addresses=

* LAN IP addresses
* VPN IP addresses
* Important network devices

=Networks=

Description of networks the machine is connected to

=Services and Daemons=

(A list of startup services that are running)

(A list of service timers that run services on a schedule)

=Cron=

==Root==

Information about cron jobs for root user

==Nonroot===

Information about cron jobs for non-root user

=Dotfiles=

Special notes about the dotfiles setup on the machine

[[Category:Foobar]]

The way this page is organized currently, it only provides reference information. If we started on a new task and wanted to take notes on what we did and when, it isn't clear where to jump in.

(Granted, this example might have a straightforward solution of just adding two or three more sections to the end, but if you do that a few times it becomes messy.)

Now restructure the page so that everything is 2 levels deep or deeper, and reserve the top-most header for the purpose this information serves: "Overview".

=Overview=

==Specifications==

...

=Addresses=

...

==Networks==

...

==Services and Daemons==

...


Now, the "Overview" section is always at the top of the page, making it easily accessible for reference.

Pattern 2: Taking Notes Chronologically

We reserve top-level headers for dividing the page based on its different uses. If we wnat to start taking notes, we can add a top-level Notes section to the bottom and start taking notes there.

To keep notes organized chronologically, we add a second-level header with the year, month, and date. That way, while we're taking notes, we don't have to worry about how to incorporate the information into the existing "Overview" information, or try and filter the information as we go. We add notes to the notes section, and can copy or move information to other parts of the page later.

Here's another example:

=Overview=

==Specifications==

...

=Addresses=

...

==Networks==

...

==Services and Daemons==

...


=Notes=

==20160101==

===Subject 1===

* Notes on subject 1

===Subject 2===

* Notes on subject 2

==20160102==

===Subject 3===

* Notes on subject 3

===Subject 4===

* Notes on subject 4

You might notice that with the Notes section occupying the top-level header, the date occupying the second-level header, and the subject occupying the third-level header, there isn't much capacity for more sections dividing up notes on a given subject.

That's actually a feature, not a bug, and leads into our next pattern - if you need more section depth for notes on a given subject, it means it's time to move all of the information in that section to its own subpage.

Pattern 3: Subpages

Suppose we're following the pattern covered above, and when we get to the section on Subject 4, it ends up being a much more involved activity than we expected. It involves research, links, tasks, notes, and generally a lot more work than we have room for in the sub-sub-subsection we've allotted.

In that case, we would create a new sub-page with information on subject 4, like [[Foobar/Subject 4]] (assuming the page contents given in the example above are on the page [[Foobar]]).

=Notes=

==20160101==

===Subject 1===

* Notes on subject 1

===Subject 2===

* Notes on subject 2

==20160102==

===Subject 3===

* Notes on subject 3

===Subject 4===

[[Foobar/Subject 4]]

And now, the same patterns we used to organize the [[Foobar]] page can be used to organize the [[Foobar/Subject 4]] page!

Is this approach overengineered?

We know what you're thinking: these patterns all seem overengineered for the simple task of putting information into a page. But as mentioned at the top of the article, the way articles are organized dictates the way the rest of the wiki is organized. A page organization system that eliminates the friction of adding notes to the zettelkasten will ultimately pay off by making the zettelkasten more useful.

This is also the product of several years of using MediaWiki as a zettelkasten, so each problem addressed here is a real problem we've run into many times before.

Conclusion

We covered three patterns for organizing pages when using MediaWiki as a zettelkasten. These three patterns are

  1. Reserve top-level section headers for meta-level page organization (different sections for different end uses)
  2. Organize notes chronologically in a top-level Notes section
  3. Sections that are dense with information or more complicated should be moved to sub-pages

Of course, as always, use these patterns as a starting point, and adjust them to suit your own personal needs; there as many ways to maintain a zettelkasten as there are people using a zettelkasten. But these patterns have been battle-tested and will help keep pages well-organized over many years, while also helping each page to serve all of the many purposes pages will inevitably end up serving.