Lab report — expectations and outline

A short, illustrated report presenting your progress, implementation choices and final result.

Your report should make clear what you did, how you did it and what you understood. Keep it short, visual and easy to review: favour screenshots and brief explanations. I already know the lab instructions; present your own work without copying or explaining the assignment again.

1. Header and Git repository

Submit your report as a PDF. At the very beginning, clearly include:

  • The first and last names of everyone who worked on the lab.
  • Your programme, year and group.
  • The course, lab number and title, and submission date.
  • A link to the project’s Git repository whenever requested. Providing this link is good practice even when it is not explicitly required.

The instructor must be able to access the repository, download the project and test its features. Include any brief instructions needed to run it, for example in a README.

Optional, but helpful: organise commits or tags by question, step or feature to make your progress easier to follow and support technical assessment.

2. Progress through the lab

Follow the main steps of the lab. For each step, present:

  • What you implemented, with one or more readable, captioned screenshots showing your progress.
  • How you proceeded and what you understood, in a few short sentences or bullet points; mention implementation choices when they help explain your work.
  • Any difficulties or blockers: what went wrong, what you tried and how you resolved it. Clearly identify any issues that remain unresolved.

Document intermediate steps as well as the final result. Your images should show how the application developed and which features you implemented along the way. Add a short caption explaining what each screenshot shows or demonstrates.

3. Conclusion: final state and personal reflection

End with a brief assessment:

  • What the final application actually contains: completed and tested features, partial or missing elements, and known limitations.
  • Optionally, a personal reflection: what you learned, the main difficulties, possible improvements or ideas for further work.

Should you include code?

There is no need to copy your code into the report. A very short snippet of pseudocode or code may help explain a particular function or choice when it makes the explanation simpler.

The report is used to assess your approach and understanding. Technical assessment of the code and application testing use the Git repository.

Reusable outline

  1. Header — names, group, course, lab, date and Git link.
  2. Lab steps — for each step: work completed, captioned screenshots, approach and choices, and any difficulties and solutions.
  3. Conclusion — the application’s exact final state, limitations and optional personal reflection.

Before submitting, check the PDF, author details, screenshot readability, coverage of intermediate steps and access to the Git repository if you provide one.