Of what we know we learn approximately
1% through Taste
2% through Touch
4% through Smell
10% through Hearing
83% through Sight
Of what we learn we retain approximately
10% of what we Read X1
20% of what we Hear
30% of what we See X1 (We "see" what we read!)
50% of what we Hear And See
70% of what we Say
90% of what we Say As We Do......"
".....15 sites on learning retention.
SOURCE http://www.nwlink.com/~donclark/hrd/hrdlink.html
Related links: "Average Learning Retention Rates" (Google_Search) 2005-07-21
Link
I've seen or heard something like this for a long time. One of my professors from WVU put this slide up and he lectured about it for a hour or so...
What does this mean for podcasting? We need to start thinking about how we can get them (the learner) involved in the creation process. I find this to be a bit of a challenge. In many office environments, the idea of jumping behind a microphone is not one that everyone jumps at. However, by doing interview-based podcasts, you can lower the resistance. I sat with out HR Director and we did an interview while surfing our corporate intranet. It was ultimately a screencast but I think she and I both learned the most from the experience.
Some other ideas may be to allow employees to narrate process that they are knowledgeable about (or even responsible for), offering tips and tricks concerning the process. Then, release the podcast through the corporate learning feed, and direct the questions (or an aggregate of the key questions to reduce workload), back to the employee for clarity or explaniation.
podcasts+learning retention
Interesting Post. Based on the statistics you've posted, developing a narrative podcast created by an employee about something they are knowledgeable about would seemingly benefit everyone. The learner retains 10% of what he/she hears, (and if a screen cast is made - 90% of what he/she sees), while the employee retains 90% of the information that he/she has conveyed through the podcast/screencast. Coming from a developer (the employee) standpoint, it would be easier if the project lead (or supervisor/boss) analyzed the work done, pulled out key elements sought to be crucial building blocks for others, and basically interviewed the employee about those topics, and how he/she developed them. This would open up the employee(s) who may feel reluctant to independently generate the podcast, giving he/she the opportunity to make key points (also tips and tricks) along the way. I'm not suggesting the project lead become familiar with the code or precise implementation, but more at an abstracted (or external) level, maybe by examining the features available in the current system or application - the user's perspective. Personally, I would definitely be interested in listening or viewing some sort of content solely based on how a process of my interest (or part of my job requirement) was completed; Only the key elements would be worth it. For example, as a programmer, syntax is not the key points, anyone can learn syntax with practice, but the overall structure as well as unique ideas/methods for building the block or function would have higher potential to gain beneficial information. Some drawbacks would be creating an environment where everyone gave positive input, and the point I made about the project lead analyzing the information requires a frequent analysis (maybe twice a month - depends on how often a new podcast is desired), and he/she may not be able to devote the time needed to properly analyze the work done to make the content in the podcast worthwhile. Good post...
ReplyDeleteRyan, How long do you think the podcast should be? Let's say it was on the development methodology of a new web-based application we had to develop. Would you rather a series of 10 minute podcasts or 1 two hour podcast that you could surf through on your own?
ReplyDeleteLee
Hmm...that's a good question. I guess it would depend on the purpose of the podcast, and how often they would be generated. Let's say we have a situation similar to the following: There are three programmers who are working in a .NET environment, but on separate files (or even projects). Every two weeks, a podcast is desired to share the core ideas behind the previous two weeks of work among all three employees. If the plan is to tell the other two programmers, I would think that the podcast could be relatively short (10-15 minutes), because (usually) all programmers think alike. There's no need to go into heavy detail about how the coding was done, but the purpose here would be to introduce a new coding method or thought process to invoke a new way of thinking for another programmer. It would keep everyone on the same page in terms of using his/her creativity towards development. I know there were plenty of instances when I would read (unfortunately not listen or see) about something that was done, and I didn't need to see the code. I needed to read the general plan of how something was setup, and in turn, that allowed me to put that same concept towards something else that I was working on personally. Unless the topic is something new to the other two employees (like AJAX), where it would be completely appropriate to explain the syntax to get them started, I would just keep it short and simple focusing on the main goals for that span of time. I think I would prefer a shorter podcast vs. a longer (hour or so) podcast, but that's just me. However, if it were something being shared among all other employees (not just programmers), then I think it would be necessary to have a longer podcast to explain the process in more detail.
ReplyDelete