Getting Marketing Done: User Interaction Bus

A good activity not only needs to have attractive gameplay, but also needs to give users a complete experience, handle interactive feedback well, and enhance the user's overall sense of interaction. So how can you achieve this goal? Maybe you can try to establish a "user interaction bus". Let's take a look at the author's analysis on how to understand and establish it.

1. Introduction

We have previously talked about the decoupling and connection between gameplays, which has basically solved 50% of the functional problems. We can basically build an activity completely, but there is still a gap from a good activity, mainly in terms of user experience and activity effect. This article will talk about how to handle the interaction problems of users participating in activities from the back-end perspective.

When designing the system architecture or abstracting the functions, the system capabilities were split for reasons such as scalability. Each gameplay can exist independently and can be dynamically linked. The system architecture design is excellent, but the activities built in this way will damage the user experience if the interactive feedback is not handled as a whole. To a certain extent, users still feel that it is a puzzle-like activity. Each gameplay handles its own interaction, the linkage is not strongly perceived by users, and there may be conflicts in the interaction between gameplays. The integrity is not strong enough.

The activities produced by our entire system should be complete rather than fragmented. The cost of each customization process is too high, and giving up on gameplay choreography would mean going back to square one. So in order to provide a better user interaction experience and reduce the cost of developing activity interaction logic, we need a centralized "bus" to be responsible for the overall user interaction.

2. Solution

1. Problem Analysis

The responsibility of the interaction bus is to "centrally process event feedback during user interaction and be responsible for the overall sense of interaction". Events are classified according to their source:

There are two major categories: established activity interaction rules (game play itself, between gameplay) and operational operations.

1. According to the form of expression, it can be divided into: toast, pop-up window, in-activity notification, private message, push, etc.
2. According to the timing, it can basically be divided into real-time reach (passive acceptance) and triggered during interaction (active trigger).

In essence, these actions are all "feedback in interaction" between the activity and the users. We only need to grasp the essence of the touch, and then analyze the scene, form, and timing of the "feedback", and then summarize and abstract it.

2. Positioning determination

The interaction bus is responsible for the feedback of an activity during the user interaction process, so it must be a "slice"-like existence. All interaction feedback occurs here. In other words, the gameplay and business event bus provide integrated function presentation, and the interaction bus provides unified user interaction feedback. These two parts provide users with a good user experience around the context of user participation.

3. Abstract

First determine the context: We are dealing with interactive feedback issues during user participation in the activity field. The core object of processing is feedback . The main problems to be solved are inconsistent feedback during the interaction process, too much or too little feedback, inability to centrally manage, and relatively high maintenance costs.

For operators, feedback is a kind of activity interaction rule that needs to be configured, managed, and triggered. For users, feedback can be actively pushed or pulled when entering an activity. These feedbacks have their own specific content, different forms of expression, and receiving users. There are priorities or mutually exclusive logics between feedbacks, etc. In general, feedback can be roughly abstracted as follows:

Therefore, you only need to implement a service that can generate and maintain feedback and uniformly handle the relationship between feedbacks.

4. Run View

Let's first take a look at the overall runtime view, and then explain in detail how to achieve unified processing of interactive feedback.

First, the event source of the interactive bus can be an asynchronous event, such as task completion, successful assistance, etc., or a user click or interface opening, or a centralized contact recall from the operation, etc. After receiving the event, we need to create interactive feedback for the event itself and event-related interactive feedback, such as a toast prompt for task completion, and a refresh action or special effect for adding a chance to win a prize after the task is completed.

After getting the corresponding feedback, it is poured into the existing buffer, or directly goes through the subsequent process, and then the event is standardized according to the rules. If there is a buffer, it is merged with other current events or discarded, and integrated with the current front-end interaction sequence to determine the final sequence of the current buffer waiting to be consumed.

The final consumable sequence can be actively pushed to the user through the server long link, or brought to the user when the user interacts.

5. Consumption Rules

Maintaining the consumption rules of the entire bus is the most complex part of the entire implementation. Usually, the consumption methods of the consumption queue can be divided into two types: pull and push. The usual logic of pull is to obtain the feedback behavior of the user's interaction between the last interaction and the current interaction, while push is usually a timed and quantitative consumption logic, and the consumption of feedback must support multi-dimensional processing, such as only consuming those related to a certain gameplay, and only consuming those related to this interaction.

Therefore, feedback has a heavy business processing feature. The implementation of this part can be very complex or very simple, depending on the business scenario. Generally speaking, the activity dimension only needs to slightly package the rules, and it will not expand to be very complex.

Let's take a relatively common example to give you a simple feel:

• Consumption mode <pull, push <timing, quantity>, pull & push <timing, quantity>;
• Feature set <merged features, priorities, discard flags, feedback tags>.

Many simple activities do not have strong feedback requirements. At this time, we only need a simple set of default timing rules or no special rules.

The rule design practice in this part is strongly related to the business scenario. It is enough for us to ensure that the rules can be flexibly plugged in and out. If you want to communicate, we can talk in detail separately.

3. Final Thoughts

This article will stop here for now. There are many technical details involved that are not discussed in detail, such as the definition of DSL, the way text is generated, whether the storage is redis or mysql, whether the SDK provides services, or an RPC is used to provide external services, or the buffer counting mechanism, push mechanism, performance and data consistency guarantee, etc., which can be determined according to the company's technology selection and business scenarios. If you have any related questions, you can chat with me. The ideas described in this article can actually be used not only in activity scenarios, but also in some notification systems or contact systems.