Devity : a server driven Ui/Ux solution

What is Server Driven UI (SDUI)?

In the traditional app development world, the UI structure and business logic are tightly knit into the app codebase. Making changes? That means rolling out a new app version and hoping that users remember to update.

Challenges with Traditional Native App Releases:

1. Slower Update Cycle: The time-consuming app release process causes delays in critical updates.

2. Slower User Adoption: Users need to download and install updates, leading to slower adoption rates for new features and bug fixes.

3. Platform-Specific Code: Developers must duplicate effort on different platforms(iOS, Android) and maintain separate codebases doubling the workload. Ensuring consistent user experience across platforms can also be challenging.

4. Slow Feedback Loop: Gathering user feedback and making quick iterations is harder due to the slower update cycle and user adoption.

Server-driven UI frameworks offer a solution by separating the user interface structure and logic from the app codebase. The UI is defined and controlled on a server, enabling real-time updates and dynamic UI changes. No more waiting for users to manually update their apps—it’s instant gratification at its finest!

In general, UI layout is defined in some general purpose language like JSON → Stored on CDN → downloaded on mobile and then →  UI rendered according to definitions in the JSON.

Design Goals

Now that we have some basic idea of how server-driven UI can be a better approach to mobile development, it is time to explore what additional features a great server-driven UI framework should have to become truly efficient and developer-friendly.

1. Intuitive UI Builder – Because let’s face it, directly editing JSON can feel like decoding hieroglyphics.

2. No Restrictions on backend API contracts – Whether you’re rocking SDUI or going old-school native, the backend shouldn’t bat an eyelid.

3. Scalable JSON CDN that scales with the number of app users and is highly performant.

4. Support for advanced features – developers should be able to implement complex business logic and UI behaviors, instead of feeling the need to shift to native development.

5. Easy to Debug – UI and logic issues debugging should be just like native development – minus the headache.

6. Inter-Widget Communication – Like filling out an age field and seeing the submit button light up.

7. Support Dynamic UI – Popups, BottomSheet, and ToolTips to give more flair to UI.

8. Versioning Capability – Support editing across different app versions and functionalities specific to each version.

9. Maker-Checker driven changes – To ensure that production changes undergo a review and approval process

SDUI Framework

The framework consists of 3 integral parts.

1. Web Console : This is your design command center. It provides an intuitive UI for constructing and maintaining a Spec (or workflow) using pre-populated attribute inspectors and drag-and-drop features.

2. Backend : Think of this as the engine room. It houses the APIs that power the Web Console, stores your spec creations, and validates your specs. It also manages publishing your JSON-representable specs to CDN.

3. Client SDK : downloads the JSON-representable spec created in the web console and seamlessly transforms it into a functional app flow.

In the diagram, users start with crafting specs (or workflows) using the Web Console. They can add screens, renderers (or layouts), widgets, actions, and other components to build their desired workflow.

Web Console – Backend Interaction

The backend stores the tree structure of the spec and validates the data provided by the user for each component, ensuring everything is accurate. Once developers finalize their spec, they can publish it, signaling Backend to transfer all the nodes to CDN. To publish nodes to CDN, developers need to request approval from peers through the maker-checker process, ensuring stability and quality for end-users.

App – CDN Interaction

Once the JSON-represented Spec Tree is fetched from chimera, the app springs into action. It parses the JSON, loads the initial screen, and invokes the initial actions to kickstart the workflow.

In debug mode, app developers can consume the spec tree directly from Backend, bypassing CDN and the approval process. This allows them to develop and test their specs more efficiently.

Below diagram shows a spec tree consisting of nested renderers and widgets and an action container that holds multiple actions:

Framework will have :

1. Prdefined widgets to build most of the complex UIs.

2. Actions like screen navigation, REST api call, alerts, loaders etc to make the UI interactive and functional

3. Expressions which can be used to write arithmetic, boolean and logical operations and craft business logic on the console.

4. It should allows developers to create external widgets and actions that can cater to very specific requirements like performing CRUD operations on a local database.

This rich toolkit can empowers app developers to effortlessly craft product workflows, implement business logic, and create interactive, dynamic UIs with ease, without worrying about app releases and user adoption.

SDUI ToolKit

SDUI Spec is a tree representation of a workflow crafted on web console. This spec is converted into JSON and stored in a Config Store (CDN). The App downloads this JSON and, using the Client SDK, converts it into a fully functional native workflow.

A Spec comprises of following components:

1. Renderer – Organizes widgets in a specific layout pattern.

2. Widget – Fundamental UI building block.

3. Style Properties – Visual attributes like border, background color etc

4. Dynamic Data – App runtime data. Example showing policy price coming from backend.

5. Actions – Event handling. Example triggering API call, showing loaders etc

6. Expressions – Logical, arithmetic, and relational operations.

7. Rule – Powers inter-widget communication. Example making the submit button light up on age field submission.

These components form a rich toolkit, enabling developers to build SDUI workflows. Let’s take a closer look at each of these components.

Renderers and Layout Philosophy

Any complex screen can be broken down into nested renderers(or layouts) and widgets. This gives us the initial structure to build a screen using SDUI. Let’s take an example of a screen.

A SDUI screen can have a Navigation Bar and 3 root-level renderers as shown on the above diagram:

1. Top Renderer – sticks to the top, with its height increasing as more widgets are added

2. Main Renderer – scrollable renderer containing the main content

3. Bottom Renderer – sticks to the bottom

Developers can add widgets and nested renderers within these root-level renderers.

The screen above shows an example of how main renderer has a three distinct renderer inside.

The possible renderer(Layout) options which we can have

We can keep the same name what flutter uses or something like above to make it generic.

Widgets

We can create a diverse library of widgets, including text fields, steppers, sliders, date pickers, buttons, text elements, images, and info cards, all aligned with our design language. The console widget picker can provide previews, which makes widget selection a breeze.

Each widget in SDUI will have defined attributes and a specific UI function. For instance, a date picker widget lets users select dates and have attributes like default date value, min/max date, and display format. An info card widget has attributes like an array of texts, left image, and right image.

A new widget is created and its attributes are defined using the console’s widget creation tool. Developers can define these attributes using primitive types (String, Int, Double, and Bool), or opt for custom types (TextModel, ImageModel, ButtonModel). For instance, the text in the date picker widget is of type TextModel. Attributes can also support collections, such as an Array of TextModel for an info card’s texts property.

TextModel Custom Type Definition:

New custom types can be on-boarded onto the Console, allowing developers to create custom data models tailored to specific needs.

The above diagram shows an example how the web console looks.

1. UI Builder for Main Renderer.

2. Date Picker Widget Attribute Inspector.

3. TextModel Custom Type Attribute Inspector.

4. Static/Dynamic Value Editor for an attribute.

While working with these attributes on the console, developers can give either a static value or a binding to consume dynamic data.

Dynamic Data Binding

Static data is known at the time of crafting the spec whereas data is considered dynamic if it gets generated at runtime. Examples include:

• Data coming from network API calls.

• User input data.

• Data stored in memory or database.

SDUI should enable developers to define schemas to bind dynamic data to UI by providing three options:

1. JSON Data: Includes data retrieved from APIs, static configurations, and JSON-representable data in memory. This is accessed using a JSON path.

2. Widget-Generated Data: User input data generated by widgets.

3. Expression-Evaluated Data: data generated by evaluating expressions, on static and dynamic data.

The below diagram illustrates the Web Console UI for binding dynamic values to an attribute. It also displays the JSON received on the app.

Expressions in SDUI:

Style Properties

After selecting a widget inside a renderer, developers can customize its visual attributes – such as border, background color, padding, corner radius, gradient, and more. These attributes are standard across all widgets and do not depend on the widget type. Developers can assign only static values to these attributes.

Actions

SDUI’s actions and event-handling infrastructure enable users to interact seamlessly with the UI.

Some of the actions to be supported by SDUI Framework:

Just like widgets, actions also have defined attributes and a similar attribute inspector UI on the web console, allowing developers to assign both static and dynamic values.

Developers can create multiple actions and link them to widgets by referencing action Identifiers within the widget’s attributes. For instance, the ‘onClickActionIds’ attribute of a button widget supports an array of action IDs, which are triggered sequentially upon a user tap. SDUI’s event handling creates a chain of actions and serially executes them.

Developers aren’t limited to predefined actions; they can create custom actions to meet specific needs. This flexibility allows the implementation of custom business logic, such as performing CRUD operations on a local database, ensuring that SDUI can adapt to a wide range of use cases and requirements.

Rules

SDUI should also support defining rules that facilitate inter-widget communication.This means that user interactions in one widget can trigger changes in another, like enabling a button when data is entered in a text field.

Here’s how it works: a rule listens to both the Age and Pincode widgets, evaluating an expression (in this case an AND Expression) to check if both contain valid values. If the conditions are met, the rule triggers the “Update Widget State” action, enabling the button. Otherwise, the button remains disabled.

Bringing It All Together

Now, let’s see how these pieces come together to power a server-driven workflow. The diagram below illustrates a sample spec tree, providing a clear overview of how these elements interconnect.

We're excited to announce that we're developing an open-source product that’s currently in progress. Stay tuned for upcoming releases that will empower you with cutting-edge features, ready to make a real impact.

References :

1. https://tech.phonepe.com/introducing-liquidui-phonepes-server-driven-ui-framework/

2. https://tech.phonepe.com/liquidui-phonepes-server-driven-ui-framework-part-2/