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!