EQuip On-line Equipment Booking System

v0.01

Contents

Introduction

Project Overview

The User Experience

The ICT Support Team Experience

Design Objectives

Technical Overview

MySQL

PHP

Apache

Additional Software

Additional Listings

Introduction

EQuip is an On-line Equipment Booking System.

Project Overview

The EQuip project will use a web-based interface to allow users to reserve technical resources, view other reservations and cancel their bookings. The EQuip system will also enable the ICT Support Team to monitor and control equipment bookings and enable equipment to be prepared for use.

The User Experience

The EQuip project should provide the following facilities to the end-user:

Allow only authenticated access.

Allow user to view the booking status of equipment using various views.

Allow user to reserve a piece of equipment

Allow user to cancel their equipment booking

Provide information on how to use EQuip.

Authentication

Access to the EQuip module is granted following a successful login to the “login” module. The level of access will be determined by the access rights granted to the user.

EQuip Start Page

Following authentication the user should be presented with the option to view booking status of pieces of equipment, an option to book equipment and to get help on using the EQuip system. The start page should incorporate a summary of that users' bookings for the day.

View Booking Information

Booking information should be available to users in the following ways:

Summary: User's bookings for the day (and tomorrow?)

Daily view of all equipment (including navigation)

Daily view of equipment in categories

Weekly view for single piece of equipment

Weekly view for categories?

Booking Equipment

Booking a piece of equipment should involve:

Locating a booking slot using the above views

Selecting the slot

Repeat booking options?

Adding information about the class

The user's session information should be used to complete the booking

Cancel a Booking

Cancelling a booking should involve:

Locating a booking slot using the above views

Confirming the cancellation

Information On How To Use Equip

Although the Equip system is designed to be as easy and intuitive to use as possible and that the users will be provided with training in the use of the system as part of their professional development, the Equip web pages should also provide information on how to use the system. This will serve as a useful reminder to users who have used the system previously and will help users who are new to the system but have not received any Professional Development.

The ICT Support Team Experience

The SATYR project should provide the following facilities to the members of the ICT Support Team:

Allow only authenticated access.

Allow ICT Support Team member to view equipment bookings.

Allow ICT Support Team member to edit or delete equipment bookings.

Allow ICT Support Team member to make equipment bookings.

Provide information on how to use the administrative features of SATYR.

Create block bookings

Grey out blocks? Eg PSHE?

Authentication

Access to the SATYR module is granted following a successful login to the “login” module.

SATYR Start Page

Following authentication the ICT Support Team member should be presented with a summary of open requests assigned to them. They should also have options to submit a new request themselves, and to review unassigned requests.

Review Unassigned Requests

For newly submitted (unevaluated) requests, the information displayed on each request should include the following fields:

The support request number.

The current status of the request.

The name or username of the user who submitted the request.

The system with regard to which the support request was submitted.

The information included by the user with the submittal.

The user’s rating of the urgency of the support request.

The date and time the support request was submitted.

An option to evaluate and assign the support request.

Review Assigned Requests

For open requests, the information displayed on each request should include the following fields:

The support request number.

The current status of the request.

The name or username of the user who submitted the request.

The system with regard to which the support request was submitted.

The information included by the user with the submittal.

The user’s rating of the urgency of the support request.

The date and time the support request was submitted.

The category assigned the request by the ICT Support Team.

The evaluation of the request by the ICT Support Team.

The date and time of the evaluation by the ICT Support Team.

The priority assigned to the support request by the ICT Support Team member who evaluated the request.

Further comments and action from the ICT Support Team.

The ICT Support Team member primarily dealing with the request.

An option to edit the ICT Support Team contributed information.

An option to close the request.

The sections showing fields submitted by the user should be visibly differentiated from the fields submitted by the Team Member.

Review Closed Requests

The information displayed in regard to closed requests should include the following fields:

The support request number.

The current status of the request.

The name or username of the user who submitted the request.

The system with regard to which the support request was submitted.

The information included by the user with the submittal.

The user’s rating of the urgency of the support request.

The date and time the support request was submitted.

The category assigned the request by the ICT Support Team.

The evaluation of the request by the ICT Support Team.

The date and time of the evaluation by the ICT Support Team.

The priority assigned to the support request by the ICT Support Team member who evaluated the request.

Further comments and action from the ICT Support Team.

The ICT Support Team member primarily dealing with the request.

The date and time the support request was closed.

An option to re-open the support request

The sections showing fields submitted by the user should be visibly differentiated from the fields submitted by the Team Member.

Submit a Support Request

After selecting to submit a new support request the ICT Support Team member should be presented with a form allowing them to enter the details for their support request. The user should be presented with the following fields:

The forename of the user, blank.

The surname of the user, blank.

The system with regard to which the support request was submitted, with the value “Unspecified”.

The information included by the user with the submittal, blank.

The user’s rating of the urgency of the support request, with the value “Unrated”.

The category assigned the request by the ICT Support Team.

The evaluation of the request by the ICT Support Team.

The priority assigned to the support request by the ICT Support Team member who evaluated the request.

Further comments and action from the ICT Support Team.

The ICT Support Team member primarily dealing with the request.

"Submit Query" button

Information On How To Use SATYR

Instructions for use of the functions available to the ICT Support Team should be available through the SATYR pages.

Administration Features

Set up the weekly timetable structure as necessary

Add number and type of equipment item

Design Objectives

The pages will be designed to be used as an in-line page element, part of a navigational structure on a broader intranet. Pages pertaining to SATYR should feature a banner identifying it as a SATYR page and contain the SATYR logo. These elements should be designed to take up a small amount of screen space, in order that users with low screen resolutions will not find the system difficult to use.

The design of the pages should present the user, whether a member of the ICT Support Team or a general user, with a page summarizing the information that they are most likely to want, together with links for the options that they are most likely to want.

New, open and closed support requests should be clearly distinguished. Fields within a support request submitted by the user should be visually distinguished from the fields completed by the ICT Support Team member.

Technical Overview

The SATYR project will use a web-based interface, and will therefore be platform-independent to the end-user. The "SATYR server" will be made up of the Apache HTTP Server, with a PHP interactive layer and a MySQL back-end. Due to the greater stability of Apache on Linux over Windows, Linux is suggested as the platform for the SATYR server.

MySQL

The key to the successful development and use of the SATYR system is the structure of the underlying database.

Database Name: STORM

Table: device

Object: request

Primary Key: id

Attribute	Data Type	Default Values	Required Field?	Description
id	INT(6)		Yes	Unique Device ID
name	VARCHAR(255)			Device name
category	VARCHAR(255)			Device category
booktable	VARCHAR(20)			Table containing data for the device

Database Name: STORM

Table: dev??book

Object: request

Primary Key: id

Attribute	Data Type	Default Values	Required Field?	Description
day	DATE		Yes	Contains data about the day to which the data applies.
chunk??book	INT(1)			Chunk booked
chunk??user	VARCHAR(30)			Username (full name?) of booker?
chunk??class	CHAR(5)			Identifying the class/lesson in question
chunk??room	CHAR(20)			Location for booking

Account permissions

The account structure should take into account the following:

The SATYR administrator needs to be able to: DELETE, INSERT, SELECT, UPDATE, DROP. Also, needs to be able to CREATE tables, on STORM.* Default account name: admin

The ICT Support Team members need to be able to:

SELECT on all fields for producing tables and search queries.

UPDATE on all fields for evaluating / updating support request details.

INSERT to create new MySQL table entries.

Default account name: ict

Users need to be able to:

SELECT on all fields for producing tables

INSERT to create new MySQL table entries.

UPDATE on all device tables (to “delete” their bookings)

Default account name: users

PHP

A recent version of PHP that supports the inbuilt session variables and arrays is essential to the operation of SATYR. For security reasons, global variables are disabled.

PHP sessions will be used to prevent the end user from having to re-authenticate at every new page. Transferring session IDs between pages uses cookies by default or internal variables as a fallback option. These methods allow users to continue through the SATYR pages without being re-authenticated, and also prevent users from book-marking pages in a session. If a user tries to view a page that was book-marked from a PHP session the user will be returned to the SATYR front page.

The following settings need to be adjusted in the file php.ini:

session.auto_start On. This setting tells the PHP engine to include every PHP page in the session. (If necessary this option can be disable and each SATYR page amended with a session_start() parameter if the automatic session setting disrupts other PHP pages served by the same web server.

Common Processes and Page Elements

PHP processes and page elements that recurr across pages should be coded in separate "include" files to allow changes to be made to a single file but reflected across the whole SATYR site. These include files have the extension .inc.

Apache

Apache can be set not to display dynamically generated index pages as a security measure. The file httpd.conf will need to be edited to associate files with the extension .php with the PHP processing engine.

Laura Cowen

1995-11-21T17:41:00