Implementation
and Testing
Part One - Survey Implementation (cont'd)
Web Site Design
A number of online resources exist which will 'build' your survey
automatically; all you have to do is select a template and type in
the questions and the online host does the rest. There was also the
possibility of using downloadable software, which would, again create
a template, with all the coding already created, to just add in the
questions and upload the finished site to the Internet. However, it
was decided in the early stages of the project to design and administer
the web site, manually. Templates built using software or online resources
do not offer the flexibility which was required to create the different
themes that could be selected or change the font types and sizes.
The Themes and fonts were an important part, not only of the site
design, adding to its usability, but were also an integral part of
the survey itself. It was, as previously mentioned hoped to show patterns
of preference towards particular colours and fonts. The eight different
themes used can be viewed in full in Appendix Two of this report.
As this particular type of site design had never been attempted before,
it was also regarded that it would be a valuable learning curve, by
incorporating it into the project.
Design Procedure
Macromedia Dreamweaver Version 4 (Sparber, 2001) was used to create
a basic Template for the page structure. The survey questions were
then transferred into the web document. Figure 2, below shows the
page layout. 'Au Natural' is the default theme used when someone first
visits the site. Full screen shots of each of themes used can be viewed
in Appendix Two of this report.
CCS (Cascading Style Sheets) (Deitel, 2000) were used to create the
eight themes. Every page displays the list of links shown here on
the right. (Figure 3:Theme Links) The corresponding bi-colour bullet
gives an indication of the colours that match the themes. Style sheets
are a method of formatting any part of a web document, be it just
the font type, the background colour, or even what images to use,
and where. Style Sheets are a great way to allow users to customise
a web page to their own preferences.
This would seem to be an especially useful advantage for dyslexic
users, considering the previous research mentioned in the Literature
Review, regarding adaptation of fonts and background colours. (Westhead,
2000, Wilkins 1996). Basic styles can be incorporated into the web
page itself, but in this case, as there were so many different combinations
of styles that could be selected; it was decided to set up independent
style sheets for each one, which would then just be referenced in
the web page. Using this method also helps speed up page download
time, as only the code for the required style is downloaded, not all
of them.
How it all works: When the user clicks their mouse on one of the links,
a small program, embedded in the web page called JavaScript, writes
a Cookie to the user's computer. The Cookie simply tells the browser
which style sheet to use, (Smoothie, Apple Pie, etc.) and can also
have an expiry date set, so that the Cookie will automatically delete
itself from the users system after a specific length of time. In this
instance, Cookies were set to expire after 30 days. The clever bit
happens when the user moves on to the next page. The JavaScript will
continue to read from the Cookie and load the new page with the same
style sheet. As the expiry date for the Cookie is set for 30 days,
every time the user visits the site within that timescale, the page
will automatically load with the style (or theme) they selected on
their previous visit. The additional pop-up windows on the first page
of the site also use the style sheets and cookies, so that whichever
theme you choose, when the pop-up window opens, it will also have
the same theme applied. Separate style sheets were also used to select
the different Font Types and Sizes. Drop-Down Menus, Figures 4 and
5, shown below, were used for selection of the fonts and sizes.
The separate sections and volume of questions made it necessary to
split it up into several pages, each one linking from the previous
and on to the next. This created a slight problem that would not be
encountered if the questions were all on the one page with a 'SUBMIT'
button at the bottom. How do you record the answers given from all
the pages until you get to the 'SUBMIT' button on the last (6th) page?
Several different methods of implementing this were researched.
ASP (Active Server Pages) is basically an HTML page, which includes
scripts, or small, embedded programs. These scripts are processed
on the server Host - server-side processing - before the page is downloaded
by the user. This allows the page to be downloaded much faster, than
if it was downloaded by the user, then processed - known as client-side
processing. The scripts can contain information to tailor a web page
to the users needs. This information typically comes from data stored
on a database on the server, which assembles the correct data and
sends the requested information to the users' browser.
PHP (derived originally from Personal home Page) is an open source
version of Microsoft's ASP scripting language which also allows scripts
embedded in the HTML code of the page to be processed on the server.
Both of these methods would have been ideal for the type of information
being processed. Not only could the personalisation of the site (themes
and fonts) be executed server-side, allowing faster page downloads,
but a database such as Microsoft Access or MySQL could be used to
store and process all the answers.
Unfortunately, this was not possible, as every reliable ISP (Internet
Service Provider) or Hosting Company who offer web space, charge a
monthly fee for offering ASP, PHP and even database support. Due to
the financial constraints of the project, this was not an option.
The problem of how to store the answers from each page was eventually
solved by simply creating another JavaScript program, this time stored
in a separate file, and called from the web pages as and when needed.
More Cookies were used to store the answers given on each page, and
then on the last page of the survey, all previous answers are called
and added to the answers given on the last page. When the user then
hits the 'SUBMIT' button to send the answers, all answers, including
those from the previous pages, are sent via email to an address specified
in the code.
Many ISP's and Hosts were researched extensively during this stage
of development, and the one finally chosen is a large international
hosting company (Netfirms) whose reliability and security was already
known. Although their FREE hosting package does not support the use
of databases or ASP/PHP, it does support CGI scripting for the use
of forms. The only other disadvantage of using this hosting company
was that they automatically add their own advertising banner to the
top of every page on your site. This did not seem to be a problem
at first as the banner is fairly small and unobtrusive, and does not
interfere with the page layout in any way.
However, the site had been designed taking all aspects of usability,
accessibility and compatibility (see the following section Survey
Testing, for more detail) into consideration. It had been hoped that
the site would warrant validation by the World Wide Web Consortium
(W3C [online]), and the 'Bobby Approved' site run by Watchfire, for
the HTML coding and CSS styles used. Netfirms advertising banner proved
to be a major obstacle for this process. The site can only be approved
by entering the URL (Uniform Resource Locator) to allow the validation
software to check it online. As the software checks each line of coding
in the HTML document, the first few lines of code are that of the
Netfirms Ad banner - which does not have all the accessibility options
required, nor can it be edited. As the software could not bypass this
banner coding to validate the rest of the site, it was impossible
to get the full validation required in order to display the W3C or
Bobby Approved logos, which would automatically inform any visitors
to the site that it was accessible to all. Choosing a monthly-payment
hosting package, which would have removed the banner, could have rectified
this, but the resources required were outside the remit of this project.
