Ok. It has been suggested that I share my experiments. I have attempted to recreate my ZK in Notion and Obsidian, and in a few others. The purpose is to truly understand how tool affordances and constraints shape a workflow. #obsidianmd#pkmloom.com/share/27e62177…
As I mentioned above I wanted to demonstrate how a graph view is in fact functional and valuable, IF the features are there to support it. So I just did a quick conceptual update on how to deal with note sequences in an Obsidian zettelkasten. loom.com/share/3862f712…
#AdviceFromARoman Continuing the "advice" column that I started some time back regarding how to best utilize @RoamResearch for your knowledge graph. The TL:DR, every block or block-tree should have three elements associated with it. An ENTITY, a TYPE, and of course its CONTENT.
What do I mean? Fundamentally, Roam "search" is a very different paradigm than other consumer writing/notes applications. Well, I am not going to explain how Roam works behind referring to my prior advice tweets about tag/page ref inheritance.
Importantly though, exploiting Roam's search workflow requires you to recognize that the power is in page refs (and "tags"). But because Roam is so flexible to the point of being agnostic in this regard, one must build with search and discoverability in mind.
A word of advice #Roamans. One of the great virtues of @RoamResearch is its flexibility and efficiency in capturing the chaos of life. Yet one of its largest hinderances to its success as a tool is its users’ behavior. There are several ways that we might better manage our graph.
One such way is to avoid page ref clutter. Two strategies. First, if you use templates (particularly daily), and you don’t end up capturing anything under a page ref - **delete it** - it will only clutter your graph, query results, and contribute to page bloat.
Similarly, if you use {{queries}} on your daily page - **delete** them as a shut-down routine. They are pointless beyond the day at which you use them. Or, as I have done, create a dashboard page containing the desired queries and use #roam42 SmartBlocks to dynamically update.
#RoamCult For new users who are like, "why is building a table or Kanban board so odd?" They are designed to take advantage of @RoamResearch's hierarchical relationships. Cells in a table row and Cards in a Kanban column are related. Use that to your advantage.
For example. Take a table. You can query for example for any value {a, b, c, d} in relation to "Item 1" since they are in the same hierarchy.
Similarly, for a Kanban Board - though constructing one is different {a, b, c, d} are still related to "Item 1." HOWEVER, as an advantage, in a Kanban board, block "a" is NOT related to block "b" outside of that fact that they share a parent.
#RoamCult if you ever thought Roam could not be used for a Weekly Review GTD style, it just requires Roamafying the workflow. Most data is removed or collapsed for privacy. Though #roam42 (@roamhacker) SmartBlocks are required. Doing this manually every week would be too much
This was just me finalizing from my old Weekly Review model: