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.
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+.
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.
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:
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.
Provide a brief explanation of how your wireframe solution fulfils the requirements outlined by the OURC Admin team.
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:
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.
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.
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:
These resources can be downloaded from the module web site as the file emaMobileResourses.zip.
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:
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 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:
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.
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:
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.
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.
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:
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.
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: