Hi @Mulen, thanks for your suggestions! Some great ideas in here.
Wanted to clarify what issue you’re having with current dropdown output format. Do you want it to output as a instead of Option A because of the space? I’m trying to understand in what scenario you’d need to be able to compare/ inform logic based on identifying an a vs doing same logic but just checking for Option A ? I could see it potentially help the WF be a bit more future proof if you change the user-facing label for “Option A” (but other than that; can’t think of a big benefit).
In terms of a solution for that, for each dropdown question what if we had a “Simple output” toggle. True by default; when set to “false” outputs each dropdown response as an object, like
{
"response_index": 0 // user selected first option in list
"response_label": "Option A"
//Future metadata could also be shown here
}
So that you can label what ever you want but the value is that you can take on the next node and do some logic.
Maybe there is an example like this
<label for="service">Choose a Service:</label>
<select name="service" id="service">
<option value="saas">Software as a Service</option>
<option value="paas">Platform as a Service</option>
<option value="managed">Fully Managed Service</option>
</select>
As you can see, when someone submit the form, i don’t want to take the label Platform as a Service to do the logic, nor try to find the right array index. Just take the index key named paas and do some logic.
Thanks for clarifying @Mulen . Is there any technical reason why you can’t do logic and be using a value that includes spaces? e.g. `if(“Option 1” == “Option 1”) still evaluates to true (for example in IF node or an expression; ofc one of the values would be a variable but evaluates to “Option 1” ultimately)
Or is it more of a preference, that you’re used to working with cleaner/ safer keys for logic?
I believe it’s more like a best practice to use cleaner / safer keys as you say to do logic. In our current setup we use these keys and match them from our database. In our database we have values: saas, paas, managed, so it’s easier to do logic without using the labels of these values
Thanks so much for the extra context! Especially the point about how those might already be the keys in other systems; so this way you don’t have to maintain a mapping between them. That along with feeling like more of a best practice are great reasons and IMO definitely improve UX in those cases.
I recommend you submit each of your requests above as a separate feature request. That way users can vote on each one (also if scope is more modular; it’s easier for us to accept a request and implement).
A quick note about the Date Field Type.
That field is an HTML input of type date, so the date formatting is set automatically based on the locale of the user’s browser.
Does this solve your request to define how to render the date, or do you still need to define how to render a date? (ignoring the user’s browser default).