TABS: Avaliability

TABS: User Registration

The User Registration Form is one of the pages the user will first interact with. In certain circumstances, registration forms can be too cluttered and confuse the user. When designing ours we tried to keep things a simple as possible, using larger than standard form elements and fonts, easy to read and identify labels for each input and to try and spread out the elements to use the full width of the page. As a design function we have used the green in the logo to style elements where interaction can be used. This will continue through out application.

The back end elements of the page consist of some Javascript for validation, some AJAX and PHP to write to the PostgreSQL.

The validation is used for verifying valid e-mails and to make sure necessary information is included before the data is submitted. The AJAX will be called when the information is submitted, parse the data to a PHP function to add the the data into the database tables via a PostgreSQL function, then get confirmation that the function was successful and callback to the javascript. The callbacks are functions called by AJAX after it has carried out its function. The reason we use AJAX in this way throughout our project is that it is an efficient way of handling data, error messages and user interaction between the front end and the database without disrupting the users page.

Form Building

Over the last couple of days we have constructed a registration page to start sending data to and from the database and get the underlying structure of the service working.

Firstly we built our form elements depending on what type of data we would eb sending to the database; eg Checkbox for values of boolean type on the back end. Then we started writing the functions that would send the inputted data to the back end. We planned to do this using AJAX, which would let us move around data without having to navigate away from the page, this task was broken down into a few steps.

Firstly, our form would send the data supplied through a Javascript function. This data is then formatted within the function and sent using Ajax into a PHP script. The PHP script will then pass the data to the database where a function there will designate which fields the data is to be stored in. Fairly simple laid out like that, but rather complicated when I came to the coding (althought made a lot easier with some examples supplied by steve!).

With the database and the page talking to eachother we decided to add some validation to the page. Some examples of these being; checking if the e-mail address is valid, making sure dates had the correct number of digits, forcing numbers only in to some fields and last but not least checking wether there is data in the required fields.

Our most complex validation function was the e-mail as we wanted to display some visual indication along the way as to wether the text being inputted was valid. It started off as being able to determin wether there was any text in place but grew to check wether it was formatted properly.

The stages of the form field are (We realise address is spelt wrong):

No Text Input

Text Input, But Not Valid

Valid Email

Obviously we’ll wont use some ghastly colors in the final design, but the framework for changing how the error is displayed is in place.

Database Building

Today we started building the backbone of our system, the database. We produced a mind-map earlier in the week detailing what fields and tables we thought we would need. However, as we have spent the day working through the database, we have discovered that it is useful to work through how the front end will work whilst bulding. We dont want to get to a point where we have to go back and change aspects of the database and potentially disrupt any existing code we have written.

We have come up with a set of three schemas (folders), containing 9 tables. We have split up some of the tables so parts of the data that doesnt always have to be recalled can be stored elsewhere and will help reduce load times. We have an audit table which will contain an archive of all the booking request history. In this table we will include all the data possible that was previously spread out on the system. In this case, having all the information in one place will eliminate the need to skim over all of the tables to retrieve data when reviewing a archived booking.

Professional Project

For the professional project, Myself and Luke Wakeford have been asked by SiSo to design and develop a student/teacher 1-to-1 booking system which has been requested by one of their clients. The system will give students the ability to check avaliable times, book sessions with their tutors and recieve confirmations by email. Lecturers will be able to allocate times that they are avaliable, manage pending and active sessions, append notes and have the system intergrate with their existing calendar solution.

We have had a brief plan out of how this will be managed. The back end will be built using postgreSQL and php; enabling us to store and manage user information,bookings, calendars and audit. For the front end we plan on using HTML5, javascript and css to create a simple user friendly interface and experience.

For our schedule we will be spending 3 days per week with SiSo to work on the project as they have the necessary tools to work with databases set up ready for use.

Performance Video Demo

Note To Self

Do this with CCV