I am a huge Notion supporter - it's our organizaation's brain and one of our most important tools.
However, having used the tool for more than a year at a 20 person org, one of the biggest pain points I have seen is people not knowing where to place new pages. There is "Notion anxiety" about not wanting to mess up the board.
One thing we've done to address this is by adding two common tables, the Documentation table and the Meetings table. Anytime anyone wants to create a new doc, they can simply add it to the documentation table and then tag it to their team, and we have a full list of all of the docs everyone has written. From there, if a certain piece of documentation needs to be somewhat else, it can be pulled out and moved there. Additionally, each team member has a default "project board table" and if you say need to create a quick to do list, you should just add it to your personal board. Having these "default tables" rather than a special table for each specific project may really help your team.
Notion requires intentional planning, and you need to be opinionated about the architecture. If you just keep adding things on haphazardly, it's going to turn into a mess.
Finally, I do agree with OP that notifications could signicantly be improved. If anyone from Notion is reading this, please think of notifications like emails. At the moment, notifications are only in the state of read/unread, and as soon as I open my notifications, they clear. Instead, I want my notifications to be a mini-inbox, where I can view notifications, respond to notifications, archive completed notifications, and filter notifications into channels (the same way I can filter emails). Notifications are a to do list, and should be thought of as such. Having this set up would address OPs concern about being able to filter notifications at the email level by setting the filtering logic in the app.
My team started using Notion last year, and this rings true:
> one of the biggest pain points I have seen is people not knowing where to place new pages
I have also seen this happen with every knowledge-base software I have ever used. A team’s knowledge-base (which represents a shared domain model) is evolving all the time, as people’s understanding of the domain evolves, and sometimes there is information that is valuable but doesn’t have an optimal home in the current domain model.
The only way I’ve seen it successfully managed is by having different standards for information structure depending on how well the information’s role is understood by the org.
You need dumping grounds where one can quickly jot down relevant information for later processing, and you need areas that present a more structured view of what you know to support decision-making, and a schedule for consolidating and structuring the unstructured knowledge. This creates far less pressure to put everything in the right place at first.
I think of it like a write-ahead log, or like how food is dumped into the stomach before the individual nutrients are extracted and delivered to various destinations around the body - you don’t deliver each nutrient molecule to its destination before eating another.
It's also how high write-throughput databases work. First write the data in a way that's optimised for getting it committed to storage and at high density.
Only later, in the background, maybe at a more convenient time, is the data reorganised for finding and reading things.
Interestingly, my company’s “knowledge base” doesn’t really have a structure for the most part. I can just publish a page in it and share the URL around, and most people interact with it via search. So no matter how I organize the page, people generally find it without going through some kind of hierarchy. I think this works really well when there are tons and tons of pages, and I also don’t have to be concerned about how to organize it.
This is exactly my pain with Notion for personal knowledge management and why I switched to Roam Research. In Notion, I have all my pages in one table, plus tags, in order to manage the hierarchy without sinking a huge amount of time it. But I think Roam isn’t very well-suited for collaborative use cases at the moment.
> I want my notifications to be a mini-inbox, where I can view notifications, respond to notifications, archive completed notifications, and filter notifications into channels (the same way I can filter emails).
This is exactly how the most recent release works, no? Notifications are "unread" by default, but "read" when you see them -- however they stay in the "Inbox" tab of the notifications panel. You can reply directly from there, or mark them as done by clicking the "x" to remove them from the Inbox. Everything you described but filtering.
> one of the biggest pain points I have seen is people not knowing where to place new pages. There is "Notion anxiety" about not wanting to mess up the board.
> One thing we've done to address this is by adding two common tables, the Documentation table and the Meetings table.
Definitely. It is important to have one or more fairly undifferentiated tables that function as an inbox or a repository of generic notes into which people can dump stuff easily.
Maybe the stuff gets triaged and organized later, or maybe the stuff in the notes tables just stays as notes - the search functionality got much faster and better a couple months ago and that can surface unorganized stuff.
Linked databases also help for this. You can create a linked db filtered for a team or tag on every team page. Create meeting docs from there, and then new meeting docs show up there and live in the master table with appropriate properties to categorise them.
This isn't a new phenomenon - my favorite past example of this is the FileMaker series of applications.
The biggest hurdle to building most great tools isn't the coding, it's the process of carefully thinking about the problem and designing something that fits without being overly complicated or too basic. Incidentally, learning to code often gives you some basic understanding of this issue.
No-code tools like Notion or Filemaker throw users straight into the deep end of designing their own solutions, and because of the data-agnostic nature of the tool it's difficult to build in guardrails to stop the user from over-complicating their solution.
At the same time, I believe there is value in allowing people to over complicate their solution. Let the user learn how to simplify their workflow over time instead of limiting them from the start.
Thank you - great comment. I have the same issue with the social networks - they are too limiting. They give you a little box to type your paragraph into. Give people hypertext - yah they’ll make a mess, but they’ll do amazing things as well. And people will figure develop the skills over time.
As a pilot run - tried migrating small amount of knowledge base from Evernote to Notion but it just feels too overwhelming. Upending existing information architecture (with umpteen possibilities re: templates) quickly gets exhausting.
This is when I realized, I need an opinionated tool. Gave up and went back to Evernote.
> Gardening Notion boards becomes an activity in itself … Notion doesn’t get out of the way, it’s malleability always invites you to tweak your boards further, to add another property, to connect another relation, to add another view, to go through your board and complete data on all cards.
Sounds exactly like the problem so many folks here are having with Emacs. Malleable tools, while powerful, often become a huge time sink if you go into the rabbit hole of tweaking them too much. And it's often hard to resist.
If you think of Notion as your team wiki, it's an exceptionally good tool.
Probably the best "wiki" I've ever used. I've used Trac, MediaWiki, MoinMoin, Confluence, GitHub Wiki (+ Gollum), and finally Notion. Notion is easy-to-use for non-developers, but still mostly supports Markdown. It makes rich content easy, including tables, in-line images, code snippets. It supports GDoc-style real-time editing, fine- & coarse-grained permissioning, in-line comments, mentions, and versioning. It's a great wiki.
It's really, really easy to over-use a wiki for everything. It's also really easy for wikis to get under-utilized, out-of-date, etc.
But if you're a fully distributed team with 20+ people, you need somewhere to store your team policies/practices, your culture, your vision/roadmap, etc. Notion is a great fit for this.
If you try to use Notion as the "hub for all of your work", you'll certainly be disappointed, just as you would have been using any other "wiki" product for this. For example, though we use Notion as our team wiki, we still use:
- GitHub Issues for bug reports, because it's built perfectly for this, and links with code and pull requests seamlessly
- GitHub project boards for code-oriented project management, because it can kanban-ize GH issues to visualize capacity, issue stages, and project/milestone progress
- Trello for non-code project management, because if you're not a programmer, Trello is much simpler than GH Issues/Projects, and nails the experience of a kanban project board
- StackOverflow for Teams for FAQ-oriented team & product knowledge base
- GDocs for long docs, forms, slides, spreadsheets, and so on -- and especially when these need to be shared "officially" with external parties
- Slack for real-time chat and notifications, often linking to the above tools
I think part of the dissatisfaction expressed in this article is that Notion is being hyped (especially with the VC valuations) as "the future of all work", similar to Slack in a prior startup generation.
Slack is better IRC for busy teams who prefer a SaaS. Notion is better MediaWiki for busy teams who prefer a SaaS. Neither is an all-in-one work hub. Neither is "the future of work". They are just communication/collaboration tools in different categories.
The Achilles’ heel for use as a simple wiki, IMO, is that you can’t just make a simple table for layout, it has to be a “database”. This is OK as long as you stay in Notion, but it sucks for exporting.
Dropbox Paper’s table implementation is really nice (now if they’d just hurry up with their Dropbox 2020 thing and unify Paper and regular Dropbox folders...)
After a few months using Notion at work, I feel such a relief when I get directed to a regular office-style doc (Google docs in our case, but Office would be just as fine).
This week I formally proposed my team move out of Notion for all internal documentation and back to google docs.
Notion is the best and easiest to use wiki there's ever been, I guess, but the reasons I tried wikis before and never stuck with them still apply to it.
Right there with you. I got relatively used to Notion, then a co-worker and I started collaborating on a Google Doc and it felt refreshingly...serious? I'm not sure how to describe it other than I took it more seriously than I do Notion and all its emoji nonsense. It feels like Notion isn't the place where real work gets done.
Fwiw I came from a law background so might value the 'seriousness' of an app more than others.
I’d love to hear why you prefer word processor docs over a Wiki?
For me, Wikis solve the big problem with word processor documents: It’s hard to define the relationships between documents. But I’d also love to hear other perspectives, e.g., what people dislike about them.
Some quick thoughts, they may be incomplete or ambiguous but hopefully will provide some idea:
- A wiki combines content and organization of that content. This is a strength (documents know about each other) but also a weakness (the organization system must understand and support the types of documents it contains). I'll expand in the next points.
- When I use a filesystem to organize, it doesn't need to care what types of documents I throw in there. In a wiki you are typically led to keep copies, not originals, of such alien document types, as attachments to a wiki-supported document.
- If you are willing to commit to a certain organization filesystem (this is not optional in a wiki), you can usually hyperlink documents using your filesystem's url format (e.g. gdrive urls).
- I have found repeatedly over time that the very ease of use of multiple documents across a wiki leads to people spreading information across multiple items "because it's so easy to navigate". But, similar to my impressions with codebases where functionality is heavily spread and atomized across a multitude of files and small functions/classes, this can hinder the ability to grasp or comprehend the compete intended contents of a document. (see http://number-none.com/blow/blog/programming/2014/09/26/carm... for more about atomized code)
- As outlined in the article, wikis tend to have to duplicate a lot of existing document editing, layout and rendering technology and standards, and very rarely reach the level of power and quality that dedicated tools have. In keeping with the intent to make them easy to use and navigate, they end up making the easy stuff easier (great for non-tech or beginners) but the hard stuff harder. So, for something trivial they are great, for complicated stuff they become a hindrance. I can't remember the last time I wrote or formatted something in Notion and didn't feel like I was fighting a 2-decades-old word processor.
- Extra customizability like Notion offers, make it quite powerful but also exacerbates the above point, because it's not just the basic built-in feature that may work half as good as they could, but the customizations end up in a similar state (because it's not a full app development platform).
It would be great if Docs had transclusion across documents.
The best there is now is embedded sections of Sheets and Slides, but being able to link sections across documents would be awesome for complex documentation.
I used to be in the camp of finding better workflows with these tools. I ended up just gardening them,losing time elsewhere.
Now I just prefer the simplest dumbest tools possible for specific use cases. Notebook + sticky notes for task mgmt, GitHub repo for code snippets, simplenote for private information, Google docs for collab
Thank you for pointing out Simplenote. All I've ever wanted is the ability to take basic textual notes on any device (including Windows) with perfect sync and with dead simple but native mobile apps. OneNote got me pretty close, but the sync feature is far too buggy to rely on for serious work; I can't deal with syncing issues when I need to pull up a note in a meeting on my phone. I'd looked at Notion but it offers much more than what I need, so using it just for basic notes was clunky. Simplenote appears to be exactly what I want.
ah yeah onenote suffers the same problem as notion. Too many ways of doing things.
I've learned to take less notes over the years. If I need image or gif support I just use slack to shoot myself the information, slack's been my new temporary dumping grounds
This is an old problem, it’s a mixture of amusement and resignation to see it keep coming up in new areas.
In the salad days of my early undergrad, i spent about three weeks hand tuning (very poorly) an init.el, learning latex, fiddling with auctex and bibtex and makefiles, and doing no work. Quite literally sophomoric.
Learned a lot about elisp, and fuckall about mechanics, but dang if i didn’t have the prettiest lab reports.
Hard to look down upon spending 3 weeks learning elisp and latex during undergrad! Tell your employer you did this and they'll be less kind probably :D
as it turns out, dropping months into obscure trivia of how to do all this silly nonsense has paid off in my professional life, but it sure felt like wasting time at the time.
Readit News
However, having used the tool for more than a year at a 20 person org, one of the biggest pain points I have seen is people not knowing where to place new pages. There is "Notion anxiety" about not wanting to mess up the board.
One thing we've done to address this is by adding two common tables, the Documentation table and the Meetings table. Anytime anyone wants to create a new doc, they can simply add it to the documentation table and then tag it to their team, and we have a full list of all of the docs everyone has written. From there, if a certain piece of documentation needs to be somewhat else, it can be pulled out and moved there. Additionally, each team member has a default "project board table" and if you say need to create a quick to do list, you should just add it to your personal board. Having these "default tables" rather than a special table for each specific project may really help your team.
Notion requires intentional planning, and you need to be opinionated about the architecture. If you just keep adding things on haphazardly, it's going to turn into a mess.
Finally, I do agree with OP that notifications could signicantly be improved. If anyone from Notion is reading this, please think of notifications like emails. At the moment, notifications are only in the state of read/unread, and as soon as I open my notifications, they clear. Instead, I want my notifications to be a mini-inbox, where I can view notifications, respond to notifications, archive completed notifications, and filter notifications into channels (the same way I can filter emails). Notifications are a to do list, and should be thought of as such. Having this set up would address OPs concern about being able to filter notifications at the email level by setting the filtering logic in the app.
> one of the biggest pain points I have seen is people not knowing where to place new pages
I have also seen this happen with every knowledge-base software I have ever used. A team’s knowledge-base (which represents a shared domain model) is evolving all the time, as people’s understanding of the domain evolves, and sometimes there is information that is valuable but doesn’t have an optimal home in the current domain model.
The only way I’ve seen it successfully managed is by having different standards for information structure depending on how well the information’s role is understood by the org.
You need dumping grounds where one can quickly jot down relevant information for later processing, and you need areas that present a more structured view of what you know to support decision-making, and a schedule for consolidating and structuring the unstructured knowledge. This creates far less pressure to put everything in the right place at first.
I think of it like a write-ahead log, or like how food is dumped into the stomach before the individual nutrients are extracted and delivered to various destinations around the body - you don’t deliver each nutrient molecule to its destination before eating another.
Lovely analogy.
It's also how high write-throughput databases work. First write the data in a way that's optimised for getting it committed to storage and at high density.
Only later, in the background, maybe at a more convenient time, is the data reorganised for finding and reading things.
This is exactly how the most recent release works, no? Notifications are "unread" by default, but "read" when you see them -- however they stay in the "Inbox" tab of the notifications panel. You can reply directly from there, or mark them as done by clicking the "x" to remove them from the Inbox. Everything you described but filtering.
> One thing we've done to address this is by adding two common tables, the Documentation table and the Meetings table.
Definitely. It is important to have one or more fairly undifferentiated tables that function as an inbox or a repository of generic notes into which people can dump stuff easily.
Maybe the stuff gets triaged and organized later, or maybe the stuff in the notes tables just stays as notes - the search functionality got much faster and better a couple months ago and that can surface unorganized stuff.
The biggest hurdle to building most great tools isn't the coding, it's the process of carefully thinking about the problem and designing something that fits without being overly complicated or too basic. Incidentally, learning to code often gives you some basic understanding of this issue.
No-code tools like Notion or Filemaker throw users straight into the deep end of designing their own solutions, and because of the data-agnostic nature of the tool it's difficult to build in guardrails to stop the user from over-complicating their solution.
At first I was excited by all of Notion’s possibilities, but after a while I felt this was not a strength but a weakness.
We were on Notion for six months, without much enthusiasm. I switched us to Clubhouse + Stack Overflow for Teams and we’re loving it.
As a pilot run - tried migrating small amount of knowledge base from Evernote to Notion but it just feels too overwhelming. Upending existing information architecture (with umpteen possibilities re: templates) quickly gets exhausting.
This is when I realized, I need an opinionated tool. Gave up and went back to Evernote.
Sounds exactly like the problem so many folks here are having with Emacs. Malleable tools, while powerful, often become a huge time sink if you go into the rabbit hole of tweaking them too much. And it's often hard to resist.
Deleted Comment
sadly vim too :(
Probably the best "wiki" I've ever used. I've used Trac, MediaWiki, MoinMoin, Confluence, GitHub Wiki (+ Gollum), and finally Notion. Notion is easy-to-use for non-developers, but still mostly supports Markdown. It makes rich content easy, including tables, in-line images, code snippets. It supports GDoc-style real-time editing, fine- & coarse-grained permissioning, in-line comments, mentions, and versioning. It's a great wiki.
It's really, really easy to over-use a wiki for everything. It's also really easy for wikis to get under-utilized, out-of-date, etc.
But if you're a fully distributed team with 20+ people, you need somewhere to store your team policies/practices, your culture, your vision/roadmap, etc. Notion is a great fit for this.
If you try to use Notion as the "hub for all of your work", you'll certainly be disappointed, just as you would have been using any other "wiki" product for this. For example, though we use Notion as our team wiki, we still use:
- GitHub Issues for bug reports, because it's built perfectly for this, and links with code and pull requests seamlessly
- GitHub project boards for code-oriented project management, because it can kanban-ize GH issues to visualize capacity, issue stages, and project/milestone progress
- Trello for non-code project management, because if you're not a programmer, Trello is much simpler than GH Issues/Projects, and nails the experience of a kanban project board
- StackOverflow for Teams for FAQ-oriented team & product knowledge base
- GDocs for long docs, forms, slides, spreadsheets, and so on -- and especially when these need to be shared "officially" with external parties
- Slack for real-time chat and notifications, often linking to the above tools
I think part of the dissatisfaction expressed in this article is that Notion is being hyped (especially with the VC valuations) as "the future of all work", similar to Slack in a prior startup generation.
Slack is better IRC for busy teams who prefer a SaaS. Notion is better MediaWiki for busy teams who prefer a SaaS. Neither is an all-in-one work hub. Neither is "the future of work". They are just communication/collaboration tools in different categories.
Dropbox Paper’s table implementation is really nice (now if they’d just hurry up with their Dropbox 2020 thing and unify Paper and regular Dropbox folders...)
This week I formally proposed my team move out of Notion for all internal documentation and back to google docs.
Notion is the best and easiest to use wiki there's ever been, I guess, but the reasons I tried wikis before and never stuck with them still apply to it.
Fwiw I came from a law background so might value the 'seriousness' of an app more than others.
For me, Wikis solve the big problem with word processor documents: It’s hard to define the relationships between documents. But I’d also love to hear other perspectives, e.g., what people dislike about them.
- A wiki combines content and organization of that content. This is a strength (documents know about each other) but also a weakness (the organization system must understand and support the types of documents it contains). I'll expand in the next points.
- When I use a filesystem to organize, it doesn't need to care what types of documents I throw in there. In a wiki you are typically led to keep copies, not originals, of such alien document types, as attachments to a wiki-supported document.
- If you are willing to commit to a certain organization filesystem (this is not optional in a wiki), you can usually hyperlink documents using your filesystem's url format (e.g. gdrive urls).
- I have found repeatedly over time that the very ease of use of multiple documents across a wiki leads to people spreading information across multiple items "because it's so easy to navigate". But, similar to my impressions with codebases where functionality is heavily spread and atomized across a multitude of files and small functions/classes, this can hinder the ability to grasp or comprehend the compete intended contents of a document. (see http://number-none.com/blow/blog/programming/2014/09/26/carm... for more about atomized code)
- As outlined in the article, wikis tend to have to duplicate a lot of existing document editing, layout and rendering technology and standards, and very rarely reach the level of power and quality that dedicated tools have. In keeping with the intent to make them easy to use and navigate, they end up making the easy stuff easier (great for non-tech or beginners) but the hard stuff harder. So, for something trivial they are great, for complicated stuff they become a hindrance. I can't remember the last time I wrote or formatted something in Notion and didn't feel like I was fighting a 2-decades-old word processor.
- Extra customizability like Notion offers, make it quite powerful but also exacerbates the above point, because it's not just the basic built-in feature that may work half as good as they could, but the customizations end up in a similar state (because it's not a full app development platform).
The best there is now is embedded sections of Sheets and Slides, but being able to link sections across documents would be awesome for complex documentation.
Deleted Comment
Now I just prefer the simplest dumbest tools possible for specific use cases. Notebook + sticky notes for task mgmt, GitHub repo for code snippets, simplenote for private information, Google docs for collab
I've learned to take less notes over the years. If I need image or gif support I just use slack to shoot myself the information, slack's been my new temporary dumping grounds
In the salad days of my early undergrad, i spent about three weeks hand tuning (very poorly) an init.el, learning latex, fiddling with auctex and bibtex and makefiles, and doing no work. Quite literally sophomoric.
Learned a lot about elisp, and fuckall about mechanics, but dang if i didn’t have the prettiest lab reports.
as it turns out, dropping months into obscure trivia of how to do all this silly nonsense has paid off in my professional life, but it sure felt like wasting time at the time.