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.
This is also important in the efficiency of the graph as well. The larger your graph grows - just as is the case in Notion, Evernote, and other systems - it will begin to slow in responsiveness. Let’s fill it with value instead of cruft!
Another piece of advice would be to avoid page ref "duplication." It only creates {{query}} clutter and unnecessary links. Since Roam's metadata cascades down block trees, one page ref in the tree (however high in the hierarchy) cascades down.
https://twitter.com/calhistorian/status/1352751908176359425?s=20
As the example demonstrates above, If I were to page ref a parent block, that metadata is linked to all children blocks down the branch. (see image)
In the vast majority of cases, if I needed to the additional context to this {{TODO}} - I would just type the Project name without 'refing' it.
I can see in the image that Project 1 is in fact tagged, and the correct block shows up in the query. However, there are instances in which you *would* want to tag in both places.
What if I didn't mention the project (or page of whatever type) in the block AND I have "Path" turned off in the query - I would have to find out what the project (page) this actually refers to.
Yes...yes.... I can see in the query what I am looking for, but this is not always so simple or desirable. One of the killer strategies of improving your efficiency is reducing on-the-fly decision-making as much as possible. So why give yourself more work?
And while I am on the topic of hierarchy and relationships of blocks - don't forget that both the {{table}} and {{kanban}} functions are designed to work with this as well. Tables create relationships via rows, while kanban create relationships via columns
https://twitter.com/calhistorian/status/1355545008300978176?s=20
• • •
Missing some Tweet in this thread? You can try to
force a refresh
