5 ms·

My go-to list of requirements for a "personal thoughts" tool: - file-based, so that: * migrated to other tools * edited with robust classic text editors

My go-to list of requirements for a "personal thoughts" tool: - file-based, so that: * migrated to other tools * edited with robust classic text editors * copied, synched and backed-up with external file tools This is essential so that persistence of the valuable knowledge stored in the application won't depend exclusively on its (fragile) internal tools, but can be managed as a system-level admin task. - Tree-based, but with external links, to allow for arbitrary network shapes (the basic "tree" outliner shape can be augmented with links to other parts of the network, without having to copy the whole sub-tree) - Multi-directional (incoming+outgoing) links (This is hard to see in most outliner note-taking tools, but Roam does it pretty well) - Easy navigation of parts of the tree through breadcrumbs (allows avoiding the "humongous tree of death" by creating "local navigation" views). Workflowy does this very well. - Tag-based persistent filters that can be stored as nodes in the tree (i.e. you don't need to search in the search bar for a combination of tags every time you want to recover it). With this, you can create new concepts by storing persistent complex searches as part of the tree. - Easy to set up, share, and use in multiple devices and OSs (mobile and desktop).

AriaMinaei 7y ago
I agree with with all those requirements except for the first one. I think there should be a way to export to files/directories, but using files/directories as the primary persistence mechanism is inherently limiting: - Editing things with classic text editors loses the intent of each edit. Ever seen a git diff look radically different from what your changeset intended? That's because a simple A/B comparison cannot recover the intention of each edit. You lose information here. Like, did the user change the name of function A, or did she define a new function that looks a lot like function A? - Backing up with external tools will work. But syncing will be limited. Because the sync tools don't understand the structure of the document. - How does the tool assign a unique ID to the smallest unit of content (say, a word, or a link, or a paragraph?) - Editing files with a classic text editor will also break real-time collaborative editing.
- The_Colonel 7y ago
  I totally agree. Filesystem works only for the simplest of use cases. Besides what you mentioned, their requirement of "Multi-directional (incoming+outgoing) link" is essentially impossible to do well with file based approach: - the only identifier of a file is the path, once you rename a file, all the links pointing to it are broken - for incoming links you'd have to scan the rest of the notes for links (which will get slow at some point) Typical way to mitigate this is to create some index files, name note files with UUIDs instead of their natural names, but this then creates a lot of other problems as well. You might also find out that the limitations of filesystem (strict tree structure, strict split between directories and files) might not be a best fit for note structure ...
  - TuringTest 7y ago
    I was thinking of a system where the content of the nodes is persisted as files, like in static website generators, and then the interactive view is generated from the content read in files when the application starts or is updated. Wikis work that way, where the payload of each page is a flat text sequence with simple markup. The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations.
    - The_Colonel 7y ago
      > Wikis work that way, where the payload of each page is a flat text sequence with simple markup. That depends on the wiki. The most well known - MediaWiki - uses traditional DB like MySQL or Postgres. > The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations. What happens when files and metadata go out of sync? People want to have the data in plaintext for interoperability with other tools so they are going to edit the data outside of the app. And your app does not know files changed so it can't selectively update the indexes/metadata. Another motivation for flat files is that users want to use standard sync tools like syncthing, dropbox etc. But these metadata and indexes will not work at all in case of write conflicts - dropbox does not know how to merge those serverless database files.
DEADBEEFC0FFEE 7y ago
The problem with tree based outlines are they are typically single root. The idea of picking an arbitrary node and visually reorganising the structure as if it were root isn't common at all. I think I have seen one mindmapper have this feature.

AriaMinaei 7y ago

I agree with with all those requirements except for the first one. I think there should be a way to export to files/directories, but using files/directories as the primary persistence mechanism is inherently limiting: - Editing things with classic text editors loses the intent of each edit. Ever seen a git diff look radically different from what your changeset intended? That's because a simple A/B comparison cannot recover the intention of each edit. You lose information here. Like, did the user change the name of function A, or did she define a new function that looks a lot like function A? - Backing up with external tools will work. But syncing will be limited. Because the sync tools don't understand the structure of the document. - How does the tool assign a unique ID to the smallest unit of content (say, a word, or a link, or a paragraph?) - Editing files with a classic text editor will also break real-time collaborative editing.

The_Colonel 7y ago
I totally agree. Filesystem works only for the simplest of use cases. Besides what you mentioned, their requirement of "Multi-directional (incoming+outgoing) link" is essentially impossible to do well with file based approach: - the only identifier of a file is the path, once you rename a file, all the links pointing to it are broken - for incoming links you'd have to scan the rest of the notes for links (which will get slow at some point) Typical way to mitigate this is to create some index files, name note files with UUIDs instead of their natural names, but this then creates a lot of other problems as well. You might also find out that the limitations of filesystem (strict tree structure, strict split between directories and files) might not be a best fit for note structure ...
- TuringTest 7y ago
  I was thinking of a system where the content of the nodes is persisted as files, like in static website generators, and then the interactive view is generated from the content read in files when the application starts or is updated. Wikis work that way, where the payload of each page is a flat text sequence with simple markup. The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations.
  - The_Colonel 7y ago
    > Wikis work that way, where the payload of each page is a flat text sequence with simple markup. That depends on the wiki. The most well known - MediaWiki - uses traditional DB like MySQL or Postgres. > The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations. What happens when files and metadata go out of sync? People want to have the data in plaintext for interoperability with other tools so they are going to edit the data outside of the app. And your app does not know files changed so it can't selectively update the indexes/metadata. Another motivation for flat files is that users want to use standard sync tools like syncthing, dropbox etc. But these metadata and indexes will not work at all in case of write conflicts - dropbox does not know how to merge those serverless database files.

DEADBEEFC0FFEE 7y ago

The problem with tree based outlines are they are typically single root. The idea of picking an arbitrary node and visually reorganising the structure as if it were root isn't common at all. I think I have seen one mindmapper have this feature.