The trouble I see with this sort of approach (not Foam itself, but a general take on Obsidian, Zettelkasten, etc.) is that you quickly end up with a single folder with thousands of files, which makes it hard to manage, share, etc. Especially if you have diagrams or media associated with your entries.
It’s the same issue with static sites: you get a posts folder, dump everything in it, and then you dump all the images in an images folder and lose association between them.
I would much prefer if these tools took front matter metadata (or a pathname) to link to each other and had a note-per-folder approach (my own site does that, and I store images for each post in the same folder as “index.md”—the pathname becomes the final URL).
Foam author here! I am very open to all suggestions in this area. Foam is a new project I built solely to my own requirements, but I'm actively seeking feedback on how to make it more broadly applicable as per our principles:
https://foambubble.github.io/foam/principles
That would seal the deal for me. I have tens of thousands of documents, notes, pictures etc. spread across hundreds of subdirectories. Foam looks extremely promising.
Amazing! Please let me know in GitHub issues or Twitter DMs how you get along. This is a very early alpha release, keen to hear feedback at all levels!
I beg to differ. Having them all in one folder is actually exactly what I want.
Storing them into folders is just giving you problems. I would need to put them into many folders, to get any benefits, but than again, this could be done by tags so much more easily.
In the end there is no reason to directly manipulate the file structure. It is just easier to have a flat hierarchy. If I need to find something: there are tags, there is the graph, and of course there is a full text search.
I partially agree with you, but it's because I have a certain searching method that I'm comfortable with. I use sed/awk/grep quite a bit. The find command is also useful - but with those utilities, I can quickly search for any string or regular expression I need.
If I'm looking for the word cow in a doc that I think is in a folder (even if it's in subfolders), then I can do this:
grep --color=always -r "cow"
(I like setting color to always, and for some reason I'm too lazy to set up an alias so I don't have to type it)
I can get way more complicated by escaping spaces, looking for certain file types, etc.... really this does about the same as grep though - but still interesting:
find -name ".txt" -o -name ".md" -type f | sed 's/\ /\\\ /'g | xargs grep --color=always -n "cow"
Using these utilities, I've been able to find things in lots of lines of code, or lots of lines of md files.
Well, I do have around 8000 documents, and I organize them with a mix of hierarchy and tags (plus search). My entire site (taoofmac.com) was built that way, but the hierarchy was key - otherwise I would have trouble grouping and managing related things.
We have actually tried to mitigate this with our knowledge-base solution[1] by using multi-parent nesting in addition to hyperlinking + backlinks (zettelkasten).
On our platform, everything is a card (rather than a document), and if you want an actual structured hierarchy, you can nest cards inside other cards. Each card can have multiple parents, so if you are collaborating with others you can easily have the same "card" in different places to keep yourself organized. In that way it works similar to symbolic links in a filesystem, except it's nesting so there are no folders – just cards all the way down.
At the same time, because your cards are not actually siloed into different folders, we have things like the "home", which has all the cards you've ever made so that you can easily filter your entire library by tag / author / etc. and see all of those cards at once.
Unlike the OC solution, however, Supernotes is not self-hosted, and so probably isn't as appealing to a lot of the techie HN crowd.
It's an incredibly powerful pattern, so much so that I'm surprised by how little you see it in the wild. We've also combined it with collaboration functionality so that cards can not only have multiple parents but can have different parents for different users. This aspect might be novel – I don't think I've seen it elsewhere, but obviously it's hard to know due to the sheer number of productivity tools that have existed (as evidenced by you pointing to Lotus Agenda, which I hadn't heard of til today, thanks!)
It's not for lack of demand. Mitch Kapor (Agenda) and Mozilla talent tried an OSS reboot, Chandler. It was so well funded and failed so spectacularly, that there's a book about it.
Question: Do you have an option where your backend could be used to supply content to a frontend public website? Mind you, given your data structure, I'm not sure how that would work.
Let me give you an example. I like to read, mostly long form non-fiction (i.e., books). Naturally, I highlight things of importance. I want to take those ideas and get them into something where I can organize, add categories and tags, etc.
Yes. A basic WordPress site would be sufficient. But given a tool like yours, why not try to take up a level? On the backend, my "thoughts" well organized. The frontend some view of that I'd want to share with the public.
Thanks! And the answer to your question is yes, absolutely!
Hopefully quite soon (we already have a working demo) we will introduce "card pages", which will be public (or semi-private, it'll be configurable) pages that represent either a card itself or that card's children. These pages can then be embedded into any other webpage.
The idea is to both support behavior akin to embedding a tweet, where you are just viewing a singular card as a card, but also to allow people to effectively create "documents" on Supernotes (that can then be shared publicly) by displaying the children of a card in "seamless" mode, so that even though it's actually a bunch of cards under the hood, it'll look like a blog post, or wiki article, or readme, or whatever.
Every card on Supernotes will be able to have multiple pages, so that you can have a truly publicly-facing representation (which might limit how people can interact with it) but simultaneously embed your card somewhere else that is semi-private (like a Notion doc for your team) and allow people to actually interact / edit the card from there.
I’m [very] interested. I saw your app before, but it was during my looking at so many different apps, I didn’t look too much into it.
Being an HNer working on the product is a pretty big pro for me. Will be showing this specific comment to a few people for reference to Supernotes as well.
Glad to hear it! Knowledge management is definitely a crowded space – probably because it's something that is almost universally useful to humanity if done "correctly".
Being around HN for a while has definitely influenced how I think about the product and what I want to build. For a while I was wanting to build Supernotes as a federated service (and at some level I still want to do that), but for now the focus is mostly on making the most seamless UX.
You seem to be hitting the nail on the head with regard to seamless UX. I’d gladly pay to support something like this, but the lock-in / “what happens if you go away” problem is real and holds me back from investing all my knowledge and time. Short of an actual federated system, a self hosted option OR just markdown export / backup of an entire database would completely alleviate that for me.
So we do currently have the ability to export all your cards as one giant markdown file. Obviously the issue with any sort of export with our system is that even if we export as markdown, the relationships don't really carry over into the export.
But this is definitely something we are working to make as easy / thorough as possible. Data ownership by our users is very important, which we've spelled out in our terms[1] as well.
I think the whole point is to not have hierarchical folders because they make it harder to see connections between ideas.
But you can tag your ideas, or create "folder" notes that contain list of other notes.
And you can nest those notes or course, and even have loops in your graph, so it's more flexible than folders.
Also, for static sites, I use Jekyll and I create a folder for each post in the image directory. It's very convenient.
Well technically Luhmann grouped hits notes into "folders" by using multiple drawers. But that might be due to the space limitations you face in the real world. I wrote about the concept here: https://emvi.com/blog/luhmanns-zettelkasten-a-productivity-t...
In Emvi [1] we built it so that you can mention an article (and everything else) anywhere and the title will get updated when the linked article is. In case you delete it there is a hint that it has been deleted.
I generally like to annotate or mark stuff instead of sorting them into folders to search through them later. It's by far easier to remember _what_ you're looking for than _where_ you can find it. If you're trying to find a place you have been to before, it's easier to remember a land mark next to it than the streets you have to drive down.
> It’s the same issue with static sites: you get a posts folder, dump everything in it, and then you dump all the images in an images folder and lose association between them.
Hugo is an exception, and a recent one at that (I followed the page bundles discussion with interest since I considered moving to it at one time, but relative link handling is still over-complex from my standpoint...)
I think that falls into a class of tradeoffs that using various tools involves. With a higher level of functionality the designer of the tool must make decisions about how to implement the functionality. They can provide options or configuration to tailor behavior to an individuals preferences but that increases friction when getting started with the tool.
I'm using a a much less capable tool for managing my notes called `mkdocs`. It converts a collection of markdown pages to HTML that I serve from a script running on a Raspberry Pi (`python3 -m http.server 8100`) `mkdocs` provides Github integration but I keep the repo on a private server so I don;t have to worry about private information leaking. Point is, It does nothing with directories so that is completely under my control. It links the pages hierarchically but I can insert links between pages and to images. Manually.
This is indeed a problem. But i think a big part of writing is organization. The organizational principles changes over time as the folder grows, and I refactor to realize new principles. For notes, this refactoring is healthy for me. It makes me realize things about my own thoughts.
Your point about managing the image resources associated with the markdown is an important one. Rather than one folder per note, the existing approach is compatible with a {file-slug}.resources/ naming scheme. Sounds like a good opportunity for another plugin.
That approach won’t fix the “thousands of files in a folder” problem. It will just add another: “thousands of subfolders”.
A full hierarchical approach (not just single level) is much better (believe me, I’ve been doing this for 16 years and have nearly 8000 notes/posts at taoofmac.com).
FWIW a hierarchy of notes can only reflect one dimension. But notes typically have multiple dimensions associated with them, and there is (in reality) no canonical hierarchy. Which means you will regularly end up in arguments with yourself about where in the hierarchy to put the note, unless your hierarchy is of a exceedingly simple kind, and serves but one single purpose.
In fact, insisting to placing notes in a single hierarchy only serves to support a common but incorrect notion IMO: that things have but one single, universally valid, most important attribute. Of course no one will seriously argue that this is the case, but the notion is nonetheless ubiquitous because of our need to simplify, probably.
> A full hierarchical approach (not just single level) is much better (believe me, I’ve been doing this for 16 years and have nearly 8000 notes/posts at taoofmac.com).
I think it would be better if you recognized that while this works neatly for you, some of us have other systems that work nicely for us.
Tags and search in particular are really empowering to me because I can file things in multiple places and find them in all of them - or I can search for multiple tags at once to slice out a subset of my notes or bookmarks.
An alternative lies in the concept of harvesting stocks from flows, which suggests starting with a journal, a timestamped, immutable list of notes, both large and small (small is better in many cases); wikilinks within those journal entries form branches, but then notes from the journal can be transcluded into other structures as deemed appropriate.
Brownfield trade-offs; the current tool is agnostic about directory structure. There are other trade-offs: simple links/URLs, the requirement for opinionated helpers/generators, and the extra layer that is not required for notes that never add attachments. I’m just throwing ideas out there; I don’t have a horse in the race.
> It’s the same issue with static sites: you get a posts folder, dump everything in it, and then you dump all the images in an images folder and lose association between them.
If only that was limited to static site generators. Wordpress does not have any media organizing by default, no folders, no nothing. There are plugins, of course.
That was my biggest surprise when I recently looked at Wordpress.
It’s the same issue with static sites: you get a posts folder, dump everything in it, and then you dump all the images in an images folder and lose association between them.
I would much prefer if these tools took front matter metadata (or a pathname) to link to each other and had a note-per-folder approach (my own site does that, and I store images for each post in the same folder as “index.md”—the pathname becomes the final URL).