Web Design (WED)

Open Assessment 2009-10

Issued: Wednesday 17th March 2010

Submitted: 11th May 2010

(Final Mark: 48/50 (96%))

Ambient 2010 Conference Website Design

Introduction

The specification detailed that a web application which will simulate a conference-booking website was to be implemented. Following the given requirements, a website was created that used HTML, PHP, JavaScript and CSS throughout. With the lack of a MySQL data link however, the website does not hold information, but instead sends the given information to the specified e-mail address.

This report explains the design rationale behind the website, by means of explanations accompanied by examples. There are six main sections that are used to identify the requirement basics and these are; Functionality, Usability, Standard conformance, Accessibility, Simplicity and maintainability, and Errors.

In addition to these, there are sections that describe the design patterns involved in the decision making, and the testing that was done on the website in order for it to be as platform independent as possible.

Requirements

Information about the conference was given, and this had to be implemented into the website. The most basic information that the user must know is that there are to be a number of tutorials taking place on Thursday 8th July, and a Research day on Friday the 9th along with a social dinner that evening. Along with this information, the prices for such events also need to be given, along with details of the accompanying persons programme that can be attended by any guests the user may take. Accommodation is also available from Wednesday 7th up to and including Friday 9th. Details of the user must be captured, and limitations on international addresses and phone numbers cannot be in place.

The given requirements state that the website must present;

• The conference programme.
• Travel Information.
• Links to Local Information.
• A facility to register for the conference.
• A facility for booking accommodation.

As there is no underlying database, as explained before, details will be sent via e-mail and it is assumed that payment will be made by cheque upon arrival. In terms of security, POSTed data does not appear in the address bar, it is put into session variables straight away upon page load. The site must be as platform independent as possible, and so testing must be done to ensure that it works on at least the main browsers.

Patterns

'Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution of that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice' (Edwards: 2009 cited in Alexander et al: 1977).

Three design patterns were used in order to create the website, each was found on Yahoo's Developer Network (2009), and these are;

• Page Grids.
  
• Left Navigation Bar.
  
• Progress Bar.

Below are the descriptions for each of the three patterns taken from Yahoo.

Based on this design pattern, a left hand navigation bar was opted for. This enables the user to quickly find the right page that they are looking for.

A progress bar keeps the user informed about where they are in a certain process, there is only one section of the website that needs such a bar and that is conference registration. During registration there are several pages to go through, and so on each page a progress bar is displayed with the current page being greyed out. This keeps the user informed about how far along the registration process they are.

Deciding on the layout can always be hard as there are a number of standard layouts that can be chosen from. The chosen layout is a 2 column liquid layout, which is explained in more detail in the 'Simplicity and Maintainability' section. This is an ideal layout that keeps the navigation to the left, while the content is to the right and as the name suggests, it is scaleable.

Functionality

This section lists each page and describes the functionality that each has implemented. Each listed page has an accompanying image (other than the header, footer and navigation bar) that supports the text and demonstrates that the required functionality for the particular page and the site overall has been met.

-Home (index.php)
This page is the basic introduction to the conference. It gives basic details about the conference, how bookings for both conference and accommodation can be made, as well as how bookings for the conference dinner and accompanying persons program can be made.
As the site is intended for conference delegates, it is more than possible that they already have an in-depth knowledge on what will be taking place. For this reason the first section (personal details) of the registration form is shown, this is an attempt to reduce the number of clicks needed to register and can be seen in Fig1.

Note: For this and all other pages that require the input of personal details, a gender selection has not been implemented as, unless there is an ongoing survey of types, there is no need to ask whether a delegate is male or female.

(Fig1: Author 2010, The index.php page showing basic conference information and a quick registration panel)

-header.php
This page contains only the title image that also has a link to index.php. As this page is called into every other page with the PHP include function, it does not matter which page is currently shown as a single click on the title will take you straight back to the index.php page. The logo for this site is loosely based on the logo from the Ambient Technologies website.

-navigation.php
This page contains the navigational links that enable the user to browse the site, and like header.php it is called into every page with the PHP include function.

-footer.php
This page contains the copyright information and university contact details. Like header.php, it is also called to every page with the PHP include function.

-Conference Programme (programme.php)
This page displays details of the conference in a tabular form. The details are split into three categories; Tutorials, Research and Dinner. All three categories appear as text links at the top of the page that each link to their counterparts within the page by use of page anchors. Each heading then has a link to the right hand side, titled 'Top' and single click will send the user straight back to the top of the page. In this instance, an anchor placed at the top of the page has been linked to as seen in Fig2.

(Fig2: Author 2010, Anchor at the top of the page)

-Travel Information (travel.php)
This page is much like the conference programme page, in terms of using anchors linking menu items to their counterparts further down the page (Fig3), as well as the inclusion of a link ('Top') to link back to the top of the page. The information on this page was taken from the University of York's travel website (University of York: 2009) for which a small link is given at the bottom of the page. This pages gives the user easy accessibility to information regarding travel by; Rail, Taxi, Bus, Car/Motorbike or Bike. For simplicity, the original links included on the university's website have been kept, although now highlighted and underlined for ease of use.

(Fig3: Author 2010, Travel information page showing the anchor links)

-Local Information Page (local.php)
This page, like the conference programme and travel information pages before it, also uses anchors in order to link menu items to their counterparts elsewhere on the page. The page displays tabular information relating to Hotels, Bed and Breakfasts (B&B's) and Tourist attractions within the city of York.

The first section 'York' gives a brief history of York, which in turn relates to some of the tourist attractions held within the last section 'York - Tourism'. The information given is nothing more than general knowledge, but a link is provided to the Visit York website so that further, more detailed, information about York, its attractions and accommodation can be obtained.

The second section is split into two sub-sections, Hotels and B&B's. A number of accommodation options are provided, neatly laid out in an easy to read tabular style as seen in Fig4. Each heading is a link to an official website for the relating accommodation (dependent on whether an official site is available). Despite a link to an official website, each option has one or all of the following associated with it; Email, Tel, Fax and Address. As the site does not include a function to book accommodation with outside sources, the inclusion of contact details is intended to help the user.

The third section focuses on the tourist attractions, and like the second section it too is displayed in a tabular fashion. Each attractions header is linked to an official site and each has contact details relating to it.

(Fig4: Author 2010, Local information page showing two hotels and the tabular layout that they have)

-Accompanying Persons' Programme (apersons.php)
This page is in addition to the actual conference registration page, as while it is possible to book accompanying persons when registering, this page enables additional accompanying persons to be booked quickly without having to cancel and go through the full booking process once again.

There are actually a few sub-pages attached to this main page as seen in Fig5, Fig6 and Fig7. Once the user has entered in all the details, they are then taken to a confirmation screen. The front of this page simply asks the user to click continue to see the bill if they are happy, while behind the scenes calculations are being made that calculate the total cost that has been accumulated from the choices made. These variables are then passed onto the following page that displays the bill. The user can then select to send the bill to their provided e-mail address.

Note: Ideally, there would be a underlying database in which a registered user would be given a reference number. This reference number can then be used in order to book accompanying persons, so to not have anyone simply registering accompanying persons without first registering for the conference. Without the underlying database, this is not possible.

The sub-pages for this section are;

-accreg.php (calculates and sets session variables)

(Fig5: Author 2010, accreg.php displaying information regarding the following processes)

-afinish.php (displays variables in a bill structure, clicking on send will take the user to amail.php)

(Fig6: Author 2010, afinish.php displaying information as a bill)

-amail.php (sends the information to given e-mail address)

(Fig7: Author 2010, amail.php displaying information that an e-mail has been sent to the provided address)

Note: The name, Andy O'shea and University contact information is given as test data only.

-Conference Registration (registration.php)
This page is the first in a string of pages that enables the user to successfully register for the conference. There are a number of validation functions that happen, but those will be discussed in the next section. Just like with index.php, this page enables the user to enter their personal details (Fig8), before clicking next and moving onto the type of registration wanted. Across the top there is a progress bar that states the current page the user is on. As it is not a menu, it is not possible to go back or forward any pages, for reasons described in the following section and also mentioned in the progress bar design pattern earlier. Each box on this first page that has an * is mandatory. Failure to fill in a mandatory field will result in an error being displayed to the user.

(Fig8: Author 2010, registration.php showing personal details for test data)

-registration2.php
The second page focuses on the type of registration (Fig9); Full, Research or Tutorial. If the research type is selected then selecting lectures is optional, while if full registration or tutorial registration are selected, selecting which lectures to attend is mandatory. Validation functions make sure that conflicting lectures cannot be selected; this is described in the next section. Up to five additional dinner tickets can also be selected, although five was selected to be the highest number of additional guest tickets, there is actually no limit on the amount of people that can register due to the absence of an underlying database and functions that would decrement an initial limit of either guests or delegates. So it was decided that there would be a limit on the amount of additional dinner tickets in order to better simulate a fully functioning registration system. As anyone selecting 'Tutorials Only' will not have access to the conference dinner, validation has been set up that makes it impossible for additional dinner tickets to be brought with that particular type of registration.

(Fig9: Author 2010, registration2.php showing the types of registration, tutorials and amount of additional dinner tickets that can be chosen)

-registration3.php
This third page focuses on the accompanying persons programme (Fig10). Having already provided personal details, the only things to select here are the amount of accompanying persons and the number of tickets needed. Validation is used here to stop the over/under buying of tickets, this is described in the next section in more detail.

(Fig10: Author 2010, registration3.php displaying information for accompanying persons)

-registration4.php
This fourth page focuses on booking accommodation (Fig11); the user can select how many people require accommodation, what types of rooms they want and the nights that they will stay. Simple validation is set up to stop too many or too few rooms being booked. Again the number of people that can apply for accommodation is limited to six for the same reasons as mentioned before with the accompanying persons. Six is the limited number (unlike five with accompanying person), as the total amount possible is one delegate and five accompanying guests.

(Fig11: Author 2010, registration4.php displaying information for accommodation)

-registration5.php
This fifth page gives the user details on what will happen next (Fig12), clicking 'Submit' will take the user to the bill. The code within this page calculates the total values, which are then carried across to the next page.

(Fig12: Author 2010, registration5.php displaying further information to the user)

-finish.php
This sixth page shows the information provided along with the total costs in a bill like structure (Fig13). From here the user can either print the page out using the browsers print function, or select send in order to send a copy to the provided e-mail address.

(Fig13: Author 2010, finish.php displaying the final bill)

-mail.php
This last page is only displayed if the user decides to have a copy of the bill sent to the provided e-mail address as shown below in Fig14.

(Fig14: Author 2010, mail.php displaying information to the user regarding the e-mail being sent)

-Book Accommodation (accom.php)
Just like the accompanying persons programme page, it is possible to book accommodation separately from the overall conference registration. The user must fill in their personal details and then select how many people and how many rooms are required as seen in Fig15. The limit is set to six, as mentioned before it is in order to provide a more realistic simulation of the booking process. Once the user has finished entering their data, they are able to move onto the next page.

Note: Ideally, there would be a underlying database in which a registered user would be given a reference number. This reference number can then be used in order to book accommodation, so to not have anyone simply registering for accommodation without first registering for the conference. Without the underlying database, this is not possible.

(Fig15: Author 2010, accom.php displaying input boxes for personal details and accommodation details)

-accomreg.php
This second page provides the user with information about what will happen next (Fig16). Again, behind the scenes the code is calculating the overall cost. The code of which will be seen in a later section. Selecting 'Submit' will take the user to the next page that shows the bill, as well as passing on the newly calculated variables.

(Fig16: Author 2010, accomreg.php displaying further information for the user)

-accfinish.php
This page displays the bill (Fig17), which can be printed by the user. The user from here can also select 'Send' to have a copy of the bill sent to their provided e-mail address.

(Fig17: Author 2010, accfinish.php displaying the bill)

-bmail.php
This final page is displayed once the user selects to send a copy of the bill to their provided e-mail address. The page merely confirms the address to which it was sent as seen below in Fig18.

(Fig18: Author 2010, bmail.php displaying information to the user regarding the e-mail being sent)

Usability

This section demonstrates the usability that each page presents. It does not display every coded function, but instead concentrates on the more important validation checks that occur for each page in order to show usability. The general layout for each page has been done in such a way that is easy for the user to understand. It is easy to navigate the site and easy to complete the required functions, if a user is having trouble, then an error that is displayed through validation will point the user in the right direction.

Nielsen (2009) defines usability by five quality components which are;

• Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
• Efficiency: Once users have learned the design, how quickly can they perform tasks?
• Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
• Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: How pleasant is it to use the design?

-Home (index.php)
As described in the Functionality section, this page is intended to give a very brief overview of the conference, along with offering access to register quickly. As with all the pages, the header, navigation and footer pages are included by means of PHP include (also seen in Fig2).

The information is set out in a tabular format, with the information itself taking the left column and the quick registration panel taking the right column as seen in Fig19. The layout feels and looks better than other layout formats which were tried, which also included having the quick registration below the conference information.

The validation behind the quick registration panel is exactly the same as the conference registration page, and so details of it are provided later.

• Learnability: The basic task of this page is to gather basic information before moving on to another page, or to start the registration process. Both are very easy.
• Efficiency: Links can be clicked on easily, and the first part of the registration process is easy to understand, and quick to complete.
• Memorability: After returning to the page after a length of time away, the page will not be any harder to use. If anything it will become easier as it has been used in the past.
• Errors: The only errors that can be made are during the registering of personal details. For some errors, validation will pick them up and inform the user about their mistake.
• Satisfaction: The design is minimilistic. There is basic information about the conference and website as a whole, with the registration of personal details surrounded by a box in order to distinguish it.

(Fig19: Author 2010, index.php displaying the tabular format for conference information and registration)

-header.php, navigation.php and footer.php
As mentioned before, these pages contain very little information as they are simply called into each page using the PHP include function, and as such the code of these pages is very simple and do not even contain header, title or body tags. If these pages where to contain such tags, then they too would be called into a page using PHP include, meaning that the page will end up with two sets of header, title and body tags.

The header page contains the title image only that is linked to index.php in order to return any user to the home page. The navigation page contains links to each one of the main sections (and also the home page) while the footer contains copyright information and the university contact information. By using PHP include on each page, these are always present , especially in regards to navigation.php, which provides the main navigational functionality to the site.

Note: These pages are merely included in the others and so the five components do not apply to them separately.

-Conference Programme (programme.php)
As described before, this page details the conference events. In terms of usability, it is important that the user is given a way to quickly get to the information they require. For this reason anchors were used in order to allow links to link to words within the page itself as seen in Fig2. A small text menu is placed near the top just under the page heading and each link then links to its counterpart further down the page as seen in Fig20. The decision was taken to have a link that takes the user back to the top of the page also, as it only seems logical that if the user wants a function that can quickly take them to the bottom, they would then also want a function to take them back and so each sub-heading has the word 'Top' to the right of it, which of course links back to the top of the page.

In this case, a table consisting of a single row with two columns has been used for each sub-heading in order to present the information nicely. The actual main content is not held within a table, as a table is simply not needed.

• Learnability: Easy to access information, with anchored links from the top to each section, and from each section to the top.
• Efficiency: It is very easy for users to obtain the information they need quickly.
• Memorability: Even after time away from the site, users will still be able to use this page with ease.
• Errors: No errors can be made on this page. The page contains information only.
• Satisfaction: The page is designed so that every section of information is clearly distinguished as a section of information, and to this end the layout makes the page easier to use.

(Fig20: Author 2010, programme.php displaying the conference programme complete with anchor links)

-Travel Information (travel.php)
Like the conference programme page, this too is designed to have its information quickly accessed by use of anchor links. The information from this page is taken from the University of York's travel website (University of York: 2009), and as there are links within the text it was deemed that it would be more user friendly to have those link accentuated by means of using bold, underlined and italicised text as can be seen in Fig21. Also like the conference programme page, each sub-heading is contained in the left side column of a single row, double columned table. The actual information is not contained in a table, again as a table is not needed.

• Learnability: Easy to access information, with anchored links from the top to each section, and from each section to the top.
• Efficiency: It is very easy for users to obtain the information they need quickly.
• Memorability: Even after time away from the site, users will still be able to use this page with ease.
• Errors: No errors can be made on this page. The page contains information only.
• Satisfaction: The page is designed so that every section of information is clearly distinguished as a section of information, and to this end the layout makes the page easier to use.

(Fig21: Author 2010, travel.php displaying travel page complete with anchor links)

-Local Information Page (local.php)

Like the previous two pages (programme and travel information) this page again uses anchor links. The information consists mainly of available accommodation and tourist attractions, and so each different accommodation item as well as each different tourist attraction is held within a table. As this is tabular data, a table seemed the best way to display it, with alternatively coloured rows (white and grey) in order to be more usable. This colour scheme helps avert confusion when looking at many rows simultaneously as seen in Fig22

• Learnability: Easy to access information, with anchored links from the top to each section, and from each section to the top.
• Efficiency: It is very easy for users to obtain the information they need quickly. Each sub-section (i.e., hotels, tourism) is also clearly marked and the information given in a tabular style with every other row being greyed out, to avoid confusion when reading quickly.
• Memorability: Even after time away from the site, users will still be able to use this page with ease.
• Errors: No errors can be made on this page. The page contains information only.
• Satisfaction: The page is designed so that every section of information is clearly distinguished as a section of information, and to this end the layout makes the page easier to use.

(Fig22: Author 2010, local.php displaying the local information page with tabular data and alternating row colours)

-Accompanying Persons' Programme (apersons.php)
This page allows the user to only register accompanying persons, by means of entering their personal details and the amount of accompanying persons and tickets required as seen in Fig23.
A number of validation functions are used that help the user to correctly enter their data which include; Blank field validation, validating the amount of tickets being brought and e-mail validation. Below is the Javascript code along with a brief explanation on how it works. The telephone numbers are supposed to be given with full country code, and so to help the user, a link is given to a site that displays all country codes. Along with the validation of this page, it has been made very simple for any user to use.

Note: It was decided that there would be no validation as such for the phone number, as there can be many different types/lengths of phone numbers from around the world. E-mail is a more important field to validate, with the added bonus of e-mail addresses having the same format world wide.

• Learnability: The basic task for this page is to book accompanying persons. In order to do this, the field must be filled in, and this is an easy task for the user to accomplish.
• Efficiency: The task of booking accompanying persons is easy to achieve. All the information needed is available and it is up to the user to complete to form.
• Memorability: Even after time away, the layout of the form the user must fill in is still very logical and easy to use.
• Errors: Errors can be made on the form, but for certain aspects (i.e. e-mail, number of tickets) the validation will check and inform the user on errors they have made. This then allows the user to correct the mistake(s).
• Satisfaction: The design is easy to use. The form is held within the content section of the body in an easy to use logical layout, with personal details followed by accompanying persons details.

(Fig23: Author 2010, apersons.php displaying input fields for personal details and accompanying persons)

-accreg.php
As mentioned before this page displays information to the user on what will happen next (Fig5). Behind the scenes though, the variables sent by the form are being captured and placed into a PHP session in order to use them on the next page. The code for which is;

<?php
session_start();
$_SESSION['firstname'] = $_POST['firstname'];
$_SESSION['lastname'] = $_POST['lastname'];
$_SESSION['email'] = $_POST['email'];
$_SESSION['addressline1'] = $_POST['addressline1'];
$_SESSION['addressline2'] = $_POST['addressline2'];
$_SESSION['addressline3'] = $_POST['addressline3'];
$_SESSION['addressline4'] = $_POST['addressline4'];
$_SESSION['addressline5'] = $_POST['addressline5'];
$_SESSION['code'] = $_POST['code'];
$_SESSION['country'] = $_POST['country'];
$_SESSION['tel'] = $_POST['tel'];
$_SESSION['mob'] = $_POST['mob'];
$_SESSION['accomp'] = $_POST['accomp'];
$_SESSION['accompthurs'] = $_POST['accompthurs'];
$_SESSION['accompfri'] = $_POST['accompfri'];
?>

As can be seen, the session variables ($_SESSION['code'],$_SESSION['tel'], etc) are capturing the POSTed variables ($_POST['code'], etc). This actually enables the variables to be used throughout the entire session, and not just the next page. The user only has to then click 'Submit' to be taken to the final bill.

• Learnability: The basic task is done by the code (collecting variables), the user only has to click 'Submit' to continue.
• Efficiency: Information is given, and only one button is available that allows the user to continue to the bill.
• Memorability: Easy to use even after time away.
• Errors: The only possible error would be for the user to click away from the page when they did not mean to. The variables are stored into session variables, so clicking the browsers back button will enable the user to go back to the page, with variables restored.
• Satisfaction: The overall design is easy and pleasant to use.

-afinish.php
This page shows the user the bill (Fig6), pulling the variables from the session variables and also calculating the total cost of the booking made, the code of which is;
$accomptt = 40 * $accompt;
$accompft = 40 * $accompf;
$total2 = $accomptt + $accompft;

The variables accomptt and accomptf represent the days Thursday and Friday respectively and are multiplied by forty each, i.e. two tickets would be eighty. They are both then added together to get the final cost, which is displayed to the user. This cost is then also placed into a hidden text field, the code of which is;

<input type="hidden" name="totalacc" value="<?php echo $total2?>" id="totalacc" />

This allows the total cost to be sent to the next page. If the user chooses to send the bill to their e-mail address, they can click 'Send'.

• Learnability: The basic task is to have the bill produced. This is done by the page and not the user, so it is very easy to use this page. The single button at the bottom of the page allows the user to send the bill to their e-mail.
• Efficiency: The task of the bill being produced is done by the page, using the data the user inputs while on previous pages.
• Memorability: Even after time away, this page is easy to understand.
• Errors: If the user clicks away from the page, simply clicking the back button on the browser will take the user back. The variables are stored into session variables and so information is not lost.
• Satisfaction: The overall design (using a bill like structure) is easy and pleasant to use.

-amail.php
This page pulls the information again from the session variables and the total cost sent from the last page, and then uses the PHP mailto function to send the bill to the provided e-mail address, the code for which was copied and modified from w3schools.com (2010) and is;

<?php
$totalac = $_POST["totalacc"];
$to = "$email";
$subject = "Registration";
$message = "Hello,
Please print and bring the bill below, you will be expected to settle the bill upon arrival. If any of the details are wrong, please contact us to correct them.

----------------------------------------
Name: $firstname $lastname
Address:
$addressline1
$addressline2
$addressline3
$addressline4
$addressline5
$code
$county

Tel: $tel
Mob: $mob
----------------------------------------
Accompanying Persons: $accompper

Number of Tickets:
Thursday: $accompt
Friday: $accompf

Total Accompanying Persons Cost: $totalac
----------------------------------------
Payment will be accepted by either cash or cheque upon check-in. Please check-in at the main office upon arrival.

Regards,
The Ambient Technology Team
";
$from = "Ambient Technologies";
mail($to,$subject,$message);
echo "An Email has been sent to the provided address: $email.";
?>

As it can be seen, the message layout is done in such a way that it resembles the bill from the previous page, as seen in Fig24. As the message is sent from the PHP server, it has the address from that server. i.e. postmaster-193384@host.com. From here the user can simply select another location from the navigational pane (Fig7).

• Learnability: The e-mail is automatically sent to the user by the page.
• Efficiency: The e-mail is automatically sent to the user by the page.
• Memorability: The e-mail is automatically sent to the user by the page.
• Errors: No errors can be made on this page. Errors made on previous pages regarding e-mail (i.e. the wrong e-mail address is given) will come to light.
• Satisfaction: The overall design is easy and pleasant to use.

(Fig24: Author 2010, The e-mail sent from the server with the values being displayed)

-Conference Registration (registration.php)
This page is the start of the conference registration, and allows the user to enter their personal details (Fig8). Like with the accompanying person's registration page mentioned before, the validation is very similar. The code of which is given below with a brief explanation. Also like the accompanying person's page, a link is given to a page that details the country dialling codes. This is all intended; along with a very simplistic layout to not only bring ease of use to the user, but also to provide full functionality. There is a progress bar near the top that tells the user which page they are currently on (as mentioned earlier). Going back a page (without pressing back on the browser) is not possible, as it would require a refresh for which the data still would not appear within the fields without added code. If it was possible to go forward and skip pages, then the registration form would be incomplete, again unless there was added code that checked otherwise. This would not be too hard as it could be as simple as a variable being incremented with every submit, and so in the end if the variable was not incremented enough an error would occur and explain to the user the steps that had been missed. To keep things simple though, it was decided to not allow users to travel back or forward pages.

• Learnability: Information is given to the user and the only form on this page refers to personal details. It is very easy to complete this first step of the registration process.
• Efficiency: Once on the page, the user must fill in their details. Validation will be done on a few (more important) fields in order to help the user. The overall task of registering user details can be performed very quickly.
• Memorability: Even with time away, the information required is that of the users, and so it is still easy to use.
• Errors: Errors can be made by the user when filling in the form fields. Validation will check the more important fields and display messages to the user regarding any errors.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-registration2.php
This page allows the user to select the type of registration (Fig9). It was designed to be very easy to use, and the validation behind it guides the user to make suitable choices, especially with the lectures. The only validation done regarding dinner tickets, is if the user selects 'Tutorials Only' registration. As the user will not attend the conference dinner, no additional tickets may be brought.

Firstly the user must choose either Full, Research or Tutorials Only registration, with the difference being that any tutorials that are chosen after will have to be paid for separately if 'Research Registration'' or 'Tutorials Only' are selected. This information is given to the user on the page. Red *'s mean that it is mandatory, although tutorials are only mandatory when either 'Full Registration' or 'Tutorials Only' registration are chosen.

Secondly, the user can choose the tutorials that they want to attend. Each tutorial has a time associated with it, and so it is not possible to select conflicting tutorials i.e. Tutorial 4 lasts all day and so no others can be selected. The validation code for this page is;

This page also contains code that captures the POSTed data from the previous page and stores them into session variables, the code is;

<?php
session_start();
$_SESSION['firstname'] = $_POST['firstname'];
$_SESSION['lastname'] = $_POST['lastname'];
$_SESSION['email'] = $_POST['email'];
$_SESSION['addressline1'] = $_POST['addressline1'];
$_SESSION['addressline2'] = $_POST['addressline2'];
$_SESSION['addressline3'] = $_POST['addressline3'];
$_SESSION['addressline4'] = $_POST['addressline4'];
$_SESSION['addressline5'] = $_POST['addressline5'];
$_SESSION['code'] = $_POST['code'];
$_SESSION['country'] = $_POST['country'];
$_SESSION['tel'] = $_POST['tel'];
$_SESSION['mob'] = $_POST['mob'];
?>

These variables are then used later in the registration process.

• Learnability: This page gives all the information required, and is easy to use. Validation displays errors relating to user mistakes, i.e. leaving the registration type blank.
• Efficiency: The user can accomplish the task of selecting the registration type very quickly.
• Memorability: Even with time away, the logical structure of the page means that it is still as easy to use once the user returns.
• Errors: Any errors made by the user will result in an error message being displayed, for example, each tutorial has a time, a user cannot be in two different places at the same time and so if two tutorials are selected that have the same time, an error will occur. An error will also occur, and the user informed, if the user tries to book additional dinner tickets when the 'Tutorials Only' selection has been made.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-registration3.php
This page allows the user to select any accompanying persons (Fig10). It uses the same kind of validation as the separate accompanying person's registration page, but with the exception that this is optional and so if it is left untouched, an 'invalid data' error does not occur. The page is very simplistic and provides the required information that will enable the user to make a suitable choice. The validation code is;

Like the page before it, this page captures the last POSTed data and stores them into session variables to use later. The code is;

<?php
session_start();
$_SESSION['RadioGroup1'] = $_POST['RadioGroup1'];
$_SESSION['CheckboxGroup1'] = $_POST['CheckboxGroup1'];
$_SESSION['CheckboxGroup2'] = $_POST['CheckboxGroup2'];
$_SESSION['CheckboxGroup3'] = $_POST['CheckboxGroup3'];
$_SESSION['CheckboxGroup4'] = $_POST['CheckboxGroup4'];
$_SESSION['dinner'] = $_POST['dinner'];
?>

• Learnability: The page is optional, and very easy to use. If the user wants to select accompanying persons they can do, and then validation checks will happen. If they do not, they can simply go to the next page.
• Efficiency: The task of selecting accompanying persons is very easy. Select boxes are provided for the user which means that they do not even have to type numbers.
• Memorability: Even with time away from this page, it will still be as easy to use upon a return to it.
• Errors: Errors can be made in the form of buying too many or too few tickets. Validation is done to an extent, i.e. if there are two accompanying persons, the user can buy 1 ticket for Thursday and one for Friday, as it is possible that each person may want to go on a different day. It is not possible though to only buy one or less tickets for two people overall, or buy more than two tickets for a single day.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-registration4.php
This page allows users to book accommodation, and like the accompanying person's page previously this is optional (Fig11). It is been designed to be very easy to use, with validation functions that are used to check for invalid input. Information regarding the accommodation is given, with the most important information being that a double room holds two people and a single room holds one person. This means that if three people require accommodation, the room choices will be either three single rooms, or one single room and one double room. It will not be possible, for example, to book two double rooms for only three people. The validation code for this is;

Again POSTed data from the last page is collected and placed in to session variables for use later, for which the code is;

<?php
session_start();
$_SESSION['accomp'] = $_POST['accomp'];
$_SESSION['accompthurs'] = $_POST['accompthurs'];
$_SESSION['accompfri'] = $_POST['accompfri'];
?>

• Learnability: The user can book accommodation on this page. The logical structure of the form and information provided is intended to help make this an easy page to use.
• Efficiency: Achieving the task of booking accommodation is easy, the only problem that may arise is if the user wants to book a double room for a single person. This is not possible to do, and is noted in the information provided.
• Memorability: Even with time away, the site is easy to use upon a return to it.
• Errors: Errors will come in the form of users trying to book too many or too few rooms, or if at least one night has not been selected. In all cases the user is informed by the validation checks.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-registration5.php
This page gives information on what will happen when the user continues (Fig12). The previous POSTed data is also collected and stored into session variables to use later. The code is;

<?php
session_start();
$_SESSION['persons'] = $_POST['persons'];
$_SESSION['single'] = $_POST['single'];
$_SESSION['double'] = $_POST['double'];
$_SESSION['CheckboxGroup5'] = $_POST['CheckboxGroup5'];
$_SESSION['CheckboxGroup6'] = $_POST['CheckboxGroup6'];
$_SESSION['CheckboxGroup7'] = $_POST['CheckboxGroup7'];
?>

On clicking 'Submit' the user is taken to the next page that displays the bill.

• Learnability: The basic task on this page is to click the 'Submit' button in order to continue. The page itself onload would have collected all the POSTed variables to store into session variables.
• Efficiency: Only a click of a single button will allow the user to continue, and so this page is very easy to use and simple to understand.
• Memorability: Even with time away, this page is easy to use upon return.
• Errors: The only error possible is if the user clicks away from the page, upon selecting back from the browser the user is returned. No other errors can be made.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-finish.php
This page displays the bill to the user (Fig13). Firstly the session variables are called and placed into new variables on the page, the code for which is;

<?php
session_start();
$email = $_SESSION['email'];
$dinner = $_SESSION['dinner'];
$reg = $_SESSION['RadioGroup1'];
$lec1 = $_SESSION['CheckboxGroup1'];
$lec2 = $_SESSION['CheckboxGroup2'];
$lec3 = $_SESSION['CheckboxGroup3'];
$lec4 = $_SESSION['CheckboxGroup4'];
$accompper = $_SESSION['accomp'];
$accompt = $_SESSION['accompthurs'];
$accompf = $_SESSION['accompfri'];
$person = $_SESSION['persons'];
$wed = $_SESSION['CheckboxGroup5'];
$thur = $_SESSION['CheckboxGroup6'];
$fri = $_SESSION['CheckboxGroup7'];

Secondly, the costs accumulated throughout the process are calculated according to the prices specified in the original requirements. These costs are then places into variables, and eventually added together for the overall total cost. The code for these calculations is;

if ( $reg == "Full Registration" ) {
$reg2 = 500;
}else if ( $reg == "Research Registration" ){
$reg2 = 400;
}else if ( $reg == "Tutorials Only" ){
$reg2 = 0;
}

if ($lec1 == "T1" && $reg != "Full Registration") {
$lec1c = 100;

}else{
$lec1c = 0;
}
if ($lec2 == "T2" && $reg != "Full Registration") {
$lec2c = 100;

}else{
$lec2c = 0;
}
if ($lec3 == "T3" && $reg != "Full Registration") {
$lec3c = 100;

}else{
$lec3c = 0;
}
if ($lec4 == "T4" && $reg != "Full Registration") {
$lec4c = 150;}else{
$lec4c = 0;
}if ( $wed == "Wednesday 7th July" ) {
$wed2 = 45 * $person;
}else{
$wed2 = 0;
}
if ( $thur == "Thursday 8th July" ) {
$thur2 = 45 * $person;
}else{
$thur2 = 0;
}
if ( $fri == "Friday 9th July" ) {
$fri2 = 45 * $person;
}else{
$fri2 = 0;
}
$accomptt = 40 * $accompt;
$accompft = 40 * $accompf;
$dinner2 = $dinner * 60;
$total = $dinner2 + $reg2 + $lec1c + $lec2c + $lec3c + $lec4c;
$total2 = $accomptt + $accompft;
$total3 = $wed2 + $thur2 + $fri2;
$total4 = $total + $total2 + $total3;

?>

Thirdly, a PHP script is used to get the layout of the data. The data has been placed in a typical bill like structure that is easy for the user to understand. Finally, the costs, and total cost are placed into hidden text fields in order to send them to the next page. The code for which is;

<input type="hidden" name="totalreg" value="<?php echo $total?>" id="totalreg" />
<input type="hidden" name="totalacc" value="<?php echo $total2?>" id="totalacc" />
<input type="hidden" name="totalaccc" value="<?php echo $total3?>" id="totalaccc" />
<input type="hidden" name="totalc" value="<?php echo $total4?>" id="totalc" />

If the user decides to have the bill sent to their provided e-mail address, the 'Send' button can be clicked.

• Learnability: The basic task is to view the bill. A copy of which can be sent via the provided e-mail address by clicking on the 'Send' button.
• Efficiency: Only a click of a single button will allow the user to continue, and so this page is very easy to use and simple to understand.
• Memorability: Even with time away, this page is easy to use upon return.
• Errors: The only error possible is if the user clicks away from the page, upon selecting back from the browser the user is returned. No other errors can be made.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-mail.php
The page sends the bill to the users provided e-mail address (Fig25). Firstly, it starts by putting all session variables into variables used on the page, the code for which is;

<?php
session_start();
$firstname = $_SESSION['firstname'];
$lastname = $_SESSION['lastname'];
$addressline1 = $_SESSION['addressline1'];
$addressline2 = $_SESSION['addressline2'];
$addressline3 = $_SESSION['addressline3'];
$addressline4 = $_SESSION['addressline4'];
$addressline5 = $_SESSION['addressline5'];
$code = $_SESSION['code'];
$country = $_SESSION['country'];
$tel = $_SESSION['tel'];
$mob = $_SESSION['mob'];
$email = $_SESSION['email'];
$dinner = $_SESSION['dinner'];
$reg = $_SESSION['RadioGroup1'];
$lec1 = $_SESSION['CheckboxGroup1'];
$lec2 = $_SESSION['CheckboxGroup2'];
$lec3 = $_SESSION['CheckboxGroup3'];
$lec4 = $_SESSION['CheckboxGroup4'];
$accompper = $_SESSION['accomp'];
$accompt = $_SESSION['accompthurs'];
$accompf = $_SESSION['accompfri'];
$person = $_SESSION['persons'];
$wed = $_SESSION['CheckboxGroup5'];
$thur = $_SESSION['CheckboxGroup6'];
$fri = $_SESSION['CheckboxGroup7'];
$accomptt = $_SESSION['accomptt'];
$accompft = $_SESSION['accompft'];
$dinner2 = $_SESSION['dinner2'];
$single = $_SESSION['single'];
$double = $_SESSION['double'];
?>

Secondly, the POSTed data from the previous page (costs/total cost) is added into variables used on the page, and the code is;

<?php
$total = $_POST["totalreg"];
$total2 = $_POST["totalacc"];
$total3 = $_POST["totalaccc"];
$total4 = $_POST["totalc"];

Thirdly, the PHP mailto function is used in order to send an e-mail to the user. The code for which was copied and modified from w3schools.com (2010) and is;

$to = "$email";
$subject = "Registration";
$message = "Hello,
Please print and bring the bill below, you will be expected to settle the bill upon arrival. If any of the details are wrong, please contact us to correct them.

----------------------------------------
Name: $firstname $lastname
Address:
$addressline1
$addressline2
$addressline3
$addressline4
$addressline5
$code
$county

Tel: $tel
Mob: $mob
----------------------------------------
Registration Type: $reg

Lectures:
$lec1
$lec2
$lec3
$lec4

Additional Dinner Tickets: $dinner

Registration Cost: $total
----------------------------------------
Accompanying Persons: $accompper

Number of Tickets:
Thursday: $accompt
Friday: $accompf

Accompanying Persons Cost: $total2
----------------------------------------
Number of People: $person

Nights:
$wed
$thur
$fri

Room Types:
Single: $single
Twin: $double

Accommodation Cost: $total3
----------------------------------------
Total Cost: $total4
----------------------------------------
Payment will be accepted by either cash or cheque upon check-in. Please check-in at the main office upon arrival.

Regards,
The Ambient Technology Team
";
$from = "Ambient Technologies";
mail($to,$subject,$message);
echo "An Email has been sent to the provided address: $email.";
?>

The user can then select any menu item from the navigational pane to go to another page.

• Learnability: The basic task of this page is to send an e-mail. This is done by the page itself and not the user.
• Efficiency: The page is easy to use, there are no other options but to click away from the page.
• Memorability: Even with time away, this page is easy to use upon return.
• Errors: No errors can be made.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

(Fig25: Author 2010, The e-mail sent from the server with the values being displayed)

-Book Accommodation (accom.php)
While users have the optional choice to book accommodation during the conference registration, this like the separate accompanying persons booking page allows the user to separately book accommodation (Fig15). So like the separate accompanying person's page, it is mandatory to select the required fields, in this case the number of people, types of rooms and the nights wanted. Like each other page before it, the layout is designed to be simple to use and easy to understand with information about the accommodation also being provided.

The validation code for this page is;

When all the details are entered correctly, the user is taken to the next page upon submit.

• Learnability: The page is intended for users to book accommodation, and as such has the logical layout of requiring the users personal details first. With the information provided to the user, and form validation checks this page is easy to use.
• Efficiency: The task of booking accommodation is very easy to achieve, as it only requires the user to input valid data.
• Memorability: Even with time away from the page, it is still easy to use upon a return to it.
• Errors: Errors for this page come from the users input data, as validation is done on the more important aspects of information, an error message is displayed to the user if something is wrong.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-accomreg.php
This page gives details to the user about what will happen next (Fig16). The code behind the scenes captures the POSTed variables and stores them into session variables to use later. The code is;

<?php
session_start();
$_SESSION['firstname'] = $_POST['firstname'];
$_SESSION['lastname'] = $_POST['lastname'];
$_SESSION['email'] = $_POST['email'];
$_SESSION['addressline1'] = $_POST['addressline1'];
$_SESSION['addressline2'] = $_POST['addressline2'];
$_SESSION['addressline3'] = $_POST['addressline3'];
$_SESSION['addressline4'] = $_POST['addressline4'];
$_SESSION['addressline5'] = $_POST['addressline5'];
$_SESSION['code'] = $_POST['code'];
$_SESSION['country'] = $_POST['country'];
$_SESSION['tel'] = $_POST['tel'];
$_SESSION['mob'] = $_POST['mob'];
$_SESSION['persons'] = $_POST['persons'];
$_SESSION['single'] = $_POST['single'];
$_SESSION['double'] = $_POST['double'];
$_SESSION['CheckboxGroup5'] = $_POST['CheckboxGroup5'];
$_SESSION['CheckboxGroup6'] = $_POST['CheckboxGroup6'];
$_SESSION['CheckboxGroup7'] = $_POST['CheckboxGroup7'];
?>

The user only has to click 'Submit' in order to continue to the next page and be presented with the bill.

• Learnability: The basic task of this page is to provide information and allow the user to continue by clicking the 'Submit' button. All POSTed variables are collected by the page upon load.
• Efficiency: The page is very easy to use and requires only a single click to continue.
• Memorability: Even with time away, it is still easy to use upon return.
• Errors: The only error is when a user clicks away from the page, as variables are stored into session variables, a simple click back will restore the page.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-accfinish.php
This page presents the user with the bill, it is given in a typical bill like structure (Fig17). The session variables are stored within page variables, and the prices are calculated from the information the user provided, the code of which is;

if ( $wed == "Wednesday 7th July" ) {
$wed2 = 45 * $person;
}else{
$wed2 = 0;
}
if ( $thur == "Thursday 8th July" ) {
$thur2 = 45 * $person;
}else{
$thur2 = 0;
}
if ( $fri == "Friday 9th July" ) {
$fri2 = 45 * $person;
}else{
$fri2 = 0;
}
$total3 = $wed2 + $thur2 + $fri2;

In order to send across the total cost to the next page, it is stored within a hidden text field and POSTed along with the form. The code for this is;
<input type="hidden" name="totalaccom" value="<?php echo $total3?>" id="totalaccom" />

The user is then able to send the bill to the provided e-mail address.

• Learnability: The basic task of this page is to provide the bill to the user. The user can then click 'Send' to have the bill sent to their provided e-mail.
• Efficiency: The page is very easy to use and requires only a single click to continue. This click though is optional.
• Memorability: Even with time away, it is still easy to use upon return.
• Errors: The only error is when a user clicks away from the page, as variables are stored into session variables or calculated on page load, a simple click back will restore the page.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

-bmail.php
This page sends the bill to the provided e-mail address (Fig18), but to start with all the session variables are called and placed into page variables, along with the total cost variable from the last page. The PHP mailto function is then used to send the bill to the user. The code for which was copied and modified from w3schools.com (2010) and is;

<?php
$totalaccom = $_POST["totalaccom"];
$to = "$email";
$subject = "Registration";
$message = "Hello,
Please print and bring the bill below, you will be expected to settle the bill upon arrival. If any of the details are wrong, please contact us to correct them.

----------------------------------------
Name: $firstname $lastname
Address:
$addressline1
$addressline2
$addressline3
$addressline4
$addressline5
$code
$county

Tel: $tel
Mob: $mob
----------------------------------------
Number of People: $person

Nights:
$wed
$thur
$fri

Room Types:
Single: $single
Twin: $double

Total Accommodation Cost: $totalaccom
----------------------------------------
Payment will be accepted by either cash or cheque upon check-in. Please check-in at the main office upon arrival.

Regards,
The Ambient Technology Team
";
$from = "Ambient Technologies";
mail($to,$subject,$message);
echo "An Email has been sent to the provided address: $email.";
?>

From this page, the user can select any menu item from the navigational pane to access any other sections of the site.

• Learnability: The basic task of this page is to send an e-mail. This is done by the page itself and not the user.
• Efficiency: The page is easy to use, there are no other options but to click away from the page.
• Memorability: Even with time away, this page is easy to use upon return.
• Errors: No errors can be made.
• Satisfaction: The overall design is set in a logical structure, easy and pleasant to use.

Standard Conformance

A given requirement is that the site must be validated at XHTML 1.0 (transitional or strict) compliant and CSS 2 standard compliant, and so each page is listed below along with images of the page passing both tests, Fig27 through to Fig63 displays each test carried out, with all XHTML 1.0 being transitional. The pages that will not be tested are header.php, footer.php and navigation.php, as they have very little code and will not pass the tests due to the lack of any headers, titles or bodies. The reason, as was explained earlier, is that the PHP include includes all code, and so pages can end up having two lots of headers, titles and bodies. Every page that was tested passed, bar three. The only three that have not technically passed, nor have they technically failed are; mail.php, amail.php, and bmail.php. Each page uses the PHP mailto function, and each page was told that it could not be validated. When the PHP mailto code was deleted, the pages passed the validation test, although this is not shown here as the code is essential to the overall operation of the pages. At first a number of pages failed the XHTML 1.0 validation as it was picking up the Javascript validation within the page, and so help was sought from webdesignerforum.co.uk (bocaj: 2009). It is stated in one of the posts to use;

<!--<![CDATA[

Content

]]>-->

This was meant to hide the script from the W3C evaluators. This did not work and so I simply tried <!-- (content) -->, this did work and now features within the code on pages that have a high level of Javascript validation, and which did not pass the initial tests.

-Home (index.php)

(Fig26: Author 2010, index.php passing the XHTML 1.0 validation | Fig27: Author 2010, index.php passing the CSS 2.1 validation)

-Conference Programme (programme.php)

(Fig28: Author 2010, programme.php passing the XHTML 1.0 validation | Fig29: Author 2010, programme.php passing the CSS 2.1 validation)

-Travel Information (travel.php)

(Fig30: Author 2010, travel.php passing the XHTML 1.0 validation | Fig31: Author 2010, travel.php passing the CSS 2.1 validation)

-Local Information Page (local.php)

(Fig32: Author 2010, local.php passing the XHTML 1.0 validation | Fig33: Author 2010, local.php passing the CSS 2.1 validation)

-Accompanying Persons' Programme (apersons.php)

(Fig34: Author 2010, apersons.php passing the XHTML 1.0 validation | Fig35: Author 2010, apersons.php passing the CSS 2.1 validation)

-accreg.php

(Fig36: Author 2010, accreg.php passing the XHTML 1.0 validation | Fig37: Author 2010, accreg.php passing the CSS 2.1 validation)

-afinish.php

(Fig38: Author 2010, afinish.php passing the XHTML 1.0 validation | Fig39: Author 2010, afinish.php passing the CSS 2.1 validation)

-amail.php

(Fig40: Author 2010, amail.php unable to be validated for XHTML 1.0 compliance | Fig41: Author 2010, amail.php unable to be validated for CSS 2.1 compliance)

-Conference Registration (registration.php)

(Fig42: Author 2010, registration.php passing the XHTML 1.0 validation | Fig43: Author 2010, registration.php passing the CSS 2.1 validation)

-registration2.php

(Fig44: Author 2010, registration2.php passing the XHTML 1.0 validation | Fig45: Author 2010, registration2.php passing the CSS 2.1 validation)

-registration3.php

(Fig46: Author 2010, registration3.php passing the XHTML 1.0 validation | Fig47: Author 2010, registration3.php passing the CSS 2.1 validation)

-registration4.php

(Fig48: Author 2010, registration4.php passing the XHTML 1.0 validation | Fig49: Author 2010, registration4.php passing the CSS 2.1 validation)

-registration5.php

(Fig50: Author 2010, registration5.php passing the XHTML 1.0 validation | Fig51: Author 2010, registration5.php passing the CSS 2.1 validation)

-finish.php

(Fig52: Author 2010, finish.php passing the XHTML 1.0 validation | Fig53: Author 2010, finish.php passing the CSS 2.1 validation)

-mail.php

(Fig54: Author 2010, mail.php unable to be validated for XHTML 1.0 compliance | Fig55: Author 2010, mail.php unable to be validated for CSS 2.1 compliance)

-Book Accommodation (accom.php)

(Fig56: Author 2010, accom.php passing the XHTML 1.0 validation | Fig57: Author 2010, accom.php passing the CSS 2.1 validation)

-accomreg.php

(Fig58: Author 2010, accomreg.php passing the XHTML 1.0 validation | Fig59: Author 2010, accomreg.php passing the CSS 2.1 validation)

-accfinish.php

(Fig60: Author 2010, accfinish.php passing the XHTML 1.0 validation | Fig61: Author 2010, accfinish.php passing the CSS 2.1 validation)

-bmail.php

(Fig62: Author 2010, bmail.php unable to be validated for XHTML 1.0 compliance | Fig63: Author 2010, bmail.php unable to be validated for CSS 2.1 compliance)

Accessibility

The list below states all priority one checkpoints that need to be passed. The site though does not use a number of the aspects mentioned and so they do not apply, i.e. they have been marked as N/A. The ones that do apply have passed the priority one check, and details on why and how each checkpoint was passed are given below.

Priority 1 checkpoints ( http://www.w3.org/TR/WCAG10/full-checklist.html)

1.1. Provide a text equivalent for every non-text element

Only one single picture exists within the site, and that is the main logo which exists in header.php. This is then included with PHP include into every page, with the code staying the same throughout. The single line of code includes 'alt', 'title' and 'longdesc' attributes and so a text equivalent is provided. The code is;

<a href="index.php"><img src="logo.jpg" alt="Ambient 2010 Conference" name="ambient" width="546" height="131" id="ambient" title="Ambient 2010 Conference" longdesc="Ambient 2010 Conference" /></a>

The 'alt' tag in Internet Explorer displays a small caption, but does not work in some of the other browsers including FireFox and Google. Instead the 'title' tag displays the caption to the user upon mouseover in those browsers.

6.1. Organize documents so they may be read without style sheets.

This checkpoint deals with the overall layout, and basically points out that the document must still be readable when the CSS is not there/turned off. The easiest way to validate this is to take the CSS away, so that the link does not work and the page cannot render as it should. Upon doing this, the page was rendered with a basic layout which consisted of such; navigation, header, content, and footer. Every page rendered the same way, and so every page is readable. Fig64 shows one such page without the CSS file to render the correct layout.

(Fig64: Author 2010, local.php is shown as still being readable without the supporting CSS document)

14.1. Use the clearest and simplest language appropriate for a site's content.

Every page within the site uses very clear and simple language, which provides the required information to the user. For example, the 'Book Accommodation' page has the following text;

"You are able to book accommodation with the university, or you may book accommodation directly with hotels, B&B's and guest houses in and around York. Although links are provided to various hotels etc in the 'Local Information' section, the university does not affiliate with any of them, and so booking with them is at your own risk. Prices for accommodation with the university are £45 per person per night. "

The text very clearly states the purpose of the page, the fact that the university is not responsible for any accommodation outside the campus, and the price. All this information is given in just a single paragraph in order to keep it simple and to not overload the user with information.

5.1. For data tables, identify row and column headers.

The only page that really uses tables is the Local Information page (local.php), for which there are 3 tables included within the content body. In order to make it accessible, especially to text readers, the following code was used;

<th id="header1"></th>
<td headers="header1"></td>

The number of headers used reached six. Fig65 shows the code implemented into the site, and that it is in order with the priority one checkpoint as pointed out in the WCAG documentation, available from http://www.w3.org/.

(Fig65: Author 2010, The code for local.php showing the different headers)

6.3. Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

This checkpoints asks that the pages are usable when scripts etc are turned off or not supported. In this case scripts are being used to validate the input data, and so when they are turned off, there is no validation.The Javascript's being used provide client-side validation, while normally PHP can be used to provide additional server-side validation in order to capture any errors that pass by the Javascript in case it is disabled. Fig66 shows how Javascript was disabled in Internet Explorer 8 (IE8) to be able to test that the page is still usable, and despite the lack of validation it presents, the page is still usable. It should be noted that although the website only has client-side validation, server-side would also be ideal, but problems were met with the implementation of server-side validation and so to keep the integrity of the site as a whole, it was omitted.

(Fig66: Author 2010, In order to disable the Javascript's, scripting was disabled in IE8)

Simplicity and Maintainability

This section deals with the decisions made in order to keep the site maintainable and simple. As with any site, a basic plan was first drawn up with the emphases on simplicity and minimalism. From there, other pages were brought in which helped with maintaining the simplistic design, and to keep consistency throughout.

-Plan

After reading through the requirements, it became clear what was needed. First a simple home page, followed by three pages giving information (programme, travel and local), and then three pages that enable users to book for the/parts of the conference (accompanying persons, conference registration and accommodation). The later three pages needed to have information sent to a provided e-mail address. It was also decided that the conference registration page had to include many sub-pages, in order to register for everything without problems. The original intentions were for each page to be minimalistic in order to keep things very simple. Fig67 shows the original design, and the relationships between the pages. Upon taking this design and creating the pages from it, three additional pages were included which were; header.php, navigation.php and footer.php. The additional pages provided navigational links, a logo, contact and copyright information.

(Fig67: Author 2010, The original design, a simple tree structure showing the relationships between pages)

- 2 Column Layout

The two column liquid layout (provided by Dreamweaver CS4) was chosen in order to gain a relatively simply layout that looks good on any screen. Various screen sizes have been tested, with the smallest being 10.1" and the largest 17". Any smaller than 10.1" and problems with the layout overlapping (caused by the CSS) may occur, but without absolute positioning (which causes horizontal scrolling) this is unavoidable. It must be noted that the layout decision was one that enabled notebook users to view the site without problem, larger screen users will be able to view the site with no problem, albeit with more white space. The decisions behind it were; that conference delegates may have notebooks, and so the site needs to look appealing on a small screen, and that the site should be as resolution independent as much as possible.

-CSS

The cascading style sheet (CSS) allows for a standardised layout. A single change will ripple through the entire website, for example, changing the font on the CSS will mean that every page using that specific CSS will display the new font. This allows easy maintainability, as it is not just the simple attributes that can be changed, but the entire layout of the site can be changed in an instance. The majority of the wed.css file was created by Dreamweaver CS4, as a specific layout was chosen the file was automatically created with the basic layout implemented. While the website progressed, this basic document was modified substantially in order to get the specifications wanted, and to also add addition content.

- PHP Include

There are a number of pages that make up the overall website, each page having its own content. This cannot be made any easier to manage without that content being fetched from a data store, thus it could also be made editable through the browser. Each page does however hold the same header, footer and navigational menu, and if this is the same for each page then a change in the navigational menu would have to be made on each and every page. The PHP 'include' function helps with this, and with this inserted into every page, only one page (the navigation page) needs to be updated for the changes to be shown throughout the site. This was done for navigation (using the code shown below), header and footer in order to keep it easy to maintain.

<?php

include 'navigation.php';

?>

A problem with with using PHP include, especially with the navigation, is that the page will always be included, and all links will remain the same. So without major coding, it is not possible to cancel a single link, so that the link cannot be selected again when viewing the related page. A major problem that also exists is that the entire page code will be included, and so as mentioned before, it is possible to get multiple headers, titles, and bodies within the same page.

- Consistency

Each and every page follows a consistent layout and style, mostly brought about by having a single CSS file. The first three pages (programme, travel and local) provide information to the user and all have a consistent style in order for the user to not get confused. The three pages relating to the booking process also have a consistent style, with the same colour scheme being used throughout the entire website.

Errors

This site is designed to minimise errors. As shown in Fig67 the design has been simple from the start, allowing for a more maintainable site. The inclusion of PHP include, also helps with the maintenance of the navigational links in order to prevent 404 errors from occurring. And the use of validation also helps with user errors, which in this case will not actually cause major errors as the data is not being sent to a database. For example, a phone number could be ten digits long, and when sent to a database the database expects only integer values of eight digits, a non integer value will cause an error, as too would a value greater than eight. This will not happen with this site, and although no validation has been included for phone number, validation has been included for the users e-mail, as this is much more important.

-Unavoidable Errors

Non-avoidable errors can be common, and although they are unavoidable there are a few ways in which they can be dealt with in order for the user to not feel isolated. It is possible to set up specialised pages for different errors, the most common ones being errors like;

401: Authorization Required
403: Forbidden
404: File Not Found
500: Internal Server Error

The most common error is 404, and can be seen on many sites as 'file not found' or 'page not found', this is the most personalised error also, as many service providers allow users to allocate their own 404 page. In light of this, the website does contain a 404.php that informs the user that the page has not been found. The following pages are also included with the website;

401.php
403.php
500.php

Errors, 401, and 403 do not really apply as there are no restricted areas on the website in order for users to fail authorisation or be met by a forbidden error. Error 500 can also be personalised and this has been seen already with mail.php, amail.php and bmail.php. All three pages could not be validated because of an internal server error (500), with W3C showing a personalised page for both XHTML 1.0 and CSS 2.0 validation which can be seen in Fig40, Fig41, Fig54, Fig55, Fig62, and Fig63.

-Layout Errors

Unfortunately, different web browsers can also have different errors. The following code was placed into the page by Dreamweaver CS4 in order to avoid several Internet Explorer (IE) bugs;

<!--[if IE]>
<style type="text/css">
/* place css fixes for all versions of IE in this conditional comment */
.twoColLiqLt #sidebar1 { padding-top: 30px; }
.twoColLiqLt #mainContent { zoom: 1; padding-top: 15px; }
/* the above proprietary zoom property gives IE the hasLayout it needs to avoid several bugs */
</style>
<![endif]-->

As each page is effectively a copy of the first page created in order to maintain the layout, this code features on all pages.

Testing

A number of tests were carried out to ensure that the site worked on a number of different platforms. Below is a list of all the tests done, along with descriptions for each.

1. Basic Testing
• Not having a dedicated PHP server, the site was created with Dreamweaver CS4 and uploaded to a personal web hosting service which supported PHP. Everything, from the creating of each page to the smallest change to an existing page, was uploaded straight to the internet. With the site fully working on the internet, a full test on campus was carried out. This brought up a few errors regarding text and so to solve these errors a guide was referred to in order to get the HTML value of the specific ASCII character, Fig68, Fig69, Fig70, Fig71 and Fig72 display screen shots of pages with character errors. The guide in question is HTML Codes - Characters and symbols (2009).
2. Resolution Testing
   • The site was designed to look good with a 10.1" screen. Any bigger and the site still looks good, but if a screen is smaller then layout errors occur due to the liquid column approach taken as mentioned before. The largest screen size tested was 17", along with many other varying sizes in between.
3. Browser Testing
• The website was tested on the main browsers which are; Google Chrome, Internet Explorer and FireFox. The site functioned on all three of them without problem, the Javascript's, which were the main concern, fully functioned on each. Fig68 - Fig72 show the site working on FireFox, a major browser. The screen shot displayed in Fig66 was taken during testing on Internet Explorer 8, while everything else was done on Google Chrome.
4. Script Tests
   • As part of the accessibility testing, the page had to be usable when scripts were turned off. Fig66 shows the scripts being turned off in Internet Explorer 8. Other than there being no validation, the site functioned normally.
5. CSS Tests
• As part of the accessibility testing, the CSS file had to be tested. Fig64 shows the results of disabling the CSS file, while every other figure shows the site with the CSS file active.
6. Users
   • The final part of the testing procedure was to get real users involved in the testing, for this a scenario based test was developed. The scenario had users find information regarding a particular conference event, and then to register for the conference.
   • The scenario was as such;
     1. The user loads index.php.
     2. From the home page the user wants to learn more about the conference and selects 'Conference Programme' from the navigational menu.
     3. After searching through the information the user decides that there is only one tutorial of interest (T4).
     4. The user also wants to attend the research day and the dinner.
     5. The user wants to attend the dinner with two guests, both of which also want to visit some of York's tourist attraction on the Friday.
     6. The user and two guests also want to book accommodation at the university.
     7. One of the guests is the users partner who will be sharing a room with the user.
     8. They want accommodation for all three nights.
     9. After the user has booked, the total cost is given as 1155 GBP.
   • Four people tested the site, following the scenario. All four were able to get the same outcome with no problem. The only errors that were reported, were the errors regarding ASCII characters not showing as they should as mentioned earlier.

(Fig68: Author 2010, Screen shot of the Accompanying Person's Programme page showing textual errors)

(Fig69: Author 2010, Screen shot of the Book Accommodation page showing textual errors)

(Fig70: Author 2010, Screen shot of the Accompanying Person's Programme during Conference Registration showing textual errors)

(Fig71: Author 2010, Screen shot of the Conference Programme page showing textual errors)

(Fig72: Author 2010, Screen shot of the Travel Information page showing textual errors)

Additional Accessibility

Since priority one checkpoints relative to the website have been passed, an attempt can be made for passing priority two checkpoints. The list below shows all priority two checkpoints, with details of each pass and failure underneath.

Priority 2 checkpoints ( http://www.w3.org/TR/WCAG10/full-checklist.html)

Passed

2.2. Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen.

Using the following website http://colorfilter.wickline.org/ (Matt: 2009), tests were done on the site to ensure that it would be readable to those that have colour deficits. Fig73 shows what the site looks like in black and white, and as it can be seen, it is still readable.

(Fig73: Author 2010, The website displayed in black and white)

3.2. Create documents that validate to published formal grammars.

Each page has a document type declaration. Fig74 show the declaration for one specific page (although it is the same for all of them).

(Fig74: Author 2010, The document declaration)

3.3. Use style sheets to control layout and presentation.

The style sheet in use throughout the entire website is that of wed.css. Fig75 shows some of the code from wed.css.

(Fig75: Author 2010, Code from wed.css)

3.4. Use relative rather than absolute units in markup language attribute values and style sheet property values.

Generally the website has both relative and absolute units, but this has been decided as a pass due to the following reason. The absolute values apply to the left hand margin only, where as relative values apply to the right hand side, once a page is shrunk down, the left hand side remains where it is, while the right hand side shrinks accordingly. If the left hand side were to also shrink, major problems with overlapping would occur. Bits of the code that control layout can be seen in Fig75.

3.5. Use header elements to convey document structure and use them according to specification.

Different headings from around the site use different styles of headers. Fig76 shows code from the conference registration page, with two headings being used; H1 and H2.

(Fig76: Author 2010, Code from registration2.php)

13.1. Clearly identify the target of each link.

Each link has a clearly defined name, meaning that no one should really get confused with where the link will lead them. Fig5 clearly shows the navigational links to the left, and shows how clearly the links are displayed.

13.2. Provide metadata to add semantic information to pages and sites.

Metadata to provide author information and keywords has been provided, and can clearly be seen in Fig74.

Failed

12.3. Divide large blocks of information into more manageable groups where natural and appropriate.

This website does not use OPTGROUP to group OPTION elements inside a SELECT, and it does not group form controls with FIELDSET and LEGEND. Because of this, this checkpoint was not passed.

13.3. Provide information about the general layout of a site (e.g., a site map or table of contents).

The website does not have a sitemap or table of contents. Because of this, this checkpoint was not passed.

13.4. Use navigation mechanisms in a consistent manner.

This website does not use navigation mechanisms as such. It can be argued that the progress bar displayed during conference registration acts as a sort of bread crumb trail, although it does not feature links. There is not much need for a bread crumb trail, as the first three pages are single pages, with the others being registration forms. Because of this, this checkpoint was not passed.

10.2. Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.

Not all of the form field have labels associated with them, especially the form fields relating to personal details. Because of this, this checkpoint was not passed.

12.4. Associate labels explicitly with their controls.

This has not been passed for the same reason as stated above.

8.1. Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]

This has not been passed, as it has not been possible to test the website with assistive technologies. It is more than possible that the scripts, for whatever reason, do not function with certain assistive technologies and so this checkpoint can not be passed until tests are done.

It is possible with time, to go through each again in order to get a pass, but without testing, especially with assistive technologies, there will always be at least one that cannot pass.

Bibliography

Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M. Fiksdahl-King, I. & Angel, S. (1977) A Pattern Language, Oxford University Press

bocaj. (2009) Javascript & W3C Validation, http://www.webdesignerforum.co.uk/topic/23965-javascript-w3c-validation/

Edwards, A. (2009) Patterns in Web Design, http://www-course.cs.york.ac.uk/wed/notes/wedPatterns.php

HTML Codes. (2009) Characters and symbols, http://www.ascii.cl/htmlcodes.htm

Matt. (2009) Colorblind Web Page Filter, http://colorfilter.wickline.org/

Nielsen, J. (2009) Usability 101: Introduction to Usability, http://www.useit.com/alertbox/20030825.html

Shannon, R. (2010) Form Validation, http://www.yourhtmlsource.com/javascript/formvalidation.html

SmartWebby. (2009) Javascript E-mail Address Validation, http://www.smartwebby.com/DHTML/email_validation.asp

University of York. (2009) How to Reach the University, http://www.york.ac.uk/np/maps/

w3schools. (2010) PHP Sending E-mails, http://www.w3schools.com/php/php_mail.asp

Yahoo! Developer Network. (2009) Left Navigation Bar, http://developer.yahoo.com/ypatterns/navigation/bar/leftnav.html

Yahoo! Developer Network. (2009) Page Grids, Yahoo! Developer Network http://developer.yahoo.com/ypatterns/layout/pagegrids.html

Yahoo! Developer Network. (2009) Progress Bar, http://developer.yahoo.com/ypatterns/navigation/bar/progress.html