We’ve been working on a mobile process language for quite some time now. During this process we’ve been devising several names for this language. We started with Tweetflows, moved to EGON and we’ve settled for lal – little activity language. The name describes the basic design principle, which is the encapsulation of (semi-)structured actions as an activity.
An activity can be compared to a check-list or todo-list: it describes things that one needs to do and can upon completion cross from the list. Sometimes these lists do not require a particular order in which the things need to be done. This is meant by semi-part of the definition: it does not matter in which order things are done. For example, if I write an article I only need to assure that I’ve completed sections, I do not necessarily care about the order I write the corresponding sections of the article (especially when I’m stuck with some part of the article, I often try to find inspiration by writing section first :-)). Important is the outcome – the finished article. There are also different types of lists when the order is important. This is the structured part of the definition. For example, I cannot compile a C programm before I install the corresponding compiler on my computer.
In lal, these dependencies are described with dedicated keywords, such as AND, OR, or THEN. These keywords explain if actions depend on each other and whether there is a particular sequence that needs to be considered.
The following example describes the simplified process of writing a scientific report. Here, I have a certain degree of freedom of writing: it doesn’t matter if I write the motivation before the introduction. However, the sequence matters when it comes to the evaluation. Obviously I can only evaluate a prototype after I programmed it (actually, in academia it is quite often the case that people first build a prototype and afterwards look for the problem that the prototype solves :-)).
But for now, we assume that it goes like this:
write.introduction
AND write.motivation
AND write.workingexample
AND program.prototype
THEN evaluate.prototype
THEN write.evaluation
AND write.conclusion
In the example, AND concatenates actions that can be executed in arbitrary order, but there is still a preferred sequence for actions. THEN on the other hand, requires actions to be executed in exactly the way as they are described in lal.
Like todo-lists, lal supports the tracking of actions that have been already completed or have begun. This is expressed in lal with the help of modifiers like did, will, or do. For example, the successful completion of the process of writing a scientific report looks like this:
didWrite.introduction
AND didWrite.motivation
AND didWrite.workingexample
AND didProgram.prototype
THEN didEvaluate.prototype
THEN didWrite.evaluation
AND didWrite.conclusion
There are some additional issues that needs extra consideration. For instance, it can be the case that actions are simply not executed. The corresponding modifier in lal provides is didNot:
didNotWrite.introduction
AND didWrite.motivation
AND didWrite.workingexample
AND didProgram.prototype
THEN didEvaluate.prototype
THEN didWrite.evaluation
AND didWrite.conclusion
Omitting the introduction as in the example above can be a problem and not acceptable, but sometimes also perfectly ok: it depends on the expected outcome of the process. Typically, there are several strategies to cope with a situation like this. A straightforward approach is to require that all actions have been successfully completed and then accept the process as completed (this is the default in lal). The alternative is to accept that a process can be completed without having all actions executed. That is where things get a bit tricky: we need to know upfront which part of the process can be omitted without having a (too) negative effect on the overall process completion. Thus, we put the burden on the designer of the process who needs to decide which actions must be completed and which actions can also be omitted. This requires a modified variant of action calls. In lal we use square brackets to denote actions that should be executed but are not mandatory. If we accept a scientific report without an introduction and without a conclusion, we express this in lal as follows:
[write.introduction]
AND write.motivation
AND write.workingexample
AND program.prototype
THEN evaluate.prototype
THEN write.evaluation
AND [write.conclusion]
Note that we do not include extra information to describe the circumstances, i.e., the context that make an action optional. The reason is that the reason for omitting an action is not important to the overall process.
We’ve continued developing LAL in the context SOLOMON project in which we extended the features of the language with additional structural elements like WHEN … THEN as well as cards and decks. We’re considering using the language also in the SOLOMON follow-up project XP to describe contextual actions on a ephemeral computing service platform.
Photo by Wander Fleur on Unsplash
