This post is inspired by the
workshop I attended at MW2009 by Carolyn Royston and Steve Gardam.
I love conferences for the way that they allow you to take time out of work and just open up your brain to ideas. It only takes a few minutes into a good conference session before my brain suddenly wakes from the deep slumber that is often induced from busy days responding to the ever-growing task list and starts to fizz with new ideas, thoughts and connections that aren't usually there.
It struck me that it would be good to start a blog post on things to remember or tips for creating e-Learning resources based on my own recent experiences and also on what Carolyn and Steve had to say on Wednesday. I'm hoping that if this works it can become a growing and evolving post and a conversation between others who may have other experiences and tips to add to it. It's far from being an exhaustive list and I'd be interested in hearing from anyone who would like to add things to it or change bits. Who knows, maybe we could draw on my wiki experience (see my
MW2009 paper on wikis with Frankie Roberto) and turn it into a wiki some day (let me know if you think that would be a good idea).
1. Test, test and test again
This is actually also partly influenced by the second MW2009 workshop I attended on evaluation.
At the start of any new e-Learning project, however small, there should be some form of user testing and evaluation. This could be as simple as running your ideas past the target audience, be it teachers, children of a certain age group or whatever. It will allow you to get an idea before you start spending any time or money about whether your idea will work. It might give you really important pointers about how you should go about your project, or suggest things that you didn't think of putting into the brief.
There should also be formative testing whilst the project is happening. It might be tempting to wait until you have some kind of usable version of the resource already built before testing it, but it's probably also worth paper prototyping (i.e. sketching out what your site will look like and testing the navigation and how pages link together on paper or with simple wireframes) much earlier than this. This is backed up by what Steve and Carolyn did, by the evaluation workshop and also by a conversation I had with a developer I was working with recently.
If there are important functionality issues that come out of testing, it's best to spot them early on and iron them out before complicated code gets written that will take time to correct at later stage. This kind of testing needn't try too hard to get a representative sample of the target audience testing it. As Kate and Jes pointed out yesterday, if you get a handful of people who don't have a clue what you're trying to achieve with your resource then that's enough to tell you that you need to make changes!
You should also evaluate your project at the end as well, even if, by that stage, you're just glad it's over. If there's scope to still change things then remedial evaluation can work but even if it's just to learn some lessons for the next similar project you do, or to share your findings with others so that they can learn from it too it is a valuable exercise.
2. Think carefully at the outset about who you need to involve in the project and what each of their roles will be
In the National Museums Online Learning Project this was particularly important because they were working across 9 big national museums with different structures, different skills, different amounts of experience etc. Carolyn used Basecamp to communicate with everyone involved in the project and it sounds like this worked really well.
From personal experience as well I would say that it's particularly important to remember that you will need considerable curatorial input into any e-Learning project. In the early stages of a project, it can be easy to concentrate on the people who will be directly managing the project. Even if the content is to be created by educators, and the technical side built by technical people, it is the curators who need to approve every aspect of factual content and the historical accuracy of any illustration etc in the resource. Getting a curator involved in the early stages of a project and making sure that project timing is planned around curatorial workloads as well as those of the departments directly creating the resource could save a lot of time further down the line. In addition, curators may be able to suggest items in the collection or subjects that an educator might not have thought of. The same is also true for other departments in the organisation. Consider for instance whether you will need to use images, and if so, what the copyright implications are and who you need to talk to in advance of the project starting about this.
Also from experience I would recommend establishing roles and levels of authority to sign things off at this early stage of a project and make sure everyone is aware of it and agrees with it. This way, if difficulties arise later on then it will be easier to resolve them. I would also advocate having a fairly formalised sign-off process which establishes an order for people to sign things off (and involves an actual signature on paper) to ensure that those with ultimate sign-off see any iterations last so that they can also approve/challenge everyone else's comments and changes.
3. Plan your resource
Steve and Carolyn stressed the importance of establishing their aims and deliverables at the start of the project. This is particularly important in a multi-partner project like theirs because it's imperative that everyone is 'singing from the same song sheet' from the start and knows what the project is trying to achieve.
I was initially quite sceptical when I was first introduced to Inspiring Learning for All but the thing I find the Generic Learning Outcomes (GLOs) particularly useful for is forcing you to anchor your project in what you want people to take away from it at the end. From a quick glance it also looks like the new Inspiring Learning website is a lot easier to use than the old one and it's much easier to find the GLOs quickly.
Steve and Carolyn suggested some key questions to ask yourself/things to remember at this planning stage:
1. be really specific about your target audience.
2. Are you genuinely meeting an audience need?
3. What do you want to achieve with this resource?
4. How is the project funded and when does that funding end (and how will the project be maintained once the funding is no longer available)?
5. Who is writing the content?
6. How will you produce content appropriate for your audience?
7. How will you make sure that your content maximises the potential of the web?
8. How will you transform raw content into an online resource?
9. How will you manage your quality control?
10. Do the people have the right skills to handle the content?
I'm going to leave this post there at the moment. As I say, it's far from being an exhaustive list. I'm hoping that it's just a start and can be something that can be built on and can continue to grow. Please feel free to comment with suggestions and I'll try and update the post as and when I think someone has added a good idea.
Labels: mw2009
