Hey team,
Back again with another user experience improvement request. This time, we're looking at Gateways and Conditions.
My biggest adversary working with Laserfiche Forms: Terminated Processes.
It should be more difficult to terminate a process, but it is just so damn easy. ;)
Two standout things that lead to problems with terminating processes:
- Variables used in gateway conditions not being validated (or persisting when changed).
- Wrong gateway type / gateways being improperly configured in the first place.
The first one is a big one. Variables get changed by form designers all the time, and they have a huge impact on processes behind the scenes. There are some activity types that are protected against changes.
For example, in the front end if you rename an email address variable, the changes you make will pass through to certain activity types where those variables might be used. For example, the Email Activity "To:" field.
This seems to be because the Email Activity uses what I refer to as "variable tokens" to represent variables in some parts of the business process modeller interface..
Personally, I think it would be great to see this approach to "variable tokens" expanded to be used in other parts of the business process modeller.
That way if a variable is updated/changed in the front end, those changes can be automatically reflected in the back end, too.
Now, if a variable was deleted, it could grey out and fail validation just like when a task that has been assigned to a disabled or missing user does.
It seems the current "token variables" I mentioned earlier are also subject to some type of additional validation. This is great because it brings potential issues to the surface pretty quickly, allowing you to prevent terminations and/or troubleshoot when changes have been made to a form. Useful when designers have had a free for all with the variables.
So to see this approach to using variables used more widely throughout the designer would be a very welcome improvement to the user experience.
In addition to "variable tokens", it would also be great if validation could be split into two types.
- Simple validation (current).
- Advanced validation (new).
Advanced validation would take longer, but it would actually test that every variable used in the process actually exists and if they don't, highlights which activities have been improperly written or configured.
Classic examples - gateway conditions and emails!
So any improvements there would be great, and really appreciated.
Lastly, is the Gateway activities in general.
- It would be REALLY appreciated if validation could be improved for gateways. Specifically that it could check if a gateway was properly configured and that the variables used in conditions exist.
- The ability to change a Gateway from one type to another (via right click or via the details pane?).
- Better documentation, examples and help information on gateway pages would be certainly welcome, too. I think I'll elaborate a bit on this..
As an example: for a Message Start Event there is this Help Icon "?" that displays the following:
But for Gateways, you get no "helper icon", but instead, depending on which type of a gateway you selected, a description for method of use..
This message specifically outlines what happens if you use the gateway to split. But it does not explain what happens when you use it to merge. Even better is the Parallel Gateway:
She gets nothing at all - even though, this is the gateway you want to use when you want a process flow to wait until all conditions are met before proceeding to the next step. Which also raises the question - why allow Parallel Gateways to have outflows conditions set at all? Shouldn't that raise an error during validation (to help educate the user on the gateway type)?
Some of these observations are just little things that get mentioned to me by users, or through my own experience. If they can be fixed, that's great. If not, understandable.
Does anyone else have some things they'd like to mention?