Add option to define how error and notification messages behave per message

Product Suggestions
1

While it was a great relieve for us to finally see the option to make error message sticky in the Tulip Player and prevent them from automatically disappearing without any user intervention, we now have the situation that there can be valid reasons why a message should indeed disappear by itself after some time is passed.

This mainly concerns cases where an error message is the direct result of pressing a button. In these cases the error is directly related to the user event.

The sticky errors are more useful to handle errors that occur as part of an automated step transition where errors might occur without the operator directly associating them with a triggered manual event.

Please add the possibility to override the sticky behavior on message level, in addition to the new newly available global default.

2

+1 in general I advocate for configuration being applied at the app level. As businesses scale Tulip to tens and sometimes hundreds of use cases, it doesn’t really make sense to have instance or even workspace wide settings. Definitely feel this same pain when working with the auto logout system.

1 Like
3

Hi @sebme, thanks for your suggestion regarding the messaging system. Would the following idea help with the issue you are experiencing?

  • In the trigger editor, use ‘Show Message’ for the message you’d like to dismiss after X seconds.
  • In the trigger editor, use ‘Show Error’ for the message you’d like to persist for the operator.
  • In the Account Settings > Player, set Toast Message Duration to X seconds and Toast Error Message Duration to 0 seconds.

If this doesn’t solve your issue fully, I’d love to hear what more we potentially could do to help!

4

Hi @shep,

no it does not, because a message is a different thing than an error.

This is further underlined by the different color scheme Tulip is using to differentiate the two messages.

As an operator, when I see something popping up in red, this tells me something is most likely wrong and there is a high likelihood I need to do something to solve it.

  • When it is an error that is the result of a complex flow that is not immediately visibly linked to some manual action (like pressing a button) the message should persist. Thsi might also show a complex error message that the user will need time to read to comprehend. “An error occurred while doing XYZ. Please do this or that to solve the problem.”
  • When it is linked to a button it might make sense to have it disappear automatically - i.e. because a simple validation was not passed. “Not yet allowed.”

When it is not something in red, it is probably just telling me I did something right or that it worked in the way that was expected. “Label added to list successfully!”

5

Hi @sebme, understood, thank you for clarifying. We took note of this suggestion and will see what we can do!

Also, thank you @danielpomeranz for sharing your thoughts around this too!