During testing we have noticed that depending on the network speed it can become difficult for the operator to tell if the Tulip player is still running and doing something in the background or whether is just got stalled for whatever reason…
This is usually the case when a network query or request is still being processed.
I am wondering how other users here are handling these kind of cases… Personally I would love to see some kind of widget that one could put somewhere which would only spin if there is still stuff going on in the background.
Best we have come up with right now is just a “dump” spinner as a custom widget which basically just keeps spinning endlessly… but this only works for “in-between” steps where you are hopping on and off to get certain things done…
Welcome to the community! This is a great idea. Id imagine you are talking primarily about step level and app level triggers? The triggers running on buttons will change the button to a loading icon while they run, but there isn’t a good way to visualize this for step triggers. Is that right?
I can picture a loading bar across the top of the step or something to indicate the step load state, or any currently running triggers. Similar to a web browser. Do you think this would do what your need?
not sure if this would need to be trigger specific… I could imagine a global “I am still busy with something” indicator would be more what we are looking for in our particular case.
Right now if there is still something being processed, the player sometimes just seems to be freezing until that activity is done with no direct visual indicator.
Yes, that has been our workaround now as well… except we have used a custom widget for this… but this only works for dedicated steps… not if there is some botton interaction by the operator going on at steps… hence the question about a rather global “busy” indicator of some sort.
No, it equally applies to the internal queries as well… at least if a lot of records need to be modified… and certainly the overall latency has an impact here as well.
I assume if the general response latency is in the range of a few ms it might be ok without any further visual indicator - in principle.
But right now I am experiencing north of 200-300 ms on almost any database request (internal or connector via Table API) no matter how basic (is this normal after all?).
About asynchronous, Tulip connector are often use to make some master data check in our ERP SAP) before post a update request. As connector actions run in sequence the more control we have the longer operator wait. Run connector function in // can reduce dramatically response time.
A query execution time in the ballpark of 300ms isn’t surprising. In the backend, Tables are referencing Postgres databases, and the table UI is simply a no-code interface for writing SQL queries for that table.
As tables expand, and the complexity of queries expands, the time to execute queries grows. We leverage a lot of indexing to improve query performance, but often this can’t be leveraged for more intricate queries. Network speed can absolutely impact query performance as well.
We can do a lot to expose the fact that these operations are running in the background. I will connect with our player and design teams to get their thoughts on the right approach for this. We could expose this to a widget, but I would love if it was something you didn’t even need to add, it was just native behavior we handled better.
yes having this as a native visualization directly in the player itself could also be a solution.
Not to hijack the initial discussion here, but regarding the query times… you start getting me worried. In my testing we are currently talking about a few tables with no more than a handful of records. No fancy aggregations going on there… just simple selects and sometimes a query which is supposed to return a single record with an aggregate to fetch the ID of the record returned…
And this would still be seeing between 200 and 300ms per request?
Do you mind shooting me a direct message with a link to your table? Our engineering team can check it out. It sounds like the most common root cause of slowness for simple queries is network speed between the device running Player and the cloud. Sometimes we see cases where the underlying database is living on a US server, and the customer is in the EU, and that drives performance issues.
This could also be tied to your instance being a trial, which has less allocated resources than an a customer.
Hello again, when will we see a transparent feedback as part of the native player experience or, alternatively, as a native widget that can be placed for this purpose?
In our production environment this has proven to be a major topic so far where operators are left wondering what is going on - and particularly IF something is still going on.
I didn’t read the whole thread, so maybe my input is already known or not useful at all.
However, I like your suggestion a lot. What I do as a workaround sometimes is:
I have a Picture widget with a variable loading_active and a second variable loading_img.
The second one contains a spinner as a *.gif as default value.
When entering the step, I load the loading_img into the loading_active as first trigger.
Then I clear the loading_active as last trigger.
For most use cases that keeps the spinner visual as long as trigger action happens.
Buttons usually have their own spinners, but you could use this technique here as well.
I know it’s not awesome, but on potential slow trigger chains it helped me a lot.
Hi, this is similar to the way we tried to adress this issue as well. But is has proven to be not adequate.
a) it is a lot of unecessary manual tinkering for something that should definetely come out of the box, arkward to maintain.
b) it does not properly reflect what is going on under the hood of the player.
The plattform in its current state is designed to support explicit triggers. The operator pushes a button and then something happens. For this ther spinner is diplayed on the button itself. It is ill equipped for properly handling automated tasks that are triggered on step entry. This is a significant limitation that developers need to be aware of. Or they run into massive issues down the line. This goes beyond the simple spinner icon.