Yeah, the term “Notebooks” seems appropriate, especially because we already have the “Page” term. Awesome idea.
Cool, I’m not really sure to know about that, would you mind writing a brief short summary, just a few sentences, on what is the problem and how this Logseq approach solves it?
Your list is on point, it seems that’s all we just need for the feature to be usable.
Remote solves this by not having any different between a Block, a Page, or a Notebook. They are interchangeable, they’re all just “Rems” in their terms. Rem with not parent is a Page, Rem with parent is a Block, Rem with no parent englobes Rem with no parent = Notebook (Folder).
The conclusion to all this seems to be: many users will greatly benefit from the introduction of a Folders-like management.
Last time a dev or team member spoke about this, they said something about “it breaks our design”. Maybe they did not explicitly said they won’t implement it, but they made it look like it.
I’m willing to change perspective on this, but they seemed quite stubborn on their claims.
Till that day, I’ll be stuck using an alternative app.
It’s a matter of mindset, it seems there are people who prefer efficiency over order and viceversa.
I came up with this idea thanks to a meme in the community of mathematics. The summary is that someone noticed that almost all algebraists eat corn in a certain way and analysts in another way.
To me, it seems algebraists prefer order over efficiency and analysts prefer efficiency over order.
The same seems to be true respectively for Object Oriented Programming and Funcional Programming (incidentally Logseq is a written with a FP language, Clojure).
I think the dichotomy holds also for
Relational Databases: used by most applications to store the data. File systems can be considered as a subclass of RDB with more strict rules. We are familiar with RDB when we use applications like Excel, Access or Notion.
Graph Databases: it’s the data structure Logseq uses internally. We generally don’t interact directly with GDBs but they are very common today: they turn data into knowledge by adding context, they power Google search algorithms, recommandation algorithms on platforms like YouTube and are used in Machine Learning.
Many discovered Logseq as an alternative to Roam and maybe they already know what’s supposed to be the mindset. Instead I didn’t know Roam, I discovered Logseq as an alternative to Obsidian.
Being used with file systems (and RDBs in general) like most people I tried to use Logseq with this mindset.
Instead the “efficiency” pursued by Logseq (and Roam) consists in just writing content in blocks without caring to “place” it somewhere: just write (maybe in the journal), use [[wikilinks]] and #tags when it makes sense and let the structure (a graph) emerge naturally. Then use powerful queries to browse your knowledge base.
Properties:: and page-properties:: adds RDB capabilities to Logseq and so you can enrich your experience with queries. But the “native” approach by Logseq is the other one. I think in the future Logseq could add UI to improve the RDB experience, but if you want to use Logseq properly I suggest you to learn both the approaches and understand when one is more convenient than the other and how to combine them in the same knowledge base.
After having used this approach, maybe my vision could be limited or something, but I truly don’t see how having a Folder-like management in addition (this is the key concept I’m trying to convey) to the current “just write somewhere, add metadata, and then use Query” approach could damage the user.
The possibility of choice. This is the key for me. I’d like to have the right to choose which method suits my specific needs in specific situations.
A corny example: you can probably do the same operations on a smartphone and a tablet, but nonetheless one could certainly be willing to spend for both of them and choose which one to use based on the moment their needs occur.
The analogy with OOP and FP is great, although it may put it a certain way that could make you think “it’s either this or that”, which is most probably true for the programming languages paradigms, but here specifically talking about this feature in Logseq, I struggle to see their irreconcilability.
Meaning, if you add Folders-like management it seems unlikely it will be detrimental to the current set of features or workflows.
At least, that’s my opinion, based on the thinking that a software provides a set of features, and the users decides how and which one to use to better suit their needs.
OK, it seems like there are several schools of thought on this topic.
1: Logseq already has a hierarchy called namespaces, why not use the filesystem for it?
2: Logseq has namespaces, but the filesystem is inappropriate for storing it for some reason(s)
3: Logseq has namespaces and might someday have additional overlapping hierarchies, so it would be arbitrary to “elevate” just one (namespace) into the filesystem
4a: The underlying filesystem doesn’t matter, I don’t care about that, just want a better UI within logseq for manipulating namespaces
4b: the filesystem might be useful for some, but I mostly want a better UI within logseq for namespaces
5: What’s all this about hierarchies, who cares about those? There are many more interesting/advanced ways of categorizing notes; let’s have that discussion instead
At this point I don’t see much support for my original position (which is #1 in case you can’t tell). I thought it was simple and implementable without much work and would bring good value, but from this discussion what I hear is that most people are much more interested in much more advanced categorizations (even if they’re much more work).
BTW “Notebooks” isn’t really different from the existing namespace feature, right? You could just organize your notes as NotebookA/note1 and NotebookB/note1 and NotebookC/Section1/note1 etc. Of course there’s no batch select, move, or rename; see 4a and 4b above.
You’re right, maybe someone could think my posts and possibly some related ones are cluttering your FR somehow. The topic may be considered expanded as being talked about hierarchies.
We could at least agree that a form of hierarchy is of help for users. The actual implementation is being discussed then.
Thing to notice is that it seems no team member has given their thoughts in here.
Current hierarchy implementation (Namespaces) may be cool, but they also have their knowns limitations.
Great summary of the points made in the posts by the way.
(My very personal feeling, and I want to stress it’s just a feeling, that I’m sharing here, don’t want to make a point or anything, is that:
the team has made their decision about hierarchies; they believe Namespaces are sufficient, and they see the need of meticulously adding tags/metadata to your new info and creating simple/complex queries to retrieve them is the way to go.)
As I said I’m not against it and I don’t think it’s set on stone for Logseq devs neither. I think it just happened that Logseq focuses on the Efficiency mindset and the UI for a more RDB experience is just lacking at the moment. If one contributes to Logseq in that direction with a good implementation I don’t think the devs will refuse it. Indeed properties are a step in that direction.
I mean one should use the best approach according to the problem, not the situation. For example if I want to track books and their authors the RDB model is better for me.
Again it depends on the problem: sometimes OOP is very naturally the best paradigm and sometimes it makes sense to use FP instead. It’s not like a developer will always use one or the other, of course.
In my opinion, compared to other applications, Logseq gives very abstract, general and powerful tools and the user is free to build a custom workflow . Indeed my “indexes” are a workaround that is possible thanks to the generic Logseq tools.
I don’t remember if I already mentioned it, but for example here there is my proposal to make it easier to add properties while keeping the efficiency approach:
They are very different: namespaces are for disambiguation. They are named so because they work like the namespaces we use in programming languages.
I think the confusion comes from Logseq labeling the breadcrumb to browse namespace “hierachy”.
When you mention [[Parent/Child]] somewhere you are referring to a “Child” that is specifically a child of the [[Parent]] page and it is different from [[Child]].
Namespaces makes sense for chapters of a book for example, [[Title/Chapter 1]], not to dinamically organize pages.
Namespaces are not folders or notebooks, they are not collections of pages, they carry a specific meaning… I don’t know how to better phrase it, sorry.
But when you want to move a page from one folder to another one… do you really want to say: “this page referred to one folder and now refers to another one”, like namespaces do?
For example, where namespaces make sense:
- [[Event A/Photos]]
- [[Place B/Photos]]
Namespaces here are saying “Photos of Event A/Place B”.
Instead a folder/notebook structure like this one:
Images
Photos
Artworks
...
is just how you choose to (temporarily) organize things, it’s not like “Photos” indicates “the photos of the images”.
Namespaces are not folders or notebooks, they are not collections of pages […]
Namespaces makes sense for chapters of a book for example, […]
which maybe is how you use them, but I use them exactly as collections of related pages. Perhaps the term “namespace” is confusing? As implemented in logseq, it’s just a simple parent/child hierarchy. I think it’s really useful that when I create projects/ProjectA/schedule I can then go to projects/projectA and see all the pages related to that project (schedule, people, resources, etc. etc.) in the hierarchy list at the bottom, as well as all the blocks tagged with that project.
But that’s just one way to use it, of course. As you say, books/Title/Chapter would be useful too.
As for moving a single page, that’s easy in logseq today – you just rename it (change the parent).
Sorry, as I said it is not: “namespaces” mean a specific thing and indeed Logseq’s namespaces work exactly as elsewhere. If not, why would they use a niche term like namespaces instead of well known folders/notebooks?
When it comes to UI, i.e. what Logseq uses to present them, it is indeed useful for browsing purposes but just because Logseq lacks notebooks/folders or other hierachical browsing, so you “hacked” your way through the UI.
ProjectA/schedule is indeed how namespaces are supposed to work, but projects/ProjectA does not.
So I hope it is clear now why Logseq devs are not going to mix namespaces with other hierarchies nor the hard drive folder structure.
My assumption has been that they didn’t want to use a term like “folder” because logseq presents the folders as pages themselves (with default queries, but also optional content). So the name “folder” would be confusing. But as to why they chose “namespace”? ¯_(ツ)_/¯
By the way, would you be happy with the Notebooks feature described above plus a button to set a certain Notebook as the folder structure on the hard drive that Logseq would automatically respect?
They clearly stated, in another post, that namespaces are for Disambiguation
In most programming languages disambiguation is solved with Namespaces
Having Namespaces allows a software project, a code base (which is just a big giant set of coding files) to have several classes (think of them as pages in Logseq) with the same name, but in different namespaces. It is useful in many cases, you can have a Utility class inside UI Namespace, and Utility class inside Network Management namespace.
If you didn’t have namespaces, you wouldn’t be allowed to have classes with the same name. Same thing I believe in Logseq, in which I think you probably can’t have pages with the same name (Logseq will ask you to merge them, but I don’t remember if you can say no to that)
Namespaces are a very technical solution to a very technical problem within the software development domain.
They just took that idea and implemented it in Logseq.
They are conceptually similar to file system folder, as there can’t be 2 folders with the same name at the same level in the hierarchy, same goes with the files (pages in Logseq).
The similarities lay only in the text form: NamespaceA/SubNamespace/PageX.md
(In some programming languages they are written with a separating dot: NamespaceA.SubNamespace.PageX.md)
Folders in the file system are a superset of Namespaces. Folders have the same capabilities of Namespace but then some more. You can drag-n-drop easily, have column view, icon view, whatever of a more visual aspect you can think of with respect of just having different names inside other different names, separated by a specific symbol.
Yes, probably… Basically I just want what namespace gives me now. For instance, I would want to see my Notebooks path (one of them? Which one?) as the primary path in the heading, rather than the current namespace path. I assume any page could have Notebook parents, even Notebook pages (pages which are some other page’s Notebook). Also I assume Notebook pages would have the same default queries at the bottom, so you can see all the child pages and parent(s) – that’s important.
Just to be clear, your proposal is for a page property notebooks like this: notebooks:: #parent1, #parent2
and page parent1 could have: notebooks:: #parent2, #parent3
It seems like since notebooks can now be at any level (they can have notebook-parents themselves), only “top-level” notebooks (those with no notebooks property) could be selected as “primary” to commit to the FS, or use as a path in the header.
There’s also the question of circularity of course, since it’s now a graph rather than a tree, but that’s solvable.
Hey, thanks for the suggestion. I actually found my peace with Remnote now. It has everything Logseq has, plus a bit more features, (IMO) a nicer UI/UX, and of course Folders.
For visual Whiteboards, I’m using Heptabase for now, really intuitive. Will check out WBs in Logseq when they will be released. Remnote also plans to add them in the future; they are now focused on tables.
Logseq is great, don’t get me wrong, but after using it for some weeks, I felt it’s still a bit rough and perhaps it leans on satisfying a workflow and mindset of structuring the whole experience for more developer-like users, not sure how to express it better (just my impress though).
Has anyone imagined the idea that a virtual directory, notebook or collection of pages, as a one more block in the graph, but actually being a link to a new graph? (that could receive certain parameters and inherit certain properties, for example, that we could call context).
Perhaps it is something drastic, but it illustrates the concept of namespace as a synonym of another (sub?) graph space, and the layout of it as an output of some kind of function or query. Doesn’t it?
Related thread about namespaces. It’s a use case of using diferents graphs as namespaces:
So the idea I described in my previous message it’s that but visualizing them as a branch of a root graph (and with the optional feature to visualize that “sub” graph according a filter, etc), in a kind of a browseable graph.
The idea is that a multi-level folder structure is a tree extracted from a graph; instead of having a predefined folder structure, the user could use any property:: as an indication on how traversing the graph and so be able to browse that tree.
We could even concatenate more properties:: as indications, for example genre::, year:: and artist:: to browse music albums starting from genre folders, then years and then by artist.
I’m glad this discussion is ongoing. Thank you all, especially @Gary_O whose summary taught me a few things I had not considered.
TL;DR (i have some detailed writing about this but I’m sparing you) I usually don’t propose solutions because if the problem is well-defined enough, there are smarter people in this room who can come up with the best solutions. So I apologise in advance.
So, what about the ~, ~/., ~/ws/git, ~ali/ws/sandbox/model/MasterData, notation? We can map tilt, ~ to base directory in Logseq and the command line context starts from there. But if I decide to create a file in Logseq (logseq’s strength) and whatever I type in that file in Logseq is created or updated exactly in the right place/path on the filesystem. Effectively, Logseq becomes the context layer of, my workspace where my filesystem manipulations are relevant to Logseq as opposed to the entire thing.
In fact, already now, I wonder why this doesn’t work:
Cmd + K, then I type ~/ws/scripts/replace-all
If this file actually opened the actual file sitting on the file system, I would be golden. Because in my case, it’s the file itself that I look to document so I don’t see why I have to maintain a separate entity if the page is directly mapped to the file on the file system. And the trick is the follow the directories, which is not happening now.
Another Example is how I produce master and reference data for my app.
Also, please also consider the mapping to URLs, as well, which I have posted about but closed in favour of this thread for simplicity, but let’s please also discuss how we map to URLs.
. Indeed my “indexes” are a workaround that is possible thanks to the generic Logseq tools.