Jun 29, 2018
Current State of Development (June 29th 2018) — the beauty of templates
As outlined in our blogpost about our strategy on community updates, this blog series shows what we are currently working at. It will give you some insights on specific questions we are dealing with right now and also on our overall progress.
Last time we featured the different blockchain targets of Unibright, this time we will elaborate on our beautiful template approach.
In the beginning of our Unibright journey, we spent a lot of time on the concept of the visual workflow designer. We wanted to have an easy to understand, no-code-needed approach, empowering process specialists to visually build blockchain logic without a single line of code.
During the last month we saw, that it doesn’t make sense alone to just replace a coding structure by a visual structure. You also have to break down the elements you really need to describe a specific use case and reduce complexity as much as possible.
That saying, we understood that it is not sufficient to just replace coding structures (like decisions, loops or assignements) by graphical representation. If this was the only level of abstraction, you would still need somebody to define the process who is albe to think in code structures.
We want users of the Unibright framework to stick to their domain and think in processes they are used to. So, we designed our templates to not only hold a use case specific base workflow, but also dedicated graphical elements that exactly fit the usecase the template stands for.
Let’s take our “Multi-Party-Approval” Template as an example. This template enables the use case of different parties (departments or employees) giving their “OK” to a certain process. You can think of it like a “checklist in the blockchain”.
The model behind is quite simple, it only consists of “Approvers” (those who give their “Go” or their “No-Go”) and “Feedbacks” the actual “Go” or “No-Go”.
When it comes to the graphical representation, the user can now connect Approvers (Squares) to Feedbacks (Circles). The connections shows if approvals can be given only in sequence (State A in the example) or also parallel (State B1 and B2 in the example).
That’s it!
- The user only has to “learn” how to handle these two elements, and can create as detailled or extensive approval processes as he wants to
- The user can think in “approval processes” rather than having to think in “how to code a multi party approval process”
- We can test and audit the resulting smart contracts for various blockchains very easily, because the “language” we use to define them is reduced as much as possible to still server the use case but avoid overhead (check “Occam’s razor” here ;-))
- We can use the same graphical representation to monitor the current state of an existing approval process — think of the states getting green or red, showing if the approved or not
The Unibright template concept holds a great scaling potential. By offering templates for specific use cases, we can easily provide a solution for a new client, without having to explain a complete graphical framework to him.
We can prepare code generation and testing at a very high level and provide much better quality than custom coded smart contracts can offer.
