QuON

A Generic Platform for the Collation and Sharing of Web Survey Data

David Paul, Mark Wallis, Frans Henskens and Kim Nolan

Distributed Computing Research Group, University of Newcastle, Callaghan, Australia

Keywords:

Survey, Data Collection, Software.

Abstract:

QuON is an open-source system that allows researchers to design and conduct Web-based surveys. It was cre-

ated to overcome limitations in existing survey systems, and is especially concerned with conditional branch-

ing, user and group management, and the generation of metadata to allow optional sharing and external dis-

covery of collected survey data. This paper describes the current QuON software system, its features, and

future directions.

1 INTRODUCTION

Surveys and questionnaires are a vital component of

many research projects (Ader et al., 2008). They can

be used for various different purposes, such as pro-

viding a benchmark of a population’s current attitudes

or behaviours, presenting information to respondents

in a relevant manner, or even to evaluate an individ-

ual’s understanding of a particular topic or issue. Sur-

veys can be conducted via face-to-face personal inter-

views, via the telephone, through paper forms sent in

the mail, using custom software, or, using Web forms,

over the Internet.

Surveys conducted over the Internet provide many

advantages to the other survey types. Like paper

forms, Web surveys do not require a researcher to

be actively involved in the collection of responses

after the survey has been designed and published,

which reduces overall cost. However, like personal

and telephone interviews, it is possible for the sur-

vey to change dynamically based on a respondent’s

previous answers. For example, a Web system can

automatically skip questions asking for more details

if the respondent has indicated that a particular set

of questions is not relevant for that individual. Fur-

ther, such customisation in Web forms can be auto-

matic, removing the risk of human error in determin-

ing which questions should be asked to a particular

respondent. While custom (non-Web-based) survey

software also enjoys these advantages, the software

must be installed on the respondent’s computer. The

fact that most computer (and tablet/smartphone) users

already have access to a Web browser lowers the bar-

rier of entry, making it easier for Web surveys to reach

a larger audience.

Thus, many research projects choose the Web as

their medium for conducting a survey. While it would

be possible to manually create the HTML forms re-

quired to conduct each new survey, various platforms

have been developed to make the creation of Web

surveys easier. However, while numerous different

frameworks exist, none has all of the features neces-

sary to conduct all kinds of research surveys.

This paper introduces QuON, a generic survey

platform designed for managing and collating scien-

tiﬁc Web surveys, especially in the area of health

behaviour. Section 2 describes existing survey sys-

tems and some of their limitations. Section 3 then

describes the QuON framework, which has been de-

signed to overcome these limitations, to improve sup-

port for scientiﬁc surveys. The current unique fea-

tures of QuON are described in Section 4. Finally,

Section 5 concludes the paper, describing QuON’s ad-

vantages over existing survey systems for scientiﬁc

surveys and indicating on-going and future work.

2 EXISTING SYSTEMS

At a high level, systems designed to facilitate Web

surveys can be split into two groups: online services,

such as (FluidSurveys, 2013; SurveyMonkey, 2012);

or stand-alone applications, such as (Digivey Survey

Center, 2012; LimeSurvey, 2013; Webmyne Systems

Inc., 2013). Some systems also offer both online and

111

Paul D., Wallis M., Henskens F. and Nolan K..

QuON - A Generic Platform for the Collation and Sharing of Web Survey Data.

DOI: 10.5220/0004402901110116

In Proceedings of the 9th International Conference on Web Information Systems and Technologies (WEBIST-2013), pages 111-116

ISBN: 978-989-8565-54-9

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

stand-alone versions (Checkbox Survey, 2013).

For scientiﬁc surveys, especially surveys involv-

ing sensitive information such as medical details, on-

line services are not always appropriate. This is espe-

cially true when ethics approvals do not allow third-

parties to store the information for a researcher; only

local systems can be used in these cases. Since QuON

is designed primarily for scientiﬁc surveys, this sec-

tion will concentrate on survey systems that can be

installed on local infrastructure.

One of the complications with survey software is

that surveys are not always linear. For example, in

many paper surveys there are instructions similar to

“If ’No’, go to Question 7”. Web surveys do not

need to display these instructions; the system can au-

tomatically skip certain questions based on previous

responses. However, in order to support such oper-

ation, it is necessary to specify this branching logic

when the survey is deﬁned. Different systems allow

this information to be entered in different ways.

One way to allow selective display of questions,

supported by (Checkbox Survey, 2013; Digivey Sur-

vey Center, 2012; LimeSurvey, 2013; SurveyMonkey,

2012), is to have a condition for each question, such

that the question is only displayed if the condition is

true. The problem with this approach is that, if the re-

searcher wants to skip a group of questions together,

then the necessary condition must be entered once

for each question. Thus, any change in the condition

logic would need to be reentered in multiple places,

which can be tedious and error-prone.

Another option to allow skipping of questions

is to include, with each question deﬁnition, an op-

tional condition that speciﬁes which question to dis-

play next, based on the response given to the cur-

rent question. Such a technique is used by systems

such as (Digivey Survey Center, 2012; SurveyMon-

key, 2012). However, the condition for these systems

can depend only on the value of the current ques-

tion. This makes it impossible, for example, to dis-

play a question that discriminates between respon-

dents, then display some common questions, and then

branch based on the discriminatory question. Other

systems, such as (Checkbox Survey, 2013) do allow

more complex conditions that are based on questions

other than the current one, but the branch logic is still

part of a question, meaning that multiple questions

cannot reference the same conditions. It is possible

to overcome these limitations by displaying any dis-

criminatory question after the common questions, but

this changes the survey’s design. Another option is to

deﬁne the common questions or branching logic mul-

tiple times, once for each of the discriminated types,

but any change to the common questions would then

require each copy to be altered.

User management is also important when con-

ducting surveys. Often, it is useful to collect anony-

mous information, where the researcher does not

know the respondent’s identity. Other times, only

authorised users should have access to complete a

particular survey, so a username and password is re-

quired. In other cases, such as when only known re-

spondents should be able to participate but passwords

would place too great a burden on the respondent, it

would be useful to assign an identiﬁer to a respon-

dent without a password. The individual can be iden-

tiﬁed for the current, or any future, survey, without be-

ing required to enter authentication information. This

is particularly useful when combined with custom

URLs generated for each respondent that include the

identiﬁcation information automatically. While cur-

rent systems do support some combination of anony-

mous and authorised access, we have no knowledge

of systems that support identiﬁed but unauthenticated

respondents.

Another consideration, for scientiﬁc surveys in

particular, is publishing the fact that data has been

collected. While particular studies, based on col-

lected data, can be published in journals or confer-

ences, there is currently no easy way for researchers

to publish information about existing datasets, and

thus it is difﬁcult for others to discover any survey re-

sponses that have already been collected. No known

existing survey software publishes metadata about the

surveys that have been conducted. However, if re-

searchers could publish such metadata to a registry,

then other researchers could dynamically discover the

dataset and may be able to produce further results

without any extra data collection. Any ethics require-

ments could still be enforced, since only information

that the dataset exists, and how to request access to it,

is released with the metadata. However, discovery of

the metadata would allow new researchers to exam-

ine all requirements necessary to gain access to the

dataset, and to determine whether it is better to access

the existing data, or whether new data should be col-

lected.

QuON is a system designed to overcome the above

limitations of existing survey software. It can be in-

stalled on a local system, meaning that no collected

data is held by a third party. It also supports com-

plex branching to allow customised surveys, different

user types to meet researcher requirements, and the

ability to publish survey metadata to allow external

researchers to discover the collected datasets.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

112

3 QuON FRAMEWORK

QuON is a Web application built using the CakePHP

platform (Cake Software Foundation, 2012). It uses

a MySQL database (Oracle, 2012) to store both def-

initions of the surveys in the system and the answers

collected for each survey. When a researcher logs in

to the system he or she can either create a new survey

or edit an existing survey. When a survey is properly

deﬁned, the researcher can publish the survey, allow-

ing respondents the ability to access and complete the

survey over the Web.

To create a survey, a researcher speciﬁes a number

of survey objects and indicates the order in which they

should be presented when a respondent is completing

the survey. Survey objects can either be questions,

which request a response from the respondent, calcu-

lations, which evaluate an expression that may rely on

a respondent’s previous answers, or branches, which

provide a novel way to customise the order in which

survey objects are presented to an individual respon-

dent. Each survey object is given a name, which is

unique for the survey. Researchers enter attributes for

each survey object, which specify options for how the

object should be processed or displayed. Figure 1,

for example, shows the researcher’s and respondent’s

views of a question object.

Questions present the user with a prompt, and

record a response from the user. QuON automatically

records information such as the time the question is

presented to a respondent, the time the respondent

provides a response to the question, and the value of

the response entered. The framework has out-of-the

box support for many common question types, and is

extensible to allow easy development of new question

types.

The default question types supported by QuON

are:

Informational. Displays text, pictures, and/or video

to the respondent and waits for an acknowledge-

ment that the respondent is ready to continue.

Text. Allows the user to enter or edit a text response

and waits until the user requests the next survey

object. A researcher can specify a regular expres-

sion that the response must match before the re-

spondent is allowed to continue.

Checkbox. Displays a list of check boxes, allowing

the respondent to select as many options as are

appropriate. Limits can be placed on the num-

ber of options that can be selected, and there is

conﬁgurable support for entering “other” values

(displaying a text box to allow the respondent to

enter more details), or for selecting “none of the

above”. Once the respondent has selected the ap-

plicable items, clicking “next” causes the system

to store the response and proceed to the next sur-

vey object.

Radio Button. Similar to a Checkbox, but the re-

spondent can only select one option. Once an

option (which could be “other” or “none of the

above”) is selected, clicking “next” moves the

system to the next survey object.

Button Option. Similar to a Radio Button, but the

options are displayed as buttons that proceed to

the next survey object as soon as they are selected,

rather than requiring the respondent to conﬁrm

their selection is complete.

Drop Down. Presents a drop-down list to the respon-

dent, allowing a single option to be selected.

Calendar. Presents a calendar allowing the respon-

dent to specify a date. Input can be restricted to a

particular date range, and the answer can be stored

as either a ﬁxed date (with a conﬁgurable date for-

mat), or as the difference from a speciﬁed (by the

researcher) date.

Rank Order. Displays a list of items that the respon-

dent can rank. The researcher can specify the

minimum and maximum number of options that

should be ranked.

Distribution of Points. Displays a list of items and

speciﬁes a number of points that the respondent

can assign. The respondent assigns points to each

item, and the system ensures the total number of

points are within the required range.

Likert Scale. Presents a list of options, allowing the

respondent to select a value on a scale for each

item. The researcher speciﬁes both the options

and the scale that are used.

Each question type is speciﬁed in a CakePHP

Helper consisting of an array that speciﬁes the at-

tributes of a question that can be customised by a re-

searcher, a function that speciﬁes how the question

should be displayed to a respondent, a function that

speciﬁes how a response should be validated, and a

function that speciﬁes how the value of any response

can be stored in a way that ensures the answer is re-

producible if the question is displayed again. Thus,

to support a new question type, a developer simply

speciﬁes a new Helper with the appropriate details.

As well as the above question types, QuON also

supports calculations based on answers to previous

questions. The researcher can specify any mathe-

matical expression supported by PHP, and question

names surrounded by square brackets are replaced by

the values of the answers stored by the system for

QuON-AGenericPlatformfortheCollationandSharingofWebSurveyData

113

(a) Researcher’s view

(b) Respondent’s view

Figure 1: Different views of a Likert Scale question survey object.

the current respondent. The value of the calculation

can be displayed to the respondent, or simply stored

so the researcher can access the value when viewing

the results of a survey. For example, if the survey

includes questions about the respondent’s mass (in

a question named “mass”) and height (in a question

named “height”), a calculation object could be used

to display the respondent’s body mass index by setting

its formula attribute to [mass]/([height] ∗ [height]).

QuON also supports branch objects to alter the

ﬂow of a survey. By default, after a survey object

has been processed, the system moves to the next sur-

vey object in the ordering speciﬁed by the researcher.

Branches allow conditional logic to alter how the next

survey object is selected. Branch objects use a simi-

lar syntax to calculation objects to allow speciﬁcation

of a PHP boolean expression that can include a re-

spondent’s previous answers, or any previous calcu-

lations. Branch objects also include the name of the

survey object to jump to if the expression is true, and

the name of the survey object to jump to if the ex-

pression is false. For example, if a question named

“hasEmail” asks “Do you have an email address?”, a

branch object with the condition [hasEmail ==

yes

]

could cause the system to skip a question asking for

the respondent’s email address if the respondent does

not have one.

As well as specifying the survey objects to be in-

cluded in a survey, the researcher must also specify

the order in which the objects are to be processed.

When a respondent begins a survey, the ﬁrst survey

object from the speciﬁed ordering is processed and

the survey continues until the last survey object has

completed. The different survey objects are processed

as follows:

Question. Depending on the question type, the ap-

propriate Helper’s display method is called, and

the system waits for the respondent to enter a re-

sponse. When a response is received, it is passed

through the Helper’s validation method. If the val-

idation fails, an error is presented to the respon-

dent and the question redisplayed. Once valida-

tion is completed successfully, the response is se-

rialised and stored in the database. The system

then moves to the next survey object in the order

speciﬁed by the researcher.

Calculation. The abstract mathematical expression

associated with the calculation is parsed and any

reference to previous questions is replaced with

the value of the answer to that question entered

by the current respondent. The expression is then

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

114

evaluated and the result stored in the database. If

the researcher has indicated the calculated value

should be displayed to the respondent, a display

page is presented. The system then moves to the

next survey object.

Branch. The abstract boolean expression associated

with the branch is parsed and any reference to pre-

vious questions is replaced with the value of the

answer to that question entered by the current re-

spondent. The expression is then evaluated and

the system jumps to the survey object with the

name speciﬁed by the branch object as the appro-

priate destination for a true or false result.

Once a researcher has speciﬁed the various survey

objects and the order they should appear in the survey,

the researcher can publish the survey, making it avail-

able to respondents. When a survey is published, the

researcher is given a URL to be shared with potential

respondents. When a respondent accesses the URL,

the ﬁrst survey object is presented (after any neces-

sary authentication; see Section 4 for the different au-

thentication types supported by QuON). The system

processes this ﬁrst object as speciﬁed above, and the

respondent answers questions to progress through the

survey.

On completion of the survey, the respondent is

presented with a “thank you” page. The researcher

can then access the information collected from that

respondent either directly through a Web browser, or

by downloading a CSV ﬁle, with all respondents’ an-

swers, that can be processed by local software tools.

4 CURRENT FEATURES

The QuON framework already offers advantages over

many existing survey systems. The branching logic,

in particular, is extremely powerful. Most alternatives

require either the same condition to be entered for

multiple questions, or questions to be entered multi-

ple times, to support the same level of ﬂexibility as of-

fered by QuON. However, QuON also includes some

other features that make it unique.

One of the limitations of existing survey systems

is the lack of support for identiﬁed, but not authenti-

cated respondents. QuON overcomes this limitation

by supporting the following respondent types:

Anonymous. The system does not request any infor-

mation from the respondent before presenting the

ﬁrst survey object.

Identiﬁed. The system requests a name that uniquely

identiﬁes the respondent. The respondent can

only begin the survey if the entered name matches

an expected respondent for the system.

Auto-identiﬁed. The system requests a name that

uniquely identiﬁes the respondent. The respon-

dent can begin the survey by entering any name

that has not already been entered by a respon-

dent. This mode can be used to allow anybody

to complete a survey, but then to restrict access

so that only respondents can access any followup

surveys.

Authenticated. The system requests a name and

password that uniquely identiﬁes the respondent.

The respondent can only begin the survey if the

entered name and password match an expected re-

spondent for the system.

QuON also supports the publication of metadata

to a registry to allow publication of a dataset. Re-

searchers can enter information such as a description

of the data collected, who the contact person for the

data is, and any restrictions on the access or use of

the dataset collected for a particular survey. When

ready, the researcher can then publish this informa-

tion to a ReDBox (Queensland Cyber Infrastructure

Foundation, 2012) repository using a standard based

on the ISO 2146:2010 standard for Information and

documentation – Registry services for libraries and

related organisations. Other researchers can then dis-

cover the dataset through ReDBox, and may be able

to avoid collecting similar data by gaining access to

what has already been collected.

5 FUTURE WORK

QuON is a platform for the creation and admin-

istration of surveys over the Web. It aims to

overcome some of the limitations of existing sur-

vey systems for research applications, especially

in areas such as health where ethics implications

make the use of online services difﬁcult. An open

source implementation of QuON is available from

http://code.google.com/p/quon/.

QuON takes a unique approach to branching in

surveys, making it much easier to alter the ﬂow of

a survey as it is being completed. This approach is

based on the idea of survey objects, which, in QuON,

can be either Questions, Calculations, or Branches.

Researchers then order the survey objects for each

survey, and the system’s processing rules ensure the

speciﬁed order is followed. Branch objects allow

complex orderings, such as skipping optional ques-

tions, or jumping back to an earlier part of a survey,

based on boolean expressions that can include any

QuON-AGenericPlatformfortheCollationandSharingofWebSurveyData

115

previous answers entered by the respondent. Further,

separating branch objects from question objects al-

lows the same conditional logic to be used from mul-

tiple areas in the survey, removing the duplication that

is necessary in other survey systems.

QuON also supports the export of metadata to fa-

cilitate the discovery of collected data by other re-

searchers. This can enhance the usefulness of any sur-

vey by allowing further research to be conducted on

any collected data, rather than requiring similar data

to be recollected by the new researcher. The system

does not automatically grant access to the collected

data, it simply allows external researchers to discover

that the data exist. The metadata also provides further

information, such as contact details, so the external

researcher can request access to the actual data.

QuON allows multiple users in a group to work

on a survey. In this way, multiple researchers can ac-

cess the same survey. The system does not currently

allow the sharing of survey objects between surveys

or groups, but support for this is planned in future re-

leases. Such a feature would allow the creation of a

pool of questions that could be pulled in to new sur-

veys without having to be completely redeveloped.

A QuON system has recently been deployed for

the Health Behaviour Research Group at the Univer-

sity of Newcastle, Australia. The experiences of the

researchers in this group will be used to evaluate the

current state of the system and further QuON develop-

ment. For example, a feature currently being imple-

mented allows templated feedback sheets to be gen-

erated after a respondent completes a survey, allow-

ing researchers to download documents that are cus-

tomised based on the answers given by the respon-

dent.

REFERENCES

Ader, H., Mellenbergh, G., and Hand, D. (2008). Advising

on Research Methods. Johannes van Kessel Publish-

ing.

Cake Software Foundation (2012). CakePHP Cookbook.

Cake Software Foundation, 2.x edition.

Checkbox Survey (2013). Checkbox Survey: Survey Soft-

ware. http://www.checkbox.com, Accessed 2013-01-

11.

Digivey Survey Center (2012). Digivey Plus collects

web survey data online. http://www.digivey.com/

digiveyplus.htm, Accessed 2013-01-11.

FluidSurveys (2013). Online Survey Software — Create

Your Survey In Minutes. http://ﬂuidsurveys.com, Ac-

cessed 2013-01-11.

LimeSurvey (2013). LimeSurvey - the free & open source

survey software tool ! http://www.limesurvey.org, Ac-

cessed 2013-01-11.

Oracle (2012). MySQL Reference Manual. Oracle, 5.5 edi-

tion.

Queensland Cyber Infrastructure Foundation (2012). ReD-

Box - Mint. http://www.redboxresearchdata.com.au,

Accessed 2013-01-11.

SurveyMonkey (2012). Surveymonkey: Free online

survey software & questionnaire tool. http://

www.surveymonkey.com, Accessed 2013-01-11.

Webmyne Systems Inc. (2013). Survey software — mag-

icsurveytool.com. http://www.magicsurveytool.com/

survey-software/, Accessed 2013-01-11.

WEBIST2013-9thInternationalConferenceonWebInformationSystemsandTechnologies

116