Hapgood

Keynote given at NWeLearn, 10/23/14. Originally titled “Taking Education Out of Airplane Mode”

Speaker’s note: I write unique pieces for presentations I give. I’ve not yet learned to economize and give set presentations to multiple audiences. And I approach presentation as articles, revising them mercilessly over months and months. So word of warning, the early drafts of this were titled “Taking Education out of Airplane Mode”. Somewhere about a month ago, a better title would have been “Design Patterns and the Coming Revolution in Course Design”. And then yesterday I was looking at this and thinking the real title should be “How to Fight Big Design Without Becoming a Design Anarchist.”

It’s all the same idea. As Tom Stoppard would say, it’s “two sides of the same coin, or the same side of two coins”. It’s all intertwingled. But I thought you should know.

This presentation is also fresh. I’ve danced around these questions on my blog the past few months while I wrote this, but kept this larger work under wraps. So this is my first comprehensive presentation of this idea anywhere, and I’m really interested in what you think.

Introduction: Songwriting

One thing not mentioned in my bio is that I’m a songwriter. Here’s a slide pertaining to  the third most bizarre incident of my life, when a song I had released under the name The Russian Apartments shot to 26 on the Latvian Airplay charts.

You’ll see that I beat out Jennifer Lopez, the Foo Fighters, and Depeche Mode, but couldn’t quite take down Katy Perry.

Though what you’re probably looking at here is number 36. Chris Brown is still putting out music? Who knew. The magic of Latvian radio. Anything can happen.

I mention my songwriting not because I think there may be some Latvians in the crowd I will impress, but because songwriting for me is a way to think about creation, and what we are in this room are creators.

Songwriting is like most other creation. You start with inspiration: a snatch of melody or a killer progression, but that’s when the real work begins. You start to add pieces — a bridge, a pre-chorus, a keyboard hook, a bass line. When you work solo on multi-track, as I do, and you are scoring 5 to 20 instruments you become acutely aware that each decision you make constrains you further. As you progress, there really are limited ways these things can fit together.

This should feel increasingly claustrophobic, but it feels quite the opposite, at least for a bit. There is a feeling in the middle of songwriting of acceleration, a feeling that you are not so much creating something as you are chipping away the stone to reveal a song that is already there.

This “emergent” coherence to this process feels like the peak of being human, and it’s not for nothing that when it works — when a song we listen to fits together like something living — we feel human ourselves. It doesn’t matter that “Waterloo Sunset” by the Kinks is a fairly lightweight pop or that “Debaser” by the Pixies is sophomore surrealism — the songs progress in a way that almost seems inevitable. They move from being a sequence of vowels and rhythms to words and melodies and beats.

Now a lot of people think this coherence is an abstract alignment of part to whole. But it’s much more than that.

It’s the feeling that the parts of a song are *re-acting* to *one another*. When we talk about what has the “spark” and what doesn’t, that’s the secret. And it’s built into the design process.

The same is true of great courses – the elements of a great course exist in a creative tension, and drive us forward into unexpected but seemingly inevitable directions.

Yet when I look at how we create courses and how we make songs, I’m struck by the difference. Each process is equally analytical. But the songwriting process generates serendipity, creative tension, and spark. And the course design process – the official course design process — all too often works against those things.

Take away that course design process though, and chaos reigns. It really does. Years as an instructional designer have taught me that some people can create a complex tech-mediated course from their gut, but most can’t. The scattershot nature of much of our “un-designed” offerings is a result of the assumption that most teachers can be the John Lennon of course design.

They can’t.

So I became obsessed with this question of whether there is a third way. Can we get coherence and creativity? Data-driven design and spark? And I started looking at other models in other disciplines. It got really interesting, and that’s what I want to talk about today.

The Coherence of the New England Downtown

This is the town where I spent the last 10 years of my life, before I came out to the Pacific Northwest.

I don’t know the sequence it was put together, but I do know these buildings have different dates on them.

You’ll have to forgive the wideness of Main St., a historical mistake they’ve done their best to work around. The rest of the street grew up around something that began as a square but ended a thoroughfare. The church was one of the first things in, early 1700s or so, and things sort of arranged themselves around that.

And weirdly, although these buildings span from the early 1700s to the mid-20th century (and although Main St. is far too wide) the effect of the downtown is one of coherence. And Keene had its issues, but I miss that downtown badly.

Here’s where I live now. Well, OK, not this. I live in a smaller twelve unit project, but along the same lines. It’s part of a development, and around it there are shopping centers. When we think about sprawl, we tend to think that it was due to a lack of design, but often the opposite is true. The development in this picture was fully planned out before a single building went up. Every last detail was controlled.

So here’s a question: how is it that the experience that was designed by hundreds of different people over hundreds of years feels more coherent and alive than this development which was designed by a single person?

The key, I’ve found, is emergent structure.

The Keene downtown was never built to be finished. If you walk down towards the end of Main Street, you can see the loose ends of the street. If Keene is smart, when new buildings go up at those loose ends they will emerge out of the constraints of the surrounding architecture and environment.

Like a song, the new pieces react to and mesh with the pieces in place. Unlike a song, they leave loose ends for the next expansion to pick up.

The development I live in is different. It was designed to be finished on delivery. Self-contained, with all threads wrapped up. Things are connected, but they don’t *react* to one another. And so, architecturally at least, we get this sort of still-born community. A structure that turns in on itself. Inside are wonderful people making the best of the situation, but they are doing that in an architecture that works against conviviality.

Does that in-turning structure sound familiar to those who have been watching the direction of online course design?

If not, you’re lucky.  If so, you’re a bit ahead of me here, though trust me, we will get there soon.

Alexander and Beyond

Observations about emergent structure aren’t unique to me. They were made in much better prose with much better precision by architect Christopher Alexander a half a century ago. And by others too: Jane Jacobs, for instance. By a lot of people. But Alexander, in particular, invented a whole new way of design, built around this concept. In Alexander’s methodology, referred to as “a pattern language”, designs are generated the way one might generate a sentence — with local context and needs pinging around the rules of grammar and producing infinite sets of expressive meaningful sentences. And this forms what Alexander called living structure.

Here’s how Alexander’s system worked. You’d have a pattern and it’d look like this — “Light from Two Sides”.

It’d be based on empirical study of how people react to different rooms. Alexander says that given two rooms, people will congregate in the room that has windows on two walls.

He’d have his students go out and measure this stuff. The patterns were data-driven. And for him, this is sort of a cognitive constant that the builder has to design around.

And that’s important too — it’s not an aesthetic to Alexander. Many aesthetics could emerge from this. It’s a cognitive and physical constraint, like people being most comfortable when the temperature is between 60 and 80, or people finding white noise more peaceful than sporadic explosions.

Have you ever wondered why people are so excited about the corner office? Well, here you go: Light on Two Sides.

But what makes this observation special is the way it feeds forward into other design details.

How do you create these multi-windowed rooms? You’ll find a reference here to higher level design concepts like the Long Thin House. And you’ll find reference to lower level concepts like Deep Reveal, and Windows Looking out on Life. One pattern leads you to another. Want Light from Two Sides? You can do Pattern Long Thin House to maximize the number of rooms with that light pattern. You can use courtyards, Cascade of Roofs, staggered outside boundaries.

This is not how we approach design right now. We approach design much more like the architect of my housing development in Washington. “OK, we’re going to need roads, and houses, so here are the plots, and here’s where the houses will go…”

We have a top-down design process that creates sterile communities, communities are the result of top-down constraint.

Patterns as they were developed by Alexander were supposed to help mitigate this. They’d make visible the values and knowledge of a community of users. They’d form a sort of contract as well.

A good example of this is the University of Oregon, which has 70 or so patterns in its campus plan which they have had since 1970.  The idea of the pattern approach was to move out of the self-reflexive, feature complete design, but provide a template that made the campus cohesive. Here are the principles that Alexander defined for that project:

• Organic Order: the design emerges through a process, not from an initial blueprint.
• Incremental Growth: development occurs by small increments.
• Patterns: a pattern language guides the planning process.
• Diagnosis: development is guided by an analysis of the problems with the current design.
• Participation: user involvement must prevail throughout the planning process
• Coordination: working together benefits the product as a whole entity.

You’ll notice that the patterns are just a piece of this. But it’s the mechanism which holds the rest together.

Design patterns are the mechanism by which the communal, long-term vision meshes with the participatory incrementalism of the short-term process.

So here’s a pattern from OU called arcades. Keeping people outside is important to your community values and purpose, but local weather sometimes precludes that. Those two things — the constraint and the community value — ping off one another and suggest arcades as a pattern.

But what about research and accountability? The research is built into the pattern. You see that line up there about the data in Pattern Language? Halfway down the page? We call this thing a name and then we can collect data about it. We only adopt it as a community if it works in a broad variety of contexts, it supports community values, and the data tells us it works.

Once we’ve established the pattern as a community sanctioned one, the community of users can go to the architects and say we want an arcade on this. And if the architects say no, there better be a darn good reason.

You’ve given design to the people by giving them design patterns with the RESEARCH BAKED IN.

Here’s a different kind of pattern called Department Hearth. And there’s a community value here that we want to facilitate discussion among people working together. And that’s run through an empirical finding that space matters — people talk to each other more when we engineer chance meeting. So buildings have to accommodate that.

Do all buildings have a common hearth and an arcade? No, not exactly. But the process of design requires that the architects explicitly consider each pattern, and if they reject it they must provide a justification why. Power to the People.

And the things the users end up specifying from the patterns — they make it easier for the architect to build the building.

It’s like a template, but it’s also the opposite of a template. The template constrains, but not in a generative way. The template doesn’t set your creativity buzzing.

This? This does.

Could this work with learning design?

I think it could.

Arcades and Department Hearths provide a way for a community to develop buildings in a decentralized way while creating the sense of a coherent whole. And maybe this approach could provide us a way to work with faculty in the driver’s seat, and to rid ourselves of so much of the dead design that plagues our higher education.

Maybe it could give faculty the tools to create their own vibrant spaces while engaging in good design and producing a coherent experience.

Programming’s Sea Change

Where the story of design patterns is going to lead you next is software, because it is in software that it has had the most influence.

In the mid-80s Ward Cunningham, Kent Beck and others were frustrated by software design. This was an age of scientific design and management. You’d determine your goal. You’d write up the product design. You’d produce your timeline/waterfall chart, sketch out your module dependencies then write a bunch of modules from scratch. In a short twelve months you’d have your prototype, show it to the customer, find out they hated it and then you’d go back to the drawing board.

Cunningham and others were fascinated by design patterns, and a lot of the work they did was developing libraries of design patterns for code.

They captured community solutions to software problems the way Oregon captured community solutions to architectural problems. And they were somewhat successful with that and somewhat unsuccessful. I think you can say that the idea of software patterns had some influence on every piece of software in your pocket right now, but only a fraction of them were built using something like a patterns repository.

But the thing that they were proposing when then pushed design patterns — well, that’s a different story.

Because the other piece of what they proposed was something called “agile programming”. And what the advocates of agile programming (or eXtreme Programming) said was radical at the time. They said, roughly, that the design emerges from the construction of programs, rather than the construction from the design. You build something to find out what it is you really want to build. And you do it not so much based on a step by step plan as through rearranging ideas that have worked before and seeing what happens.

In other words, even though programming involved an awful lot of people working together, it could and should be less like that waterfall chart, and more like writing music, or composing an essay, or fishing, or cooking by taste.

It’s difficult to grasp how crazy this sounded to people in corporate software in the 80s and the 90s. Sure, a process like that could produce a small piece of software. Individual programmers had kinda sorta been doing this with smaller project from time immemorial.

But to bring such a thing into the enterprise? And to hold the work together with patterns and pair-programming and other organic methods? It was nuts. It was sloppy. It was a method fit only for individual hackers, and spaghetti coders — not for highly paid teams at IBM.

Top-down design tells us that the abstract concepts give rise to the instantiation of those concepts. There’s a hierarchy. Theory begets practice. Specification begets code.

Agile programming said your specification *was* the code. It said your common architectural designs — if considered at the right level of abstraction and empirically verified — could guide you through construction better than theory, needs analysis, or top-down design.

That sounds abstract, but this part is not. People don’t write 18 month prototypes anymore. There may be some companies that do waterfall charts of programming projects, but you be hard pressed to find the most talented programmers there.

In fact, the way software is designed today looks a lot like the way Oregon designed their campus:

• Organic Order: the design emerges through a process, not from an initial blueprint.
• Incremental Growth: development occurs by small increments.
• Patterns: a pattern language guides the planning process.
• Diagnosis: development is guided by an analysis of the problems with the current design.
• Participation: user involvement must prevail throughout the planning process
• Coordination: working together benefits the product as a whole entity.

And this is my thesis — as Instructional Designers we’re sort of in what the dark days of the 80s were to programming.

In many places we’ve become implementers of the spec.

We are, in many places, pushing faculty into ADDIE inspired processes — processes that were created to build instruction for military personnel going into very defined jobs. We’re using those same processes to teach students who are going to switch jobs a dozen times in their careers.

Here’s a final thing about Ward and others in that agile software movement.

They had this crazy “agile” idea, but to their minds they were less scientists inventing the idea than anthropologists discovering the system under the system. Big Design was in full force, but if you pulled back the curtain, you’d find that what good programmers were doing, in actual practice, was more organic than that. They had hints of agile programming in their process — they were just in a system that made them feel guilty for that.

I don’t know if this resonates with anyone out there. But it resonates with me. I don’t want to work in a system that makes me pretend things I know about process are not true. I don’t think you do either.

Learning Design

I’d started this presentation saying that we were designing courses wrongly, and were being hindered by that. I’m hoping by now you can see there are approaches to design that we have not truly considered as a field.

But how do they relate to learning design?

Here’s my take. What we currently have in our institutions in the face-to-face space is a sort of design anarchy. Every professor chooses his or her own approach. And while that allows the occasional Jim Groom or Michael Wesch to flourish, for the most part it produces something architecturally similar to this:

Many face-to-face classes are good, but so many are not. There are an awful lot of classes which have no empirical basis for the way they are designed whatsoever. And even where they are good, the experience can be so disconnected that the most flexible of students feels a bit overwhelmed.

At the same time, the online world is moving in. This is a world where many design methodologies came out of the military, a world comfortable talking about courses as reproducible experiences, suitable for mass manufacture at a zero marginal cost. And they are bringing in something that looks like this:

And I think a lot of administrators are frankly relieved about this, because as more and more education moves online, the idea is that we can bulldoze our strip-mall exburban eyesore and replace it with something centrally managed and controlled.  And courses will be delivered as these closed, feature complete products, designed by the experts — us, the instructional designers.

Yay, us.

And the feeling I get is in this massive battle that’s about to happen you are expected to be either for design anarchy or for Big Design’s waterfall process.

When I try in my job to move away from Big Design, I feel I always have to fight the impression that I’m being unserious, or unstructured.

I want to say to people, look, try running a blog as your class site, putting all your communications and materials into a single place. One which also aggregates student work. Seriously. It will change the nature of your class.

Well, hold on a second. What learning objective does that serve? What letter of ADDIE is that? People can get a bit freaked.

And when I talk to people on the design anarchy side, it’s worse — I’m making this too complex, they say. Let everyone do what they want, and it all works out.

Well, has it? Do most of our students feel like they had a coherent, interconnected school experience? Do most of our classes engage in empirically supported methods?

In a way, of course, the design anarchists are the ones who should listen up the most.

Because if you’ve watched the K-8 space, you know who wins the anarchy vs. Big Design battle. It’s Big Design and it’s not even close.

We are moving to a future where every minute of every day of a grade school teacher is precisely scripted by a textbook company in collaboration with a district. I have zero doubt that unless something changes this will be the fate of much of higher education as well.

If you’re an instructional designer, then maybe you get to write that script. Again, yay you.

Instructional Design Patterns

But what if we could do better than that? What if we could transcend the ADDIE mindset that has plagued us all these years?

What if we could push good design not by learning designers scripting classes, but by us creating the learning design patterns and the enabling architecture for faculty to implement them?

What if instead of saying hey, you need a course blog, and we can do that because of ACADEMIC FREE-ANCE!!!111! — what if we agreed as institutions that courses need a “Learning Hearth”?

LEARNING HEARTH (1):

Begin with a preposition:

When

When what?

When each student’s digital learning space is separate from other students learning spaces, and there is no peripheral awareness of what other students are doing, a student’s experience becomes disconnected, losing the SYMPATHY OF NUMBERS (34) provided in a physical space. Under these conditions there is little chance for a community to develop; students become disengaged, unmotivated, and less likely to learn.

Therefore, what?

THEREFORE, in every digital space create a LEARNING HEARTH, a space in which students are forced to bump into each other’s work. This space should combine announcements, course materials, and important links with feeds of student created content, linked and excerpted to entice the student to engage with them. Links should be composed of RIVERS OF WORK (48) and class information should be NEXT TASKS FOREGROUNDED (12).

This leads us to RIVERS OF WORK, and NEXT TASK FOREGROUNDED.

Here’s RIVERS OF WORK.

RIVERS OF WORK (48):

Begin with a preposition:

When

When what?

When students do tasks in isolation, they can often misunderstand tasks, or apply less effort than when they complete these tasks in the presence of others. Additionally, when courses consist of online assignments, students can feel disconnected from other students in the class. Theories of social facilitation also suggest that a public-ness to work can increase motivation and engagement.

Therefore, what?

THEREFORE, create RIVERS OF WORK which show students the latest work submitted by their peers, and encourage them to react to that work either by comment, their own work, or a remix of the presented work. Attention should be given to river size as small rivers do not generate forward class momentum, and large rivers can be overwhelming (see data).

RIVERS OF WORK are a crucial part of the higher-level pattern LEARNING HEARTHS, and maybe curated into ASSIGNMENT EXEMPLARS.

An important thing to see here is that looking at RIVERS OF WORK will lead you to the LEARNING HEARTH pattern, and the LEARNING HEARTH pattern leads you down to RIVERS OF WORK.  And RIVERS OF WORK suggests ASSIGNMENT EXEMPLARS.

And thinking about RIVERS OF WORK makes you think of what those rivers would consist of. Reading response? Article summaries? Updates to a crowd-sourced project?

You do this already, I’m sure. “What would this class look as a wiki? A blog?”

But again, we’re not supposed to think like this. We’re supposed to define the Student Learning Outcome and choose the best possible assignment for that SLO.

We’re supposed to take the plot of land, draw the roads, divide it into plots, and determine the shape of the house by the plot, and the layout of the rooms by the shape of the house.

Eventually, at some level, where you put your dining room table is determined by the needs of the road system. And that’s bad, because the roads have to be aware of the needs of your dining room table as well.

Top-down gives you consistency, but it doesn’t give you anything living structure. The magic actually comes about when you think — what does a RIVER OF WORK look like in Psychology 101?

It’s in the collision of the design pattern with the local need. We’re allowed to think through the pattern.

What this generates with WordPress in a Philosophy class for a general education class will of course be different than what it might generate with Canvas in a Physics class. But there will be a coherence all the same to the student experience. And while we are not enforcing checklists of standards on faculty, we are, in fact getting the sort of consistency and quality that matters.

It gets better. The work and testing you do with LEARNING HEARTHS at your institution — and the things you learn — transfer easily to work at my institution, because we have a common language.

And if we’re not afraid of the “f” word — feelings — we could start to look at what a learning hearth should FEEL like.  Alexander says, quite rightly, that during design holding on to what something should feel like is the best way of keeping on course, because you know when you’ve taken a wrong turn right away.  Select three examples of Learning Hearths for the faculty member to look at. Have them pay attention to how it feels.

Sound like hippie nonsense? Read Kahneman, read cognitive science on thin-slicing.

Again, I think this stuff is, in fact, what many of us are already doing, but just not in a formalized or institutionally approved way. And not in a way for which we have a language. And not in a way that our claims can be empirically tested, or formally analyzed to guide improvement.

And I want to say quite clearly that idea of learning design patterns is not new. As I’ve gotten into this I’ve found that people have been kicking this idea around since at least the mid-90s, and that in the past few years various efforts have made some significant progress. Here’s a book I just recently came upon from 2010, for example:

And I would bet you that after this keynote four or five of you will come up to me and tell me your own learning design pattern project. That’s exactly what I want out of this talk.

As for the rest of you, some of this, no doubt, will seem confusing to you.  It probably is confused, a bit.

But I return to the software example.

Years ago you had the maverick hackers and the institutional plodders. If you worked in a group you were probably following the approved process feeling miserable, or not following it and making other people’s lives miserable. And life sucked for programmers until the industry realized that you could have fluidity and structure at the same time if you made that a priority. And what I feel now, instinctively, is that we are in those dark ages.

Conclusion

I started out writing this cheerily, working on it in my free time, seeing where it led. And somewhere in the middle — not of this piece, mind you, but of the writing process — it got very dark.

We are in dark days. Everywhere I look I see the exuberance of the mid-aughts being crushed by processes and requirements and specs that don’t fit. And where I see signs of hope, it’s all cowboys and mavericks, stuff that will never mesh with our institutions, that sets itself up as in conflict with the very institutions in which it is trying to root.

I’ve got nothing against cowboys. As the great philosopher William Nelson said, all my heroes are cowboys. You look at the stuff I’m doing on my own campus, and it’s being run off of off-campus servers. You look at where I’ve been successful and it’s grass-roots under-the-radar stuff.

The dark piece of that is that it can’t take root in the organization in a way that transcends the individuals involved.

Here’s a story for you. I came to Washington State University, gung ho about my new job, and wondered why we were behind on the use of things like blogs and wikis. I started building stuff, because there was nothing there.

It wasn’t until I was a year into it that someone said to me — this is great! It reminds us of the old MediaWiki we used to have.

Turns out WSU was a *leader* in this stuff. Papers, keynotes, conferences. Early — and impressive — use of a university wiki. The use of worldware for ePortfolios. Student blogging and course blogs in 2006 or so.

Leadership changed. People were moved, rearranged, let go. Servers were shut down, and student work deleted. And this experimentation was obliterated so fully that I only came on it by accident.

This is not a unique story. I have a friend who presented to the board of a prestigious college about Networked Learning. And after talking about blogs, wikis, and the like he was told that they’d had all of that – in 2008. It’s gone now.

If I opened up the floor right here, I’m sure many of you could tell similar stories.

It’s easy to shake our fists at some imaginary villain here. But if we want better learning design, we can’t get that, strangely enough, by simply producing better learning design. Or we can’t get it permanently at any rate.

Instead, we have to look at the process by which we produce classes, and come to new community and professional understandings of what that process should look like.

We have to articulate that process publicly, so that the people following new processes are not mistaken for cowboys or illiterates.

And we have to make that new process comprehensible to faculty, and give them the tools to participate more fully while still preserving the integrity of the process.

We have to root deeply into the Way Things Happen. Or even more than that – we have to change the soil so these ideas can take root.

I said it got dark in the middle of writing this. It did. It kept getting darker, until I was talking to someone involved in the Agile Software movement. And what they said is, look, we launched this thing in the 80s, we didn’t get everything we wanted, but programming is a much better job today than it was even ten years ago. The way companies have programmers program now — almost everywhere — is much more in line with how we naturally think about these things.

In programming, they found ways for people to bring that organic experience of programming alone into programming with people. In programming, they found a place in between 1970s exburb strip mall loops and the sterility of the 1980s mall.

And that’s promising. It excites me. Because I can imagine us looking at the way we work now in 10 years and thinking, my God, how did we put up with that?

Maybe the learning design approach I’ve specified here is not where we’ll go. But if we can open up a honest conversation about process, perhaps these experiments can take root, and this Groundhog Day could end.

Perhaps. And perhaps, for me, is a word of hope.

———

Image credits:

Latvian Airplay
http://www.lanet.lv/news/airplay/2011/110529lv.html

Keene Downtown Shots
http://www.monadnockregion.net/

Tract Housing:
http://en.wikipedia.org/wiki/Tract_housing

Outer Strip w/ Car Dealerships:
http://www.torontotransforms.com/

Waterfall model:
http://proceedings.esri.com/library/userconf/proc97/proc97/to300/pap272/p272.htm

OU Pattern Language (arcades, department hearths):
from The Oregon Experiment. http://bit.ly/1pxB7Gr

Pattern Language (Light from two sides):
http://patternlanguage.com/

ADDIE
http://extension.oregonstate.edu/

Planet of the Apes, Lady Liberty
http://bit.ly/1yVtcLJ