Allow to hide "on step enter" activity behind a loader without already displaying the step content

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?

Regards Chris

@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?

1 Like

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 :slight_smile:

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.

Sorry, please read again - first post. Thank you.