This post is part of my wider enquiry into my note-making practices.
In terms of setting a baseline for where I started (and some of the history) I think it’s useful to split this into “Practice” and “Tools”.
In my work sphere, although I write a considerable volume, it it is always withn the context of work-based collaboration. So for example position papers, agendas and meeting notes tend to be organised within the shared storage for the relevant working groups or projects. Technical architecture design notes and technical or process documentation tend to be filed in the shared spaces where the work is carried out, and so on.
Personal working notes tend to be very sporadic - historically I’ve tended to keep a rough daily log of any key accomplishments, key points from conversations, issues to raise later, but not in a systematic way. Historically I write very little in terms of explicit knowledge capture - a mixture of tacit knowledge and a faith in a combination of internet search and link-tagging in Diigo have been the mainstay of my day-to-day work.
Outside of work, or for areas of practice where I feel able to document things publicly, I have maintained this blog for nearly two decades as a Stream mode note system. Alongside that I have long felt the need for notes which are more state mode but have never had a clear and consistent practice for working with them.
In the work environment, the ubiquitous tools are the Microsoft Office suite. Even work product that gets created in specialist tools (such as UML modelling) nearly always ends up in some kind of Office file to support collaboration. Personal workplace notes such as any kind of work journal have historically spread over a variety of media including paper notebooks and my current preference, Microsoft OneNote.
For personal note-making, the ubiquitous personal tool is of course the smartphone, for everything from shopping lists upwards. One of the key technical goals from the changes I am making is to enable me to add to any note-system from a mobile device.
Alongside the blog I have used a variety of tools as a personal wiki, starting in 2003 with some now-unknown software, then moving the same year to TikiWiki. I infer from old posts that something else came next, then I moved to WikkaWiki in 2007. That lasted until I started playing with Smallest Federated Wiki from 2016.
Points of friction
From a purely technical point of view the main difference between the “old way” and the “new way” is the switch from database-backed websites to plain text files, with optional publishing to static websites. The key that unlocks progress is to separate the writing context from the publishing context.
The blog made this change last year when I switched to Hugo, as I have started to look at better note-making methods it seems a good idea to look at a similar switch for my main notes.
The experiment with Federated Wiki has been useful, and it is potentially a very effective way of taking notes - Mike Caulfield has perhaps the best series of posts about how to use it. However I found that the following issues became limiting factors:
- paragraph-oriented drag and drop
- lack of backlinks
- lack of easy graphical visualisation (although there are some graphvis plugins)
The second area of friction is the disconnect between personal and work-personal note-taking systems. (I exclude work product which is to be shared as that will need to stay in the right system for colleagues - this is about personal notes)
Not only is this a technical friction but also a process restriction - during any given day one switches between “personal” and “work” mode frequently, and knowledge itself is not bounded in that way.
The obvious place to start in terms of my personal content is to continue the move to plain text files that I started with the move from Wordpress to Hugo, and extend that to how I write and edit notes.
The other area that requires attention to is to build working practices that combine the organisation of work with the capture and refinement of knowledge artifacts.