Empowering UI Workflow Creation on the go — Introducing State-of-the-art OmniWidget
Introduction
In today’s fast-paced digital landscape, ensuring optimal application performance is paramount for us at Airtel in order to deliver seamless user experiences and maintain a competitive edge.
At Airtel, we have nearly 5 million users visiting our various channels, such as New Service Order (Airtel Black / Broadband / Prepaid SIM / XSafe, etc.), for changes in existing services, and shifting of existing services among others. All these products and services require their own customised journey and we need to constantly adapt to the changing market conditions and ever-increasing customer expectations. Hence, it is very important for us to keep modifying our website as well as Airtel Thanks App to cope with fast paced market.
To solve the above problems and bring more uniformity to customer experience, we embarked upon the journey to gain the ability to define user journeys without having to write a single line of code for both, mobile app and web. At the same time, we made sure that the process is so simple and robust that we can run multiple A/B experiments at the same time.
We call this sophisticated, yet powerful, engine — OmniWidget
In this blog, we will take you on a step-by-step journey through our OmniWidget and highlight its unique features and capabilities.
Background and Motivation
Before the advent of OmniWidget, we faced numerous challenges when it came to effectively launching UI/UX for new products/services or upgrading the UI/UX of our existing services.
A tedious development effort was required, followed by rigorous testing. Running multiple variants of the same journey made the situation worse. This led to slower turnarounds and reduced productivity in terms of driving the growth numbers. Technically, this also led to more frequent code cleanup cycles to get rid of functionalities not in use, which in turn increased the pressure on our engineering teams.
All these problems, and more, motivated us to come up with a UI rendering engine that would not rely on any preset template for modification. In short, we had to create a system that will create the entire UI based on some configurations, would understand what should happen on every user interaction, take action based on the configuration, enables AB Experimentation, and runs on both Web and App.
Solution
To create an application that would integrate smoothly with Android Native and iOS Native applications, the clear choice for us was React Native.
For the application to work on the web as well, we used react-native-web. This way, we employed a mono-repo structure to develop the application for both our web and app consumers.
For integration with web journeys, we support IFRAME-based integration.
This readily enables us to send the updates on the fly in extreme cases when there is a code change.
For integration with Mobile Apps, we support SDK-based integration wherein we expose OmniWidget in a native language SDK.
Architecture Powering OmniWidget
As soon as OmniWidget is opened, it requests all the configurations from the backend. Which fields to render, prerequisite API requests, whether the field will be enabled/disabled, whether the field will be visible/hidden, whether there are validation errors on the field, actions to take onBlur, onFocus, onClick, onSelect, onDrag, etc., are some of the examples of how configurations drive the entire UX. Along with this, there is a theme engine that applies CSS styling to each of these fields.
The configurations to send to the client are decided based on the defined user cohorts. This approach enables AB Experimentation without requiring us to write a single line of code.
As a design principle, we were focused on breaking down the entire webpage into the smallest of components, figuring out what they’ll need to function, and in a pyramid approach, we finalised which components are the best fit for our code — once architecture.
How OmniWidget Solved Basic Problems of Traditional Webpage
A. Component Layout
We return all our component configurations in a tree-like structure, similar to how we would code in a dedicated mobile app
B. Data Feeding
For every component, there is a dynamic entry created in the redux store. Each component refers to its own entry in the redux store to show its data.
C. Data Fetching and User Interaction
We developed a TaskEngine driven completely by backend configurations. Each task is very basic like setting a certain value in the redux store, firing an API, sending data to the parent, etc. Each task has the ability to create its custom payload based on data present in the store.
For a city dropdown, we first have a premount task that fetches the list of cities from the backend. Then another task sets it in the exact location in the redux store which the component points to. Whenever the user selects a new city, the same field is updated.
D. Conditional Visibility, Disability or Validation
We developed a RuleEngine which implements basic rules like AND operations, OR Operations, isEmpty, isNotEmpty, equals, regexMatch, etc.
Based on these rules, we configure under what condition visibility is allowed, disability is enforced, etc
E. Conditional Task Operations like form submit
Our TaskEngine is hidden behind RuleEngine. This way we define what Task to perform if defined rules are passed or failed.
F. How did we manage to style
As mentioned above, we have assigned a unique ID to each component. This way, we can simply send our stylesheet from the backend, and each component refers to its own stylesheet.
These are a few of the examples in which we solved basic UI operations
Other benefits of this Architecture
A. Smaller Teams to achieve bigger tasks
Since the entire UI is created using configurations, we don’t need dedicated development and testing teams for each product. A single team responsible for maintaining OmniWidget is all it takes.
B. Faster Adaptability and Lower GTM Time
Writing configuration is much faster than writing code and hence we are now in a position to create entire UI journeys in a matter of days. This way, our GTM time is very quick.
C. Faster Onboarding
Since it’s the same team and one single product, the overall learning curve for new members of the team is much lower now.
Conclusion
OmniWidget helped solve a business challenge for us which is the quicker turnaround.
Given it’s State-of-the-art architecture, we don’t need to pollute our code with redundant functionalities. Since it’s based on a minimalistic approach, code is much cleaner and much easier to maintain.
We don’t need a large team to maintain it and our existing team of React developers can now maintain the Android, iOS, and Web products and hence nullifying the need for larger teams.
Because of a single repo and single interface, our monitoring is more efficient and requires much less time.
Credible Mentions
Special thanks to the entire OmniWidget team for making it come to life.
Abhishek Sukhija, Kushagra Chadha, Sharad Agarwal, Sidhant Gupta, Shubham Bansal and Rajnish Kumar
Blog Authors: Abhishek Sukhija, Kushagra Chadha & Sharad Agarwal
