The user experience of a typical enterprise application is provided by hundreds or even thousands of pages created by developers. Each page will display a set of fields and offer the user a set of allowed actions they can take.
At its root, each page may provide access to an underlying database record with additional context including child or other related records from the database or from other data sources/APIs.
Sometimes we may need to create multiple pages to display the same record depending on the status of the record workflow or the role of the user. For example, consider an HR application and a “worker” record. The user experience of the worker record (e.g. which fields are visible / editable, how information is displayed, etc.) will be very different when the status of the record workflow lifecycle is either: “Application, Interview, Employed, or Terminated”. We could code logic on a single page to deal with the record status, or create separate pages for each record status. A similar argument exists for different user roles: if the user is a “candidate” then their user experience will be very different to an “HR admin” user. So in the end, we can often end up with a single worker page with lots of logic or multiple worker pages that need to be maintained together.
Whilst some of these pages can be very simple, others will be very complex. Based on our analysis of many projects, we found that the code used to render a record and its context on a page and then transfer changes back to the database, or initiate an action, averages around 1,000 lines. This includes accessing the database, data models/business objects, controllers, views and content validation etc. A moderately sized enterprise application with 500 pages can have about 500,000 lines of code controlling its user interface.
In addition to the user experience pages and code, we also need to create some test cases and scripts. Based on past projects, to properly test an application, this can easily be 2 or even 3 times as much code as that in the user experience. We also have overheads of regression testing as we change the application over time.
Our trellispark platform is a “pageless” approach to building enterprise applications.
If we can eliminate 500 pages and 500,000 lines of code and another 1-1.5 million lines of test cases, then we have significantly reduced the cost, time to market, and risk with building an enterprise application.
The real question is how does trellispark enable us to build pageless applications?
We started by separating the concept of user experience from its implementation as a set of pages.
We emphasize that a user experience does not have to be produced by an actual page in the application.
We defined a simple component hierarchy to implement a dynamic page builder to render the user experience at run-time:
- We defined a user experience as a “form” which will be displayed to a user. A form may have one or more tabs, only one of which will be displayed to the user at any given time. Whether the tab is displayed will depend upon a number of tab permissions which will include: the state of the record being displayed, and the role(s) of the current user.
- On any given form tab, we defined a set of fields that could be displayed for the user. Whether the field is displayed will depend upon a number of field permissions which will include: the state of the record being displayed, the role(s) of the current user, the content of the record, and perhaps other custom logic. Of the fields displayed to the user, a subset may be read-only based on the same set of field permissions.
- A “field” is a generic component that includes information that determines where on the tab it is to be displayed, a title, descriptive/help text, and a specific component for the type of data being displayed/updated/validated.
Using these 3 hierarchy levels (form, tab, and field) we can define in configuration data any required user experience using our trellispark UX Creator app.
The trellispark implementation of dynamic page generation starts on the server. When a request to load a page is received, the required record and form definition is retrieved from the database. The record and form definition are combined on the server with the identity and roles of the current user to create a user experience (UX) definition which is returned to the client. This ensures that only the minimum required data is sent to the client.
On the client side, the UX definition is processed by a set of Blazor components to render the desired user experience and wait for the user’s next action. If the user changes the data being displayed, then those changes are sent back to the server and the page is reloaded. The user could also chose to initiate a workflow action, in which case any changes to the record are saved before the action is executed and then the page is reloaded.
Using this simple dynamic page builder approach means that trellispark can be used to eliminate all the user experience pages from an enterprise application. Instead of having to create, maintain, and test page code. We just have to create configuration data to define the forms, tabs, and fields required by our application.
These form definitions can be created by non-technical resources (e.g. Citizen Developers) and refined during user experience workshops. It is frequently faster building the actual user experience using the UX Creator than it is to create and document wireframes. Being able to define and test the actual UX in the workshop significantly shortens development cycles and increases the quality of requirements.
The trellispark platform doesn’t completely eliminate the need for code. There will always be workflow actions that will need to be custom coded and tested. For example, we may need to process orders and calculate taxes. This code is going to be required whether you use trellispark or a traditional page-based user experience. Workflow code should be abstracted into its own business object or API independent of any user experience code. Based on past projects, the total workflow code in an enterprise application using pages averages less than 5% of the total lines of code. This means we can substantially reduce the volume of total code required for an enterprise application and focus our development effort and quality on the remaining code.