10 min read
Coda at scale: managing page count
Pages are a great way to organize content...until they aren’t.
What you'll learn
- Why page count matters
- Ways to reduce page counts
- Scalable doc schemas
What you'll use
- Tables and views
- Copying pages to docs
Why does page count matter?
Usability
Part of Coda's magic lies in its ability to customize intuitive spaces for your work—and long lists of pages can be tough to navigate. It gets overwhelming trying to find the specific section or page you're looking for, especially when there are thousands of pages to go through. It's frustrating and inefficient to have to dig through other teams' stuff just to find what you need. Clutter is nobody's friend.Performance
In most cases, the usability of Coda docs will start to suffer before the performance does. You can have thousands of pages in your doc before it starts to slow down. But eventually, performance will start to be an issue. The actual number of pages that will cause slower loading times depends on how much content is on each page, but around 5000 pages is a rough estimate.Why do docs get so big?
There are two common doc structures that can bloat page counts.1. Repeating templates
These docs have pages that get copied over and over again. The most common example of this is meeting notes: a new page is made for every meeting. You'll also see this happening a lot with project briefs, where a new page or set of pages is created for each new project.Meeting notes where each meeting gets it's own page
2. Broad content libraries
These docs have all sorts of info on different topics, usually from different teams. A classic example is a company-wide wiki, where each department has their own section but everything is in one big doc. You can also see this setup in some project docs, where all the info about the projects a department is working on is kept in the same doc.How can I structure docs to scale?
1. Consider a table.
Tables with a canvas column are super useful for keeping a ton of "pages organized and easy to find. Tables offer a bunch of options to help you organize and search for content, so you won't have to scroll through a messy list of pages anymore. Consider how you'll be using your doc. If you think you'll need to create new pages frequently, using a table could be a great choice. This technique will not make a document more efficient from a technical point of view, but it will address usability concerns.Table of meeting notes, shown in detail view
2. Consider multiple docs.
In general, it's better to have fewer things in your docs rather than more. This way, users don't have to dig through pages that aren't relevant to them, and your docs can be more focused on specific audiences and situations. Typically, docs are created with a specific use case and audience in mind. If different parts of your doc are meant for completely different audiences for reasons like UX or privacy, it might be a good idea to separate them. And if you find yourself constantly making pages that will only be used by a small group of users, it might be worth creating a new doc just for that group.Oops, my doc already has too many pages.
Have a mega doc on your hands? That's ok! There is no time like the present to make a few changes to your doc or workflow and reign in that page count. Consider the following solutions:1. Split up existing content.
Use “Copy page to doc” to split sections of your large doc into smaller, more focused docs.Copying a page to another doc
- Team-based: Does your big docs have separate team pages or spaces for several different teams? Consider making each of those spaces it’s own team doc.
- Topic-based: Does your large doc house information on multiple different projects or subjects? Consider making a separate doc for each.
- Time-based: Create a new doc for specific time periods, like a new OKR doc for each quarter.
2. Archive and start fresh.
In certain cases, you have the option to completely stop using the old content, label it as archived, and start working from a more streamlined doc. This method is great for situations where you don't need to refer to older content frequently, but want to keep it around just in case. A perfect example of this is meeting notes. If you're switching from taking notes in separate pages to storing them in a single table, it would make sense to announce, "From now on, let's take notes in this table. You can find all previous notes in the original doc.”How should I handle the change management?
While it is often advantageous in the long run, making improvements to a widely used doc or process may cause disruptions to daily business operations if not managed properly. Check out this guide for tips on how to plan for a seamless and effective rollout.Was this helpful?
YesNo