Progressive summarisation or how to create discoverable notes | Tiago Forte

Progressive summarisation may not be ideally suited for me right now, but it's an idea which stuck with me whilst I was undergoing my own taxonomy building process. It's worth stepping through the setup for the idea logically:

  • You want to create a "second brain" that stores all the information you find useful but don't have an immediate need for, so you can reference it later; a "storage and retrieval system" for knowledge;
  • That storage system needs a structure, which is where P.A.R.A (Projects, Areas, Resources, Archives) comes in. This system uses these four folders to quickly categorise any piece of information. Projects is for things being actively worked on; areas is for core subjects that you use routinely (hobbies or work-related); resources is broader topic information that you may want in the future (more like a library categorisation system); and archives are for notes that you find interesting but may never need to look at again;
  • Sorting information into these buckets of relevance places it on a timeline: projects are for now; archives are potentially for never. The other two fit in the medium- and long-term.

But P.A.R.A doesn't explain how to take notes. There are two approaches: tagging and notebooks (aka categorisation). Tagging sounds cool, because you build an esoteric web of interlinked data over time, but it doesn't fit how most people's brains work so it's bad for memory recall. Notebooks work like our brains, forming "discrete containers", but they kill serendipity (to paraphrase).

Tiago argues for a note-first approach where you focus on simply recording knowledge as notes. It's a universally applicable system, so it works regardless of existing content structures and makes migration simpler, and it prioritises the act of notation which is the most useful in the long run. It mimics atomic design: notes are atoms and can be assembled into elements, molecules etc. in the future.

But that means our notes need to be well designed so they're useful in the future, but they also need to be quick to create (efficient). There's an obvious paradox here; as Tiago puts it:

You cannot compress something without losing some of its context.

He gives some great outlines of this, where notes are too condensed and therefore lose meaning with time, or two contextualised and therefore too long to be an efficient note-taking (or reading) process. The balance point is progressive summarisation, where you take an iterative approach. It's similar to how I used to condense course notes into flashcards into memory. Critically, you do this over time. So step one is done the moment you create the note; step two the first time you return to it, and so on.

  1. Makes notes. These will be long.
  2. Go through and bold key takeaways or phrases, the bits that really matter.
  3. Highlight any passages which you come back to more than once, so that the real gems slowly rise to the surface.
  4. Create a tl;dr style summary; use your own words so that it becomes learned knowledge.
  5. (this is rare) Remix it. Find the links, the novel new take, whatever spark of creativity you've had on the subject and write that up as a top-level paragraph.

At no point during summarisation do you delete anything; this is pretty much only ever an additive process, it's just that you slowly prioritise the information until what's left is the stuff which is most useful. That means if your use changes in the future, you still have the full context.

It's an interesting take on cataloguing information and I can't help but consider it an ideal methodology for Wiki-style information stores. Unfortunately, I don't want wiki-style stores; I want an information web. I don't see it working quite as well for that in the long term.

Explore Other Notes

Newer

Input attribute for one-time code

Just a neat tip: the autocomplete="one-time-code" attribute/value allows an HTML form to fetch a code used for two-factor authentication directly from the messaging app. Seems to only work for …

Older

What the heck is inclusive design?

I love Heydon's breakdown of why "accessible" =/= "good". To paraphrase: accessibility is about removing barriers that would prevent people from using your site, but if the content is crap or the …

  • <!DOCTYPE html> <html> <head> <title></title> </head> <body> <p>Progressive summarisation may not be ideally suited for me right now, but it's an idea which stuck with me whilst I was undergoing my own taxonomy building process. It's worth stepping through the …</p> </body> </html>
  • Murray Adcock.
Journal permalink