At greatideaz, we have invested considerable time and effort into building a Blazor user experience based on our Dynamic Page Builder technology for our trellispark platform. The trellispark UX Creator is used to create a set of configuration data that defines the form and fields that will be rendered by the dynamic page builder. This approach eliminates over 90% of the CRUD code that needs to be built and tested.
Our long-term intention is to create a MAUI variant of our Dynamic Page Builder to target cross-platform devices.
As an intermediate step we have implemented a Blazor/MAUI Hybrid approach that utilizes our existing Blazor Dynamic Page Builder within the context of a MAUI native application.
Since our ultimate target is utilize a single Form Definition data model to drive both the Blazor and MAUI Dynamic Page Builders we had a good look at the out-of-box MAUI components.
One of the obvious first things we considered was how we were going to layout the fields on a form. We loved the idea of using the “Grid” control in MAUI to layout our forms and decided that it offered some significant advantages compared to our current Blazor implementation which was based on tables/rows.
As we studied the work required we also decided that we could eliminate some complexity from our use of Subform Definitions (a mechanism for subclassing forms based on Type). We decided to consolidate all of the Field Definitions we had defined on Subforms onto the main Form Definition. We then added the idea of a Conditional Filter to select subsets of Field Definitions.
The questions then became how much time and effort was it going to take to:
- Modify the data model of the Form Definitions to support a Grid layout?
- Once the Form Definition was modified – how long to convert all of the existing form definition data?
- Review and check the modified data models looking for layout errors in the Grid?
- Modify the shared REST API Dynamic Page Builder component to support Grid layout?
- Modify the Blazor client Dynamic Page Builder component to support Grid layout?
- Modify the T-SQL Code Generation for query optimization and data migration?
- End to end test the new Blazor client Dynamic Page Generator with the new form definitions?
The answers to these questions will likely surprise you 😊
Modify the data model of the Form Definitions to support a Grid layout?
We added extra XML elements to the Field Definition data model to support the Grid (GridRow, GridRowSpan, GridColumn, GridColumnSpan, Layer).
We also added a new Form Definition for “Conditional Filter”, added that as a childlist to the Form Definition concept and finished up with adding a multi-select Conditional Filter XML element on the Field Definition.
In total these changes took less than an hour to make during a solutioning workshop with the development team.
Once the Form Definition was modified – how long to convert all of the existing form definition data?
We already had a lot of existing data models that contained hundreds of Form Definitions and thousands of Field Definitions. This means that a manual update process was not a possibility.
We added a temporary command to our development environment that could add all of the new required XML elements and Conditional Filter records based on the existing table/row data.
It took four hours to create and test the new command and another 3 hours to run the command over all of the existing data and sanity check the results in the development and QA environments.
Review and check the modified data models looking for layout errors in the Grid and opportunities to improve the user experience?
The automated data conversion process was at least 95% with minimal layout errors. We were able to quickly review and correct any layout errors. This also enabled us to simplify many of the more complex forms and improve the overall user experience.
This was the longest “technical” step in the entire process. In total, we spent 20 hours over a week to review hundreds of forms and correct minor layout errors.
Ongoing user experience enhancements is just part of our ongoing improvement roadmap.
Modify the shared REST API Dynamic Page Builder component to support Grid layout?
The REST API Dynamic Page Builder component is responsible for producing an XML fragment that combines the requested record data with the appropriate Form Definition and then applies restrictions based on the state of the record, roles of the user and any other custom business rules.
The XML fragment returned by this shared component will be used both by the Blazor client and ultimately the MAUI client.
Most of the REST API component would remain unchanged but we had to make the following minor modifications:
- Eliminate the Subform related processing as all Field Definitions would now come from the Form Definition.
- Evaluate Conditional Filters for the current record before starting to determine which fields to display.
- Apply Conditional Filters to eliminate fields that should not be displayed for the current record.
- Add the Field Definitions directly to the Tab Definitions instead of the Row Definitions.
- Eliminate the Row Definitions from the Tab Definitions.
- Eliminate the “GUID Subform” field type and update list processing for Subform fields.
In all these changes took 8 hours to make and test.
Modify the Blazor client Dynamic Page Builder component to support Grid layout
The Blazor client Dynamic Page Builder component was built around a hierarchic set of Blazor components. Rendering a page consisted of getting an XML fragment from the REST API Dynamic Page Builder component and then for the current Tab, displaying a set of Rows, and for each Row displaying the Fields.
This meant that we simply had to rework our Tab component to render a Telerik Blazor GridLayout control with 12 columns and an unlimited number of rows. The Tab control then simply had to read the XML fragment to determine which Fields needed to be displayed and then add them to the GridLayout.
In making these changes we also learned how we could use control layering to add further depth to our user experience. This was as further significant improvement to the trellispark UX capability.
These changes took 8 hours to make and test.
Modify the T-SQL Code Generation for query optimization and data migration
We use the Form Definition data models as a basis for the code generation technology used to create T-SQL for query optimization and data migration.
Since we eliminated the idea of using Subforms from our UX Creator we also had to make some changes to how the code generators worked. This simplified the code generation since we now only had one set of records that would define all of the fields on a record.
The code generator changes took 4 hours to make and test.
End to end test the new Blazor client Dynamic Page Generator with the new form definitions
The end to end testing time was mostly built into all the above activities since we use our own platform for all our development work. During the development process we didn’t destroy or change any existing Form Definition data.
This meant that we could work with the new model and new code in our development environment. During this testing phase we tested that the Blazor client worked well on the website AND that it also worked correctly as part of a Blazor/MAUI Hybrid application.
When we were ready with the new data models we pushed those in the QA environment running against the old build to sanity check that we hadn’t broken anything. Then we updated the QA environment with the new code to verify that the new user experience was working correctly.
Deployment, Form Definition data migration and testing in QA took 2 hours.
Conclusion
In total, this change took us forty-seven (47) hours to make and test over a period of five (5) working days. Nearly half – twenty (20) hours of this work was manually checking the user experience of the converted Form Definitions and correcting a few minor layout errors.
So what was the return on this investment?
- Simplifying the Blazor client Dynamic Page Builder component resulted in a performance improvement of about 5-10%.
- Simplifying the REST API Dynamic Page Builder component resulted in a performance improvements of about 20-30%
- Eliminating the Subform concepts has made the UX Creator functionality much easier to explain to new users. All of the possible form fields are now on a single record instead of being distributed across several records.
- Using a Grid layout instead of the Row/Field Position mechanism makes it much easier to explain to new users where their fields will appear on a Tab. A significantly lower learning curve enables faster adoption.
- The fixed 12 column Grid layout means that we don’t need to define specific Row Templates that determine where fields will be placed. This was one of the key benefits of completely eliminating the row concept from the platform.
- Using a Grid also means that we can create fields that can span multiple grid locations (rows/columns).
- Using the Grid also meant that we could introduce a layering concept that enables us to add background formatting to groups of controls.
The net benefits for greatideaz are huge, our customers get a faster and much richer user experience which is also far easier for them to both create and maintain.
With the trellispark Dynamic Page Builder, we were able to make a significant enhancement to our user experience capability across hundreds of forms and thousands of fields. This enhancement was designed, implemented and tested in a week by two developers.