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.