Requirements of a Platform for Building Enterprise Class UIs on Cloud

Published in

trillo-platform

10 min readAug 9, 2017

Imagine the scenario that you have a comprehensive set of UI components designed according to company’s styling guideline. Also, there is a tool available that allows you to stitch components on a page visually and customize them. It lets you define page transitions, actions, and API endpoints. If it all becomes possible, UI development would become analogous to creating a PowerPoint presentation with animation. Teams will be able to craft UIs quickly. Rather than spending time on plumbing, they will be able to focus on new innovations, such as new processes, motifs of UI or advanced components.

Is this a pipedream? Not anymore. In this article we will discuss a few platforms that are slowly and gradually moving industry in that direction.

Not only that, such a platform will fuel new innovations; it can also mitigate project failures by delivering a flexible-UI. The meaning of flexible-UI in this case is that it is easy to make changes to UI while maintaining its stability. Team members should be able to iterate and deploy in minutes and not in weeks. In order to achieve these goals, such a platform should meet certain requirements. We discuss those requirements. Finally, we conclude by discussing available cloud-based UI platforms.

Problem

Cloud services from Amazon, Microsoft, Google, IBM etc. have accelerated application development on the server side. However, UI has seen the opposite. Stitching together a client facing functionality requires a long time. Over the past two years, we observed 3 large-scale applications. Each failed due to the long development cycles in spite of having excellent multi-functional teams. Each project cost $20-$30 millions. Although the UI share was 20%, an early delivery of a functioning MVP (minimum viable product) would have given teams insight into user requirements. These projects might have succeeded or at least failed sooner (hence saving costs), if there were a process and platform to help deliver MVP sooner.

Time and time again we have seen this being repeated. The industry research shows that it happens 68% times.

Solution — Deliver a Flexible-UI Quickly

Due to complexity of real-life problems, the insight is gained as the project progresses. Assuming that the specification will be frozen, before the development begins, is not practical and possible. In fact, committing to specification and resisting its changes is a recipe for failure. The specification changes are reality and we need to learn to live with them.

The specification changes can be categorized into two broad buckets — server side changes and UI changes. The server side changes are generally contained (even if they are complex). The changes on UI side are numerous, open ended and painful. They seem to keep coming. Team should be able to incorporate them in UI quickly.

Looking at the above discussion differently, the availability of a UI during the development of project is critical for fine-tuning. The real appreciation of the solution and its applicability for the business problem comes only after seeing an application in action i.e. feeling its dynamics through UI. Due to the complexity of domain it is hard to stretch imagination and think of all scenarios including exception cases. Therefore using a flexible-UI, to help gain insight into the application, is the best approach. The speed of churn is also important i.e. teams should be able to iterate over UI quickly and without causing stability problems. If UI is not evolving fast enough from users’ perspective or not stable, users will lose confidence in the project.

At this point we can somewhat conclude that, an early delivery of a flexible-UI or MVP can help remedy the project failures or conclude non-viability of the project sooner. It can expose the limitations of the backend services and suitability of application for the business problem. It can even mitigate project management issues. Early UI successes energize team. It is like being on the home court and 20 points ahead of your opponent. There are high fives everywhere.

An early delivery of UI can save millions of dollars.

Technical Challenges

In past, some of us have tried to build platforms for flexible, stable and rapid UIs. The past attempts failed due to following reasons:

There was a lack of understanding of UI meta-model and how to weave it with the scripting. Therefore the output of the tool was hard to comprehend and it made the tool convoluted.
The backend services were not accessible through well-defined APIs. This lack of standardization required that the developers handcraft backend interactions.
The cloud technology was either not available or had a limited availability. This created a hurdle in defining team collaboration and automated deployment process.

Ingredients of Flexible-UI Design

Let us look over the important ingredients for building a flexible-UI at a faster speed.

Componentized design.
Availability of component library styled as per company UX guidelines.
Ability to stitch components into pages by drag and drop.
Ability to specify page transition.
Simple scripting model to incorporate any business logic at the periphery (without intricate wiring).
Collaboration among teams members (including product/ sales and marketing people).
Deployment within seconds.

Componentized Design

Use of components is a de facto pattern in UI design. In order to be flexible and modular, components should follow a metadata driven implementation as discussed below.

Example of Components Used in an Application

To make a UI flexible, we want its components to be highly configurable. It will allow a tool to reconfigure them in place and save modified configuration in a repository (code repository or application data repository). A configurable component makes use of some kind of expressive language and exposes a set of meta-properties. Fortunately HTML and CSS (our focus is web UI in this post) are expressive languages and they take us a long way in making components configurable. If we can edit HTML and CSS of a component in place and save in the repository, it would let a designer/ developer configure look-n-feel of components easily. There are several other structural aspects that can be captured in metadata using declarative programming style. A few examples are as follows:

Backend API specification for a component in JSON.
Role-based access control.
Well-known action specification.

By allowing meta-model to be extensible, domain specific meta-properties can also be specified and edited using the tool.

Another requirement is that components should make use of a well-defined base API and application context (data-space or state of UI) so they can co-exist with other components and within environment (a page in this case). The following list further elaborates it.

Lifecycle management API and ability to intercept them (example preRender / beforeMount, afterRender / afterMount).
Ability to add handlers to important UI events such as click or keyboard shortcuts.
Make use of current context to infer parameters required to create a component’s instance.
Component should be able to add its state to the context.

By default MVC (model-view-controller) is a popular pattern for components API. For a metadata driven component, its runtime MVC classes should make use of metadata. It would also mean that the several components of the same type could use the same MVC classes (JavaScript code). The need to write or extend MV for a particular instance of a component should be rare. The extension of ‘C’ (controller) would mostly be limited to business logic. The framework should, at the same time, permit that the new implementation of application specific MVC classes could be added and used like framework classes. These assumptions make the framework opinionated.

The lines of application code reduce drastically if several instances of a component of a type can use same MVC classes and differences can be incorporated through metadata configuration.

Let us consider a concrete example of how a configurable component is used. For example, a table component may be used in a UI at several places. It is same at each place except the APIs it uses to get data from the backend are different. A team member should be able to drop the component on the page, edit API specification. It should be transparently saved in the code repository. Let us go one step further. Say, in one-instance API returns the data in the format as expected by the table component. In another instance, the data needs to be transformed. A developer should be able to specify the custom controller for the component. This controller will receive a call to intercept the result and return modified data.

Library of Components

A platform should provide a set of commonly used components out-of-box. Also, users should be able to build new components using tool’s visual interface or by importing external templates. A team should be able to customize components to match the company’s styling guide.

Stitching Components Together

A page is a collection of components placed in a visually appealing layout. Another characteristics of these components are that they may have interdependency so a component can be instantiated only after its predecessor is available. A predecessor provides context for the successors. For example, in case of a list-detail view type UI, a detail view shows the item selected in the list. Therefore, a detail-view requires that the list view exists before it.

Components can be stitched on a page using a drag drop tool, which provides the following features:

It shows the drop points where a component can be dropped in the page grid. This keeps the layout sane.
It provides various properties dialogs to configure components in place such as API spec, CSS styling, dimensions, rules for resizing components on different size screens etc.
It can use the drop order as the implicit order of component instantiation or provide some kind of UI motif to let the user define dependency. Implicit ordering is intuitive, easy and does not burden users with extra interactions. Therefore it may be a preferred convention.

Page Transition

In a rich UI there are two types of page transitions, a) UI navigates away to a different page; b) swapping few “div” or other elements within a page based on some user action. Navigating to a different page is easy use-case. It can be achieved by a link element’s “href” attribute. Swapping of “divs” within same page is typically what is required for an enterprise UI (to give it a feel of native UI).

User should be able to specify both kinds of page transitions intuitively using a design time tool.

Scripting Business Behavior

Cleanly scripting business behavior is another requirements of a flexible-UI platform. It ensures that the code does not become unstable due to any code change. In a metadata driven framework, it is expected that addition of new MV classes will be rare. When MV classes are extended, it can be handled as a special case and require more rigorous testing. Otherwise, typically a “controller” class would be extended for adding business behavior. The controller class receives all important life cycle events, user action events. For example, a controller class should be able to override “postRender” method to set state of UI elements based some business logic. Another example, when use clicks on a button, the action should be delivered to the controller first before the default action is executed.

New Type of Team Collaboration

The word “new type” is to stress that a UI platform can enable collaboration that is more effective and efficient. Consider the following scenario:

1. UX person wants to change an image in UI.

2. She designs a new image.

3. She will send email to developer with a link of image or as an attachment.

4. Developer will download image, place in the right folder of application, change code, push changes, do new build and deploy.

5. UX will verify the changes.

The alternate process can be:

1. UX is looking at the UI; she double-clicks on the image and changes it.

2. She confirms her changes; the platform creates a new branch and pushes code to GIT.

3. A senior developer can merge her changes after regular process of approving pull-request etc.

The new type of team collaboration means that every member of team should be able to contribute directly to the code base when possible. She/ he should be able to so without messing up the application (merge process is still controller by senior developers). In order to make it possible and convenient, such a platform should provide transparent integration with Git (or other source code control system).

The following diagram depicts the new type of collaboration process.

Auto Deployment

We cannot stress enough the importance of quick deployment of UIs. The fine-tuning of UI requires that changes are made quickly and verified. Ideally, a member should be able to test without browser refresh. In a complex environment where UI is interacting with multiple services, you need to deploy it in an environment, which is similar to your production environment.

One more important point for the cost control, a team may have several members (sometime 3 digit). Any member should be able to deploy any branch or any number of branches for verification. Each deployment should not require spinning new VM or container. The cost of development will spiral if the platform cannot support multiple versions of code using one container/ VM. It means that the platform should provide a logical sandbox for each branch.

The ideal deployment scenario is the one in which one web-server can pull any number of branches directly from Git, sandbox each and serve anyone of them based on the selection by user. It is depicted using a diagram below.