Author’s brief introduction

New light for

Qunar front-end technology director

I joined Qunar in June 2014 and now focus on qunar wine marketing business and mini programs. Technically, it focuses on the construction of component-based platform, practices the concept of low code with the architecture thinking of micro front end, and strives to improve reuse and efficiency to a higher level.

1. Business background

Qunar has a large user base in the tourism industry. In addition to daily ticket purchase, we also want to make more contact with users to let them feel the temperature of the platform. This contact can be divided into three parts:

  1. Daily promotion, such as the purchase of air tickets and hotels, can be lucky draw, launch bargaining to get cash and other activities, to increase the stickiness of users and actually bring benefits to users.
  2. The guide of new customers, app terminal and small program have special areas for new people, there are various activities and tasks to guide users to purchase tickets and convert.
  3. During holidays and festivals, the platform will launch strong promotional activities to further improve user conversion and brand influence.

For the above three main scenarios, Qunar has corresponding product operation teams for each business line. Then the problem comes: pages are needed to reach users. How to produce such high-frequency and large-scale pages?

2. Solutions

If according to the conventional project implementation process, the cost and cycle can not meet the demand, we first think about the plan, and then look at the implementation problem:

  1. Large number of pages – reuse ideas, do not have to redevelop every page
  2. High frequency of change – Configuration is supported without having to republish every change

The first problem is that if we want to reuse ideas, we should abstract different scenes of marketing, and achieve standardized unification of design with UI students, so as to achieve the unification of page style.

The second problem is that if you want to support configuration, you need to design the changeable points of the page components in advance, so that you can make these configuration types and integrate them into the system.

So at this point, there’s something that definitely needs a technician to land:

  1. Designing a system allows developers to develop components and then integrate them into the system, giving operators the flexibility to assemble the pages they want.
  2. After the page goes online, if there are modification points, allow the operation personnel to modify the component configuration items in the system, and preview, the effect is good, then push online.

3. System design

3.1 Page Management System

To make the page configuration live, we first need to design a page management system, allowing components to drag and drop, edit, to complete the page assembly and live.

This System, which we’ll call CMS=Component Management System, is a little different from the industry’s “CMS” content Management System, and we’re going to use CMS to simplify things.

Components are the most valuable material of CMS system, and our vision and practical actions are based on the following concepts:

Pages are not developed, they are assembled, and operations have the flexibility to assemble them from component libraries, enabling operations with each iteration of the component library.

3.2 Developing Component Access

Components need to be iterated. The life cycle of a component is: development -> test -> deployment -> integration – operation, and the middle inevitably needs to be modified, so the whole link needs to be carefully designed.

Problems faced:

If the business is numerous and the number of components is large, it is bound to become more and more bloated if they are all iterated in one project. Therefore, we designed a distributed project development scheme, which means that developers can build a Git project by themselves and integrate it into the main system.

Developed components can be released and integrated into the main system:

After the integration of components, we can integrate all required components in the marketing classification management interface:

In this way, operations students can see the components in the component list, drag and drop the page, edit and go online.

3.3 Page rendering system

There are three main scenarios for page rendering:

  1. In-app rendering, Hybrid supports offline package
  2. H5 browser side, support server side rendering
  3. Small application side rendering, natural offline package mode

In this way, we achieved a good rendering effect at each end, and there were some problems to be solved at each step:

  1. For in-app rendering, when we package resources, we should consider that the operation modification configuration takes effect in real time, so the page bearer system of node side should support such delayed request configuration. And when the network is down, automatically use the last configuration, degraded rendering.
  2. H5 browser side, if the high performance requirements of the scene, you can synchronize the template to the Node side, so that the final HTML calculation will be returned to the browser, directly render.
  3. Small program side, code packaged out to render in native mode, natural offline package mode, also do when offline, automatically use the last configuration, degraded rendering.

4. Evolution

4.1 Multi-terminal rendering

Therefore, we need to explore a kind of program based on a set of source code, in the micro channel small program side can also according to the original way to render the scheme, and investigated the following schemes:

Comprehensive cost, engineering, component status, the final use of self-development, CMS components in a native way to run in the small program end, the basic idea is to develop a container at both ends, this container will be in the run of the component call adaptation to the small program end.

After all, the two ends are completely different. There are many details in the middle page, which have been solved now:

About performance:

The small program side update the page is setData, so for complex pages, setData will lead to render lag, refer to the official loss of eu:

Developers.weixin.qq.com/miniprogram…

Therefore, CMS adopts the solution of using Component of wechat, so that partial refresh can be achieved. Even if there are many page components, the performance can be optimized and controlled.

Automatic adaptation of CMS components to Component mainly involves a Component dynamic packaging problem. For details, please refer to the official document:

Developers.weixin.qq.com/miniprogram…

Its life cycle is more complex and special, so it needs to grind these life cycles in the CMS small program container side, setState to setData automatic conversion, these two problems solved, basically adapted.

4.2 Risk Control

There are risks in human-operated scenarios, especially for pages that are already online. Every configuration of component properties and adjustment of component skins may cause failures. So from the system dimension, we did the following:

  1. Components follow version management: that is, development adds a new version to an existing web page, and operations will not use the latest version unless they actively click on the update, thus reducing the risk of the page dropping.
  2. Component properties edit validation: For a component, some properties are mandatory and some properties must conform to a certain format. If there is no constraint, the page may be displayed. Therefore, component properties allow you to configure validation rules to avoid this problem to some extent.
  3. Page configuration draft box: every modification is the default into the draft box, as long as you do not click on the line, it is impossible to affect the online page.
  4. The online page needs to be reviewed: for key pages, every time they click online, they need to be reviewed. Reviewers can test and verify the diFF changes in the system before they are finally online.
  5. Perfect system operation and maintenance: the rendering rate of page components, errors in JS code execution, and loading errors of pictures and other resources; unified access to real-time monitoring, to ensure active detection of online problems as far as possible.

4.3 Process Precipitation

When the system system is set up, it needs to rely on the standardization of the process if it wants to play the real reuse value. If there is no unified closure of requirements, it can lead to repeated development of components. Therefore, the following four parties need to make a stipulation:

  1. Operation: Basically, all requirements come from operation. When operation students have requirements, they will directly report them to design if they are simple, and to products if they are complex. Of course, sometimes they will directly seek technology.
  2. Design: Unified review of presentation and interaction requirements, initial decision whether to reuse existing components.
  3. Product: Unified review of functional and logical requirements, initial decision whether to reuse existing components.
  4. Technology: Based on the demands and suggestions of the three parties, as well as the perspective of component code design, give further suggestions, whether to reuse, and the transformation degree of reuse; If there is a dispute among the three parties, the decision will be made based on the specific situation.

With the flow, it covers most scenarios, but in practice there will be bypasses and jumps, so the final check on the technical side is very important. The design, product and technology parties receive the requirements, and the other two parties confirm the timely upgrade of disputes, which is also very important.

5. Summary of effects

5.1 From the perspective of cost

Qunar previously had three sets of marketing front management systems. With the birth of the machine wine business group, THE CMS has gone through the first and second iterations and has been able to integrate the marketing needs of air tickets, hotels and the market and unify the design, development and operation processes.

The intuitive effect is that there are fewer people to maintain the system, the design students focus on the design of component skin, and their energy is released. The operation students have a large number of reusable components, and the frequency of activities is higher.

In addition to daily marketing online, launched after fusion: double town shop, 999 seconds to kill, 11 to promote three key projects, and draw, seconds kill, vouchers, shelf components in these three got reuse, especially the air ticket, hotel, market three 11 promoting activities of the business, 0 development can be achieved, but direct online.

5.2 From the perspective of experience

Experience consistency: The UI team behind the previous three systems is also different, so the skin of the same components is also different. With the unity of the UI team, the page display effect is more consistent.

Page availability: In the same system, CMS has made degraded rendering processing in app offline package and small program offline package scenes, as well as optimization such as automatic retry of picture loading, to improve the weak network environment experience.

5.3 From the Perspective of Bearer Services

The system is currently carrying the air ticket, hotel, market bargaining business, every day for the platform to pull a large number of new customers, win free orders, phone charge, lottery after payment and other high-frequency business, as well as the daily airline operation activities of ticket, hotel, entertainment daily operation activities, can operate independent configuration online.

6. Follow-up planning

After the first and second iterations of CMS, component coverage, system concurrency and risk control have been guaranteed. But in the end, for this to be successful, the following points must be met:

  1. Development costs are greatly reduced
  2. UI design costs are significantly reduced
  3. Operating costs are greatly reduced

In the case of 1 and 2, because of reuse, the cost goes down; However, due to the complex configuration of some components (such as seconds, shelves, vouchers, etc.), operation students still find it difficult to use them, so we set an emotional goal:

Improved operation smoothness

If the operation configuration is smooth, it means less time, and naturally this problem will not exist. To improve the operation smoothness, we plan to not only optimize component properties, but also:

  1. Component add, delete, and modify basic operation smoothness
  2. Component property simplification, Chinese, manual synchronization
  3. Be able to quickly find the components you want and give full play to your imagination

Serve marketing, the only constant is change; For marketing, a long way to go, the marketing scene is changeable and complex, we must always keep sensitive, treading on thin ice, optimization of the system, to be able to better serve the user, enabling marketing.