Which approach will be optimum in repeating group with respect to WUs?

I have a repeating group having main group which consists of around 20 sub groups having text and input fields. And all the input fields are hidden and only be visible on click button “edit”. Which of following approach will be optimum?
1- edit icon on each sub group like 20 edit icon buttons in 20 sub group. On click each icon only the relevant input field will visible and having save button to make change in DB.
2-Main group having 1 edit icon button and in workflow set 20 workflows of(show element) and than on save button to save change in DB.
3-Or use custom states/url parameters to show all the fields in sub groups and save all data in DB.
RIGHT NOW. This app is built on 1 approach and pie chart regading WUs also attached. in just one hour and running 3 to 4 workflows its conumed 137 WUs. :exploding_head:
Thanks in advance.


I’m interesting to hear what your tests show. Please post pics of your pie chart for each of 3 tests you’re going to run.

Thanks for you interest man. But i have no data or pie to show you because this app was built couple of months before this new “Supper Fantasy Pricing Plan”. Now i am curious to which approach will work ? Hope any pro bubbler can answer this.

I think all the pros are busy testing their different approaches…that’s what I’m doing for my client apps and my own apps.

Nobody can tell you what’s best unless they test, everything else is educated guess.

My professional educated guess is that you make all fields visible by default and have one save button that saves all fields.

The basic nature of the field is hidden because its just edit field & only be visible when ones want to make change in the relevant record in DB.
Here is my Pie for approach 1

I understand that…you could always assume client side actions eat no WUs, so do what you want to make them visible or not, then save to custom state, then single save button to save all custom state values, but that might not be what you want to do, so then do edit icon next to each, which will be cluttered, but if we’ll presented could be fine, and run actions to save each individually, which will eat WUs, or use auto binding, but you might not want to do that, but it’s been discussed as a likely approach, but is basically the same as individual saves, which eat WUs, so maybe use URL parameters but user might forget to save like when using custom states… which leads me to say show all and save all with one button click.

1 Like

I developed this app with single field save approach as i had a feedback related to same type of app/software which saves all data on single click and operator have to renter all the data which sucks. And the other scenario as you discussed above if one can forget to save eventually he will lose the updated data.

Users don’t need to RE-enter all data. You’re supposed to have input elements initial content set to what it is in the database. That way, user can see what the value is, and if don’t change it and save, the value stays the same.

This topic was automatically closed after 70 days. New replies are no longer allowed.