The ten technical principles of building effective courseware

Hello everyone,

Firstly to introduce myself on my first posting to the blog, my name’s James Connor and I head the technical team at Epigeum.

Following on from David's last post on effective courseware design, I'd like to add a post on the technical principles of building effective courseware. It's tough to keep this at ten, but I have managed to do so and here is my list. Let me know if you have any comments or suggestions.

1.Adhere to standards

Adhering closely to standards such as IMS Content Packaging gives you flexibility on how to distribute your courses and allows you to tap into the ecosystem of developer tools, skilled staff and delivery systems that surround a standard. These advantages are generally beneficial but critical to a content publisher such as Epigeum.

2.Ensure compliance with accessibility legislation

We take accessibility seriously and not just to meet accessibility legislation. We believe that the more accessible our courses are, the easier they are to use. We want all users to be able to access our courses and also find that features such as video transcripts, the ability to increase text size, and printable versions of screens are generally useful, whatever the requirements of a particular user. We'll publish a further Epigeum Insights soon giving an overview of the accessibility measures taken when building our courses.

Lines of ActionScript code

3.Reuse code templates where possible

Reusing code templates enables you to build materials more quickly and to a higher quality. The speed increase is obvious but why the increase in quality? We find our code templates don't stand still but are continually refined, meaning that far more thought and work is put into reusable templates than one-time builds. We also find that usability is increased as the user becomes accustomed to how our interactive objects work.

4.Ensure you have a robust commenting procedure in place

Anyone familiar with computer coding will be familiar with the feeling of frustration when trying to edit code that has been poorly commented. Commenting code is a key skill required of all programmers, but developers tend to be more diligent in their comments when coding software rather than e-learning content. However, like software, if you build good-quality content then there will be a need to revise and update this content on a regular basis. Robust commenting procedures are also required if your developers work in teams as we do at Epigeum.

5.Don't use the latest specifications but do continually innovate

A danger of rushing to cutting-edge specifications is that most people will not be able to access your materials and those that can are likely to have a frustrating user experience. However, this doesn’t mean that innovation isn’t crucial. If you stand still in our field, then your courses will look dated very quickly. We keep an eye on all new technologies emerging in the industry, particularly the ones that we feel will make for an improved user experience. Our approach is to be continually innovative with our products but ensure that they remain usable.

6.Pay attention to the detail... repeatedly

Check, check, and check again! Technical delivery requires as much attention to detail as editorial and content. How many times should you check? Well, it probably depends on how many people are involved, in that the more people do the checking, the less iterations are required. At Epigeum we supplement formal proofreading and user testing with a system that asks all staff to perform QA at each level, from editorial down to the programming of each individual object built by our developers.

7.Keep it simple

With the advent of technologies such as HTML5, Ajax and sophisticated CSS, the technical build of webpages is becoming increasingly intricate; however, when it comes to e-learning material, it pays to keep it simple. Delivery platforms such as VLEs are continually updated and complicated structures nearly always break when viewed across different VLEs! Therefore, our advice is to keep things simple, building solid code using HTML, JavaScript and ActionScript, that we know will work across all browsers.

8.Don't build until you have completed storyboards and brief from editorial team

The storyboard is the final paper version of the course content, ready to be built into an interactive format. There is always the temptation to make a start on a build before the specification is 100% complete, but in our experience this nearly always results in repetition and errors that actually result in a build finishing later than planned rather than earlier.

9.Check your courseware within its delivery framework

Like most e-learning content these days, Epigeum courses are delivered to users through a VLE/LMS. It seems obvious, but it is dangerous to assume that courseware will work as planned within the VLE/LMS just because it works fine outside it. VLEs/LMSs are strange and complicated systems that tend to perform all kinds of processing on your code before delivering to users. It is essential to test courseware within its delivery platform. At Epigeum our approach is to ensure that our courses work in the most commonly-used, mainstream systems, and then offer a personal support service to any universities using a different system if they are having difficulty installing.

Internet browser icons

10.Ensure browser compatibility

This is the age-old question of browser compatibility. The browser market is so fragmented now that it is virtually impossible to ensure courseware is compatible with every existing version of every browser. So what to do? Our strategy has to be to test the most widely-used browsers, checking web browser stats to find which are the most commonly used ones and aiming to hit 95% of systems in use. Our untested belief is that most of the users of the remaining 5% also tend to have access to compatible browsers on their PC. Once we have established the most commonly used browsers, we test every element of our courses with these browsers to ensure compatibility.