The need for simple tables in Coda
Turn Coda into your daily buddy
In Coda, tables play a prominent role. The data living in tables can be shown in various ways. These are table views. In this blog I argue that most table views are useless, although some are pretty. My main point is that we need a new controller type to onboard people with data fear. We need simple tables.
Update 1: April 16, 2024 Beta launch grid.
Update 2: July 11, 2024, launch grid
https://help.coda.io/en/articles/9585920-arrange-content-in-grids
update 3: Oct 28, 2024: grid improvementsAs you can read in the Coda documentation, the launched grid tables are too simple to my liking. You can reference them via a link, but you cannot fill out columns using buttons or automations. That said, keep on reading!
This blog is an extension on my plea for simplicity:
and a continuation of the line of thoughts developed here:
Why do we use tables?
Tables store structured data. The row logic permits fast and efficient filtering and sorting, while columns provide control over data types. One of the hardest challenges for new Coda users is getting familiar with this logic. Below an example based on a question in the community
The Coda alternative is the one below, we transpose the above logic. It is a different set up that requires a bit of reflection. You can easily add rows, which makes it a robust solution. Nevertheless, the maker asking the question, was not fully satisfied with the hiqh quality response of Rickard. We come back to that later.
In this contribution you see the patterns I wrote about in this blog:
This brings me back to the question:
Why is it we use tables in Coda ?
We use tables to store data and to calculate outcomes. Calculations are based on stored data and sometimes complimented with date driven functions like Today() or weekNumber() or manipulated via a Random() function. In short, the data in tables can be used to calculate with. Although Coda tables are far more efficient in calculating all sorts of outcomes when you master the filter logic than spreadsheets, Coda is not about number crunching because it lacks advanced number crunching features Google sheets and Excel offer. Coda is instead great to organize lists of content like inventory lists, contact lists, customer lists. To make these lists more attractive, Coda added for example.
- file attachements
- rich field types
- grouping
This makes Coda visibly better for organizational use cases than any spreadsheet. No wonder that makers started to pimp their tables and got encouraged by Coda to do so.
As maker you not only can make the content of your table more appealing, you can also use the view of a table to stress a certain logic. You can use a card view, a graph or a calendar view. They all relate to the same table, it is only a different presentation. The data does not change, only the view layer does. This opportunity offers amazing and inspiring advantages.
In short we use tables to store data, to calculate with it and to present data. Data is not necessarily based on calculations. A reporting of something is not a calculation, but maybe worthwhile to show like your sales numbers.
Not everybody likes tables
There are people who love spreadsheets (and tables), but a far larger groups avoids using them. When you ask, they may say that spreadsheets are not for them, that they are not a number person, not good with math etc.
Based on the changes Coda makes, I am rather sure that they found out in user groups that people easily feel lost in table focused Coda. Instead of adapting their marketing efforts and trying to attract users who feel comfortable in tables, they decided to hide the parts that feel difficult. It started with pushing the formula builder out of sight — which they rebranded with the confusing term ‘calculate’. In buttons they offer first preset values, although they are of little help in most cases. You have to make at least one click extra to enter the formula editor. The launch of the compose value type follows the same pattern. In general the idea is to make Coda easier by hiding anything related to formulas. Forgive me my criticism, but you can even see it back in how they implemented the weekday() logic, a functional settings depending on a doc setting. They did not read this blog very well.
Pushing calculations out of sight feels a bit odd for a software that is to a large extend powerful because of its brilliant formula language. That makes me believe that these efforts won’t help to increase user adaptation. Those who are uncomfortable with formulas are not helped by preset values , they simply don’t want to see anything of it at all. If you don’t like formulas, Coda is of little help to you, unless you have somebody preparing a doc and you are a pure user. That is a different story and this is the scenario I explore first. It also relates to my conviction that Coda should make a clear distinction between makers and editors, both in permissions and in costs. Today Editors are makers light and that not only confusing, it is getting incredible expensive due to all sorts of work arounds we have to introduce. I’ll let you know the day they contact me for advice 🔔.
Two types of makers
I am going to discriminate between two groups. First we look at makers trying to keep data out of sight.
I previously wrote about how data cannot be hidden in any doc. The Coda set up suggest you can filter data out of view (which is okay for most use cases) but this behavior is bypassed via the search bar, the modals and the user icon. No bad intent is required to get to see data that is not meant for you. Features we are waiting for won’t solve these issues. The remarkable silence on behalf of Coda is shocking, they should care and not pretend they don’t.
To avoid that people see data not meant for them, these people should not have access to the doc these tables are living in. Solutions promoted by Coda makers here, give a false impression.
That said, any B2B oriented software should solve these issues for its users natively and not require any bricolage. Coda decided two things: first not to communicate about it and second not to solve it. That leaves us with one alternative: distribute your sensitive doc content over various docs.
You can pimp tables as much as you want, it only makes sense when everybody can see everything, which is rarely the case. It happens in for example company wikis, but more often than not, makers intentionally try to hide data like in a voting table or one of the other well know rituals Coda promotes. As shown, this hiding can be breached any moment, even in a voting table and all very simple and fast. In short, makers try to create a safe space for other users, but they have to become resourceful to make it work (building bridges between docs).
The second group makers work with consist of people who don’t like data, don’t like spreadsheets, don’t like tables. This is a huge group of users, a group we easily overlook because they have no voice in the Coda community, partly they may not like to admit it or are unaware of their ‘data fear’. This group requires special attention.
Let me first remind you why tools like Coda are better options than spreadsheets. Not for data crunching, but to store all sorts of lists of data like tasks, sub tasks, objectives, key results, time lines, your inventory, etc. Coda is a great solution. Here is the thing, it is quite likely that those afraid of spreadsheets never used spreadsheets for keeping track of lists of all sorts. Maybe they did not at all or did it in a different tool like a normal doc (or likely MS Word). This brings us to the question how to make Coda their buddy?
How to turn Coda into your daily buddy?
We continue with the user type that feels uncomfortable with spreadsheets and tables, they are the majority of people and future Coda users. These people take notes and probably use Ms Word or a Google Doc. We are convinced that Coda serves them well when dealing with all sorts of content lists ranging from tasks to how many cars do I have in my inventory. Here we meet the great advantage of Coda offers: blending structured and unstructured data.
These users should not see tables or anything that looks like a calculation. Below a set up I created in the context of a room reservation system. You recognize the cards as a table view, but the users we have in mind, won’t see that. They only would see images with text. On top I created a simple tool to check if a room is available. You cannot make a room reservation and that is on purpose. This limited functionality is great for people on the phone. They can respond by telling when the room is available. It is an option to add a button to open a form to create a reservation.
We should construct our docs in such a way that every user with data fear loves the outcome, not the functionality behind it. Today we have a few tools helping us in getting there. Below an overview of the controls we can use. Some of them deserve an update and more love like the date picker.
In previous blogs I said that you better stay away from table views when the standard grid table is presented differently and certainly from modals (they leak). That statement holds, but not everybody agrees with me. Some makers want to have more options. I see on the other hand great use cases for charts and time lines. Technically speaking they are also table views, but in our direct experience they trigger a different emotion — they give us a certain kind of clarity. Like wise for the card view as shown. The problem with the configuration we have in Coda today is the need for locking this page. This is cumbersome and counter intuitive. Again defining editors as makers light is a costly mistake.
We need a new controller type
To make pages interesting and informative, we need a new control type. A new version of tables. There is already some discussion on how to style them and questions got asked how smart these tables should be.
There is even an official Coda inquiry to gather feedback.
Edit on March 26, 2024: a new phase got launched around the theme ‘grid’.
You can imagine all sort of content rich discussions when it is unclear which problem to solve specifically. To give an example (that surprised me) people suggested we should have a sort of excel alike functionalities in tables, because users ask for it. I can see where that comes from — I’ll come back to that — and I can see why it is likely that the suggested solutions by data lovers is not going to work for our target group. People with data fear are not served with a spreadsheet functionality. We don’t need a table that allows for any (super simple) calculation. We have already well performing tables taking care of that.
Before I dive into the table characteristics first something on the layout of the pages. Coda gave as in April 2023 the opportunity to work with columns and to have a wide version, which I love.
More style elements like custom icons (June 2023) and call outs give us tools to present data in an interesting manner. Here is certainly room for improvement, but the biggest help would be — in my not so humble view — : a controller named ‘simple table’.
What is a simple table?
It is a what it is, a table, thus columns and rows and the user decides how many of each manually or via actions. The main and only function of this simple table is presenting data. This perspective fits the logic of icons, wide views etc. It helps the user of the doc to understand data better. It is al about presentation. Eye candy if you wish, but so important to make Coda your buddy in your daily operations.
In simple tables columns have names and value types like text, numbers, images. This matters because we should be able to relate to these tables (since they are a controller type) and fill them out with values of all sorts using buttons and automations. For example — and I relate to the use case I started with — users want to show data differently (vertical). I showed this principle in this post.
The simple table should support all kinds of formatting, including hex colors in the most easy way. Coda should stretch their formatting logic for this type of table to limits we only can dream of today. It is all about visualisation, not about functionalities. This table will have one view only, the grid view, no cards, no timelines. They are and stay simple tables.
The improved grid logic does not meet my expectations. The improvements are the ability to add colors and to turn your grid into a table.
Transpose
As you can see I showed how to transpose in a simple manner. I apply this method in most docs. We store data horizontally, but users love a vertical presentation. When introducing simple tables we need a transpose tool. AI could be of great help, but for the moment I am afraid it won’t listen well enough to respect our needs in a deterministic way. A formula based solution may be needed and as you see, it is not so difficult to create a transpose function in Coda — I created a formula which used existing functions.
Advanced tables
We actually need an other table type. Tables that — due to their direct link with for example Azure or AWS — can handle millions of rows and updates in milliseconds. These tables mainly mirror what happens outside Coda, but are fueled and viewed via Coda. This is a premium feature and will help to make the application more enterprise ready. Those who believe that any pack will solve this, are mistaken. It should be a native integration. Period.
You reached the end of this long read. I hope you take away that I deeply care about Coda, but that I am also a bit worried about the product development process. Sometimes I wonder if the promoted ‘Eigen questions’ can drive you with full conviction off the cliff. I hope that the Coda team shows me wrong.
I hope this article was informative and helpful. Did it help you to solve a problem you unlike would have solved other ways? What about a donation?
My name is Christiaan, and I regularly blog about Coda. While this article is free, my professional services (including consultations) are not, but I’m always happy to chat and explore potential solutions. You can find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.
