Topics Map > Page Builder
CoP - Betty Blocks Forms - Deeper Dive Best Practices
The Community of Practice (CoP) is now developing their own best practices documents as they dive deeper and get experience in Betty Blocks. This document pertains to forms using the page builder in Betty Blocks.
Page Organization
- Name your form
- Name all fields while keeping the type (Select - Department)
- Name your form actions so you will know on what page the action belongs
Fields
- Pass in a UUID for the page with hidden fields, if needed
- Consider adding a validation pattern (e.g. regular expression) if a specific format is needed
- Include a reminder that autocompletes are searchable via the helper text
- To change the width of a field, set it to full width inside of a box and change the box width
- To make a conditional question, place the question in a conditional and set the logic based on the input of the field
- Set fields to required on the form if they are required in your data model
- For multiple uploads, use a dialogue with a separate form and display the uploads in a datalist
- For a file upload, include a "File Name" text field so you have something to display in the UI other than the URL string
Interactions
- Set interactions based on the form and not based on the submit button. (The submit button should just submit the form).
- Add a clear interaction for every field on the form any time a Cancel button is used
- Add a clear interaction for every field on the form upon action success
- Add interactions to disable the submit button on load and to enable on success and error
- Add interactions to toggle the load state of a submit button on load, and then again on success and error
- Add interactions on action success to re-fetch any data containers/lists/tables that would be impacted
- If an auto-submitting form has text input, use "on blur" instead of "on change" to the form isn't submitted on every key press
- Customize the alerts if you don't want the default server message to display (e.g. Custom alert of "Updates saved" instead of default "Form successfully submitted")
- On long forms, consider moving alerts to the bottom of the page
- Consider moving form alerts to snack bars to better control the location of the alert on the page
User Experience
- Add a description text to your submit button to describe what the form is doing
- Use the Multilingual feature if you expect multi-language use
- Test your form with keyboard-only navigation (i.e. no mouse usage), especially noting the order when you tab from field to field
Potential Pitfalls
- Don't duplicate pages with forms on them
- Using the price field type may lead to errors, since it gets confused by the European currency style vs US format
- Don't drag your fields outside of the form, even briefly. This breaks the field and anywhere the field is referenced in the form action.
- If using the tab functionality to visually break up the fields across multiple tabs, beware that only data entered the "active" tab fields is sent, even if data was entered in an inactive tab field.
- In the circumstance of needing to recreate a form on a page, keep the former one on the page as reference until you are complete with the new one.
- Adding an update form will auto-add a page input for your model ID. If using UUID as the page input, swap the UUID out in the filter and delete the adding page input id
- Avoid rich text field types until it is made accessible (i.e. keyboard-only navigation gets stuck in rich text fields)
- Don't duplicate the submit button. It holds onto its hidden ability to submit data from the original form upon clicking.
- Consider using CSS borders instead of divider components, given that CSS borders provide less page bloat and more control
- Add a "fresh" field into your form instead of duplicating an existing field of the same type (i.e. don't duplicate form fields)
Additions to this topic?
If you have additional issues or ideas to add to this page, please bring them to the CoP's attention