RECENT ASSIGNMENT

A group of past and present students have formed an OU Walking Club, where they can take part in organised walks and socialise.
Following a recommendation from the OU Running Club, the club organisers have contracted Online Solutions to undertake the design of a website targeted to the needs of current and new club members (the ‘club website’). The design proposed by Online Solutions will allow current and potential club members to view planned walks, news and other events. It will also enable new club members to sign up and consent to receive email announcements, and current club members to post their own walk events.
However, this process has not addressed how the content of the club website is to be managed.
The club organisers (the ‘admin team’) are keen to create a web application that will support the day-to-day administrative tasks that are essential if the website is to fulfil its design goals (the ‘admin application’). Without this web application, these tasks can only be accomplished by people who have the knowledge and skills to work with PHP and databases directly. It is hoped that, by creating a web application, the work can be shared among all members of the club’s admin team.
The admin team has had several meetings to try and establish what the admin application should provide in terms of basic functionality, but they are concerned about some of the implementation details, and the security of the application.
Only two members of the admin team have any experience of managing the development of a web application from concept to deployment. The team is therefore looking for some practical advice about development, testing and version control for the application.
Online Solutions are too busy to develop the admin application, so the admin team have asked you to step in.
Online Solutions have produced wireframes for the club website. The admin team feel that these wireframes help to clarify the overall structure and navigation of the club website, and they would like to see something similar for the admin application. They are keen to know if the requirements they have identified can be rationalised into a coherent set of web pages that illustrate how the various features of the application will be presented to an admin user.
Your task is to create ‘interactive’ (i.e. navigable) wireframes of your proposed solution for the administration application as it might appear on a laptop or desktop screen (i.e. 1024px wide, landscape orientation). The wireframes should demonstrate how the different parts of the application are organised, what information is displayed on each page, how navigation works between the pages, and so on. Pages returned by a server in response to specific user input are not required. You should also think carefully how your design will respond when viewed on a mobile device screen (i.e. 375px wide, portrait orientation) and include two ‘interactive’ wireframes (two pages) to illustrate how the solution might appear on a mobile device screen.
Your wireframes must be submitted as a set of one or more HTML files and may also include CSS and image files. You can use Pencil, a text editor, or any other tool with which you are familiar to create these files. Submitting your wireframes in any other format will result in a penalty being applied.
Should you decide to use Pencil, you must use the ‘Export Document’ option to export your wireframe as a ‘Single web page’ using the ‘Default HTML Template’. This creates a HTML file and a folder of images which ensures that the client can review your wireframe without the need to install the Pencil application. You should not make any further changes to these files and make sure to include them all in your submission.
Collect the files that make up your wireframes into a single ZIP archive, retaining any folder structure that you may have created (e.g. that created by Pencil). Please name the ZIP file using your own OUCU (namely ‘OUCU_Q1.zip’) and record the filename for your marker in your document.
It is essential to keep in mind that a wireframe illustrates successful capture of an application’s requirements by means of content and information architecture. It is not about implementation or branding, so should not include coloured text or images. 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 displayed on a page. You can set the image width and height attributes to the size required.
You may find the following pointers useful.
Consider the application from an admin user’s perspective to see how information might be organised or functionality grouped. There may not be an exact match between pages and features.
Consider how users will navigate around the admin 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).
Think how your design your respond when viewed on a mobile device screen.
1(b) Explanation
In your document, for the admin team, define what wireframes are and provide a description of their role in web development. Then explain how the design demonstrated by your wireframes fulfils the requirements they have outlined.
Hint: imagine that you meet with the admin team and walk them through the key features of your solution – this is not simply an explanation of what you have done, it is an explanation of why your design is appropriate.
You have a maximum of 500 words for Question 1(b).
2(a) ‘Add walk event’ page for laptop screen
This part of the question is about the admin application.
The admin team is keen to see some ideas for the visual design of the admin application. Given that the application is not accessible to the public, the design is not required to meet the OU ICE guidelines, but the implementation must be standards-compliant.
Your task is to create and validate a web page containing a form to allow a member of the admin team to add a walk event. The overall page layout should be consistent with your wireframes and must be valid HTML and CSS. The page must, of course, be an actual realisation of the corresponding wireframe component and not simply a repetition of a part of the wireframe itself.
The form should work and submit data to the TT284 reflector: http://students.open.ac.uk/mct/tt284/reflect/reflect.php. You are not required to implement any PHP to process this data at this stage.
The form should include a hidden field. The field should be named ‘sessionID’ and should contain the value ‘abcd1234-ee56-ff78-9090’.
The page should use a CSS style sheet.
As with the wireframe, the page should be easy to use on a laptop or desktop screen (1024px wide, landscape orientation, e.g. 768px high).
The page and form should be accessible.
The form may use HTML5 input types described in Block 2 Part 3, but validation of input data is not required at this stage.
Any admin application navigation features proposed in your wireframes should be present on the page, but are not required to function.
The web page and any related files should be clearly named e.g. ‘q2a.html’, ‘q2a.css’.
Validate your HTML using the W3C Markup Validation Service.
You can validate the file by uploading it directly to the validator service. Make sure that you are using the HTML5 option. There should be no errors reported. As with earlier assignments, you are not required to address any warnings that may be reported. You should also validate your CSS, but you are not required to provide evidence of this.
Ensure you read Question 5 before completing Question 2.
In your document, for your marker, provide a screenshot of the part of the page that shows the line ‘Document checking completed’ and the tags within the head tag of your source code just below. Record the filename of your 2(a) HTML file so that your marker can open and test it.
2(b) Responsive ‘Add walk event’ page
This part of the question is about the admin application.
Some members of the admin team are interested in the possibility of carrying out some admin tasks using a mobile device; for example, while they are on a walk. They would like to see how the admin application might be presented on a mobile device.
Your task is to make a copy of your solution to 2(a) and amend the CSS and HTML as appropriate to present the same form on a smartphone-sized screen.
Use techniques you have learned in Block 3 to allow the page layout to respond to screen width, such that the page and form are also usable on a mobile device screen (375px wide, portrait orientation, e.g. 667px high). Both the form and the page navigation should be responsive.
No changes to functionality are required, but you may consider HTML5 inputs even if you did not use these in your 2(a) solution.
The page and form should continue to be accessible (consider any accessibility decisions you made in 2(a)).
Take care not to change your original 2(a) solution files.
The web page and any related files should be clearly named e.g. ‘q2b.html’, ‘q2b.css’.
Your 2(b) solution should work for two combinations of device and orientation: a mobile device in portrait orientation and a laptop device in landscape orientation. Therefore, your solution should work at two screen widths: 375px and 1024px (‘Mobile M’ and ‘Laptop’ in Chrome’s Device Toolbar, as described in Block 3 Part 1 Activity 5). Your solution is not required to respond appropriately to widths less than, between, or greater than these two values.
Hint: as you saw in Block 3 Part 3, page layout on mobile device screens is typically a single column, with the most useful or commonly used content or functionality presented sooner. For forms, labels are often presented above inputs rather than to their left. In addition to examples provided in Block 3, the file ‘emaMobileResources.zip’ provides a further example of some HTML and CSS which you can adapt if you wish.
Validate your HTML using the W3C Markup Validation Service. You should also validate your CSS, but you are not required to provide evidence of this.
In your document, for your marker, provide a screenshot of the part of the page that shows the line ‘Document checking completed’ and the tags within the head tag of your source code just below.
Collect the files that make up your 2(a) and 2(b) solutions into a single ZIP archive, retaining any folder structure that you may have created. Please name the file using your own OUCU (namely ‘OUCU_Q2.zip’) and record the filename for your marker in your document. Record the filename of your 2(b) HTML file so that your marker can open and test it. Note that your 2(a) and 2(b) solutions must work independently of each other.
2(c) Explanation and recommendation
This part of the question is about the admin application and the club website.
In your document, for the admin team, describe the features of the page design in your 2(b) solution that make it responsive. Describe any choices or compromises you made or difficulties you encountered in making the page and form responsive, usable and accessible on a mobile screen. Explain why you made such choices and compromises. (It does not matter if you made these changes in your 2(b) solution or they were already present in your 2(a) solution.)
Then, given this experience, and drawing on your view of the likely needs of club members and the admin team, discuss whether the admin team should focus on making either the club website or the admin application (or both) responsive to mobile devices, or whether they should consider another approach.
You have a maximum of 500 words for Question 2(c).