Coda and SMB readiness — 3P’s
Permissions, Print — PDF & Performance
Coda: a doc as powerful as an app, continually evolving. One wonders why all the app like features Coda blends with document logic do not yet convince most Small and Medium Businesses owners all over the planet. The tool is versatile, smart, good looking and most of all a great help in solving day to day business issues efficiently.
However, for the main and larger group counts that they compare Coda to what they know and the programs they are used to. This group does not compare functional languages and their respective benefits, they look for something similar and better than what they use today. This gets tricky easily. Coda has many similarities with well know products as Word, Google Docs, Excel, Google Sheets and so on, but it differs fundamentally on how to blend structured and unstructured data. In fact it does it way, way better even to the extend that it feels overwhelming.
All these great advantages are taken for granted or sometimes not even noticed at all by business users want to do — for them — simple stuff with Coda like printing an invoice or turning a proposal into a PDF. Most of them are not so much into voting tables or rituals, maybe the should, but they are not (yet).
This blog explores 3 suggestions that — once implemented — I believe help to turn Coda into the preferred tool for SMB all over the world. The 3 suggestions are mentioned in order of importance from my perspective.
Coda was created around the concept of collaboration. The many beloved and consequential features become cumbersome once you need to make people working together who are not allowed to share all information or who should not be able to delete /change certain columns or rows. We talk about budgets, personal details, bookings, turn over, planning etc.
Recently we had an absolute great update (more about it here) in this regard:
Previously, changing a canvas control value would update the corresponding table data for everyone. Now, you can select personal mode within the control’s settings, and the table will filter just for you.
This improvement is the way forward, but we are not there yet and I am sure that the Coda team is with me on this point. What is urgently needed to make the above working well is a table in our doc that contains the details of the users of that doc in order to manage them properly. This table should be created by Coda and be available via for example the “ / “.
The page locking does not work well enough. You can still access data from locked pages when the tables on locked pages are referenced elsewhere. Pack driven solutions to solve these matters are in my point of view at best a temporarily solution, even the very smart solution Paul provided and the Web Hook Pack Scott created. I am aware that Coda has noticed this issue and put it on their agenda to solve it.
Attention, these permissions are not related to the data security of any doc. As Paul explained in 2020, once you have access to a doc, you can hack it to obtain illegally access to the data living in that doc. This is inherent to how docs are set up today.
II — Print & PDF
There is a function that permits for printing a page and turning a page into PDF, there are even some options. Users have no control over line breaks, lay out and so forth. A doc that cannot be printed properly (into PDF) is for any SMB client, not a good enough doc. Not everything lives only as HTML on a page. Sometimes you need to send documents, invoices, proposals ect. Today this is too far away from good enough. It pops up in the community once in a while and one maker created even a Pack to print tables properly.
The text below I came across is a story about a start up writing about low code and how it served them well. They needed PDF files badly and hacked a solution together that in my understanding should be part of Coda since almost everything needed is already in place.
We also need to send a lot of documents to our customers and partners, so generating PDFs (a wide variety of them) was something we needed badly. We started of with a hack of using Google Sheets to generate PDFs. A template would be created in GSheets, and the cells to be filled up would be marked. These cells would be filled up using scenarios created in Integromat. We would then make a HTTP request to export the file as PDF and save it in Airtable from where it would be picked up by another automation and mailed out. To my surprise, within 1 year we had around 25 different documents being generated in 100s daily and these automations rarely failed. It was only after 2 years when we started reaching GSheet’s limitations of 300 requests per minute. Even then we decided not to build something, but switched to DocSpring which allows us to generate PDFs via API calls. Creating such a system would have needed months and a team of 3–4 engineers. Migration to DocSpring took 1 week. Source
As long as Coda employees express their surprise as below, I have no hopes at all that they will solve the print (to PDF) problem fundamentally. By the way, this is nice, but only a tiny step forward.
This topic is not so much about processing 100K rows in a doc (which would be great by the way and I got the confirmation for the great Coda connaisseur Joostmineur that this is possible today — Dec 2022 when I add this comment.) but more about the speed you feel at your fingertips when working in the doc. It happens that Coda gets sluggish and not only when the doc grows, also in buttons it happens when you edit formulas and when you execute an action (like building a table with a for example 4000 rows based on calculations — I use to set up a planning.
Google sheets remains amazingly fast even when filled with 10K rows and more. Today we have to find a work around when the execution of a calculation takes more than just a few seconds and this not (always) because of inefficient and or expensive functions, it partly depends on how Coda deals with calculations. We can be sure that the Coda team is improving the performance step by step and day by day, however sometimes faster is not fast enough.
Packs. Why don’t we talk about Packs as a crucial condition? Well, they are not essential in most cases. Obviously the Gmail and alike packs are of great value once you want to interact with users (via email for example) and or data living outside Coda. I like for example the VAT pack from Daniel S. It is easy and does one job very very well: it evaluates EU Vat numbers based on data living outside your doc. On top, it does it fast and accurate.
Though Packs are promising (not only to import data in your doc, but also to create new functions in your doc, like financial functions or to export data), they do not belong to the core of Coda yet. Packs are in my opinion what nuts and chocolate are to an ice cream: a topping.
The day I can show my clients how to print an invoice properly and put permissions in place while the doc remains fast as an orka processing details of 100 employees in seconds, they don’t care a lot about:
- Personalized icons
- Smarter date & currency formatting
- Markdown support
- Gantt charts
- Language related functionalities
- The code editor
- Forms and how they look
- Visualisations of all sorts
- Etc, etc.
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. Besides you find my (for free) contributions to the Coda Community and on Twitter
My name is Christiaan and I support SMB with calculations (budgets and planning) and I prefer using Coda to get the job done.
Not to forget: the Coda Community provides great insights for free once you add a sample doc.