Multiple Device Form Layout (Device Targeted Form)

_{Share or Open in Web}

Table of Contents

Overview

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. 

Fortunately, forms created in TrialKit can easily be made to display well on multiple device types and screen sizes. This gives form builders the most detailed control over form layout across the various devices that users of the study will be entering forms on. For example, a physically wide 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 would make for poor user experience. 

Due to the complexity of case report forms in clinical trials, TrialKit provides an automated tool for study builders to take a form they've built and rapidly set it up for multiple devices, and still maintain a streamlined single set of data 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. I
   
   

2. Setup the Targeted Device sizes or PDFs that will be needed in the study. 

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.

When defining the screen width value of different devices, TrialKit uses what is called UIKit sizes (or points), based on 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 between 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 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). 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. Any data variable queries will also be presented in the device language, but the query text itself in the queries report will be stored in whatever language edit checks are created in.

To create targeted language forms, continue reading below.

PDF Targeting

Lastly, the device type "PDF" can be used to create paper versions of the electronic forms. This version will never be displayed to end-users. Instead, it's specifically a tool for form builders to create paper CRFs for printing.

How to Create Targeted Forms from the Device Dictionary

After defining your target device sizes and languages that can be used on any study within the host:

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).

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

Notice in the form above, it was set with a width of 1400. This is likely because other tabs on the form include content that takes up more width on a screen and is designed to be completed on the website.

Scroll to the bottom of the form properties and select a device to target. The list of options is the one from step 2 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.

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 in the forms list

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

Text labels and text within choice fields can be updated in batch, as applicable when doing form translations for different languages. This is done in the Form Properties.

Testing for language forms

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

Related articles