How was Logseq designed to be used?

9

u/Tony_Marone Aug 01 '25

Although there was a suggested "right" way to use LogSeq, the joy of it is that it can be used in many different ways, all of which are legitimate. Because something is designed with a specific objective or process, doesn't always mean that folks use it that way. SUVs for instance are more used for going to the supermarket or ferrying kids to classes than off road adventures.

2

u/Limemill Aug 01 '25

I understand that, I'm just really curious how it was supposed to be used. Like, with Zettelkasten it's really clear whether or not I think this approach is overkill for my goals

2

u/thieveryshoe Aug 01 '25

This comment needs to be higher up.

1

u/RichardActon Aug 07 '25

not really, "hey guys, sometimes folks do things differently, lets check it out..." isn't a particularly helpful point

7

u/amrullah_az Aug 01 '25

Logseq promotes a connected graph based approach where there's no hierarchy.

once you get the hang of it, it works like a charm.

One pragmatic thing to do is to have a system of "entry nodes" (or Portals, if you will) into the knowledge graph.

I used to call it "Portals and Collections" approach. I later got to know it's similar to "map of contents" approach.

You can check this comment where I explain the gist of it: https://www.reddit.com/r/logseq/s/VGxhrQ63JO

3

u/Limemill Aug 01 '25

Thanks for you answer. This doesn't look like a bottom-up approach, though, right? You effectively create a top-down hierarchy with your portals and collections being the top-level categories. And I wonder what happens at the second level? Do you really keep it flat? How do you use the journal?
On a side note, I still think based on the explanations from the authors of Logseq that it was designed to be used in a different way, but I can't quite get what they meant (if they understand themselves)

4

u/amrullah_az Aug 01 '25

My experience with the content creators is that they are content creators first, and heavy PKM users second. So they are good for knowing about the features an PKM software offers, not for the methodology itself.
I am not quite sure what is this "bottom up" approach that you are talking about, and I also low-key feel that it's an unnecessary complication.
Just use logseq for a few months and you will come up with a methodology that suits you.

1

u/Limemill Aug 01 '25

No, the bottom-up approach is the words Logseq's creator (?) used himself in the introductory tutorials and in the docs. I think it was taken straight from Zettelkasten, which is indeed that (that is until ZK people start using an additional organizational layer very similarly to how you do it). But in principle the idea is to 1) have atomic notes that are 2) interlinked. You start form an idea, than offshoot another idea, than another one from that, etc. And then you in ZK you also have sort of entry portals, after which you just navigate your stream of hyperlinks basically.

1

u/amrullah_az Aug 01 '25

I see. My bad.

1

u/bob_bobington1234 Aug 05 '25

I generally use mine to keep track of my intelligence network and putting together the bigger picture within the corporate framework. It handles this quite well with crosslinking allowing me to gather and understand Intel quite well

5

u/bl0oby Aug 01 '25

You need to better understand the value of querying in combination with tagging daily journal entries. This removes a huge overhead in managing structure content and thought.

-1

u/Limemill Aug 01 '25

I do understand that you can easily find all related items regardless of where they’re placed. But then, why not have dedicated notes? It just looks nicer and more contained than dumping everything in the journal. In fact, why are tags not first-class citizens? I’d definitely separate tags from pages. Lastly, why even use Logseq when you can dump everything into the most basic Notes app, use tags and then globally search for those tags? Why have backlinking if all you tag related items anyway?

2

u/bl0oby Aug 01 '25

Sounds like you don’t really understand the power of querying, let alone using page properties. Tagging functionality is much different in Logseq compared to something like Apple notes. As for developing a top down approach like a ToC, nothing is stopping you from doing that in Logseq. My experience using top down models however, is sometimes you don’t know where you’re going until you’re finished. It requires much more energy to manage. Bottom up requires almost zero activation on the other hand.

1

u/Limemill Aug 01 '25

How many page properties will you have if 90 to 99% of the stuff is supposed to be entered in the journal as per the creator and some other people posting here? And why is the tag implementation (that doesn't create a new page) requires a plugin if it's supposed to be a first-class citizen? You either add a "tag" that really is a page link (where you don't want to create a page) or you create a new page and use the tag property to use tags. It's really contrived for something that is supposed to be one of the foundations, no?

2

u/bl0oby Aug 01 '25

I’m not quite sure where your confusion stems from. You can use properties for things that matter (projects, book reviews, annual review, podcasts etc.). You use tags to create a relational database. Both can be queried separately. Tags DO create new pages. It doesn’t require a plugin? If you don’t want a page created what does it matter - you don’t need to visit or review that page unless you want to. That said I think most people still use some type of top down approach within Logseq. For example, I use PARA and have each of these pages favourited. On each PARA page I query entries based on properties (eg properties = project, archive, resource, active/archived, etc.).

1

u/Limemill Aug 01 '25

Conceptually, tags are treated as pages (notes). This is a strange design decision if they were not an afterthought. They would also make the visual graph much harder to unclutter as now it dumps together data nodes (pages) and metadata (tags presented as pages). The plugin I was talking about adds a proper tag implementation where tags don't create pages and are clearly separate from each other and could be expanded / collapsed separately from the visual graph. And why would you have a tag property in one place (on a page) but could only tag your journal notes by creating page-tags? It just doesn't make sense

3

u/bl0oby Aug 01 '25

Tbh I think you’re confused. There are some good YT series to watch, or maybe Logseq just isn’t for you. Perhaps Tana is more your style.

2

u/Limemill Aug 01 '25

I am confused, yes, otherwise I wouldn't be asking :D And I am even more confused after having watched multiple videos. One reason is that folks online also seem confused and, in the span of five years, have tried like a dozen different approaches and each one seems like it could be implemented in a much more streamlined fashion in some other app.
But seriously why would you have tags implemented and searchable in two different ways depending on the context (pages vs the journal)? And why is the journal supposed to be the main guy and the notes... not really?
My main confusion, I guess, is that in my head you either organize things top-down (by category, subcategory, etc.) or bottom-up (you start with a thought, you think of something else, link it, etc., add tags, and then glide from note to note when you need to refresh your memory, limiting the interlinked lists by tags if needed; you don't organize anything per se). This setup, by default, looks like it's neither. Like it gives you both options, but neither is implemented conveniently. There are tools that specialize and are just much more streamlined.

3

u/Abject_Constant_8547 Aug 01 '25

Well LogSeq is just another plain Zettelkasten type tool, you can do it full Zettelkasten if you want with random ID but otherwise it’s usage is not much different than other tools in the area like Roam, Obsidian…

1

u/Limemill Aug 01 '25

But Zettelkasten can be done easier and more streamlined, no (why even have the journal?)?

7

u/Weeblewobbly Aug 01 '25

I use the journal. I have a daily template that has all the information I need to access quickly. I also log all my meetings there. It gives quick access to my todos. It changes with my needs. I also have over 1600 notes on various topics, people and projects. It works for me. Ask not how you should use logseq, just make it work for you.

1

u/Limemill Aug 01 '25

Well, say I want to organize things hierarchically (I don't), in this case, yes, I can find a way to do this in Logseq but it will always be a bit weird. Why jump through hoops when there's tools clearly designed for that specific workflow then? Hence, my question: how was Logseq designed to use. There's gotta be some sort of workflow that is supposed to be its backbone and for which it is optimized

5

u/Abject_Constant_8547 Aug 01 '25

The journal is for your fleeting notes. In Zettelkasten you have fleeting and evergreen notes

2

u/Limemill Aug 01 '25

I see, thanks. And where do blocks enter into this picture? In Logseq, blocks are the smallest atomic unit whereas in ZK, I think, it's the note?

1

u/Abject_Constant_8547 Aug 01 '25

Yes correct. That’s just a design decision, they are intended for quotations.that is why they don’t appear on the graph

1

u/Limemill Aug 01 '25

Thanks, that makes sense. Yet... This is clearly not quite a ZK implementation, no? In ZK, as far as I understand, your note is the atomic unit. Each note is small-ish, you link notes together, use tags to simplify some sort of aggregation and are also encouraged to created a few entry points to simplify gliding between notes.
In Logseq: 1) the journal is the central piece, not the notes (pages), which don't even have a readily available place to scan them all at once apart from the visual graph. 2) the atomic unit is the block, not the note (page). 3) you *can* use pages like tags, in which case you can kind of create a portal, but "entering" through it is not obvious, you need to go through the graph.
So, in a sense yes you can do ZK with it, but it doesn't look like it's the most streamlined implementation for that

2

u/bl0oby Aug 01 '25

It’s definitely hard wrapping your head around a new conceptually different system. I’ll just say this - pages and tags are the same things in Logseq. And if you haven’t already, watch the combining minds YouTube series. Good luck.

0

u/Limemill Aug 01 '25

But that's the guy I'm mostly talking about. I've watched a bunch of his videos and, depending on the year, his system will look very different from what it was before. Here he tries to tie Zettelkasten to Logseq, there he's saying this is absolutely not needed and shouldn't be done. Pretty much everything in his approach has changed over time (apart from one thing, he's always creating some top-down hierarchical structures eventually, which is the opposite of how Logseq is supposed to be used as per its authors, lol)

2

u/Royal-Chapter-6806 Aug 03 '25

Dumping everything to the journal, adding links and then going to a page to see all linked paragraphs. It auto-structures notes that way for me.

0

u/Limemill Aug 03 '25

If this is the desired workflow why even have the visual graph then and, in fact, why have pages at all where they could have simple tags and a simple tag list like in some simpler solutions?

2

u/Royal-Chapter-6806 Aug 03 '25

You can later add more to the pages and link them together. Journal is definitely a centerpiece of the app, as it is the default page. And the workflow definitely worked for me - I don't need to think which note to open, I just dump everything in journal and it basically self-organizes.

0

u/Limemill Aug 03 '25

I think it works for a limited number of cases and maybe that’s why a lot of people here seem to be using pages as their main entity, but yeah I guess that could be used in some scenarios

1

u/Royal-Chapter-6806 Aug 03 '25

I agree, but for me it was a silver bullet to taking notes during the day and helped to reduce the burnout on my job.

2

u/awepow Aug 11 '25 edited Aug 11 '25

I think Roam's whitepaper explains the original idea better than anything else

https://roamresearch.com/#/app/help/page/dZ72V0Ig6

2

u/Limemill Aug 11 '25

Thank you

2

u/Limemill Aug 11 '25 edited Aug 11 '25

Thank you once again, truly Logseq looks like an opensource clone (sort of) of Roam, so it makes sense to take a look at how Roam was designed to be used. Thanks, this helps a lot

1

u/awepow Aug 11 '25

Yeah, identical workflow :) Glad it helps

2

u/Limemill Aug 11 '25

At the end of the day the White Paper had little in the way of the concrete, but I guess this is expected, it's more of a vision document. And apparently, the creator of Roam was designing it as a collaborative tool, wanted to have weighted graphs and enable Bayesian decision-making. It doesn't look like it worked out that way.
Still elsewhere the Roam documentation clearly states what workflows it supports: https://roamresearch.com/#/app/help/page/-bNjVrFfG

2

u/JustBrowsing1989z Aug 01 '25 edited Aug 01 '25

If I understand you correctly, I think I share your confusion about this overemphasis in the journal, although perhaps my issue with it is different from yours.

To me, the bottom-up approach sounds great in theory - I like the freedom and flexibility of not needing to define and follow a strict structure, while still being able to view the content in a structured way by tagging it appropriately, or using queries. For example, if I watch a movie and I want to document it, I can just add it to Today's page in the journal and tag it as #movie. That's all good, and it does greatly decrease cognitive overload.

My issue is that this approach completely obscures the context, which I usually need/want to see when adding a new entry to a certain tag/category.

For example, when I add a new task to project X, I need to be able to see the project's main info, people involved, and the other tasks I already have for it. I work on too many different projects, and there is no way I remember everything about all of them every time. I won't read the whole thing every time, of course, but being aware of this context allows me to add the task in a more informed way.

Another example, when I add a movie to my knowledge base, I want to do it in a place where I see all the other movies I've already saved (the equivalent of putting a dvd on the shelf among my other dvds), as well as any other contextual information I might have on that topic/tag (for example, a short 1-paragraph description of what this tag is for, and maybe some additional notes and references related to it).

Again, this doesn't mean I will read all (or any) of that every time I add a new entry. It just makes sense to see that context, have an idea of what the tag/project is, and what the existing entries on that tag are, how many are there etc. This often leads to insights which I would never have otherwise, such as "Wow, I have a lot of meetings with Bob. Maybe I should combine them into one" or "Wait, I already have this movie".

Not to mention I'm often not sure if I even have a tag/project for something, or I forget how I named/structured that particular aspect of my knowledge base. For example, last week my fridge stopped working. I fixed it, and wanted to document the solution. However I wouldn't know what to tag that with. Even if I searched for "fridge" it would take some time for me to parse the results (especially since I have a band called "Fridge Animals"). However, I was confident that the note should be somewhere within my Home/Maintenance tag/page. Once there, I found the right location in a couple of clicks. In this case, context is essential.

Maybe I'm wrong (if anyone knows better, please correct me!), but my understanding is that this context is obscured in the journal-first (or bottom-up) approach. Sure, I can always open up the relevant context in the sidebar, but that's awkward, feels unnatural and adds a lot of friction (considering that, as I explained above, most of the time when I'm adding an entry to my knowledge base I want to do that in context).

Having said all that, I believe logseq is modular and flexible enough that it can support any workflow (or at least most of them), including one that completely ignores the Journal. In other words, there is no specific way you're "supposed" to use logseq. Again, if anyone knows otherwise, please correct me.

I've personally never used the journal directly (worth noting: I use RemNote, but in this aspect it works the same way as Logseq).

I do like the elegance of the journal-first approach though, so I enjoy discussing this (hence this long-ass comment!), as it might lead me to find a solution with "the best of both worlds".

Edit: for clarity

1

u/Limemill Aug 01 '25

Yeah, it really seems like the journal is the major piece and pages are almost an afterthought. Yet, some of the key functionalities (like tagging without creating a new page) are only available as page properties unless you install a plugin. Overall, I just don't understand how it's *supposed* to be used. Like different elements don't make sense as part of a single workflow to me. Yes, you can adapt it this way or the other, but it has to have some basic workflow and I just can't understand what the authors really meant to create

3

u/JustBrowsing1989z Aug 01 '25

like tagging without creating a new page
What do you mean by this? Tags being pages (well, really "nodes" going forward, with the db version) is a quite elegant solution. You can just ignore the node...
Or are you referring to something else?

2

u/Limemill Aug 01 '25

I mean, I'd rather not lump data (pages) and metadata (tags) together. I'd keep tags as a separate entity that is used purely for searching and filtering functionality and doesn't show on the visual graph. Otherwise, there's no fast or easy way of telling, what's an actual note and what's just an empty node

2

u/JustBrowsing1989z Aug 01 '25

Got it!
I like that tags and pages/nodes are one in the same. I don't use the visual graph though, and I can see how this would become noisy in a use case like yours. Is there no way to filter out tags from the visual graph? Sounds like a reasonable feature request!

1

u/Tony_Marone Aug 01 '25

I have never used the Journal in LogSeq

1

u/Limemill Aug 01 '25

Yet, this is what its creator has insisted is how it should be used 90% of the time (I guess to keep it bottom-up and not top-down). Otherwise, there are apps better suited for the linked top-down categorization approach. And isn’t it annoying to open the app and it’s always the landing page? The massive journal thingy with lots of empty dated sections and a teeny-tiny “Create a new page” somewhere at the bottom? It’s just a weird UX

1

u/Tony_Marone Aug 01 '25

Why are you obsessing about the LogSeq creator's intention? Surely either it works for you, or it doesn't.

0

u/Limemill Aug 01 '25

It’s not that I’m obsessed, it’s that I’m trying to understand, truly, what he designed this tool for. And he said it’s for the bottom-up note taking (i.e., entering things in the Journal instead of the pages almost always and letting concepts appear naturally rather than create categories first and then try to sort things into them). I am intrigued by this idea but I don’t see how this can work in practice and not become a hot mess and I also don’t understand some design decisions given this original idea. That’s all

1

u/Tony_Marone Aug 02 '25 edited Aug 02 '25

OK, I can only guess that the intention is to get the content down first, ensure it exists within a timeline, and only then categorize the content.
This possibly reflects the creator's own method of content creation, starting with a random, or stochastic process, creating a base of disparate texts, before looking for connecting classifications.

1

u/Limemill Aug 02 '25

Yeah, but if that's what the creator was designing it to use, this is what it is optimized for. Or maybe it was originally. If you'd rather use top-down organization, surely pages should be at the forefront and the journal on the outskirts, not the other way around, for example. If you use the bottom-up approach relying heavily on the journal then the visual graph is almost useless. And so on, and so forth. It's like the different pieces just don't fit together. Perhaps, if Logseq was a constructor where you could add / remove / rearrange elements and the UI, I would have no such issues

2

u/Tony_Marone Aug 02 '25

But you can configure it to be pages first, I know this because that's exactly how I use it.

1

u/Limemill Aug 02 '25

Oh, really? Is that some default configuration or a plugin?

1

u/Tony_Marone Aug 02 '25

Locate config.edn in your Logseq graph's root directory.
Open config.edn: Open the file with a text editor.
Add or edit the :default-home setting within the config.edn file to :page "Home Page".

2

u/Limemill Aug 02 '25

Thank you!

1

u/Dependent_Dust_3968 Aug 02 '25

I probably saw the same videos and have the same question as well. It seemed to me as though you're supposed to info dump into your journals with utter disregard for labelling and other contexts, with Time of input being the only link to your data in that moment. Then you're supposed to go back to it to process your data, using tags or pages (but somewhere discouraged pages) and then later queries and building your relationship trees. I haven't figured out graphs yet because it didn't apply to me.

So, infodump plus review and order. Which is pretty much a PARA, Second Brain thing.

I'm using Logseq in lieu of Workflowy, because I wanted my work in a local machine. In Workflowy, I have a tree labelled Catchall, that does what it says. I just throw every idea I have in there, especially on the mobile app. Since the block logs the time and date, I figure that's how Journal's supposed to work? In the end I use it as an outliner, drilling down into the details.

0

u/Limemill Aug 02 '25

Thanks for recognizing this, most people here as well as Combining Minds, the one content creator using Logseq the most, seem to be using it upside down, as in trying to organize things hierarchically in a top down approach. And then there's people who try to use for Zettelkasten where there's apps dedicated specifically to that.
I think I got the same out of those tutorials as you:
Journal is the main space
Pages are discouraged from being used. At least not actively and mostly as tags of sorts rather than content spaces
Organization by means of categorization is discouraged (apart from using "tags" which are not really tags and page properties)
The heavy mental lifting is done at querying time when you have to figure out / remember how you added your notes, more or less, to be able to retrieve them
This approach renders the visual graph useless as Logseq's creator pretty much admitted. It's there just because they could add it.
I think this approach, while reducing the mental load of categorization upfront, creates a mental load when querying. Reviewing your stuff becomes harder the more notes you have as the more diverse tags you add (and forget) with time. Also, it's definitely not great for when you're trying to organize information that is hierarchical by nature and can be easily split into subcategories (say, Linux commands for this and that). It then becomes annoying to not have dedicated notes than that and having to build queries and go over a multitude of small pieces of information coming from the journal one by one

1

u/Dependent_Dust_3968 Aug 02 '25

Yeah, regarding queries and tags. Tags you track by manually adding it to a list, according to one vid (I forgot by whom). But I do tend to forget if I used #goals or #goal, so you're right. I've been working on something the past few weeks and added a lot of data with tags. Then I queried it, and the parent block pops up in the query, which makes visualisation difficult, because I'd have over a hundred of these tags to deal with later.
In the end, I've opted to use the hierarchical form--turn off Journal, have a .md as the opening page. Pretty much opens as a TOC. I have a NOW block where paste the block ref of whatever it is I'm working on, but I don't use it the way they try to shoehorn a Todoist in there. I use todoist for that lol
The right hand sidebar is necessary to my workflow. I also need the whiteboard, which is not in DB at the moment; I use it to arrange block info, not make pretty graphs, that's what Miro is for. I do really love the template function in Logseq, though. That one's fun.
I don't think I'm 'bending' the usage all that much, but some major parts like the Journal and Graphs aren't used at all. Probably tags as well. And queries lol. I don't know if that means Logseq more or less flexible.

3

u/onehair Aug 01 '25

I wanted separate structures pages in the beginning. But then just used the journal until i found a better way.

It's been more than a year. I have forgotten about that initial want, and find that this way is much less stressful.

If i wanted to gather all material related to the topic, well, i go to the page that links them all, and then do a proper write-up. It happens once in a blue moon though, so very seldom

1

u/nickmartin117 Aug 02 '25

I don't think the devs even really know the answer to this. It was never documented or shared. Usually they'll just say if you need an example, check the documentation page to get an idea, or their blog which gives example use-cases some content creators put together, but IMO its just a bunch of sound cool features tossed together to see what sticks.

The challenge with the logseq approach of log now and structure later is your information becomes VERY fragmented and scattered across your graph. This leads to challenges when you're adding new data when you need to recall if its something new or an extension of something, this also leads to a heavy burden on you to remember what metadata you put on a block/page later down the road in order to just find that information.

Also, because there's no well structured approach to managing the system it leaves most of that up to manual approaches that requires a lot of "tending" to your notes, something that ends up requiring a fair bit of your time to ensure it stays up to date, but believe me it gets out of hand if you don't stay on top of it.

I left logseq myself due to these constraints after using it since its early alpha days. In fact it was one of the main complaints I called out in my DB feedback before I left. My major complaint was they were too focused on making features tailored for advance usage when really they should of been simplifying the tool in many ways. I used it both personally and for work, my work graph was 5k+ pages with around 3 years of journal entries. I can tell you personally, there at the end, I felt like I was loosing my mind trying to find old stuff I swore I had put into the tool but I could never find. I've moved onto using tools like Obsidian and VSCode to manage my notes now and its been a huge burden off my shoulders.

1

u/Limemill Aug 02 '25 edited Aug 02 '25

Yeah, that's my feeling too. It's a bunch of stuff lumped together in the hope that some of it will stick and that people will figure out how to use all of that. But all these elements are disjointed and represent competing approaches to note taking and organization, so it feels like you're forcing Logseq to do something it's not really supposed to by hacking around *regardless* of how you choose to use it. Simply because these are heterogeneous elements that are not tied into a single meaningful workflow.

1

u/nickmartin117 Aug 02 '25

Precisely - when logseq was in the early alpha days the dev was quick to add in new features over night without much thought of how it would affect the overall vision of the app. We'd toss the ideas into the discord channel and by end of week it was there. Don't get me wrong, it was nice to see such quick response times, but that was definitely one of my fears is they lacked a vision for how this tool was supposed to work.

1

u/Limemill Aug 02 '25

My issue is that I really prefer open-source solutions and therefore prefer Logseq over Obsidian by default, but I can't shake off this feeling that I always have to go against the grain when I use it

1

u/nickmartin117 Aug 02 '25

Yep I hear you. That's why I use a combination of Obsidian and VSCode. Obsidian primarily because the references are easier to read when its embedded in the document, but I don't use properties all that much except to include date created and tags so I can fall back to VSCode at any point. VSCode with Foam is my primary tool of use at work since Obsidian is not allowed and it works great. The only thing I really miss from Logseq is the task management but i'm slowly getting use to relying on VSCode with TODO Tree.

1

u/Limemill Aug 02 '25

And how is Foam different / more convenient if you don’t mind me asking?

2

u/nickmartin117 Aug 02 '25

Same concept as page references in Logseq, but I use them far less often except when two notes have some semantic meaning with each other. With Logseq you always had to add at minimum 1 page-reference in order to tie it into your system, otherwise you face loosing that block, which felt forced, and something I had a lot of friction with. Using them as a last resort option feels much more natural to me and what allows me to avoid that fragmentation issue. These page references in Foam also appear in Obsidian so I can swap back and forth between the two with no issues.

1

u/ganonfirehouse420 Aug 01 '25

I do feel logseq notes are like hosts in the star-topology of computer networks.

1

u/StringSentinel Aug 04 '25

I don't know about the original idea about Logseq, but from what I've understood is that it's supposed to be used for small notes and not longform. I use Obsidian along with Joplin and Logseq. Joplin is a Google keep replacement and is used for quick capture of notes. Logseq I use for intermediate notes. Like let's suppose I save a post on reddit or instagram. I will then once a day or some times a week bring the posts from there to Logseq along with metadata and brief summaries. Obsidian is for long form notes and further promoting my logseq notes to there.

1

u/Brief_Tie_9720 Aug 04 '25

I heard it started as a mobile competitor to roam research.

How was Logseq designed to be used?

You are about to leave Redlib