Introduction to Headless Forms

Transcript

Hello everyone, welcome to the session on headless adaptive forms. My name is Rahul Chosain. I lead the engineering team for adaptive forms in the AEM forms team. Today we’ll be discussing how to improve developer velocity to build amazing data capture experiences with headless adaptive form capability. Here’s a brief outline of the session. After a quick overview of AEM forms for folks new to the product, we’ll cover the context and thought process behind the headless adaptive forms development. Then we’ll see the capability in action with some cool demos. Time permitting, we’ll take questions. In meantime, feel free to post your questions in chat as we have product team online to provide the answers. So starting with an introduction on AEM forms, AEM form support user support your customers end to end journey from onboarding all the way to retention. And that’s what differentiates us from our competition. It allows us to create exceptional enrollment experiences using digital forms. These forms are created once and adapt to the digital surface like web mobile automatically. Process users can use drag-drop or three to quickly create and launch these experiences. After form submission, the end users expect to receive a confirmation or notification document about the status. AEM forms allows to create out of the box personalized communications to users and send them at scale. Each form submission requires an organizational process for someone to take an action. These processes can be automated using AEM forms workflow or third-party workflow engines like Microsoft Power Automate to gain further organizational efficiency. Moving on, let’s discuss what challenges an organization faces when digitalizing their forms and documents at scale. So typically organizations start with digitalizing a subset of their paper box and processes with a small team using a do-it-yourself technology they know best. While they can turn around in less time initially, the scope of the project is limited. Also in long term, the original dev team may leave the organization or move internally. This leaves a knowledge gap and thus such point projects become difficult to maintain and expand the scope. AEM forms offers an enterprise solution for organizations to undertake large scale digital transformations with piece of mind for the business users as well as flexibility to the developer teams. Headless Adaptive Forms provides complete flexibility to front-end developers to use their preferred front-end technology of choice while leveraging the richness of AEM forms capabilities to build amazing enrollment experiences for the end users. So how does it work? Business users can use easy drag-drop based authoring using the latest Adaptive Form code components to build the form definition. This definition serves as a single source of truth for web forms as well as adjacent representation for the headless rendition of the form on multiple channels. The headless form JSON is standardized which can be used with React Web, React Native or other front-end technologies. It can be used to embed the form experiences inside a mobile app or even conversational form filling channels like Chatbot. As the original form definition uses AEM forms core component, the form can be easily embedded inside AEM site stage for a seamless content and data experience. This leads to the question, what are Adaptive Form core components and what are their benefits? So Adaptive Form core components are a set of standard based, production ready, easily customizable data capture components. They use AEM core component methodology. This enables existing AEM developers to use and extend them easily without an additional learning curve. These components are available publicly on GitHub and are accessible by default. They are easy to maintain with the version management as well as backward compatible. There is no reliability on third party libraries like jQuery and Underscore. The benefit of creating a form using core component based backdrop authoring is that it automatically generates a compliant JSON for headless form delivery. Front-end developers can simply refer to this JSON to develop the data capture experience as per their organizational requirements. So by now you may want to know how to develop and use the headless forms. Let’s discuss briefly the flow before we move to the demo. So here are a few artifacts that help use Headless Adaptive Forms successfully. First is the Adaptive Form stack, which defines the components of the form, their properties, how to represent business logic of the form, and other things. Next is the AEM Forms authoring UI, which uses core component in a drag drop interface used to build the form definition. This allows developers to generate a compliant JSON representation without having manually to write it as well as maintain it inside the AEM Forms repository. For front-end developers, we will provide a web SDK with several renders and a host of HTTP APIs for form related operations. Finally, to help the development process, we provide the documentation and a storybook for the developers. Now let’s see it all in action. Just give me a minute. I’ll just log into my demo machine. So starting with the demo, I’m starting with the form management UI. It lists down all the forms that are available on your environment. I’m using my cloud sandbox to develop the forms. For this particular demo, I have created an initial form. Let me go and edit it. In the form, I’ll just do a preview and show a brief about the form. We have two tabs. First is the personal information. It’s a contact form. It asks for the first name. Then a preferred mode of communication, email or phone. And a phone number here. If I select email, accordingly, the email information is shown. Going back to the authoring, I realized that, okay, I have the first name, but I missed the last name field. So what I’ll do is I’ll add a text field. I’ll place it according to my requirement below the first name. I’ll give it a good name to start with. I want to make this field as mandatory. And if someone does not provide the mandate, he should get a business error message. So I’ll write the last name. Enter. So I have a new field. Last name. Now, I want to add some dynamic behavior to the form. So I can use the rule editor. So the rule editor allows us to introduce dynamicity in the form. It allows a lot of custom functions, out of the box functions that can be used to introduce the dynamic behavior. So what I do is I create a rule which says that, show the phone number field when the preferred channel contains the string phone. So the two options that we were seeing, email and phone, those were coming from the radio button options. So the field is shown when the preferred channel has phone selected, otherwise it is hidden. I’ll save this. I’ll close the rule editor. And now if I do a preview. I fill the name. Currently, it does not show any additional field apart from the additional comments. I select email and I have the email field. Similarly, I select phone and I have the phone number field. So what we saw right now was authoring using the core component based authoring using a drag drop feature as well as rules using the visual rule editor. The rendition that we are seeing that’s a web rendition, but how do we get the head full rendition, the season for the form? So for this, we provide a set of fresh APIs, open APIs. So what I’m doing is on the form on my sandbox environment, I’m calling the API Adobe forms is lift box. So this is the list forms API. It lists the forms which are available on the environment. I was working on the contactors form. So I’ll copy the ID for this. And I call the get form API. The get form API takes the ID of the form and you get adjacent. The if model definition is the form definition that is available that is required for headless rendition. Now moving on to the headless rendition part of it. So I have my code editor open. So in this, I created a simple reactor application and using the AF reactor that is part of the SDK that we provide. We are getting a competent adaptive form. It takes input as mappings and a form station. Form station is the one that we just saw. So I am fetching the JSON from this URL and passing it to the form station, the adaptive form, if model definition part of it. The mapping is something special, which helps us map our core components to the react components that you have. So here I am starting with vanilla components. So these vanilla components are using the same name structure as the code components. And we provide these components as a reference to start with. So in this mapping, what I’m doing is based on the various field types, I’m mapping the components which are defined in this project. And accordingly, I can go back to the app. So I’m starting with the vanilla component here. And for the theme part, I’m using the same theme that we were seeing in the core component rendition. I just did an NPM brand start on this project. And now if I see the form, I can see a similar rendition in a react application. If you see, I have the same fields, the contact information does not have any additional field. But if I select email, I can see the email field. So all the rules are also executing successfully on the react rendition. Now I go back to the code. So not everyone would be using the same components. So for this demo, what I’m doing is I have created another component library based on material UN. So I tried to switch the rendition to the material UI. And for this, I do not want to use the theme that we were using for the weekend theme. So it is possible that we may have a different rendition for the head full rendition, the web rendition that we have, but a totally different rendition on the react side of it. So I just committed the weekend theme part of it. And now if I build it, oops, yeah. So now I have a material UI rendition for it. All the rules work seamlessly. I do not see the fields here. But as soon as I select these values, I have the email and full number fields available. So that was the first demo that I wanted to show where we are altering the form using core components. We are able to fetch the JSON that can be used inside a react application. And the react application can be easily modified to render based on your component library. Now, moving on to the next demo. In this demo, I want to showcase how the multi user journey, how a multi channel user journey can be achieved using a headless adaptive form. For this part, I’ll be showcasing a proof of consent that we did some time back. And I’ll be using a recording for that. So in this, we have a user who is accessing an application, and he wants to apply for a loan. He would provide the required cell number and the credit card number. And then using the visual rule editor, we would be invoking a race service to generate an OTP pin. That’s the business logic part of the form definition. And once the OTP is verified, he can choose the additional, he can fill the additional information. So the user provides the mobile number. He provides the four digit credit card number and then receives an OTP. After filling the OTP, he’s authenticated and he chooses the loan amount and the duration. But at this time, he feels for some reason, he decides to sign out. He’s not filling the remaining of the form fields, which are providing the bank information and the account details, but he has already filled the EMI part and the loan amount. So what happens is this information is sent to the backend and the bank can accordingly decide to retarget. So the bank is using a WhatsApp channel to send a message that whether the user wants to resume the instance loan application. So the user responses, yes. So the thing to note here is he’s not being asked the initial loan amount and the duration. He is being asked the subsequent fields in the form. So we are doing a pre-fill of the form and continuing from the existing state of the form fill. Again, so resuming from there. So we have a validation of 10 digits on that account number, but here the user provided nine digits. So what we can see here is the form validation message that had been added to the form definition, it can be leveraged even on the WhatsApp channel. The user is again asked for the account number, then a confirmation. And after filling the IFSC code, he’ll be requested for an OTP. So the web service call that was shown in the previous web rendition can be achieved on the WhatsApp as well. Finally the form is submitted and you see the thank you message that was configured on the form. And then a user has an option to see the submitted data. So in this demo, we saw that within the same form interaction, user can actually switch from one channel to another. And using retargeting, business users can easily target these forms. So here are some helpful resources for your reference. And with that, a big thank you for attending the session and we are open for questions. Thank you everyone.