Era of dynamic attributes

Background

As the need for our application increased we were always asked about adding more customizations to elements/forms. In the past, we would support such customization requests by using a concept of Reference ID’s which allowed us to treat an element/form in a particular way as per customized by the form designer. It quickly became clear that it was not going to scale for making a large number of adjustments to the behavior of our existing application.

Usage of reference id to allow moving a point on location element

Drawbacks of that method were:

1. Fixed number of columns for reference id’s meant that either the customization’s had to be limited or some of the reference id columns must be reused for different flags.
2. If we needed more columns the current data structure would need to be modified which meant a lot of application logic had to be touched (changing databases, API, mobile & backend service enhancements, etc).
3. Some customization demands were not popular and the application turn around time to make those changes was a bit longer, so that would mean that either the functionality was completely scrapped, or, it left a bad experience for the end user who had a long wait cycle.

Some of the benefits of the that approach were:

1. Easy to add a reference id customization if that element did not already have many customizations set.
2. Mobile/Client apps could handle the changes as soon as the reference id’s were stored in the form design within the current limits of table columns. This became one of the main reasons the old architecture was supported for so long.

New architecture on the horizon

As you have seen, because of the challenges of the old architecture, it became inevitable that we needed a successor to the reference id’s to add more flexibility to the platform while at the same time, maintaining the robustness of the platform that our users have learned to trust for so many use-cases over the years. The Engineering team sat down with some guidelines and devised a new concept called “Dynamic Attributes.”

Let me define it first; Dynamic Attributes are “selectable Properties of elements and pages that can be further customized. Specific elements will have specific attributes that allows them to enhance the data collection process outside of the scope of our already powerful smart controls”

We decided to introduce new data structures to store these dynamic attributes for forms/elements. Some of the benefits of this design would be;

1. No extra columns need to be added to the existing data structures for elements/forms.
2. No need of API and backend services to change to accept any new data structure. (Although some new endpoints have to be added to support the new structure.)
3. Each new attribute can now be further customized within its definition to any element data type, e.g a Time element can have a 24-hour time format customization, a date-time attribute can be stored in yyyy-mm-dd format.
4. By adding the logic at the database level, this means that we can further customize and introduce certain attributes only to certain customers and once it is tested it can be then distributed at scale.

Element dynamic attribute showing 12/24 hour customization for Time Element

Framework details

To introduce the dynamic attributes, we had to add a set of 2 new tables in the system for “attribute reference” and “attribute storage.” In the attribute reference table we store the relation between the attribute type and its respective element data type, we also store the attribute details such as name, label, description, and validation. This enables us to dynamically add attributes without making any further changes to the application code and the table definition, avoiding a new release.

e.g of attribute reference where 24 hr format is applied to time and data-time elements

Now the Formbuilder service is designed in such a way that it will check for newer attributes at certain intervals and dynamically populate them on the UI to be used by the desired element data type. This gives a lot of benefits for quick testing and debugging the attribute type implementation.

Once the selection is made for an attribute in Formbuilder, we store the data in the attribute table for attribute type and its corresponding element id.

time format stored for element ID

The attributes are added both at the form level and the element level

Conclusion

We have strived to make this a very self-reliant experience to the end user by adding labels, descriptions, etc to the Formbuilder UI. By adding the dynamic attributes to our arsenal of strong form building controls, we have achieved the capabilities to add more flexibility and customization that our end-user community has been demanding for many years.