I’ve been using Logseq for 3 months, and weaned myself off Evernote!
I have separate graphs for work and home, because if I ever share my Logseq screen while writing content, I don’t want any references to home topics popping up.
Also sometimes I’d like to have access to all graphs without switching, but somtimes I want to focus in on “work” or “home” or some other namespace without the clutter of all the other references.
Ideally I’d just use one graph.
Is there a way to set and clear a filter in the GUI perhaps with namespaces? So that all popup references and “recents” are then restricted to subsets of that namespace?
How do others operate home and work content?
4 Likes
I think I’ve been using Logseq for about 3 months now as well. Though I’ve really only been using it consistently in a determinate fashion for the last 3-4 weeks.
I personally haven’t used multiple graphs on one system but what you describe sounds pretty neat. I just have one graph on my work computer for work related stuff and one graph on my personal computers for my personal stuff.
Never mix work and play. 
1 Like
Thanks for the reply. I just run logseq on my personal laptop, ipad, and iphone - not allowed on the work pc.
Multiple graphs does work, but hangs for a couple of minutes as you change from one to the other because of icloud. I’d still like to be able to do everything in one graph and filter the views.
Anyone else solved this a different way?
1 Like
Proposal for Improved Folder Structure in Logseq
Hello fellow Logseq users!
Having delved into Logseq for the past 3 months and successfully transitioning from Evernote, I’ve thoroughly enjoyed the versatility this platform offers. However, I’ve encountered a common issue that might resonate with many: managing the divide between work and personal content within Logseq.
Considering the original problem where users want to:
- Prevent home topics from popping up during work-related tasks.
- Access all graphs without switching.
- Focus on specific namespaces like “work” or “home” without distractions from other references.
-
Proposed Solution:
I’m proposing an idea that involves re-structuring the folder organization. What if we adopt a two top-level folder system: “Work” and “Home”? Here’s a detailed breakdown:
- Logseq
- Work
- assets
- journals
- logseq
- pages
- whiteboards
- Home
- assets
- journals
- logseq
- pages
- whiteboards
By structuring our content in this manner, it provided me with a clear distinction between work and personal content.
Validation
I have tried 2 things here to validate that it works:
- write something in both journal pages in the two different folders and see if i could access it in the other folder/journals/“date” → I could not
- create a new link / reference in one journal page in the two different folders and see if I could access it in the other journal page → I could not
Seeking Feedback:
While I believe this could be a feasible solution, I’d love to hear from the community.
* What do you think of this proposal?
* Are there any potential drawbacks or arguments against adopting this folder structure
* Every feedback, be it in support or against, would be immensely helpful in refining this idea. Let’s discuss and enhance our Logseq experience together!
Warm regards and I hope you find it helpful
1 Like
I am currently using two graphs.
I can switch between the graphs in the app.
This works for me except for when I accidentally type a load of content in the wrong one. In this case I’d like the abillity to quickly “send” a block from one graph to another.
In short, I think modelling this as seperate graphs seems the right approach to me to keep that clear distinction and boundary, however if this is the solution then having some functions in the app to better deal with “transferring” content between graphs becomes needed.
1 Like
I think 'separate graphs ’ is still frequently asked topic, you may find lots request and discussion if search in the forum.
And to me, I still thought simply and purely that multiple instance (not multiple window) is a direct way for even a new user, though I already realized that develop team doesn’t consider multi instance from beginning(consider there might be conflicts to access multiple graphs simultaneously, something like that.)
So I am wondering if there’s a simple way to call/start multiple Logseq.exe, I will use it personally and take the possible risk myself.
Just a pity that there’s no further feedback from others in the @sokrates posts.
Perhaps some time later there will be better solution or suggestion from someone also need to use multiple graphs/dBs.
I think some kind of boundary between public and private would be very good, however I think it might be even better to create a mechanism that allows for certain parts of the graph to be hidden at certain moments.
As an example, I usually put my private personal thoughts under a block tagged #interstitial in my journal. Since the graph I’m working on also contains a lot of what might be interesting technical notes, I’d like to publish it via GitHub - logseq/publish-spa: A github action and CLI to publish logseq graphs as a SPA app
To be able to do that, I have some choices:
- resort to some kind of file system manipulation, or create a new graph dedicated to the notes I want to export
- mark the pages I want to publish using
public:: true.
Either of those choices isn’t perfect. Filesystem manipulation requires me to completely forego the abstraction created by the application, and manually copy the pages that I’m interested in a separate folder, which can be very labourious if the notes are many and it is a job that might need to be repeated in case of updates.
Marking the pages using public:: true is an improvement, but it requires me to explicitly think of every page as “public” or “private”, and to put the boundary on this distinction on the single graph. What I mean is, I might have notes about different topics in my graph, and maybe I want to publish the notes about one topic to a website and the notes about some other topic to a different website.
In general, to me all these problems seem solvable using a different, better strategy, which is using a filter. You type in a query that matches the pages you’re interested in, and you get to hide them, for example. So in a work context I could hide all my private diaries creating a filter for everything tagged #interstitial. At the same time, I would have a mechanism that allows me to ask the application to publish only the pages I want without marking them explicitly public (for example, publish all the pages tagged #anthropology).
This would also mean better exploiting the metadata structure of the graph for the task and to avoid relying on the filesystem, which seems particularly relevant since a database version is scheduled to come out.
The issues I see with purely a metadata based approach for work / personal separation are things like:-
- It’s easy to miss some metadata, or make a query mistake, and suddenly you’ve got some personal content showing in your work presentation, or a work related meeting showing in your personal calendar or something.
For this reason, I think the boundary of separation needs to be more spacial / structural in nature for those uncomfortable with metadata and query accuracy being the sole arbitor, so this would manifest in something like as proposed above by SdnRhr42 with seperate “folders” for work versus personal. However… I can think of a system that could be good enough to accomodate both styles and potentially more cases like as a mechanism to “share” sections of your graph with others.
- Typical user starts off with the graph and everything at root level as normal:
- Logseq
- assets
- journals
- logseq
- pages
- whiteboards
A new folder is introduced (this is to demonstrate the concept not the final UI)
- views
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”…
- views
- My work stuff (this is expandable)
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 loooks like:
- Logseq
- assets
- journals
- logseq
- pages
- whiteboards
- views
- My work stuff
- assets
- journals
- logseq
- pages
- whiteboards
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, or share views (read only) i.e so team members can “import” your shared view into their graph in order to have read only access to that content, or potentially in future, there could be colloboration features around that.
This would solve the work / personal seperation because:-
- 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 personal content shouldn’t be 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.
1 Like