Standalone Forms
These views are architecturally treated as an external-submission mechanism (shareable by URL to non-Fibery-users). That design choice is why they don’t get the “Create and open” panel redirect that the “+ New” popover on grids/boards/lists gets. Although I would appreciate parity for the users, I acknowledge it’s a deliberate product tradeoff, so I am not asking for this to be changed at this stage.
However, I do want to make a note that the form could check whether a user is logged-in and navigate them to the created entity on save, if it was set up that way.
‘Create Entity’ Functionality and Usability of In-Platform Forms
While the forms available by the ‘C’ shortcut are nice for power users, the following issues have been raised from our team since adopting this platform 15 months ago:
- Default form for each form type is not set here — The standard ‘Default’ form is effectively required fields only, which is almost never correct due to automations, validation rules, and values populated from different entry points. While the addition of ‘Required Form’ toggle (Pro feature) can be set on a form itself, it doesn’t help if there is a level of polymorphism which requires more nuance than a blanket solution.
- Forms open in ‘Compact’ mode, always — Users have expressed that this layout is unintuitive and limiting. They prefer the ‘Full’ layout to be the global default for all forms, and I tend to agree. I think Full should be the default, with Compact as the optional alternative.
- Compact form ordering is set and unintuitive with formula names — ‘Name will be generated by a formula’ is not helpful information. Many times throughout the app, I’ve used a pattern where the Name formula is delimited ‘text field’ + ‘some identifier’. In the Full forms, the field from which the Name is derived can be hoisted to the top of the page for legibility and a very human sense of orderly progression; this is not so in Compact form views.
‘New Entity’ Usability of Smart Folder Shortcuts
Similarly, when there are Smart Folders in the sidebar with ‘+’ icon, the subsequent ‘New Entity’ button that appears functions identically as the ‘C’ shortcut — Compact mode, no default set. The ‘Required Form’ comment above still stands (in my opinion, it’s actually more relevant here) since each Smart Folder has its own filters applied, which set the default value of fields.
Take, for example, a ticketing system. Tickets may have different types, each with their own ‘required’ fields. Without true polymorphism (a base Ticket, a Bug implementing the Ticket interface, etc.), the system must either treat them as two completely different entities (each with a separate database), or as the same entity type with caveats, including messy field validation.
Conclusion
I don’t know whether any of this is on your radar or planned for future re-visiting, but I thought I’d just get it out there and start the discussion.