Over the past 3 years, we’ve been continually trying to improve our web design course and make it more ‘user friendly’ in response to feedback from learners. Some changes have been really successful, others not so, but we’ll keep trying to listen, reflect and improve the learning experience.
This semester one of the strongest points of feedback has been the need for more structure. People really enjoy the benefits of learning at a pace that suits them individually, but also need more structure - to see the path ahead, to know what is due when, to see exactly where they are in the course. These are all very reasonable points, which begs the question: Why aren’t these things built into the course already? The short answer is that they were, but as we’ve tried to improve the course to suit the flexible needs of learners these qualities have unfortunately slipped in priority… leaving people sometimes feeling like there isn’t a target to work towards. “What’s the due date? Whatever we negotiate together, given your own commitments and client projects” - sometimes this is too vague and difficult with a lot of students. And we want to fix this.
The current course structure
If you’re interested you can read a brief history of the webdesign course to understand how it has developed to date, but the bottom line is that now we’ve got a range of learners learning at their own pace (sometimes in small groups which is great), some who attend fulltime, others who attend one or two set days each week, and a few whose attendence fits in around their work schedules. A very small percentage of learners are able to complete the course in a single semester (usually those who already have substantial programming experience), most full-time students complete in two semesters.
The biggest problem that we’re facing is how to provide a schedule of learning activities that caters for the ranging needs of learners and addresses the required skills. We tried to implement the idea of a succession of mini-projects where each project builds on the last project and integrates more skills, together with individual learning contracts with individual deadlines (see Teaching Web Design Part II for more details). In practice, we’ve only had time to create individual learning contracts with the flexible students (leaving full-time students who learn at their own pace with only a vague schedule or timeline through the course) and the mini-projects were too difficult to develop without time put aside to do so. In addition to this, quite a few students had something better to work on which demanded their time: real client projects.
To enable learners to progress through the course flexibly we’ve been structuring the Web Design Wiki-course into topics (Basic HTML/CSS, Intermediate HTML/CSS, Client-side scripting, Server-side scripting, Emerging Technologies etc) that are based on the national units of competency - which makes great sense for assessment, but not so much for learning. One big problem is that most topics are either too narrowly defined or, on the other hand, way too big to focus on in one hit. Most participants get overwhelmed when they first hit Javascript. They feel that they’re not “getting it” quickly enough and their motivation levels start to sink (an effect I think of as Competency Based Drowning).
In the past we’d schedule 4 weeks of learning Javascript and many people would end up just feeling dumb. For the last year we’ve been allowing people to take their time as they progress through these harder large topics, but because people are then focusing on the one topic for a substantial amount of time, the feeling of progression is lost and as a result some people end up again just feeling dumb.
Ultimately, what we’re looking for is a way to provide a concrete pathway through the course that supports people learning flexibly and yet still provides concrete timeframes for individuals to work with.
Enter the Next Level
In her article What can software learn from Kung Fu, Kathy Sierra highlights how reaching a recognised “next level”, whether in a computer game, a Karate belt, or web programming, stirs us on to keep progressing even when it’s tough:
“There’s always something new to aim for and as you progress through each level, the motivation to go higher keeps growing. How many of you have felt the seduction–where you go into something thinking you’ll never care about anything beyond the bare minimum entry-level, only to find yourself sucked in? Next thing you know, it turns out you did want to learn CSS. Because once you know CSS, then you can do… (and on it goes).”
I reckon people in class have experienced this feeling when they start getting the hang of HTML and CSS! But I also get the feeling that starting Javascript or PHP can be like running into an inpenetrable brick wall. Perhaps a better picture of our motivation would be this second one.
Luckily a number of people in class have real client projects that keep them in the flow of progression and motivated to keep learning. But the problem remains that the larger, more complicated topics can get us bogged down, losing sight of the end, and failing to see any progression in our learning.
My question is: Would it be worthwhile for us to re-structure the course into smaller, more achievable levels - where each level can be mastered in a matter of weeks (maximum 15 days full-time).
Each Level could have it’s own time frame (for e.g., “Estimated time required to master level 1 is 6-8 days”), could include a range of technical, communication and media-based activities that are ideally integrated together. The level description can also be used as the basis for an individual learning contract that is printed and signed - helping us facilitators to negotiate concrete timeframes with everyone. At the end of certain levels learners may be ready to demonstrate their competence in certain units of their qualification. And most importantly, learners can see exactly where they are in the course (e.g. “I’m currently working at mastering level 9. Level 12 is the final level for my course so I’m approximately 3/4 of the way through.”).
Larger or more complicated topics can be spread out over a number of levels and integrated into activities that continue build other skill-areas. For example, Javascript could be introduced in Level 3 (What are Javascript events?), built upon gradually through Levels 4 and 5 (functions, basic input validation etc.) and completed in level 6 (dynamicly hiding/showing elements on a page, more complicated form validation etc.) Yet the learner wouldn’t be stuck doing only Javascript through levels 3-6: the activities at different levels could build on HTML skills (e.g. learning more accessible forms using the label element), CSS Skills (e.g. a few CSS challenges), Multimedia skills (e.g. designing buttons for image rollovers) and communication skills (e.g. determining client functionality required for a dynamic page).
At the end of each level, learners might review their learning (using a variety of tools such as simple Flash-card sets), demonstrate their skills with their facilitator and sign off for mastering that level (possibly also for certain units of competency).
Hopefully this would allow learners the time needed to process and practise more difficult skills while still progressing in other areas, and more importantly, recognising their progression from one level to the next. Learners can always see exactly where they are in the course (which Level). Learners can learn in a holistic yet practical way that can be self paced (but doesn’t have to be), while still having concrete deadlines to work towards. Facilitators can link units of competency and assessment activities to the appropriate level, and hopefully track learner progress without so much pain!
Over to you…
So, over to you. Have I correctly understood the feedback from learners? Would it be worthwhile to restructure the course into smaller, more achievable levels? Do you agree with the benefits outlined for you as a learner or facilitator, or can you see disasterous problems? Please let me know your thoughts below! After you’ve done that, you can even help us brainstorm the new structure on the Wiki-course site.
So in the past, the option of starting a client project early on has not helped most learners to learn the other essential aspects of Web Design. But at the same time, working on a real project early on does provides an incredible amount of motivation for applying our coding skills. So the question I’ve been asking myself is: how can we use a client project early on in the process to build our coding skills as well as introduce and build on other essential aspects of web design?
Ideally learners would work in groups of 2 or 3, perhaps using the more experienced people in class as consultants on their projects. If there are a number of learners who, after completing their 
It’s been a crazy first week back in class, with over 20 of us starting out in the Web Design course! It’s got me thinking about better ways to facilitate our individual learning when there’s so many of us… and I’d love to have some feedback!
On our orientation day (last Monday), we ran a