Add image widget which allows you to switch images to signal state

Looking for a native widget that lets me easily switch between different images (png/jpeg/svg (!)) depending on variable value to signal state to the operator.

Most simple example: switch between loading spinner and loaded checkmark.

Ideally should either accept text (=> many states) or boolean (3 states: null, true, false)

Corrected… version

Hi @sebme, thanks for your product request!

Just to verify that I fully understand the request, you would like to show an image/icon based on conditional logic (If variable value = X, then show Image A)?

Doing so will allow you to show state of the application, step, or data to the end user operator.

If I have the interpretation correct, this makes a lot of sense. We will see what we can do!

Yes, this is what I would like to do.

1 Like

Why don’t you put your images into variables and on each state you replace the displayed image variable?
4 Variables:

  • loading_image (with the image url as default value)
  • success_image (with the image url as default value)
  • failure_image (with the image url as default value)
  • displayed_image

On each state you make a Data Manipulation (e.g.) success_image into displayed_image
Thats what I do with a loading spinner…


If you avoid using the image widget and simply display the image variable with the variable widget, it would work fine and you will have no distortion, even when the seperate images are different in size and aspect ratio…


This seems like the best approach. Thanks for providing this solution, @thorsten.langner.

You could also achieve a similar result using a custom widget.

In addition, our team will investigate further to make this easier to configure in the future.

:smile: ok… creative workaround! with variable pollution. Would probably do the trick for the moment… but I would still welcome a more structured approach. Anothe option would be to be able to pre-populate an object array and then use that… but that comes with the currently crazy array index matching and lookup using expressions… also not pretty. :roll_eyes:

I am in the process of eliminating custom widgets as much as possible… so this is not really an option.

The array lookup method to have the states pre-structured…

Crazy expression-based array lookup using indexes to come…

array_index_of(map_to_text_list(@Variable.UX_Loading States , "state"),"loading")

Potential downside of wither approache, though I am not 100% sure right now how it behaves: caching behavior.

If I close the player and restart it and then load the app I initially see a blank image… Lots of flickering :frowning:

Are default assets in variables not pre-loaded?

Thanks for the additional info, @sebme. This is very helpful for when we investigate this request.

This is a super interesting thread! Many thoughts here.

First, I would note that I have used @thorsten.langner 's method many times - at this point, one of my first steps in making any inspection-esque app is to upload the result_good , result_ng, and result_neutral images i’ve saved on my desktop to make these “Environment Variables” for later use.

(It also has the added benefit of being a potential indicator of inspection results; let’s say step 1 passes. If I want to, later on, check if step 1 has passed then perhaps I don’t need a boolean step1_result variable. Instead, I simply check if step1_result_icon is equal to result_good or result_ng, if that makes any sense)

The array lookup method is very interesting as it allows you to pull programmatically. However, unless you’re doing an IF() in the expression to pull an icon depending on some condition, I might instead recommend having these be their own variable and simply selecting one or the other in your trigger.
(note that you can still map objects to other objects, as long as the keys are identical; I use this commonly for mapping, say, multiple colors at once to a button to change its visual state)

re. caching, @sebme you are correct that the cache of assets/variables is cleared when the app is restarted. One thing I’ve done before to avoid this first-time flicker is to put the assets offscreen on the first step of your app - or maybe the base layer, if it doesn’t affect performance too much - so they “load” in the background.
Especially in the case of larger items like videos, a “load automatically in the background” option would probably be a nice optional feature in the product; I’ll take this back to the team.