[Open Discussion] An old-new way to deal with data: Grids

[Federico_Stefanato]

Hi all,
I browsed through past posts but I was not able to find something similar.
I’m wondering if I’m the only one who needs something like this.
What about having a Data Grid element in the docs?

Basically, just like an excel grid, with cells that can be referenced through coordinates.

Don’t misunderstand me: I love the approach of Coda and I immediately become an enthusiast of its flexibility, potential and… elegance; and I don’t want to switch it back to an excel sheet.

However, sometimes I’d like to have a way to represent data “grouping” that aren’t necessarily coming from a structured entity (i.e. tables).
This come useful especially when presenting reports or heterogeneous aggregations.

I’d love to hear your opinion, if you would think it would be useful and - from Codans - if this is something somehow in the radar.

Thanks a lot!

[Paul_Danyliuk]

I know the pain you feel. I’m in the middle of migrating a complex Sheet to Coda for a client. Since the sheet is a big cross-table with values and aggregation on both axes and is oriented vertically (pivoted so to say), it f-cks with my brain big time.

That said, I still managed to map it onto a Coda flat table, and I actually love how logical and structured everything became.

IMO it is much better to put effort but have a strict structure rather than have a freeform cell grid that’s much more prone to messing things up.

Cannot share the doc I’m working on, but here’s an exploration demo for a part of it (cohort analysis):

P.S. That said, I’d really love for Coda to have a pivoted view, where columns are oriented horizontally (e.g. to display different calculated metrics over years, where the years are left to right). Ideally columns could behave like groups and be either on the top or left.

[Federico_Stefanato]

Hi @Paul_Danyliuk,
somehow I was pretty sure of your answer

Firstly: wow! That’s an amazing implementation

Said that, I come to your opinion:

IMO it is much better to put effort but have a strict structure rather than have a freeform cell grid that’s much more prone to messing things up.

Most of the times I agree on this: It’s a matter of discipline, mindset and proper data modelling and - in the long term - it usually pays off.

However, most of the times is not always.
Not taking advantage of the freedom of an alternative because it could end up with mess it’s IMO missing an opportunity.

Especially in financial reporting, having orthogonal subtotals and totals is really a great advantage.
I’m not saying it’s not doable in different ways, but I believe we should also keep in mind the “protocol of language” they belong to.

Anyway, thanks as usual for your contribution: always both intellectual and very pragmatic.

[Paul_Danyliuk]

@Federico_Stefanato

Especially in financial reporting, having orthogonal subtotals and totals is really a great advantage.

Totally see what you mean, and yeah, sometimes a finance team just wants to have it like they used to in Excel. Been there done that, had to implement workarounds.

And came to a conclusion that — well, maybe not everything belongs in Coda and one should still turn to sheets for things that are easier to do with sheets?

(unless, of course, one pays me hourly and sweetly )

[Federico_Stefanato]

Sure; I agree.
I took some time before posting this question just because I also asked myself: “why reimplement excel if there IS excel?”.

Let’s keep it this way: either with enhancements or with integrations (i.e. Google sheets), it would be nice to have talking data in Coda docs.
And perhaps Coda’s philosophy rightly goes with the second approach.

[Federico_Stefanato]

(unless, of course, one pays me hourly and sweetly )

Well, that’s for sure

[Jean_Pierre_Traets]

Dear @Federico_Stefanato

Have you ever considered to use named formulas?

I use them for this type of cases and in an helper section of the doc I place them with some explanation as reference to remember what I have been creating this for.

[Federico_Stefanato]

Hi @Jean_Pierre_Traets,
sure Named Fomulas help in referencing sparse/unstructured data, but side of the problem is also properly displaying them.

Currently there is not a way to put numbers in a page aside from either on a table or following the normal document’s flow.
It’s great in the use-case you suggest, a bit less if you have to show a financial report.

This is the actual need of a grid.

Again, I believe spreadsheets are stil - well… - excelling on this.
It’s something currently not doable in Coda and I feel this gap would be useful to be bridged either by

• adding such functionalities
• integrating them somehow

Thanks!

[Thomas_Robbs1]

+1 for simple components to use in laying out a Coda Page, like the Grid concept (or what’s called a Table in Google Docs or MS Word).

More on my wishes here:

Table as layout vs. data store

I think you might be overthinking it @Connor_McCormick . Open a Google Doc. Insert a 2x2 Table. Put “A” in cell (1,1). Put “B” in cell (1,2) Put “C” in cell (2,1) Put “D” in cell (2,2) That’s a table in the layout sense, not in the database sense. Now I want to do the same thing on a Coda Page.

[jeo]

@Federico_Stefanato

Currently there is not a way to put numbers in a page aside from either on a table or following the normal document’s flow.

@Federico_Stefanato [and anyone else who reads this later]
Please click through to

(2021-04-22)

Coda seeking feedback on potential new feature!

Hey there! We’ve heard your feedback, and Coda’s product team is now exploring the possibility of a new feature: canvas columns . To explain it simply, this feature would allow you to position content side-by-side in the canvas. At this point, we’re still in the exploration phase and can’t make any promises. And should we be able to move forward with this feature, it will likely take time (don’t expect to see it launched in the next few weeks). But with all that said, we’d love to get some more…