F164 Website Development: NEA Guide

Every later step depends on the scenario, so pull these six things out of it first and keep the list next to you. Use the scenario's own words where it gives them.

Website type: the type decides most of what goes into the later steps. The table below shows what each type adds.

No devices named: if the scenario does not name devices, state the ones you will support (for example phone, tablet and desktop) as requirements in Step 1, and build and test for those.

Client requirements under the four headings in Topic Area 2.1: purpose, type of website, target audience, content of website. Start from what you found in your scenario. Then the user requirements: what the target audience needs to use the site well.

Turn each one into a numbered, checkable requirement (R1, R2 and so on), including every feature the client names and the devices the site must work on. Step 23 checks every one of them.

Sample: want the website to work on mobile devices becomes "R4: every page displays in a single column with no horizontal scrolling on a phone screen".

All four hosting requirements in Topic Area 2.1: cost, location, security and domain name.

Explain: "Explain" means giving reasons. For each requirement, say what this client needs and why, linked to the site's purpose. Topic Area 2.1 asks how purpose impacts domain name choice and hosting requirements. For example: a site with video or sound needs more storage and bandwidth; a site with forms that collect personal details or orders needs HTTPS; a site that promotes or sells a business needs a domain name that matches the business name.

Tool: A site plan (Topic Area 2.2): every page as a box, the index page at the top, lines for every link. Add the navigation system (which links appear in the navigation bar and footer) and two or three lines of content summary per page.

Check: Read the plan as if you had never seen the scenario. If it does not say what each page contains and how to reach it, add detail. Do this yourself: the assignment is completed under supervision, so the plan cannot be shown to other people.

Tools: Annotated wireframes for each template, ideally one at phone width and one at desktop width, plus a house style sheet: colours with hex codes, fonts and sizes for headings and body, image and text styles (the house style parts of Topic Area 2.1).

Take each house style choice from Step 4 and give a reason tied to the scenario: the brand, the purpose, the target audience, and any words the client uses about how the site should look or feel. Start from those words.

Sample: the client wants a site that reflects the fact that the shop is near the sea, so the colour reasoning can start there.

Columns: Name, type (text, sound, image, video/animation, form), description, where it is used, planned source, and licence or copyright status. Recording the file format and properties now makes Step 13 quicker.

The essential assets follow from the website type and the named features: a multimedia brief needs sound, video or animation; a brief that sells needs product images and an order or enquiry form.

Name each library or framework (Topic Area 1.4 groups them as HTML, CSS, JavaScript and PHP based) and link it to a feature of the site: which requirement it delivers, and how.

Link: D4 in Task 2 asks you to use them and show evidence, so plan ones you will actually use.

The Topic Area 1.5 techniques: crawling, indexing, keywords, metadata, mobile-friendly, ranking. For each one you plan to use, say what you will do and why it makes this site visible to the people searching for it.

Justify: "Justify" means giving valid reasons. Choosing keywords from what the target audience would search for is a reason; "keywords help SEO" is not.

Go through the designs from Steps 3 and 4 and judge each choice against a named guideline. The current accessibility guidelines are WCAG 2.2, with levels A, AA and AAA; for example, text contrast of at least 4.5:1 is success criterion 1.4.3 at level AA.

Assess: "Assess" means a reasoned judgement informed by facts: say how well each choice meets the guideline, including any that only partly meet it.

Three parts: Methods: dry run/trace table, iterative, test plan. Types: technical, viewpoint, user. OCR does not define viewpoint testing; the elements list includes multiple viewpoint size testing, which points to checking the site at different screen sizes. Elements: from the Topic Area 4.1 list, e.g. hyperlinking, interactive elements, multiple device testing, readability of content.

Template: Use the test table in your live assignment if it has one. OCR's sample assignment includes a test table with these columns: test number, test type, test description, test data, expected result, actual result, remedial action required. Writing the first five columns now gives you the test plan.

Give a reason for each method, type and element you chose, linked to the requirements. Topic Area 4.1 covers when it is appropriate to use each testing type and how and why to test iteratively.

Format: The assessor must be able to see the final prototype, so submit a version that opens in a browser with no extra software, or recordings of it working. A recording also shows interactions that screenshots cannot.

Folders for templates, assets and pages (Topic Area 3.1), index.html in the root folder, pages named as on your site plan. Screenshot the expanded folder tree.

Techniques: The Topic Area 3.2 examples: sizing, changing resolution, cropping, removing backgrounds, changing the length or duration of sound, video or animation, and animating static images into moving objects or banners. Choose web file formats and use a naming convention.

Components: Navigational (Topic Area 1.4): hyperlinks, hotspots, navigation bar. Interactive (Topic Area 2.1): buttons, media controls, user input fields, rollovers. Every link on your site plan should work.

"Appropriate" means the components your scenario calls for: media controls for a multimedia brief, user input fields for a brief that collects enquiries, orders or bookings, and every interactive feature the client names.

Tools: A visual design environment or a scripting environment with coding assistance, a template for the shared parts of every page, CSS, form controls, interactive features, then preview in several browsers.

Put the house style from Step 4 into one external stylesheet linked from every page. Screenshot the stylesheet next to the pages it styles.

Features: The Topic Area 1.4 features: browser and device compatibility, fluid grids, media queries/break points, relative sizing. Add the viewport meta tag.

Evidence: Film or photograph the site on each device named in the scenario. Browser device emulation is useful while building, but the guidance names the devices themselves. If the scenario names no devices, use the ones you set as requirements in Step 1.

Valid HTML and CSS (check with the W3C Markup Validation Service and the CSS Validation Service), semantic elements, the page language, alt text on every image, labels on every form input, captions or transcripts for media, sufficient contrast, and everything usable by keyboard.

Link: This builds what D2 assessed in your designs, so use the same guidelines.

Implement what you justified in Step 8: a unique <title> and meta description on each page, keywords in headings and text, descriptive file names and alt text, a mobile-friendly layout. Screenshot the code for each technique.

Evidence: Screenshots of where each library is linked in the code and of the feature it delivers on the page.

Run the tests planned in Step 10 and fill in the actual result for each. OCR recommends its test plan template, and a different appropriate template must not be penalised.

Analyse: For each failed or partly passed test: what went wrong, why, its effect on users, and the fix needed. Look for patterns, such as several failures caused by one missing media query.

The Topic Area 5.1 list: client requirements, user requirements, accessibility, device independence/compatibility, responsive design, and the SEO techniques used. Work through your numbered requirements from Step 1 and judge each as met, partly met or not met, with evidence from testing.

Improvements from Topic Area 5.2.1: accessibility, browser and device compatibility, content, visuals and interaction, domain name, SEO, security, considered against the constraints (legislation, libraries/frameworks, skills, software, time). Further developments from 5.2.2: extra content and features, further user interactivity, hosting, payment gateways/processors.

Discuss: "Discuss" means presenting and evaluating points to reach a reasoned judgement. Weigh each improvement's benefit against its cost and effort, and say which should come first.