Form builder value styles
Word processor paragraph styles as no-code custom data types 2021-04-27 #NoCode
No-code form builders give non-programmers a way to build custom forms, typically as part of a survey, workflow or decision management tool. As in other programming environments, authors can typically use built-in form field types, such as text, number, date and email address.
Some tools also give you a way to add your own. You can define custom types, such as a single-valued price in Euro, or a delivery address that includes more than one field. However, no-code form builders haven’t yet settled on an obvious or best way to support user-defined field types.
Word-processors offer an alternative model for custom types. They let you create user-defined ‘types’ for formatting and layout, but call them paragraph styles.
Paragraph styles and value styles
Word processors offer the convenience of selecting a built-in heading style, but you get more benefit from the ability to change all headings to use a different font, and other document-wide changes. While styles may seem to focus on making it easy to apply predefined formatting, their more important contribution lies in maintaining consistent styling throughout a document.
By analogy with word-processors, form builders need value styles that preserve consistency between similar fields on different forms whose data shares the same meaning. Like a paragraph style, a value style defines where you want consistency, starting with formatting.
Note: value sounds friendlier and more specific than data.
This context lets us get away with blurring the distinction between a concrete instance and the abstract category, ignoring the difference between value types and entities. No-code environments can improve their authoring experience with this kind of simplification, and traditional developers often get it wrong anyway.Editing rules and display formats
Paragraph styles typically define formatting in a font section: font family, bold, italic, underline, colour, etc. In a value style, this corresponds to its display format. For a value style for a single underlying value, such as a price, this mostly corresponds to editing and display formats. Editing includes rules about valid values, such as no negative prices. Display formats can include currency symbols and a fixed number of decimal places.
Values that have nested fields, such as postal addresses or prices with variable currencies, introduce more complexity but can otherwise work the same way. This stretches the analogy, though, because while an address contains separate city and post code values, word processor paragraph styles don’t include either structured data or much metadata. (Perhaps a paragraph’s language or its list of tab stops come closest.)
Defining styles
Paragraph styles’ type definition approach seems plausible, but somewhat pointless. Its benefit turns out to lie in how word processors use direct formatting to define or update styles from examples, instead of up-front definition.
Traditional programming languages generally define types with some kind of explicit type definition, before you create values with that type, instead of starting from examples. This introduces up-front design that non-programmers usually get to avoid, as in word processors. No-code platforms would also benefit from that kind of direct manipulation and definition by example.
