A [Wonkish] Cautionary Tale: Notion
Before you get too involved in adopting a tool, test how you will exit
Last fall, I decided to give Notion a try, after reading about it. I was particularly intrigued by the opportunity to develop a work management apparatus with the spreadbase architecture of the platform. Note, spreadbase is a term I am using for Notion and a list of its competitors, like Airtable and Coda: spreadbase = spreadsheet-style database.
I’ve written a few posts about my early experiences with Notion, here and here. The short version is that I found it reasonably usable for my purposes, but ran into problems whenever I wanted to export information to other tools… which brings me to the subtitle above:
Before you get too involved in adopting a tool, test how you will exit.
And, after a few months of use, I found that Notion is a very difficult tool to exit.
For those less interested in the wonkish details, that is the biggest takeaway of this post. Non-wonks may want to stop here.
Exporting From Notion Is A Pain
Notion is based on tables, such as this collection of work projects:
Looks straightforward, right? Notion provides great mechanisms for viewing such tables, as Kanban boards, lists, and tables, as shown above. Capabilities to sort and filter based on data values are simple to use and flexible.
However, exporting is impossible, basically. Here’s what that table resolves to when exported:
Many of the elements of the table are actually links to parts of the underlying database, and there is no way to export the text version of the fields. If I select the entire table and copy it, I am not presented with something like a Word or Markdown table, but a list of the project names — which is the defining column in the table. And those are rendered as hyperlinks back to the corresponding table entries in Notion.
The export to PDF does provide a partial escape valve since the PDF file can be copied and pasted as a table, as shown here in part. In the enterprise version, the PDF export can include subpages, for example, the various tasks listed in the table. Of course, a user is unlikely to sign up for the enterprise pricing tier in order to exit the tool.
Needless to say, going through the process of exporting the data from Notion ultimately wasn’t worth the trouble. I simply restarted a new list of active projects in the fashion I had been doing before, in markdown in Typora.
There are a variety of alternatives (Notejoy, Coda, and others) that can import table data that has been exported from Notion, but they rely — as far as I can tell — on being able to include subpages, which leads back to enterprise pricing issues. And of course, you have to want to be using one of those tools subsequently
An API Could Change Everything
This last week, Notion announced the availability of an API in public beta. Along with integrations with a variety of commonly used tools — like Zapier, Typeform, and Automate.io — someone could build a better export tool. But it’s moot for me, at this point.
My next post in this series will be a first look at Obsidian, a markdown editor that operates much like Typora, working on files on the user’s computer. It’s positioned as ‘a second brain, for you, forever’. We’ll see. At least it will be markdown files, so I won’t have to worry too much about exporting data if I decide to exit.
A critical issue that gets missed too often. One advantage of getting older is that we've been burned by this kind of issue before. I now tend to look at export/underlying datastore questions at the outset. It's one of the reasons I was hesitant about Notion when I was looking at it. It is one of the primary reasons I've chosen to work with Obsidian rather than join the Roam-cult, for example.
Came here to shout OBSIDIAN but was beaten to it