Dynamically generated inputs

Owned by Lite Farm
Last updated: Jul 22, 2020
4 min read

The design for LiteFarm is all about accessibility. We are striving at every point to create the easiest interaction possible for farmers using the app. A big part of this is limiting the amount of information we ask users to input to exactly what they are hoping to get out of the system. This also applies to the number of input fields that are required.

For every single required input field, there needs to be a reason it is required.

However, many of the strongest incentives to use LiteFarm come from what the user can do with the data they generate in LiteFarm. For example, being able to manage my farm in LiteFarm and use the data I input to get an organic certification is a huge draw. In this situation, we need to be able to gather this additional data (over a farmer not interested in getting an organic certification). Supporting both of these users is a big part of our to meet farmers where they are. One example, is the amount of information needed to add a new type of fertilizer to inventory:

We can see from the highlighted fields, that there are modifications to both the fields that are visible and those that are required for input based on whether a user has opted to use “vanilla” LiteFarm or is seeking an organic certification through COABC. That is, the inputs to this flow are dynamically generated based on the choices a specific farmer has made during on-boarding. These choices may influence every single flow a user interacts with.

Architectural Considerations

It’s important to note that this pattern will repeat, and must be extensible. For example, 10 different organic certifying bodies will likely have 10 different schemes for the data they collect. In the case of organic certifications, it’s unlikely a farmer will require two certifications that will dynamically update a form. Instead, the right certification will be inferred based on their geolocation. However, it is perfectly likely a farmer will have several different “modules” that modify the inputs and required inputs for flows. For example, they may be interested in “seed-to-sale”, “planning”, and “workforce management” modules - each of which could introduce new visible and required inputs to vanilla flows. The system needs to be able to handle these potentially overlapping influences and generate a form that is a superset of the visible and required inputs.

Use Case - Organic Certification through COABC

LiteFarm is currently creating a data push to COABC's (Certified Organic Associations of British Columbia) iCertify system. iCertify accepts somewhere between 3 and 50 csv's from an organic or would-be organic farmer in order to verify they meet the provincial standards to be considered organic. The number of csv's the farmer needs to populate depends on the complexity of their farming operation. Our process for mapping data from LiteFarm to iCertify has roughly taken the following pathway (and is definitely still a work in progress!):

  1. Understand the forms and data fields for each iCertify form, as well as the criteria to determine if an organic farmer needs to fill out a specific form.

2. Map each form or group of forms to a question or action that can either be asked to users during on-boarding, e.g. "Are you interested in becoming organic certified?” and “Do you use inputs/products on your crops?" or which can be determined in app based on user inputs, e.g. indicating an interest in becoming organic certified during on-boarding and clicking “Create fertilizing log” at a later time.

3. Based on inputs and supporting information (e.g. geospatial coordinates to determine the farm lies with COABC jurisdiction), determine which records LiteFarm needs to generate as an export. For example, a farmer wishing to become organic certified that uses inputs on their crops must gather inputs for record “I - Crop”.

4. Map these form inputs to specific flows within the application.

5. Augment the flow to include required inputs as visible and required inputs in LiteFarm. Make sure to define visibility and requiredness for both the base case (e.g. “vanilla LiteFarm”) and the COABC case*. Where no flow exists to gather the required inputs, or the inputs are not collected in the correct format, update the flow or create a new flow within the application to support the collection of the required data.

6. For purposes of exporting the COABC data, create a controller that queries data from each source table and create de-normalized data structures that matches the COABC output forms. The de-normalized data should be exported as csv’s, packaged into a zip file, and emailed to the user. The user triggers this action by clicking “Export my COABC forms” in app.

* When generating an input field for a user, the system must dynamically display or dynamically require inputs for specific fields based on what the user needs to get out of LiteFarm.