Docs:Course Development
Before a thorough discussion of the use of the wiki to produce course content can be undertaken, the design of the courses themselves must be explained. The course design used by APEcs is the product of over a decade of research, and refinement in response to student feedback. It attempts to take the presentation of electronic learning materials in a different direction than the majority of its peers by emphasising aspects that set the design apart from conventional written texts or agglomerations of text, powerpoint, and other "strictly presentational" media. APEcs' course design philosophy can be roughly summarised as:
- Breaking material up into small chunks is a Good Thing.
- Linearity is a Bad Thing.
- Interactivity is a Good Thing.
- Make the most of the platform.
What follows is a more in-depth discussion of these points and how they apply to the design and creation of course material in general and within this wiki.
Small Chunks are a Good Thing
There have been numerous studies conducted concerning reader attention spans, many of them producing contradictory results. However, throughout the development and delivery of APEcs courses, one thing that has appeared again and again in comments from students is that splitting content up into smaller pieces - pages with only a couple of paragraphs and an image or animation - makes the material more engaging and easier to digest. APEcs' CBT package structure consists of three distinct levels:
- The course. This is the CBT package itself, and a course consists of one or more (usually 4 or more) Themes.
- Themes represent a conceptual grouping. When writing a course about a programming language you might want to place all the information about flow control in one theme, information representation in another, and so on. If you are writing a databases course you might want to put design methods in one theme, SQL in another... Basically, a theme is a large collection of associated concepts, or possibly even only one concept, and each Theme contains one or more Modules.
- Modules may contain discussion of one concept per module, several simple concepts per module, or even several modules discussing a single concept at different levels of detail. Modules are colour-coded by difficulty or complexity:
- green modules are simpler and less detailed, generally used when introducing the basic aspects of a concept, or when discussing a very simple concept.
- yellow and then orange modules are increasingly complicated or detailed. They let you refine information presented in green modules, fleshing out concepts and providing more details about them, or covering more advanced concepts than would fit into a green module.
- red modules are the most complicated, specific, and detailed. They are used for advanced topics, or complicated discussions of concepts introduced in earlier modules.
Modules themselves are split up into steps - individual sections in the wiki, and pages in processed courses - which break the discussion of the concept or concepts up into small pieces, illustrating the discussion with diagrams, interactive animation, video, sound, or other media. In general, each step will only contain a handful of paragraphs, any significant length may indicate that the step needs to be broken up into two or more pieces.
This structure has some analogies with conventional written texts, but its granularity is better suited to electronic media. In particular, it is easy to fall into the trap of associating themes and modules with sections and chapters of a linear textbook - while there is some equivalence, you need to be careful to avoid the trap of linearity...
Linearity is a Bad Thing
Unlike a printed textbook, which will generally tell a linear narrative concerning its subject (introducing concepts with a basic outline early on, and slowly building on them as the text proceeds), such linearity is not really desirable in a CBT package. It may be tempting to split your material up so that one theme in the CBT package corresponds to the first chapter, or group of chapters, another theme is the second chapter, and so on. The system is flexible enough that you could, in fact, do this, but doing so is not making the most of the features and structure available: it makes your material harder to browse as a reference, and makes it difficult to have multiple different paths through the material tailored to different levels of student ability.
If you organise your material so that related concepts are grouped together, the student doesn't need to look through several different themes or modules to locate a given concept: they may simply go to the theme that is concerned with that concept or the group of concepts it falls into. The aim here is to split your material up so that one theme covers a concept or group of closely related concepts, another theme covers another concept or group, and so on. Within a theme, modules follow on from each other going from basic and shallow descriptions of the theme's concept or one of the concepts in its group through to detailed, specific, or complicated. Perhaps a useful, if still somewhat inadequate, way to look at the idea is to treat a course as a collection of small, extremely specific, books: each theme is one of these books, and the book concentrates on a specific topic - perhaps one covers nothing but control flow, another looks at overheads at various levels of detail, a third looks at storage. Of course, this analogy fails because, even within a theme, there is no need for linearity: each module may logically lead to two or more other modules directly, as you can see in the diagram to the right!
It is especially important to note that, in general, using lecture material - powerpoint slides, lecture notes, etc - as the basis of material in the wiki should be done only with the utmost caution. Preferably, do not use them at all! Powerpoint slides and lecture notes are never sufficient as course material: when giving a lecture, you do not simply read your slides; you talk about the material and use the slides and notes as reference points, memory aids, and brief summaries that only include a fraction of the important information you are imparting to the student. If you use slides and lecture notes, you may well end up writing more than you could without them, and struggling to fit your material into a structure that works well. Think very carefully before using existing sides and notes as the basis for a course, as you will often be well be better off without them.
When looking at your material, and trying to organise what you need to cover into themes and modules, it can helpful to look at the titles you are considering giving them. If you have long theme or module titles, it is quite possible that you are attempting to put too many concepts into too few themes or modules - if you are using words like 'and', or 'or', or there are commas in your theme and module titles, it is almost certain that you need to look carefully at your structure and try to split your themes or modules up more. Put in software engineering terms, you want to aim for 'high cohesion' in your themes and modules: try to make them focus on specific concepts or related groups of concepts. Never be afraid of making 'too many' themes or modules, especially during earlier stages of development: they can always be merged or rearranged later if necessary!
It's important to note that, even if the course package does not enforce any linear structure, the supporting material for the course may indicate the recommended path through the package! It is quite understandable and reasonable that the tutor should want to direct students along a linear path through the material (if nothing else, to keep the students in sync and so that everyone has an idea of where they should be in the course at any time). This can be done with a separate 'route map' that indicates the modules to study at any given point in the course, it may even tell the student that they need to study several modules in different themes at any given point, so that they are studying a variety of different concepts at a given level. It is even possible to provide different route maps for different versions of a course, or you could instruct more able students to optionally skip specific pieces of a theme rather than waste their time on it.
Interactivity is a Good Thing
Including interactive material - be it stepped animations the user can click through, videos or sound the user clicks to start, self-test quizzes, or full simulations - can go a long way to helping retain student attention, and help the student to learn more effectively. It provides a different representation of the concept you are discussing than 'plain, boring' text, and the need to do something rather than passively read through content helps to keep the reader active and awake!
Interactive content can, obviously, take many forms and the details are mostly beyond the scope of this document, but ideally you want to try to use as much of it as possible. Even it it seems redundant to replicate the illustration of something covered in the text, providing an animation, video, short audio clip, or simulation related to it may give the reader a better grasp of the idea than text alone would allow. For example, there are numerous concepts in programming that are much easier to understand and explain when presented graphically rather than just as a Wall Of Text (pointers and complex data structures are prime examples of this). When additional diagrams and animations have been provided concerning these concepts, students have reported a significant increase in understandability and ease of recall. In addition, interactive content can allow students to check that they have understood the contents of the text, and may allow them to notice things they have missed - this is obviously true of self-test quizzes, but animations and videos can also allow students to identify misunderstandings or things they missed in the text.
Make the most of the platform
In part, this is a reiteration of the previous three points - the very nature of electronic teaching resources allows for the creation of material that would be difficult or impossible in conventional printed media. This is actually a blessing and a curse: you can do things that can't be done by traditional means, but it's also very difficult to explain the possibilities and imagine the scope of the system! If you do not intend to actually make use of at least a small subset of the possibilities it presents, you may well be better off just producing a pdf textbook. However, going down that route means that your material will lack features that may greatly enhance its teaching ability. Similarly, simply placing masses of text into the wiki will result in structured course material, but it can be drastically enhanced by the use of graphics, animation, video, or sound.
The platform provides a very wide range of possibilities - many of them you might not even realise until you talk to one of the APEcs staff - and no one course is likely to use them all, but using even a few can change a course from a wall of text into an interesting, engaging package that can serve as both initial training material and reference while enhancing the student's learning experience drastically.
| |||||||||||||||||||||||||||||||