New in Docs: forms and layouts updates

Hey @Ruggy-Joesten

Regarding the 3. item (Hide table/view): this link does exactly the same as hitting the X. Great that we can remove the link, but this is not really what many of us had asked for.
The three dot menu is the real pain:


We want to be able to turn of the option that allows people to go to the master table, because that really disturbs the workflow (among other issues).
Could you please see if the developers can arrange for an option to hide this menu item?
Thanks,
Greetings,
Joost

9 Likes

OK I’m a bit late to the party but I had been so vocal about those improvements (especially the “Submit” button) for so long that I just had to say THANK YOU out loud! :partying_face:

3 Likes

just came across this!

Might be off topic
I have a use case for forms, where I would dream of being able to push content from html forms to the coda directly without auth/token via API request, like Google Forms does.

I use this approach on my personal website precisionandcraft.com to create super snappy and frictionless feedback and data collection forms. Currently I can’t do it with coda because iFrame only and that data is then harder to capture.

Would you consider this an option?

2 Likes

Really appreciate all the new features, amazing progress!

I have been trying to use the conditional logic for some complex forms, and I have the feeling the feature is not completely baked yet.

  • It only accepts checking if a field is empty or (does not) contain a specific item, so not even simple mathematical conditions.
  • When a select/relation column is calculated, instead of showing all the possible options it only shows those that already appear in the table. No items are selectable in rules for empty tables, because the table itself doesn’t contain any items yet.
  • Once the visibility of a field is affected by a rule, it cannot be affected by another rule. For some cases, you can workaround this limitation, but then you need to create many many more rules and becomes unmanageable. If you want the visibility of a field to be dependent on 2 or more fields, it’s just not possible.
  • Hidden fields cannot determine the visibility of other fields. Why?

Is it planned to continue to work on this feature? What is the best way to give further feedback? I would recommend to take a look at Tally for inspiration, they really did solve it very well.

Best regards,
Pablo

1 Like

i am just about to write a blog post on branching (or conditional logic as you name it); would you mind adding some screenshots to clarify the issues you encountered?

looking forward!
cheers, Christiaan

Sure, here you go.

The first point is just a current limitation, but maybe they are planning on allowing more complex rules or ideally custom formulas.

  • When a select/relation column is calculated, instead of showing all the possible options it only shows those that already appear in the table. No items are selectable in rules for empty tables, because the table itself doesn’t contain any items yet.

In this example, the select list contains the options ‘a’, ‘b’ and ‘c’. But since there’s only a row with option ‘a’, the other options don’t appear as selectable in the rule.


  • Once the visibility of a field is affected by a rule, it cannot be affected by another rule. For some cases, you can workaround this limitation, but then you need to create many many more rules and becomes unmanageable. If you want the visibility of a field to be dependent on 2 or more fields, it’s just not possible.

i am write that your understanding is that you can have a single criteria like give me all black teas, but not return me all black teas under 50 Euro?

do helper columns where you store intermediate values not help. I guess not, you would have thought about that :wink:

merci @Pablo_DV ! Christiaan

Yeah actually you can use a helper column to get almost any logic you want, but it gets infinitely tedious, so better to improve the implementation. So the workaround would be to create a calculated select/relation column with each option being a specific condition that you could program separately, then base the conditional logic on that.

For example:

Black tea AND > 50 → A
Black tea AND <=50 → B
Green tea → C

Caveat: The helper column needs to be visible in the form, otherwise you cannot create rules based on it.

thanks for the clarification @Pablo_DV
@Ruggy-Joesten , can you ask the team working on this feature (branching) comes back with some feedback, also in the scenario that no further updates are planned? merci. christiaan

1 Like

@Pablo_DV @Christiaan_Huizer - appreciate the feedback! We’re actively working on some improvements for the feature following the initial launch. Would be helpful to see some of your use case examples in more depth - I’ll follow up directly!