Similar to Google Forms, where questions can be sectioned into e.g. personal contact information, questions set A, questions set B, questions set C, signature. This can make long forms seem less intimidating.
In addition to sections (which would include both a Title and Description), the ability to add a simple text box to hold instructions… data that’s only on the Form, not in the Entity… would be handy; e.g., doing surveys often requires instructions like “select one or more of the following”.
Right now, I’m using a Rich Text field with multiple questions with checkboxes for respondents to tick just so I can provide more detailed instructions (and people can of course edit everything I’ve pre-populated). I’d rather use Checkbox fields, but have no way to clearly communicate the instructions.
+1, this is the only reason I still use Google Forms for my registration. The only thing that is a bit weird is that it means that forms hold data, when they are actually meant to only be for data input… Maybe a way to reference rich text in other entities within the form? Then you have an “Agreement” database…? This might be overkill though. Just worries about data loss / correct data storage. What do you think? Or maybe allowing pre-populated rich text which is NOT editable? Which serves as a description? Then you you also have a log of the data that the user agreed to?
I could go either way. Not having all that captured certainly simplifies the Database design and Entity data. If the product goal would be “G Forms parity”, then living only in the Form is fine.
If creating a unique, more advanced Form product is the goal, capturing all Form configuration data in the Entity would be one approach.
Or rather than capturing every bit of Form content in the Entity, perhaps Form version management would be a middle ground: allow people to create a Form version name / ID, then capture in the Entity the Form’s current version name / ID each time a Form is submitted. Provide a way to view a particular Form version.
If I wanted to do “version management” today, I could of course create a new Form, but that comes with a new URL. Depending on how a URL is being distributed, perhaps this works just fine. One would also need to figure out an automation to capture the Form’s URL in the Entity (is this even possible?) so you know which one was used.
I do find it a little confusing that field names are editable on the Form vs forcing a match with the Database field name. If there are multiple people designing and managing a Form, seems like it could be easy to confuse which Entity fields map to which Form fields.