FORMS DESIGNER

The forms designer is among the core functionalities of the applications as it the one that spits out all what will appear on the mobile client and further it specifies how the data will be collected. The management, design, tweaking and organizing of questionnaires is accomplished by the functionality contained herein.

The tabs that are contained in the design tab are as follows:

Study – Design – Properties TAB

This tab mimics that earlier properties tab in functionality only that it lists the properties of the questions on a given form.

Some of the properties are optional where as others are mandatory. Important to note is that some options are automatically put by the designer in order for the user not to miss them. It is advisable to avoid editing default values put by the designers because this can put the whole form in an unstable state.

The properties are explained below:

• Text: This property specifies the text that the question will have. It can be appended with a question mark at the end to show that it is a question. This question mark is for aesthetic reasons on the mobile client. An example of a text property can be; what is your first name? This property is mandatory.
• Help Text: This property specifies the optional help text that will appear on the question on the mobile device. E.g. User’s first name. This property is optional.
• Type: The type of question. It can be Boolean, text or any other question type that is specified in the drop down list bound to this property. This property is mandatory.
• Binding: This property is the database name used to identify this item. It’s the identifier for the question that has value which is persisted in the data after data has been collected.

Important to note is that the binding is context specific. If it’s the study, then the binding becomes the identifier in the database and if it’s a Form, then the binding becomes the identifier in the database for the form. Same applies for the form version.

Example: Say last name, its binding in the database (table column) will be lastname

• Visible: This property specifies if a question will be visible or not both on the client and on the server. When you set this property to true, when the form opens, the question will be hidden. Also, when you download this form onto the mobile device, this particular question will not be visible to whoever is collecting data. This property is optional.
• Enabled: This property is specified if you want a question to be enabled as default or disabled as default. A disabled question will not be used to collect data. It is optional.
• Locked: If you want a question to be visible but not available for editing on the server and the client. This property is optional.
• Required: A question specified as required becomes mandatory i.e. it must be answered before a submission is made from the client to the server.
• Default value: This will specify the default value for a question. If no answer is provided, the default will be provided. Note that when the question loads, the default value will be specified in the answer field.
• Calculation This is only for those fields whose values are a result of some computation. For instance if we had three fields: Weight1, Weight2, Weight3. Where Weight3 = Weight2 - Weight1. Then the calculation property would be only for the Weight3 field and would be: /form/weight2 - /form/weight1. You can use the "add field" link on the right hand side which lets you select a form field and it inserts the xpath expression for each field.
• Description template: A combination of optional fields and text to describe a collected set of data. Any example would be where you have used a specific form version to collect over one thousand records, description templates can be used to identify each instance of collected data independently.

Down the properties tab there is a utility tab that is used to set more properties on the form being designed.

The tabs down are:

• Skip Logic tab
• Validation logic tab
• Dynamic lists tab

Study – Design – Properties - Skip Logic Tab

This tab is used to set skip logic on a specific question on the form. If you want the next question or previous question to have a value in relation to the current value in the current question, then this tab can provide the functionality to do that.

You can enable, disable, hide or show, make a question mandatory depending on a preceding value or past expression.

An example would be: 1. what is your gender? 2. Are you pregnant?

If male, then the next question (2) should not be asked.

Study – Design – Properties - Validation Logic Tab

This tab is used to specify the error message to be displayed when a particular condition fails. The error message tab specifies that text to be displayed on both the mobile device and the server when a particular set condition is not satisfied. E.g. if age < 18.

Study – Design – Properties - Dynamic List Tab

This tab is meant to specify a list of values to display based on a value. An example would be if continent = Africa, display only a list of countries from the African continent.

Study – Design – Xforms Source TAB

This tab will display the underlying xforms source code associated with the currently selected form version. A technical person can edit the xform instead of using widgets to design a form or study but this requires high technical expertise.

Study – Design – Design TAB

This is the graphical user interface equivalent of the above tab. Instead of editing the xform source directly, a user can decide to drag widgets on the design form to create a visually appealing layout. The underlying xform will still be generated by the designer but this tab is meant to make it easy to design forms and easily deploy them to the server.

Study – Design – Layout XML TAB

This tab contains the layout xml source that defines the layout structure of the widgets of a particular form during editing in the browser. When data is returned, it’s this layout that is used by the application to correctly align and visually lay out widgets in a way that is aesthetically appealing. This layout is not used by the mobile device.

Study – Design – Preview TAB

After designing the form in the design mode, this tab is used to see how it will look in the browser. It’s meant to give the designer a rough idea of how the form will layout on a particular browser of choice.

This preview is not used on the mobile device. It’s not guaranteed that they way it looks here is the same way it looks on the device but the difference is small. But it can be used to test things like skip logic, validation logic and the like.

Study – Design – Model XML TAB

This tab contains the xml that is actually submitted to the server by the client. If the designer wants to know how the submitted xml will look like, this is a correct place to look. It mimics the xml that will contain the data coming from th

Study – Design – JavaScript TAB

This is where you put JavaScript to do whatever the form designer does not do for you. This could be some complicated skip logic, validation logic, or anything else that you feel can do in JavaScript. Each widget has a property called "ID", as you can see it from the widget properties tab, which you can assign a value and be able to reference the widget from JavaScript using functions like "document.getElementById("id")". The JavaScript is saved together with the form and will always be executed when running the form both in the preview mode and when doing the real form data entry.