Coda —a transparent doc
Nothing can be hidden in a doc as powerful as an app
When you create a Coda doc and you try to use it as an application, you start collaborating and you invite people to your doc. The thesis of this blog is that all users of your doc will be able to see all information, no matter how hard you try to hide it. That is not necessarily a problem once you understand its implications beforehand.
I call these routes showing information that might not be meant for you: ‘leaks’. It goes against the idea that the doc maker decides what she wants to share and what she wants to hide. In fact, Coda decided upfront for us, the makers, that all users of your doc can see everything. The unfortunate thing is is that Coda never communicated explicitly about this. They simply made it happen.
For me the main question is: are these leaks are what they seem to be? Are they gateways to access intentionally hidden data? I am pretty sure that for most readers it is obvious that this is a bug, leak or oversight in the Coda product. But what if the core products’ logic is that once you are in a Coda doc, you are allowed to see everything? What if this is a fundamental assumption underlying the rest of the product philosophy? We can test this thesis by looking for consistency.
Some community posts elaborating about what users can see:
- Page visibility by tag
- Schedule, Lock By Date/Time
- Limit the Doc Search capability
- Search for content within a doc — Security
- “Search” unfortunately reveals all “hidden” pages, all hidden data
To make my point clear, I am not writing about the challenge all web based solutions face (Google, Microsoft, etc.). More about that here and here. Instead I write about the observation that all data is in theory available to those without malicious intentions. In this blog I write about paths people stumble upon out of curiosity or by accident without doing something forbidden like hacking the source code. You can consider my positon as diametrical opposed to the soothing words found here.
I hope that when you read this blog you understand why it is important to structure your data, including users in a proper way: distributed over various docs. More about my vision on synced docs in the blog:
The ‘leaks’ discussed in this blog
You have to be aware of the fact that for example, when you have two teams in one doc and they discuss budgets in a table filtered on the users of a specific team, the filter does not work when searching for budget related info via the search box.
When leaks are so obvious, are they leaks or are they signals, messages you better listen to?
In this blog we show leaking via:
- Modals
- Search box — the strongest gateway
- The user icon
I also show why filtering on user not works as is assumed by many, although it may stop some curious users.
Leaking modals
We start with the simplest of all leaks. You find it in the modals. With forms you don’t have to worry about this, but modals are generally the in-doc way to enter new or edit existing data.
Update on March 26, 2024. In this blog post the great Coda connaisseur Joostmineur asks for feedback on how the links I show below function. In short, on top left the source table is replaced by the table that generates the modal. This specific problem becomes a bit different, but still persists, but in a more subtle manner. Objects bring you always back to the table that generates them.
Some argue:
- that we we can hide a table inside an other table living in a canvas column and filter the table based on the user.
- that we can name the view is in such a way, it does not attract attention and users won’t click on it.
- that we can create a user specific table (which is a variation on the first)
- more inspiration here
Don’t you think that this is complicated? Well I certainly do and as you might have understood from my blogs, I don’t like complications. I prefer simple stable solutions for makers and users. Simplicity arrives partly by following the rules, not by creating workarounds.
One of these rules is that Coda does not deem it necessary to hide the originating table / view in a modal, not even giving us the option to show or hide these links. It is not that they don’t know. In the community many makers have asked for it, repeatedly. Technically speaking and also from a UX point of view, this is not difficult to accomplish for Coda. At least not compared to something like permitting for a 2WaySync. Coda can create modal settings in which you toggle these links off, but they don’t.
The search box leaks
This is the real thing.
When you filter your tables on users and you hide your table in a canvas column of a table that is also filtered on users, you do not expect that people other then the intended user can access the content of the table.
The details are well explained by the great Coda connaisseur Joostmineur , although it was already noticed in 2020, as I found out via this post. I am not going to repeat the arguments you can read here, instead I focus on the peculiar mechanisms that are in my opinion failing. My suggestion is that the software should to a large extend safeguard our work.
Coda introduced table views with the possibility of filtering on users and we should be able to trust what it suggests it is doing.
This feels as a contradiction to what we have seen so far and that bothers me. The filter concept suggest that you can hide data from users, it is not consistent with the modal logic.
Update Jan 30, 2024.
Coda announced un update on the search box. It became stronger, we now can even find more information. Although I am impressed by the technical capabilities of this extended search, I am depressed by how the company communicates about this updated feature. Not a single word references the discussions we showed relevant in this blog. As if they don’t understand.
It is again the great Coda connaisseur Joost Mineur who gave feedback and showed willingness to invest time to make the team understanding what is missing from a perspective that Coda is expected be consequent in her approach.
In this discussion it would also help may Coda shed light on their ambitions. Is this a product for mainly enterprise clients dealing with OKRs and Wikis (which may explain the current behavior) ? It would be good to know. By what I can tell so far based on the Coda communication is that once you have a bit of info you want to set apart (make only visible to a selected group of people), you may consider looking for a solution that takes permissions serious. The next few months I will follow up on this.
The user Icon leaks
I was unaware of this trick until a teacher wrote about it here. It is surprisingly simple, follow the user!
The AI is NOT leaking
Is AI not a wonderful thing in our docs? All editors and makers can use it.
Here is the surprise — in this context the AI respects the active filters. The AI is not telling me the task of Gijsbert, even though there is one.
How will the story continue?
I initially assumed to find a pattern showing that Coda purposely links and thus shows data to inform the user that you cannot hide data in the doc. That would make sense from a broader (legal) perspective saying : ‘hi user, be aware that hiding is not what it looks like’. However the filter logic on user and the recently implemented AI logic give the idea that hiding is sort of working. Looking at Search and AI I can only draw one conclusion: using the search box is a gateway and leaks intentionally hidden data.
I would appreciate a transparent and formal communication from Coda stating you can’t hide data and filtering is for UX, and for UX only.
This observation relates to another ongoing discussion about permissions. The company has identified several stages in current and future development. Right now we are at stage 2 while stage 3 is being developed. It is only when we reach stage 4 that we have a product that complies to what most users feel is correct.
Supposedly, in stage 4 you can edit shared content and it will ‘sync back’ to the source doc to which you do not have access. Although the term ‘sync pages’ is likely misleading: you are working directly in the source doc.
If these sync pages honor the filters when searching, we are fine. If it doesn’t honor filters, you might need a separate view and a separate page for each user and put a filtered view on a level higher. But just like today, that might not work and if that’s the case, a major advantage of synced pages is gone. We have to wait and see, until now Coda did not share much.
Imagine that synced pages work as we hope for, then we may face a situation in which we need many more docs, even to the extend that you no longer can see the wood for the trees . Coda has to create sub folders and other mechanism to keep docs together in an intuitive way as asked for here. That is a challenge in itself, while maybe it is easier to fix the leaks in a doc.
So far this exercise has shown us a two faced concept. Coda is making it clear via the modals that data is always linked, they introduce filters — suggesting you can hide data — which you can bypass via the search box, while AI honors the filter(s).
To be continued.
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. 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.
