Current tools do not support flexible exploration and refactoring of structures as they inevitably evolve
Authored By:: Rob Haisfield
Predefining a system limits our ability to explore alternatives outside the current structure. This cascades into the decisions to be made while in the act of work – what folder to place the note in, what naming conventions to use, what metadata should be added, and on.
When something doesn’t feel like it fits into a pre-existing structure, participants would feel stressed out. This happens frequently while exploring a new domain of knowledge, as people don’t yet know what the most useful schema will be. People also like to change their schemas as their skill with a thought processor increases and they learn more optimal paths.
A simple, practical example:
Imagine you have a template for each book you read, but you want to add additional attributes later. Updating your template is nice, but it doesn’t highlight what’s missing from current files. This creates more work for yourself whenever you want to make an update!
In note writing tools like Obsidian and Athens, adding this new metadata to instances of the template in hindsight is entirely manual. It’s hard to change structure later. In a relational database like Notion or Airtable, the process is a little easier: add a new column to the table and filter or apply conditional formatting for empty fields.
Of course, done correctly, this structure can also enable easier reuse of past thoughts and the sharing of ideas with others. As we’ve discussed, structure is not a bad thing! However, the limitations of predefining structure are worth noting. Choosing not to define consistent attributes, or simply using implicit structure in notes, allows for flexibility in our thought process and preserves optionality. On the downside, this limits our ability for rich querying and flexibility of “views” down the road. Then we have to rely on our calcified memory of attributes to refactor our work.
If we want structure in our notes, our current tools require that we explicitly add it, in the form of names, placement or attributes. Certain sorts of structure are more rigid than others. For example, open ended metadata enabled email to be expanded into new use cases. - > You can add any headers you like. This makes the set of headers an open set, enabling new use-cases to evolve from the bottom-up. Want to record the title, author, and publish date of your books? Add some headers. Want to include a location? Add a header.
Gordon Brander [If headers did not exist, it would be necessary to invent them](https://subconscious.substack.com/p/if-headers-did-not-exist-it-would)
Also, whether there are multiple paths to the data is important. For example, someone using Roam might be more comfortable throwing many types of structure at the wall because they know if one system fails to resurface a note they likely have a fallback. In a file / folder system like Evernote, the folder location of a note matters much more because search is your only fallback if you don’t remember which folder a note was in. For example, someone using Roam might be more comfortable throwing things at the wall because they know if one system fails to resurface something they might have a fallback
For more details on how to enable restructuring in hindsight, see Search as a primitive and Agora, as well as the question How might we allow people to adapt their past system and notes to current needs