The next breaking point for the Mini Program? Dingding small program card, deep integration of application and platform

Author: Tang Nuo

20 seconds to understand the mini program card

Case: Happiness bus grabs a seat with one key

If you have used the Happy Bus seat grab function before, you may remember the fear of being connected to vpn and all kinds of jumping back and forth H5.

Comparison of seat grabbing process:

The seat grab process of the previous H5 page	The current seat grab process of the card application
1. Xiaomi searches for "Happy Bus"	1. Xiaomi searches for "Happy Bus"
2. Click on the jump link	2. One-click to grab a seat and finish
3. Connect to VPN
4. Open the booking H5 page to grab a seat

Compared with the previous, one-click reservation, one-key query, one-key cancellation, and the real-time seat information of the shifts, saving two minutes for every student who takes the bus.

How to do

Happiness Bus was originally an H5 application developed by Enterprise Intelligence on DingTalk. This time, based on the card capabilities of the applet, the front-end user interface was quickly transformed into a card form, while the back-end services still reuse the original system.

We can understand it this way:

The previous bus system = back-end service + front-end page (jump to the new full-screen page)
The current bus system = back-end service + front-end card (in and out of Xiaomi conversation)

The development method of this front-end card is as simple as developing a small program component. As long as you can develop a small program, you will develop a card.

An example of a card application code is as follows:

Case: ICBU customer invitation card

ICBU transforms the original customer invitation system into a card application based on the ability of small program cards.

The system will automatically send the customer invitation through the robot. The sales staff will directly operate on the card, select the date of the visit, fill in the visit plan form, and the form of the invitation status after submission will also be directly displayed on the card content.

Through the card application, the user's direct back and forth between communication and business system is reduced.

Speaking from the little red dot

Seeing this, you may already have some application-level understanding of the applet card technology, but returning to the technology itself, we may need to start from the little red point...

The small red dot (Badge), originated from BlackBerry, was carried forward by Apple (the patent belongs to Apple), and has now become the UI specification for iOS, Android and other major system App push notifications.

The design of the little red dot is so successful that I will not discuss the UI aside. I personally think that its greatest significance for users is that it will information on the upper carrier (such as App Icon) that originally required users to enter the APP to see. were standardization revealing , greatly reduced the information acquired path .

There is no lack of similar designs in modern operating systems, and further supports user interaction. Such as iOS, Android and other system widgets, notification center, control center, etc.

Under cloud nail integration will increasingly become the operating system of the enterprise digital platform. In order to shorten the user information acquisition path, we need a set of with immersive experience friendly to developers , and finally Anywhere block-level application solutions.

applet card program can well meet the appeal requirements.

Immersive experience

Compared with traditional applets, mini program cards have the biggest advantage that they can bring an immersive experience.

Traditional applets are applications that hide behind an icon (or sharing link). Users who want to obtain or create effective information based on the applet need to jump out of the current context. This relatively fragmented way of interaction can cause great distress to users in certain scenarios, such as IM. Dingding IM, as Dingding’s core capability, carries most of the communication information related to work.

Imagine that Xiao Wang, a sales classmate, needs to synchronize yesterday's work progress and work schedule with his colleagues in the group every morning, and cooperate with other colleagues to complete business follow-up together. While paying attention to other simultaneous chat information, Xiao Wang needs to query and modify customer information in other applications of the workbench. This kind of continuous switching between the chat window and other applications makes Xiao Wang’s work efficiency very low and may even miss Important information.

Immersive interaction

In order to allow users to directly manipulate the Mini Program card in IM, we have conducted in-depth cooperation with the DingTalk IM team, and deeply integrate the rendering process and data link with the IM module, turning the Mini Program card into a special message type. , Can be sent directly to the message list.

The following figure shows the process of modifying the permissions of the DingDing document card, and the user can directly modify the corresponding document permissions on the card:

And, combined with the characteristics of IM itself, the small and medium program card in IM can also support top operation . The sticking operation is very meaningful for those small program cards that need to interact for a long time, such as location sharing , data big etc.

Real-time data synchronization

Functional UI tells us UI = F(data) , which shows that data plays a decisive role in UI. for example:

The DingTalk group voting card allows us to vote directly in IM. Compared with the interactive experience of jumping a independent "voting" application from IM and then voting, it is undoubtedly a big step forward.

But what if we want to track the voting progress in real time and get the final voting result? For example, the capabilities shown below:

To achieve this capability, the usual practice is for the business side to add a data synchronization mechanism to its business logic, refresh the data and then update the view. However, this data synchronization method is actually very inefficient. As a client, in order to ensure the timeliness of the data, it can only be refreshed regularly through a timer (long connections also have other problems). Imagine that in a group of 100 people, there is a card that needs data synchronization, which means that 100 requests will be sent to the server at the same time. What if there are m cards in n groups at the same time?

The mini program card has a built-in efficient data synchronization mechanism. Developers only need to synchronize the latest card data to the mini program card frame to quickly update all cards with the same ID.

Integration with applets

When the Mini Program Card runs as an independent application, due to its block-level application positioning, it cannot carry overly complex user interactions and business processes. At this point, the applet card can be integrated with the applet capabilities. Click on an action area of the applet card to support a half-screen to evoke a applet with complete capabilities, and provide developers with sufficient ability support while maintaining an immersive experience Its business.

At the same time, it supports access to and changes to the data of the mini program card in the mini program. Similarly, these data changes will be synchronized to all cards with the same ID.

At this time, the applet card can be used as the carrier of the core information and operation of the main applet to quickly reach users and complete the core business process.

"Traditional" apps vs. card apps

"traditional" applications	Card application
The system hidden behind the icon or link	In a block-based way, it is forwarded to the core scenes such as communication, workbench, search, etc.
To view data, you need to jump to the application page for operations, you need to jump to the application page	Immersive interaction, no need to leave the context. The content is revealed on the card in real time, and the data is automatically updated (real-time seat information). The basic interactive closed loop can be completed on the card (for seat grabbing)
Human-system interaction	After being integrated into the communication, the interaction between people is increased

Anywhere running

We hope that when the developer completes the development of the mini program card, he can run it in:

Multi-terminal: iOS, Android, Windows, Mac;
Multiple runtimes: native (IM list, search result page), applet, H5, and even in iOS widgets.

Traditional applets use webview as a rendering container, but it is too heavy to embed a webview for each card directly in IM, and it is difficult to solve the problem of excessive memory usage when multiple cards coexist.

Therefore, based on the same set of DSL, we will package it into different products through different compilers to adapt to different host environments, and ensure the consistency of multi-end rendering through the strong constraints of DSL.

Relying on the current mini program offline package mechanism, we package a variety of products (which can be configured in the future) into the mini program offline package to achieve resource offline.

Before the card is rendered, the card framework will first determine the current environment and select different packaged products for card rendering according to different environments.

Using the card unified DSL can decouple the business code from the "card underlying engine implementation", and the business can be painlessly upgraded when more rendering engines are added in the future.

Based on this solution, Mini Program Card has supported three containers: 1615986352eba0 Webview , Native , and Mini Program

Consistent development experience

Use applet DSL

Developers use applet DSL as a card to unify DSL to develop applet card .

When we determine how developers should develop block-level applications, we feel that they must meet the following three conditions:

Widely accepted and used by developers
Sufficiently standardized
Open-minded

Widely accepted and used

Being widely accepted and used means that its ecology must have a considerable scale, and the scale effect will bring about cost reduction. The cost includes two aspects:

The technical cost that the developer itself needs to master and the various technical dividends that the ecosystem brings to the developer (multi-terminal framework, UI library, etc.);
The prosperous mini-program ecology saves talent costs for enterprises.

Since the launch of WeChat Mini Programs in 2016, Mini Programs have quickly become the most popular open application form on all platforms due to their lower development costs, out-of-the-box development model and better performance than traditional web applications. . In 2018, the number of small program developers has million at the level of . The rapid maturity of the mini program ecosystem and the admission of players with a large number of registered users such as Alipay, Taobao, Dingding, etc. will inevitably accelerate the popularization of mini programs and attract more high-quality developers.

Standardized DSL

A sufficiently standardized DSL means stability.

In September 2019, Alibaba combined its own mini program practice and associated companies to formulate and publish the "Mini Program Standardization White Paper" at W3C to promote the development of unified mini program standards. Currently, the MiniApps Ecosystem Community Group has been established to incubate international standards for small programs with companies such as Google, Huawei, Xiaomi, and Facebook.

It is in the standard that defines the card-this kind of block-level small program application form.

Chapter 2.1.4:

In addition to being presented in the form of an MiniApp page, MiniApp can also be displayed in the form of information fragment, that is, a MiniApp widget. In this form, developers can put their service and/or content to various host scenarios, called host environment, such as assistants, search page, etc.. This feature connects services of the MiniApp with the scenario, providing users with more convenience.

Open-minded

Block-level application is an independent application form, and openness is its natural appeal. But with the increasing number of small program developers, the level of developers will inevitably be uneven .

The applet itself dual-thread architecture + unified runtime + offline package mechanism can ensure that its performance is always at a high level and improve the bottom line of application quality.

Application Type	Coding flexibility	performance	Platform management and control capabilities
H5	high	The variance is large, and the requirements for developers are high. Average, medium.	Weak, control url and back-end interface
Applets	Relatively weak	The variance is small, and the average level is significantly higher than that of H5.	Strong, can be controlled at the code level

And because we have complete control over the small program architecture, this means that we can continue to iteratively upgrade it, and these will be transparent to developers, and developers will continue to benefit from the upgrade of the framework itself.

Mini Program Card will be consistent with the Mini Program in terms of framework design and platform management and control strategy.

IDE integration

In order to lower the threshold for card development, we have added a small program card application in the IDE. Developers can create, develop, test, preview, and upload the (currently in the proprietary nail workbench project). Landing in the middle).

At the same time, we card Anywhere run and card encoding flexibility were trade-offs.

As a block-level application, Mini Program Card determines that the interaction and UI in its business scenarios will not be too complicated (scenarios such as charts can be drawn using card canvas), so we simplified the Mini Program Card DSL. Strictly speaking, it is a subset of the Mini Program DSL. At the same time, in order to better adapt to multi-end and multi-scene, we use class tailwindcss technology to realize card style development, thereby realizing strong constraints on styles.

After simplifying the applet DSL and adding tailwindcss (subset), tools are inevitably needed to and precompile to facilitate relevant tips to developers during the development phase. Based on this, we provide the official IDE plug-in for the card, which is responsible for verifying the DSL capability and providing necessary error prompts during the card issuance process.

When a developer creates a small program card application in the IDE, the IDE will automatically create a directly runnable initialization code for it, and at the same time will automatically install the official IDE plug-in . The initialization code includes a demo card and a simple card data mock scheme, which allows developers to quickly get started with the first card development.

Low code build

For cards dedicated to IM, the Dingding team has now combined Dingding's scene group business to officially provide card building services on the Dingding open platform. For details, please see: Create Message Template-DingTalk Open Platform.

In building the platform, DingTalk combined its own practice of mini program cards, and has deposited a series of general templates for developers to use directly, aiming to help developers develop and use mini program cards at the lowest possible cost.

Evolution route

As a brand-new application form and technical solution, Mini Program Card still has many imperfections. After that, we will continue to iterate and optimize to improve card performance and productization capabilities.

Full platform support

At present, the mini program card can only be run in scenes such as IM, search, and workbench in the DingTalk client. The host environment supports native, H5, and mini programs. For larger application scenarios: the external web does not support it.

There is not much difference between the inside and outside of the card's H5 runtime. The problem lies in the resource link and the data link. It involves authentication, offline resource loading, container protocol webization, data security and other issues, but these issues are not completely unsolvable. After that, we will gradually solve the link problem and maximize the value of Card Anywhere.

Basic ability upgrade

At the runtime level, the applet card will continue to expand on the basis of existing components, introducing basic components such as map , video , audio, canvas etc., and gradually complete the alignment with the standard components of the applet.

On JS runtime support, the card will gradually access the custom component mode that meets the applet standard to improve card development efficiency.

Increased production efficiency

At present, the fullcode mode of small program cards is mainly for developers of one party in CLI mode. The CLI mode is flexible enough, but when it is open to the outside world, it is not suitable for all external developers.

Therefore, in the future, we will continue to optimize and migrate the IDE integrated development model that has been implemented on proprietary nails to standard nails. At the same time, we will establish a relatively complete card development link from development to online on standard nails to provide developers with An out-of-the-box card development environment.

Follow us, 3 mobile technology practices & dry goods for you to think about every week!