Okay, please hear me out on this! I understand that many people will not like this or agree with me, but allow users to insert and/or create actual spreadsheets inside Coda documents.
Currently, users are only able to create or insert tables that are relational databases (relational tables) in Coda documents, copy/paste portions of a spreadsheet that become relational databases, or import CSV files that also become databases.
I understand the power of relational databases, but Coda has a schizophrenic feeling for me when I use it. On one hand, the Text & Layout (i.e., “word” part of it) functions feel simple to use. I put what I need where I need it to go, and it works. The tables aspect, however, feels like overkill for much of what I am trying to accomplish and if I do need the power of a relational database (which I usually don’t), I feel overwhelmed by what it requires of me. In many cases, I am told to rethink what data I actually need or how to restructure the data so that it will work better in Coda.
Essentially, I am preparing reports that use a variety of formats or I am aggregating information in such a way that long-term storage and retrieval is not needed. If I am preparing an annual budget for my organization to present to my board of trustees, for example, inserting or embedding a spreadsheet inside the document works great. Doing it in Coda makes sense because I can add all sorts of other goodies like PDFs, images, media files, maps, and so on together in one place. Coda actually handles these items quite well. Using relational tables for the financial part of things does not make sense though and that’s where using Coda falls apart for me.
I guess I’m just a caveman. As a caveman, is it possible to just give me a simple tool for simpler tasks? Having such a spreadsheet option is no threat to Coda. It’s just another way for people to get work done. Yes, documents evolve, but is it not true with evolution that the evolved form and original form can co-exist at the same time?
Although I think I understand where you are coming from, I don’t agree, not even a little bit. A spreadsheet is a very powerful tool and certainly has its place in our toolbox, but from what you are saying, I am pretty much convinced you don’t need a spreadsheet. The way you can open up a new (or existing) table in your document gives you everything you need, with the only exception of cell references (and cell references are possible too, but in a Coda way of doing things).
Tables allow you to add rows, group rows, summarize withing groups, summarize the full table, get (sub)totals anywhere you want in your doc.
For basic tasks the learning curve is extremely short and even though the documentation of Coda leaves a lot to be desired, there is enough to get you started.
I used to be a spreadsheet junky, but these days the only time I use a spreadsheet is when I need to work with some old stuff (or, when my spreadsheet has a couple 100K rows). And yes, spreadsheets have some nice pre-baked functions, in particular financial, but if you really need those, you use a spreadsheet.
I realize this is not the answer you were looking for, but make a shared dummy doc, share in your doc what you want to accomplish (even if it is just a couple of screenprints) and you will almost guaranteed get working samples from members of this community delivered in your doc probably quicker than you could design your spreadsheets.
I get a feeling that you think using a table is more complicated than using a spreadsheet and that tables are relational databases (and complicated). But a table by itself is nothing more then a collection of rows holding data and they don’t need to be related to anything.
Many of us will be happy to show you once we know what you are looking for.
Greetings, Joost
I too agree that not having spreadsheet functionality inside of Coda is a very big limitation. I am constantly finding that there are calculations that I want to do around the data that I have in tables that is best done in a spreadsheet, and right now, I have my work split amongst Coda and Google Sheets in a way that is highly inconvenient.
Let me give you an example: I use Coda to track and categorize construction expenses in one table, and other types of expenses in a different table. I use a Google Sheet to do forecasting, and that Sheet needs to reference the data in the Coda tables. Yes I can do this, but it’s highly inconvenient to have to work in these two different environments.
Hi Piet, the big difference between a spreadsheet and a database (which is what Coda is at it’s core) is that each row in a spreadsheet can have a very different format and set of information to the other rows. In the models that I need to build there are many variables and calculations that don’t fit in the format of a repeating row structure.
As one example of this, I operate in multiple currencies, and need to model the effects of how changes in those exchange rates could impact cash needs. That kind of multi-variable model would be very hard to construct in a database structure.
I would change that to “very different to construct”.
I used to do the 5-year forecasts for Toyota South Africa years ago. I would definitely do it in Coda if I had to redo.
Coda has the added benefit of providing structure so that you don’t accidentally overwrite formulas. When I first joined Coda, I thought that there was a lot of things for which spreadsheets would still be necessary, and I posted that sentiment somewhere in this community. A few years later I went back, and retracted that comment.
Now anything “serious” in financial terms, I would do in Coda.
Thanks Piet. I can understand that for situations where you are building models to be used over and over, where you can take the time to do that. But what about the many situations where you just need to do something for yourself that isn’t that formal?
And as a matter of interest, how do you easily reference a single cell in a row in a table, where there is no unique identifier? That would be a common thing in a spreadsheet calculation.
The formula comes from the example I have build shown below. It gives you a Forecast Parameter table with interest rates per loan.
The formula is from the Interest paid column in the Forecast Details table, and it calculates the interest paid per month per loan, using the relevant rate from the parameter table. I filter on one parameter characteristic (Loan), but you can expand that indefinitely: for example for Forex, you would have the from and to currencies, the date, and if you want to go onto that level of detail, a buy/sell rate indicator as well
It very definitely does take some getting use to the Coda logic - it probably took me about a year of dabbling with various docs. But I would now not go back to spreadsheets, unless it is for something very quick and dirty.
I understand the willingness to have “One tool that rules them all”. Sometimes I find myself in need of note-taking in tabular format (aka spreadsheets). If grids had X and Y parameter to reference a cell that would solve it… I think.
Thank you Richard. This is great for quick and dirty calcs, which I would use quite often. As I understand it, it has a disadvantage for more serious shared applications: if the data in Row 2 was shifted out of Row 2 by an insertion above that row, it would no longer retrieve the right value. But Piet has provided a way to solve that problem for that more serious shared application.
I appreciate you taking the time to provide this solution.
Thanks Piet, I will study this to make sure I fully understand how the cell reference was created, but it does look like this is a nice solution to a particular set of problems.
I very much appreciate the work you have put into answering my comment.
Hello @David_Skok ,
Spreadsheets are (nowadays) extremely scalable. Spreadsheets are extremely sensitive for errors (that hardly anybody notices until it’s to late).
I used to be a spreadsheet junky (because of the volume of my data and the ease of working with large datasets). My needs have changed a bit (less records - more complicated actions) and I hardly ever touch a spreadsheet anymore. When your datasets are less than 50K rows, I would say that Coda is most of the time more reliable and easier to work with. You have to learn to work differently, but most of the time, the results are at least as reliable, and often more reliable, than your spreadsheet results.
Coda can’t do everything, but it can do a lot.
Your example about forecasting with different valuta is easily solved: just make sure there is a valuta reference in your row and you only have to update the valuta in one place (a base table) for every row in your work table. Or, if the valuta can be coupled to a client or a product or a branch, you can set your tables up in such a way, that you don’t even need a valuta reference in your table.
If you share a dummy doc that sort of shows what you are trying to accomplish, I am sure one of us can offer some help.
Needless to say: no tool can do everything the most efficient way. But Coda goes quite a long way…
