Skip to content

A Guide to Module Materials

While we will be using Aula to drive the module materials, all of the content written is also available on GitHub Pages.

Here is a quick overview of the conventions I will use here, where I get a few more formatting options.

Accessibility

One reason I have used the GitHub / Markdown approach in the past, is to help students with accessibility issues. For example, I find it really hard to work outside of "Dark Mode".

If you want to talk to me about this, please do, there is a heck of a lot we can do with formatting that can help address any requirements you have.

Dark and Light Mode:

Personally, I hate light mode, the contrast seems to make things much harder to read, but I also appreciate it not for everyone.

Footnotes

Will be used either to:

  • refer to other material (like a citation)
  • As a note on something3

Breakout Boxes

Throughout the text I will be using breakout boxes. I will use this as a way to highlight important points or make tasks clear.

I also use notes to replace the side-tracks that I tend to go down when giving lectures...

Discussions

Are intended to be talking points about the topics we learn. Use the aula to discuss these points with your class mates. If you don't want to use the aula, its cool, expect to be asked your views in the lecture / lab sessions.

Discuss

A question to think about and discuss on the Aula It will usually come with a #tag

Tasks

I firmly believe that learning through doing is the best way of learning4. Throughout the module we will have lots of practical tasks for you to complete.

There are also different levels of task. To get a decent grade in the module you should aim to complete all the easy, and standard tasks. The hard tasks are there to give you the chance to explore the subject in more depth.

Easy Task

You should be able to do this to pass the module.

Task

Being able to complete this should give you a decent grade.

Hard Task

Optional harder task for those who want to test their skills

Spotted a Bug or Typo

Well done. Writing this module was hard because of how much content went into it, and the nature of the topic. Just like writing code, it's not possible to be 100% bug-free and although I try to catch any problems, inevitably some will slip through the gaps2

The "minimising" step here is to try to get multiple people reading the material in advance of the module start, using a spell-checker, and developing in an environment that allows for version control, separation of content and presentation, reducing duplication and the chance for drift, etc. 1

As for catching bugs that make it through that process: you're the beta tester. If you find a bug, typo, factual error or even just have a good idea for improvement, let me know. Drop me a message at (aa9863@coventry.ac.uk). Unless you prefer to remain anonymous, you will be credited as a contributor to the page.

  1. Markdown, MKDocs, Git ↩

  2. You do not want to see the custom dictionary to get rid of the "red squiggles", spell checkers do not like assembly code. ↩

  3. There may even be notes that are less visible. You are hackers, you know the drill. ↩

  4. Its also a practical subject, you will need to do these tasks for the coursework. ↩

Back to top