Hello,
Will Forms Classic be deprecated at any point in the near future?
Thanks,
Jeff Curtis
Hello,
Will Forms Classic be deprecated at any point in the near future?
Thanks,
Jeff Curtis
Echoing what @████████ said (cuz I said what he heard 😉) there is currently not a plan to deprecate the classic designer, but I highly encourage any new forms be built with the new form designer. We will not be releasing any changes to the classic designer that are not high priority security/functionality items.
I understand that the community is largely more comfortable with the classic designer, but the new designer is easier to push new features to. It is also more performant, and more secure for you and your end users. If there are features you are still missing in the new designer please post in Answers about them because I am very active here and continuously triaging items for my team to work on.
The new designer is a slight change to the mental model when needing to do anything custom, but I have built some highly customized forms with it so I encourage you to try it out. A few of the forms I am building will be showcased at empower so find me there and we can chat!
I'm going to sound like a broken record here, but my organization needs more flexibility in JavaScript before we can even consider making the switch.
Currently, about 80-90% of our mission-critical forms cannot be reproduced in the new designer, even with all the truly great new features that address a lot of things that were commonly done via JavaScript.
It's gotten to a point where we don't start new projects in Forms nearly as much as we used to because we're uneasy about dependence on what is at this point a "legacy" designer.
While I understand the desire to improve performance and provide an easy-to-use API, and I do agree the new designer is in most ways far superior, the change to JavaScript has essentially put a "wall" around process development.
Even if that is expanded with new functionality, if/when we run into that wall we're just stuck and it's exceedingly rare that I can put a project on hold to wait for enhancements that may or may not come.
The biggest challenge is that it's not just about recreating what we've already done, which so far I haven't been able to do, it's about that unknown project down the road that needs something I can't provide out-of-the-box with Forms, especially when it is an uncommon use case that wouldn't have much traction as a feature request in the larger user community.
In the past, I could just get creative with JavaScript to bridge the gap, but with the recent changes I have few options/workarounds; our user base and stakeholders have become accustomed to a certain degree of functionality and customization in Forms that we just cannot provide in the new designer.
I totally understand your sentiment and appreciate the feedback. The "unknown" solution/feature aspect of project development makes our jobs incredibly difficult haha. I have used the classic designer for several years and have built many absolutely crazy custom forms essentially under the guise of you can do literally anything you want. I have a list of features from my own experience and some answers posts of must haves that will enable the new designer to handle as close to unlimited possibilities as I can. I also have another feature set in the works to handle additional use cases that don't quite fit in anywhere else.
The fundamental goal of the new designer is to build out of the box ways to do common things that were scripted in classic designers. My list continues with this strategy while also providing interfaces/documentation surrounding more advanced customization as those possibilities arise. My hope is that the features in the new designer begin to outweigh specific customer requests and lower development costs for building and maintaining forms (like only needing one form for most processes). Then you and your customers can meet a compromise between specific features and services costs.
The main reason we stay with Classic Designer is because of using Google with the Address field.
If we could use Google in the Modern Designer address field, we'd move over completely.
@████████ can you give some examples of what you are doing using JavaScript in the 80-90% of your mission-critical forms that can't be reproduced with the modern designer? While Zac and his team might not be able to address the "unknown" projects, they might be able to review what you are currently doing and possibly work on built-in solutions for a future version.
Also based off of the post below from one of our Consultants and reply from @Zhiyong Deng, the process to use Topaz with Forms is not supported with the Modern Forms designer.
https://answers.laserfiche.com/questions/212856/Forms-11-and-Topaz-Signature-Pad-not-working#212860
Hi Blake,
There was a post a few years back where people were listing off some of the things they were doing via JavaScript, and there were some discussions during Empower that year as well.
New Forms Designer: Common Use Cases for Java - Laserfiche Answers
There's a good number of things that have since been addressed with out-of-the-box features (field rules, LFForm object, etc.), so the list is definitely a lot shorter now, just not quite where we would need it to be to switch.
We went pretty extreme on the customization in some cases so there are some things I wouldn't expect to be "common" use cases.
Some highlights,
One of our biggest processes is/was for public submission of documents; this process was responsible for about 27,000 submissions per month.
We started migrating that process to a different application so it's down to about 7,000 submissions per month now, but it relies heavily on JavaScript:
We have a process for document destruction orders:
We have a process for employee change requests (promotions, transfers, office moves, etc.):
We have a process for updating document statuses (voiding and such):
We have a process for document redactions:
An "availability" questionnaire for the public:
Some common elements I use in multiple forms:
I tried to focus on the more "extreme" stuff because more than a few things in my original post can now be done out-of-the-box with field rules, the LFForm object, etc., so things have come a long way for sure, but still not quite enough for us to transition our "big" processes, either because necessary functionality can't be reproduced, or because our users/stakeholders just refuse to let go of functionality that can't be reproduced.
This is a fantastic list, a lot of these are things I had in mind. Especially cross-window/frame communications either with the web client or another site. I will try to replicate some of these features and use missing items/qol stuff to add to my list.
I really appreciate the detail you put into this post so thank you!
Hi Zachary,
Thank you for all the work you and your team have done. I don't want to be too hard on the new designer because it really is great, and some big leaps have been made since the initial release so it has definitely reached a point where most things can probably be migrated.
My primary role is application development, so I totally understand that a lot of what we do is a bit "fringe" and falls under the ninety-ninety rule; I know all too well how addressing that uncommon stuff usually accounts for a severely disproportionate amount of development effort haha.
I have to ask, is the user expected to go through 25,000 rows of data before making a decision on the form?
@████████ Fortunately no haha; it's more like the final disposition step in records management. All the items in the list are 100% eligible for destruction based on very specific conditions so the task is more about getting documented approval from top-level leadership (1-2 tasks per month for 1 user).
The process gives them the ability to check boxes to exclude items from the list, in which case they'd be checking for a specific name or some other identifying information that would be known in advance, but so far that option has never actually been utilized.
We implemented a similar final records disposition approval process for a customer on one of my first projects. Though I don't think it had quite that volume of items, it was still in the hundreds to low thousands. The approval form had checkboxes to exclude specific records from disposition. Forms would send the approved list of entries to Workflow to process, and then generate a Certificate of Destruction.
I was on a webinar recently where Laserfiche stated that there are currently no plans to deprecate the Forms Classic designer. That doesn't mean that it will get new features though.
To add to what Zac has already said, we have no current plans to "deprecate" Classic forms and force people to attempt to migrate nearly a decade worth of existing processes to the Modern Designer. That would be an extreme burden across our customer base, requiring many thousands of hours of work in aggregate to deliver little business value.
The Classic designer will, at minimum, continue to receive security updates through regular Forms releases.
While you can expect to see continued emphasis in the Forms UI and marketing materials on the new Designer, new features only going there, etc., that only reflects our desire for people to use it for new projects because it's the focus of our developments efforts going forward. It does not mean that we're imminently pulling the plug on Classic.
As always, we welcome your feedback on any blockers to doing things in the new Designer that you could in Classic because bridging that gap is one of our current main goals.
We are painfully aware of the JavaScript limitations. Zac and the team are working on it