Nowadays it is common and expected that domain experts can’t program, and programmers do not know enough of domain area to make decisions. So, you need at least two people to solve anything. And a manager.

Who is a domain expert? For example, it could be a game designer, who needs to design and then fine-tune the gameplay of a game; it could be an advertising manager, who needs to control ads targeting; it could be an analyst who has to dig into inapplication statistics to figure out where the business is going. And so on.

It is well and good if at early stages programmers can anticipate all the features that a domain expert would need in the software. Then it is possible to give the expert all the necessary controls, teach him to use them, and leave him to do his job.

But that does not (and should not) happen in real life — the market changes and / or the early anticipations are proven wrong and incomplete by practice, and BAM! your programmers tell you that they need to rewrite everything from scratch. (Not to speak about long development time needed to build such a “feature-complete” system in the first place.)

To prevent that, software is designed to be flexible and extensible. An API is facilitated to separate business logic from the system. Often a scripting programming language is embedded, so the business logic can be fine-tuned more easily by less skilled programmers.

So, now we have at least three people in the chain: domain expert, business logic programmer (or “scripter”), system programmer (plus manager). (People, qualified enough to be system programmers, usually do not like to code business logic.)

What would a domain expert do if he needs a new feature in the system business logic?

• Write a proposal for a feature.
• Defend that proposal on a meeting with a manager.
• Make sure that the task is assigned to a business logic programmer.
• Wait until the feature is coded.
• Test the implementation and realize that programmer got it wrong, or the original proposal was slightly wrong, or there are critical bugs.
• Repeat.

Depending on programmer’s availability and workload, a week and more may pass between idea and final implementation, regardless of an actual change complexity. Usually even more time is needed to see it deployed on production. The feedback loop is too long.

If a new feature requires changes in the system logic, there is not much that can be done to speed things up. However, often requested changes are trivial.

For example, a game designer may want to fiddle with achievement award logic; an advertising manager may want a slightly more complex condition in targeting rule than the system allows him to express; the analyst may want more of existing database fields to appear in the query form UI.

If the domain expert would be able to make changes he needs directly, he would be able to quickly try out his ideas, experiment with them, discard invalid ones and fine-tune what is viable. Quick feedback is essential for productivity.

Unless you want to teach the domain expert to code (usually not a good idea — he is likely to have enough on his hands as it is), the solution is to provide him with more flexible UI.

The problem with such UIs is that they are usually inflexible, hard to code and maintain. Furthermore, it is hard to make them reusable in other projects. As such UI is a part of backend, invisible to end-users, manpower to improve it is often allocated on a leftover basis. Depending on complexity, a full-blown backend to control business logic may take many man-months to implement.

The Visual Business Logic Editor Toolkit (or “The Toolkit” in short) is a product, designed to take the burden of an editor development off your team. The Toolkit is particularly well suited for business logic editors and is, in general, good for any hierarchical data editors, complex data filters, query builders etc.

Basically, The Toolkit allows the programmer to describe the API that a scripter would use to code the business logic (this description is called a “schema”). The Toolkit then generates (“renders”) the visual editor UI frontend for that API and the backend that generates the actual code from the editor data. (Hierarchical data are handled likewise, but programmer writes not the API schema, but the schema of data format.)

The domain expert configures the business logic visually in the editor. His work is then automatically converted to the code to be executed by the application (or to the data, to be consumed by it).

The editor and the backend take care about the data validation. If the schema is written correctly, it is not possible to create syntactically or semantically invalid code with the editor. Invalid hand-crafted editor data that does not match the schema will be rejected by the backend. (Still, if editor data may come from untrusted source, some reasonable sandboxing of the generated code is recommended, just in case.)

The UI frontend, generated by The Toolkit, is highly configurable and is easy to use after some accustoming. The Toolkit makes it easy to design the UI so the domain expert would work with the domain field concepts, natural to him, not in some obscure programmer terms of the API.

The Toolkit is agnostic to the resulting code language / data format. As long as what you want to get is a structured text (i.e., code in any programming language, SQL, XML, JSON, you name it) or even binary data, you will be able to create an editor for it. (Though for some complicated cases it helps to code a small intermediate abstraction layer to further transform the output.)

The schema description format is easy to grasp and use for a programmer. It contains a set of rules to build an editor data tree, along with transformation rules, describing how to render that data tree to the editor UI and to the resulting code / data.

The Toolkit supports editor data upgrades between schema versions. So, if you changed schema, you will be able to automatically upgrade existing editor data to match it. For common trivial cases data upgrade code is generated automatically. For rarer complex cases your programmers will need to write a few lines of code. Data upgrade routines are coded in Lua (lua.org, an easy-to-learn dynamic programming language), and are, in fact, a set of data tree traversal callback.

Demos

Some demos of The Toolkit editors are available at demo.logiceditor.com (hint: click on the red flag on the top-right to see the backend output). More demos are available upon request. Please note that most demos are a work in progress. Also, please note that the actual editor control is on the right side of the page. Everything around it — the left pane and the toolbar — are parts of our demo framework.

If you are interested in getting a prototype for your particular use-case or have any questions, please contact us at toolkit@logiceditor.com.

The Toolkit allows your programmers to easily create visual editors for your business logic and your hierarchical data. Also excellent for complicated forms, data filters etc.

Features

• Highly-customizable, easy-to-make low-maintenance web-based easy-to-use visual editor UI.
• Full-blown automatic data validation.
• Optional visualization for runtime errors.
• Optional data upgrade support to handle schema changes.

Web-based implementation

The Toolkit generates editor control, based on HTML and JavaScript. It is easy to embed into your backoffice HTML pages. All the editor users would need is a modern enough browser. (Note that mobile browsers are not yet fully supported.)

The backend that translates editor data to the resulting code / data is generated as a Lua library. We provide wrappers to that library, so it may be used out-of-the-box as a Linux console program or Linux HTTP-service. We’re able to provide packages for your favorite Linux distribution if necessary. Backend solutions for other OS-es (including Windows) may be implemented upon request.

Alternative implementations

Lua is very easy to embed. So to get a standalone application, you may embed a web browser control (like Awesomium, or any of free alternatives), embed Lua, and voilá — you have your own standalone business logic editor. Or, if you prefer to get a ready-made solution, contact us: toolkit@logiceditor.com.

If embedding a web-browser and / or Lua is not an option, it is usually not hard to implement alternative editor and backend for your specific situation. Contact us for details. For example, we plan to introduce a C# editor/backend, tailored for Unity, in the future.

SaaS

As an alternative to the hosting on the customer side, we are providing SaaS-like services for The Toolkit — we host for you the backends (as a HTTPS-services) and, optionally, the editor controls for your editors. We also provide remote access to the schema tools (which generate backend and editor control) for you, so you will get everything out of the box.

Contact us for details: toolkit@logiceditor.com.