System Plan

Name: Jordan Fonseka

Student Number: 10637217

Date: 3rd May 2008

Project Overview

The task I have chosen to undertake for my learning project is to create a web application which acts as a support or subscription tool by distributing files to users on request. Files will be matched and supplied to the user based on personal details and requirements derived from their user profile.

I will use the model of a music subscription service which provides audio files related to interests users have specified when creating an account to demonstrate this. A music subscription or download service provides me with a wide range of categories to match files to my individual user's preferences and is also a plausible 'real world' scenario .

Who will use the site?

Given the nature of music copyright if this site were to actually be implemented then the only way a site such as this could work would be to distribute independent music with the copyright holders permission, or older music whose copyright has lapsed. Therefore the kind of person I envisage using the site would be a hobbyist musician or a fan of independent music.

Site Map

The site map presented here is very simplistic. This is deliberate as only the pages which I would deem important to the goals outlined in my learning contract will be created. The 'file upload' option listed below would only be available to users who were flagged as administrators.

site map

The flow chart below illustrates how a user might navigate through the website and includes more detail on incidental pages such as would displayed when a user failed to enter the right username/password combination during the login process.

flow chart

Wireframes:

The following wireframes show the structure of information within a single page for my proposed project. As my original proposal stated, my goals are to experiment and become familiar with server side technologies and not to involve myself too deeply with the visuals or structure of a website whose purpose is only to demonstrate technology rather than provide a fully functioning application/site. With that in mind I've kept the pages themselves simple.

There are two wireframes, one general purpose layout and another for forms. The rationale behind the separate form layout is to remove the side column data which might prove distracting to the user whilst filling out a form. I don't want a user to follow a link elsewhere when halfway through filling out the registration form.

Pages are designed for a minimum resolution of 1024x768. These images are scaled down, click on them for a full size.

basic wireframe

form wireframe

Screenshots

The screenshots correspond to the previous wireframes, more can be found at my dmt blog. Once again, these images are scaled down, please click for a full size image.

screenshot

screenshot

Note that I have not implemented the main user menu (top right) as shown in the wireframes. Again, this is because those pages are beyond the scope of my project and there is little point (other than aesthetics) in my creating links to them. For the purposes of this project navigation is basically linear.

System overview

 

system architecture

Client side technologies

The web pages will be built with XHTML (strict doctype) and use CSS for styling. As per the brief, I will only be designing for Mozilla Firefox.

Javascript will be used for tasks such as validating form data before it is sent to the server and other user interface type enhancements. However, should the user have javascript disabled either by choice or by an enforced network security policy they will not be inhibited in their usage of the site. In other words, javascript will be an enhancement but not a vital technology.

Server Side Technologies

The project makes use of PHP and SQL as illustrated in the previous diagram which shows the architecture of the entire website

SQL database
The following entity relation diagram outlines the simple database which will be used in this project.

database entity relation diagram

Briefly, the diagram breaks down as follows. The first table represents the users, storing basic data which is mostly supplied by the user through the user registration form. Exceptions to this are the users age which is derived from the supplied date of birth and used to restrict access to explicit language music files and the userRole field which is set by default to 'user' and to 'admin' manually through phpadmin. The userLoginDate is set to the date of the user's most recent login and is used in one of the pre-defined search options ('show me newly uploaded music' or similar.). The userValidated is a boolean set to false by default and set to true only when the user has had their email address confirmed as part of the registration process.

The Music table consists of data which is mostly entered by admins when they upload new music files via the upload page. Much of the data comes from the files ID3 tag. Should time permit I intend to automate this using PHP via getID3(). Non ID3 related data is stored in musicImage, which refers to a separate image file, mostly likely an album cover or an artist shot, and filePublic, a boolean which, when set to true, indicates the item is available for download to ordinary users.

Example SQL queries:

Selecting all the tracks of the users favourite genre returning just directory/filename.mp3 via filename:

SELECT fileName
FROM music
WHERE filePublic = TRUE
AND musicgenre IN (SELECT userfavgenre FROM user WHERE username = $currentUser);

Select all files in the genre called hiphop where the quality (bitrate) is 160kps or better. Filter out explicit tracks as our user is under 18.

SELECT fileName
FROM Music
WHERE filePublic = TRUE
AND musicGenre = 'hiphop'
AND musicBitrate >= 160
AND musicExplicit = FALSE;

Planning and Schedule