Identifying Forms

When it comes to understanding extension, we find that while people pick up the theory behind what a extension does and understand its basic concept, they have difficulty then identifying how that extension could be applied to their own application. The goal of this article is to help you take that next step, focusing on identifying the Forms extension.

It’s important that before you go into this, you have already familiarised yourself with the extension. This means that you have an understanding of what it is capable of, but also what it is limited by. For developers, this also means having a technical understanding of how it functions so that you can make judgement calls with as few assumptions as you can manage.

About Forms

A large majority of the content we have written about the Forms extension is in this Forms extension overview. While you most likely have already looked at it, if you have not, make sure you have a thorough read.

The focus of this article lies on the information written in the section at the top, where we have written about what the Forms extension does well and what it is ill-suited to. These points are an excellent place to start at when analysing your application for potential extension use. Make sure you remember these points before you begin.

For techies, we also recommend that you become familiar with the technical aspects of the extension, and have a play and explore so that you know the limitations of what the code can and cannot do.

Identifying a Potential Form

Identifying a potential use for Forms is easy; if you need to capture information from a user using some sort of textfield or input, then you will probably need some sort of form. The difficulty with the identification is not knowing when to use a form, but rather how it should be implemented.

Is it a Form, or is it a CRUD view?

The issue with forms is it can sometimes be hard to distinguish between what could be a Form submission, and what could be a CRUD create view. A lot of people who are new to the extensions, and even some experienced people, get confused about which should be used in what scenarios. When you introduce the concept of custom code, the lines blur even further when it comes to what can be done with them. Outlined below are a few keys points which you should consider:

Data Type

The confusion between the two is that they are both used to capture data. The difference between them is the type of data which is being captured; the CRUD create view focuses on only capturing structured data, specifically, another entry in the entity which the CRUD is related to (i.e. adding another fish into your database). Forms is more suited to capturing arbitrary data, and focuses more on just capturing the information rather than working with it. Since the questions, and therefore data structure, of the form can change over time, it is unstructured data.

Working with the Data

The downside of using Forms is that due to the lack of structured data, it is harder to use the data which you capture elsewhere in your app. When you use CRUD to capture data, it is stored directly into the database and is able to be manipulated just like any other piece of data. If it is suitable for you to use it, CRUD can be much more simple to work with from a custom development point of view.

If you need to make a form where you will need to take the data which is captured and then use it to do something else (i.e. make a new fish and store it in the database), then you will need to use custom code to make sure you can work with it easily. This is due to the fact that, since forms can have versions and the questions can change, they are not saved in the same way that other data is. You can use custom code to manipulate the data and save it in the database properly, though if you ever change the questions then it may break the code you wrote.

Configuring the form

The third key difference is how they are configured: CRUD is configured on the Platform, whereas the forms are configured within the app itself, meaning that you can make changes to it without releasing.

When you are work with CRUD, it will display a field for every attribute that is in the entity it is assigned to. While this can be a good thing, since you wouldn’t need to go and edit the form if you wanted to capture extra data, it can also be a negative if you have attributes that you don’t want to be displayed to your users. Since it is configured on the Platform, it also means that if you want to make a change, you will need to go through the whole release process to make the changes live.

On the other hand, if you use Forms you are able to edit them inside your target application as required, without needing to do any sort of releasing. You can put in whatever questions you require without much fuss.

So when it comes to making the choice based on configuration, ask yourself the following: “How often am I going to need to change this form, and who is going to need to be doing the changing?”. If it is only going to be very rarely and you are happy to release when it needs to happen, and you have no issues with relying on a developer to make the change, then CRUD would suit (at least for this aspect). However, if you think the form will need to be able to be changed on a semi-regular basis, or by someone who is not comfortable with the Platform, then Forms will be more appropriate.

Versioning / Submission History

Due to the nature of CRUD, there is no versioning or edit log which is available against the “form” which was used. There is no way of seeing what the CRUD form looked like when it was initially filled out, and if you ever try to edit the entry, then you may find that you have lost data, or now have extra fields to fill out.

Alternatively, Forms uses versions to ensure that once a submission has been completed, it can stay in that state even if you create a different version of the form. It also has the additional bonus of letting you create drafts and choose when your changes go live.

Displaying the Questions

Using CRUD means that you don’t have a lot of control over how the questions are displayed (unless you use custom code of course). The name of the attribute is what is displayed as the field’s label, so if you want an actual question, you will need to name the attribute something like “how did you hear about us?”, which isn’t a very good practice.

Making a Decision

When it comes to making a decision, consider all of the aspects outlined above and weigh up the pros and cons. If it seems pretty even, consider the future; are any of the scenarios you considered above likely to change once the app has been released out into the world? What are the chances that the questions are going to need to change in the future? Since it isn’t clearcut, you will have to make a decision at some point. If you are truely stuck, reach out to your development team members or Codebots for guidance.

Examples of Forms

The following list provides examples of forms used in day-to-day life, along with a high-level explanation of how they could be used on the Codebots Platform.

Contact Form / Newsletter Signup

The contact form is one of the most basic forms that almost every website has. It would be fairly easy to build this form in your application and if all you want to do is capture the data and then handle it yourself, you could use forms right out of the box.

Ideally, you would probably have some minor customisation to do some more things like:

• send you an email to notify you that a submission has been made
• an auto reply email to the person who filled out the form
• a connection with your email management API to subscribe them to your service
• add some validation against the email field to ensure that it is a legitimate address.

Survey Monkey / Google Forms / Online Form Builders

The Forms extension was initially designed for surveys, which means you can use Forms to create an awesome range of different surveys. You will find the experience will be similar to the traditional survey builders found online; you can choose from a range of question tiles to drop onto the form, shuffle them around, and create drafts which are published as live versions.

After a form has been submitted, you can review the submissions in your application’s backend and do with them what you will. Again, you may find it beneficial to do some customisation to alert you when data is submitted so you can review the results, or to respond to the user who filled it out.

Daily Reports

One of the awesome things you can do with the forms is to create a form or document which can be filled out on a regular basis. Consider a daily huddle which happens every morning; before the team can begin work for the day, they must first complete the meeting and log their notes in the system. In this scenario, you could have a form which is filled out each morning in the app. The submissions are stored in the system and could be accessed easily if required.

Say the boss comes along and asks for an additional question to be added into the agenda. It is simple enough process to add a new question into the form and publish a new version. Now all the new notes will have the new field available, but the previous submissions are still in the same format they were when they were created.