Hi Everybody,
I’d like to see if someone else could benefit from this evolution.
Scenario:
We are a Startup following the classic OKR approach for every “department” (Marketing, Sales, Development, Strategy, …)
Every Key Result has a set of Tasks that have common fields (e.g. Collaborator, Due Date, Story Points, Status, etc… ) plus some departmental specific ones (e.g. Resolution Time, Sentiment, Account Reference, …).
This leads to have a comprehensive table Tasks holding all the fields with different views to show/hide the most relevant for the context.
It would be extremely useful to define a single table entity Task with the common set of fields and “extended” tables (e.g. Market Activities, Development Tasks, etc) that only define the differences needed to be tracked.
Something like: New Table [Extend from …]:
This would allow to have a common aggregation for metrics/statistics on reference tables - in the scenario example, Key Result would still have a set of “generic” Tasks.
At the same time, every departmental evolution/addition would not affect the “base” table.
This would permit also to keep some basic features on common low-level tables.
A couple ideas. One is to create the table of OKRs in one document and then cross-doc import that into your other document and append those additional columns in there. That would keep the original list clean.
Another is to keep the OKR table as it is, then create another table with many of the other attributes, and then make the display column ‘Lookup’ from the original table. The upside is that this will partition the data in the way that you want, the downside is that you will have to create the new row for every original OKR / won’t have every row automatically come through (there are pluses and minuses to this approach. If this isn’t clear let me know and I can make you an example.
Yep - makes a lot of sense. I think this is why GraphQL was created - to create an abstraction insulator that can be used to class and subclass the underlying schema.
@Federico_Stefanato, this is one of the big questions that I have trouble trying to figure out how to solve in Coda due to the fact that you can only really link one table to one other. You helped me in another thread with a Polymorphic formula that I later confirmed with Coda support is not really supposed to be used.
I am still not 100% sure I understand your post as it’s advanced for me - you underscore the sophistication of most Power Makers around here when you say:
“I don’t want to bother with O-O principles (also because I assume people here know them quite well…),”
haha, just goes to show that there are a bunch of devs communicating!
But I wanted to ask how you would characterize this example in the context of your post:
I have a table I use to tag work in my team called “Department”. The rows are Marketing, Sales, Engineering.
These tags are used across many other tables, ones I have for tasks, product, OKR’s, equipment (for example, the company’s computers that are distributed), etc.
Can I create a view where I’d see all these items across Coda that are “tagged” with the rows from the “Department” table? In other words, the computers that belong to Marketing, the OKR’s that belong to Marketing, the tasks that belong to Marketing?
Is this example something you are talking about here?
yes, I think it’s somehow relevant with this topic, but from another perspective.
Let’s see if I can make myself better understandable…
I’d translate your need into something like
“I’d like to see all my [–stuff–] that have Marketing tag”.
Take into consideration that
[–stuff–] means multiple tables (Computers, Tasks, Meetings)
filters work from a single table. i.e. [Table].Filter(--your criteria--).[Column].Count(), for instance.
So, the two things cannot be combined (they mutually exclude).
But… (turn on imagination, here)
If we could have a kind of common “root” (or parent) table, something like Taggable, that contains a specific column (e.g. Tag) and few handful others and we could create new tables (e.g. Meetings) that “extend” Taggable (i.e has all the columns of Taggable), we could actually filter with Taggable.Filter(Tag="Marketing") and it would collect all the children.
To be honest, my intention in this post was only to have this feature to save time, rather than collateral - though useful - inheritance filtering.
Anyway, I sincerely hope I gave you some clarification (though I have the feeling I could messed he things up even more… ).
Let me know!
Edit:
Obviously there are workarounds, as we already mentioned.
Like List(Computers.Filter(Tag="Marketing"), Meetings.Filter(Tag="Marketing"), ...), but this would se explicit knowledge (and therefore logic) in the design evolution.
Sorry if this is digressing a bit, but you got me thinking about this question. I never got far enough along with Coda to have an issue here, but can you simply set up a tag type in Coda, use it in multiple tables, then set up a view of every row it affects?
As I think about it, this basic functionality I think is missing, correct?
In other words, sticking with the example - If I have a tables for Computers, Tasks, and Meetings, and I create a lookup column in each to another table for “Company Departments” and Marketing is in there, can I then see all the items from those three tables that have the “Marketing” value in that lookup column?
I think the answer is “no,” right?
But you are proposing with this Extension solution to solve this?
Eager to find out if I got that right, thanks again!
Hi @ABp (Aaron),
I love the way you like to dissect topics!
I’ll try to go deeper, though I’m sure it will never be enough for you
Well, first let’s give credit to Coda: it’s not so basic…
It is quite complex to put in place in a a friendly and straightforward interface.
Again, it’s not binary: you do can (we actually did it, remember?) as there are some workarounds. It’s not a simple procedure and it needs some hacks. Surely it’s not a built-in, straightforward feature.
Sorry for being so elusive, but once again I have to be honest: I think this might sort it out; but it really depends on the overall implementation under the hood and how the interface allows to act accordingly.
It’s not that far from the Coda Pack (external tables) for a certain perspective; only Coda engineers and designers know what it would imply, though.
However, a simple solution like List(Computers.Filter(Tag="Marketing"), Meetings.Filter(Tag="Marketing"), ...).BulletedList() could definitely work as first level aggregator of information, wouldn’t it?
Maybe if you can share your doc, I’ll ry to do a try (I have some ideas…).
@Federico_Stefanato, as always, much appreciate the time you take responding to me.
I have to say that continues to be a bit over my head. No question I appreciate the power of Coda, but I think for now it remains more a tool suited for experts such as yourself as opposed to others who are not as adept in coding or formulas.
I’m basically referring to the same thing we were working on here:
One thing I did realize while thinking about this is you could achieve a view I’m thinking of by embedding into a section three separate views of the Meeting, Task, and Computers table and then filter for the column “Marketing” in each. That is a bit of work though, and I feel like it’s a workaround vs. just having a common table or list of rows from all three tables that would have the Marketing tag.
I appreciate your continued dialogue. Really think it would be great if Coda offered Polymorphic capabilities out of the box, but I guess that’s up to the Product Team!
).