Color. Color was the most intuitive for me. If you choose the color palette accordingly. Because when you use color to represent it, you can see at a glance what is happening in the process. I don't know the details yet but on a top level it is possible to get an overview which rule is active where. Furthermore, I find the annotation of a task with multiple constraints to be a very clean representation in this way. 

 

 

Yes 

 

Symbols, also give a good overview but they are too small, I can get some information from them but it is hard to see which rules are active on which activities because of the size.  

 

Hard to say, scaling the symbols would make them much bigger and it would be hard to show multiple active rules on one activity. I find the expressive power of symbols better because I can more easily make an association between rule and symbol. Symbols are more intuitive to recognize, of course it depends on the chosen symbols. 

 

 

Clearly text. With text, I can present complexity in a compact form. Without many restrictions, I can convey a lot of information using text. Even in different granularity adapted to the user. I have no restrictions on the design of the text and can create and refine drafts very easily. 

Textures can also be positively highlighted in the detail view but what has to be emphasized is that the training time for textures certainly plays a higher role. Without a legend, textures are harder to understand. But a texture offers another dimension with the structure/density information. Surely a texture has a charm, but you must not forget that the tasklabel must still be readable. 

 

I like scaling as a concept very much because here I can express something that can be seen both at a glance and in detail. However, the concept alone is not enough in a complex scenario, it is no longer comprehensible. The big advantage is that you can see at a glance "Look here" with this activity is something. The concept is also known from word processing with e.g. bold font that should indicate something important. Exciting can also be the effect of the rule with the size to represent for example critical rules are represented very large. Edges are completely unsuitable in the 3D representation with several instances and rules. If I don't put any function in the edge except the membership, edges completely negate the bonus I gain from a 3D representation. 

 

I think a separation between process and instances is good, i.e. process and rules on one side and process instances and rule instances on the other side. Then I see compactly how the process looks like and which rules can occur and then you would have the process instances and constraint instances. It always depends what role is using the system they may want different granularity of information. 

 

No, of course it always depends on the end user, but I personally do not think that a representation should be omitted.  

 

Colors and symbols. But mainly colors, like a traffic light, that's a common concept that we've standardized. For me it's just very intuitive because the concept is just so present. 

 

From my experience, for example in robot programming. It makes more sense to work with AR/VR for more complex processes. I think navigation is easier with AR/VR, especially when the models fan out even more and become higher.  

 

I think it's a very good approach to model the rules explicitly and not to model them into the process as this makes the process more complex without important content that can be outsourced. I think the potential is there just by looking at the use cases we have at our company.