1. 31
    1. 8

      Seeing these Zettelkasten-management systems pop up recently has been very interesting to me. Being German, the Zettelkasten was known to me earlier than for most Americans, so I’ve been stewing on the idea for quite some time (and wrote my own software to support it, as one does)

      Most of the now-available Zettelkaesten have the following things I see as flaws these days:

      • Titles for cards. These, to me, are an error and lead to ideas being discarded that have value in context. Often it’s much easier to have an idea in context and to write it down. Forcing titling of ideas leads to ideas being discarded that would otherwise (in context) be valuable.
      • The use of meaningless numbers/dates/hashes for file names. If you look into how Luhmann used his Kasten, he made heavy use of ad-hoc sequences and branched ideas based on ancestors, hence his tree-like notation for card IDs. This is a completely ignored aspects in many of the modern implementations. My own Kasten started out this way, too, until I found that it encouraged bigger individual notes - every note tends to be an island, and groups don’t actually form.
      • The treatment of the Kasten as a graph, rather than a tree. The Kasten is not meant to be an arbitrary graph - it’s a tree, where later nodes relate to their ancestors and build on them. Cross references are possible and encouraged, but need to be explicit.

      This leads to many people treating a Kasten like a local-hosted wiki with fancier/more integrated interface - everything that was already possible with a directory full of markdown files and some editor support. In writing my own emacs-based solution for this, I’ve fallen into all of the above pitfalls, repeatedly re-writing my kasten into something that I will actually use and converse with.

      For further reading, the Kasten is partially transcribed/digitized by the university of Bielefeld. The project can be found here (in German), and it might give some insight into how the person that invented it used it. The common literature that introduced the idea was How To Take Smart Notes, which was targeted at academic writing. Since then it seems the idea has taken off since Roam became a thing. I’m curious as to whether or not my personal conclusions will be replicated in other people’s experiences, or if I’m just a weirdo here.

      1. 4

        Interesting feedback.

        I’ve opened #181 for the optional title thing.

        I also think that tree representation is often more useful than a plain graph representation. For now, I’ve kept both - and made tree links the default (allowing user to override it), which becomes available here: https://neuron.zettel.page/z-index.html

        I don’t understand your comment on IDs though. What’s wrong with random hashes for file names? As I understand, Lumann used the number system to make it easier to navigate on a paper based system. In digital systems we don’t have this problem; the filename can be whatever; as long as the notes are linked correctly, they can be navigated using “backlinks” and such. And a tree can automatically be built from the links, like Neuron does.

        1. 2

          The ID issue is most likely to be something personal to me. I found, using my kasten more and more to store thoughts that fell out of short term memory, I relied on the rough taxonomy that was implied by using Luhmann’s tree notation. A prefix and group of numbers implied a mental context that carried over for me. They also imply an activity proxy in just the ID, something that I also use to look into active branches.

          It’s likely that this is something that doesn’t generalise, so YMMV here. Moving my implementation from a serial increasing identifier to the Luhmann notation increased my associated mental context and so the usefulness of each note. It’s entirely possible that this will backfire on me, as the context in a group of notes will shift and be independent of its ancestors. Hasn’t happened yet, but given my Kasten is only a few years old, too early to tell.

          1. 2

            I’ve been experimenting with a physical zettelkasten-style system for a while; I didn’t know the term when I started but since it became trendy I’ve been able to do a lot of reading on the subject which I’ve enjoyed. A problem I’ve found with my original date-based IDs, and that would perhaps be even more of an issue with random hashes, is writing references to other notes. It’s much easier to get a sense of where I would find a note if they are ordered by relation to the related notes rather than their date. That’s what I’ve found, anyway.

    2. 7

      Could someone possibly try and explain to me in short words how the Zettelkasten system works? I tried reading about it, but my initial search results seem to be drowning in a sea of “life improvement”-grade advice and philosophising (in the area of notetaking). Is there some gist that can be explained in a few dry sentences, assuming I already decided I want to try and start using it, so don’t need convincing & marketing? And without the showing-off how everybody is apparently even more Zettelkasten-y and hyperlinked than the others around? One that would give me like 80% benefits for 20% “depth”? I need something simple for a beginner before I can even understand further subtleties and reach any kind of “deeper levels of enlightenment” in this… hobby?

      Also, do you personally use Z(…..)n for all and any notes you ever do anywhere, or only for some specific use cases? I’m not a guru of this rel… err, hobby, so you can speak freely to me …obviously unless you’re afraid of others finding your confessions on the public web ;)

      1. 4

        Favor composition over inheritance.

        Zettelkasten is that idea applied to note-taking, build your hierarchy bottom up rather than top down. File system hierarchies and sections in tree-layouts like markdown or org-mode are top down, so you need to know the context before you write the note. Zettelkasten is supposed to free you to write notes and have the context become clear with time.

        Now, how you accomplish this is far from clear since you need to have a way to index and discover notes that compose nicely.

        People have different numbering systems as well as linking structures to keep some order to their notes. Really this amounts to building topologies over your notes in different ways and attempting to do so with ergonomics intact.

        1. 3

          Hmmm; I don’t think I fully understand what you wrote; but as of now it starts to sound to me, that on “technical side,” what everybody seems to agree, is that it for sure has:

          • writing notes, on paper or computer
          • marking/tagging them with topics (kinda “tags”/“categories”/“hashtags”)

          (so, technically, basically any wiki system with backlinks/hashtags/categories would probably work as a basis?)

          Now, how those “tags” are to be formed/structured, here people seem to not really be sure, a.k.a. have tons of various ideas. Also people seem to have varying opinions how/whether the contents of the notes should be structured in some ways.

          Finally, it is expected that after some time, the tagging will (fingers crossed) lead to some kind of Better Organisation and Emergent Taxonomies in the notes.

          Did I get it? Or miss spectacularly?

          edit: ok, I think this is a good overview for me: https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1

          1. 1

            Is the system, “take notes on index cards, keep them mostly sorted by idea”?

            1. 1

              I think with: “…with branching, and giving each card a nested/branched ‘address’”

          2. 1

            Yep I think you get it. The original zettelkasten had a sequential numbering system with both links and tags.

            In a computer people seem to agree that the structure that emerges from sequential numbering has no semantic value and so hashes are better indicators. Then for tags vs links some people again feel tags are sufficient.

            I’m trying to build my own system and in it I pretty much only use tags.

      2. 3

        Check out this Twitter thread for someone’s personal take on it https://twitter.com/eugeneyan/status/1259540160468770817

        1. 1

          Unfortunately, this to me is an example of a chaotic, too long page, that jumps between different levels of abstraction, assumes some prior knowledge, is overfull with links, and sprinkled with occasional philosophising sentences. I can’t make heads or toes of what Z(…) is from it, unfortunately :(

    3. 6

      Cool, this has been moving fast! Excited to see where it goes.

    4. 4

      looks cool, I wish it would not require nix and haskell to be build. Is there a possibility to get static binaries?

      1. 2

        Well, with the nix cache you would not have to build any Haskell libraries other than neuron itself.

        Creating static binaries is a good idea. Feel free to open an issue on GitHub! There is also WIP docker support.

        EDIT: macOS cache is currently broken; I’m fixing it.

        1. 1
    5. 2

      We use rST (docutils) and Sphinx to build documentation about our Python applications. Sphinx documents are based on a Table of Contents (toc). Basically, you register your pages to the toc. Adding pages, modifying the toc - a piece of cake; couldn’t be easier.

      Neuron is similar to Sphinx with one big difference: you don’t need to build a toc. Instead, you link pages; and the Neuron index of the links is automatically updated (using rim) (similar to the Sphinx approach).

      We now think we have one solution with two parts: 1 A light weight method of recording ideas, instructions, comments (Neuron zettels) 2 A heavy duty documentation environment (Sphinx)

      The underlying file - a markdown/rST document - can easily be move between the two environments.