Current state of Development (June 1st 2018) — some thoughts on grouping

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.

On wednesday we set up a new sprint with our frontend development team working on the Workflow Designer. We discussed some general approaches for “grouping”. There are different levels where you can think about grouping of elements in the Unibright universe, and this problem gives a good feeling about the challenges of defining interfaces between different teams and parts of the framework:

• Thinking of the graphical representation, a “group” could be seen as a concept to mark several single workflow elements as belonging together. This group could be displayed in a special way, for example as a dashed rectangle, surrounding all the elements that are part of group.
• If you think of a workflow consisting of single elements, a group could also be used to “hide” some elements from the view to reduce complexity.
• From code generation perspective a group of single workflow activities could be seen as a building block whose elements belong together and are not allowed to be altered
• From the perspective of a published “live” smart contract, a group of single statements could be seen as a transaction, as something that should be either executed completely or not at all
• From the perspective of a process orchestrator, a group could also be a “sub workflow”, being defined by a dedicated Unibright template and resulting in a dedicated set of smart contracts

Grouping of elements

Here is an excerpt our of the acceptance criteria (“AC”)of the corresponding user stories, taken from the issues of the current sprint:

Defining groups in the workflow designer:

• 1) drag transaction group to the artboard
• 2) drag existing elements into the group
• AC: Group should be marked with the dashed rectangle
• AC: Different group types should be marked in different fashions
• AC: Groups should have only one connection in and one out
• AC: The content of a group should be treated as a “new workflow”

Expanding / collapsing groups in the workflow designer:

• AC: User should be able to expand and collapse grouped elements
• AC: User should recognize whether group is expanded (dotted line) or not

As you can see, there are different understandings of a grouping concept and the connected goals we want to achieve. As we are still in the beginning of the development with all teams working on the different parts of the framework, we decided to reduce complexity and design the graphical aspects for the workflow designer first. We will build different types of groups with dedicated graphical representations, so their use within the process can be defined seperately, as soon as it is specified more detailled.

More updates soon, stay tuned.