13 Matching Annotations
  1. Jun 2022
    1. The addressing system that many digital note taking systems offer is reminiscent of Luhmann's paper system where it served a particular use. Many might ask themselves if they really need this functionality in digital contexts where text search and other affordances can be more directly useful.

      Frequently missed by many, perhaps because they're befuddled by the complex branching numbering system which gets more publicity, Luhmann's paper-based system had a highly useful and simple subject heading index (see: https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_2_SW1_001_V, for example) which can be replicated using either #tags or [[wikilinks]] within tools like Obsidian. Of course having an index doesn't preclude the incredible usefulness of directly linking one idea to potentially multiple others in some branching tree-like or network structure.

      Note that one highly valuable feature of Luhmann's paper version was that the totality of cards were linked to a minimum of at least one other card by the default that they were placed into the file itself. Those putting notes into Obsidian often place them into their system as singlet, un-linked notes as a default, and this can lead to problems down the road. However this can be mitigated by utilizing topical or subject headings on individual cards which allows for searching on a heading and then cross-linking individual ideas as appropriate.

      As an example, because two cards may be tagged with "archaeology" doesn't necessarily mean they're closely related as ideas. This tends to decrease in likelihood if one is an archaeologist and a large proportion of cards might contain that tag, but will simultaneously create more value over time as generic tags increase in number but the specific ideas cross link in small numbers. Similarly as one delves more deeply into archaeology, one will also come up with more granular and useful sub-tags (like Zooarcheology, Paleobotany, Archeopedology, Forensic Archeology, Archeoastronomy, Geoarcheology, etc.) as their knowledge in sub areas increases.

      Concretely, one might expect that the subject heading "sociology" would be nearly useless to Luhmann as that was the overarching topic of both of his zettelkästen (I & II), whereas "Autonomie" was much more specific and useful for cross linking a smaller handful of potentially related ideas in the future.

      Looking beyond Luhmann can be highly helpful in designing and using one's own system. I'd recommend taking a look at John Locke's work on indexing (1685) (https://publicdomainreview.org/collection/john-lockes-method-for-common-place-books-1685 is an interesting source, though you're obviously applying it to (digital) cards and not a notebook) or Ross Ashby's hybrid notebook/index card system which is also available online (http://www.rossashby.info/journal/index.html) as an example.

      Another helpful tip some are sure to appreciate in systems that have an auto-complete function is simply starting to write a wikilink with various related subject heading words that may appear within your system. You'll then be presented with potential options of things to link to serendipitously that you may not have otherwise considered. Within a digital zettelkasten, the popularly used DYAC (Damn You Auto Complete) may turn into Bless You Auto Complete.

  2. Jan 2022
  3. Nov 2021
    1. https://diggingthedigital.com/abonneren-op-aantekeningen/

      I like the idea here of being able to watch over someone's shoulder quietly to see what they're working on and how they're doing it. There's some interesting anthropology hiding here.

      Have to say I'm a bit flattered that it's me that's being watched...

  4. Oct 2021
  5. Dec 2020
  6. Nov 2020
  7. Oct 2020
    1. For years, I’ve shared with friends and clients what I call the bunny theory of code. The theory is that code multiplies when you’re not looking, not unlike bunnies that tend to multiply when you’re not looking.
    1. About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.
    2. it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.
  8. Jun 2020
  9. May 2020
    1. The administration and its allies fear that the more people gravitate toward the successful, free-market self-insurance approach, the worse their government-engineered health “reform” will look. We’re already seeing the beginning of this trend.
  10. Apr 2020
  11. Jun 2015
    1. glancing, glimpsing, scanning, surveying, and other forms of casual or disinterested looking, staring

      I like the diversity of ways of looking laid out for us here.