Some suggestions for beginners

⁠

If you find this document useful, please consider buying me a

Ko-fi here.⁠

⁠

Somebody asked what is best practice for Coda. “Best practice” is a nebulous term, because it will always depend on the purpose of your doc and your personal style of working and building. Please bear this in mind, when I give some pointers from my personal way of doing things. Everybody is different.

One last thing before I start: When you are new to Coda, or to no-code applications in general, be aware that it will take some time for you to get “the hang of things”. Do not build your magnum opus in the first three months, because you most likely will do it over. And sometimes more than once. And this is especially true if you are skilled in spreadsheets or databases, like Excel or Access. Coda is very different to those tools, sometimes in subtle ways. Start on the smaller side, and try different ways to do things.

I’ll share a few ideas that I personally adhere to:

Keep the document count to a minimum.

With this I mean that a Coda doc is not like a word document or a spreadsheet, which are usually limited to a single topic. The strength of Coda really comes to the fore when you have all of your information in one place, and start integrating that.

Here is an example from my “other job” as an SAP consultant:

(Note: I have since found out that the number of tables I had in mind for the doc, was too large for Coda and/or the pack I was using to handle.)

⁠

SAP Knowledge Acquisition Toolkit⁠

⁠

Typically all the configuration information is prepared in spreadsheets, before it is uploaded into the SAP ECC or SAP S4 system. These lists of information are typically stored in separate spreadsheets, or at best in separate tabs in one spreadsheet. In this example there is a list of Material Types, Account Category References and Valuation Classes.

These three tables are interrelated but it is not visible at all when viewing the three tables. However, Coda can for very little extra effort combine those table together to give you the view shown in the screen shot below. In spreadsheets it is NEVER going to be possible to go from Material Type to Account Category to Valuation Class, and see which valuation classes are allowed for which Material Type.

But wait, that is not all!: Now you can type, anywhere in your document, @ and any piece of information in this table. Coda will then provide you with a link to that table. Whether you want to include that information in a special section, or whether you simply needed a reminder.

⁠

For my personal PIM, I have just one doc:

In that doc is my “dictionary”, my list of interesting books, webpages, Facebook comments to get back to, my expense tracker, my (people and business) contact list, my action list, etc, etc. And the topics keep expanding, e g the expense tracker has evolved into a rudimentary accounting package. For banks with CSV files, I cut and paste, for banks that do not, I parse the line in Coda. It can do journals. And report month by month. The list of webpages feeds into my “research” area.

What I do have separate is a Coda example doc (this doc), because I often share that with the community, and of course docs that I do for my clients.

Keep as much as possible in one table.

There are two dimensions to this, rows and columns. As far as rows go, i have not come close to pushing Coda. People talk about 10,000 rows being ok, of course depending on the formulas and other recalculations in the table. If number of rows becomes a problem, just archive to another table, or split on some criteria, depending on the situation.

With columns I find that people split tables too easily, a holdover from 3rd normal form design. Much can be achieved with filters and views on a single table. So what if not all columns are always populated?

I would rather have one business partner table, than separate customer and vendor tables, for example. In another dimension, I would keep an invoice in one table, not a separate header and item table.

I keep one table per page.

It is also generally recommended to keep the tables themselves in a special “back office” area, and use views of those tables in the rest of the doc. It keeps things conceptually separate, and also allows you to configure characteristics that you want to propagate to all views of a table.

Overall, keep things simple.

But then we get into the whole debate on whether e=mc^2 is a complex or simple formula….

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.