Hey folks, I have a page that has a couple of forms on it. Meaning, a number of questions tied to a submit button. When that submit button is clicked, the next form becomes visible.
I have created groups around forms and inputs and buttons to help better structure and organize the page.
My issue is that the “input should not be empty” isn’t being adhered to properly, so the button workflow is just running even when these input elements are empty.
The way I have things grouped today looks like this:
On the same page, I repeat this for “form 2”, etc.
Is there an issue with where my inputs and button are located w/in groups? They’re all under the “form 1” group, which I thought would work.
If I’ve done this wrong, please suggest how I must restructure this to get it to work. Appreciate any help! I’d prefer not to have to do manual validation via conditionals or workflows.
For whatever it’s worth, this is what a “question 1” group looks like:
I’m doing something very similar with multi level forms and grouped buttons etc, so it’s certainly possible.
What exactly are your buttons doing? What do their workflows look like?
If you don’t want the buttons to submit the forms (and move onto the next), I assume you must have some conditions set up on the workflows for those buttons, and I assume you’re not using auto-binding?
In order to make use of the Input Should Not be Empty function and have it result in a workflow not proceeding in the event the Input is empty, that Input’s Value needs to be part of a workflow action within the series of actions, if it is not, the workflow will run.
What this means, is you should have a workflow action that will save the values to the DB…I’m not 100% sure if set a custom state using the inputs value works the same way or not, but probably.
You’ve shared some interesting thoughts here. I think what I’ve learned here is that the workflows themselves help define whether the button will actually trigger the workflow. I was under the impression this was based on UI placement of buttons/elements.
That said, the workflows aren’t doing anything other than visibility work. I am using auto-binding, which might explain the entire problem.
I’d still like to use auto-binding, while controlling visibility with the buttons, while still managing whether or not the user is allowed to continue based on required inputs. I’ll experiment w/ the setting a state idea. If there are any other thoughts on how to perform a workflow action (outside of writing to the DB again) that would control the button activity and highlight the inputs in a clean way I’m all ears.
One, I would not find it necessary to use autobinding and custom states in tandem as it seems you are based on the below quote.
Another reason not to use autobinding is that it may cost more in WUs than simply saving the value to a custom state and at the end of the form saving all values to the DB via the custom state values…however, there may be reasons I am unaware of for your choice of autobinding.
Don’t control the visibility of the buttons, control the coloring of the buttons. If a button is not visible, for me personally, I find it a poorer UX than if the button were visible with a color difference indicating it’s disabled state. In my apps I use the style to create a condition for when this button is not clickable to change the background color to a grey color. Then on the button element on the page I put a condition to determine when it is not clickable based on the mandatory values (ie: input values of mandatory fields). That does pose a challenge though, as the button that is not clickable will not cause a mandatory input to show as invalid (ie: must not be empty, when empty is invalid)…so sometimes, I just simply change the color on the element itself, have a second workflow trigger based on conditions of empty field values to ensure I can alert the user to the areas missing information.
There are a lot of different ways to approach these things, and sometimes constraints on the setup of elements (ie: using repeating group versus regular group) causes a need to take one approach over the other.
