Hidden tables in your Coda doc
Be careful with tables and keep focus
Coda permits to blends structured with unstructured data elegantly and with little effort. The structured data lives mainly in tables. These tables are the core of any Coda doc. You rarely start writing pages full of text without having a table. It is mostly the other way around. You set up tables and you blend data living in tables with your text like a contract.
When you say table, you say formula and when you say formula you say functions and this implies logic and reasoning. Indeed some functions are difficult and there is nothing wrong with having difficult functions in your table helping you navigating your work. Reflection requires effort, although when you solve many comparable puzzles like I do, it gets faster and cleaner over time. It is a matter of practicing like driving a car or getting on a bike.
The Coda set up anticipates that most users in the doc are not doc makers, are thus not ones that set up tables, work with functions to create formulas and so on. Most users are editors with a passive Coda knowledge. They understand the outcome when they hit a button, but are often unaware of what is required to get the desired outcome. That is okay. Driving a car does not require you to become a mechanic.
My suggestion
The split between makers & editors could be defined sharper, even to the extend that editors are no longer makers light as they are today. Such a change would affect all teams and should have serious consequences for the pricing of the product. Since in this approach every team would be in need of more makers, keeping the same price would make Coda price wise unattractive. Via this link you can read how I see this logic. An alternative option is that once you are maker in another workspace, you can take up that role as well in other workspaces instead of being reduced to editor.
Coda so far did not respond to these suggestions, instead they limited the editor’s capabilities. You can no longer create or (re)name a page in a doc when you are not a maker. A product decision that eventually may generate more problems than it solves and may also become a costly affair for Coda as the gap with other software is closing (or becomes negative).
Dealing with the current situation
In the community you may get the idea that people in general love to solve all sorts of puzzles, but that seems a bit of a simplification. The community does not represent all users, only a fraction. When Coda communicates it serves 40.000 teams and we assume an average of 3 person per team, we have about 120.000 users, but this is likely more. Compared to all users in the community (about 13500), this is little.
Most people tend to say away from what is happening in the tables. Nevertheless, Coda creates the perception that tables are nice and easy. Needless to say that also well designed, a table requires coding, which requires reflection and that can be frighting for a large group of people. The often read misconception about complexity surfaces in the community from time to time when users express their frustration with not ‘getting it’. These users often talk about how difficult Coda can be, rarely how complex it can get. As explained before difficulty can be overcome, complexity we have to push back.
Don’t get me wrong, I like nicely styled tables like the one you see below. I also like a good challenge, partly because I have the confidence I can crack the puzzle. The main variable is how much time I need.
However in the current set up, any editor can change and even remove valuable information and not everything is avoidable. An editor can delete a column, can change formulas and remove a controller. The duct tape solution to not allow deleting rows in tables is a dirty quick fix, like the other Team plan related options. It requires the maker to be constant alert and it does not even avoid all kind of trouble.
Splitting the doc in two
Building smart tables is a profession. You need to apply all sorts of insights varying from company specific process to more general software skills. That is not an easy job, it takes time and there is a lot going forward & backwards before you have something that holds. The last thing you need is users breaking this logic. You also want them to enjoy the advantages related to a view of a table approach (cards, calandre, graphs, etc). Below you see how I created two action pages. These contain controllers allowing users to read or add or edit data via a modal
The modal opens via a button and the buttons are directed by controllers. Once you are in the modal you can ‘do something’ like below.
I applied all sorts of tricks for an optimal user experience. Users who want simplicity get it via this way. Those who want to see the complete table, malheureusement, can do so. I wrote about this phenome in the blog below.
It is an unfortunate set up, one that complicates the usage of modals in general and generates unnecessary confusion for users who simply only want to read, add or edit data. Many readers won’t like to acknowledge it since they — like me — love tables, but most of your colleges prefer to stay away from what they interpret wrongly as complexity. We as makers have the role to support the other users, not the other way around.
Complexity, fragility, and cost
In a separate blog I’ll wrote in more detail on direct and indirect costs related to complexity.
The argument goes like this:
- difficult does not equal complex, you can overcome difficulty by improving your skills, thus by learning
- complexity increases when clarity disappears due to a lack of oversight
- your doc becomes fragile when complexity increases
- the costs to use, maintain and improve your docs is going through the roof when the complexity passes a hard to pin point threshold. You only notice this point in your rearview mirror. Lesson: be care full and don’t pass it.
Instead of exposing users (editors) to the tables, we keep them as much out of sight as we can. We use views users access via controllers like buttons and lookups (the relations). This will automatically make your doc smaller because you won’t go far with many pages full of controllers. The split between tables and view of tables getting opened via controllers is a self-correcting mechanism. Have a look at this doc for some inspiration.
My name is Christiaan and blog about Coda. Since the summer of 2023 mainly about how to Coda with AI to support organisations dealing with texts and templates. The latest Coda AI update was on Dec 7, 2023.
Why I focus on Coda AI you can read here: ⤵️
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. You find my (for free) contributions to the Coda Community and on Twitter.
Coda comes with a set of building blocks ー like pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your doc ーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.t
