PKM #3: Competing Goals

Continuing my series on spitballing in public on personal knowledge management systems that I started a year ago. Here’s what’s new.

One thing that’s been troubling me when it comes to developing a decent PKM is the problem of competing goals. It’s also the main reason (other than time) that I haven’t been able to make much progress on this front: I’m seeking a perfect solution that addresses all of the competing goals in an elegant way. First, finding a perfect solution is unlikely, given the difficulty of resolving all of the constraints and competing goals; second, it’s even more unlikely that I’ll be able to find a solution in a vacuum — that is, without trying things out, putting them into production, and seeing how they turn out in practice and tweak from there. (Whoops, did I say that in my very first post more than one year ago? Yes, yes I did.)

Designing products is basically a complicated constraint satisfaction problem, and that’s especially the case for something as complex as a system that manages knowledge. The first step is denial, errr, enumerating the competing goals.

Possibly competing goals

1. A logical but flexible organization system. Content should be able to be organized in a flexible way that somehow combines the best of tag-based/graph-based organization and folder-based categorization.
2. Support for both wiki-type ‘notes’/‘articles’ and Simplenote-like ‘snippets’. Almost all note-taking apps seem to focus on one type of note entity, and all notes have the same priority and use the same categorization system. However, there are really two types of notes: those that I organize and structure, and those that are just snippets that I jot down, or notes from books, or that sort of thing. An ideal PKM would excel both at wiki-abilities and snippet-abilities. (Another set of terminology for this, from PKM #2, is documents and notes).
3. Everything is a note. The idea behind this ideal is that everything is a note, even those that look like “folders” — those are just notes with sub-notes under them. This allows for “folders” to have content of their own; for example, a folder that contains information about a particular project can have content that details the current status of the project and anything that needs to be kept top-of-mind.
4. Only one organization system. This ideal stems from not wanting to have to over-categorize things; this means that having a categorization system plus a tagging system, like Evernote does, is not ideal since it makes us not rely on one definitive organization system but makes us have to hold two organization models (categorization and tagging) in mind. Ideally, we wouldn’t have to do that.
5. Matches how the brain stores and processes information. The perfect system could be a direct mirror of how the brain is storing information. In rough terms, the best approximation we have is that memory is relational.
6. Clean and organized. We’d ideally have a clean and organized system that is free of cruft.

Problems

Goal #1, a logical but flexible organization system, by itself seems to be a contradiction. If tags are separate from categories, then it can work similar to Evernote where notebooks and tags are totally different things, but can be used interchangeably. But if we try to jimmy a categorization system built on top of tags, that might lead to conflict — like, what if a tag is used in multiple places?

Of course, if we separate categorization and tagging — say, if I had a note about design ideas that I categorize under a project and also tag as “design” — that’s in conflict with Goal #4, where we don’t want to duplicate our work with organizing stuff and have to hold two organization models in mind.

If we use categories similar to tags, and allow a note to be categorized into multiple categories (as Dan reminded me about earlier today), then we’d have to have some sort of affordance to make sure people know that updating a note updates it in multiple places. And what happens if we try to rename a note in one place — should that new name propagate to the other copies of that note?

Another conflict: we want to keep this system clean and organized, but we also want to allow notes to connect to other notes. But this necessarily creates a more complex network of items than just having categories or notebooks like Evernote. And if one part of the graph has different naming conventions and such than another part, that makes it hard to keep things clean and organized.

Finally, trying to build something that matches the brain’s memory structure probably will be difficult, especially if it’s the case that the tools that we have today, i.e. mobile phones, computers, browsers, etc., can’t sufficiently interface with such a structure. For example, if memory is really relational and memories are made via connection to other memories, inputting memories through a touchscreen or keyboard and then trying to manually connect it to other memories is likely impractical.

Finding a solution that seems to fit all of these might be difficult. One approach might be to figure out what the best-in-class is for each goal, instead of trying to integrate them all from the beginning, and then see how we can integrate things. What I’ve started with is to try to drop the requirement to match the brain’s memory processes, and try to just build a pretty good PKM see how we can iterate closer to something that matches the brain.

Iteration

There are a few interesting structural decisions that this mockup reflects that I think have been a distillation of some thinking since I started this PKM series more than a year ago:

• Documents and snippets coexisting. Documents are the wiki-like articles that are ‘organized’ notes: they’re meant to serve as documents that you reference and edit. On the other hand, snippets can be offhand notes, commonplace book entries, or really just anything that doesn’t need to be a document. These are the kind of things you put into Apple Notes or Simplenote or on a Post-It Note. In this iteration, we can see that snippets can exist inside categories, which I think is pretty useful; one can also build up a commonplace book using this by tossing snippets under a category named for a book.
• Implementation of a dual categories/tag system. The main organization system here are categories, and each item can also have tags associated with it.
• Document replication across categories. To the left of the tag for “Design ideas” is an indicator that says that a document is being replicated in another category. This addresses a key issue I came across in PKM #1, and doesn’t really even require a tagging system:

“But my initial feeling: categorization systems are already showing its foibles. I wanted to add meeting notes for a dinner I had the other day with two people — but a categorization system would make me choose between adding that note to one person or the other. A tagging system would allow me to tag it to two people.”

• Everything is a note. Here, the category is “PKM”, but we can also add content to this category, in essence making it a note with sub-notes under it. Finding a way to display sub-notes may be a difficult design task.
• Two-level categorization view. I’ve been struggling with figuring out how to best allow for traversal between categories; this was one of the things I played around with in the mockups for PKM #2. The things I focused on were non-clunkiness, ability to deterministically know where to click to get back to a previous level (as opposed to it changing all the time), easy switching between sibling levels, and some others that I don’t remember. I think this is a particularly good one, since it allows for traversal to the enclosing folder, and also across siblings in the folder (which can also be done with keyboard shortcuts) and is less clunky than a regular folder drilldown.

Other thoughts

• For the most flexibility and ability to cover different sorts of information, it would be best if a system wasn’t too opinionated and could support a variety of different views. For example, the mockup above could be the default, but there should be options to browse in a way that’s more like, say, a Finder window, or more like a graph, or something of that sort.
• One key difficulty is representing a graph as a categorical system. We could maybe get closer to this by talking about notes/documents as nodes and sub-notes as the nodes that a given node points to. This makes sense from a graph perspective, though it may be unorthodox to have a directed graph system (where if A points to B, B doesn’t necessarily point to A), especially from a UI/UX perspective. Maybe some clever design could solve this problem and make connecting items to other items a bit easier.
• I’m still thinking there needs to be an ‘inbox’ of some sort for snippets, so that they can be added to the hierarchy in the future, or archived. I don’t like the idea of an inbox, though, and I think it will feel like work. So maybe a stream of most recent snippets is the right idea. I also really like the idea of “archiving” snippets from the recent view like how Google Keep does it, but I don’t know how that will play out in the hierarchy. Will ‘archived’ snippets be hidden from the hierarchy, or will that only happen when they are trashed?
• I really like newcomer iPhone notes app Better. Its clean interface and its simple way to add a hashtag are stellar, and it’s just a joy to use. Wish it had sync.
• Notion.so is an absolutely stellar wiki/knowledge base product, though its organization features are a bit difficult to use and it doesn’t really support quick note-taking.
• A commonplace book has been the main use case consideration for me for snippets: a place where you can store snippets of books that you find important. (OCR applied to this would also help for search; metadata would as well.)

A home screen concept. Top-of-mind elements can be accessed readily, but so can the hierarchy.

A concept for individual pages. It would be nice to have a way to have sub-pages either shown below the page or to the side of it, depending on what kind of ‘gravity’ the page and its connections should have. (If the page is just a page to store information or metadata about a project, it should go above and the standard browse UI should appear; if the page is a regular page, then the importance of sub-pages is lessened.)

Concept for adding a new item. We want a simple way to attach new pages to existing ‘folders’ when creating a new document without having to do the whole drill-down process, so auto-matching based on previous pages seems to be the right idea.