camunda-modeler icon indicating copy to clipboard operation
camunda-modeler copied to clipboard

Support conditional "Show if" as an alternative to "Hide if"

Open tobiasschaefer opened this issue 1 year ago • 6 comments

Problem you would like to solve

Currently, Camunda Modeler supports "Hide if" for various elements. However, in many cases a "Show if" would be easier to read.

Negative FEEL expression are not easy to read 👎 . Or to write it in a positive way: Positive FEEL expressions are easy to read 👍

Look at the example for "yellow" in https://camunda.com/blog/2024/01/camunda-forms-features-you-dont-know/

It is IMHO confusing. Which values will actually show yellow? yellow: hide if creditScore >= 739 or creditScore < 580

This is much easier to read and maintain:

yellow: show if creditScore >= 580 and creditScore <= 738 (hope I got those numbers right :-) )

or even better:

yellow: show-if creditScore between 580 and 738

Proposed solution

I would

  • add an UI element in the modeler to switch between "hide if" and "show if" - so similar to the "fx" button to switch between FEEL expressions and constant values.
  • switching should not change the existing value in any way but simply keep it

Technically, I see two approaches

Approach 1: change in underlying JSON

  • in the case of "show if" this would be something like
"conditional": {
        "show": "=creditScore between 580 and 738"
      }
  • "hide" and "show" must be exclusive - there is no reason to support both at the same time
  • form.js (?) would need to support "show"

Approach 2: no change in underlying JSON

  • in the case of "show if" the conditional-hide expression in the JSON is negated with an enclosing not(...) so that the user actually never sees the enclosing not(...) unless he looks in the JSON
  • the modeler would show "hide if" if there is no enclosing not(....) (like now already) and show "show if" if there is a enclosing not. In the case of "show if" it would not show the enclosing not(...) to to the user.
  • This would also work with existing not-expressions which would then simply be shown as "show if"
  • forms.js (?) would not need a change because there is no change in the underlying JSON schema

Personally, I prefer the first approach.

To discuss: what should be the default in future? We'd need to consider that an empty "show if" might be confusing because no condition could be interpreted as "do not show". In my opinion it would be good to have three states instead:

  • "show always" (without condition allowed) as the default
  • "show if" (with required (!) condition)
  • "hide if" (with required (!) condition)

Alternatives considered

Let the user enter the enclosing not(...) manually and mentally interpret it as "show if". (oh no!)

Additional context

No response

tobiasschaefer avatar Feb 12 '24 06:02 tobiasschaefer

How about wrapping your show-if function with a not() function to make it a hide-if? This is a very good alternative I think ;)

But I see your point.

I would guess the origin is the hidden HTML attribute, but as form-js evolves to a low-codish tool, the UX plays a bigger role than the roots.

I support the following proposal:

Leave one expression field in place, and add a flag whether the expression should be for show-if or hide-if:

In the json structure, I would add a field "invert" next to hide:

...
"conditional": {
  "hide": "=mySweetExpression",
  "invert": true // false by default, setting this true would invert the hide logic
}

This would:

  • be backwards compatible
  • not allow adding 2 expressions that possibly have overlapping results...
  • be good to handle in the UI
  • still be a readable json (as someone reading json will probably know about the hidden attribute)

jonathanlukas avatar Feb 12 '24 11:02 jonathanlukas

Thanks @jonathanlukas

To me "conditional" seems generic and is not only there for "hide". If you add an attribute "invert" it may work for now because "hide" is the only subelement but who know what other elements may be added. So it should rather be named "invert-hide" or "hide-invert".

Personally, I'm still rather for "show" as a new attribute (my first approach) because it looks cleaner but I'm not here to decide because my view (especially on the internals and dependencies) is limited ;-)

tobiasschaefer avatar Feb 12 '24 13:02 tobiasschaefer

Hi @tobiasschaefer,

when I design a form, my expectation is to show all fields that I drag into the canvas.

Only on exceptions, I want to hide some of them.

ingorichtsmeier avatar Feb 12 '24 17:02 ingorichtsmeier

Hi @ingorichtsmeier,

I basically agree that fields will normally be shown but of course there are use cases where a field will only be shown for special cases. But I don't think that this is the crucial argument.

IMHO, more important is that we generally want to show (!) something and in quite a few cases it is easier to understand when something should be shown and not when it is hidden. The more complex the FEEL expressions are the more important it seems to me.

Take the example from above: yellow should be "shown when the value is in the range of 580 and 738". This is much easier to understand than "hide it when the value is below 580 or above 738".

I'm not arguing to remove "hide if" but simply add the option "show if" for cases it which this makes more sense.

tobiasschaefer avatar Feb 14 '24 05:02 tobiasschaefer

One thing we want to avoid here is ambiguity: What happens if folks have two options, show if, and hide if, and populate both? Right now the message is clear, and by adding more options the message becomes unclear.

I agree that hideif may be counter intuitive for some scenarios. You could easily argue that a field is always shown, unless there is a condition that does not match. It would work either way.

My point is: Let's be careful adding additional UI options, because that can bite us.

nikku avatar Feb 14 '24 07:02 nikku

We'll move it to backlog for now and assess it based on further feedback we get.

nikku avatar Feb 14 '24 07:02 nikku