1. Help Center
  2. Study Configuration and Form Building

Targeting Web Forms for Devices and Languages

Multiple Device Form Layout (Device Targeted Form) and Displays on Multiple Device Types and Screen Sizes

Table of Contents

The TrialKit mobile app takes a clinical trial beyond the computer screen. When building forms and surveys for a study, as a form builder, it's tough to create a form that looks good on the various screen sizes that might view it down the road. After all, one size does not fit all. 

Forms created in TrialKit can easily be made to display well on multiple device types and screen sizes. This gives form builders control over form layouts across the various devices users use for entering study data. For example, a physically wide form (e.g. a log form) that looks good on the web, when opened on a mobile phone via the TrialKit app, would run off the screen forcing the user to scroll horizontally back and forth to see the entire form, which can be challenging to a user. 

TrialKit provides an automated tool for study builders to take a form they've built and rapidly set it up for multiple devices, allowing ease of entry while maintaining a single streamlined dataset in the end.

The steps below outline how to target form layout for multiple devices. These steps only apply to study builders.

Device Dictionary

  1. Ensure you have access to the Device Dictionary within the Host level role security menu on the app.

Mobile App:

Tap on the Device Dictionary: 

2022-09-24_9-55-44

On this screen, you will define the Targeted Device sizes, PDFs, and which language-version of the form should be used. All of this is covered in more detail below.

 2022-09-24_9-58-01

It's okay if you are not sure about which screen sizes to target, especially for ePRO studies where subjects use their own devices. Having 3-5 targeted sizes for a range of devices is sufficient.

 Size Requirements:

  • iPads or Tablets: 800
  • Large phones: 400
  • Small phones: 320
  • PDF: 800
  • Targeted Languages: 300*

*Most device sizes are configurable, except when using targeted languages. The web browser will require device size of 300 in order to display the correct language.

When defining the screen width value of different devices, TrialKit uses what is called UIKit sizes (or points), based on the pixel mapping used by iOS. You can read more here on that.

If a form is being opened on a device with a screen width size not specifically targeted in the study, the system will open the form in the next smallest size that it can find.

For example, in the list below, if a user opens a form on a device with a screen width of 400 units wide, the system will open the form on the 375 size, which only means the form won't be utilizing the full width of the screen. With that said, it's good practice to target the one common small device to meet the lowest common denominator.

 If the system does not have the next smallest device being targeted, it will open the main form size, and the user will need to scroll horizontally to see the entire form if the form was built wider than the screen of the device it's being viewed on. Read more below about the main form.

Language Targeting

Language-specific devices can also be targeted, whereby the form will open based on the user's device-level language settings (on the app), or browser language settings (on the web patient portal). For example, if a French user has their device settings in the French language, and the study they are doing data entry on has a form targeted to French, the user will see that version of the form. Queries will display translated text for system-based query information, but the query/error text defined in the edit check will be presented in the language they were authored in.

Language targeting is normally only used in ePRO studies where Participants are performing data entry. If Clinicians also need to view forms in other languages, it is best to setup separate forms entirely for each possible language. Those forms can then be conditionally hidden based on each site's own language.

To create targeted language forms, continue reading below.

Languages currently Supported: September 2022:  If you do not see a language you need supported contact support to request adding it.

Chinese (Simplified) - zh
Czech - cs
Dutch - nl
English -en-US
French - fr
Georgian - ka
German - de
Greek - el
Italian - it
Japanese - ja
Norwegian - no
Polish - pl
Russian - ru
Spanish - es
Swedish - sv
Ukrainian - uk

If creating a target for a language, consider that the form where the data is collected will store all data in a single table. In other words, the data exports at the end of the study's life will contain an exported file for that form with all languages in one file. 

If you prefer to keep separate data sets for each language, do not create a targeted language. Instead, create a separate parent form directly in that language and translate the text of the parent form. Then display that form based on some external variable where each subject's language is identified.

 

PDF Targeting

Lastly, the device type "PDF" can be used to create paper versions of the electronic forms. This version will be what users see when they export the form as a PDF. Creating a unique sizing for paper PDF in often necessary because the electronic version of the form goes outside of paper bounds.

 

Creating Targeted Forms In the Form Builder

After defining your target device sizes and languages that will be an on the study (done within the Host) you being building the forms.

In the Form Builder, open a form that you would like to target for various screen sizes. Then open the form properties for that form (highlighted below).

Important Point: The form you are opening is referred to as the Parent form. It's best if this form is originally built on the web so that the web version of the form is optimized for that environment.

In this step, you are taking that parent form and creating a mobile/child form from it in order to set up a different layout of the same form.

 

Select a device or language to target. The list of options comes from the Device Dictionary section described above.

There is also an option to force the layout into a single column if desired. Depending on the screen width and current form layout, this may happen anyway.

Then tap the Build Device Form button.

 

Do not tap save on the parent form. To see the new form that was created, exit the current form by opening the forms manager.

 


In the background, the system will instantaneously re-arrange the form layout to fit the device width being targeted. The new form referred to as a child (targeted) form, that was created can be accessed in the Form Manager screen. It will have the same name as the parent form followed by a number. You will also see a description of the device it's targeted for, based on how you defined devices in the device dictionary.

If a different language was targeted, this process will also use Google’s Translate API to interpret all the text and labels on the form. Further revisions to the translations can be made as needed.

 
 

Open the child form by tapping on it.

Review the layout that was generated by the system, change the layout or item sizes as desired, and save the changes to the child form.

Important Point: Do not add new or delete fields on a child form. If a change must be made to the form, variables, or logic, make the change on the parent form and then re-create the targeted form so the form variables and behavior match. Form Targeting should only be used to alter the layout of forms for a different presentation.

 

Updating Language Text

Forms can easily be targeted to support different languages, or updated entirely to a different language after the form is built. It does this by running the form text through the Google Translate APIs and then providing a means to export all the text to a file so it can be translated outside of the system, and then the ability to reimport that file.

The reason for this approach of manually updating the text via a file is because the machine translation will not likely be 100% accurate. 

All of this is done via the Form Properties

Testing for language forms

If the form translations have been done on child forms, when testing to make sure a targeted language is opening, it is important to have your device language or browser language set to the same language to which the form(s) have been targeted. If the system continues opening the parent form, it's either because the language doesn’t match the device or the form width can’t be used.

To display targeted language forms on the web, set the device dictionary width to 300.