October releases have been
Annotating things inside a system is so important for onboarding and your future self. Especially in a platform like Fibery, that is prone to sprawl into many databases, fields and views, if adopted well.
I have some feedback for forms!
Can we have the form field trim the (plain) text fields on submit?
I.e. want a user that copy-pastes an entry like ID abc123
to be stored in DB as abc123
Itâs super duper common when users copies and pastes data from other applications, that leading or trailing whitespace is transferred, and in my experience there are never a reason to ârespectâ leading or trailing spaces, in simple text fields. If the form doesnât trim it, we have to put cumbersome automations to do it.
Notion actually trims all leading and trailing whitespace in most inputs including databases on copy-paste (Fibery does not ).
In Notion DBs, trailing and leading whitespace are stripped on paste into text fields, but user can manually enter a text field, and add (back) whitespace via keyboard, if they so wich. Spaces added this way are then retained on copy paste (I donât know how they do it, but itâs super nice).
Personally I cannot think of any use case where Iâd want to intentionally store leading or trailing spaces in a text field on manual user input. (Updates via API should naturally preserve content including whitepace.)
It would be super great with basic regex validation on (plain) text fields
One typical benefit of forms is to validate user input. With the form being connected to fibery that has typed field, this is already very good. Dates, Numeric fields, Selects, etc.
However, text fields are a bit problematic. Typical use case is we ask our user for something like a customer id or order id. But our users easily confuses the IDs, or types something else that is wrong.
Regex is very powerful here to validate text fields, and raise the data quality of data from submissions.
Therefore Iâd love basic regex validation support for (plain) text field. Since regex is so powerful, we can build most of any pattern validation we want.
I donât think we need a separate validation error display field apart from some error highlight on the offending field, since we can put the input (format) we expect into the field descriptions, which is already supported.
Add âsubmit anotherâ after submission
It would be great if admin could set if user should get a âSubmit another responseâ link, that returns the visitor to the form again (blank).
Especially when a form is iframe:d, it can be hard for the user to work with the form otherwise, if they need to make multiple submissions. Even if you can refresh the page without side-effects, its not really obvious that itâs possible.
Microsofts Form has one implemtation of that. In MS Forms, itâs an option the form creator can enable per-form. I typically think its fine as a default behavior, but I can imagine some users might want to have it as an option.
Idea: can we have the option to let Creators & Admins âlockâ the default view mode to preview ?
I can see the form being useful not only as a shared link outside of Fibery users, but as a simple templates for internal Fibery users. I guess this a bit analogous to the âcreate Issueâ forms that Jira always had.
If you create an entity and it has 20 fields, it can be hard to focus on the most important fields. Once you update, you typically just work with one or a few fields, but that is not the case when you create an entity.
For example, to quickly register a add a new invoice to Fibery, Iâd like to use the âAdd Invoiceâ form inside Fibery as well. Using the form, I got nice descriptions, and I can focus on only the relevant fields thanks to the form. I have some simple validation to guide me as well.
However I do recognize this path is a little⊠slippery slope-ish?
Because then next, Iâd want the form submission page (inside Fibery only) to give me the option to redirect to the newly created entity, or to submit another. And maybe have the have form presented as an option to use, when a user creates an new entity.
I see something more controlled, like Jira-forms, down this path (which is a good thing! but obviously requires significant effort). But I be curious to hear if you have planned something like this for later?
Other form issues
You already seems to be working on relations and putting hidden inputs, so we can properly target a form submission with a automation rule.
I wonder if we will be able to filter the relations that will be selectable, since it can potentially be quite a lot that shows up (e.g. and 90% might be archived/non-relevant)?
Also templates in rich fields would help a lot to keep things dynamic and flexible, perfect for stuff like bug reports and as a template for user requests and feedback (what data we expect user to send in).
But I think you are working on a solution to make that possible as well?