Sharing a doc while keeping (part of) the structure hidden and other sharing thoughts

Suggestion Box
1

Hello Codans,

The following is applicable to a lot of different situations, but I am going to describe one particular situation to illustrate the problems I am running into, how I tried to get by and why it is not working satisfactory. I have some suggestions that hopefully can be implemented. For my planning it would really help to know if you think this is going to happen. I know I am not the only one struggling with these things.

Casus: I have a doc to collect information that is supplied by separate entities (called ‘clubs’ from hereon) about their business. This document has an intro page, some data collection pages and some pages for statistics. The clubs are not allowed to see each others records - and preferably they are not allowed to visit the pages we use for setting up defaults and other stuff.

We could collect information by using forms, but for this project that is not a good solution because:

  1. we want the users to to go back to the information they entered earlier and edit this information
  2. we want them to make new records while being able to check previous information and look for trends
  3. we want them to be able to add and edit (multiple) contacts for their club

Sub 1) I realize we can workout a scheme where data is submitted by forms and updates previously older information, but often the users won’t remember what they entered earlier, editing existing records is a lot more convenient.
Sub 3) This also could be accomplished by separate forms, but the users won’t have any insight in which contacts have already been entered in the past (perhaps by another club member).

I started building this doc, got an authorization table, used locking to prevent unwanted changes, used filters to show users only the records they are authorized to see and it pretty much works as intended. However, there are a lot of issues that makes it hard to deploy to the less tech oriented people. Not all of this is shocking, but we need more options to make this work. Some items are not as critical as others, but I will mention them all. Addressing them one way or the other will really give us a better Coda for many uses.

  1. on boarding: not everyone has a Google account and not everyone has a Coda account either. It is great that we can invite people with any email address, but when they first answer their invite email, it is not so obvious what the have to do. I would like for all people that are invited with a non-apple or non google email address to be guided to a sign-up page if their address is new to Coda. This will make it a lot easier for people to get in.

  2. Once they are logged in, they get way to many options. For some collaboration projects that might be fine, for for many projects it is very confusing. I tried publishing in edit mode to circumvent some of this, but the locking scheme does not work properly in edit-mode published docs. So that is an absolute no at this time.

I think the doc maker needs to be able to set the following for his doc as defaults
a) Hide collaborators activity (because most users are not going to find this themselves and the setting is not persistent across sessions). It is very confusing to see other users names and their login status at the top, see their name in the middle of a page when they are doing something, etc.
b) Hide the explore settings button (link) (it is only confusing and they can’t do anything there anyawy)
c) Hide the document setting button (doc map brings them right to my hidden pages, and all the other stuff is of no importance to them, of none of their business. Why should they see my automations?)
d) Hide the “show hidden pages” switch (other than for some named users)

Option d) is going to save me so much time, because I have to filter all my setup and lookup tables to only allow acces for some people. Even though the hidden pages switch is not that obvious for many users, it is easy to find for people that want to find it.

I realize the buttons and collaboration insight are there for a (good) reason, Coda is about collaboration. But there are many levels of collaboration and in certain situations we need to help our users with less options.

I have mentioned the issues about hidden pages before and I know how complicated this is to solve this through an authentication scheme. However, hiding the hidden pages switch should be peanuts in compare to an authentication scheme. And yes, I also realize that it is not rock solid and bullet proof, but it is good enough for me.

I really hope you can add these options, either under some document default settings (in the sharing menu perhaps) or in- or next to the locking options. It will be a big step towards being able to share Coda with many more people.

I can’t find this in de documentation, but can you tell me if the Enterprise version accommodates for some of these options?

Thank you for your consideration,
Greetings, Joost

1 Like
2

I like these ideas.

To manage this in the past, I’ve written my own apps for those non-administrative users, which pull Coda data in as needed via the API. But I agree that it would be really nice if Coda could find a way to double down on the docs-as-apps philosophy to present app surfaces to more than just equal, trusted collaborators. In my mind it would probably grow out of the Published Docs area of the product.

In the meantime, one model you might try is cross-doc; each club could have its own doc (scaffolded from a template), and their data could be pulled in via Cross Doc to a private administrative doc that aggregates everything.

3

Hey @Nick_HE

Writing apps: We have done the same here, but it feels kind of funny to have something that is almost perfect (Coda) and then write an app in Java, store (a copy of) data in Firebase and then have an app that is a bit on the slow side and a lot more work to maintain. Our docs are a continuous work in progress and I want to work in Coda,I really really do,

I do agree that it perhaps grows out the Published Docs area (that said though, it is already outgrown true docs, especially considering ‘develop your own pack’ options that is being release upon us), I am aware of some limitations in the docs concept, but Coda gave us the means of doing all this, formulas are added, optimizations are happening regularly, it is already more app orientated than doc orientated. I realize that the wishes never stop coming, but it would be so nice if Codans can try to take care of some of the simple requests before going on with other big things and leaving loose ends.

The workarounds, in particular with cross docs, is going to be a monster to maintain once you get more then just a couple of clubs (I am looking at about 20 now) and there is no way I can keep 20 docs completely synced unless there is going to be a tool to update templated docs (and I don’t expect this tools to be available anytime soon, if ever.

Let me close this message stating that I can release and maintain my Coda apps quicker and with a lot less effort than I have been able to do any other way. I accept that Coda can’t replace a full blown development environment: I just hope that some of the easier stuff that helps big time gets done too.

Therefore, I will keep posting my findings and wishes :slight_smile:

Looking forward to all the goodies that 2022 has coming for us.

3 Likes
4

I totally agree with this. Im a bit surprised that individual pages cant be permanently hidden from specific users.

For example I have a page with bills on it, and i only want specific users to have access to the table to push items to quickbooks. Id simple like to to permanently hide that page to everyone except 2 other users. Its been obvious Coda needs better granular controls over pages, but I didnt realize it was this elementary at it.

For an app thats catered to businesses simplifying their processes, they really make things much more challenging. Perhaps its different in an open/flat environment, but in healthcare and other small businesses we need much tighter controls.