Helping a beginner understand Logseq

Logseq can work as a research-and-publication workspace if notes are organized around “projects” and “questions,” then connected to the people who can answer them—using indentation, tags, and filters rather than folders. A practical workflow emerges: create a project page (e.g., “basic income grant”), add a “questions” section under it, and link each question to a “people to speak to” block. Over time, those questions can expand into fuller answers, turning scattered reading into a structured knowledge base that’s easy to revisit.

The session also challenges a common beginner instinct: splitting everything into separate graphs. One approach keeps everything in a single graph so information can be resurfaced across contexts through keyword search and tag-based queries. That matters because a single question often connects multiple domains—economic policy, social housing, and related institutions—so filtering a unified graph can reveal cross-cutting relationships. The tradeoff is psychological as much as technical: a large one-graph setup can feel overwhelming, and it may not “prompt” the right queries organically. Still, the workflow leans on Logseq’s ability to filter by tags like “questions,” “social housing,” or “basic income grants,” effectively recreating the same view you’d get from a more compartmentalized system.

Indentation is treated as more than formatting—it’s a way to encode meaning. When a question is nested under parent blocks (for example, “questions” → “iej” → “social housing”), the nested structure becomes inheritable context. That means the same question can be found and filtered later even if it was created in a stream-of-consciousness way. The session demonstrates that tags and indentation work together: tags act like cross-references, while indentation preserves the local hierarchy that makes retrieval intuitive.

The notes also cover how to build navigation inside Logseq. A “table of contents” can be created without heavy linking by using chapter-like pages or sections that can be collapsed during active work, then jumped to later via graph view. For content production, that navigation becomes a practical memory aid—especially when research and video-making happen weeks apart. Checklists and “how-to” pages (like a repeatable process for highlighting animations) are positioned as reusable references that reduce the need to rediscover steps.

Finally, the session introduces two ways to model “projects.” One uses metadata-style titles (e.g., “type:: project”) so project pages appear as nodes and can be queried like an index. Another uses title namespaces (hierarchical prefixes in titles) to group projects into a visible structure in graph view. The overall takeaway is less about finding a single correct system and more about iterating on workflows: start with one graph, tighten indentation and tagging, then adjust structure over a few weeks as new questions appear. The goal is a system that supports both research publication and the day-to-day mechanics of returning to work months later.