Being able to programmatically enable/disable objects

Product Suggestions
1

Being able to programmatically enable/disable objects, for examples buttons

2

Hi @mellerbeck,

there is a workaround for this use case.
You must use a color variable to make visible or not your button. Then, use a boolean variable to activate or not the triggers linked to your button.

2 Likes
3

HI @mathieu.rey,

I know this is from 2020 but, I want to come back to this topic…

To me there is no good workaround and it does not work for input fields.

  1. its hard to ensure a consistent user interface, if the inactive design is also created manually
  2. if there are many triggers on one button, you need to set a valid variable on true, check for validity, set is false if not valid and check for true in all of the triggers. This is a lot of work and a lot of possible error sources. It also increses the trigger logic significantly.
  3. you also have to add unnacccessary user communication including language. A button that just does not work and is grey is easy to understand.
  4. to hide or change a Button you have to change at least two and up to four colors. To do so for e.g. 4 Buttons its up to 16 more variables and adds a lot of complexity

It would be so easy to make the html-attributes disabled and hidden accessable for buttons and inputs.

image
download
(right button disabled, left button is as created in Tulip)

The hidden attribute would also allow to block any other object behind a semi transparent widget and remove this blocker-widget by trigger logic to allow access to the object. This would also work for images, docs, custom widgets… the benefit of “hidden” is, that it is away and does not block the underlying content from getting clicked (as transparent color would still do)…

1 Like
4

I still want to be able to enable/disable objects :slight_smile: :slight_smile: :slight_smile:

1 Like
5

@mellerbeck, noted :sweat_smile:

I am curious though: what are your use-cases for enabling/disabling objects and ui/elements?

6

Hi @John,

here are some of my thoughts:

  • Enabeliung features dependent on user fields (hiding is better than showing what you cant do).

  • Enabeling widgets at the end of a loop (so you cant click as long as its still calculating. Checking would be an aditional trigger/task)

  • Preparing features for a later automated go-live

  • Putting more on the base layout (switching of, on individual steps. The layout stays more consistent.)

  • Enable a button after a timer, to force a minimum time you need to read or fulfil a step conscientious

  • Enable a widget, after confirming a checkbox

  • Enable different inputs, depending on previous input values

One example I an App, where I have more than one usecase for hiding and disabeling inputs and buttons.

On the first step I want the user to choose a quality measurement type.

On one type he needs to choose a measuring equipment and a measurement resolution, on the other he needs to choose a step length only.

On the next step he needs to type in 14 measurement values (amount depending on the type from step 1)
He should be able to confirm only if there are exactly 14 values. Otherwise the Button should be inactive. When there are 14 values, the input should become inactive.
(There are relatively many triggers in this button, to disable. Disabeling also avoids that the user performs unnecessary interactions.)

On the next step, a loop runs calculating values, that are added to the table and some fields. This needs some time. All inputs and buttons must be inactive as long as the loop calculation runs.

I hope that is some input, which illustrates the added value of these features.

1 Like
7

What they said. But in a nutshell, being able to hide\disable things is super useful from a UI perspective.

1 Like