logseq presentation mode

Presentation Mode: filtered views of the graph

I propose a feature I will refer to as “Views”. This will solve specific problems that have been discussed in topics on this forum but in a flexible way. See Separate graphs for work and home? - Questions & Help - Logseq for background.

• Typical user starts off with the typical graph structure and everything at root level as normal:

A new folder is introduced (this is to demonstrate the concept not the final UI)

The user can create a view of their graph by defining a filter query and giving it a name. It then shows up under “views”…

When you click on this query you don’t just see a page with the results of the query, rather it acts more like a node a parent node in the graph and projects all the matching items of the query as nodes in the subgraph i.e like a top level folder. So you can expand it and so your total structure now looks like:

However in this expanded view, the only nodes present are the nodes that satisfy the query for that “view”…

This could be made even more powerful in future, with things like:-

• The ability to publish, export, views.

This would solve the work / personal separation because, or even just situations in which you want to prepare for what can be seen at some presentation, talk or demo:-

• Those that want physical seperation can still use seperate graphs and ignore this feature.
• Alternatively those that want top level folder seperation can have seperate “parent” pages in the hierarcht for work vs personal, and can then define a seperate “View” for “Work” that just queries everything from the “Work” folder. This is less fragile than relying on metadata and only needs to be set up once. When in a work presentation, the user is able to switch to the “Work” view, and this constrains the graph that logseq is displaying in the app and that the current user can work with, until they switch out of this view, to the default view or another. So liss danger of work content being visible during that presentation.
• And for those that are comfortable purely with metadata and queries to distingush work / personal content, can forgo structuring there pages into top level /personal / work folders and can just rely on the metadata in their queries, and still leverage views to switch contexts if desired.

Just because we already have queries , it doesn’t mean that they are the right tool for creating the desired secure views. Filtering , and more generally starting with the whole and then separating it down to parts, presents all kinds of challenges and risks (never-ending global security mess testifies to that). It is not easy to:

• make a composite query work
• guarantee that a working query works exactly as desired
• make it performant for big graphs
• make a small change without breaking the above
• explain that to and educate non-technical users
• make a major update to the application without breaking the above

Should instead go for composition , which is the inverse:

• Start with graphs as separate as possible (even physically separated).
• This is the one-time hard part.
• pick the desired graphs
• optionally arrange them to determine the behavior in case of conflicts

When that is ready, there is minimal distance to also combine graphs from different users .

I’m not sure synchronizing and merging different graphs into one would necessarily be any simpler than queries. Besides, such an approach would require to preemptively structure the different graphs around the views that you want to have, which is something that is likely to change over time and that a user might not know in advance. I don’t think it’s always easy to know which graph a piece of information belongs to, making ideas like quick capture harder to implement in this scenario.

There can be some cases where the queries used might be overly complicated and underperforming, but I feel like it shouldn’t really be that way for easy ones, such as filtering based on a tag or property, which I guess would be the common case.

I think having the common case be well performing and the hard case be slow but possible wouldn’t be bad. But in case that’s too hard, maybe some simpler filtering mechanisms could be put in place, ex. just specifying tags or properties. Although queries “feel” like they should be the right tool for this.

@mentaloid I think both approaches are somewhat complimentary. However with the composite approach, the user has to seperate there content into seperate graphs from the outset, with the eventual use case in mind which cannot always be anticipated in advance. It’s also the case that when they want that contextual view to give some presentation, or talk at some hobby group, it may be that the boundaries of the view, and the boundaries of whats in each graph don’t perfectly align so they have to physically create graphs to model their desired View… sounds nasty. i.e I keep alll my hobby information in a seperate graph and luckily for me I end up talking at a hobby group one day, so I can view just that graph. But then I take up another hobby and some of the content in the graph is relevent for one hobby session, but not another. Do I have to split it our again? What about when there is overlap - i.e at some point I want the freedom to flexibly model what I can see / access, not in terms of an entire graph r composite of graphs, but rather querying the graph / or accross the graphs, so whether thats a single graph (as this feature proposes) or mulltiple (you’ve basically tacked on a complimentary feature but one that doesn’t necessarily preclude the solution for the problem I am suggesting). I have removed the mention of “sharing” from the proposition, because I think that is muddying the waters.

Short version

Are we trying to solve the same problem ? Remember that this discussion begun with the problem of a high-level work-home or public-private separation. I have a few questions:

• impractical?
• difficult to implement?
• Don’t all graphs already group some pages together?
• a specialized virtual container of pages included explicitly with no surprises ever
• the empty set
• the set of every page
• e.g. > instead of <

Long version

I should have guessed that my suggestion would be read from the perspective of what we have today. Let me clarify :

• Problematic performance is merely an indicator of a problematic solution.
• That would be a big leap backwards .
• That would defeat the concept of graph and its benefits.
• They are like libraries of cohesive books (one per Logseq page), within a specific domain of knowledge .
• This can provide enormous leverage .
• That would be very rigid and inflexible .
• Users don’t need to know any particular usage in advance .
• Though they could support meta-pages, if needed.
• With queries .
• With graphs .
• Different graphs don’t need any syncing, only same graphs need.
• We have enough troubles with syncing as it is.
• Each page should belong to a specific graph.
• A page may always be put at a wrong graph and queries cannot prevent mistakes either. The goal is to make the most costly mistakes (those of security ) less easy to commit.
• That would add excessive overhead on every change (among other issues).
• When working with combined graphs, all the functionality of a single graph is still there.
• This is mostly about preventing navigation outside the desired combination.
• They run on every graph in the combination, then the merging applies to the results .
• A graph can be served both by files and by databases. Likewise, a virtual graph can be served both by one and by multiple underlying graphs.

Being inverse to each-other, the two suggestions may seem complimentary , but for me they are not.

• When all you have is queries , everything looks like a problem solvable by a query.
• If a simple problem is not solvable by a simple query, then queries are an inferior solution.
• Separating things should be as simple as putting them in separate containers .
• Mixing everything into a big container and using queries to form virtual containers, may work, but is the wrong tool.
• Working with whole containers is both simpler and faster .
• This is necessary if our house is a mess .
• We still have the feeling that we missed something.
• This works if our house is in order .
• We can easily verify the process.
• The same reason that prevented the clean separation of graphs, will prevent the creation of a straightforward query.
• Which one is more predictable ?
• The extra pages of which one can you afford to ignore ?
• It may be too late when you find out.
• You hardly know if your new fix will cover a future case .
• Simply avoid putting it in a “dangerous” graph.
• Keep adding/removing tags until you are confident enough.
• You cannot forget putting a page somewhere. But you can forget tagging it against some view.
• When that happens, you would wish that you could work with an already smaller graph, instead of facing every single page that you have.
• That could result to the worst of both.
• The fact that one suggestion contributes to sharing graphs among users, doesn’t change its primary target (that of effective content separation ), it is merely a clue that it has the right direction.

Queries are overpowered and yet overrated.

• It is not what queries are made for to begin with.
• But can you afford the remaining ones?
• Even query experts (which are rare) cannot cover every case, unless they have good knowledge of the underlying graph.
• For queries to be either simple or performant , the hard work has already taken place during tagging etc.
• this post is already lengthy
• the point is that the solution doesn’t have to come from within the problem’s limited frame
• Things can get very ugly, especially in bigger graphs.
• don’t need content separation
• could simply dedicate a specific graph to dumping
• Better doesn’t mean more powerful (thus more dangerous), it means more fitting .

What I’m thinking is, check what a block is tagged with, and if the tag matches one of those that should be hidden hide it. You seem to be thinking that this would be harder/more impractical or insecure than putting together a bunch of graphs in memory, and I’m not sure I really understand why. I think we might not be understanding each other here. I feel like loading private data together with public always puts you at risk of showing the wrong thing at the wrong time, depending on the implementation.

I can agree that the full power of simple queries might be too much on this front. Maybe it would be a good idea to limit this to tagging/properties excluding more general queries. I can also agree on the fact that it could be debatable on wheter this should be done at the block or at the page level, also depending on what is more practical/achievable from a development perspective.

I do although think that it would be way more impractical, on the user perspective, to have a bunch of graphs, each one with its own journal, and to have to switch graph for every topic switch the user goes through (which is kind of what I’ve been doing in the past). I understand you want to be able to work with multiple graphs at the UX level, but then I feel like you’d have the same problems you’re thinking of when you talk about a metadata-based solution. In short, when you create a page/journal block in the multigraph, you’d have to pick a graph it belongs to, and you’d need to keep mental track of what graph contains what to avoid showing something you wouldn’t want to be seen. The difference is, if we’re talking about different containers, things can no longer be intersectional: for example, something cannot be both in the “private” graph and in the “psychology” graph, I’d have to pick one and I feel for some things there just wouldn’t be right choices, just wrong compromises.

Would it? I feel like it would be zero work for me. I already tag my pages with the topics they belong to. To have something that is more generally private, I could just type #private at the end.

Besides, a metadata-based approach would work on existing graphs which are often already tagged, while what you’re describing would require splitting a lot knowledge bases, something I already had to do in the past to have published graphs corresponding only to certain topics. I feel like it is kind of absurd that I have to do this by hand or by grepping files, when the metadata about what page belongs to what topic is already there for me.

And, of course, this wouldn’t be the only time such a restructuring would be required. Because it is, you know, a restructuring, so you can say this:

But of course putting certain things in separated graphs would impose a very rigid structure on the information you put in, which is the choice of singular graph it should belong to (even though most things almost always cross topic boundaries, as you’d want to be represented in a tool for interconnected thought).

And yet, what you’re proposing would bind views and structure, inextricably tying the information I put in (ex. my psychological state) with its usage (whether I want to keep it private or not). On the other hand, metadata allows me to just tag something with both #psychology and #private , as well as many other approaches that would fit a specific individual better.

I think it’s good that we agree on this. But then this seems to be contradictory to me:

I think I’m missing something here? This to me feels exactly like folders, an hierarchy of containers. Please let me know if I’m getting this wrong. Besides, my house will always be a mess. I want a tool that embraces that.

I have the same impression, so I’m not going to answer everything.

Certainly. Maybe you read too much into the house-trip example or the word container . To clarify, I’m going to rename containers into graph-sets. Graphs have many restrictions that graph-sets don’t. Compare these two:

• every node (except of the root) belongs to one and only one other node
• Folders need planning .
• Usage needs discipline .
• Deleting, moving or even renaming a folder can easily break things.
• graphs (and graph-sets) don’t belong to any graph-set, they move around as needed
• all combinations of nested graph-sets always produce a single flat graph-set
• The contents of each graph-set don’t affect any other.
• They can be modified, deleted etc. at any time without affecting anything.
• Users don’t need to plan graph-sets for the future, they just put together something that covers their present need.
• Even using two identical graph-sets under a different name would be fine.

Many tools can operate in messy conditions (the real “wrong compromises”), but never in a secure way.

• This is inherently vulnerable to leaking sensitive info.
• Every additional tag is like one more knot that filtering needs to consider.
• At the same time, missing tags affect a lot the quality of tag-based queries.
• they are difficult to maintain
• their noise hides much of their value
• When something is not loaded , it is impossible to leak .
• There are no boundaries .
• No information is tied.
• This is a prerequisite , otherwise the solution is wrong.
• both tagging and picking a target-graph need the same effort
• good for finding info
• bad for protecting info

Thank you for the thorough answer, this clarified a lot. In the end, I think this comes up to a difference in philosophies and I see where you’re coming from.

@mentaloid In terms of the strict boundary / isolation for security purposes - this is exactly why I use two seperate graphs today for personal versus work content and is what I advocated for on the thread I linked.

However for the use case I had in mind with this feature proposal, it was really all about not enforcing that requirement / answer onto the user who isnt after the strict security but more the convenience of a contextualised view perhaps for some adhoc presentation. You’ve asked some questions many of which seem to come down to the “safety” in terms of security around queries versus graphs. For my particular work / personal scenario, my preference is that I want the security guarantees of not accidentally mixing content… but for others it might not be necessary. Keep in mind Work versus Personal is only one case. To someone who owns their own business they might not initially see any case for splitting this into two graphs. There are other cases like for example:-

• Someone who gives Demo to customers who might be asked to share their screen and they want to show that customers contents without for example - work meetings being present.
• Someone giving presentation on a project and want only that projects notes to be visible for the duration.
• Someone giving presentations at hobby groups. They may be part of several different hobby groups, and on Thursdays they just want their “Beer brewing” content to be shown, and Friday’s its “Whisky club” content time. Both areas have some overlapping content.

These people may be comfortable with accepting the tradeoff in terms of risk in security, versus having to prepare and maintain seperate graphs. You would hope they would enact simplfiied query or stucture mechanism to reduce that risk as much as possible. For example perhaps they resort to namespace per customer or something. To me the feature I proposed was the one about a user wanting to eliminate the noise from the UI for a contextualised view of the world, not a hard security feature - as the latter is already there - I can and do already use seperate graphs.

Saying all this, I could imagine support for combining or attaching graphs indirectly enabling this feature but not by eliminating the query aspect:

• User defined a query to filter context for their “contextual view”
• The matching nodes is built into its own graph
• The graph is “attached” as a subgraph and shows up under a “Views” folder.
• Imagine the view now being selectable in the dropdown where you can select what graph you have open.

But… this is pretty much the feature I described, a seperate graph is part of the solution, but its built by an adhoc query that can meet the user where they are and not punish a user who hasnt split their content into graphs from the outset to match a potentially future adhoc requirement, and not require the original content to be maintained any differenly moving forward than it was before. In other words, after the presentation is done, the view could be deleted with no impact.

If the title is changed from promising things that queries cannot do, namely:

• content separation
• graph organization

to instead promise:

• inherently insecure
• the natural application for queries

then I can agree that this is:

• a separate feature
• with useful applications in some scenarios

@mentaloid Agreed, good suggestion. I outsourced the title creation to ChatGPT and having had this discussion I am inclined to agree it’s not the best. Thank you for all of your detailed feedback thus far. I can’t seem to figure out how to change the title! I was thinking of something like “Contextual Views for Presentations” or maybe “Switching to a filtered version of the graph for a presentation” - if anyone is able to adjust the title please do.

A small thought. When it comes to security its sometimes useful not just to think in terms of boundaries (i.e seperate databases, seperate web apps etc), but also there are some boundaries that have their own security model within them. For example, a SAAS web application, will let a user authenticate, and will use a query to work out what roles and permissions that user has. They then may have access to only the parts of the web application which is relevent for their role / permissions (Authorisation). The UI is presenting what’s available to them, based on a query that takes their roles and permissions into account.

• If there was a mistake in this query, a user may well see something that they are not meant to.
• If an admin had assigned the wrong role or permission to the user, same result.

Now, LogSeq doesn’t have its own internal security model, it’s a single user application and the user of the app has full “rights” to all pieces of content, which includes CRUD operations.

If LogSeq did have a security model, there are many ways it could be implemented.

• Seperate User Profiles would take on the role of the different “Contextual Views for presentation”
• Content blocks or pages could have strict metadata relating to the security model feature - i.e The profiles or permissions that the “user” needs in order to peform CRUD operations.

In LogSeq if this feature was enabled it could:-

• have strict UI’s to ensure such content had valid security model attributes reducing a certain class of error such as “typos” in attribute names.
• Assume a “restrictive” rather than “permissive” default policy - i.e any content without appropriate security model metadata would only be accessible under the “root” profile.

This was a thought experiment to think through how such a security model might be implemented and could achieve the same goal, without necessarily introducing seperate graphs… but ultimately at some level its still query based as it’s now able to achieve not just “content hiding” but also preventing accidetnal CRUD operations during that presentation etc, based on the security model, and the queries powering that feature.

Mind the KISS principle.

I value simplicity and this would add complexity to Logseq and make maintenance harder.

This is my solution to the problem to be able to separate work and home. Create 2 separate graphs. I have a “home” graph and a “work” graph. Sometimes they intersect and then I just add a link to the other graph. I have 2 windows open of Logseq which I can easily switch between. I have also added some custom.css to make a distinct color of the left panel to be able at an instance to know which graph I am looking at.

@gh_hy44 The proposed feature wouldn’t add any complexity for you - simply don’t use it if you don’t need it. Your usage would remain just as simple as before.

• Queries, already exist.
• The ability to naviigate a graph of content in the UI already exists.

I don’t see any massive complexity added here, maybe you can elaborate?

I also use seperate contexts for work and home. I am not able to edit my initial opening post, but this wasnt just about that one specific case. If you read above, there are examples where the user wants a contextual view (for example for some presentation) where its impractical to maintain content in seperate graphs from the outset or on an ongoing basis. If you reject the use cases or the proposed solution still then fine, would be good to know:-

• Maybe one should build / prepare a seperate graph manually per presentation? Or is there some way of using a query to do a filtered export of content perhaps in order to build a seperate graph? Think of the person with multiple hobbies who wants to give a presentation at one hobby group on Monday and another on Thursday and hasnt setup two seperate graphs from the outset

I can’t seem to edit the opening post and I wonder if it would be best to close this topic and open a fresh one which attempts to be more refined from the outset, to make this not about content seperation but content hiding as @mentaloid suggested.

Notice that this can partially be implemented manually by using “nested graphs” but it works only on desktop OSs that support symlinks. The point is creating some graphs and then one that contains symlinks to the /pages folders from other graphs. It works if you don’t have pages with the same name in different graph and this can be solved using namespaces and you can also create a “base” graph containing only “meta” pages like the pages for properties that you may want to be in common between all your graphs (again by using symlinks).

It sounds complex but you can setup it in 5 minutes starting from scratch while adapting your existing graph to this may takes some time.

That’s a clever use of symlinks and worth knowing about, thank you for sharing!

I just wanted to add clarification that the concept of composing graphs versus “views” are complimentary but different features.

The graphs bit, helps with providing the raw material / data for a query. The “views” bit, is about flexibility over what is presented from those graphs, whether that be:-

• a single graph or a composite
• whether a composite graph is achieved using symlinks or some other newly introduced feature

When creating a View:-

• This means you may achieve things like: select page foo - (originates from graph A), and page bar (originates from graph B), but filter out everything else.
• You could clone that view adhoc, and modify the query to also include some other page from graph C.
• You can create as many views for your use cases as you like, perhaps including overlapping sets of pages / blocks, or perhaps not, and delete them when done.
• LogSeq solution to improve that situation on the query authoring side slightly is it’s “simple query” experience. Perhaps that will improve over time.

If it was for me, Logseq should expose the results of all the queries as a virtual filesystem, maybe a WebDAV local server since it’s supported by all the three desktop OSs. Maybe let you set each query to be “mounted” as a specific folder. Those virtual files would be available as far as Logseq is running, but to make them available when it is not, it could create folders containing symlinks to pages that are query results.

To solve the problem of pointing to a specific block using a file, at least on Linux one can create a .desktop launcher that open the default text editor at a specified line.

I always wonder how other people plan to get by with just two privacy contexts in the long arc of time, given multiple employers, multiple use cases, each with slightly different security layers and/or resource sharing needs. I would certainly need more contexts than Logseq Instance windows that I can reasonably be expected to open on one device. I’ve said this elsewhere, but in my opinion, Logseq should be a package manager. Each package would be a knowledge graph. Some would require authentication, some would be public, open source knowledge graph packages. Some would be read-only, with a read-write option upon sufficient authentication (or in some cases, upon merge request, in the case of a git repository).

I do not think this is incompatible with @mentaloid ’s view above, though for me, there is a hard requirement that one should be able to insert references and links across graphs. For example, if I have a public computer science graph and six private software engineering employer project-oriented graphs, I should be able to reference the public graph in the the private graphs.

• Linking across anything is easy.
• updating broken links in private graphs
• maintaining backlinks from private graphs into public graphs
• It is the trade-off between security and convenience.

Introduction

• Learning-Oriented Docs
• Problem-Oriented Docs
• Search entry
• Contents Page
• Understanding-Oriented Docs
• Blocks and Pages
• Information-Oriented Docs

This documentation follows the "Grand Unified Theory of Documentation" . Therefore it consists of

• learning-oriented tutorials ,
• problem-oriented how-to guides ,
• understanding-oriented explanations and
• information-oriented references .

How to publish Logseq notes on your website

Logseq allows you to freely publish notes using custom domain or GitHub pages. Using the below steps, you can accomplish that.

Terminology

Publishing notes - roam vs. obsidian vs. logseq, set homepage, set pages public, set custom theme, export graph/notes, previewing linked notes, math equations, viewing graph, searching notes, presenting slides.

Before going ahead, let’s clear up some terminology.

• PKM : Personal knowledge management , collecting information.
• Backlink : Link to the referred resource/note. Mostly you will refer to another note by surrounding them with double square brackets ( [[test]] to link test note)
• Bidirectional linking : if Note A refers to Note B , then Note B has Backlink to Note A . (A <=> B)
• Graph : Shows all the connections between notes. Some apps like Roam Research & Logseq refer to graph as a database (collection of your notes), whereas Obsidian refers to vault as a database.

Roam Research , Obsidian and Logseq provide bidirectional linking between notes and graph views of them.

To use Roam Research, you need to pay monthly/yearly (15$/month at this time of writing), and it allows you to create up to 3 graphs that you can store in their cloud. You can make a graph public to publish your notes. There are other services like Roam Garden which provide a more excellent UI to your notes; this is paid service (7.5$/month).

Obsidian allows you to use any folder to store your notes. All your notes are stored locally, and you can sync with any service like Syncthing , Resilio Sync , Google Drive, Dropbox, Github. Obsidian also released an Obsidian Sync feature (8$/month), where all the notes are encrypted locally with your password and sent to their servers (more secure than Roam Research). They provide an Obsidian Publish service for publishing notes, which costs 16$/month.

With Logseq, you can choose any local folder (can be synced to the cloud) to store notes; for publishing notes, they provide an option to export Graph to HTML pages, and you can deploy this to your server or domain or GitHub pages or IPFS.

Steps to publishing notes using Logseq

Note that you can import notes from Roam Research as JSON and import them to Logseq.

After selecting the folder to store your graph/database, select ... and choose Settings in the right upper corner. Select the Editor tab and disable “Journals”, once done the “Set the default home page” option will be enabled; set this to any name you would like to name your home page. Create a new note/page with the same name.

You can also make this change directly in config.edn file, go to Settings => General tab => select Edit config.edn ,

will open config.edn, search for default-home and set default home page like below

Note : You can get config.edn by using search, keyboard shortcut is Cmd+k or Ctrl+k depending on macOS or windows.

You have two options,

• Publish all notes. For this, go to Settings , select Editor , and enable All pages public when publishing.
• Select what notes you want to publish by selecting Make it public for publishing

To change the default theme, go to Settings => General tab => “Edit custom.css”, here you can add your custom CSS. There are many themes available; refer to this , pick any theme you like, copy the theme custom.css content, and paste in your logseq custom.css.

After having your notes, it’s time to export. Settings => select “Export Graph”, select “Export public pages”, select any folder where you want to store the generated static files from your notes. You can open the index.html in this folder to preview.

Deploying notes

You can deploy the folder containing the generated static files from above to Github pages, Vercel or Netlify . You can also deploy this folder to decentralized network using IPFS, refer this post . Here is a sample graph I deployed, https://logseq.rajashekar.org .

Hovering over links, shows preview of the note.

Below is how math equations will be shown.

Excalidraw drawings are not displayed, but you can copy the diagrams as png and include them.

Logseq supports Org Mode and has some nice font icons - you can refer to this cheatsheet

Clicking on the Graph view will show links between notes. Here is preview of the graph I deployed.

Below is how backlinks are shown.

Pressing Ctrl+k (for Windows) Cmd+k (for macOS) will pop up the search bar, and you can search all your notes.

Last but not least, you can present a page/note as a slide. Click on “Presentation” in page settings, and press f to present in full screen. Below is the demo.

Here is page used to demo. You can try it yourself.

I hope the above gave an idea of how to publish your notes and get all the excellent features of Logseq at no cost.

About Rajashekar Chintalapati

Software Engineer, Learner, Prokopton.

Roam Research: Protect your file uploads

Roam Notes Security

Scripting with ex: non-visual form of vi

Vi Vim Tips Development

How to use Logseq as a dev log for technical notes

The ease with which you can add notes in Logseq makes it the perfect companion to learn throughout the day. See how developer Bryan Jenks uses Logseq to take technical notes and reuse them later.

Are you a developer or learning to code? Bryan Jenks shows within 15 minutes how he uses Logseq to continuously learn new concepts and languages. He shares how he uses the Linked References as an inbox,

The video below starts at 12:56 as the part before is an overview and review of Logseq.

Screenshots from the video

Click an image to see it in full size

How to Set Up an Automated Daily Template in Logseq

Templates are the best way to easily structure and link your notes in Logseq. Not only do templates provide structure, having consistent links means that you can more reliably find your notes using queries. This comes in handy when you want to build systems in Logseq.

There are many different ways Logseqers use templates on their Journals page. Personally, I have a daily template to track habits, have a place to write my morning pages, import calendar events, and have a simple inbox to capture anything else.

In this article, I'll show how to create templates and define a template that's loaded onto your Journals page every day. If you already know how to create templates in Logseq, you can skip the first section and head over to how to set a daily recurring template.

How to set up a Logseq template

Before we get started with the automation part, let's first have a look at setting up a template that you want to appear on the Journals page every day. In case you already have a daily template set up, you can skip this section.

I recommend you pick one page where you store all of your templates (e.g. [[templates]] ). While it's possible to get an overview of all of your templates using a query, collecting all of them on one page makes management a lot easier.

Here are the three steps to set up a template in Logseq:

Step 1: Create a parent block

The best practice is to nest the template blocks underneath a parent block. This will make navigating the [[templates]] page much easier.

When creating the template trigger in the third step, you'll be able to set if you want to make this parent block part of the template or not. Many people who decide to include this parent block in their template often add links to it. This way, all blocks that are part of the template will be tagged with those links when you run the template. Keep this in mind as you structure your daily template.

Step 2: Add the template

Nested underneath the parent block you can add as many template blocks as you like. From a single block to hundreds; Logseq can handle them all.

In the Logseq documentation , you can find all the possibilities of templates. One popular feature are the dynamic variables which let you add date links using natural language (e.g. time or last Friday ).

Step 3: Set the template name

Right-click on the parent block of the template and select the Make template option:

Next, fill in the name of the template. This will be the name that appears in the list when you run the /template command. This name will also be used in the configuration file, so it's best to not include special characters like emojis in the template name.

If you wish to include the parent block in the template, enable the option Including the parent block in the template . However, as we're creating a daily template, the best practice is to have a template with all blocks on the root level (minimum indentation level). In other words: I recommend not enabling this option.

When you're done, click the Submit button. You'll now see metadata added to the parent block:

That's it, you're now all set. You can even choose to not automate the process and just run the /template command manually each day.

How to set a daily recurring template

Have you set up a template you want to use every day? Great! Now let's see how to make it appear on the fresh Journals page you get every day at midnight.

Step 1: Open config.edn

The config.edn file is where your settings are saved. Anytime you change anything in the Logseq settings screen, they are saved to this file. However, config.edn has a few more options than are available via the interface.

To open the configuration file, open the search bar using the Cmd-k (macOS) / Ctrl-k (Windows, Linux) shortcut. Alternatively, click the 🔍 icon in the top menu bar. Now type config.edn , locate the result, and hit Enter :

Another way to open the config.edn file is by opening the settings screen and clicking the Edit config.edn button from the General tab:

Step 2: Define the template

Look for the following lines (probably around 18-19) in the config.edn file:

Next, type the name of the template you want to use between the quotes:

Step 3: Refresh Logseq

For the changes to take effect you need to refresh Logseq. Either use the keyboard shortcut Cmd-r (macOS) / Ctrl-r (Windows, Linux), or click the Refresh option from the menu in the left sidebar:

That's it! You're now all set. Every day at midnight you'll get a new Journals page with the template already populated.

To test if the template works, empty today's Journals page (cut-paste onto another page if it already contains content). If the template does not appear, make you sure the only thing on the page is a single bullet that says Click here to edit... If the bullet has no text, place your cursor in the block, hit Esc and then Backspace or Delete on your keyboard. Now the template should appear within a few seconds. If that's not the case, check if you wrote the template name correctly in config.edn and is wrapped with double-quotes.

Having a daily structure is an excellent way to program your attention, so change the template as you see fit. To do so, you'll only need to head over to the [[templates]] page and change the template. Your new template will show up on the next day's Journals page.

Supercharge your daily template using plugins

Logseq is improving every day thanks to its plugin ecosystem. On the Marketplace (which you can find via the ... > Plugins option in the top menubar), there are several plugins that you can use in combination with a daily template. I'll highlight a few below.

The plugin names link to their respective GitHub pages. But no worries: you can install them in one click from the Marketplace.

Logseq Habit Tracker

Using a few hashtags on your Journals page, you can easily visualize how well you've kept to habits that you set for yourself. Simply add the tags and the habit you want to track to your daily Journal, and use the plugin to see how you're doing.

Logseq Property Visualizer

If you add page properties to the first block of your Journals pages, you can visualize them using the Logseq Property Visualizer plugin. Personally, I use this instead to track habits, as I try to hit specific numbers every day (workouts, minutes of foreign language input, words written, etc.).

Logseq SmartBlocks

If you notice that you often don't use (tagged) blocks in your daily Journals template, consider replacing them with SmartBlocks buttons. Much like Roam SmartBlocks , this plugin lets you create buttons to trigger templates. If you chop up your daily template into smaller templates and add trigger buttons to your main daily template, you can reduce noise by a lot. It'll also prevent having empty but linked blocks lingering on your old Journals pages.

Logseq Full House Templates

If you need to use more complex logic for your Daily Journal templates, you can use the Full House Templates plugin. This plugin allows you to involve the JavaScript environment and any Logseq context information to create a template that suits your needs. For example, you can add a navigation header to switch between days, include a monthly review task (but only on the last day of the month), or enhance your journal with stylish views of what you're currently reading.

You can find an example of how to set up a daily journal template with the Full House Templates plugin here.

Even if you are not familiar with programming, you can still set up ready-made templates from the Showroom .

Ideas on how to make this process better?

Do you see ways to make the daily Journals template even better, or do you know of useful new plugins? Send us a message and help improve this article.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

The Focus Mode plugin for Logseq allows you to quickly switch into a distraction-free "zen" mode by toggling into full-screen and hiding elements like the sidebar or properties section.

sethfair/logseq-focus-mode

Folders and files, repository files navigation.

Settings -> Plugin Settings -> Focus Mode

⚠️ REQUIRED: You must configure the focus plugin before using it by clicking on the options you want to change, otherwise nothing will be affected.

MIT License

Releases 19

Contributors 4.

• JavaScript 97.0%