Just knowing how different Classic Forms is to Responsive, I would opt for that second approach. Depending on the size and scope of the form in question, it could easily take more than a weekend (especially if you're getting feedback from someone in the company who has to use the new re-design and might not be used to the stark visual change).
Unfortunately I do not know of any tools to make this easier.
@bgarvey Thanks for your post. I was curios to know more about your use case and intended outcome on the Form for users to see if we can look at providing a solution in the next generation technology, New Responsive Form.
I have a SP2019 site where one list has a few thousand entries. Lots of rules used as process guardrails, lots of fields where we use buttons at the top of the form and panels to act as pagination. The form also acts as a launching point to load documents into various doc libraries, bringing in metadata via URL parameters to the receiving form. For speed to market, we used responsive designer, even though no field users or iOS users are involved.
Over the time, the process has been revamped so many times, that many rules have been come unnecessary, or fields removed that were in rules, etc.. After documenting the process and gathering requirements, we decided to create a new form v 2.0, and leverage classic designer to pick up things like:
- embedding filter list views of related doc libraries
- JS buttons
- pagination
- minor jQuery actions to set field values on the fly
- other minor items that are classic only
Currently we have copied the site down to QA, will confirm all matching guids etc, and start with a fresh form there. Our workflows are also a mess, with about 15 firing on every change. We intend to combine as much as reasonable, keeping individual functions as Manual only for cases where a wf gets hung. We would love to use more conditional wf's, but they seem to bog the form down on Save.
Unfortunately, we are stuck on prem for now, as our work has federal compliance regulations wrapped up in the data portion. Thanks for the interest, let me know if you have any other questions!
Thank you @bgarvey , appreciate the details and understand having to stay on-prem due to federal compliance. Would you be able to possibly provide any screenshots of the following with confidential data crossed out:
- Lots of fields where we use buttons at the top of the form (are these also referred to as "JS buttons"?)
- Panels to act as pagination
- The form also acts as a launching point to load documents into various doc libraries, bringing in metadata via URL parameters to the receiving form. (is this the same as "embedding filter list views of related doc libraries")
- Minor jQuery actions to set field values on the fly
And please do not feel obligated to take any further action, as I am only trying to learn more about customer use cases, see the form elements and intended outcomes. Thank you
@bgarvey And the learning is also intended for improvements in our next generation forms platform to accommodate your use cases.
