After more than two years of iteration, the Odeon big data platform has been quite rich in the capacity construction of the bottom layer. In recent half a year, we have also invested a lot of energy in data visualization. At present, the self-service BI product has been successfully launched and has been running stably for a period of time. Today, WE will share some of our experience in data visualization.

Today’s share focuses on some of the work of the visual layout module, a canvas that holds visual diagrams and is one of the most important means users use to organize their business logic. First try out the online demo or see the following renderings:

Figure 1: Visual layout module renderings

Why develop visual layout components?

In fact, no matter in data visualization, or in some self-publishing operating platforms, self-service layout has always been a difficult problem to skip. This question also plagued us at the beginning of the project. Should we develop several sets of preset templates for users to choose from, or a set of layout modules that users can drag and drop configurations from?

The former is very simple to implement, and it is easy to design beautifully, but it lacks a lot of flexibility and is easy to be the same. The latter users have a high degree of freedom in use and can drag out an interface more in line with their expectations. However, the development cost is relatively high, and it is difficult to achieve stability, ease of use and high accessibility.

Considering all of these issues, we were not satisfied with the solutions we developed, and decided to implement a component that could assist users with drag-and-drop layouts.

How did we do it?

After design, we have combed the interaction model and designed a two-layer structure of cards and charts. On this basis, the overall design of the data model, combined with the above renderings and online demo can be more easily understand the following division.

The first is a locally scoped singleton Map class that describes the entire Dashboard layout, as well as other data stores.

Next is the Widget class, which defines the card information, including the card’s size, location, and more detailed card title, card type, footnote, chart ID, and so on.

Finally, there is the Chart class, which defines Chart information. In order to separate the layout from the chart model, the chart information is placed less, only the necessary id and other fields are stored, and the chart itself is implemented by external slot slots.

Figure 2: Data model

Third, how to deal with interaction?

With the data model built, it’s time to start designing drag and drop interactions.

For the sake of responsiveness and to reduce the randomness of user operation, we abandoned pixel units in layout design, but designed a virtual 12 grid segmentation for node size, strictly referring to this grid layout during initialization, scaling and movement.

In order to ensure a smooth drag and drop experience for users and keep the layout neat, we designed the card redrawing process based on the automatic card adjustment logic, which will be described in detail later.

In order to provide better drag and drop experience, we designed additional virtual cards to assist users in layout. Users can preview the position and size of the cards after releasing the mouse at any time. The effect is shown in the shadow in the picture below.

Figure 3: Drag and drop preview renderings

Four, what are the difficulties?

With the above data model design, in fact, most of the difficulties have been solved. The difficulties are mainly reflected in the processing of ease of use in the process of auxiliary layout, which can be summarized as follows.

1. How to deal with collision detection

Actually simple collision detection is very easy to solve, after all, all the CARDS just two-dimensional rectangular, it is not difficult, difficult is after collision was card need a way to make contact, we need to find all the collision to the card, and all subsequent affected by this card card, this is a difficult point.

Figure 4: Collision detection layout redrawing process

2. How to achieve the effect of automatic top suction

In the process of designing the layout, the user may drag the card to the ground, and in the process of collision detection mentioned above, the adjacent cards will be affected. The initial interaction found that the drag-and-drop process took a long time to rearrange the layout, so in order to keep the layout tight, there had to be a way to pull all the suspended cards up and down in order.

Figure 5: Automatic ceiling layout redrawing process

Five, how to deal with these two problems?

The two difficulties mentioned above exist in the drag and drop interactions of move and zoom, and are logically consistent. Therefore, in the drag and drop layout process, we abstract out a set of redraw logic, which is sorted in the following order:

  • 1. Collision detection to find out the cards that overlap with the current card in the process of dragging, which may be contacted by multiple cards;
  • 2. Circle the scope of influence, as shown on the left side of Figure 4, recursively find all cards affected by the collision and remove the reprocessing;
  • 3. Temporarily give way, as shown on the right side of Figure 4. All affected cards are shifted downward with the same amplitude to accommodate the dragged cards;
  • 4. Automatic top suction, as shown in Part 5 of Figure 5, requires automatic processing of all cards. The logic is that if there is available space above the card, it will be automatically attached.

Because drag and drop requires a live preview, the above four-step redraw logic is triggered frequently. To avoid repeated contamination of the real position data during layout, we introduced a previewOffset field for the card position to store the vertical offset of the preview effect.

Some students may ask a question: this is the business redraw logic, such a high density of modified data will not be poor performance?

In fact, this problem is solved thanks to the data model design of Widget class. During a series of processing processes, from collision detection to automatic top drawing, position objects are frequently calculated and modified only in relative units, while screenPosition objects in absolute units are used in interface layout. Data and presentation are separated, and the update of screenPosition is triggered only after a redrawing process is completed. In this way, the update pace of the interface is more controllable, the interface is more stable, and the problem of flickering card positions in the vision is avoided.

According to this redrawing logic, the redundant redrawing overhead of DOM layer is avoided, the overall performance is improved, the usability of interface layout is greatly improved, and the operation experience is more stable and smooth.

This article mainly develops from the visual layout module interaction logic design, does not involve the specific code implementation, as Odeon big data platform in the visual layout module some ideas, I believe that through this article you have a preliminary understanding.

If you are interested in the implementation details of collision detection, yield handling, top suction effect and auxiliary layout mentioned in this article, please discuss them in private. If possible, I will write another article to discuss them in detail.

A link to the

  • Article Source:Bh-lay.com/blog/1663a2…
  • Online demo:Bh – lay. Dead simple. IO/demos/layou…
  • Module source: [github.com/bh-lay/demo…]