A setting to import and export notes to/from a single file. To allow users to easily backup and restore notes.
Hi, what format would you like us to support?
You can export documents as Markdown / HTML and databases as CSV files.
We also support bulk import of Markdown / CSV files
Md would be sufficient, for me.
Hi Annie,
great question. Iâm not that technical about exporting and importing - but I guess anything that stops that scary feeling of vendor lock-in?
NOTES CULTURAL ISSUE:
Hi all, one thing I really would love to see more of when joining a new notes app is something like a guide on setting up with warnings about certain format choices that might make it more difficult to leave them again. I wish notes apps were so confident of their product being the best that they had plenty of warnings about how best to format all your notes if you ever wanted to leave them! Because right now I have the ironic situation where BECAUSE it is so hard to leave my current App - I feel like leaving them. If I knew it was easier to leave them, and every new note I typed was not increasing my workload later - then Iâd be more relaxed and possibly just stay. But as Jordan Peterson says, do what you can to solve your problems today. Donât leave them all to future you - because they accumulate. âGee Iâd hate to be that guy!â
MY CURRENT SETUP MAKES IT HARDER FOR ME TO LEAVE
I currently have my notes feeling more and more âtrappedâ in a certain app where it is going to take a LOT of work to export them neatly. It seems some notes apps have databases that do not export neatly to other notes databases. I wish I had known that going in.
ITâS ALL ABOUT THE NOTES DIRECTORY TREE
I have avoided the âEvernoteâ style of what I call the notes âDirectory Treeâ - with master notes having sub-notes and sub-sub notes, etc almost to infinity. I was nervous that I might accidentally delete a page that contained maybe ONE hidden note down the bottom somewhere that I might have forgotten had hundreds of other notes subbing off it! (My life and mind get a little chaotic at times.)
Instead - I relied on a database system to store all my notes âsafelyâ - and used âPage Proxyâ links menus to get around. That meant there were no actual pages as sub-notes. If I deleted a page with lots of lists of âsub-pagesâ linked on it - none of those pages would actually be deleted. They were safe back in the database - and were just proxies! I was so happy.
(This was in an app that had âsynced blocksâ so one link update on a menu would update across hundreds of other pages. It makes this kind of navigating quite visual and easy compared to searching databases. It also meant I could have flexible topic sub-menus, with heaps of reminders to myself when dealing with overlapping themes - and not just feel locked into the rigidness of the Master Page with 30 links to Sub-pages with 30 links to Sub-Sub-pages with 30 links, etc.)
I was so happy ⌠untilâŚ. I discovered most notes app databases do not talk to each other!
I now have to put them all back into a Notes Directory Tree if I ever want to export these notes to another app! Itâs going to be a lot of work.
What do you think? Would notes apps being more able to export to each other make people more likely to stay - or less likely?
ADVICE IF YOU ARE IN MY SITUATION
Donât leave your app until youâve setup the Directory Tree first! Itâs far easier to do that by using your Database to select Tags and move a few dozen notes at a time to a new Master Page than it is to export them first, then reimport them into the next app - and have to resort them all manually! Depending on the tag, that could be dozens - or even hundreds of times the work!
I think OP means in their FR they want mass/bulk export - an essential feature to avoid app lock-in. The bulk export would need to maintain the relationships between notes. Links would be easy in Markdown; databases not so.
For bulk export of documents, if AppFlowy markup is a subset of Markdown, then Markdown is the gold standard.
For databases, CSV files are standard, but if they canât model relationships from AppFlowy, then SQLite would be the most common and widely compatible format.
Would be worth looking at how Logseq deals with table data and queries. Its storage medium is Markdown rather than a custom database and format, which means the âexportâ is already there at all times.