Many companies want to offer their products and services as both web and native experiences — so-called multi-screen application development. Application development on various devices is historically siloed. Every device-specific team performs the same tasks:

• Orchestration of calls to underlying domain services for data

• Massaging the data from various services to fit into UI’s need

• Performing L10N translation and formatting on data

• Implementing Experimentation of features

• Handling user behavior tracking

• Presenting UI to end user and managing user interactions 

Presentation work is truly device specific and must be done for each device type. Other works are almost the same, but duplicately developed on all devices. This approach has caused many problems:

• Duplicate development wastes engineering resources. It is not a scalable process.

• So much duplicate work by each team slows down business feature time-to-market.

• Users see different experiences on different devices. Features are either not available or implemented differently.

Delivering new business functionalities to all native app users with a fast time-to-market is particularly challenging. Studies show that 70-80% of users upgrade to the new app version within a couple of weeks of its release. The remaining 20-30% users wait up to 2 years before getting latest business features. Therefore, we need a different approach that can deliver business functionality to most mobile users with minimal or no change to the mobile native app.

Experience Service Comes to the Rescue

An Experience Service removes duplicate work by centralizing those duplicate tasks into a new server-side layer to speed up client app development, as illustrated in the diagram below.  

A UI page/view is comprised of a collection of UI modules. The Experience Service interface is driven by the UI module, as opposed to a regular data service driven by a data entity. The experience service can

• Identify between web and native clients

• Select an appropriate set of modules for the client type, taking experimentation into account

• Orchestrate calls to the underlying domain process and entity services

• Select/transform/compute domain service responses into groups of what’s needed for each UI module

• Format/convert/localize the data to the client’s need, with presentation hints when needed

• Attach user behavior tracking metadata to user actions

• Return module data in a standardized format to clients 

Client apps, upon receiving the Experience Service response, render the module data with matching UI components and deal with user interaction. This approach greatly speeds up client app development and, at the same time, increases information and user experience consistency.

An Example of the eBay Checkout Experience Service Interface

Let’s take a look at one of eBay’s first Experience Services -- Checkout Experience Service. In the diagram below, on the left is the Experience Service JSON response. To its right, we have screen dumps of the checkout page for a desktop browser, mobile web, and iOS app. Unlike the domain service interface consisting of data entities -- orders, items, users, etc., the Experience Service response JSON contains a collection of modules made of synthesized/transformed entity data, which provides concise and relevant information within each module. For easy matching between JSON responses and UI modules in the screen dumps, modules are color-coded, e.g: Summary module - pink, Shipping Address module - green, Payment Method module - red, Cart Details module - blue.

Let’s zoom into the Summary Module:

Across the desktop Web, mobile web (mWeb), and iOS apps, the Summary module needs the following info:

• An Order total with label and amount

• A list of line items, each with a label and an amount for Items purchased and shipping cost 

These are directly supported by the JSON module’s “total” attribute and “summaryItemList” attribute. Each element is consistently modeled with

• A “label” attribute with localized text

• A “type” attribute to provide a client hint to present “TOTAL” differently from others

• An “amount” attribute, which has

• “textSpans” holding multiple segments of localized/formatted/styled version of amount

• An optional “value” of raw data for the client to store and process when needed

With this approach, all client apps are receiving consistent and relevant data ready to present to the user, without concern about which underlying domain services to call and what business rules to implement. New line items and business functionalities can be added (e.g. coupons) into the list and delivered to eBay users on all devices with very little or without client app change. For the modules where different clients do need different experiences, the Experience Service can identify the client type and return different modules or data for each.

Conclusion

It has proven in eBay production that a carefully designed Experience Service interface that abstracts most business logic/knowledge away from the clients can provide new functionality to native and web apps without a client code change by altering business logic inside the service. If new UI components need to be built, a client app change is required. However, many new business functionalities can be introduced by composing the previously built client UI components with agreed protocols from the Experience Service. This drastically reduces client app development and release timelines.

Since the introduction of Experience a couple of years ago, most eBay major user-facing apps have developed Experience Services. Some of them are already in production, and most eBay’s major user-facing pages will be served by Experience Service by the end of 2018 on all devices. The Experience Service pattern has proved valuable to eBay’s customers, business, and engineering organization. Teams also have found many areas for Experience Service patterns and processes to evolve, so it can further improve the multi-screen application development.