What I learned about markdown from interviewing a bunch of people
6 May 2022 | 12:56 pm

A view of my old room when I was at the University of Iceland
This is the only photo I have of my old Mac Performa. Taken when I was moving out of student housing at the University of Iceland, hence the empty shelves.

A prologue, of sorts

I can’t remember when I first started to use plain text files for my notes and other writing. It would have been some time after 1995 when I was 18 and had recently spent the money I’d earned on my part-time job on a down payment for a Mac Performa.

(I was paying for that computer for years afterwards.)

That computer was an upgrade from my old Mac SE and in many ways, a major improvement:

  • Colour! Thousands of them, even. So nice.
  • Multi-tasking. Also great. More than one app running at a time? Sign me up.
  • More storage.
  • An option for a built-in modem. Hello, Internet!

But, and this is where the story begins to sound familiar to modern Mac users, the software was a different story. However, this time the fault wasn’t with Apple but with Microsoft.

My go-to application on the SE (commonly nicknamed the “kýrauga” in Icelandic, literally “porthole”) was Microsoft Word. Anything I typed I typed in Word. A small black and white screen, Word 5.1, and a mechanical keyboard made for a surprisingly good writing environment.

With the upgrade came a transition to Word 6.0, courtesy of ‘borrowed’ install disks from my mom’s office, and I was not happy.

The performance and UX disaster that was Word for Mac 6.0 is well-documented elsewhere. It’s a textbook case by now. This meant that I began to use Word less and less for personal writing and relied on it primarily for writing for school.

I’ve always written and have always used computers for writing. I began by usign WordPerfect for DOS when I was ten years old. Switched to Word on the SE. And when Word disappointed on the Performa I began to search for alternatives. I tried ClarisWorks for a while. Even tried Nisus Writer.

As you might guess, all this switching meant that file format compatibility became a bit of an issue. And given that most of this was just notes and other personal writing, I eventually settled on plain text and BBedit Lite and have since then mostly stuck to plain text as my primary format for taking digital notes. My use of plain text predates my use of markdown and other markup formats (including HTML).

For work, I’ve always just used what I had to: Word, Google Docs, Pages, whatever. But for myself? Plain text.

The User Interviews

I had forgotten about all of this when I was preparing for the user research interviews I had set up for my Colophon Cards project.

The interviews were a follow-up to the survey I had conducted a few weeks earlier. I wanted some more context on the data from the survey and to get some feedback on the initial paper prototype of the main view (implemented in HTML, natch). I got around a dozen people volunteering for an interview, which I split into two cohorts:

  1. For the first, I focused on the various kinds of note-taking they were juggling in their lives: collaborative work, individual work, personal, household, hobby, etc. Followed by a short test of the initial paper prototype.
  2. With the second cohort, I tried to dig more into how the various parallel note-taking processes that people used worked together. Were the analogue notes ever moved into digital? Was there a flow between the collaborative notes for work and the individual work notes? Followed by a short test of a new iteration of the paper/HTML prototype.

It’s not the sort of study you do to get conclusive actionable data. Too few participants; too unstructured; a self-selected group of expert users.

That last part is an especially big issue for studies like these. It’s much easier to recruit subjects who have a deep interest in the subject matter, so you tend to end up with a higher proportion of expert users than would be representative of your actual user base. And that was certainly the case here.

These sorts of interviews can be a good source for leads and ideas, though. I view these results more as a starting point for further testing and research.

I wanted some context for some of the bigger questions I had after the survey. One of them was on formats and lock-in. Quite a few of the respondents looked like habitual app switchers and I wanted to find out why.

My motivation was quite self-serving:

  • People who switch are more likely to give a new app a chance.
  • If you know what problem causes people to switch, you can address it before it happens.

So, Why Did Switchers Switch?

A lot of it is, frankly, down to trauma. Everybody who has used computers for more than a few years has had at least one experience akin to “Word for Mac 6.0.”

  • Apps that got steadily worse with each update.
  • UX degradation as features pile up.
  • Apps that were abandoned or even shut down as businesses' priorities changed or companies went bankrupt.
  • Having to switch OSes for some reason and discovering that an app didn’t support their new platform.

The switch for most wasn’t to markdown or a markdown app. They switched to plain text because that format works everywhere with everything. They weren’t switching to markdown specifically. Plain text lets you mix and match apps depending on the platform. You aren’t locked into the same app on desktop and mobile.

This is where expert user bias is important. These respondents were your ideal markdown user: technically competent, curious, and familiar with markup as a concept. They all know markdown and many of them use it regularly. But none of the benefits they described were those of markdown. They weren’t publishing these notes. They weren’t converting their notes to HTML or printing them. What they wanted was the portability and interoperability of plain text. Markdown just made plain text more usable.

If expert users aren’t using markdown for markdown’s sake, what are the chances that a non-expert markdown user is motivated to use it out of genuine interest in a markup format?

To markdown or not to markdown?

A question that has been rattling around in my head from the start of this project—actually, from the start of my projects at Rebus a few years ago—was whether the writing widgets in the apps I work on should be based on rich text or on markdown?

Markdown has a number of obvious flaws. It starts off simple for most users but its mid-level or advanced features are surprisingly hard to master. Many find it quite difficult, for example, to remember what kind of bracket to use and where. Which comes first in a markdown link, the square brackets or the regular ones? Personally, I can’t, for the life of me, remember how the image markup works. I usually end up embedding an HTML image element. I don’t even know where to start with markdown tables. And I’ve been blogging with markdown for almost two decades.

HTML markup tends to be clearer for many elements, easier to write and read, and less ambiguous. Images, tables, and even links tend to be more straightforward in HTML.

It’s uglier, sure. HTML source code isn’t noted for its typographic aesthetics. But clarity and consistency go a long way.

A bigger issue is that HTML and markdown have drifted apart. Markdown doesn’t have a standard way to markup figure elements. The methods for generating an id attribute, important for cross-referencing, are also non-standard.

But these issues generally don’t matter if you’re writing for yourself and don’t plan on converting the text into HTML or PDF. In those cases, the primary value is the non-proprietary nature of plaintext and the features that markdown provides are just gravy on top. What matters in that context is that non-expert users aren’t likely to be even aware of markdown’s features or even markdown’s existence in the first place. The risk is that you have a bunch of users for whom markdown’s learning curve is so steep that it looks like a wall.

Rich text then?

I’m not a fan of many of the current trends in rich text editing either.

Block-based editors generally started off utterly dysfunctional because they were, for the most part, flawed conceptually. (Any rich text editor that doesn’t let you select text across blocks is not fit for purpose.) The only way to ‘fix’ most of them has been for them to lose more and more of their unique characteristics. Now, ‘block-based’ has devolved into a marketing term as most of these editors are indistinguishable from their non-block-based counterparts.

Rich text editors today also tend to rely on margin or command menu buttons that are so over-loaded that they make even the most cluttered and ambitious hamburger menu look as clear and straightforward as that of MacPaint in my old SE all those decades ago. Most of them are UX messes overloaded with features.

The minimalist rich text editors, on the other hand, tend to be too minimal. They either rely heavily on hover state for revealing UI elements or just literally expect you to know markdown to activate many of their formatting features. The few that do neither tend to be too spartan and support little beyond basic inline formatting, a couple of heading levels, and image embeds.

Rich text widgets are also notoriously hard to implement properly (usably and accessibly) on the web. They’re extremely easy to get wrong, esp. if you’re trying to roll your own. (Don’t do that.) And if you reuse an existing widget, you tend to inherit whichever garbage UX trend was popular when that widget was first implemented. Markdown, by contrast, just needs a text area. It can benefit from more but doesn’t require it.

Rich-text widgets also raise the spectre of interoperability. People use plaintext for a reason, which is that it works everywhere, with everything, and is readable even in apps that don’t support markdown or other markup formats specifically. You could store the output of a rich text editor as HTML, which has many of the same interoperability benefits as markdown as it’s also a markup format built on plain text. But markdown has one clear advantage over HTML, which is that most of its block-defining markup is either invisible or as-good-as invisible. Paragraphs are defined by new lines. Lists are defined by looking like lists. Even headings are conceptually simple. Even if you had to use HTML for everything else, these block-level features on their own add tremendously to markdown’s usability as a plain text format.

This might not be an issue if you’re just using HTML for interoperability but might become an issue for users who need to edit it by hand for some reason.

You could use markdown as your editor interchange format but then markdown’s multiple flavours and drift from HTML becomes an issue.

So, what? Just give up?

Surrender means text areas, which means markdown wins by default, except in a way that you can’t market or leverage in any meaningful way.

Instead, I’d like to split this issue into a number of smaller problems to tackle:

  • Ongoing interoperability. The ability to integrate other apps and tools into your note-taking workflow is vital to many.
  • Sporadic interoperability. Being able to export files to use in other contexts and apps.
  • Ease of use. Being able to take notes without learning a markup format.
  • Power. Being able to accomplish your note-taking or writing goals.

The interoperability issues can be tackled, using markdown even, without forcing markdown as a writing tool.

Ease of use is, quite honestly, best served with a rich text editor. They’re tricky to do well but doable.

Power, then, becomes the toughest nut to crack. I think that’s an interesting problem in its own right. You don’t need to resort to markdown to enable power user features in note-taking.

So, I have an angle on this I need to research and pursue, that doesn’t necessarily require me to build a markdown-oriented app.

An epilogue, of sorts

For most of my life, I had been an avid keyboard user. I hardly ever wrote anything out by hand and had notoriously illegible handwriting. But I had completely forgotten about my initial transition into plain text in the early days of my computing life.

A few years ago, I decided to switch most of my note-taking to analogue. I decided to prioritise my own enjoyment of the note-taking experience over productivity or automation. I switched from being a mostly keyboard and plaintext note-taker to being an avid user of paper, fountain pens, notebooks, and index cards. I later added a whiteboard (now a chalkboard) into the mix.

What I found out was that my productivity and understanding of what I was working on didn’t decrease at all. Instead, it increased with my enjoyment. This is what initially prompted me to expand my ongoing research focus from digital reading to annotation, note-taking and writing as well.

One of the reasons why I’ve spent so many years looking at digital reading was because I felt that many of the ideas from print-based reading have been lost in the transition. We have gotten many of the basics right with our digital reading interfaces. Typography and resolution are much improved, for example. But our apps and devices rarely go beyond those basics and it’s rare to see any meaningful variations in the reading app genre.

My fountain pens and index cards made me realise that note-taking, esp. when you include annotation, shares many of the same problems, both in implementation, the lack of variation from the basics, and the lossy translation from print. Most importantly, they all tend to lack a sense of joy.

Hence, Colophon Cards. It might not end up being revolutionary but hopefully, with enough work, it’ll add some polish to the note-taking app genre.

(Next, what I learned about the various kinds of note-taking from talking to a bunch of people.)


The different kinds of notes
6 May 2022 | 12:56 pm

This is the second entry of three where I go over what I learned from the user research I’ve been doing for Colophon Cards.

The ratty old spiral notebook that is the oldest notebook I own
My oldest notebook

The post where I outline my general theory of notetaking for all to disagree with

At the end of my last post, I mentioned that I had switched to pen and paper notetaking in the early 2010s, after years of serious digital notetaking using plain text files.

I wrote about how much more enjoyable the analogue notetaking was but what I didn’t mention was why I abandoned my plain text system. Nor did I write about my first foray into serious notetaking.

The notebook above, from 1994, is the oldest notebook of mine I’ve found. It’s the first proper notebook I kept. It wasn’t a journal, sketchbook, drafts, or workbook for school. Just notes.

And it petered out pretty quickly. I had forgotten all about it until I found it in a box a few months ago. For a good reason: it was a random mess that I didn’t take seriously.

Notetaking seriousness didn’t come for me until college, which makes sense. College is when I first started to test myself with more structured projects. Essays, theses, and my early blogging, all required a little bit more thought and planning than a teenager’s haphazard writing hobby.

Serious writing required serious notetaking, both in terms of scheduling and structure. For years, I had a strict notetaking system. Each day I made a new text file with the current date as a file name. Each file was filled with whatever notes I needed for whatever I was working on at the time. Every day I wrote something, I crossed it off on the calendar with a black marker. On the days when I didn’t write something, I marked in red.

The goal was to keep the run of black unbroken. It worked. Sort of. This regimented system was based on a random quote from Jerry Seinfeld, of all people, and a misunderstanding on my part of the purpose of Julia Cameron’s Morning Pages from her book The Artist’s Way.

I’d fallen into one of the oldest process trap of all: I had cargo culted methods whose principles, concepts, and motivations I did not understand. I had copied the ritual without understanding the mechanism.

Over time this turned into a slog, _no matter what, write three pages!, and by the time I got to my PhD, it made everything about a bad experience worse.

When I began my PhD in 2001, we were all still recovering from the dot-com crash. It made sense to work on a thesis that was grounded in an evolutionary, small-c conservative, view of media. Not only was web- and new media scepticism abundant at the time, it was very strong in the specific academic environment where I was working. Over the years that I worked on my PhD, that view became untenable to me. Interactive media—the web—was and is fundamentally different from its predecessors, in a way that promised to be completely revolutionary to both culture and society. But I was locked in a reactionary thesis. Starting from scratch would have almost inevitably led to me having to abandon the PhD. This meant that I had to write a thesis I utterly disagreed with, making an argument I didn’t believe in, using references that I felt were borderline nonsense in the context I was pulling them into, and making the words I wrote feel like ash.

The regimented daily pages notetaking routine made everything worse. It turned the writing process into a multi-year death march, filling the folders of my hard drive with unusable nonsense that I didn’t believe in then and don’t believe in now.

I managed to complete and defend my PhD and swore to leave academia behind for the rest of my life.

It took me years to fully recover.

To get there—to recover from my unrelenting thesis death march—I had to get more thoughtful and serious about writing and my notetaking. As is the way of my people (overthinkers, that is), this meant research. Lots and lots of research. On writing. On creativity. On notes and notetaking. On planning. Even research on skills development, the cognitive component in expertise, as well as memory formation. I dug through the entire Cambridge Handbook of Expertise and Expert Performance (over 900 pages). I read fluffy, self-help books on creativity. I read serious studies on the effects stress has on memory formation. I read old books. I read new books. Some of them dated. Some of them timeless. Some worked. Some didn’t.

I also began to understand the mechanism behind Julia Cameron’s morning pages, how it was supposed to work, and what it had in common with other approaches, even the ones that superficially look completely different.

I began to understand, at least for my own purposes, what notetaking was for.

And I think—based on the research I’ve been doing—that I’m not alone.

It’s all about boxes and maps.


The different kinds of notes

I recently interviewed about a dozen people on their notetaking habits. Before that, I had done a survey.

There’s a lot to cover as notes seem to come in an endless variety. Even from a group as small as twelve people you already got more than twelve different kinds of notetaking:

  • Household management (shopping lists, chores, etc.)
  • Task management
  • Mnemonic notes (write to help you remember)
  • Various kinds of annotations
  • Shared work notes (meeting minutes, documentation, etc.)
  • Personal work notes
  • Idea exploration
  • Journalling
  • Scrapbooking (digital and analogue)
  • Research management
  • Outlining
  • Information management (bookmarks and the like)
  • Project management
  • Client management
  • Concept database (save your ideas)
A blackboard. On it I've written 'Notes. Workspace vs DB vs Mnemonic. Idea management. Mnemonic. Revision. Shared work --- wiki. Collaboration. Journaling. Problem solving. Idea exploration. Project Management. Task management. Client management. Research management. Concept databases. Rading. Fragmented context.
The above list in blackboard form

This is not an exhaustive list. The closer you look, the more varieties of notetaking you find, even in such a small group of people.

There’s a temptation there to dig in, get into even more detail, and generally act as if you’ve hit a motherlode, a vein that’s rich and deep and rewarding. Just really get into it, interview dozens or hundreds of people, do study after study and spend years cataloguing all the varieties of notetaking

But that would be a mistake.

When you’re in a domain where increasing the resolution and detail only reveals an escalating amount of previously undiscovered complexity, odds are you are tackling what E.F. Schumacher called a ‘divergent problem’. These problems aren’t technical. They can’t be broken down into parts to solve each part step by step. A problem like this becomes more complex and hard to solve under close analysis, not simpler and easier to solve. The more detail you see, the more conflicting data points you encounter and the harder it gets to reconcile the diversity you’re witnessing with a cohesive mental model.

From A Guide for the Perplexed, page 126:

I have said that to solve a problem is to kill it. There is nothing wrong with “killing” a convergent problem, for it relates to what remains after life, consciousness, and self-awareness have already been eliminated. But can—or should—divergent problems be killed? (The words “final solution” still have a terrible ring in the ears of my generation.)

Divergent problems cannot be killed; they cannot be solved in the sense of establishing a “correct formula”; they can, however, be transcended. A pair of opposites—like freedom and order—are opposites at the level of ordinary life, but they cease to be opposites at the higher level, the really human level, where self-awareness plays its proper role.

So, when I step back, squint a bit, and stare at my blackboard and my notes, it strikes me that most of the notetaking methods the interviewees described are trying to answer at least one of the three following questions:

  1. How do I manage my creativity?
  2. How do I manage my knowledge?
  3. How do I manage my understanding?

Or, more to the point, the notetaking methods are a way for the writer to continuously ask themselves these questions and adjust their tactics as needed. None of the methods are prescriptive or rigid; they are all constantly being adapted.

The job of notes for creativity is to:

  • Generate ideas in a structured way through research and sketching.
  • Preserve those ideas.
  • Explore the ideas until they have gelled into a cohesive plan or solved a problem.

The job of notes for knowledge is to:

  • Extend your memory to help you keep track of useful information (client data, meeting notes, references).
  • Connect that information to your current tasks or projects so that you can find it when you need it.

The job of notes for understanding is to:

  • Break apart, reframe, and contextualise information and ideas so that they become a part of your own thought process.
  • Turn learning into something you can outline in your own words.

In terms of software, that means we have these three broad approaches:

  • Notes for creativity tend to favour loosely structured workspaces. Scrivener and Ulysses probably come the closest, though, in practice, I have doubts that either of them is loosely structured enough.
  • Notes for knowledge favour databases, ‘everything-buckets’ (apps that expect you to store everything in them), and hypertextual ‘link-everything’ note apps.
  • Notes for understanding tend to favour tools that have powerful writing or drawing features (which you favour will depend on your skill set and comfort).

I don’t think you can make software that perfectly serves all three of these kinds of notetaking. Knowledge bases become too rigid to serve as workspaces for creativity. The creative spaces are too loosely structured to work well as knowledge bases. You can integrate writing and drawing tools in either, but that serves notetaking for understanding only up to a point. Most knowledge bases preserve too much detail and context, which gets in the way of reframing and contextualization. And too fully featured writing or drawing tools could make the creativity tools too complex to use.

In the parlance of roleplaying games, these are the three character statistics of your notetaking app, and you only get to assign 15 points between them. You could choose to be average in all three (5, 5, 5, uninteresting). You could choose to dump all of the points in one stat and be just plain bad at the rest, which would simplify the design a bit. Or, you could think of it as a priority list: most important, second important, unimportant (dump stat!).

'The three stats of note app design.' Followed by a table where Creativity, Knowledge, and Understanding run down the side and the numbers 1-10 run along the top. At the bottom: 'You have 15 points!'

(If you aren’t familiar with RPGs, you can think of them as three sliders with a fixed sum of values between themselves. Every time you push a slider above ‘5’, another slider has to go down a corresponding amount.)

How would I divvy up the points for Colophon Cards? What would the Colophon Cards character sheet look like?

At the moment, I’m leaning towards this:

  • Creativity: 7
  • Knowledge: 2 (dump stat!)
  • Understanding: 6
The same image as above except this one has the values coloured in as bars: Creativity: 7, Knowledge: 2, Understanding: 6.

A workspace that:

  1. Favours lightweight and flexible structure over detailed organisation and connections.
  2. Prioritises speed over accuracy when creating and finding notes.
  3. Has better-than-average writing tools.

Now, I’m not going to pretend that I’m basing those priorities on the comparatively little user research I’ve been doing. They instead represent the kind of app I want to use and enjoy. Because it turns out that enjoyment is essential for long-term notetaking. The research helped me clarify what I wanted, give it focus, and place it properly in the larger context. But, ultimately, I want to make an app I enjoy.

Also, it made me drop a bunch of smaller ideas that research revealed to be less likely to work, but that’s honestly a little less interesting. Though possibly a topic for a future blog post.


Boxes and Maps

You don’t have to copy the methods of a German academic with a tendency for the abstruse to take notes

In my relentless daily writing during my PhD, I had missed the point of it. By using a regimented notetaking structure I drove my creativity into the ground, my joy and motivation cratered with it, and burnout inevitably followed.

What I had missed was that the point of these techniques wasn’t to continuously force march forward according to a predetermined master plan. Just writing or getting things done isn’t the purpose, at least not in any of the writing methods I’ve looked at.

And I’ve looked at a few—they all cover some form of notetaking or journaling as a core part of their process:

Umberto Eco’s How to Write a Thesis is a book about writing that contains a fully-formed (and very usable) notetaking system based on index cards. It’s structured so that everything hangs off the Table of Contents or outline. The thesis’s ToC becomes the map you use to structure your notes.

(I wish that I had read Eco’s book before I did my thesis. Alas.)

Anne Lamott’s Bird by Bird describes an ad hoc and improvised system of index cards. She presents it as an almost random process but then proceeds to spend an entire chapter explaining the value of a loosely structured notetaking system. Her notes are more of a box full of unsorted items that prod the work forward and guide it.

A good chunk of David Hewson’s Writing: A User Manual is about how various kinds of notes help you write your book. His method has elements of both the Box and the Map. He recommends plotting and planning in advance, but he also uses an unstructured daily journal and a ‘box’ of notes on characters, concepts, places, and ideas to guide the process.

The Story Grid by Shawn Coyne is pretty much just an excel-based, fiction-oriented version of Eco’s “How to Write a Thesis”. Instead of Eco’s table of contents, the story grid uses a list of scenes. But it’s otherwise a very similar principle: the map guides the project and structures your notes. The map evolves as you go but no matter how much it changes it remains the primary organizing principle.

Brenda Ueland, in her 1938 book If You Want to Write recommends keeping a “slovenly, headlong, impulsive, honest diary”. The way she puts it:

Write every day, or as often as you possibly can, as fast as and as carelessly as you possibly can, without reading it again, anything you happened to have thought, seen or felt the day before.

In her amazing The Creative Habit Twyla Tharp talks about The Box. A literal box. Each project of hers gets a box which is full of items that document the active research and work on that project. It’s filled with objects, notes, files, clippings, toys and just stuff. Some people store things in files. She prefers boxes.

And, last but not least, the idea I had misunderstood so badly years ago, seems so clear today when I reread Julia Cameron’s words in The Artist’s Way:

There is no wrong way to do morning pages. These daily morning meanderings are not meant to be art. Or even writing. I stress that point to reassure the nonwriters working with this book. Writing is simply one of the tools. Pages are meant to be, simply, the act of moving the hand across the page and writing down whatever comes to mind. Nothing is too petty, too silly, too stupid, or too weird to be included.

It’s about re-contextualising your experiences, reading, thoughts, ideas, and goals in words. This serves both as a mnemonic and to increase understanding as the act of reframing it all in words, in black and white, serves to help your mind integrate it. It turns external ideas and information into integrated thoughts that you understand and can act on.

Flipping to the next page, I can also immediately see the one paragraph that later led to all of my notetaking misery:

Morning pages are nonnegotiable. Never skip or skimp on morning pages. Your mood doesn’t matter.

If you ever read her book, ignore this paragraph. Your mood does matter in the long run. Don’t beat yourself up about it. There are other ways to accomplish the same thing without torturing yourself. What’s especially galling is that I clearly didn’t finish reading the book at the time as its entire purpose is to prevent people from making the mistake that I made.

Once you take in these many approaches to writing and study them as wholes, as opposed to just teasing out individual components, you begin to spot a few common threads running through them, among both the Box and Map creators.

The first one is that the difference between the Box and the Map isn’t as great as you think.

Those who favour the Box maintain an evolving internal map of where they are going with the project. The purpose of the items in the box is to both make it easy for you to maintain that internal representation and to give it enough context to adapt it to changing circumstances.

Those who favour the Map instead flip this around. The map is external and evolving and serves to make it easy for you to maintain the context internally so that you can adapt the project to changing circumstances. The goal is the same. The methods are remarkably similar. It’s just a question of which bit is serving as a mnemonic for the other bits.

Evidence boards are a compromise between the two that shows just how little the difference between the two is in actual practice. Depending on how you look at it, the evidence board is either the items of the box pinned to a board or a map that has been loosely transposed over to a wall.

Which general approach you should choose is entirely personal. As the difference is primarily in mnemonic tactics, the optimal approach depends on how your own memory and other cognitive processes work. Some people’s memory is “out of sight, out of mind.' Or, you might find it easy to remember details but have a harder time maintaining a big picture context. Some have an internalised heuristic or rule of thumb for how a project should work, so they only need reminders and bookmarks that they check against their mental rubric. Some have a hard time visualising the final product that is the goal of their project and so need a tactic that keeps them motivated and more observant of the bigger picture. People vary and so must their methods.

The tactic to use depends on how your mind works. Experiment. Try different approaches out. But, once you’ve found your process, trust that the overall process is roughly the same:

Collect

All the things you fancy. Note down ideas and thoughts. Take notes on what you read. Take pictures. Sketch when the whim strikes. Collect what interests you in life using whatever method is the most convenient for you. Anne Lamott uses index cards. Twyla Tharp uses whatever can be collected in her boxes. David Hewson uses a notetaking app (Ulysses, last I heard). Some use pens and notebooks. Whatever you use, remember that these notes are necessarily only an intermediate form. They don’t become understanding or thoughts until you integrate them. You need to be able to review them, and storing them safely is always useful, but, paradoxically, notes aren’t the be all or end all of the notetaking process.

Contextualise

The purpose of the various journalling tactics as well as some of the mapping tactics (like the evidence board) is to get you into the habit of reframing and contextualising your thoughts, your reading, and your ideas. By reframing them in words (or sketches) you integrate them which makes them available to your thinking and decision-making processes. If you don’t integrate what you collect, are just building an ever more intimidating database of opaque words and alien ideas.

An external brain is a brain that can’t drive your thoughts and actions and will just make your work harder.

A daily written journal is a common way to accomplish this integration. But people have also used daily sketches, voice memos (on tape in the olden days), or video diaries. The goal isn’t to preserve or convince but to reframe and understand in your own terms what you’ve experienced, read, and thought. Blogs work great. Twitter might be stretching it because of the character limit. Use whatever works for you.

Rule of thumb: let the contextualisation method match the bones of the project. A writing project benefits from writing tools.

Map

The final part is the map, the bird’s eye picture of where you are, what lies ahead, and where you want to end up. It’ll start off vague, whatever tactic you use. As you work it’ll become clearer, no matter whether you’re maintaining it in your mind, on paper, or in an Excel spreadsheet. The map might end up being an outline, a diagram, a building plan, a list of tasks in Trello, or a list of issues on GitHub. It will change over time, but don’t worry if it doesn’t. It’s important to keep in mind that the map isn’t the end product, just one more tool among many to help you build the end product.

What does this all have to do with a notetaking app?

The first, most obvious conclusion is that there is no one best method. The above meta-framework for notetaking is broad enough to encompass both Zettelkasten and Twyla Tharp’s boxes filled with stuff. If I’m right about notetaking methods being especially sensitive to individual variation in neurocognition, then there will never be one method or one app to rule all of notetaking.

It becomes a question then of deciding on what my own particular take on this software genre might be. And, if you’ve been following my earlier posts, you probably have some idea of the direction I’m taking. At least in broad strokes.

But the meta-framework doesn’t answer one, very important, question. One that people have been tackling since the dawn of humanity.

What happens when you need to collaborate with other people?

Because nobody, not even your lone wolf novelist, truly works alone.

So…

Next: the final entry in the Colophon Cards research blog series, where I write about how collaboration and sharing fit into all of this.


The Colophon Cards User Survey
2 February 2022 | 12:56 pm

A small notebook with the word 'todo' on the front, surrounded by post-its and other notetaking items

I need your help to create a user-friendly web app for note-taking!

Notes, notebooks, stickies—physical or digital—have become a big part of our professional and personal lives.

Whether we’re using Apple’s built-in Notes app, a physical notebook or deck of index cards, or something more involved like Notion or Roam, most of us have tools that we use to make notes—ephemeral or permanent—to help us organise our lives.

I’m Baldur Bjarnason. I’ve been working in web development, digital publishing, and digital reading for over twenty years. I’m working on a prototype for a note-taking web app called Colophon Cards1.

(You can follow my progress on the project over at the Colophon Cards website.)

My Colophon Cards project is an effort to build a note-taking tool that stakes out the otherwise sparsely populated middle ground in the Personal Knowledge Management (PKM) space:

  • As straightforward to use as is sensible
  • A bit more visually oriented than the high-end apps
  • Have the hypertextual or organisational features from the high-end that don’t make the app too complicated to use
  • Have at least basic support for our digital reading needs

To accomplish this, I need your help!

I need to know what you are doing—how you take notes.

Ideally, I would also need to know how some of my in-progress ideas and designs work for you.

The first step towards this is a short survey you can take to help me see the lay of the note-taking land. It should only take you about five minutes to finish. More importantly, it ends with a question where you can volunteer to be a tester for the project.

Which I would find very helpful 🙂.

Feel free to share a link to this post or the survey with anybody you think might be interested in this space.

Colophon Cards: Note-taking User Research


  1. Funded by The Icelandic Centre for Research’s Technology Development Fund ↩︎



More News from this Feed See Full Web Site