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:
- we want the users to to go back to the information they entered earlier and edit this information
- we want them to make new records while being able to check previous information and look for trends
- 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.
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.
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,