10 min read

Coda at scale: managing view count

Explore why view counts grow and learn strategies to reduce them

Table views are a fantastic way to interact with your data and enable you to slice and dice tables in an infinite number of ways. However, too much of a great thing is rarely good, and the same is true for views. This guide explores why having too many views of a table is detrimental to a doc, and provides some alternatives that will keep your docs performant and easy to use.

What you'll learn:

Why high view counts are risky.
Common doc structures that lead to large view counts.
Doc schemas that keep view counts low.

What you'll need:

What are the risks?

When thinking about view counts, there are two main concerns:

Usability: As view count increases, it can become increasingly difficult for users to understand what each view is showing and know when they should use each one. Even if the user knows what view they need, finding that specific view becomes hard in a sea of many.
Performance: When a row changes, every connected view needs to know about it - based on the change, the row could get filtered in or out, switch groups, change sort position, or more. With higher view counts, the amount of time spent tracking these changes increases as well, which can result in performance issues.

Causes and alternatives

There are some common doc setups that lead to large view counts.

Scenario 1: Individual user views

In this setup, individual contributors make their own views to see only their assigned items. While this works fine small teams, view count is directly proportional to team size. As the team grows, so does view count! The better alternatives:

The user filter

Replace user specific views with a single "My Rows" view. By adding a filter with an owner equal to the current user, the view will automatically filter and show the things owned by the viewer. Everyone sees only their rows, but only one view is created.

Enable the filter bar

The filter bar is great way to set up dynamic filters that anyone can quickly use to filter data just for themselves. These filters appear directly directly above the table, beneath the table title. Users can easily locate, click, and modify these filters to instantly change how the table data is filtered. The filter bar is user specific. Team members can choose any criteria they’d like, and changes in the table will only be reflected for them — other team members will not see any.

Scenario 2: Project pages

Let’s say your team has a project hub where each project has its own page or section of the doc. You’ve got a main table for all tasks associated with all projects (using the one big table schema like the expert builder you are!) and filtered task views on each project page. As with the individual views scenario above, the number of views increases proportionally with the number of projects you have. The better alternatives:

Dynamic project dashboard

If each of your project pages are the same, consider making a “project dashboard” that is controlled by a canvas control. Here, you go to the same view for every project, and change which project you’re viewing using the dropdown control. In this way, you can have an unlimited number of projects, but always have just one view.

Hub and spoke docs

Alternatively, consider breaking projects out into their own docs. You can keep your “all tasks” table in a centralized "all projects" hub doc, and cross-doc a filtered view of that table into individual “spoke” docs for each project.

Scenario 3: Views in repeating templates

We see this pattern a lot with meeting notes. Let’s say you have a meeting notes table, and a view of action items in each notes section, filtered for that day. Well, the number of views you have of that action item table equals the number of meetings you have, and we all know how many meetings there can be! The better alternative:

A relation column

Instead of adding a view to the notes section of the canvas column, have a relation column connected to the accessory table, display it as a subtable. You will have the same “view” experience, but relation columns are more performant than individual views. Learn more about implementing relation columns here.

Change management for doc updates

If you decide to update an existing doc with lots of views to one that is more efficiently designed, you'll need to be strategic with how you roll out the updates. While it is advantageous to address risky documents in the long term, altering a widely used document or process may cause disruptions to daily business operations if not managed properly. This tutorial offers guidance on how to plan for a seamless and effective migration process.

Was this helpful?

YesNo