I. Background Overview
Referring to the consistency of brand recognition in the process of internationalization of brands such as Apple, Booking and AirBnB, Ctrip and Trip (hereinafter referred to as "C&T") have tended to unify the brand effect of different countries and different customer groups.
There are also duplicate development workloads caused by similar C&T requirements in the overall R&D link, the service link is not completely abstracted and unified, and the front-end link has a low reuse rate and lacks dynamic capabilities.
There is a situation of functional misalignment among multiple terminals, resulting in inconsistent user experience, and the combination of C&T scenarios further exacerbates the problems of low reuse rate of functional modules and low utilization of R&D resources.
To sum up the above three points, the problem of C&T consistency and multi-terminal integration is waiting for the technology to give an answer.
2. Research and analysis
In the analysis stage, we explore the technical feasibility from two aspects: brand consistency and multi-terminal consistency.
2.1 Brand Consistency
The source of brand consistency lies in consistent design specifications and consistent functionality.
Consistent design specifications:
- Fine-grained design specifications are constrained on visual elements to form one or more sets of design specifications that are suitable for different business scenarios.
- The UED team and the front-end R&D team realize the presentation and dynamic transformation of the brand language through the design specifications and the corresponding tool library.
Consistent Functional Implementation:
- Unify user interfaces and interaction processes to ensure that the same features of different brands are aligned in terms of user experience.
- The core process and common functions are designed for functional consistency, and the interaction experience is optimized for different terminals.
Without addressing brand consistency, UED, product, and R&D all require double or more effort to serve users on both platforms.
2.2 Multi-terminal consistency
C&T and multi-terminal are almost always relatively independent on the link.
The current situation of multi-terminal inconsistency is analyzed from the perspective of R&D in three aspects:
1) Multiple terminals belong to different R&D teams, and the allocation of R&D resources tends to be different with the number of orders. In this context, two types of questions arise:
- There will be a "generation gap" in the number and frequency of demand iterations between multiple terminals, that is, the difference and inconsistency of functions, and the absolute length of this "generation difference" may be more than 6 months.
- The technical vision of R&D teams at different terminals is limited, which reduces the circulation of front-end R&D resources.
2) The "generation difference" between terminals requires more compatibility with the services at the Controller layer, and with the increase of compatible codes, the Controller is split into a one-to-one architecture form according to different terminal requirements, and the common code part is also decreasing, which further aggravates the multi-terminal inconsistency.
3) The Controller layer is responsible for the development of the server, and in the scenario of multiple Controller service instances, due to the "generation gap", the redundancy of the code (Controller layer) and the laborious degree of abstraction logic make the R&D resources of the server become a resource bottleneck. At the same time, the dividing line between front-end and back-end code also lacks constraints, which aggravates the differentiation and inconsistency of the entire link between multiple terminals.
3. Solution
3.1 Brand Consistency
3.1.1 The design specifications are consistent
The design style of UED belongs to two different design systems, TDS (Trip Design System) and CDS (Ctrip Design System), and there are differences in the use of many design elements.
In the context of gradually achieving brand consistency, the two different design systems need to complete some "mutual recognition" compromises.
Our approach:
1) The design system is built by the design team, and the design team agrees on a collection of common design principles under the guidance of the brand theme and design concept, such as the use of color, the classification of font size, etc. Agreed-upon design principles can be used to define the state of the same element in two different design styles through Design Tokens.
2) Since the Design Token in the Design System is a design constraint on element-level granularity, and the function page is composed of countless elements, the Design Token can be configured to achieve flexibility, and also establish a contract between UED and front-end R&D.
3) A set of fine-grained design specification constraints is constructed through the Design System, which can adapt to the current design status of Ctrip and Trip, and finally support the final goal of brand consistency through the Design System at low cost and flexibility.
3.1.2 Consistent functionality
In the vast majority of the current situation, the regional customer groups targeted by different brands determine the differences in design language at the view level, and these differences do not lead to differences in the implementation of business functions, such as the "pay for order" function, which has a clear and unique understanding among different regional customer groups.
However, from the perspective of different terminals, there are some differences in user interaction for the same function implementation, such as the presentation of detailed information on the App and H5 terminals.
- The App side will be more inclined to use the display form of masked layer or newly opened interface, because it can be closed by swiping the screen left and right with gestures, giving users a sense of smoothness of one-handed interaction;
- The H5 end is carried by the mobile browser App, which is used as a container, which will evoke the browser's action of reverting the web page under the gesture of swiping the screen left and right, which will then affect the interactive purpose. Therefore, the H5 side will use more of a floating layer to display it, and reduce user misoperation by clicking on the blank area of the screen to close.
Based on the above analysis, we give a suggested solution:
1) Organize and abstract the functional model and view model on the service side, sink the business function logic in the Controller layer to the Integrated Service layer and the Micro Service layer, and realize the unification and closure of the function implementation at the technical level.
2) The view model is transferred to the BFF layer to complete abstraction and differentiated customization, so that multi-terminal rendering can share a set of BFF services.
3) The rendering of multiple terminals is carried by the front-end business component library, which is used to smooth out the differences in the interaction of each terminal, and the view model serves as a contract connecting the BFF service and the front-end rendering.
3.2 Multi-terminal consistency
After analyzing the current situation of multi-terminal inconsistency, if the controller service layer can support multi-terminal reuse, that is, the BFF layer solution mentioned in the chapter "Function Consistency", the problem of server R&D resource bottleneck can be effectively solved.
At the same time, since the BFF layer supports multiple terminals, if the ability of front-end development resources is expanded to the BFF layer, it can not only further release the pressure on server-side R&D resources, but also reduce the communication cost of front-end and back-end R&D resources.
With the advancement of this working mode, the problem of "generation gap" will eventually be solved, and the energy efficiency of R&D resources will also be greatly improved.
3.2.1 BFF architecture design
In the BFF model, different front-end applications (such as web and mobile) share a set of business logic and view models, which can be deployed independently. The benefit of this is that while different front-ends may have different requirements and features, they can leverage the same service to work with the view model, while also allowing for the necessary customization based on the characteristics of their respective platforms. This architectural pattern not only ensures the consistency of multi-terminal applications, but also retains flexibility and scalability.
In terms of architecture design, it is necessary to start from three layers: engine, integration service, and BFF service, which represent the following:
- Engine: Responsible for the production of the underlying data, the holding and processing layer of different business domain models
- Integration service: responsible for smoothing out the differences of C&T data, the aggregation layer of different business domain models
- BFF service: responsible for maintaining the relationship between the business domain model and the view model, and the support layer of multi-terminal and dynamic capabilities
3.2.2 Dynamic capability
In the architecture design of the above figure, it can be found that there is a Service Driven Layer at the BFF layer, which is used to support the dynamic capacity building of the front-end. We will fully elaborate on the idea of implementation from several aspects.
Since the BFF layer is used to process the view model in a unified manner, there are still personalized differences in different business scenarios, and these differences are solved through the Service Driven Layer and the front-end component library.
Taking the actual results as an example, there is nearly 70~80% consistency between the hotel card in the hotel list page and the hotel card in the hotel marketing page, how will the personalized part be solved?
The main process of selling
Marketing process
In terms of component library, we disassemble the page into the structure combination of the module set, the module into the structure combination of the component set, and the component structure into the structure combination of the element set, so that the disassembly link can refine the structure of multiple dimensions, and these structures will help us to implement dynamic capabilities more flexibly and regularly at compile time and runtime.
The processing of the style part uses a similar idea to generate (Style), and then connects with the UED team's Design System to realize the full-link specification and dynamic ability from visual design to product realization.
Finally, through the Service Driven Layer, the BFF layer will deliver two optional contents in addition to the ViewModel data required by the module:
- 页面与组件结构（Page/Component Structure）
- 动态样式（Component Style）
Through this combination, front-end pages can be built and rendered according to the same concept in different business scenarios, whether static coding or dynamic delivery, and these capabilities will greatly improve the energy efficiency of R&D resources.
Fourth, the way of landing
Let's analyze the landing process step by step:
1) The left half of the figure is the development stage, and the front-end part is landed
- UED与前端通过Design System的Design Token作为契约进行交流
- The style compatibility of differentiated requirements needs to be completed through Style Config, which needs to rely on Design Token on the one hand, and the construction and support of component libraries on the other hand
- The structure combination of the same and differentiated requirements needs to be completed through the Structure Config
2) The right half of the figure is the online stage, and the landing method of the service part
- BFF Service完成多端一致的能力落地,将Intergrated 和 Micro Service中的业务模型转换成视图模型
- Style Config 与Structure Config 分别实现样式与结构的动态化能力
- Aggregated through the Server Driven Layer, through the runtime drop of the terminal code
Fifth, the results of the demonstration
From 0 to 1, BFF supports C&T dual platform, multi-terminal and dynamic, demonstrates technical feasibility project by project, builds the required technical support capabilities, and at the same time clears historical technical debts to accelerate R&D efficiency.
C&T Web 酒店详情页
At present, this architecture design is supported on the hotel details page on the C&T website. A set of BFF function interfaces is shared to realize modular function interfaces. In the process, the double-end logic sinking of the front-end and the server-side was completed, which improved the R&D efficiency and expanded the front-end function.
The scope of the transformation involves a total of 5 terminals of Ctrip H5, Mini Program, Trip Online, and Trip H5, realizing the transformation of 17 functional module interfaces, and the multi-terminal functional modules are closed and landed in the BFF layer to achieve multi-terminal consistency and reuse, and improve R&D energy efficiency. At the same time, the front-end size of multiple terminals is reduced by 27~39%.
In the process of transformation, it is transformed from a business domain model to an abstract view model, and at the same time, it has the personalized modules and functions that may exist in different terminals, which verifies that the architecture design has the ability of front-end dynamics at the same time.
C&T Multi-Terminal Hotel Selling Point Page
Using BFF services combined with Ctrip's self-developed one-code multi-terminal framework xTaro, a total of 7 terminal hotel selling point pages of C&T were completed.
The project further demonstrated the feasibility of the solution, greatly optimized the energy efficiency of R&D resources and the overall workflow, and completed the implementation of one-code and multi-terminal capabilities through the component library in multi-terminal consistent scenarios.
epilogue
In the process of landing, such a full-link solution needs to cross the river by feeling the stones, boldly envisaging and carefully demonstrating, always maintaining communication with relevant teams, and moving forward for a common goal.
We hope to productize the technical achievements of each link in this solution and provide them to more R&D teams with the same needs.
Author: Jia Lu, R&D Director of Ctrip, focusing on the construction and innovation of the core value of the big front-end.
Source-WeChat public account: Ctrip Technology
Source: https://mp.weixin.qq.com/s/2xfd-KczeVF_ZhKNwZu-KQ?poc_token=HDlEK2ajsO_AalzyfmRuoDWcNWuf0-iczmyG4yNq