Setting Form Properties
One of the first and last steps in creating an e-Form is to view and adjust the forms properties, through the ‘Form Properties’ Tab in the ‘Field Element Panel’. Clicking the ‘Show’ Link will open the forms properties in the ‘Element Properties Panel’ on the right side of the interface. This section allows the form administrator/creator to modify the properties of the form.
From here the form name and description can be changed. Workflow can be assigned and a range of other properties can be controlled such the forms buttons, permissions, and submission processes.
The image below shows a section of the Form Properties window along with a description for each property. The rest of the properties are shown on the following page.
Workflow can be attached to a form by selecting the available process from the list. The workflow will be triggered every time the form is submitted using this form as the form-start property for the workflow.
Only the starting form of a workflow process needs to have the process assigned in this manner. Every other form in the workflow does not need to have the process assigned. Assigning a process to another form in a workflow will cause that form to trigger a new workflow instance on each submission. Using this method a process can be used to trigger other processes by assigning the appropriate workflow to the right form.
Forms completed using MobiTask will also trigger workflow in the same manner as those on the web. Any form in the workflow can be completed from the mobile client. When the device is synchronized all tasks assigned to that user will also be synchronized to the device. There are limitations however, since the functionality of the mobile client is not the same as that of a web browser, the form needs to be designed with mobile use in mind.
Save as a Draft is a feature that can be enabled by administrators for forms that may not be able to be completed in one shot. Some forms may be length, others may require multiple days to complete and other yet may be complex and require the filler to take other actions while filling the form. In any of these cases the user may need the ability to save the work they have done and return to it at a later time. Enabling the property allows users to save the work for completion at a later time. Only the user that saves the form can return to continue working on it. Administrators can also enforce a minimum dataset to be completed prior to saving the draft or allow the user to save at any time.
The Save as Draft property is really only meant for web browser use. The mobile client supports a save function for all forms regardless of whether or not this property has been checked by the form designer. There is no way to enable/disable this function on the mobile client dynamically. Mobile users can press ‘Save’ on their devices at any time while filling out a form and come back to it later.
eXFORMA has the unique ability to generate database tables automatically based on a forms definition. By checking this property, eXFORMA will take every collection field on the form and generate a table in its database. Generated tables follow the naming convention f_(formId)_(formVersion)_sub. Each field will become a column in the table using the reference as the column name with the prefix ‘gx_’. Every submission against this form will then be recorded in this table as a record.
There are some conditions to using submission tables. Because the system uses the field reference value to generate the column names every field on the form must be referenced. The system will also not accept the default sys_ref/id1 references, so each field must have its own unique custom reference.
eXFORMA can automatically generate PDF or HTML versions of each submission and store them within its file structure (eforma_home/upload by default). With this property administrators can choose to generate a PDF or HTML view for each submission, store it on the system or even use it as an attachment in an email notification/confirmation. For PDFs the designer would need to upload a PDF template which the system can use to populate the data with. The system will use the submissionId as a default naming reference unless otherwise provided. For HTML generation, no template is necessary.
Submission Page Controls
Administrators can control the behaviour their forms with submission page controls. They can set the properties for which pages to display, which buttons to display on each page as well as customize the labels and behaviour of each button. There are three pages; the form, preview page and competed page, each with their own set of customizations.
The Preview page has some additional configurations available. Administrators can choose whether they wish to even display it at all, or provide customized messages. Of course then can also modify the buttons on the preview page by clicking ‘Set Buttons’.
Finally there is the Completed page. This acts as a confirmation page to the user that the submission has been completed. Again the form designer/administrator can choose whether or not they want to even show this screen, or if they want to show it without values or modify the text to provide their own custom message. There is also a single ‘Back’ button which can customized in the ‘Set Buttons’ interface.
It should be noted that these page controls or set button functions apply only to web browsing and have no effect on the behaviour of the forms in MobiTask.
When a form designer creates a multipage form they have the option of setting page names and links on the form to make navigation easier for the user. On the web in addition to next and previous buttons at the bottom of the form used to navigate between pages, the system can provide direct links to the pages themselves. The administrator can choose to put the links at the top of the form, at the bottom or in both places. The labels for the links can be customized through the ‘Set Page Names’.
Below is an image showing how page names would appear on a web form.
Page names also work in MobiTask in a similar way. Here is a sample of a 4 page form, where the page names were simply Page 1, Page 2, Page 3 and Page 4. MobiTask by default also displays the next and previous buttons for all pages, as well as a counter which displays the current page number and the total number of pages. In this case we’re looking at page 1 of 4, and the page name is Page 1.
Field Control Panel
Let us highlight some key points to remember when creating an e-Form:
- All of a forms fields and content are organized on the form in tables
- Each table consists of any number of columns and rows
- The number of columns is based on how many elements are on the same row
- The number of rows is based on how many row check boxes are checked for that table
- Tables are rendered by the browser!
- Control the appearance of a form through the effective use of the ‘Space’ element type
- Therefore how they appear depends on the browser settings like size of the font and width of the browser window, and as such vary from browser to browser
- Clicking on ‘Preview’ and then on the ‘Show Grid’ button from the preview screen allows the designer to see each table and row separately in a grid like structure.
Field Property Panels
Each ‘HTML Element’ has a corresponding set of properties. Selecting an element in the ‘Field Control Panel’ displays the set of ‘Element Properties’ for that specific element type in the panel on the right. The form designer can then modify the individual properties of each specific element.
These properties tend to be organized to three distinct sections which appear on most HTML elements; Label Properties, HTML Element Properties, and Other Properties.
There are many common properties between elements and then there are properties which are unique to each specific element. Some of the more common properties tend to be Label Properties, since most HTML Elements have labels.
Consider any of the screens we have already encountered, like the one pictured below, they are comprised largely of HTML Elements consisting of a Label and HTML Properties. Below there are three clearly visible textfields, with the Labels Name:, Description: and Search: each followed by its corresponding field to input text, each of which has its own element properties that can be customized.
Let us look at some of the more common properties.
Invisible: The label text will not appear on the form next to (or on top of) the element.
Font Size and Face: Select the desired size and style from the pulldown menus for the particular element. Note these properties only apply to the label of the element not the actual object.
Alignment: Choose to align the label text within its cell space. Labels can be left aligned, right aligned, centered or justified.
Text Color: Select the colour by using the choose link and then picking from the colour palette available or by inputting the hexcolour (hex triplet) code into the space provided. The hexcolour code is the hexadecimal colour code created by concatenating of the three hexadecimal digits together from the decimal equivalents of the red, green, and blue values of the colour. (Example: #FFFFFF, #000000, #006699, #DEE3EF, etc.)
Text Style: Select whether you want the text to be bold, italic, or underlined, or any of the combination of the three. Again this applies strictly to the label of the element.
The text color and text style are both transferable to MobiTask, as is the invisible property. The Font Face, Font Size and Alignment are not properties the MobiTask client will recognize but form designers can still use the features to customize the appearance of the form on the web.
Access Key: The keyboard keystroke (shortcut key) to jump directly to this field
Background: Set the background colour in hexadecimal code for both the label and object cells of this HTML element
Size: The property value varies element to element. For a textfield it is the visible length of the textbox in characters on the form (inputted text can still be longer) and is used when no default width % is entered.
Max. Length: Set the maximum length of input of characters
Width: The amount of space within the line of the form that the field will take up. Each line is 100% of the width of the form, so the sum of widths for fields within a line should add up to 100%. Setting the width of a field at 50% means the field will take 50% of the available line space.
Lookup Reference Field: Select if this field is a reference for other values in the form
Lookup Reference Field Event: The form event that will trigger the lookup reference
Data Source [dslookup]: Allows the designer to select a data source from which the element can populate data automatically with specific information from the specified database
Only the Width and Max Length properties are directly related. MobiTask uses different methods for lookups which do not require the properties Lookup Reference Field and Lookup Reference Field Event to be entered but the functionality still applies. Access Key, Background and Size are not supported on the mobile client.
Reference: The XML element name or attribute – supports nested structures. Use simple Xpath expressions
Hint: Text for the “Tooltip” that is displayed when the mouse cursor is over the element
JS Description: Allows the designer to provide a description of what the entered code does for future reference.
Value/Formula: To provide a default value to the element, or to perform a mathematical function. We’ll discuss mathematical functions in greater detail later in this document.
Summary: Check this to show the value of this field in the submission description. The submission description is used in few places, and is the string of data that allows users to identify which submission they are looking at. You should only select this property on the 4-5 fields that help describe this submissions uniqueness to the end-user. Note that the field values are concatenated in the order of appearance on the form and are then truncated at 250 characters for display, so select your summary fields wisely.
Label on top: eXFORMA by default has this value checked and places all labels on top of the object – un-selecting this option moves the label for the element next to the object. Note that when the label is next to the field, it is combined with the object when the width ratios are calculated.
Required: Check this box to make this element mandatory for form submission.
Read Only: To make the field visible but not modifiable, often used on pre-populated form data that the designer does not want the user to change, ie – data lookups, calculation fields.
Show in printable: To override the print option of disabling if no value is entered.
Shown in Submission: To show this form value in the submission review.
Check Spelling: To check the spelling of an input to this specific element.
Validation: Select a predefined type of validation to be performed on the value of the input data.
Validation Message: Message that will appear if the value of the input does not meet the requirements.