I enjoyed having conversations with Doug Belshaw this morning as we walked around Amersfoort. Tonight I’m going through his presentation on Open Badges for the Dutch national libraries conference this week, which was why he was in town and which provided the opportunity to meet up.

I wonder how I could connect the convictions my company has about our work with open badges, and how such badges can play a role in promoting the skills connected to those convictions to our team and new hires, as well as our wider network. Meet-ups, unconferences, that we already organise may turn into a bit more, by acknowledging the knowledge and skills transfer taking place with a badge perhaps, by issuing them from our company. As recognition for things we deem important. I also associate it with my train of thought on framing our convictions and principles in terms of SDGs. Lots to chew on, besides badges, like co-ops, as well.

In reply to On taking notes and syndicating them by zblesk

Thank you for writing that! I too find it highly interesting to see how other people arrange their workflows, choose their tools and what they do with them. Often there are things that spark an idea or suggest a useful tweak to my own workflows. So thank you for making a comparison between how you work and what I wrote about how I work.

A few reactions to some of the things you mention.

My perspective on (personal) knowledge management is centered around the notion that I should have everything under my fingertips, and should be able to fully determine my own choice of tools. Tools one can preferably tweak, reshape or replace easily. I started taking notes in the early 1990’s and local text files were the most basic choice I made (and one of the few I then could make). Later convenience lured me into other things like Evernote, and Things for tasks, but I’ve returned to that basic starting point of using text files more recently.

At the core are these notions I hold:

  • Local first. I’m from an era that connectivity can’t be taken for granted, and regularly work in settings where that is still true. It is also a dependency that even when it is usually reliable, probably carries a high cost if it does fail, as that most likely is in key moments (basically a version of the demo effect).
  • Agency over tools. Tools must provide actual agency. A key part of it is being able to fully control it’s deployment and use, being able to tweak it etc. Tools must be smaller than us in that sense (not in a literal sense). Convenience may make me ignore this factor up to a certain point, but in the end having control over my tools always comes back up as an issue. Not having such control ultimately always turns a tool into a single point of failure. (Gmail and Evernote are prime examples to me) That drives me to simpler tools within my own scope of control and power to manipulate, and only allowing more complexity if it increases my personal agency significantly. It also means to me that tools need to be useful on their own, and more useful when networked.
  • Personal tools. Tools need to be adaptable to the person using it. That makes it easier to make those tools smarter. As personal preferences can be assumed as the defaults, and personal routines are predictable to the person itself. Predictable routines plus preferences equal functions and parameters, i.e. code.
  • Personal agency is always in the context of networked agency. In most settings the unit of agency is not the individual but a small group of connected people trying to solve something that is important to the group itself. Whatever tools the group uses should be within the scope of control of that same group. As a group’s notion of local is usually a networked notion, my local stuff needs to be able to connect (yet not depend on it). Distribution is important here. Centralisation is mostly to be avoided as it carries a cost in overhead, control and resilience.

Put that all together, and indeed POSSE basically becomes the prime directive for everything.

On PHP: I’ve been using PHP for about 20 years. When I create something as a personal tool, it makes sense to just grab the building blocks I’m already familiar with. I’ve always run a local webserver on my pc/laptop, and writing up a few lines of PHP and dropping it in a folder my local webserver uses, makes it fast and easy. Easier at least than getting to know new frameworks, or whatnot. Javascript never appealed to me even if it is from the same 1990’s era, nor succeeded in making much sense to me. Apart from doing browser side things with it in an HTML page.

On WordPress: I used to handcode my sites, until I started using Movable Type shortly after I initiated my blog (hosted on a webserver at home). That was written in Perl which I was comfortable with having written my then employer’s first intranet in it. A decade later I switched to WordPress when my Movable Type install suddenly stopped working completely. I see you use Ghost, which ran a kickstarter I supported shortly after I switched to WordPress (self hosted on an external hosting package). By the time Ghost saw its first release I didn’t act on my earlier idea of running that on a home server. I’m not particularly attached to WP (also used Drupal heavily for other sites), and use it pretty bare bones, but it has served me well for the last 10 years. The switch to Gutenberg and blocks though has me thinking I might maybe go for something simpler.

On Obsidian / Joplin: I also use Joplin, but haven’t tweaked it like you have, I use it out of the box. It’s where my Evernote exports live, which from there I export to md files as needed. I treat Obsidian as a viewer, and Joplin too. Because of that I dislike that Joplin stores stuff locally in an sqlite database, obscuring the contents from my filesystem that way. From a viewer it then becomes an obscurer. Currently Obsidian has my sympathy, that may change, no tool is forever. So in my choices of e.g. plugins for Obsidian I avoid things that provide functionality that comes with a type of lock-in, where if you stop using a plugin part of your information disappears or is hard to get at because it was in a database not in the notes. I dislike YAML frontmatter too. For the Dataview plugin I use inline datafields (key:: value) which makes them a regular part of the note itself. Only when for some automation I need to know where to easily find a data field, I will put it at the top (but still not as YAML frontmatter).

On public RSS subscriptions: yes, I post a list of all the feeds I subscribe to. I treat them as individual’s voices (so no feeds from news outlets etc), and group them by my perceived social distance. I treat blogging and interacting with feeds as distributed conversations.

I always like reading about how other people process information and handle their notes/knowledge bases. It’s a topic I think about often.

Ton Zijlstra’s ideas are especially interesting to me because it seems we are trying to achieve similar goals, but go about it in opposite ways.


(also posted to Indienews)

In het past weeks I struggled to get to action. I didn’t have the sense that I was in the pilot seat. Too many little things budding in, not being able to get started on bigger things, and no sense of overview. Or rather, a too overwhelming overview, and no easy way for myself to bring the scope of that view down to something manageable for the day.

I have about 35 areas of activity, this includes projects, general tasks, both business, volunteer work and personal. For each of those 35 or so activities I keep a running list of things to do. Some lists have a few items, others have a few dozen. If on average they hold 10 tasks each, it means a tasklist of 300 to 400 items to choose from. That makes for an overwhelming overview. It gets better if I dive into the scope of a specific project or activity area, but then I don’t see the small things I can do to keep the other activities rolling. When I was still using Things I had the same effect, so this isn’t something particular to my current use of Obsidian for tasks.

The result has been that, because the overall list is too overwhelming, I haven’t been using it much. Which means I have even less sense of overview or being on top of my stuff.

In an attempt to regain that sense, I’m now trying to each morning go through the entire list and pick a handful of things for the day. That small curated list has a more manageable scope, without being limited to a single activity.

I don’t want to copy tasks from one place to another. I want them to stay on their respective project or activity list, but marked and summarised on my daily list. I’m aware there are various task oriented plugins for Obsidian, but they will prescribe me a certain mode of working, and it isn’t certain that in their absence the same information will be as usable / findable (a type of functional lock-in or dependency I always want to avoid)

What I came up with is I mark every task I choose for the day with ‘t::’, in whichever line of whichever file I want. This can be an existing tasklist, but I can do the same while making meeting notes, to quickly mark something as a task resulting from the meeting. The Dataview plugin I already use sees ‘t::’ as an inline datafield and is able to extract them into a list using the following brief piece of code:

TABLE t as Vandaag
SORT File asc

I display that at the top of my daily note. It allows me to quickly jump into a task list or other note to delete it when done, and to copy it over into my daily note in the ‘done’ list.

In the coming days I will test if this improves my days and activities.

A brief list of selected tasks from other files. Also note that at the top t:: is mentioned inline twice, and both show up as task items in the list.

Bookmarked Research Rabbit

Research Rabbit is a tool that, when provided with some academic paper you already are familiar with, can suggest other related material as well as provide that material. By looking for material from the same authors, by following the references, and by looking at the topics. This can speed up the discovery phase quite a lot I think. (And potentially also further increases the amount of stuff you haven’t looked at but which sounds relevant, thus feeding the collector’s fallacy.).

I’ve created an account. It can connect to Zotero where you already have your library of papers you are interested in (if you use Zotero with an account. I use Zotero standalone at the moment I added a Zotero account and storage subscription to sync with Research Rabbit).

Looks very useful. HT to Chris Aldrich for in Hypothesis pointing to a blogpost by Dan Alloso which mentioned Research Rabbit.

Favorited Sketch noting for PKM by Zsolt Viczián

Multiple elegant ideas (and practices) in that post, about the use of Excalidraw within Obsidian (which I previously described):
1) creating icons from basic forms (such as sketch noting teaches as well) and iterate each time you use them
2) keep your icons in a library in Excalidraw for various forms of re-use and for iteration
3) add #keywords to your icon, because in Excalidraw/Obsidian these behave as active searches for those keywords just like regular # in a text.

I came across this post by Zsolt Viczián through a list of PKM system examples by Elizabeth Butler, in which she also linked to my PKM description. Naturally I explored the other examples in that list, and this one stood out for me.

Because I couldn’t even get past the level of drawing stick figures, I have always felt intimidated by friends who could draw well. The idea of developing my visual vocabulary was a game-changer for me…… I added hashtags to each icon because, this way, if you add them to your sketch in the Obsidian-Excalidraw plugin, your drawing will be tagged with the relevant keywords.

Zsolt Viczián

Gisteravond vond de 3e Nederlandstalige Obsidian meet-up plaats, dit keer met zeven deelnemers. Organisator was Christian. Het was al weer even geleden dat ik de eerste 2 sessies hield. Veel langer geleden dan ik me realiseerde toen ik het tijdens de sessie gisteren opzocht (de eerste was in april, de tweede in juli)

Omdat ik ziek in bed lig deed ik mee zonder camera en geluid. Af en toe liet ik van me horen in de chat van de online meet-up. Enkele voor mij bekende gezichten, zoals Wouter en Willy, en vooral nieuwe. Dat was prettig want zo hoor je nieuwe dingen.

Een paar dingen die me opvielen en in me opkwamen, voor mijn beperkte energie op was, en ik het gesprek verliet:

Ieder van ons heeft een lange geschiedenis met notitie-apps, en uiteindelijk wint volgens mij de toepassing die niet alleen frictie reduceert om dingen op te slaan en met die dingen te werken, maar die ook andere wegen openhoudt en je niet opsluit in het denken van de maker van de tool. Op een gegeven moment ging het over welke plugins we gebruiken, en ook daar hoorde je reserve voor plugins die je ‘opsluiten’ in de tool, d.w.z. die niet alleen functionaliteit toevoegen, maar ook inhoud die vervolgens buiten Obsidian niet toegankelijk is (in de platte tekstfiles waarin je notities zijn opgeslagen). Later las ik dat er een plugin is die dat opsluitend effect expliciet probeert tegen te gaan voor wat Obsidian zelf aan gegevens opslaat: de Obsidian metadata-extractor die de metadata naar je harde schijf schrijft zodat andere applicaties (zoals bijv AlfredApp) er bij kunnen. Hiermee kun je Obsidian directer vanuit andere applicaties aansturen als je wilt.

Digitaal eerst, of niet?

Digitaal of eerst op papier? Dat is een vraag die al vroeg aan bod kwam. Mede naar aanleiding van hoe Wouter Obsidian gebruikt. Hij doet alles eerst op papier, scant die pagina’s (met Genius Scan van Grizzly Labs op zijn telefoon), en maakt bij elke foto een korte index, zodat hij via de zoekfunctie de juiste scans kan vinden. Na de eerste meet-up waarin hij dat ook vertelde, ben ik mijn eigen papieren notitieboeken ook gaan scannen, met mijn CZUR staande scanner, en maak daar eveneens indexes bij. Dit keer werd me duidelijk dat hij dat net iets anders doet dan ik heb gedaan. Ik maak 1 index per notebook met links naar de plaatjes in de vorm “plaatje12 over #opendata en gesprek met XYZ”, Wouter maakt per scan een note met daarin zijn annotaties, zodat je de afbeelding meteen boven die annotaties ziet staan. Dat lijkt me weliswaar eleganter, maar ook meer werk.

Al heb ik zelf een sterke voorkeur in het meteen digitaal maken van mijn notities, is de rol van papier en pen wel degelijk belangrijk. De reden om als het kan digitaal-eerst te werken heeft vooral met de frictie te maken die de latere omzetting naar digitaal nog altijd betekent. Sinds klas 5 van de basisschool houd ik al notitieblokken vol aantekeningen bij. Dat is 4 decennia aan notitieblokken.
Fysiek iets schrijven is anders en levert andere verbindingen op dan tekst tikken op het scherm.
Fysiek omgaan met bestaande notities heeft dat andere effect ook bij mij: ik plak met enige regelmaat een reeks post-its met inhoud uit mijn notes op de muur om beter te snappen wat onderlinge verbanden kunnen zijn, ‘gaten’ te zien. Ik kan dat welisaar ook in tools als Tinderbox visueel doen op mijn scherm, maar het werkt anders omdat ik dan mijn handen niet gebruik, niet voor de muur in mijn kamer heen en weer drentel etc.

We hadden het ook over lezen op papier of digitaal. Ook daar speelt voor mij de wrijving een rol in hoe je aantekeningen later digitaal kunt verwerken. Ik lees vooral digitaal (het is veelal goedkoper en scheelt thuis vooral enorm veel ruimte), maar voor non-fictie is mijn eigenlijke voorkeur papier, vanwege het overzicht dat het biedt op een manier die e-readers nog altijd niet weten te bieden. Op mijn e-ink device, en voor PDFs die ik in Zotero verzamel is dingen in boeken markeren of in de kantlijn schrijven inmiddels naadloos naar mijn notities te krijgen, zodat ik ze daar inhoudelijk kan verwerken. In deze context werd ook het boek Proust and the Squid: The Story and Science of the Reading Brain van Maryanne Wolf genoemd.

Visueel en tekstgericht

Markdown is een opmaaktaal voor tekst, en Obsidian is een viewer op markdown files, en dus in principe geheel tekstgericht. Je kunt wel plaatjes opnemen maar dat zijn passieve afbeeldingen. Je kunt daarnaast Mermaid diagrammen maken, als manier om in tekst een diagram te definieren.
Tot nu toe was dat weinig nuttig voor me, omdat ik eigenlijk uitsluitend in edit-mode werk, en dan zie je alleen je eigen ruwe tekst, niet de opmaak of het diagram als je die toevoegt. Het is de reden dat veel mensen gelijktijdig de markdown tekst waarin ze werken en het visuele resultaat naast elkaar op hun scherm toonden, maar ik doe dat eigenlijk nooit.
Nu is er sinds kort de Live Preview modus (in beta), waarin je eigenlijk altijd het opgemaakte resultaat van je tekst ziet, totdat je je cursor ergens zet en begint te editen. Dan wordt daar lokaal je orginele markdown zichtbaar. Ik heb nu geen extra muisklikken nodig, en hoef geen extra schermpjes open te hebben om mijn markdown ‘live’ te zien. Dat maakt het weer veel aantrekkelijker voor me om ook visuele elementen in mijn notities (te proberen) te gebruiken.
Een van de deelnemers is een eindexamenkandidaat die de stof deels ook in schetsen en diagrammen vertaalt. Iets visueel maken helpt bij het internaliseren van stof, maar ook bij het naar voren halen van die kennis als je de afbeelding weer ziet. Ingewikkelde complexe dingen laten zich vaak makkelijker in een schets vangen dan in een platte tekst die per definitie lineariteit en hiërarchie suggereert. Tot mijn verrassing gebruikte hij een schetstool die volledig in Obsidian te integreren is, en waarmee je ook zelfs links in een afbeelding naar andere notes kunt opnemen. Die schetstool is Excalidraw, in principe een browsergebaseerde tool. waarvoor iemand een Obsidian plugin heeft gemaakt. Excalidraw is net als Obsidian zelf nog maar anderhalf jaar oud. Daar ga ik zeker mee experimenteren.

In de context van schetsen maken kwam ook The Back of the Napkin van Dan Roam ter sprake, en ik moest zelf ook denken aan sketchnoting en The Sketchnote Handbook van Mike Rohde (alleen al een tof boek omdat ik er in sta 😉 )

Een van de andere deelnemers, Roy Scholten is nadrukkelijk bezig met de rol van visualisatie in het overbrengen van kennis en het helpen bij duiding. Zijn blog Bildung zit vanaf nu in mijn feedreader.

Werk en Privé

Het laatste dat ik even wil aanstippen was een gesprek over of je in je notities werk en privé mengt of juist scheidt, en of je er aparte vaults (losse collecties in Obsidian) voor bijhoudt. Bij mij zit alles op 1 plek, onderscheid maak ik in een folderstructuur zodat dingen over bijvoorbeeld ons huishouden niet staan tussen dingen over een huidig klantproject. Al mijn conceptuele notities zitten wel in één folder, ongeacht het onderwerp, want daar telt de onderlinge (netwerk)verbinding het zwaarst. Mijn folderstructuur is niet thematisch gesplitst maar in aandachtsgebieden in mijn leven (zoals in de Getting Things Done methodiek, en in PARA al zitten mijn projecten allemaal in zo’n aandachtsgebied, anders dan PARA). Voor de genoemde eindexamenkandidaat lag er een splitsing tussen school en de rest, en dat kan ik me goed voorstellen. Je notities voor je eindexamen komen voort uit iets dat je wordt opgelegd, iets vooral buiten je eigen directe interesses of activiteiten. (Tijdens je studie is dat weer net wat anders, daar ontdek je juist welke aspecten je straks in je professie boeiend vindt, dus daar wordt het meer eigen, en minder externe verwachting ondanks de tentamenstructuur). Sommigen doen het net als ik, waar ‘alles’ in het systeem zit. Mijn PKM is deels gebouwd op Getting Things Done en daaruit vloeit die ‘allesomvattendheid’ al voort, maar ook op mijn persoonlijk opvatting dat er weinig verschil is tussen werk en niet-werk voor mij. In die context werd ook gesproken over Kanban of Trello boards voor thuis. Mijn primaire tools voor mijn werk en voor thuis zijn identiek eigenlijk, voor klanten hanteer ik daarnaast meestal andere (die ik grotendeels niet thuis zou willen inzetten, dat is waar). Het thuis hanteren van uit je werk bekende methoden om zo de logistiek thuis te vergemakkelijken, en ruimte te maken voor elkaar lijkt me vooral gezond. Onze eerste verjaardagsconferentie in 2008 ging al hierover.

Dank aan Christian voor het organiseren van deze bijeenkomst, en alle deelnemers voor het delen van hun ervaringen en werkwijzen.

Ook met andere Nederlandstalige Obsidiangebruikers van gedachten wisselen? Die Nederlandstalige Obsidian gebruikers vind je ‘allemaal’ op het Obsidian Discord kanaal #nederlands.