Since the beginning of last year, we have been working internally on two editors:

  • 3d editor supports building 3D scenes.
  • Topology/Large Screen Editor Supports setting up large screen/topology/configuration scenarios.

The main goal of the development editor is to improve the efficiency of the delivery of projects within the team, and both editors are currently referenced in the team’s related projects. Of course, the editor currently supports projects with other companies as well. Here are some sample diagrams for several projects:

In the middle is a 3D scene edited by a 3D editor, and around it are some big-screen elements edited by a big-screen editor.

Different from the general large screen editor, our large screen editor not only supports the layout of large screen elements, but also supports hierarchical topology, architecture, traffic diagrams, and configuration functions. Based on the joint development of Canvas + HTML5 elements, it can support more rich functions and effects. For example, the following topology effect:

There are also rail transit, subway, traffic route map and so on:

Of course, there are configuration diagrams, such as the following power primary wiring diagram.

In the development of the editor, there are many iterations, self-denial, and then constant growth. In the process of product development, we need to conduct in-depth discussion on product design. Here are some insights to share with you. The purpose of this article is to share aspects of product functional design, not software development architecture.

Ease of use

Ease of use is a very broad concept. But it is one of the most important factors in product design, and even ease of use can make or break a product. The product is to help users to achieve a certain task, so the first product needs to have availability, availability is through a product function, can achieve the purpose of overdue. For example, the user needs to be able to configure a chart chart chart, and there is a chart chart configuration function in the editor. The usability of a product is to ensure that the product does its job properly, which is the most basic requirement.

But usability alone is not enough. In order for a product to be recognized, it has to be easy to use. Ease of use refers to the ease of use of the final product for users. Generally, the worse the ease of use, the more difficult it is for users to accept a product.

We also make a lot of effort in terms of ease of use. For example, some common copy functions are provided in the editor, whether it is convenient for users to improve efficiency and accuracy:

  • Various alignment functions
  • The average distribution
  • Isometric configuration
  • Mesh, automatic adsorption
  • Bulk copy
  • Drag and drop to copy
  • Combine and shatter
  • lock
  • undo redo
  • .

The above functions are designed to make it easier for users to use them.

In addition to the usual ancillary work, there are a few other rules to follow to do a good job of usability. Such as

  • Intuition Sometimes, many hidden functions are implemented unconsciously, such as using shortcut keys or right-click menus. Use shortcut keys or right menu should be cautious, more taboo is a function, only shortcut keys can be called up, and there is no intuitive button. And shortcuts can’t be viewed quickly, and the design delivered to the user is even worse. Of course, shortcuts in the case of intuitive delivery, sometimes can increase user efficiency.
  • Clarity, Avoiding ambiguity and ambiguity Function points should be clearly designed and not ambiguously expressed.
  • Simplicity Each function point should be designed to be relatively simple, and multiple functions should not be integrated by means of logical switches.

Of course, there is more ease of use, which is described later.

generality

Sometimes when we meet some requirements, we need to abstract the specific requirements into more abstract requirements; Take a specific need and turn it into a more general need. This seems to complicate the need for simplicity, but it is necessary to keep the software from becoming bloated.

For example, there was a component requirement like this:

Similar to progress bar requirements. To realize this component itself, it is not difficult. It can be achieved by using canvas drawing to repeatedly draw many rectangles and defining the number of repeated rectangles through data.

However, a more general rule that can be advanced from the middle is the repeated drawing of an object. Here, we abstract the concrete rectangle into something more abstract. How do you define an object? As simple as that, we could take all the primiprimies in our existing library as “some object”, and the final requirement would be:

  • All primitives in the primitives library can be repeatedly drawn, and the number of repetitions is defined by data.

So we finally defined a RepeatNode object (the meaning of RepeatNode), RepeatNode can specify a primitive to repeat, as shown in the following figure:

This node object can specify the object to repeat (the rectangle in the red box above is that), can specify the repeat here, spacing, and so on. When such as the number of repetitions can also be driven by dynamic data to achieve dynamic results.

With repeatNode, we can easily implement other similar effects besides the original requirement effects, such as:

There’s a follow-up feature that’s similar to the TAB TAB in HTML5, which requires clicking a button to switch between pages:

In the early stage of the editor, the mechanism of event dispatch is used. For example, click on the safeguard above, the script dispatches an event, and then relevant elements are displayed, while irrelevant elements are hidden.

It is ok to show and hide content by sending and receiving events, but the problem is that ease of use is not good, it is complicated to implement through editors, and it is difficult for ordinary implementors to use. Therefore, we can consider abstracting a TabNode. Some technical people have raised the question that the TabNode title part is not fixed, and may vary. But actually, we can do it in a different way than a regular Tab. A TabNode is simply given a Tab container that can be configured to specify which elements are the title of the Tab tag (similar to RepeatNode). This solves the problem that the TabNode title can vary.

In fact, you can reuse the original event dispatch mechanism to implement TabNode switching.

Flexibility and ease of use are sometimes at odds. For example, with TabNode, event-based scripting is definitely the most flexible, because scripting can handle almost any change in requirements, but it’s not easy to use.

Flexibility and ease of use. How do you do that? What I agree with is the multi-level design idea, the lowest level is a flexible way of implementation; On the basis of the flexibility of the underlying, we are in the further encapsulation, the commonly used functions and elements packaged into a more easy to use.

For example, this is the idea behind TabNode.

There is also editor support for Echart charts and HtmlNode functionality. Echart configuration is changeable, if all the configuration items are taken out, made into a visual mode, the workload is huge, so the editor directly provides json configuration, it is very flexible, but the ease of use is poor; HtmlNode is similar to the template mechanism of Vue and requires more professional developers to deal with it.

Echart diagrams and HTMLNodes are both flexible elements, but not easy to use. So what’s the solution? We have to think is to provide a template function, the common projects above do a good configuration, make templates, put in the template library. For non-specialists, you can choose from the template library instead of manually configuring JSON or HTML tags.

scalability

The most common change in an editor is a primitive change, so we provide a primitive editor. You can edit all kinds of needed primitives through the primitives editor, and also support the import processing of SVG images, such as the primitives used in the following figure:

All of the above primitives have dynamic effects, such as the first three-paragraph one, where the length of each paragraph can vary. The second quantity is variable, and the third quantity and height are variable.

The above is just to illustrate that the actual editing primitives are very large and flexible:

At the same time, it also provides a plug-in mechanism, which can appropriately extend the original function and facilitate the realization of some special requirements of the project.

conclusion

Here are some designs and thoughts, mainly based on the topology/large screen editor. In order to have better products, we have been working hard on architecture, design and thinking.

There are many similar design ideas for 3d editors, but I’ll talk about them later. If you have good ideas, you can discuss them by Email or wechat author: [email protected], wechat: 541002349. Please also follow the public account “ITMan Biao Shu “for more information.