Einstein, lol nah, just a has-been developer who lost his spark for coding but coincidentally found a different niche where he could apply his skills.
As a matter of fact, I do Coda consulting for about half a year already. Super busy at the moment though — four concurrent clients at the moment and two more on hold. I already regret taking a day off today and see how tomorrow and the next week are going to be pure hell.
Since “sub-topics” and “topics” are the same thing — you put them on the same table. One “kind of thing” — one table. If you had two conceptually different things (e.g. projects and tasks, having two distinct sets of properties) then you’d go with separate tables.
The conventional way to build a hierarchy for entries of the same kind of thing — is to specify a parent entry for each entry. The entry that has no parent entry is the one that sits on the top. In Coda this can be done by adding a Lookup column of the same table.
On its own, that Parent column doesn’t mean anything. It’s what you do with it then that matters. E.g., you can recursively construct the path of each item:
thisTable.Filter(CurrentValue != thisRow AND CurrentValue.Path.Contains(thisRow))
In my case with that tree map demo, what I’m doing is using that parent-child relation to ultimately calculate the X,Y coordinates of the nodes and lines to draw
When displayed in Layout view, you can render children or descendants as a subtable. You can add a button to drill down to the sub-task via row URL (although it seems like it may have stopped working recently):
P.S. Actually in Coda this can be done the other way around as well. Instead of specifying a parent, you can add a multi-select Lookup column where you’d specify children. But I guess it’s a matter of convention to do this the other way around. First, it’s sorta traditional, since databases usually can only store one reference in a property (i.e. one parent). Second, it’s harder to mess up this way, ending up with a task belonging to multiple parents (unless that’s what you need). Third, adding tasks doesn’t require going back to the parent entry and updating the list of children there — you select the parent as you populate the child row, and so it’s harder to forget to assign it.
@Paul_Danyliuk, I had a question on this: If you have deeper hierarchy here, say 4 or 5 levels, can you create a column that will relate the descendant and ancestor all the way through the hierarchy?
So If I have something like these levels in a table for breaking down company Initiatives:
Can I set up in my Objectives rows Columns that would just show the Projects, so 2 levels down, and vice versa?
And this may be elementary, but I can probably easily group all four levels in this example to create a sort of WBS type view as discussed here?
Granted, what I’m looking for is a way to group from left to right, and not necessarily fold and view the way Krunal set up. Although if Krunal’s solution was more “natively” doable in Coda without all the formulas, I’d use it extensively!
I’m coming from a PM background in engineering and using large Primavera or MS Project schedules (not a fan but without API’s and a robust grid and a relational database the way to go for large construction or mining projects).
I’ve build estimated in excel with WBS and commodity codes so I understand how it can be done in excel, but i’m yet to see large tables work well (and not load slowly) in apps such as these. Airtale struggles with 1000’s of rows (even a small project would have 2000 rows)
So I guess my question is can Coda work for this type of use case or do we stick to docs, which I have to say are incredible and sourcing tables from larger master tables like business requirements sourced from a master req doc into a BRD or PRD works very well
I’m going to play with the API and bring in the data to a server outside of Coda and look into it more, many thanks - had disregarded this sort of due to changes in the API but they must be minimal these days