The business scenario

The OU Running Club (OURC) has contracted Online Solutions to undertake the design and development of a new website targeted to the needs of existing and new club members. However, this development has not addressed how the content of the new website is to be managed.

The OURC organisers (the admin team) are keen to create a new web application that will support the day-to-day administrative tasks that are essential if the website is to fulfil its design goals. At present most of the content is updated by interacting with the back-end database, so it can only be undertaken by people who have the knowledge and skills to work with MySQL directly. It is hoped that by creating a web-based interface the work can be shared amongst all the members of the admin-team.

The admin team have had several meetings to try and establish what the new application should provide in terms of basic functionality, but they are also concerned about some of the implementation details, especially the security of the application.

Only two members of the admin team have prior experience of managing the development of a web application from concept to deployment. The team are therefore looking for some practical advice about version control, testing of the application, and mobile application development.

The application requirements

Based on the outcome of their discussions, the admin team has identified the following features for the application:

Race results: Occasionally an error is made recording the time or finishing position of a member who took part in a race. The application should provide the ability to correct the recorded result for the member.

Race events: The calendar of race events is continually updated throughout the year; hence a facility is required to add a new race by providing a title, location, date, and an optional reference to a Google map that will display the route of the race. Experience has shown that errors can be made so it must be possible to change the details of an event after it has been created.

Other events: The OURC tries to encourage greater interaction between members through a series of social events. These events are publicised via the club website, but will be added via the admin application.

Membership: A means to add new individuals to the current membership is required. Although self-registration is possible, the admin team has decided that this could be open to abuse by ‘spammers’, so new members must be registered manually. The minimum information necessary to register a new member is the member’s full name and email address.

Members of OURC are responsible for updating their own information via the client website. However, some members have been slow to make the changes, perhaps because they have moved away from the Milton Keynes area or they have left the Open University (OU). The admin team has agreed that any member who has not engaged with the club (taken part in a race or updated their membership) for more than 24 months should be removed from the active members list.

News items: The admin team recognises that, if the club’s website is to remain a valuable resource to members, it must keep members informed of other running related events taking place around Milton Keynes and North Buckinghamshire. News items are intended to be quite short, a maximum of 300 words, and when added will include the dates for first and last showing of the item. When a news item is added to the database, the record must include the ID of the user posting the item, which can be derived from the log-on credentials.

Mailings: The admin team has decided they would like the option to send announcements as emails to the entire membership, but only to those members who have given their prior consent. The messages will be plain text with the option of a single file attachment. The application should provide the facility to create the message, select an attachment, and specify the date the message should be sent.

Authorisation: The application must be protected to ensure that only members of the admin team, or other designated club members, can access it.

Browsers: The admin team has decided that, given the small number of users, all acceptance tests must pass for the following set browsers: IE 8+, Firefox 11+ and Chrome 20+.

Project tasks

This section provides details of the various tasks that you should complete as part of your project.

All your explanatory text should be submitted in a single document. Word count limits are given for each section and include everything counted as 'words' by common word processor applications. No penalty will be applied provided these limits are not exceeded by more than 10%.

Note carefully the dependency of task 4 on the other tasks.

Requirements analysis

Wireframe design

The admin team felt that the wireframe produced by Online Solutions helped to clarify the overall structure and navigation of the client application and would like to see something similar for the administration application. They are keen to know if the requirements they have identified can be rationalised into a coherent set of pages that illustrate how the various features of the application will be presented to the user.

Your task is to create an interactive wireframe model of your proposed solution for the administration application. The wireframe should demonstrate how the different parts of the application are organised, how navigation functions, what information is displayed on each page, and so on. You can use the wireframe of the client application for inspiration (see http://norton.open.ac.uk/tt284/ourc/wireframes/v1.0/ home).

The wireframe model should be submitted as a set of ‘static’ HTML pages and a single CSS stylesheet. The file emaWireframeResources.zip contains simple placeholder images (bars, squares and rectangles) and a file of ‘latin’ text that you can use to illustrate how content will be organised on a page. Set the image width and height attributes to the size required.

Photographs and coloured graphics must not be used; a wireframe is not about visual design.

The pages, stylesheet, and images must be properly organised in a hierarchical directory structure such that anyone can open a single page and navigate to any other page. Keep in mind that your solution will be packaged as a Zip archive and copied to another computer where it will be decompressed for viewing, so ensure you test your solution before submitting it.

You may find the following pointers useful:

  • Solutions that simply create a page for each of the required features will not score well. Consider the application from a user’s perspective to see how information might be organised or functions grouped.
  • Consider how users will navigate around the application. Think about the screen layout and the use of ‘white space’ to separate content.
  • Read the requirements carefully to ensure the admin team has not omitted important functionality (e.g. it should be possible to edit or update an item after it has been added).

All the files that make up your wirefame solution should be collected together into a single Zip archive, so as to retain any folder structure that you may have created. Name the archive TT284_Wireframes.zip.

Wireframe explanation (300–400 words)

Provide a brief explanation of how your wireframe solution fulfils the requirements outlined by the OURC Admin team.

Solution design

HTML form template

The admin team is keen to see some alternative ideas for the visual design of the application. Given that the application is not accessible to the public, the design need not be constrained by the OU ICE guidelines, but must be standards-compliant.

Your task is to design and validate a web page that will display a form to capture an OURC email message. The page should be consistent with the wireframe model you have created and should be validated against the XHTML ‘strict’ and CSS 2.1 standards. The validation reports, which can be saved using your browser's 'save as' feature, should be included in your submission as evidence of successful validation.

You are not required to produce any JavaScript for client-side validation and no marks will be awarded if any validation script is provided.

You may use any of the images provided in the resource files emaWireframeResources.zip or emaMobileResources.zip.

For the purposes of this task you should:

  • set the ‘action’ attribute of the < form > element to ‘http://students.open.ac.uk/mct/tt284/reflect/reflect.php’
  • set the ‘method’ attribute to ‘post’
  • include a hidden field to track the current user. The field should be named ‘sessionID’ and should contain the value ‘ABCDEF01-ABCD-ABCD-ABDC-ABCDEF012345’.

The HTML and CSS files and the two validation reports (XHTML and CSS) should be collected together into a single Zip archive so as to retain any folder structure you may have created. Name the archive TT284_Template.zip.

Security and data validation (300–400 words)

The administration application includes the facility to create and send ‘news’ items. Such items are likely to contain links to other web content and could therefore expose sensitive information from the database to the client. Two of the most commonly encountered security issues associated with this type of ‘user content’ are ‘cross-site scripting’ and ‘SQL injection’.

Briefly describe what both these security issues are and what must be done in terms of client/server data validation to protect the web application.

Mobile development

Data entry form

Several members of the OURC Admin team regularly use mobile devices for web activities and are keen to ensure that the design of the administration application does not preclude use of mobile devices.

Your task is to create a single CSS file that will control the display of a generic form on a mobile device. To this end you have been provided with:

  • an HTML form which should be displayed in a mobile device. You should not need to edit the HTML page itself, but should aim to display the page in a device such as ‘Generic – WVGA (480x800)’. This is one of the ‘standard’ devices supported by Ripple (which you used earlier in Block 3).
  • a style sheet ‘styles.css’ which displays the web page with styling suitable for display in a browser, or other device, with a width greater than 480 pixels.
  • an empty style sheet file ‘mobilestyles.css’ which you should use to hold your style declarations.
  • a JavaScript file which is loaded as an external script file by the form and which switches between ‘styles.css’ and ‘mobilestyles.css’ according to the width in pixels of the device displaying the form. You should not need to edit this file.
  • a directory of images which are used in the form. You may add your own images if you wish.

These resources can be downloaded from the module web site as the file emaMobileResourses.zip.

Changing Styles for a Mobile Device

In Section 6 of Block 3, Part 1 you saw how to use JavaScript to detect the size of the screen and use the outcome to change the style in use for the body of a document.

The code listed in this section should be relatively familiar to you as it performs a similar operation to that in Block 3. The significant difference is that the entire CSS file is changed by the function rather than just the class of the document body.

There are several approaches to changing the styles in use dynamically. The style sheet being used by a web page is declared in the < head > element of a page, for example:

< head > < link rel="stylesheet" type="text/css" href="mystyle.css" /> < /head >

In terms of the Document Object Model (DOM), which you met in Block 2, the < link > element for the CSS file can be seen as a child node of the < head > element ().

Figure 1 DOM tree structure of a simple document with a link node (View larger image)

JavaScript can be used to manipulate the structure and content of a web page through the DOM by adding, changing, or deleting nodes.

To change the CSS file that a page uses the HTML head node can be retrieved and a new link node added as the last child of the head node. This will mean that styles in the new link node will be applied.

The function ‘changeStyle’ listed below will:

  • Get the head node (into a variable _head)
  • Create a new link node (or element) and set attributes of this so that it represents the HTML declaration: < link rel="stylesheet" type="text/css" href=cssFile />
  • where ‘cssFile’ is a parameter passed into the function that contains the name of the CSS file to be used.
  • Append the new link containing the reference to the CSS file as the last child of the head node.
function changeStyle(cssFile) { var _head = document.getElementsByTagName(‘head’)[0]; var newlink = document.createElement(‘link’); newlink.setAttribute("rel", "stylesheet"); newlink.setAttribute("type", "text/css"); newlink.setAttribute("href", cssFile); _head.appendChild(newlink); }

As you saw in Block 3, the ‘changeStyle’ function can be called by a simple ‘if’ statement according to the width of the device that is loading the code:

if ( window.innerWidth <= 480 ){ changeStyle("mobilestyles.css"); } else { changeStyle("styles.css"); }

The test for a window.innerWidth less than or equal to 480 pixels is used to decide which CSS file to use to display a web page. Keep in mind that on a mobile phone the window size always fills the whole screen so that if the screen width of the device is less than 480 pixels then the ‘mobileStyle.css’ file is used otherwise the ‘styles.css’ file is used.

The reference to the external JavaScript file, that contains the ‘changeStyle’ function and the window-width test, is located in the < head > element of the page to ensure that the script is executed before the page is displayed.

The HTML Form Displayed

The HTML form provided comes with a quite complex style sheet ‘styles.css’ which is a version of the actual styles produce by Online Solutions in the OURC case study. The form has a look and feel similar to the rest of the OURC web site.

A snapshot of the form displayed in a desktop browser (width > 480 pixels) using the ‘styles.css’ file is shown in Figure 2. Whilst the appearance is quite attractive and fits well with the OURC web site style it is not very suitable for display in a mobile device. See image.

Figure 2 OURC Form displayed by browser (View larger image) If you display the same HTML form in a device with a width <= 480 pixels (such as the ‘Generic –WVGA (480x800)’ device found in Ripple) then the ‘mobilestyles.css’ file is selected by the JavaScript. As provided to you, ‘mobilestyles.css’ is empty, so there is no styling applied and the form will appear as shown in Figure 3. See image.

Figure 3 OURC form displayed in Ripple device with no styling You task is to add styles to ‘mobilestyles.css’ so that the form is displayed in a more usable and attractive fashion. There are two approaches you could take:

  • You could copy much of ‘styles.css’ and then simplify and adjust this to suit a mobile device.
  • Write a set of style declarations of your own to style the HTML elements in the form.

Figure 4 shows an example of the form displayed after taking each of these approaches. See image.

You may take whichever approach you prefer. You may also add graphics of your own but only via the style sheet; (you must not edit the HTML file).

Whichever approach you take you will probably find it useful to examine the styles in ‘styles.css’ to see how some of the features of the form are presented. In particular note the use of background images in the style sheet, for example:

#header .ou{ background:url('./images/ou_logo.png') no-repeat 0 0 }

which will use the image file ‘images/ou_logo.png’ as the background for items with class ‘ou’ that are descendants of the item with an ID value of ‘header’.

As the two examples in Figure 4 illustrate, all items should be displayed on the device in a simple fashion. Both of the solutions illustrated are equally acceptable for the purposes of this project even though the left-hand version is more consistent with the OURC site style.

Development tools (300–400 words)

None of the admin team has any experience of mobile application development, so they are keen to know what you have learnt.

Provide a brief assessment of your experience using App Inventor and compare the features of the App Inventor platform to any other mobile application development platform (e.g. PhoneGap). You might like to consider aspects such as:

  • Support for native apps vs. web apps
  • Total cost of ownership
  • Access to and the power of APIs that are provided
  • Ease of use vs. flexibility of the tool(s)
  • Support for single or multiple target platforms
  • Quality and availability or support and documentation
  • Availability of potential staff familiar with the platform
  • The likely future path the platform might take.

When writing this section don’t get bogged down in the step-by-step details of how to use App Inventor; think in terms of how well App Inventor supported you in producing applications and your own personal view of its weaknesses and strengths.

Development management

Acceptance test plan

Prepare a tabular outline of an acceptance test plan for the administration application. The plan should detail what is to be tested, how it will be tested, and by whom it will be tested. The entries in the table should reflect the sequence in which the tests will be undertaken.

No word limit has been set for this tabular plan. Any comment or explanation will be ignored.

Version control

The OURC Admin team has been advised that they must ensure that application development is carefully managed and that some form of version control is put in place from the outset of the project.

Your task is to demonstrate how you would use version control for one of the design tasks. You will need to create a local SVN repository, create storage for the assets under version control, and use the repository to track changes as the design activity progresses.

Evidence of your use of version control should be provided in your report. There are three forms of evidence that you can provide, only one is required:

  • a snapshot of the repository browser window to show the internal structure of the project’s folder
  • a snapshot of the Log Messages window to show content changes over time
  • a sample of the ‘log messages’ extracted with the command-line utility ‘svn’. You may want to extract the messages in two goes, a few early messages then a few of the later messages. 10 – 12 messages are more than sufficient.

Please ensure your evidence is self-explanatory by providing captions to images, and titles to tables and lists. Failure to clearly identify what the 'evidence' shows could lose you marks.

Developing at scale (500–600 words)

Large-scale events, such as the London Olympics 2012, bring a unique set of challenges to the development and deployment of web applications. Briefly describe one example of the solutions (methods, techniques, technologies, etc.) that could be adopted in relation to:

  • maximising availability and to
  • system testing.
Academic Honesty!
It is not our intention to break the school's academic policy. Projects posted are only used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly fill out the form. Please provide a valid email address and we'll get back to you in less than 24 hours. We will be sending an invoice through PayPal upon confirmation. We are a non profit organization however we need an amount to keep this organization running, and to be able to complete our research and development.