|
|
| This paper came out of PLoP '95 and is posted here with the author's permission. -- Ian |
| Abstract | ||
| The "Patterns" section lists some patterns for teaching difficult technical topics (such as object-oriented programming), including patterns for examples, games, flow of the course, and dealing with different learning styles of students: each pattern has four portions. The first two, Problem and Constraints & Forces, lay out the context for the third portion, Solution. The fourth portion describes connections between Related Patterns. The "Pattern Language" section briefly describes how the patterns are used together in the course development process. |
|
In the Problem portion of each pattern you will find the problem or group of problems that the pattern solves. The Constraints and Forces portion describes any additional context necessary to determine when to apply the pattern, and often this includes a more detailed restatement of the problem. The Solution portion contains the pattern's solution. The portion called Related Patterns includes both other patterns in this paper, and ones that aren't written yet (or they are and I haven't read them).
The patterns that follow are arranged in order of most abstract to most concrete. Several of the patterns, especially the more abstract ones, are strategies which lead to solutions. Others, especially the more concrete ones, are ready to implement. Pattern #1 has the highest level of abstraction, #2-6 next highest, and #7-14 are at the most concrete level. Within that arrangement, closely related patterns are together. For instance, the three patterns relating to examples are #8-10. There's no need to read them in the order presented.
At the end of the paper, you'll find a section called "The Pattern Language", an attempt to tie together the patterns below into a system of course development. Also discussed in that section are additional forces that may affect the patterns as a group; for example, the three "learning styles" which form part of the context of many of the patterns here. The three are: learning by doing, learning by seeing, and learning by hearing.
Constraints and Forces: A single course developer is only one person, and no matter how experienced, may have trouble accounting for widely different learning styles. The developer's own learning style will naturally tend to attract the most attention. Even a team of course developers may still leave gaps. Some presentation concepts may seem like great ideas on paper, but aren't successful in practice. Others fail on the first try only due to some mistake or oversight in preparation.
For example, #5: "Pitfall Diagnosis and Prevention" requires you to figure out where students will have the most trouble. The easiest and most accurate way to do this is by teaching the course, and seeing where students have great difficulty.
If a course is presented by different people, each trying different techniques, it becomes difficult to tell which techniques work best. It may even be tricky to tell which techniques have been tried at all.
Solution: Develop courses iteratively. The developer or team can do their best isolated development effort, then take the course out and actually present it. As audiences change over the long run, the course will continue to grow and improve.
To document the iterative changes in the course, use patterns as much as possible. This will help those working on the next iteration know what to try next, and what has worked in the past.
This pattern is named after its problem, while most of these patterns are named after their solution.
Problem: Two concepts are each a prerequisite for the other. It's a "chicken and egg" situation: if the student doesn't understand A, he won't understand B; but if the student doesn't understand B, she won't understand A.
Constraints and Forces: You could just explain one, then the other; but at the halfway point, everyone would be confused. But many people, if confused, stop trying. This invalidates a "just go ahead" approach. You could just simplify each concept to the point of incorrectness, for the sake of explaining the other one. But many people object to being lied to, even for their own good. This invalidates the "Santa Claus and Easter Bunny" approach.
Solution: Give the students the illusion of understanding, by explaining each of A and B very superficially, but essentially correctly. Iterate through the pair over and over, each time going into more detail. Each time be sure to maintain the illusion of understanding.
Related Patterns: #3: "Mix New and Old": as you iterate through the pair of topics, mix new material about each with a review of the old material.
Vary the `learning style' of the material each time through.
Constraints and Forces: In addition, each student varies in their "learning style"; whether they learn better from doing something, seeing diagrams or demonstrations, or hearing explanations. [Gagne70][Goldstein74]
Solution: Iterate over a concept several times. Each time, present the material in a different variation on the learning styles. Each time, mix in some new material with the old. This both maintains students' interest through the review and helps them absorb the new material.
Related Patterns: #12: "Simulation Games" provide an alternative to exercises for the learning style that learns by doing. #7: "Visible Checklist" provides an extra stimulus for the group that learns by seeing. #11: "Colorful Analogy" provides a boost for the learn by hearing group.
When the same course is taught the same way, you may notice students making the same kind of mistakes every time. These pitfall concepts are covered in the course, emphasized the same amount as all the other concepts which are equally important and central. Yet, students understand the others but miss the pitfalls.
Constraints and Forces: Usually it's difficult or impossible to figure out what concepts will be the pitfalls without actually teaching the course. When you change the structure or style of the course, you may change the pattern of pitfalls. You have to see the trouble to figure out what will give trouble.
Solution: "An Ounce of Prevention": when something is a problem in one session of a course, when you teach it again, underline the concept as it first comes up. Make sure to highlight in the students' minds that this is a vital part of the subject matter, not to be forgotten.
As an example, I found that students who don't know much about sorting algorithms often found it hard to believe that you can specify a sorting order by providing a function that can sort only two values. This confusion led to the students being unwilling to use this kind of sort routine. I had just diagnosed a pitfall; now I had to prevent it.
To avoid having to either explain sorting algorithms, or leave students doubtful, I constructed a simulation game in which I provided several typical objects: a pair of scissors, an apple, a candle, etc. I give them a balance on which they can see which of any two items is the heavier, and ask them to arrange the items in order of weight, lightest to heaviest. After doing this, the pitfall never appeared.
Another pitfall I diagnosed in Smalltalk was that many students could not remember the message printString, always trying to use asString instead. This I prevented by writing "printString" on the whiteboard in fancy letters, and leaving it up. Every time a student got an error from sending asString, I just pointed at the board.
For a third example of pitfall prevention, see the solution section of pattern #11: "Colorful Analogy".
Related Patterns: #1: "Iterative Development" tells you to record your pitfalls so you can later apply this pattern. #7: "Visible Checklist", #11: "Colorful Analogy" and #12: "Simulation Games" all provide possible ways to highlight the concept and prevent the pitfall.
Constraints and Forces: You may have a module which really is a bunch of bits and pieces, or you may have things which seem disconnected when a student first learns them, or a sequence of things which are each prerequisite for the next, but otherwise unconnected.
One idea would be to break them into separate modules. But the resulting modules might be too short, or not have any use on their own, or otherwise be too small.
Solution: Come up with an example, exercise or goal which makes use of all the topics in the module. Make the flow of the module into a story. The preview becomes a foreshadowing of where the story will lead, and a motivation for its end goal; the review takes care of itself as you can just recite how the series of steps taken led to a solution to the story's conflict.
Often, keeping the story foremost in your mind will make the module flow like a story. You may not even have to explicitly tell the story to the students. If that is not enough, think of writing the module as creating a story, and delivering the module as telling that story. Or explain the exercise or goal as the preview of the module, letting the students tell the story to themselves as the module progresses. Then review how each topic covered in the module fits that introductory exercise or goal.
Related Patterns: #8: "Acquaintance Examples" will help you choose an example or exercise topic. #7: "Visible Checklist" can support the story flow of a module. A checklist can even, alone, provide the Module's Story for a module that has enough natural cohesion.
Constraints and Forces: You want people to be able to keep the entire set of topics for a module in mind, and to be able to relate them to each other. The module should be short enough to finish without a break and long enough to keep the course from seeming choppy.
A person's short term memory can hold about 7, give or take 2, things. This is often called the "Miller Limit", after psychologist George Miller. [Miller56]
Solution: If you can divide the module topic into about 7 steps or sub-topics, it will seem about right to most people.
Often the instructor or the students or both forget exactly how a piece of detail in the middle of a section relates to the overall purpose of the section, as defined in the preview or review. People have only so much memory, and when it's being taken up with details, they may forget the high level concepts.
Constraints and Forces: You want to make sure that students not only understand the general outline of a topic, but also how to take that general outline and use it in a specific instance. However, while showing a specific example of a general task, people can get too bogged down in the details. You want to keep relating the specific steps back to the general steps of which they're examples.
Solution: While going through the preview, place a visual aid in everyone's field of vision which acts as a checklist. The checklist must remain on display throughout the section, while you go through the main body of the section Each time you go on to the next step, refer back to the checklist. At the end, use the checklist for the review.
The checklist pattern can support all three learning styles, though it primarily aids the learn by seeing style:
Constraints and Forces: There is a range of example domains, from those totally unfamiliar to those in which the student has professional expertise.
If a student is completely unfamiliar with an example's basis, the instructor can spend more time explaining the example than using it. If the instructor is trying to demonstrate the creation of abstract classes, and uses as the example "Control Chart", which has as concrete subclasses "Non P Control Chart" and "X Bar Chart" among others, he doesn't want to spend more time explaining what X Bar means than what the difference between abstract and concrete is.
On the other hand, if the student is an expert in the example domain, the student can become bogged down in the example's domain details, and fail to see the point the example was intended to illustrate. If the instructor is trying to explain when to use a Phone Number object instead of an array of strings representing the area code, exchange, and station of a phone number, she doesn't want the telephony expert student arguing whether exchanges are a valid description of how phone numbers work these days.
Solution: Choose examples that are the most likely to be familiar to students, but not to be within the area of students' expertise. One way to do this is to choose businesses that students patronize but don't run, for instance a hotel or a video rental store. You may wish to have two alternatives ready so you can use the one which is more appropriate for each group of students. Choosing appropriate Acquaintance Examples can be a very difficult task.
If a class is homogeneous, with all students having expertise in the same domain, an Acquaintance Example can serve as an "icebreaker", to get students to see how to apply their new knowledge. Then the instructor can supplement the Acquaintance Example with an example closer to the students' domain, to demonstrate that their new knowledge applies to their domain of expertise as well.
Constraints and Forces: There are pros and cons for each alternative:
Solution: If an example is used, it may and should be continued throughout a week-long unit. This means a seminar needs new examples each meeting, while a training session should contain example(s) that continue to be elucidated throughout the session.
Related Patterns: #8: "Acquaintance Examples" for how to choose the domain of examples used in a class.
Constraints and Forces: Often, if the course developer doesn't provide any examples at all in the course materials, students insist the instructor provide them during delivery. This can be impossible in the tight time constraints postulated, and yet it points out that some students really require examples for any complex topic.
Solution: Provide references to examples that will be available to students after the course ends. For example: in a Smalltalk course, all students should have access to a base Smalltalk image. A reference example in such a course could be simply a reference to an example in the base image. For almost any topic, the instructor could provide a reference to a paper or journal article that includes detailed examples illustrating the topic.
Constraints and Forces: This is a concept whose name may be memorable but the explanation is not. People may tend to remember that there's something called that, but they forget what it means. Simply emphasizing this concept tends to just confuse people, or to be so boring that students will just tune out.
Solution: A dry concept can be highlighted with a colorful analogy that provides a place to go back to to recall the details.
The example I see most frequently using the colorful analogy is the explanation of the difference between identity and equality in objects. The analogy is a story of a restaurant patron who sees another diner eating a delicious-looking lasagna. He tells the waiter, "I want what she's having." Equality would mean the waiter goes into the kitchen and gets another plate of lasagna for him. Identity would mean that the waiter takes the lasagna the other customer is eating, and gives it to him. With the right analogy, a single word (in this case, "lasagna") can become a touchstone that recalls enough of the details of the explanation to make sense.
Explain tricky concepts: Many problems are hard to learn from the explanation. If you've ever tried to learn to play a complex game just from reading the rules, you know what I mean. It's much easier to just play the game, and watch what happens, than to try to figure out the written rules.
Provide interaction: Interactive games are a way to help get students involved in the material. They engage all the types of learners, but especially those who learn best by "doing". Having some interaction in the course will help increase the amount of interaction going on in exercises and lectures, too, by setting the tone.
Constraints and Forces: Some individuals may not get involved in the class, because they decide that they will do best by sitting still and listening even when they don't understand. They plan later to sit down alone and just try to do the things they learned. (Most of these students come from the group who learns mostly by doing.) Therefore these are the students who it's most vital to get to interact with the group. Otherwise they may get completely lost and never let on.
Interaction at the very beginning of a class lets the students loosen up and feel free to ask questions, answer them, and generally relax. But it also needs periodic "boosters" to keep up the interactive atmosphere.
Solution: Playing a simulation of a complex activity often provides a much better understanding of what is going on than a straight explanation would. Plus, this activity serves very well as an occasion for interaction.
Related patterns: #13: "Quiz Games" also provide interaction, when no suitable topic for simulation is on the agenda. There are also general purpose icebreaker games which are often suitable at the very beginning of a class. These are not covered in this paper, but there are books available that describe them [Green-Forbess83][Pike94].
Related Patterns: #4: "Pitfall Diagnosis and Prevention": quiz games can discover pitfalls. #7: "Visible Checklist" can provide material for quiz game questions.
Constraints and Forces: Students often have better retention and buy-in if they discover something themselves; but not all students may discover the same things. How can they share their discoveries with one another to leverage this "aha!" factor?
Solution: After an activity, exercise, or simulation game which is designed to stimulate students to discover something, lead a discussion of what the students learned. Ask open-ended questions (ones without a yes or no answer) to draw out the comments and insights of each student. Students will value each others' discoveries almost as much as their own, and more than things simply told to them by the instructor.
Related Patterns: A debrief is often useful after a simulation game (#12: "Simulation Games").
Developing a course, like developing a program, involves requirements gathering, analysis, design, and implementation. The above is the requirements and the beginnings of the analysis.
During the design of the course, the course developer lays out the sequence in which the material will be presented, and decides the means of presentation. Usually the material will not organize itself neatly--often it takes a great deal of effort (and a number of iterations: pattern #1: "Iterative Course Development") to invent an effective organization for the presentation. Three natural groupings of topics often occur in a given body of material:
A dependent group is a group of topics which belong together and must be explained together. Each is necessary to facilitate understanding of the rest. This formation causes one kind of problem: that in order to explain each of them, you must already have explained the others. Getting these into a module is self evident: they belong together. Organizing their order within the module is more problematic. (See pattern #2: "Chicken & Egg".)
A series is a group of topics that follow logically, one after another, each building on the previous one. The problem here is that the most natural way to proceed is to address each of these topics in sequence. One benefit: this approach is very motivational, as each new topic provides a use and purpose for the preceding topic. However, there is a great risk to this approach. If a student fails to understand a topic, that student will (in domino-chain fashion) then fail to understand all the subsequent topics in the group. (For some ways to help prevent this, see patterns #3: "Mix New and Old" and #4: "Pitfall Diagnosis and Prevention"). Students who are understanding each section can also lose sight of the overall picture, how each topic leads to the next. (See pattern #7: "Visible Checklist")
An independent group is a group of topics which are independent of one another; each could be presented without reference to the others. They form a group because of some external reason, which might include:
The problem the course developer faces with this third kind of grouping is to create unity for the group. A student's interest must transfer to the next topic as the course moves along, not remain behind with the previous topic. (One approach for this is pattern #5: "Module's Story".) In addition, sometimes this lack of cohesion means that this "group" should be subdivided into smaller groups. (To determine when to break it down further, see pattern #6: "Seven Parts".)
Course design also involves creating examples that demonstrate the course's concepts. (See pattern #8: "Acquaintance Examples", #9: "Example Lasts One Week" and pattern #10:"Reference Examples" .)
Once the course is designed, and the developer has determined the sequence of topics and their division into modules, the next step is to create presentation materials that will support the actual delivery of the course. The presentation materials should target all three kinds of sensory learning styles, which are: learning by seeing, learning by hearing, and learning by doing. I'm not sure if "Three Learning Styles" is a pattern, or just a major part of the context of the patterns in this paper. The patterns refer to these three learning styles often.
Delivery must contain preview material, so that students know what to expect, have an overall outline of what they will learn, and know the sequence so they don't need to ask questions if the answers will be delivered in a later section. Delivery must contain explanations that students understand, so they learn the new material. And delivery must contain review, because the instructor must verify that prerequisites have been learned, and because most people can't handle all-new material all the time and have any hope of being able to remember and apply it later. Most people will remember up to 10 minutes' worth of new material each hour.
There's a commonly known pattern that I call "Preview & Review", because of this necessity to preview and review at all levels of presentation. It's also referred to colloquially as "Tell them what you're going to tell them, then tell them, then tell them what you've told them." The patterns in this paper refer to previews and reviews often.
Presentation materials can include checklists (pattern #7: "Visible Checklist") and games (pattern #12: "Simulation Games" and #13: "Quiz Games"). Modules can be organized around the topic groups that naturally occur, around exercises, and/or around the checklists and games. Each module should contain some new material and some review material.
When the course is first presented, usually the instructor will discover weak areas, where the course needs more material, more review, and/or more emphasis. (See pattern #4: "Pitfall Diagnosis and Prevention".) Extra emphasis include any or all of the following techniques: a highlight or larger text in the presentation materials; a special exercise or review exercise on the topic; special emphasis in a quiz game (pattern #13:"Quiz Games"); or a colorful analogy (pattern #11: "Colorful Analogy").
[Howe77]Howe, M. J. A. (ed.), Adult-Learning-Psychological Research and Applications. Wiley, 1977.
[Gagne70]Gagne, R.M., The Conditions of Learning, 2nd ed. Holt, Rinehart & Winston, 1970.
[Goldstein74]Goldstein, I.L., Training: Program Development and Evaluation. Brooks/Cole, 1974.
[Greene-Forbess83]Greene-Forbess, Sue, The Encyclopedia of Icebreakers: Structured Activities that Warm-up, Motivate, Challenge, Acquaint, and Energize. University Associates, CA., 1983.
[Miller56]Miller, George A., "The Magical Number Seven, Plus or Minus Two: Some limits on our Capacity for Processing Information." Psychological Review, 63 (1956):81-97
[Pike94]Pike, Bob, Dynamic Openers & Energizers. Lakewood Publications, 1994.