In our current apps, we occasionally have a number of “pass-through” steps. Typically, these steps do some sort of validation on entry, based on which the step is either displayed to the operator or skipped.
At present, Tulip will first load the step content and only then start processing the “on step enter” trigger chain. This can cause confusion to the operator because even if only briefly shown, it suggests that there might have been something odd going on.
Our current best known workaround is to move the validation step to the proceeding step instead. But this has proven problematic because it requires to replicate the same logic in different places in case this “pass-through” step is called for from multiple different locations. It also breaks the logical flow.
It would be great if there was the possibility to display a loader while the on step enter triggers are executed (or at least an option to do so). This would allow to keep the required logic at the actual step and remove any potential confusion of the operator.
Hi Seb,
mh, I’m using a dummy step too, where I set a few variables, make some decisions and jump then to the right step.
My dummy step is empty but the default base layout and I can’t remember to see this step ever.
Do you have some connector queries at this step which takes some time to end?
@ChrisF jap, if you use an empty step that might work (or the base one) because the content is empty or already pre-cached. … If you add an image or many more widgets, it will show.
@sebme Thanks for the suggestion, details on your use case, and the diagram — very helpful to learn about this. Your idea of showing a loading indicator is a good one and we will certainly consider that.
Would another potential solution be to only load the UI after the step enter trigger logic has been executed? I’m guessing you want to show the loading indicator instead of the UI because you need to validate which step UI to load for the user?
To counter this I made the triggers to prepare data on “on step exist” on previous step but having it in a separate empty step is also a novel idea - though a potential maintenance hassle. The proposal of having influence on when UI is rendered would be a help, because we often reload the same step to present data if a value is manipulated. I would say that it also stems from not wanting to have the same triggers configured on e.g. a drop down / single select widget + on the “on step enter” triggers. Then we just reload. Currently triggers cant be moved around, but being allowed to move triggers into a “On step enter - before GUI” category could be really cool.
On a related note: Sometimes the player takes some time to load the content for the step because in some cases we have 5-7 record placeholders and a few connectors that need to (re)load data + various other preparation tasks. Such more complex task can drive loading up to 5-7 seconds and sometimes slower. We are of cause working to optimize the design, but I have always thought it was a bit sad that we are forced to run all triggers sequentially. A know we are running all the logic on the client side so we are dependent on the power of the client hardware and internet connection, but for some of our more advanced design there are a lot of triggers which could be fired at once, or in category sequences in parallel which are not at all dependent of one another. I believe the sequential implementation is a very safe and easy design to maintain, but has it been discussed that sequential doesn’t always deliver on speed? An analogy; When you buy a car the level of noise in the car is a indicator of quality. For IT system I think a lot of end users perceive the speed of the application as an indicator of quality
I may be missing something here, but I’ve used these kind of logic-steps before and have just put a blinking “loading” icon or text on the screen. For example, before we had the looping widget and the looping automation, looping used to be accomplished by transitioning into a step multiple times until a condition was met. With each transition into the step I would often display the increment number over the total to give the user a visual indicator of the progress.
Would something like this work for you? It is definitely a simple solution, but sometimes those are exactly what I’m looking for.
The issue is not the placeholder like a loader or something! it is the fact that you need to put your logic in a placeholder step in front of the actual step if you don’t want to show something to an operator. Like explained above.
Say you have a form that you only want to show under certain circumstances. Or maybe a more compelling case, a flashy warning sign to notify the operator that a certain condition is met. If the material is not cached, the step will load and show and only then the logic will be evaluated. This will cause the warning to be displayed for a short period of time regardless of whether the condition in the entry is met or not.
Just ran again into a situation where some logic that would send the operator to a particular step was buried in a preceding step that was not that obvious… just in the aim to not confuse our shop floor with some flashing big red warning/stop sign (even if only for maybe a second) if the checking logic would have been put right in the step where it belongs logically, but in the “on step start” trigger bucket…
could you give us a sample how an additional routing step would be an issue?
I use that a lot and I find it quite logical, that I don’t want to open a step, that is not meant to be shown… I would actually avoid entering steps, to then skip them (what you seem to want to achieve)…
This is one example. But I can’t see where I have to duplicate logic here.
Maybe your flow is more complex, so it would be helpful to know an example…
That does not solve “the problem” of having to put logic not on the corresponding step but at some other place that might not immediately be transparent since there is no visual workflow engine the would transparently show this… does that explain it better??
Okay I see you want more visibility of all possible transitions…
However, I cannot see why the decision whether or not to enter step x should happen on step x.
I can also not see, how a step enter trigger is more visible to you than a step exit trigger.
To me the issue of visibility is a real one for sure.
But that just seems not to be a solution to me.
Imagine, you need to drive to work by car daily. You first drive to a gas station and there you check your tank level. If it’s less than half full, you fill it up. Otherwise you drive to work without filling it up.
Now you find that unnecessary. That’s why you decide to only pass the gas station instead of stopping on the gas station premises.
But it is still unnecessary to drive there isn’t it?
Sorry if this comparison does not match what you try to achieve, but to mee it feels like that.
To me the decision does not belong to the actual target step!
Tulip structures all its logic around steps. What is so wrong about having a way to tie display logic of a step to the actual step itself? Especially if it is a conditional show or hide decision that treats a step as a strict sequence of steps? Why make it overly confusing and difficult to navigate conceptually? Sorry, I can’t follow you there.
To me its just logical to decide where to go before you actually go there.
Maybe that’s just the way I think.
I just cant see how moving the decision from step enter to the before step exit makes anything more complicated or confusing.
Quite the opposite: I find it more structured, since the step enter trigger might contain actual calculations to execute on the step.
This is more separated and easier to read to me.
But:
There is nothing wrong. I am not the measure of all things. I might think different than many other people, so your point can absolutely be valid.
Please don’t feel attacked or so, I just wanted to share my thoughts on solving those things.
In this constellation a transparency problem arises that requires you to be aware of the entire context of the app. In a complex app this can become a problem if said step is navigated to from multiple different other steps. So you start adding identical logic in multiple locations or implement additional helper steps. If things need to change and later someone looks at it, he will first navigate to the optional step… and then from there needs to reverse engineer from which other end-triggers this step might be navigated to…
Yes you can do it… but no matter what, it would be a great enhancement of functionality to be able to hide the UI from the operator in one way or another while an “initialization” trigger is executed. This could be used to pre-load data as well as trigger 1st order transitions before that operator sees anything that might cause him to wonder what is going on.