Dingtalk: How to Design a Cool App

1. The overall introduction of Qunku application

1. What is the cool application of the group scene

Group scene cool application refers to a type of application that can be directly activated in the group and interact with users in the group. It is deeply integrated with the scene in which the group is located and can help the users of the group to complete the business closed loop in the group.

The following figure shows two typical cool application group scenarios: project management group application scenario and work order collaboration group application scenario. Project management progress, task details, group work order information, and the person in charge will all be presented in the group.

2. Product design architecture of Qunku application

A complete group application must include multiple application nodes that can be installed in the session application bar and a group robot, and mainly use interactive cards, half-screen containers and PC sidebars to interact with users.

An excellent group application should focus on solving vertical problems in vertical scenarios, and its own business service capabilities can basically close the loop within the group.

3. Core Competencies of Qunku Apps

The core competence composition of Qunku application is shown in the following figure:
a. Event callback: perceive various life cycle events of cool apps and groups, including cool app activation, deactivation, group dissolution, adding/deleting group members, etc.;

b. Interactive card: The developer page is embedded in the open block to present data and provide user interaction. The functions include message card, sticky card, user interaction, active update, thousands of people, thousands of faces, etc.;

c. Group application entrance: the shortcut entrance of application functions, users can quickly access the function page by clicking, the functions include: multi-terminal customization, multi-mode opening, dynamic parameters, red dot guidance, multi-level menu, etc.;

d. Robot: message receiving and sending channels, with the ability of conversational interaction, functions include sending/receiving messages, withdrawing messages, checking read and unread, etc.;

e. Capability Kit: A series of DingTalk front-end components that can be embedded into the developer's own page, with functions including enabling cool apps, building groups, users sending messages, adding people, etc.;

4. The ability of the group on the client side is open

For various scenarios of application developers, the group has been fully opened on the client side. The basic open capabilities include: session settings, sticky cards, robots, interactive cards, messages, conversation applications, etc., to help developers better serve client.

a. Conversation app bar

The session application bar is the core entry for group applications in the group. The user side can quickly develop various service capabilities of applications deployed in the group through the session entry on the application bar, such as viewing the work order list or creating new tasks.

In this scenario, the session provides the application with the ability to pass parameters, and the application developer can obtain which user clicked which plug-in in which group, so as to better provide targeted services, even if the same entry, different users It will achieve thousands of people and thousands of faces, so that users can get a better experience.
b. Interactive cards

Interactive cards are the main carrier of cool apps in the group. How to design and use the interaction and refresh capabilities of interactive cards is the key to determining the quality of cool apps.

Three core capabilities of interactive cards: dynamic card update, user click interaction, thousands of people and thousands of faces.

Ability 1: Card Dynamic Update

Developers can update interactive card data in real time, and DingTalk can update card content in real time on multiple terminals.
There are two ways to trigger an update of data:
• Click to update: The user clicks the card button to trigger a callback, and the developer returns the latest card data, such as group solitaire;
• Active update: developers call API to actively update card data;

Ability 2: User Click Interaction

"Real-time interaction" capability: Allow users to interact directly in the card, promote communication and interaction, and do not need to enter the secondary page, which can shorten the user's operation path and improve efficiency.

Note: User interaction is processed through http callback to the developer's service. If the service call rt is lower than 1200ms for a long time, the current may be limited.

Ability 3: Thousands of people and thousands of faces

The card data provided by the developer will be used for card layout rendering and data content filling. It is divided into public and private data. With the help of public and private data, the card layout and content can be varied:
• Public data: The default card renders the data preferentially used by each user;
• Private data: Specify private data for some users, and render cards with private data first.

Take the following picture as an example, the "Reject" and "Accept" of the previous card are public data, that is, everyone in the group can see it. When the user clicks Reject or Accept, the second card will display "Rejected" It is private data, which is only visible to the user who clicks.
Another example is a card report, which pushes the sales performance of the day. Some information such as customer data and sales amount cannot be presented to all members in the group. In this scenario, you only need to set private data in the module of the card, and specify which data is limited to. Visible to people, when the card is sent to the group, the members in the group will see different card content
Note: A single card supports private data of up to 500 users, and a single call to create card and update card interfaces supports the transfer of private data of up to 20 users. Therefore, the thousand-person approach is not recommended in very large groups.

c. Swarm robots

Swarm bots are enabled when the app is installed in the swarm. The group robot provides the application with the ability to directly exchange with users in the group, such as pushing progress announcements and task information, and responding to the user's @ information. Robots are the main carrier of interactive card delivery.
Core competencies of robots:

• Receive user messages
The message of the user at the robot is called back to the developer in the form of Http callback;
• Send a message
API can be used to send various content such as interactive cards to the group;
• Query read/unread
Query the read and unread data of sent messages through the message id to help developers improve business operation efficiency and comprehensively understand business operations;
• Withdraw messages
recall sent message by message id;
• Robot management
The robot is installed into the group together with the cool application, and at the same time, the robot is also uninstalled from the group together with the cool application.

The overall link of the robot

The following figure is the overall link diagram of DingTalk robot. All DingTalk robot message links conform to the design paradigm of this key link.
DingTalk robot overall link diagram

In this link, it mainly includes the robot message sending system and the robot message callback system.
• The developer sends the robot message, requests to the open platform gateway, and then automatically sends the message to the client;
• Messages are sent through robot message current limiting, content security inspection, message body format detection, etc.;
• After the client receives the message, it will monitor the client's message, parse/process the message body, construct the data structure, etc., and push it to the developer through the robot message callback system

d. Container Capability

To design a cool application in a group, it is necessary to make full use of the container capability of IM in the terminal, so that the user side can complete all interactions and all services in one interface, without jumping out of the scene, and solving the problem of users jumping back and forth between multiple application entrances The problem is to realize that all interactions are completed in a closed loop within the group.
Open the link in the sidebar on the PC side
Mobile half-screen container open link

Half-screen container example

Take the Dingdang OKR Cool application as an example, put "My OKR" and "Create OKR" as the entry points on the group shortcut bar, so that users in the internal group can directly view OKRs and create OKRs in the group, and at the same time, with the help of blue bars and The red dot prompting ability can also be used to prompt information on the plug-in.

2. Case analysis based on group scenarios

1. Cool App Design Tool: Scenario Swimlane Diagram
Scene swimlane diagram

Scenario swimlane diagrams divide cool app design into three steps:

• Step 1: Clarify the main line of the scene
Describe the corresponding scene in the way of the scene main line, and mark the task node on the scene main line;
• Step 2: Identify functional activity
Label the functional activity of the task node;
• Step 3: Carding high-frequency functions
For high-frequency functions, use card update, callback, private data and other functions to update the progress in the group.

Taking the recruitment scenario "Joining Together" as an example, the business scenario is disassembled as follows:

• Role settings: As a one-time job, DingTalk recommends that role settings be placed in the main application process;
• Resume upload: This is a relatively medium-frequency job, mainly responsible for HR, and you only need to enable the quick entry in the group;
• Resume screening: It can be done using group cards, and the initially screened resumes are sent to the interviewers in the group in the form of cards;
• Interview arrangement: It is a high-frequency job. After the interviewer arranges the interview time, he will inform the relevant personnel of the information. The card needs to be pushed to the group and the schedule will be synchronized to the DingTalk schedule;
• Interview feedback and employment: both belong to high-frequency work. The feedback and employment after the interview need to be informed in the group, which is also pushed to the group in the form of a card, and the progress is updated in real time in the form of a group ceiling;
• Interview review: After the interview, do the interview review and present it in the group.

2. Specific cases

[Case 1] Cool application transformation of customer service system

The original process that highly relied on manual collaboration

a. Before renovation:
• Customer problems are reported and dealt with in one group, information is mixed, and Xiaoer frequently switches between DingTalk and the work order system;
• Customers lack self-service problem solving channels, so Xiao Er needs to keep an eye on group information and work order status;

b. Retrofit steps:
• Aggregate all information into a group where customer staff and customer service staff are in this group, and the robot will respond to customer questions immediately;
• Redeploy the group shortcut bar entry, and put tasks such as workbenches and work orders on the shortcut bar entry, so that customers can self-check information and process tasks without manual connection;
• Redesign the business process, and put information and task processing that are not directly related to the main group into subgroups. For example, after a customer asks a question, the online customer service will create a subgroup and automatically pull the customer and related personnel into the subgroup. deal with problems;

c. After modification:
• A single group, a small group handles faults, a large group synchronizes progress in real time, and no amount of information is chaotic;
• Through process dismantling and grouping, information efficiency has been improved tenfold;

d. Core Values:
• Order building model: change the business model of online services and release productivity;
• Task single group: Effectively solve the situation of information overload and lost tasks, and focus on message management and task follow-up.

【Case 2】Design of emergency response system

a. Business pain points:
• Multiple groups respond, information is scattered, and it is difficult for people related to the faulty link to find a group immediately;
• The emergency coordination is not clear, it is not clear what the SOP is, and who is responsible for what in the group;
• In an emergency, the current progress cannot be obtained in time and relies on climbing stairs;
• There is no record of responses, actions and decisions in the emergency process, which cannot be traced back and relies on climbing stairs;

b. Solutions
• Unified management of fault handling groups, and guide them to the same group for processing through announcements and messages;
• Collaborate on personnel and processes through robots, and identify personnel in the group;
• Process progress synchronously across groups through ceilings and cards;
• Combine chat records and group interaction information to automatically generate processing procedures;


c. Expected value
• Based on DingTalk IM's open capability, open up business systems such as monitoring, operation and maintenance, and scheduling, and build online collaborative solutions to ensure efficient, orderly and transparent emergency response.

3. Summary

1. Applicable scenarios of Qunku application

The Quncool application is suitable for scenarios with multiple people (number of participants), multiple nodes (task complexity), and multitasking (parallel tasks).

2. Cool app category

Cool apps are classified into four categories based on three dimensions: number of participants, task complexity, and amount of parallel tasks:

• Data collection type
Multiple people, single task, single node, such as: check-in, ordering, questionnaire, voting, interest group, daily newspaper, technology sharing, etc.;

• Customer service
Multiple people, multi-tasking, single-node, such as marketing services (Funxiang Sales, Sales Help);

• Single task flow transformation
One person, single task, multiple nodes, such as: work order, GOC alarm, AONE, recruitment, etc.;

• Custom
Multiple people, multiple tasks, and multiple nodes, such as: traveling together (Alibaba Business Travel), OKR (Dingdang OKR), asset management (Gongbei Assets), etc.;

The first three categories are general-purpose types, and Dingding provides a cool application universal template for quick adaptation. For the fourth type of custom type, Dingding provides design tools and design guidelines to speed up the operation of application transformation.


4. Q&A

Q: Do cool apps have templates?
A: The cool app itself does not have a template. Dingding provides a developer template for the interactive cards in the cool app. If it is difficult to develop full code, you can try to use the low-code cool application development that is suitable for you.

Q: Can I embed H5 in a page opened in half-screen?
A: In fact, the half-screen opening is an H5+ browser, which can embed the original business system.

Q: Where can I see cool application cases?
A: There are many cool application cases in the DingTalk Open Platform documentation for your reference.