Know and understand output formats including screen layouts and report layouts

ICT 0417 – Output Formats: Screen & Report Layouts (Cambridge IGCSE ICT)

1. Quick‑check against the Cambridge IGCSE ICT (0417) syllabus

2. Types & Components of Computer Systems (Mapping to Output Formats)

• CPU (Central Processing Unit) – Executes program logic; generates data for both screen rendering and report generation.
• RAM (Random‑Access Memory) – Holds active data while a user works with a screen layout; temporary storage for calculations before they are written to a report.
• ROM / Firmware – Provides low‑level instructions for hardware (e.g., printer drivers) that affect printable output quality.
• Secondary storage (HDD, SSD, USB, Cloud) – Stores source files (HTML, CSS, DOCX, PDF) and databases that feed screen and report outputs.
• Input devices – Keyboard, mouse, touch, scanner, microphone – capture data that will later appear on screens or in reports.
• Output devices
  • Monitor / LCD panel – Displays screen layouts; colour depth and resolution influence design choices (e.g., use of SVG for crisp icons).
  • Printer – Produces hard‑copy reports; DPI (dots per inch) determines required image resolution (≥300 dpi for print).
  • Speaker – Audio feedback for screen interfaces (alerts, confirmations).
• Network components – LAN, WAN, Internet, Wi‑Fi enable delivery of screen layouts (web pages, web‑apps) and distribution of reports (email, cloud storage).

3. Safety, e‑Safety & Legal Considerations for Output Generation

4. ICT Applications – Real‑world Contexts

5. Systems Life Cycle (SLC) – Overview & Output Mapping

1. Planning – Set objectives, resources, and identify the audience for screen and report outputs.
2. Analysis – Gather functional & non‑functional requirements (e.g., required data fields, accessibility standards).
3. Design – Produce wire‑frames (screens) and report templates (layout, fonts, colour palette).
4. Development – Code HTML/CSS, create database queries, set up reporting tools.
5. Testing – Verify that screens render correctly on all devices and that reports match specifications (layout, data accuracy, security).
6. Implementation – Deploy web servers, install printers, train users, distribute reports.
7. Evaluation – Collect user feedback, measure performance, recommend improvements.

6. Screen Layouts – Design, HTML/CSS & Accessibility

6.1 Core Components of a Screen Layout

6.2 Design Best‑Practice for Screens

• Consistency – Uniform fonts, colours, button styles, and interaction patterns.
• Responsiveness – Use fluid grids, flexible images, and CSS media queries to adapt to desktops, tablets and smartphones.
• Accessibility – Minimum 4.5:1 colour contrast, scalable fonts (≥12 pt), ARIA labels, keyboard navigation.
• Usability – Keep critical actions within thumb‑reach on mobile; limit clicks to complete a task (ideally ≤3).
• Security – Mask passwords, hide sensitive data, enforce HTTPS, implement session time‑outs.

6.3 HTML /CSS Essentials (AO2 – Design)

• Semantic markup – Use structural elements:

  <header> … </header>
  <nav> … </nav>
  <main> … </main>
  <section> … </section>
  <footer> … </footer>

• ARIA attributes – Add roles and properties for assistive technologies:

  role="button" aria‑pressed="false"
  aria‑label="Open navigation menu"

• Responsive techniques – Example media query:

  @media (max-width: 768px) {
    .sidebar { display:none; }
    .nav { flex-direction:column; }
  }

• Image handling – Use srcset and sizes for responsive images; prefer .svg for icons (vector, resolution‑independent).
• Performance optimisation – Minify CSS/JS, enable browser caching, compress images (JPEG quality 70 % for photos, PNG‑8 for simple graphics).

7. Report Layouts – Structure, Formatting & Chart Design

7.1 Standard Sections of a Report

7.2 Chart‑Design Checklist (AO2 – Produce)

• Title that clearly describes the data.
• Axis labels with units (e.g., “Revenue (£)”).
• Consistent, colour‑blind safe palette (e.g., #4477AA, #66CCEE, #228833, #CC6677).
• Legends placed close to the chart, not overlapping data.
• Data markers or gridlines only where they aid interpretation.
• Source citation below the chart.
• Resolution ≥300 dpi for printed reports; 72 dpi sufficient for on‑screen PDFs.

7.3 File‑Format Decision Tree (Report vs. Screen)

8. File Management & Supporting Media (Syllabus 11‑16)

9. Database → Report Workflow (AO3 – Evaluate)

1. User enters data (e.g., sales transaction) via a screen form.
2. Data is stored in a relational table (MySQL, Access, etc.).
3. A SQL query extracts the required fields and performs calculations
   (SUM, AVG, GROUP BY).
4. The query result is fed to a reporting tool (e.g., Crystal Reports,
   Microsoft Word mail‑merge, or a Python/LaTeX script).
5. The tool creates charts (using the colour‑blind safe palette) and
   inserts them into a pre‑designed PDF template.
6. The final PDF is:
   • E‑mailed to stakeholders,
   • Saved to a shared drive,
   • Optionally printed.

10. Practical Integration – From Data to Output (Full Example)

1. Data capture – Teacher records student attendance via a responsive web form (screen layout).
2. Database storage – Form data saved in a MySQL table attendance.
3. Processing – Server‑side script calculates monthly totals and flags low attendance (<90 %).
4. Screen output – Dashboard updates with colour‑coded bar chart (green = OK, red = low) using HTML5 Canvas and CSS media queries.
5. Report generation – A scheduled job runs a SQL query, feeds the result to a PDF template (using wkhtmltopdf), applying the report‑layout guidelines.
6. Distribution – PDF emailed to parents; dashboard accessed via secure HTTPS login.

11. Assessment Objectives (AO) & Command‑Word Guidance (Exam Focus)

12. Summary

• Output formats (screen & report) are defined during the Design phase but are shaped by requirements gathered in Analysis and verified in Testing.
• Screen layouts are interactive, must be responsive, accessible (semantic HTML, ARIA, colour contrast) and secure (HTTPS, masked data).
• Report layouts are structured, printable documents that need clear headings, consistent styling, colour‑blind safe charts, and appropriate file formats (PDF, DOCX).
• Hardware, software, networks and storage all influence how data is transformed into screen or printed outputs.
• Safety, e‑safety, legal and audience considerations are essential when designing any output.
• Effective file management, image optimisation, and a solid database‑to‑report workflow ensure data integrity and professional presentation.
• Use the AO table and command‑word list to plan answers for Paper 1, 2 and 3, linking each task to the relevant phase of the SLC.