When I said I wanted Cross-Doc, I lied (I want Doc Views)

TL;DR

I want to make multiple views of a doc, where only certain pages are visible to each user type depending on the user, but the whole doc is still loaded in the background so it’s live and responsive.

This would make it easier for users to understand without having multiple pages of a complex doc to click through, and it would also remove the need to use cross-doc (which is slow and complex) in many situations.

I’m currently involved in a project to centralize a massive cross doc application into a single location.

There are a handful of problems with cross doc:

  1. It has high latency (info can be up to 1hr old with automatic updates)
  2. It sometimes requires manual table updates
  3. It’s slow to pull in data
  4. It requires lots of extra work to maintain (both OUT and IN syncing tables, and all the logic that needs to go into that)

It turns out that when I reach for cross doc I am reaching for it for the wrong reason. The time to use cross doc is when you need to protect information. The time not to use cross doc is when you want to “modularize” your coda docs.

Here’s what I mean by that:
If you have sensitive payment information in a doc, you should keep that in its own permissioned doc, and then pull in additional information (e.g. hours worked) into that doc to run calculations with the sensitive payment data. This way you can get your information without others having access to it.

However, if you just want your users to use a “Time Tracking” doc to keep track of their hours worked, and a “Project Management” doc to keep track of the projects that need to be worked on, you should not use cross doc. Put it all into one doc.

The reasons to put it into one doc is that:

  1. Everything will run much faster and be simpler to develop
  2. If you ever have to merge the two together it will be a major chore (you’ll have multiple columns to merge with colliding names, formulas will break, rows will be missing, etc.), whereas splitting them up is fairly easy.

The reason I was tempted to use cross doc was because I thought it would be easier for my users if they could just click on an icon in their coda landing page called “Time Tracking” and it would take them to a doc with nothing but Time Tracking related information. But this doesn’t require a separate doc. It can all be done in the same doc with good Welcome pages. But it could be better.

I don’t want to make cross docs, instead I want to make multiple views of a doc, where only certain pages are visible to each user type depending on the user, but the whole doc is still loaded in the background so it’s live and responsive.

This would make it easier for users to understand without having multiple pages of a complex doc to click through, and it would also remove the need to use cross-doc (which is slow and complex) in many situations.

8 Likes

Hi @cnr,
Have you already considered publishing a doc with hidden sections?

Hi @cnr :slight_smile:
As @Federico_Stefanato says publishing is probably the better way to achieve your goals as now, but a future implementation that i’d love would be to use Coda Forms as “light view” of the doc.
Those can be already “created” in different way for different users, they are just missing some option to be compatible with the concept of “light doc”, like possibility to use them on pre-existing rows and the “transformation” of tables into graphs or whatever, maybe in a far future those could be a game changer!
The concept of having limited views for user is a good one! (and more or less can be achieved in Published docs) but it could also improve performance strongly!
I was thinking maybe the hidden table are not loaded or maybe heavy calculi could be done in the cloud, this will resolve the problem of having “one big doc” of the weight of half gigabyte…

Yeah hidden sections are obviously great, not sure they solve the problem though. Can you publish two docs with the same underlying tables (that are connected to one another in a live way) which have different hidden sections?

E.g. if you have a doc with both a Time Tracking page and a Project Management page, but you want one user type to use only the Time Tracking pages and another user type to only use the Project Management pages, is it possible to give each group a doc link that’s specific for their use? Not only should these docs be specific to each user type, they should also affect each other’s docs. So, a user of the Project Management doc should see live (immediate) updates from the users of the Time Tracking doc. Is that possible with hidden sections in published docs?

1 Like

Hi @cnr
this is actually interesting :+1:t2:

Basically having multiple publish for a single doc, each one with different settings.

I’m pretty sure this is not available at the moment (I’ll try later: I’m not in front of my computer), but I think it would work great.
The underlying complexity would not be trivial, I guess, but I see how powerful this would be.

2 Likes

I am glad to see more people have similar concerns. I have shared my concerns with Coda through different channels and I want to be careful to not say the same thing over and over. But reading the above I want to share the following:
as long as there is a possibility to copy a doc, you can hide whatever you want but is is not a security feature.
Regarding crossdoc: I find it a solution that does not work for my purposes. Therefore, I plea for tableviews that work accross docs. That way you can share docs with only the views you want to share. Through filters you can limit the information (but keep in mind - filters only help if someone can’t copy your doc and undo your filters).

1 Like

Yeah, cross doc is going to be the only way to have security, at least for a while, as @Paul_Danyliuk has pointed out, even if they completely removed the buttons that would give you access to the data, it’s still available if you know how to look for it in the document that coda sends to your browser.

Perhaps there could be encryption on that, but while that may be what you’re looking for, I’m really not concerned right now with the security of the data (I can get that through cross doc), rather, I just want to make it cognitively simple on my users.