# Two parts

You’ve chosen course outcomes. Provisionally, maybe, but you have something to work with. The next step is to model the course, creating a framework or skeleton showing the most important things. You’ll flesh it out later.

Let’s split course modeling into two parts:

- Knowledge modeling
- Experience modeling

Knowledge modelling describes what students should learn. However, we can’t give that knowledge to students directly, baked into a pie, for example. Hmm, pie!

Students learn from experiences, like reading, doing exercises, and taking exams.^{1} Once you know what knowledge students should learn, then you can design experiences that will help them learn that knowledge.

# Knowledge modeling

A knowledge model is a tree or network diagram with three types of components:

- Outcomes
- Patterns
- Big Ideas

Outcomes are tasks that students can do. You know about them already.

## Patterns

A pattern is a mental structure that people find useful. For the last 40 years or so, the research literature on expert performance has been dominated by the idea of patterns, also called schemas.

Here’s a pattern from an intro programming course:

```
Pattern 1
To work with a file:
Open the file
Do something with the data in the file
Close the file
Here's another:
```

```
Pattern 2
To process data in a file, line by line:
While there are more lines in the file
Read a line
Do something with it
```

Things to notice.

- The patterns are about tasks, like “To work with a file.”
- The patterns don’t give programming syntax details. To implement “Open the file” in pattern 1 in PHP, you would type something likee
`$f = fopen($filepath, 'r');`

. Students have to know that, or know where to look it up. - Patterns nest. Pattern 2 could be the “Do something with the data in the file” in pattern 1.
- Patterns aren’t cognitive icing. They’re how people understand tasks.

That last one needs some explanation. An example from your childhood:

A train leaves St. Louis at 9 a.m, traveling to Cincinnati at 50 mph, along a 1,000 mile track. Another train leaves Cincinnati at 11 a.m., traveling to St. Louis on the same track at 40 mph. When will the trains collide?

How do people work on the task? One student might think about trains. “The one from St. Louis is faster, so it might be newer. Or maybe The Cincinnati train has more freight, or a fraidy cat driver.” Not helpful.

Another student thinks, “When the trains collide, they will be at the same place. So an equation for place for the St. Louis train, will equal an equation for place for the Cincinnati train. That gives an equation with one variable. I know how to solve that.”

When the student saw the “equation with one variable” pattern, her understanding of the task shifted. For her, the task isn’t about trains, but about formulating an equation from the problem description (the hard part), and solving the equation (the easy part).

A course can be modeled as learning how to use a set of patterns. You can take a course outcome, and ask: “What patterns would a student need to know to do the task?” And then: “What would a student need to know to learn those patterns? What tasks would demonstrate mastery of those patterns?” And so on. Backwards, until you get to what students know at the start of the course.

## Big Ideas

If you take a programming class, the instructor might spank you (metaphorically) if you don’t follow some basic rules about code layout. This is spank-worthy code:

```
$x1=fopen('pet-industry-sales.txt','r');
$x2=0;
while(!feof($x1))
{$x3=fgets($f);$x2+=$x3;
print $x3.'<br>';}
fclose($x1);print '<p>Total: '.$x2.'</p>';
```

This code will avoid the Spank Plank:

```
$f = fopen( 'pet-industry-sales.txt', 'r' );
$total = 0;
while ( ! feof($f) ) {
$sales = fgets($f);
$total += $sales;
print $sales . '<br>';
}
fclose($f);
print '<p>Total: ' . $total . '</p>';
```

Both will run the same way, and give the same result. So why does the first one elicit cries of “A spanking! A spanking!”?

That’s what Big Ideas tell you. They are the principles that underlie patterns.

Take the example above. In programming, one Big Idea is:

People need to change programs, sometimes long after they were written. Make code easy to understand, so people can work quickly and accurately.

Big Ideas help students adjust patterns, and create new ones. Take that last Big Idea, about understanding code. A student might say,

“Hey, how about writing down what each variable means. The variable’s name, then a short description.”

Nice! The student came up with a new pattern, by applying a Big Idea. That’s understanding at work. Yeeha!

## A knowledge model

Knowledge models look something like this:^{2}

Outcome B is a final course outcome. Students need to know patterns B and C before they can achieve outcome B. Big Idea B is a principle behind patterns A, B, and C. Outcome A is an intermediate outcome, showing that a student knows how to use pattern A. Pattern A is involved with pattern B, perhaps nested within it.

# Experience modeling

Now you need to attach experiences to your knowledge model. Experiences are things like:

- Didactic explanations, perhaps as text with images
- Demonstrations, by pseudents or live
- Guest speakers to talk about, e.g., Big Ideas
- Exercises
- More exercises

^{1} The empirical evidence is strong: taking exams helps learning. It might be combination of priming, repeated activation, and deeper processing.

^{2} There’s a prototype of a Cyco visual course modeler. Pretty neat. Clicky clicky, draggy droppy. It needs to be rewritten before it’s ready for human consumption, though. No idea when that will happen.

# Summary

Time to model the course, creating a framework or skeleton showing the most important things. Knowledge modelling describes what students should learn. A knowledge model is a tree or network diagram with three types of components: outcomes, patterns, and Big Ideas.

Students learn from experiences, like reading, doing exercises, and taking exams. Once you know what knowledge students should learn, then you can design experiences that will help them learn that knowledge.

# Moving on

There are three parts to making a Cycourse:

- Specifying outcomes – what should students be able to do by the end of the course?
- Modelling the course – make a skeleton for the course, just the high points.
- Build out the course – flesh out the skeleton with text, exercises, patterns, etc.

We’ve talked briefly about the first two. Now let’s look at the last one. This involves the Cyco software to a greater extent.

## Add new comment