Building InsureTech UI with an Excellent User Experience
In an earlier blog, we discussed how to build a serverless InsureTech backend. This blog discusses the user interface of the suite. The source code for the entire UI is available in Github under friendly MIT license. The repository is the same as for the backend.
Although the backend can be used with UIs built using any other technology, the UI described here provides several benefits.
- Using provided code and its documentation you can customize it easily and deliver your solution quickly.
- You can customize it using a visual environment, which is freely available.
- UI is based on open source technologies and primarily uses jQuery and Bootstrap. It is relatively easy to find resources with knowledge of these technologies.
- UI development does not require any DevOp pipeline. Simply make changes and deploy on the runtime using a single click.
- A separate sandbox is automatically used for each developer and environments such as “int”, “staging”, “production”. It allows you to make changes frequently and freely without breaking anything. It makes UI development iterative and you can do it in conjunction with the end-user.
- UI follows a simple componentized model (inspired by web-component). It is modular and easy to customize.
- It is a responsive Web UI with a smaller footprint and progressive design. It can run optimally on all devices (phone or tablets).
Let us get into the details of what constitutes the UI and how to customize it.
Structure of UI
All modern UIs are single page UIs. A single page consists of the following parts:
- The top part is the header and it consists of a few metatags (title, search words) and links to “css” files.
- An HTML fragment in the middle is for the main content.
- The bottom part is a list of “js” files.
Since we want to keep our UI independent of any tooling and DevOp, we take the following approach.
- We create a JSON file listing all metatags.
- List all “css” file in a text file. To make it optimal, we have a version of this text file listing all minified files.
- Create one HTML file for the middle portion.
- List all “js” files in a text file. Similar to “css”, we have a version of this text file listing all minified files.
Since our focus is what goes inside the middle part, let us briefly discuss the top and bottom portions and get them out of the way.
JSON File for Application Page Metatags
For our single page UI, we specify all metatags that go in the header in a JSON file. The following JSON file lists the metatags for our InsureTech application.
Text File for CSS
We list CSS files in two text files. One is for all open source libraries. These libraries can be specified using the CDN URL or downloaded locally and linked accordingly. The second file lists all CSS files that are the part of the application.
- See an example text file listing open source CSS files.
- See an example text file listing application specific CSS files.
Text File for JS
Similar to the CSS file, there are two text files listing all JS files — 1) open source JS files, 2) application specific JS files.
- See an example text file listing open source JS files.
- See an example text file listing application specific JS files.
Why text files?
Our runtime application server uses these files to serve JS and CSS along with the main page content. The application server takes the responsibility of optimally serving these files (minifying, combining etc). For developers, it keeps things very simple and makes modular. It eliminates the need to have a DevOp pipeline.
These files and their locations in the code are discussed in details in the documentation linked from the Github.
Main Page HTML
Since our application is a single page UI, it has a bootstrap page. Let us refer to it as the main page. The top and bottom parts of the HTML page are constructed using the information above and not required to be the parts of the main page file. Therefore, our main page merely refers to the content HTML. If our page is a “Hello World” message, the main page file could merely read as follows:
<div><h1>Hello World</h1></div>
The runtime application server would construct a valid HTML file with the top part (head + CSS files links), body and the bottom part (JS files links) as follows.
Building UI Page using Modular Components
In our approach, we have to primarily focus on building the content of the body to create a UI.
Let us see, how it is built in steps and what we mean by modular components.
Imagine UI scenarios. For simplicity, let us assume the following.
- UI has a top bar.
- It has a sidebar for navigations to different scenarios, say Home, Tasks, Documents, etc.
- By default, Home is selected.
- In Home page selection, UI shows a greeting message.
It leads to the following conclusion.
- UI has a topBar component.
- UI has a sidebar component.
- UI has a component (panel or card) which displays a nicely formatted greeting message.
We want to display these components when the UI comes up. In our componentized approach, it is done as follows:
- Create an HTML file for the top bar (topBar.htm).
- Create an HTML file for the sidebar (sidebar.htm).
- Create an HTML file for the greeting message (greeting.htm).
- Using CSS framework of choice (say Bootstrap 4.3), create the page layout as a grid. (page.htm)
- In the top cell add attributes so the framework JS code can inline topBar.html.
- In the top cell add attributes so the framework JS code can inline sideBar.htm.
- In the main cell add attributes so a framework JS code can inline greeting.htm.
The following page.htm snippet will give an idea, how could it work. A brief mention that the “row”, “column” css defines a “grid”.
The above code will render the page by including three components. We would later see, a) how each component gets the data from the server, b) how data-binding works, c) how UI events are handled. Let us first see how our single page UI implements navigation and state transition of the page.
Navigation and the Multiple States of the Page
Let us say that our page shows “greeting.htm” page when the path is “/home” and it shows “task.htm” when the path is “/task”. By adding the path info as a custom tag in the HTML we can support the multiple states of the page and state transition (assume that our JS framework interprets the custom attribute and acts accordingly).
See the following HTML template and notice new data-trigger attribute.
In the above example, “data-trigger” attribute instructs to the framework to inline “greeting.htm” when the path is “/home”. Otherwise, it is hidden from the view. Similarly, “tasks.html” is inlined when the path is “/tasks”, otherwise it is hidden.
Anatomy of Component
So far we saw how components’ are specified in HTML and, they are stitched in a page to form a scenario. We also saw how to transition to different scenarios.
But a component is more than HTML in a real life. It has data and it has behavior. Our example “tasks.htm” can have the following specification:
- “tasks.htm” will get the list of tasks from the server and display as a table.
- When the user clicks on the title of the task, it will pop up a dialog showing the details of the task.
- When the user clicks on the complete checkbox, the task will be marked completed in the server.
A component with data and behavior, as described above, is implemented using model, view, and controller (MVC) pattern. The MVC is followed by all frameworks in some form. In our framework, they are specified as follows:
- View: a view is specified in HTML. It has an associated JS file to render its dynamic parts. JS code is provided by the framework. You have the flexibility to extend the framework class. In 99% of cases, the framework code suffices without any change.
- Model: a model has two parts, how it gets data and a runtime object to manage the data. The details of how to get data from the backend are specified in the JSON file as API-specification. The JavaScript model class provides methods to access, update data, listen for events. It also provides methods to rollback changes. The runtime class of the model is provided by the framework. The framework provides flexibility to add new models. In 99% of cases, the framework code suffices.
- Controller: the controller JS class manages UI events and also supports the application specific logic. In our design, an application specific controller extends a framework class. A controller also receives all life cycle callbacks and they can be overridden. These callbacks are such as “modelAvailable”, “preSetup”, “previewViewShow”, “postViewShow”, etc. I
In approach discussed above, as an applicaiton developer, you are not required to write much JavaScript code in UI . You can build 80–90% UI by simply specifying it in HTML, CSS, and JSON files. Since HTML, CSS and JS files are expressive, it is easy to code them. In a later blog, we will show how a UI Builder and an IDE like environment in the browser futher simplifies authering them.
The following table shows how much of the UI code you would write in a typical application.
Model & API Specification
In our framework, models are specified in a JSON file. We follow the naming convention to correlate files of the “view” and “model”. For example, “tasks.html” which is “view” of a task list, has corresponding “tasks.json” for the model specification. In fact, “tasks.json” is also used for other meta-data of the “view”. In the detailed document, we discuss all meta-data of a view. The values inside the JSON file can be templatized using Mustache template-specification. The following shows an example JSON file for the model and API specification.
You will notice that actions can also be specified in a declarative way. The above shows an action, which means, when the user clicks on the “title”, navigate to “TaskDetail” view.
Controller Logic of a Components
The controller is JavaScript code extending a framework class. A custom controller for a component can be added by following naming conventions (there are other ways to add a controller if the same code has to be reused in two components). In our example “tasks.htm”, “tasksC.js” would specify the controller code for “tasks.htm”. The suffix “C” indicates that it is a controller.
A controller receives all life cycle callbacks and events. A callback or event can be intercepted in the controller code for adding the application-specific logic. The following code shows an example controller.
Commonly Used Components
Our framework provides several components out of the box such as form, wizard, top bar, sidebar, tab, table, data table, editable table, tree, card, panel, modal, non-modal, alerts, charts, banners, etc.
Anything that can be specified in HTML can be used as a component by following the naming convention.
Importing a New Themes
There are several sources of professional quality themes (material, responsive, paper etc). The detailed documentation covers how to import them. This gives you a head start to building beautiful and professional UIs.
InsureTech Suite UI
Our InsureTech UI is the part of the same repo as the server. The UI specific files are contained in the following directories.
- The “view” directory contains HTML files of all views.
- The “viewSpec” directory contains JSON files with model, API specification. In fact, our JSON file is capable of holding other metadata (discussed in the detail documentation).
- The “static/css” directory contains the application specific CSS files.
- The “static/js” directory contains the application specific JS files.
- The “static/img” directory contains the image files.
- The “static/font” directory contains font files.
- The “_vendor” directory contains the references to the open source or external libraries.
Customizing InsureTech UI
You can follow these steps to customize InsureTech UI.
- There are three distinct applications in it: a) quote: quote to buy process UI, b) SelfService: self-service portal, c) InsureAdmin: backend insurance administrator.
- Familiarize yourself with the code (view, viewSpec, css and js directories within each application directory).
- To add a new view, you can copy an existing HTML file, its corresponding JSON file and change it. The document also provides a link to an online UI Builder / IDE like environment to do it conveniently.
- To modify an existing view, edit its HTML, CSS, JSON or JS files as needed.
- To create a new scenario, edit the main page file (same name as the application). For example, if you want to create a new scenario in SelfService, edit SelfService.htm.
Final Conclusion
Building a UI for the top class user-experience and look-n-feel is a daunting task. It is time-consuming and requires multiple iterations. In this blog, we described an approach to simplify it by using a modular approach. We also split the UI construction into two parts:
- Declarative: Bulk of UI can be specified using HTML, CSS, and JSON. It enables people with HTML and CSS skills to focus on visuals. The declarative HTML is complemented by an intelligent framework that can interpret custom tags, attributes, etc and synthesize the dynamic behavior.
- Behavioral: This is written in JavaScript code. We try to minimize the JavaScript code and, require only for the application specific logic (eliminate it for all types of plumbing such as routing).
Finally, you can view the UI in action at the following URL. This is the “quote” application UI. If you walk thru it completely then you will receive an email provided at the end. The link in the email will walk you thru the SelfService portal. The email is the part of the application flow and, the email is not used for any other purpose.
