Instructions

android

Introduction

Creating a project

Form Builder

Adding a Form
          Key Field
          Title

Text Fields
          Plain

          Numeric
          Date
          Time
          Drop-Down
          Radio 
            Check Boxes
          
Media Fields
           Location

           Photo
           Video
           Audio
           barcode

Validation
           Text
           RegEx   
           Double Entry

Form Logic
           Jumps


Linking Forms
           Hierarchy

           Branching

android


Installing EpiCollect+
Loading a Project


Collecting Data

Text Fields
          Plain

          Numeric
          Date
          Time
          Drop-Down
          Radio
             Check Boxes

Media Fields
           Location

           Photo
           Video
           Audio
           barcode

Saving Data

List/Sync data

Maps

Backing up data

Remote Data

Settings

android


Project Website

Map View

Multiple Forms

Downloading Data

android


Introduction

EpiCollect Markup

The Document
           <model>

The Form
           <form>


Text Fields
           <input>

          <select>
           <select1>
          <radio>
Setting defaults

Media Fields
           <location>
           <photo>
           <video>
           <audio>
           <barcode>

Defining keys

Form Logic
           Jumps


Linking Forms
           Hierarchy
           Branching
  
Validating



From one to many linked forms

The ability to define any number of text and or media fields, in combination with logic such as skip patterns and validation methods, provides a flexible framework for describing a single form for a data gathering project.

However, a single form may not be adequate for the kind of project you wish to undertake, and therefore we provide the ability to link multiple forms together within a single project in two ways; in a hierarchy and branching.


Linking forms in a hierarchy

Forms can be linked together in a hierarchical fashion allowing data gathering to occur in a 'one to many' fashion down the hierarchy. A single field within each form (termed a unique key) is used to link forms within the hierarchy. To illustrate this, we will expand our hypothetical project surveying schools to also survey the teachers and their pupils within each school..

For a school, we have defined a single form, and for each teacher we wish to define a different form (containing teacher specific questions) and similarly for pupils we wish to define a different form (with pupil specific questions).

We now therefore have three forms One to capture details about a school (Form A), one to capture details about a teacher (Form B) and, finally, a third form to capture details about a pupil (form C). 

linkforms

Figure1A. Within our schools project, three forms have been designed and are linked together as follows:-

 

Form A (details about a school)
|
Form B (details about a teacher)
|
Form C (details about a pupil)

Figure 1B. This hierarchy is top to bottom and allows data gathering in a 'one to many' fashion. For example, each Form A entry (a school) can have many Form B entries (each teacher in the school), which in turn can have many Form C entries (each pupil of each teacher in the school) etc..

Linking forms together requires referencing questions between levels in the hierarchy, using a forms number and key="" attribute.

 

Each form in the hierarchy is linked to the one above using a forms unique key.   For example, for each school (Form A) a school ID can be defined which is unique to that school.  When assigning a teacher form (Form B) the school ID is included in the teacher form thus preserving the link. Similarly,  each pupil form (Form C) contains a teacher ID, which links back up to the school form.   Further levels in the hierarchy can be added, for example, adding blood and urine sample forms for each pupil. This kind of linked hierarchy provides the means for much richer data collection than possible with a single form project and makes EpiCollect+ a versatile tool for many types of data collection project .

In our demonstration schools project we define our forms to simply record the names of schools, teachers and pupils andhave three simple forms which contain a 'what is the name' question.

For each form we specify a num="" attribute which specifies the order of the hierarchy and we must also specify a key="" attribute, as previously, which defines which field must be unique in all entries (see defining keys)

 

<form num="1" name="School" key="SchoolID">

	<input ref="SchoolID" title="true">
	   
	   <label>what is the school's name?</label>

	</input>

</form>

<form num="2" name="Teacher" key="TeacherID">

	<input ref="TeacherID" title="true">
	
	   <label>what is the teacher's name?</label>
	
	</input>

</form>

<form num="3" name="Pupil" key="PupilID">

	<input ref="PupilID" title="true">
	
	   <label>what is the pupils's name?</label>
	
	</input>

</form>

Note: We have set the title="true" attribute on each of the key fields for each table - Remember, this is what is shown to you when you list or view entries on the mobile device see here

In the example above, the key for the School form is set as the Schoolname input, in the Teacher form the key is set as the Teachername input, and in the Pupil Form the key is set as the Pupilname input.

This means that all School names must be unique (and a user will be warned should they attempt to create a new entry with the same School name as an existing entry). All Teacher names for a particular school must also be unique and all pupil names for a particular teacher must be unique.

The forms are listed in the order they appear in the hierarchy, meaning that many teacher entries can be added for each school entry and many pupil entries can be entered for a particular teacher.

 

Linking is inferred by the inclusion of the KEY field from the table above

The key field from the form above in the hierarchy MUST be included in the form below. So, in the example below, the Schoolname key from the School form is included in the teacher form. Likewise, the teachername key from the teacher form is included in the pupil form.

These fields will be displayed, and the value shown to the user. However, should you wish to 'hide' the linking key field you can do so by including the 'display="false" attribute in the corresponding form:

 

Explicitly displaying your linking key fields

<form name="School" key="Schoolname">

	  <input ref="Schoolname" title="true">
	   
	     <label>what is the school's name?</label>

	  </input>

</form>

<form name="Teacher" key="Teachername">

   <input ref="Schoolname">
	   
	     <label>school name</label>

   </input>

    <input ref="Teachername" title="true">
	
	     <label>what is the teacher's name?</label>
	
	   </input>

</form>

<form  name="Pupil" key="Pupilname">

    <input ref="Teachername">
	
	      <label>teacher's name</label>
	
	   </input>
<input ref="Pupilname" title="true"> <label>what is the pupils's name?</label> </input> </form>

You can see that we have included the linking key from the table above in the hierarchy and this will be displayed to the user within their form.

These relationships can be visualised as follows:

forms_simple

By defining the linkage key in the form below in the hierarchy, every teacher you enter is linked to the relevant school and every pupil you enter is linked to a teacher and ultimately to a school.

In the example above, a user adding a teacher will be presented onscreen with the School name that the teacher has been assigned to as the first question - The School name will be filled in automatically as in the following screenshots.

The flow of data entry for this three table example is as follows::

 

 

2

The initial view lists the forms within your hierarchy. Tapping takes you to the menu for that particular form.

 

In this example, we tap on School which takes us to the School Form menu

     
ard        
To add a School entry, tap 'Add'   This is the School Form 'key' we defined above   To store the School entry tap 'Store'
3

 

 

 

arrow

4

 

 

 

arrow

5
  ard   ard
We can now add another School or We can add a teacher to this School
6
 
7
To add a Teacher entry, tap 'Add'   Note: the School Form Key is included   This is the Teacher Form 'key' we defined above   To store the Teacher entry tap 'Store'
8

 

 

 

arrow

9

 

 

 

arrow

10

 

 

 

arrow

11
            ard
 
12
  After storing, we can either add another teacher for this school or go back and select a different school to add further teacher forms to.

The same flow in steps is present for the Pupil Table underneath.

 

 

 

Next | Branching Forms