Exploring ORMs | Technical guide | Gathering and preserving participant information

Introduction

Beyond the survey data, there are a number of possibilities for the collection of information that may be of use to the researcher.

This page will describe how information can be stored in hidden form fields to be submitted alongside the data from visible form fields.

It will also provide an overview of how JavaScript and a technology called 'server-side includes' can be used to collect the following:

IP addresses and date and time information including approximate completion time which may be useful for security and identifying and removing anomalous submissions.
The URL of the referring page (the page which contained the link the participant followed to reach the questionnaire) which may be useful in providing information about the success of the forms of advertising used to elicit participation.
Information about the user's computer and browser such as whether JavaScript and cookies were enabled, the screen-size of the monitor used, or which type and version of browser was used to access the questionnaire. This information may prove valuable in determining whether some features such as validation were available when the participant completed the questionnaire. It is also likely to be useful in gaining an overview of the technologies available to respondents. If it becomes clear, for example, that older or less common browsers are being used to access the questionnaire, it can be tested on these browsers and redesigned if necessary.

Finally, it will outline how cookies can be saved onto a participant's computer so that action can be taken if the same computer is used to access the questionnaire for a second time.

Adding data to hidden form fields

As their name suggests, hidden form fields and their contents are not displayed in the browser. They can thus be used to submit information along with the form data which it is not necessary or desirable to display. It should be remembered, however, that a participant can access the information in a hidden form field simply by opting to view the HTML source code for the page.

Adding information to a form in a hidden form field is straightforward. The code is as follows:

<input type="hidden" name="hidden1" value="value added by the researcher or set via HTML or JavaScript" />

When the form is submitted, the contents of the form field (the value) are added alongside the data from visible form fields. Thus, for example, if more than one version of a questionnaire is released, the version number can be added to the form as follows:

<input type="hidden" name="version" value="1" />

When data is submitted, it would thus be clear which version of the questionnaire was completed.

Client-side or server-side information gathering

Where the ability to gather user information is desired as an 'extra' in cases where the researcher is able to accept that it may not be possible to gather information from all participants, the use of Client-side information gathering using JavaScript is ideal as it allows a straightforward way of collecting a wide range of information. It does not matter what type of server the questionnaire is hosted on as the processing that collects the information and adds it to the form data is carried out on the user's computer.

In cases where the gathering of user information is essential to a study, however, it is recommended that the process is carried out using server-side processing which will operate regardless of the technologies available on the client computer. This is because JavaScript may not be available to all browsers and because users may choose to disable JavaScript on their machines.

A further advantage of using server-side processing is that it is more likely to allow accuracy and consistency of information to be achieved. For example, JavaScript relies on the accuracy of the time and date on the user's computer which may be open to variation across different machines. Server-side technologies, however, take this from a single source (the server). It is relatively straightforward to gather a range of information using ASP.NET or PHP, depending on the server technology used. (see the 'Server-side processing' section for more information on these technologies).

For researchers with a server capable of supporting them, Server-Side Includes (SSI) provide perhaps the most straightforward and easily-implemented way of gathering user information through server-side processes. This page will focus on the use of this technology alongside JavaScript.

Data gathering via Server-Side Includes (SSI)

Server-Side Includes are designed to allow small pieces of a web page to be dynamically generated. They are frequently used in web pages to add information such as the date the page was last modified or the current time and date. SSI pages are generally marked with an .shtml suffix which signals to the server that any SSI directives should be processed server-side.

Where the questionnaire is hosted on a server that supports them, Server-Side Includes offer a straightforward and easily-implemented method of collecting user information. The apache web server can easily be configured to allow them to be used and simple measures can be taken to ensure their use does not lead to any vulnerability in terms of security. The following tutorial describes how this can be done and provides a general overview of SSI.

http://httpd.apache.org/docs/1.3/howto/ssi.html

NB. Server-Side Includes are not supported by windows-based Microsoft server technologies for which ASP.NET is likely to provide the best alternative.

The basic structure of an SSI directive is as follows:

For example, if the following SSI directive is placed in a web page on an SSI compatible server, it will automatically be replaced by the time and date that the page was last modified.

The var="LAST_MODIFIED" section sets a standard 'environment variable' which, in this case, is the time and date of the last modification. The #echo command then writes this variable to the web page, effectively replacing the directive with the value of the variable. The whole directive is placed within HTML comments  so that it will be ignored by the browser if the server fails to process it correctly.

By placing SSI directives in hidden form fields, information can be collected and submitted alongside the form without interfering with the working of the questionnaire. The following information can be easily gathered using SSI directives:

Date and time

The date and time that the questionnaire was accessed can be established using the following SSI directive:

If this is placed in a web page on an SSI compatible server, it will be replaced by the time and date in the format specified by the default settings of the server. This may be as follows:

Day, Date, Time, Time zone, e.g.

Saturday, 31-Dec-2005 23:59:50 GMT

To modify the format of the date, the following SSI directive can be placed immediately before .

where value is replaced by a series of SSI time codes such as the following:

Code	Description	Example
%a	Abbreviated day of the week	Sat
%A	Full day of week	Saturday
%b	Abbreviated month name	Dec
%B	Full month name	December
%D	Numerical date (likely to be expressed in the Month/Day/Year format)	12/31/05
%d	Day as digit	31
%m	Month as digit	12
%H	Hour (24-Hour format)	23
%I	Hour (12-Hour format)	11
%M	Minutes	59
%S	Seconds	50
%p	AM or PM	PM
%T	24-Hour time	23:59:50
%y	2-digit year	05
%Y	4-digit year	2005
%B	Full month name	December

Thus the following directives:

display the date and time as follows:

Date: 31/12/2005 Time: 23:59:50

This information can be added to hidden form fields for submission with the form data as follows:

<input type="hidden" name="date" value="" />

<input type="hidden" name="time" value="" />

Browser information

It is possible to use SSI directives to gather information about the browser which is being used to access the questionnaire. As stated in the introduction, this information may prove valuable in allowing an overview to the gained of the technologies available to respondents. If it becomes clear, for example, that older or less common browsers are being used to access the questionnaire, it can be tested on these browsers and redesigned if necessary.

Information about browser type and version can be established using the following directive:

When placed in a web page on an SSI compatible server, it will be replaced by a string of information about the browser's name, version, platform, and language settings. Some of the information may be confusing especially software/version information which usually begins the string and which may suggest that an older version is being used. Information from some browsers may also be more extensive than from others. However, the type and version can usually be established successfully. Some examples of the results of the directive when the most common browsers are used are as follows, with the key browser information highlighted in bold:

Internet Explorer 6

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Firefox 1.0.4

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Netscape 7.2:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

Opera 7.54

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [en]

If you wish to decipher any more unusual strings of information that may be returned, it may be necessary to refer to explanatory lists of user agents. The following is a very extensive list of browser types and typical user agent strings that they return:

http://www.zytrax.com/tech/web/browser_ids.htm

A second SSI directive which offers information about the participant's browser is as follows:

This provides a list of the types of information the client will accept from the server. These are expressed as a list of MIME types in a type/acceptable subtype format as in the following example:

image/gif, image/jpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*

The */* syntax indicates that the client machine will accept all types of information.

A final directive which can be used to collect browser information is as follows:

This provides the language(s) that are defined as being the user's preferred language(s), as in the following example which specifies that Portuguese (Brazilian) and English (British) are the preferred languages stated by the client machine:

pt-br, en-gb

User identification

When placed in a web page on an SSI compatible server, the following directive will be replaced by the IP address of the client computer accessing the page.

The IP address is a group of four numbers separated by full stops (e.g. 81.77.39.115) which are associated with a particular computer or server. Collecting the IP address of the client computer that the participant used to access the questionnaire is worthwhile as repeat submissions from the same IP address within a short space of time may indicate multiple submission from the same participant and can be investigated further.

However, the use of IP addresses as the sole means of identifying multiple submissions from the same machine is unreliable as the IP address of a computer which accesses the internet via an internet-service provider is likely to be different each time it is connected to the internet. Possible multiple submissions are thus only likely to be traceable if they are carried out in a single internet session. Even when there is only a short space of time between multiple submissions from the same IP address, it may be difficult to establish whether they have come from the same user or from different users of shared computers or of computers on a shared server with the same IP address.

The use of cookies to identify particular computers offers potential for more reliable user identification, but this remains limited (see section below).

For truly effective access control, a server-side system of access via password is likely to be needed so that only invited participants with a password can access the questionnaire (see the 'Server-side processing' section of this technical guide.

The referring page

The following directive can be used to display the URL of the page from which a link to the questionnaire was followed:

If the participant reached the questionnaire directly without following a link, there will be no referrer and the directive will be replaced by the following:

(none)

Data gathering via JavaScript

It is also possible to use JavaScript to collect information about the user's computer, date and time information, and the referring link (the link that the participant followed to reach the questionnaire).

Example

The following example shows information gathered via JavaScript about your computer:

Name of browser:

Version of browser:

Browser platform:

Screen size:

Cookies enabled? (true or false)

Referring link:

Date:

Time started (measured from when the page is loaded)

Time ended (added when the form is submitted)

Completion time

In a questionnaire, this information could be placed within hidden form fields and submitted alongside the questionnaire data.

NB. It should be remembered that time information is measured according to the clock settings on the client machine which may not be accurate and which may mean that data is subject to time-zone differences.

However, the completion time is likely to be accurate as the start and end times will be taken from the same clock settings.

The form

To collect this information, hidden form fields are given suitable names and placed within the questionnaire form which is also given a suitable name. The information is added to the hidden form fields through the action of two functions called startForm() and endTime().

The startForm() function adds the relevant information to the first eight hidden form fields when the form loads. The function is called by the onload event handler when the body of the HTML document loads into the browser.

The endForm() function adds the time of the questionnaire submission and the total completion time when the form is submitted. It is called by the onSubmit event handler in the form tag.

The HTML is shown below.

Check your understanding of how the HTML creates and names the form and form elements, and of where and how the functions are called. Review the 'Web forms', 'Introduction to JavaScript' and 'Form validation' sections of this guide if necessary.

<body onload="startForm();">

<form name="quesForm" action="" method="post" onSubmit="return endTime();">

ADD THE FOLLOWING BOXES AT THE END OF THE QUESTIONNAIRE QUESTIONS...

<input name="browserNameBox" type="hidden" /> <input name="browserVersionBox" type="hidden" /> <input name="browserPlatformBox" type="hidden" /> <input name="screenSizeBox" type="hidden" /> <input name="enabledCookiesBox" type="hidden" /> <input name="referrerBox" type="hidden" /> <input name="dateBox" type="hidden" /> <input name="startTimeBox" type="hidden" /> <input name="endTimeBox" type="hidden" /> <input name="completionTimeBox" type="hidden" />

<input type="submit" name="Submit" value="Submit" />

</form>

</body>

Data collection

As you will see, the data collection functions take advantage of the following JavaScript objects and properties to collect the information:

Object&property	Description	Example
navigator.appName	Returns the name of the browser being used to access the page.	Microsoft Internet Explorer
navigator.appVersion	Returns the version of the browser.	4.0 (compatible; MSIE 6.0; Windows NT 5.1)
navigator.platform	Returns the browser's platform or operating system.	Win32
navigator.cookieEnabled	Returns a value of true if cookies are enabled and false if they are disabled.	true
screen.width	returns the width in pixels of the user's screen.	1024
screen.height	returns the height in pixels of the user's screen.	768
window.document.referrer	returns the URL of the page from which the user navigated to the current page. Returns an empty string if there is no referring link.	http://www.le.ac.uk
date.getDate()	Returns the day of the month	25
date.getMonth()	Return the month of the year as a number from 0 (January) to 11 (December)	11
date.getFullYear()	Returns the year (may not work in older browsers)	2005
date.getHours()	Returns the hour of the day (24-Hour format)	23
date.getMinutes()	Returns the minute of the hour	59
date.getSeconds()	Returns the second of the minute	50
date.getTime()	Returns the current time in milliseconds	112473628262

The information is automatically returned when the objects and properties are included in the code.

The JavaScript functions

The code for the first function is as follows:

Check your understanding of the code by reading the comments. Review the 'Introduction to JavaScript' and 'Form validation' sections for more information on JavaScript if necessary.

function startForm(){

// Change the value of the hidden form field called 'browserNameBox' to the value returned by the 'appName' property of the 'navigator' object (i.e. the name of the browser used to access the form)

document.infoForm.browserNameBox.value = navigator.appName;

// Change the value of the browserVersionBox

document.infoForm.browserVersionBox.value = navigator.appVersion;

// Change the value of the browserPlatformBox

document.infoForm.browserPlatformBox.value = navigator.Platform;

// Change the value of the enabledCookiesBox

document.infoForm.enabledCookiesBox.value = navigator.cookieEnabled;

// Change the value of the screenSizeBox by adding the values of screen.width and screen.height separated by a string (" x ")

document.infoForm.screenBox.value = screen.width + " x " + screen.height;

// Change the value of the referrerBox

document.infoForm.referrerBox.value = window.document.referrer;

// Change the value of the dateBox

// Declare a new date object given the name 'date'

var date = new Date();

// Set a variable called 'day' to store the day of the month of this date object

var day = date.getDate();

// Format the day by adding a zero if it is lower than 10 so that the fifth will appear as 05 rather than 5

if (day < 10){

day = "0" + day;

}

// Set a variable called 'month' to store the month of this date object and format it so that January appears as 01 rather than 0 and December appears as 12 rather than 11

var month = date.getMonth() + 1;

if (month < 10){

month = "0" + month;

}

// Set a variable called 'year' to store the year of this date object

var year = date.getFullYear();

// Add the full date to the hidden form field called dateBox by adding the variables 'day', 'month' and 'year' separated by strings ("/")

document.infoForm.dateBox.value = day + "/" + month + "/" + year;

// Change the value of the startTimeBox by setting a new date object and storing the hours, minutes and seconds of this date object in variables. In each case, format the time so that digits lower than 10 are preceded by a zero

var startTime = new Date(); var hour = startTime.getHours(); if (hour < 10){ hour = "0" + hour; } var minute = startTime.getMinutes(); if (minute < 10){ minute = "0" + minute; } var second = startTime.getSeconds(); if (second < 10){ second = "0" + second; }

// Add the complete time to the 'startTimeBox' hidden form field by adding the variables 'hour', 'minute' and 'second' separated by strings (" : ")

document.infoForm.startTimeBox.value = hour + " : " + minute + " : " + second;

// Finally set a variable called 'startTiming' with the current time in milliseconds. This will be used to calculate completion time.

now = new Date(); startTiming = (now.getTime()) }

The code for the second function is as follows:

function endForm(){

// Get the current time in the same way as in the previous function

var endTime = new Date(); var hour = endTime.getHours(); if (hour < 10){ hour = "0" + hour; } var minute = endTime.getMinutes(); if (minute < 10){ minute = "0" + minute; } var second = endTime.getSeconds(); if (second < 10){ second = "0" + second; }

// Add the complete time to the hidden form field 'endTimeBox'

document.infoForm.endTimeBox.value = hour + " : " + minute + " : " + second;

// Set a variable called 'endTiming' with the current time in milliseconds.

now = new Date(); endTiming = (now.getTime());

// Calculate completion time by subtracting the start time obtained by the first function (called when the page loaded) from this end time (calculated at submission). Round up the result and convert it from milliseconds to seconds. Store it in a variable called 'timeTaken'.

timeTaken=Math.round((endTiming-startTiming)/1000);

// Add this to the hidden form field 'completionTimeBox' followed by the string " secs"

document.infoForm.completionTimeBox.value = timeTaken + " Secs";

// Finally, return true to the form to allow submission to proceed

return true; }

You can select the following link to open the HTML page and code in a new window. As the form fields are hidden, they will not be visible in your browser, but you can select VIEW -> SOURCE to see or copy the complete HTML file. There are instructions on how to incorporate the hidden form fields and code into your own questionnaires.

Combining data gathering with validation

If you are using validation code in a function called by the onSubmit event handler, the endForm function cannot be called from within the form at the same time. Instead, it should be called from within the validation function itself.

If the validation routine finds that the form is ready to be submitted it will return true to the form to allow submission to proceed (see the 'Form validation' section). By adding endForm() to call the function before the return true syntax, the hidden form fields will be changed before the final submission.

The final lines of the section of the validation code that deals with successfully completed forms will thus be

endForm();
return true;

rather than simply

return true;

Select the following link to see a web form with the information gathering functions combined with validation routines. This will open in a new window. You can select VIEW -> SOURCE to see or copy the complete HTML file.

Dealing with non-JavaScript browsers

Providing that testing is carried out to ensure that the JavaScript used will not interfere with the completion and submission of the questionnaire in non-JavaScript browsers, there will be no problems for respondents without JavaScript. The hidden form fields will simply be returned with empty values.

A simple way of gathering the information that JavaScript was not available (and verifying that empty values are caused by this rather than by any problems with the form or the scripting) is to include a hidden form field enclosed in <noscript></noscript> tags as follows.

<noscript><input type="hidden" name="JavaScript" value="unavailable"></noscript>

This will only add the code within the tags in cases where JavaScript is not available so that the value will only be sent along with the form if this is the case.

Cookies

Setting a cookie to identify when a computer has already been used to submit a questionnaire is more reliable than using IP addresses. When a user submits the questionnaire, a cookie can be stored on the hard drive of the computer which will identify the fact that it has been used to make a submission. Should the same computer be used to access the questionnaire a second time, action can be taken such as delivering a message or redirecting the user.

However, problems remain in the use of this method to prevent multiple submission as users can opt to reject cookies or delete them from their hard drive. These examples also depend on the use of JavaScript which can be disabled in the browser. It should also be remembered that different participants may be using the same machine to access the questionnaire.

For truly effective access control, a system of access via password is likely to be needed so that only invited participants with access to a password can participate (see the 'Server-side processing' section of this technical guide).

Where the researcher does not wish to limit access in this way, however, the use of cookies is likely to be helpful in highlighting or preventing multiple submissions as the majority of users are unlikely to have disabled cookies on their machines. The process of identifying when a computer has already been used to submit a questionnaire using cookies is straightforward.

Examples

The following examples open a web page in a pop-up window. When the page is opened, JavaScript is used to check whether or not the computer has a cookie called "Multiple" saved on it. If it does not, it is assumed that it is the first time that the computer has been used to access the questionnaire. A cookie called "Multiple" is then saved to ensure that the first check will establish that the computer has been used to access the questionnaire if it is subsequently used again.

Each of the examples carries out a different action if the cookie called "Multiple" is found.

1. An alert box message

2. A message appears at the top of the page

3. The user is redirected to another page.

NB. These links uses JavaScript to open pop-up windows. As your browser does not allow JavaScript, you will not be able to do this. However, you can select these link to open the pages in new windows, but you will need to activate JavaScript to examine the functionalities in the new pages. Otherwise, you will be able to follow the descriptions of the JavaScript functionalities and the procedures for adding them, but not see their effects in the examples.Alert box message;Message appears at top of page; The user is redirected.

You can test each of these by using the following link to delete the cookie.

Explanation

The JavaScript code for the first example is as follows:

<script language="javascript" type="text/javascript"> function checkCookie(){ var found; if (document.cookie.length>0){

found = document.cookie.indexOf("multiple="); if (found != -1){ alert("It appears that your computer has been used to access this questionnaire before. If it was used by you, please do not complete the questionnaire a second time.") return; }

} setCookie("multiple", "yes", ""); } function setCookie(name, value, expires){ if (expires ==""){ var now = new Date(); now.setTime(now.getTime() + (1000*60*60*24*365)); expires = now.toGMTString(); } document.cookie = escape(name) + "=" + escape(value) + "; path =/" + ";expires=" + expires; } </script>

The first function checkCookie() checks whether or not the cookie called "multiple" has been previously saved to the computer's hard drive. If it has, the alert message is delivered. If not, the setCookie("multiple", "yes", "") function is called. This saves a cookie called "multiple" with the value "yes", and sets the expiry date for the cookie to 1 year from the current date (1000*60*60*24*365) which is the number of hours (1000*60*60) multiplied by the hours in a day and the days in a year (24*365).

The checkCookie() function is then called when the body of the page loads using the onload event handler:

<body onload="checkCookie();">

The code for the other examples is similar, but the action that occurs when the cookie called "multiple" is found is different.

For the second example, a function called showMessage('multiple')is called which shows the hidden layer called 'multiple' to reveal the message at the top of the page. The setCookie() function is the same, but the checkCookie() function changes as follows:

function checkCookie(){ var found; if (document.cookie.length>0){

found = document.cookie.indexOf("multiple="); if (found != -1){ showMessage('multiple'); return; }

} setCookie("multiple", "yes", ""); }

The following functions are also added to provide the functionality required to reveal the message at the top of the questionnaire.

// The message to the participant is delivered by showing or hiding layers. This is done differently according to the type of browser the participant is using. This block of code checks the type of browser

var isIE4 = false; var isCompliant = false; if(document.getElementById){

if(!document.all) { isCompliant=true; } if(document.all) { isIE4=true; }

}

// Code to allow the hidden layer used to deliver the messages to be made visible. A different method is used according to the type of browser identified in the previous block of code.

function aLs(layerID){ var returnLayer ="null"; if(isIE4){

returnLayer = eval("document.all." + layerID + ".style"); }

if(isCompliant){

returnLayer = eval("document.getElementById('" + layerID + "').style"); }

} return returnLayer; }

// Function to make a layer visible when called. The layer name is fed into the function when it is called.

function showMessage(ID) { aLs(ID).display = ""; }

For the third example, the URL of the page is changed using the code window.document.location="newpage.htm"; where "newpage.htm" is the link to the page opened when the cookie called "Multiple" is found. The setCookie() function is the same, but the checkCookie() function changes as follows:

function checkCookie(){ var found; if (document.cookie.length>0){

found = document.cookie.indexOf("multiple="); if (found != -1){ window.document.location="newpage.htm"; return; }

} setCookie("multiple", "yes", ""); }

This URL "newpage.htm" is automatically loaded if the cookie is found. This page includes a link to a different version of the questionnaire which can be submitted using a hidden form fields to alert the researcher that the computer had already been used to complete the questionnaire and prompt him/her to check further (see 'Adding data to hidden form fields' section above).

Select the following links to view the HTML pages and code for each of these examples in a new window. You can then select VIEW -> SOURCE if you wish to see or copy the complete HTML/JavaScript file.

1. An alert box message

2. A message appears at the top of the page

3. The user is redirected to another page (You will need to click on the following link to delete the cookie to ensure that the first page loads without automatically opening the second).

« BACK UP NEXT »

Gathering information about participants

Internet Explorer 6

Firefox 1.0.4

Netscape 7.2:

Opera 7.54