Sometimes I took some time to input a static value for testing (I’m mainly thinking of options in single select for example). There are situations in which the values in the list are very close if not identical to what will actually be used and where it would be too “heavy” to have a table to list the values.
It would be nice if one had a button next to the static value form to save what was input to a variable. This would ask the user for the variable name and, once validated, a variable with the static value as a default value and the input name would be added to the app.
Thanks @fti , what’s the reason you’re hoping to have this be a variable – is it because you’re using it later again, or because you’re setting up a test & debug workflow and you’re hoping to enter test cases?
It could be both for testing purposes and during actual app building. Sometimes reflection about the process occurs during app building with the customer. Prototypes tend to become the 1st Production version of an app.
This is a minor improvement but I think it should be seen as a “Quality of Life” change.
We don’t fully understand your use case. Is there a video you could link?
We’re wondering why not just start with a variable as in the attached screenshot for the single select – instead of the static option. Then you don’t have to promote.
(I chose to describe the idea textually. This should be clear enough I hope but if you still think that’s needed, I’ll take the time to make a video.)
The user could start with a variable indeed. However the point I’m trying to make here is that there’s a good chance that they won’t, for various reasons.
Regarding the context, maybe they’re in a hurry because they’re wireframing during a meeting. Or maybe they are editing an app and are just inputing dummy static values which will later be edited during a client meeting and replaced with real values.
More importantly, regarding the actual actions required, the user can either input static values or create a variable. Creating a variable might sound like the most reasonable choice but has both a time and cognitive cost. It forces them to:
switch to the App tab, hiding the Widget tab which is usually more useful when editing
wait for variable modal to load
click Create
remember what type of variable they need for their widget and configure it (which can be particularly painful when dealing with complex Object values since they must remember both the type and name of each object property)
set the variable’s default value
go back to the Widget tab
bind the variable they’ve just created to their widget (I find variable searching UX rather annoying in Tulip’s current release)
When faced with that choice, the user will probably and unconsciously choose to input static values instead because it’s faster and simpler (Tulip helps a lot by showing an interface compatible with the value type and validating the input). But they now have a user work debt! They will have to execute the seven actions I’ve listed above eventually, on top of the work they’ve just done. They will basically input the values twice (once when setting the static value(s), once when creating the variable).
Implementing the feature I’ve suggested won’t save them the work of inputing the values. But they will at least do it only once. It will also spare them the seven actions described above, replacing them with two mouse clicks and a variable name input.
(again, this is not top priority and more of a quality-of-life change to improve UX)
