Open/close
all![[Skip instructions]](../generic/trans.gif){kind=small}
![[i]](../generic/instructions.gif){kind=small}
Click on the headings to open them. They will open on this page. Open the following link
for further
information about these headings if required.
Your browser does not support these headings. To ensure that the contents remain accessible, they have been automatically opened so that all the information on the page is displayed.
However, to take advantage of the headings and to ensure that the layout and design of this site are displayed correctly, you are recommended to upgrade to a current version of one of the following standards compliant browsers:
- Internet Explorer (http://www.microsoft.com/ windows/ie/downloads/ default.mspx)
- Mozilla Firefox (http://www.mozilla.org/ products/firefox/)
- Opera (http://www.opera.com/download/)
CLOSEGlossary links are included within this page. If a word appears as a link, clicking on this link will show the definition of the word in a 'pop-up window'. Select the following link for information about these glossary links if required.
- Select the links see the definitions in a pop-up window.
- NB. If you use pop-up window blocking software, you will need to deactivate it for pop-ups on this site to use the glossary links. Alternatively, all glossary definitions can be seen on the 'Glossary' page in the 'Resources' section.
- Use of the glossary links is JavaScript dependent. If JavaScript is disabled, it will be necessary to open the 'Glossary' page to view the definitions. Opening this page in a new window may allow you to refer more easily to the definitions while you navigate the site.
Introduction
This section aims to provide the necessary skills to ensure that good design practices are followed in the creation of an online questionnaire. Alongside other aspects, it provides the supporting technical information for the design practices outlined in the design sections of the 'Online questionnaires' module. The following information is covered:
- Deciding whether to present a questionnaire as a one-page web form or as one that spans multiple pages;
- Implementing a progress bar in multiple-page questionnaires;
- Delivering instructions via pop-up windows and alert boxes;
- Ensuring accessibility;
- Ensuring consistency: Browser issues, screen size, and the use of colour and font.
Single
or multiple-paged questionnaires
One-page questionnaires are generally more straightforward to implement as they consist of a single web form which can easily be processed through the submission of this one form. Where the questionnaire is relatively short and straightforward in terms of structure, this is likely to be the best option.
However, with longer or more complex forms, attempting to present the entire questionnaire in one page may lead to problems such as the following:
- Presenting all questions at the same time may give an impression of greater length which may discourage participants from proceeding.
- Opportunities to validate individual questions or smaller groups of questions as the participant progresses through the questionnaire may be reduced (see the 'Form validation' section). In turn, this may lead to frustration if all questions are validated at once at the end of the questionnaire.
- Although skip patterns patterns can be introduced through linking to anchors further down a page (see the information about linking in the 'Introduction to HTML 1' section of this module) or through instructing participants to skip a question by scrolling to the next, this may not be the most effective or intuitive method of delivering the questions.
- If a participant drops out mid-questionnaire, all data will be lost and there will be no opportunity for collection of partially-completed questionnaires or for identification of questions that may be precipitating drop out.
For longer questionnaires, the use of multiple pages can add to the effectiveness of question delivery, providing clearer routes through the questions and offering the opportunity for a more sophisticated presentation of skip patterns. For example, links to different sections can be added which participants can be prompted to select according to the answer to key questions. However, because all the questions are not made visible, submitted and processed at the same time, a number of extra aspects must be considered
- An indication of progress through the questionnaire must be given, either through the use of a progress bar (see section below) or through structuring the questionnaire into different sections and indicating the nature of this structure to respondents (see the information about questionnaire length in the 'Design of online questionnaires 2: Content' section of the 'Online questionnaires' module). If this is not done effectively, uncertainty over progress or a realisation that the indicators of progress are inaccurate, may lead to frustration and drop out.
- A decision must be made on whether data should be submitted for processing at the end of each page, or at the end of the questionnaire. If it is done at the end of each page, this will allow partially-completed questionnaires to be collected and any problem questions to be identified, but measures must be taken to identify or prevent multiple submission of any sections. If it is done at the end of the questionnaire, it will be necessary to pass information supplied up to a given point in the questionnaire from page to page.
- As participants progress through the questionnaire, they may wish to return to a previous page to review and change answers. Unless measures are taken to ensure that the data they have already entered is still available when they do this, it is important to inform them that answers already entered may be no longer available if they go back. It may also be important to add instructions not to go back through a questionnaire if each page is to be submitted individually, or to add validation routines preventing submission a second time.
Dealing with these issues is likely to add to the complexity of developing the questionnaire as more invloved server-side processing will be required. The 'Server-side processing' section of this guide provides an overview of server-side technologies and their use in gathering data via questionnaires, and includes links on working with multiple-paged questionnaires.
Implementing
a progress bar
Where a questionnaire is delivered across multiple pages, the use of a progress bar can provide an indication of the proportion of the questionnaire completed and may thus reduce drop out rates. This is likely to be more effective when combined with instructions that give an accurate indication of the time needed to complete each section. Two relatively straightforward methods of implementing a progress bar are shown below:
Table
cells
Perhaps the simplest method of implementing a progress bar is to include a two-cell table at the top or bottom of each page. By making the colour of the left-hand cell different to that of the right hand cell, and increasing its width as the user progresses through the pages, this can provide a graphical representation of progress. If this method is used, summary text should be added to describe the function of the table for users of screen-readers and speech browsers.
e.g.
Page 1 of 5
<table width="400" border="1"
bordercolor="#000033" summary="Two-cell table
used to provide a visual representation of progress through
the questionnaire: 20% complete.">
<tr>
<td width ="20%" bgcolor="#000033"> </td>
<td> </td>
</tr>
</table>
Page 2 of 5
(The width of the first table cell has been increased to 40%).
Page 3 of 5
(The width of the first table cell has been increased to 60%).
Similar effects could also be achieved through the use of CSS to style the table and cells.
If this method is chosen, it is important to be aware that there may be some unpredictability in the way that the table cells render in different browsers. Thus it important to test in different browsers and to consider supporting the visual representation of progress with text.
Graphics
An alternative to this is to create a series of graphics using a graphics program such as Jasc Paint Shop Pro, Adobe Photoshop, or Macromedia Fireworks. These can then be added at the top or bottom of each page. This has the advantage of allowing the creation of a more sophisticated or professional-looking progress bar, but it depends on having some familiarity with how these programs work (although it is relatively easy to create basic images using auto shapes such a circles or rectangles). Depending on the size of the images used, it may also have an impact on the overall file size of the questionnaire, possibly increasing download times and leading to increased non-response. If these images are used, alt text should also be added to provide an alternative description for users of text-only browsers.
e.g.
Page 1
<p><img src="bar1.gif" alt="Progress
bar: part 0 of 6" width="398" height="40"></p>
Page 2
Page 3
Delivering
instructions via pop-up windows and alert boxes
When offering specific instructions for different question types, it can be useful to include optional instructions which can be accessed by the user when required or delivered where a user experiences difficulty. This can be achieved through the use of simple JavaScripts to insert instructions in alert boxes and pop-up windows. An example is shown below.
1. Choose the option that most closely matches your opinion on the following statement: [?]
The internet is useful for buying products at a good price.
2. Which of the following do you regularly use the internet for?
(You can select as many options as you like) [?]
Alert
boxes
The following is an example of a link which displays an alert box message when clicked:
The code to produce this link is as follows:
<a href="JavaScript:void(0);" onclick="alert('Alert
box message is added here...');">Click to see the
alert box message</a>
The link "JavaScript:void(0);" is an
'empty' link so that when the user clicks on it, a new document
is not loaded, but some JavaScript is carried out. The action
alert('Alert box message is added here...') is
triggered by the onclick event handler when the
user clicks on the link. The contents of the alert box are placed
within inverted commas. It is important to ensure that the message
does not include inverted commas as this would signal the end
of the message and lead to an error which would prevent the
box being displayed. Rather than using the inverted comma mark
('), the special character codes ‘ (‘)
and ’ (’) should be used to prevent
this.
e.g.
is produced by:
<a href="JavaScript:void(0);" onclick="alert('It’s
important not to use inverted commas. Special characters should
be used instead (‘ and ’)');">Click
to see the use of special characters rather than inverted
commas.</a>
It is also possible to change the message in the status bar at the bottom of the browser window to provide instructions on how to use the link when the user places his/her mouse over the link. In the following link, the status bar text is changed to 'Click to see the alert box message'.
<a href="JavaScript:void(0);" onclick="alert('Alert
box message added here...');" onmouseover
="window.status = 'Click to see the alert box message';
return true;" onmouseout ="window.status = '';">Hold
your mouse over the link to see the changed status bar text.</a>
The code for changing the text is window.status = "Add
status bar text here...". This is triggered by an
onmouseover event handler so that the action occurs
when the mouse is placed over the link.
The action triggered by the onmouseout event when
the user's mouse moves away from the link deletes the text in
the status bar, replacing it with an empty string ("").
In both cases, it is necessary to add the syntax
return true; to preserve the text (or empty string)
that has been set until another instruction to change the status
bar text is reached.
To ensure that the instructions remain accessible when a user
accesses them using the keyboard rather than a mouse, it is
also important to add the onfocus="this.onmouseover();"
and the onblur="this.onmouseout();"
code, which ensures that the same actions will take place when
a user without a mouse tabs to or away from the image.
<a href="JavaScript:void(0);"
onclick="alert('Alert box message added here...');"
onmouseover ="window.status = 'Click to see the alert
box message'; return true;" onmouseout ="window.status
= '';" onfocus="this.onmouseover();"
onblur="this.onmouseout();">Tab
to the link or hold your mouse over it to see the changed
status bar text.</a>/>
Pop-up windows
In a similar way, JavaScript can be used to produce a link which opens a pop-up window when clicked as follows:
Select the following link to further instructions if required. These will open in a pop-up window so you will need to disable any pop-up blocking software to see them.
To create this link, the following JavaScript is placed in the head of the document (Note that the style information included in the example to produce style elements such as the green border and font choices have been removed for clarity):
<script language="javascript" type="text/javascript">
function popInstr(msg){
var win = window.open ('blank.htm', '', 'width=300,height=75,left=150,top=150scrollbars=yes');
win.document.write("<html><head><title>Example
of 'pop-up' instructions'</title></head><body><p>"
+ msg + "</p><p><a href='JavaScript:void(0);'
onclick='window.close()'>CLOSE </a></p></body></html>");
win.document.close();
}
</script>
The following HTML/JavaScript is then placed in the body of the document:
<p>Select the following link to <a
href="JavaScript:void(0);" onclick="popInstr('Further
instructions in a pop-up window');" onmouseover ="window.status
= 'Click to see the pop-up window'; return true;" onmouseout
="window.status = '';">further instructions</a>
if required. These will open in a pop-up window so you will
need to disable any pop-up blocking software to see them.</p>
Learning
activity: Examining the JavaScript code for creating a pop-up
window
![[?]](../generic/questionwh.gif){kind=small}
Examine the different parts of the code to try to establish
what their functions are. Select each to see explanations.
<script language="javascript" type="text/javascript">
Scripts in a document must be surrounded by the
script tags <script></script>.
This tells the browser that what follows is a script
and indicates which scripting language is being
used to allow it to interpret the information correctly.
This declares a function called popInstr
and tells it to expect an argument called msg
to be included when the function is called.
See the 'Introduction
to JavaScript' section for more information
about functions and arguments if required. The
function is surrounded by curly brackets ({}).
var
win = window.open ('blank.htm', 'blank', 'width=300,height=75,left=150,top=150,scrollbars=yes');
This declares a variable called win
which consists of a new window created using
the window.open method. The new
window opens an HTML document saved in the same
folder called blank.htm which is
given the name blank. This window
is set to a size of 300x75 pixels and is placed
150 pixels from the top-left corner of the user's
screen. It is given scrollbars, but no tool
bar, status bar or menu bar.
It is important to add all the settings information with no spaces to ensure that the browser can recognise it correctly.
win.document.write("<html><head><title>Example of 'pop-up' instructions'</title></head><body><p>"
+ msg + "</p><p><a href='JavaScript:void(0);'
onclick='window.close()'>CLOSE </a></p></body></html>");
This writes HTML to the new window (win)
using the document.write method.
Everything within the brackets is written to
the document in the window. The contents are
added as strings between inverted commas. The
syntax '+ msg +' tells the function
that the argument called msg should be fed in
to the function at this point when it is called.
The plus signs are used to add this argument
to the contents of the two strings on either
side (i.e. the message is added to the HTML
written to the new window). See the 'Introduction
to JavaScript' section for more information
about arguments if necessary.
The HTML written to the window includes an
'empty' link with an onclick event handler that
closes the window when the link is clicked using
the window.close()
method.
(<a
href='JavaScript:void(0);' onclick='window.close()'>CLOSE
</a>)
CSS or HTML attributes and values could be added at the relevant points to change the style of the contents of the new document.
The document.close method is then added to
indicate that the process of writing to the
window (win) is complete.
<a href="JavaScript:void(0);"
onclick="popInstr('Further
instructions in a pop-up window');" onmouseover ="window.status
= 'Click to see the pop-up window'; return true;" onmouseout
="window.status = '';">
This is an 'empty' link which means that when
the user clicks on it, a new document is not
loaded, but a JavaScript function is carried
out. There are three event handlers onclick,
onmouseover,
and onmouseout.
When the user select the link(onclick)
, the function popInstr
is called and the argument 'Further
instructions in a pop-up window'
is fed in to the function. When the user holds
his/her mouse over the link (onmouseover),
the status bar text changes to 'Click
to see the pop-up window'. When the
user moves his/her mouse away from the link
(onmouseout),
the status bar text is deleted, changing to
an empty string ('').
For further information see the following link for a range of JavaScript examples with source code specifically related to windows.
![[External Link - opens in a new window]](../generic/external.gif){kind=small}
http://www.irt.org/script/window.htm
N.B. It should be remembered that some users may not have JavaScript
activated in the browser and the use of alternative instructions
should be included which will display for users without JavaScript
through the <noscript> tag - see the 'Introduction
to JavaScript' section of this guide.
Accessibility
There are a number of simple steps that can be taken to increase the accessibility of an online questionnaire and its associated web pages. These can ensure that the contents are accessible to users with a range of user-agents including text-only and screen reading browsers and other assistive technologies, and mobile web-enabled devices.
Designing the site to be compliant with standards set out by the World Wide Web Consortium (W3C) is an important step in ensuring accessibility. The 'Resources' section of this 'Technical guide' module includes a link to W3C's validation tools which allow web pages to be checked for standards compliance. By uploading a page or entering the URL, the tools will run automated tests and report on any pieces of invalid markup in the pages.
It is also good practice to separate content from presentation in web pages by using Cascading Style Sheets (CSS) to add design features (See the 'Introduction to CSS' section of this guide). This allows the user to control how the site should be presented, allowing style information to be overridden to allow presentational features such as text size, font, colour and layout to be changed according to need or preference. It also maximises the possibilities that the site will be fully accessible to a range of user agents (e.g. browsers, media players and assistive technologies).
Beyond this, the W3C Web Accessibility Initiative guidelines (WAI)
includes a wide range of measures which should be taken to ensure
that a website is accessible (http://www.w3.org/
WAI/intro/wcag.php). The guidelines divide these measures into
Priority 1, 2 or 3 according to how essential they are to accessibility.
Some key measures that should be taken for accessibility are shown
below.
Key measures
-
If scripting and third-party plug-ins (e.g. Flash) are used, ensure that all content remains accessible when these are not available in the user's browser. Provide alternatives to scripts if necessary through the use of
<noscript></noscript>tags (see the 'Introduction to JavaScript' section of this guide) and provide text-only alternatives to multimedia; -
Make explicit links between form labels and form elements using the
<label for="name of element">tag, and make sure that there is a logical tab order within forms to make them fully useable and to ease navigation via keyboard (see the 'Web forms' section); -
Provide text alternatives for graphics to ensure the site contents can be accessed in non-graphical browsers. It is important to make sure that this provides an adequate description of the value of the image on the page. Descriptions are added using the
alt="Add description"attribute of the image tag as follows:<img src="logo.gif" alt="University of Leicester Logo" width="100" height="50" /> -
Use descriptive links to ensure links make sense out of context and make them accessible to user agents that present all links on a page as a simple list. e.g.
Select the following link for more information about accessibility
rather than
For more information about accessibility, click here
-
Ensure that colour schemes are appropriate so that there is adequate contrast between the colours used. Ensure that different colours are not used to provide information that can not be otherwise gleaned by users who can not distinguish between them
A service called 'Vischeck' allows pages to be tested for suitability for colour-blind users. The service simulates the appearance of pages to users with different forms of colour blindness:
-
Avoid excess movement on screen or flickering screens caused by elements such as animations or 'blinking text' which can cause problems for epileptic users.
-
Use relative sizing to make contents flow into viewing areas of different sizes and to allow users to control the size of text through their browser settings. e.g.:
<table width="95%">rather than
<table width="560"> -
Use the
summary="Add description"attribute to describe the purpose of tables, especially if they are used for layout rather than data. Organise data in tables to ensure that it makes sense if read by screen-reading software (usually row by row from left to right). -
Use consistent and clear navigation, colours and icons and make language clear and as simple as possible for the purpose and intended audience of the questionnaire. This will make the contents as accessible as possible to users who may have reading and/or cognitive disabilities.
Consistency
The following issues need to be considered alongside the accessibility information given above. This will ensure that the questionnaire appears as consistently as possible in different browsers and on different computer systems.
Browser
issues
It is important to design a questionnaire with an awareness that participants may be using a range of different browsers and that that the way the questionnaire looks in these browsers may vary.
Information on the main browsers available at the time of writing is available on the Worldwide Web Consortium (W3C) website at the link below along with statistics on the usage levels of each (though it should be noted that the statistics are based on users of the site and should thus be generally considered to be skewed in favour of more technically proficient users).
http://www.w3schools.com/browsers/default.asp
At the time of writing, estimates suggest that at least three-quarters of web users have Microsoft Internet Explorer (many suggest that the proportion is substantially higher than this), with the vast majority of the remainder using the Mozilla Firefox browser.
Maintaining a straightforward design for the questionnaire, ensuring it is designed for accessibility (see above) and validating the CSS and/or HTML used to create it (see the 'Resources' section of this guide for further information if required) will limit differences of appearance in different browsers. However differences in aspects such as the size and appearance of form elements and tables may remain. It is thus good practice to test pages on as many different browsers and systems as possible, and as an absolute minimum to install the latest versions of the three most popular browsers on your desktop and use these to test. Friends and acquaintances with different systems (e.g. AppleMacs or PCs) and older versions of browsers can also be called on to test for any problems.
Where design problems are found in particular systems and browsers, an attempt can be made to change the design to best accommodate them, bearing in mind usage statistics, the context of the research, and the overall balance of probability of a participant having this browser.
It is also possible to use browser detection JavaScript to identify which browser is being used. A number of tutorials on how to do this as well as free scripts can be found using a simple search for 'browser detection' or 'browser sniffing'. The browser information can then be used to deliver different designs tailored to particular browsers. This can be done either by linking to different CSS files designed for different browsers, or redirecting to different versions of the same questionnaire. However, when considering this, it should be remembered that users may not have JavaScript activated in the browser - see the 'Introduction to JavaScript' section). Aiming for an accessible and relatively straightforward design should avoid the necessity for browser detection.
It is also possible to collect information about the user's computer and browser alongside the data from the questionnaire (see the 'Gathering information about participants' section of this 'Technical guide' module). This can allow an overview of the technologies available to respondents to be gained. 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.
Plug-in
detection
Where a questionnaire includes multi-media, it should be remembered that users may not have the necessary technology installed. In many cases, the user's browser will automatically detect that a particular plug-in is required and prompt the user accordingly, although many users may be reluctant to proceed with installing software on their machines. Clearly specifying minimum specifications required for the questionnaire and adding an easily accessible link to any plug-in software required may increase the chances of the user doing this.
JavaScript browser detection (or 'browser sniffing') can also be used to test whether or not the user has certain technology installed. If, for example, Macromedia Flash content has been used extensively to deliver video or animation as part of the questionnaire, it may be necessary to redirect the user to instructions or alternative content if he or she does not have a suitable version of Flash installed. The following web site provides a good explanation of Flash detection (and its limitations) along with free scripts to carry it out:
http://moock.org/web
design/flash/detection/moockfpi/
The latest version of Macromedia Flash also allows for files to be published with automatic detection of which version of the Flash player is being used to access them, followed by automatic redirection to an alternative site where the version is not adequately up to date.
Screen
size
When designing a questionnaire, it is important to try to ensure that it can be viewed successfully on a range of different screen sizes. At the time of writing, the most common screen size is 800 x 600 pixels (with an approximate typical page viewing area of 745 x 415 pixels when the space taken by the browser toolbars is considered). However other common screen sizes are:
| Screen size | Typical viewing area |
|---|---|
| 640 x 400 pixels |
585 x 295 pixels |
| 1024 x 768 |
970 x 580 |
| 1280 x 1024 |
1225 x 840 |
Increasingly, web statistics such as those from the Worldwide Web Consortium (W3C) indicate that very few computers have screen settings of 640 x 400, and it is common practice for web developers to design their pages with 800 x 600 as a notional minimum.
If, however, a researcher wishes to ensure that his or her questionnaire will be fully accessible to those who may be using older equipment, he or she may decide to design for a 600 x 640 minimum. This assumes that any items such as images or tables which are larger than 585 x 295 pixels may not be fully visible in the browser window that and scrolling will be required.
Limiting width is particularly important as horizontal scrolling tends to produce serious usability problems which may affect response rates and validity of results. Although vertical scrolling does not tend to present such serious usability problems in general web use, this may need to be given particular consideration for online questionnaires. For example, if the possible responses to a particular question are not all visible at the same time, this may have an effect on results. For this reason, keeping the height of each question to a maximum of 295 pixels should be considered.
To test how a questionnaire appears at different sizes, a link to a pop-up window set to the test size can be used. The HTML / JavaScript to achieve this is as follows:
<p><a href="JavaScript:void(0);" onclick="window.open('question.htm','test','width=585,height=295,scrollbars=yes')">Screen
size test</a></p>
It is necessary simply to replace 'question.htm' with the path to the test page, and to change the width and height to the desired test size.
In the following example, a test link is used to check whether the following question causes scrolling problems at a 640 x 400 screen size:
5. Which of the following do you regularly use the internet for?
(You can select as many options as you like. If you would like to remove a selection
you have made, select it again to deselect it).
E mail
Finding information about things to buy
Making purchases
Entertainment
Finding general information
Educational courses
Downloading music
Discussion boards
Real-time chat
Select the following link to open the question in a new window
set to 585 x 295 pixels. You should close the new window to
return to this page.
Colour
When choosing a colour scheme for the questionnaire it is recommended that web-safe colours are used to ensure consistency. The 'web-safe' colour palette consists of 216 colours which are not subject to variation on different types of monitors and systems. The following link provides a palette of web-safe colours organised by either hue (colour) or value (lightness). This makes it easier to design appropriate colour schemes using these colours.
Font
When choosing a font for use in the questionnaire, it is important to remember that the user's computer may not have particular fonts that you may wish to use. If the user's browser automatically replaces a font that you have used, this may have an impact on the layout and usability of you questionnaire, e.g. by having unanticipated effects on the spacing of possible responses or increasing the width of items beyond the smallest screen sizes.
Using common fonts is recommended, as is the use of 'font-families'
which provide the browser with information about which fonts should
be used as a replacement in a case where a particular font is not
available. Thus the use of the HTML tag <font face="Verdana,
Arial, Helvetica, sans-serif"> (or the CSS rule body
{ font-family: Verdana, Arial, Helvetica, sans-serif}) tells
the browser to use Arial if Verdana is not available, followed by
Helvetica, and finally by the default sans-serif font. The questionnaire
can then be checked with each of these fonts to ensure that
the size, spacing and layout is suitable with each.