Automations Concepts Overview

Almost any serious no-code tool should have automations at some point. Automation is bread and butter of a useful system that help people be more productive. First stage is data collecting for sure, but second is automation.

We are thinking about automations in Fibery, since it seems data collection problem in Fibery is close to its ultimate resolution. However, automations creation is hard, since it is very close to programming. In this article I tried to briefly review all possible ways to add automation layer into a system. Feel free to add more if you know any.

Problem

You have to explain your desired automation flow to the computer and be precise enough to not mislead it. Any vagueness will be penalized by errors and unwanted outcome.

Current Solutions

Language based

Low level code (scripting language)

The lowest approach is just code. Scripting language was used in many software tools, like HyperCards, FileMaker, etc. It provides enormous flexibility, but there is a huge entry barrier and only programmers can penetrate it in general.

Graphical Language

We can represent code using graphical blocks + text. This approach is used in Scratch, for example, and kids quite quickly grasp it.

In general, the power of such system can be comparable with low-code solution, since you still operate with all programming language constructs. The benefit is more clear scoping and prevention of bad composability. For example, you can’t insert some blocks inside another, since shape is different. This prevents some groups of mistakes.

The downside is that it becomes hard to grasp for large programs. However, automation rules might be small enough to use this approach without problems.

DSL

We can create a special language designed only for automation purpose. In this case it will be easier to grasp by knowledge workers, since you may use familiar terms and restrict language flexibility. For example, iterators and recursion are hard to understand and debug, so this DSL may wrap such constructs into something less complex.

When Task.State.Name is “Coded” 
Then GitLab["Profile"].Create.PullRequest(Task.Id + Task.Name)

This approach might be promising, but console interfaces are hard to grasp for most people. It seems this should be a fall-back from some other solution.

Human Language Processing (NLP)

Tools like Siri show some promise. In general some people use it to do actions like setup a meeting or send an email. However, it is not about automation. NLP can be used to describe desired automation, but it is very hard to do even conceptually, not even thinking about technical difficulties. We have to transform human text into formal lower level constructs (like DSL), and this is hard to do. Still there are some attempts in NLQ that looks interesting.

Forms

Forms is one of the most popular approach to design automation rules. There are many systems like IFTT and Zapier that follow this way and all of them are quite successful.

When/Then

People are familiar with point-and-click interfaces, so it is natural to use this approach for everything.

The problem is that automation rule is an algorithm, not a static structure. And it is very hard to visualize dynamic things like algorithms using static images and static UI. You have to be able to re-play the flow in your head with some visual hints from UI.

By Example

Macros Recording

We can “show“ to a system what we want to do and “record“ a manual flow to translate it into automation flow. For example, Photoshop has macros’ that can be recorded and executed on many images.

It looks like a possible way to go for a single system, but almost impossible for several systems.

For example, we can merge several actions in Fibery into one:

1. Change state to Planned
2. Set Planned Quarter to Q1 2020
3. Assign to Me

This is a simple case where we select exact values, so we can record this flow and execute it with a single button click. Let’s say, we create Plan button that will execute these actions when clicked.

It can be more complex:

1. Create new Bug named “Problem in Search module“
2. Assign to Vadim

In general we want to assign all search related bugs to Vadim, but system will not understand this generalization. However, if we create this macros, it might be easier to clarify what we want in the macros than creating the whole rule from scratch. Imagine, we can edit a macros and set a condition (filter?) for entity creation, like Name.Contains(“Search“).

Block-schemes

You can assemble automation rules using pseudo-code or block-schemes. The advantage is that it visualizes flow somehow. You can imagine that entity flows from top state to bottom state via some conditions and actions. Still it is an abstract representation that barely adds something useful on top of basic text. In fact, you can imagine that every line of text is just the next step and have a very similar representation with one exception — conditional logic. It is much easier to see logic branches here:

Moreover, here we have DnD interface that you manipulate directly and it is closer to WYSIWYG principle. Basically, you name every step of the algorithm and thus have better understanding what is going on here on a high level. However, details of every steps are somewhat hidden, so for power users it might be not the fastest way to create automations.

Mixed

Block-schemes + Forms

You can create high level flow using blocks and specify block details using Form UI.

Block-schemes + Code

You can create the overall flow using blocks, but every block has DSL or code inside. Thus you split algorithm/flow creation into manageable pieces and it may not look like programming at all. It may be as complex and Formulas in Fibery and this level of complexity can be low enough to allow many people create automations.

Notes, Ideas and Observations

• Automations creation is a heavy cognitive task. It demands significant effort from a person and somewhat “programming-oriented mind”. You have to think about the process flow and this is often very hard. Even simplest algorithms are hard to grasp and internalize to a formal form.
• Validating and debugging automation rules is very hard. You should be able to understand what step failed and why. This is as close to programming as you can get.
• Connecting external tools is hard. You have to pass authentication barrier and somehow get the tools terminology to understand what to do. When tools name same things differently, you have a mismatch to overcome every time you create a rule.
• It seems WYSIWYG approach with some real-time feedback (check Bret Victor ideas) is a way to go for mere mortals. Still flow visualization is hard. We should try to help people with visual queues, current state visualization, etc. We should augment human thoughts and help them penetrate rules creation barrier. For example, user can provide some sample data and on every step we can show how this data looks.
• It is interesting to think about declarative approach. Can we describe what we want to achieve with a rule instead how to execute it? SQL does that well. Can we apply similar approach? Like describe initial state, describe event, describe final state. Can system build rules based on this info?