[Open Discussion] An Object-Oriented approach for Tables: Extensions

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.

Curious to know Community & Codans opionions!

Thanks!

1 Like

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.

Hi @Johg_Ananda,
thanks for your answer.

Both great ideas, but I guess I was not enough clear.

Three hierarchical tables:
Objectives, Key Results and Tasks
Objective holds many Key Resultys. (fine with this).

Key Result holds many Tasks

The polymorphic guy here is Task.
Maketing Tasks, Salses Tasks, Development Tasks, Service Tasks, …

Creating cross-doc extension would not let the base table Tasks to grow accordingly any time a new [Extended] Task is created.

Does it make sense?

I’m kind of tracking, but if you could make an example doc that would really allow us to flush it out.

Fair enough: you’re right.
I’ll prepare a sample doc ASAP.

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.

Here a very basic example.
I described the scenario and the proposal in the Doc itself.
Please, add your comments.

Thanks!

1 Like