Learning by Wholes

David Perkins is a senior professor of education at Harvard who has done a lot of super-applicable, general-audience writing. I just finished his book Make Learning Whole, and am eager to try applying each of the seven principles he outlines within. Here are some ideas of how I think each could apply to my own work, along with an explanation of the principles themselves.

Play the Whole Game

"We can ask ourselves when we begin to learn anything, do we engage some accessible version of the whole game early and often? When we do, we get what might be called a 'threshold experience,' a learning experience that gets us past the initial disorientation and into the game. From there it's easier to move forward in a meaningful motivated way."

By game, Perkins means a domain, a field, an area of learning. The point is to not to just talk about the game, not to pick away at learning just elements that are part of the game, but to actually do it and participate in it. Sure, you might have to play a junior version, probably with lots of scaffolding to support you at first, but that's still far superior to being promised you'll (maybe kinda sorta) get to the real thing later.

As a computing educator, it is tempting to say that playing the whole game comes for free since you start writing code pretty much right away. But the whole game isn't always present, at least not until later. There are oh-so-many examples of introductory programming learning experiences that go through a laundry list of concepts, using toy examples for each one before eventually getting to look at any sort of interesting, realistic problem. I avoided this with my CS1 design. It is structured around a series of demo programs in Processing. Each module is devoted to modelling how to create one demo, introducing computing concepts as they are needed. I want to make sure I continue to keep the whole game in mind for all my learning experiences. If my learners aren't doing something resembling the real thing, I need to fix that.

Make the Game Worth Playing

Motivation is always a tricky thing, especially in contexts where the reason for learning something is because a teacher said you have to. So how do we make the game worth playing? By playing the whole game, for a start. Look for intrinsic motivators. Connect to practical applications, personal insights, to other areas of the curriculum. Focus instruction on generative topics ("topics that figure centrally in the discipline or practice under study, resonate with the learner's interests and concerns, and, importantly, resonate with the teacher's also"). Teach in a way that highlights "understandings of wide scope, with enlightenment, empowerment, and responsibility in the foreground." Build a tone of enticement into the beginning of lessons. Teach for understanding. Foster a growth mindset. Provide a pleasantly frustrating challenge, seeking flow.

I've done a lot of thinking on game-like learning, and have led and contributed to development of a few game-like and even game-based learning experiences. I think that a lot of the ideas behind making the game worth playing connect well with game-like learning. I recently delivered a course to employees at work and struggled a bit with engagement. In my next experiment, I'm thinking of using game elements to increase engagement and retention.

Work on the Hard Parts

"The hard parts have an annoying characteristic: They do not always get better just through playing the whole game. Real improvement depends on deconstructing the game, singling out the hard parts for special attention, practicing them on the side, developing strategies to deal with them better, and reintegrating them soon into the whole game." Actionable assessment and communicative feedback are important aspects. To anticipate the hard parts, watch out for certain kinds of knowledge: ritual, inert, foreign, tacit, skilled, and conceptually difficult.

I've fully adopted backward course design, and have gotten pretty good at writing learning outcomes. In my next designs, I'd like to identify the 'hard parts' among the learning outcomes, and double check that I am isolating, practising, and reintegrating them. I think I am doing this in my aforementioned CS1, where I get learners to practice the newly introduced computing concept before reintegrating it back into the development of the module's demo.

Play Out of Town

We want our learners to be able to transfer their learning: "People learn something in one context, and this informs how well they learn and perform in another context. ... In other words, transfer is a matter of 'playing out of town,' applying the games we learn to bits and pieces of those games not just in their original contexts but elsewhere, in some other setting where they might be helpful." Think about "what is supposed to transfer, to where is it supposed to transfer, and how is the transfer accomplished." Fostering transfer means including "some of the connection making that we hope learners will do later on."

One of the big goals I had when starting our curriculum-aligned work-integrated learning program a few years ago was to help our students see computer science more holistically while making deliberate, explicit connections between academic theory and the industry work they do. Although I don't work on that program directly anymore, I'm always brainstorming ways to do this and making suggestions to the team. My hope is that the result will be better transfer of academic knowledge to the workplace. I'm also hoping to look for more ways to incorporate reflective abstraction and diverse applications into individual learning experiences.

Uncover the Hidden Game

"Any complicated and challenging activity always has multiple layers beneath the obvious. ... The hidden games are not only interesting but often important to doing well at the surface game. ... A great deal of learning proceeds as if there were no hidden games. But there always are. They need attention or the learners will always just be skating on the surface." A few example types of hidden games include the hidden games of strategy, causal thinking, inquiry, and power. Games hide under the rug of simplicity, within the margins of good enough, inside the cloak of the tacit, and beyond the horizon of readiness.

The next time I create a learning experience for developers who want to learn a different language or tech framework, I want to use my subject-matter experts to help me uncover the hidden game of what they do. I think a short lesson on the ideas from the book might help them know what I'm going after, and I can use my own expertise as a practitioner to dig further. I want to make sure the hidden game surfaces in the learning outcomes and therefore the rest of the learning experience.

Learn from the Team

So much of formal education has the expectation of learning solo. Learning from the team means engaging with richer participation structures (how activities are organized through roles and responsibilities) that are more social and collaborative. Effective participation structures include pair problem solving, studio learning, communities of practice, cross-age tutoring, and extreme team learning.

We've used a few of these, some more directly than others. For example, our work-integrated learning students are asked to pair program very early on in their industry-based education paths. As I work on my CS1 course to be delivered to employees, I'm planning on incorporating learning teams, each one assigned its own mentor. I also want to encourage pair or group problem solving and more meaningful peer evaluation opportunities.

Learn the Game of Learning

"Learning to learn has to do with many things: directing one's attention, choosing time and place, relating new ideas and skills to what you already know. Indeed, it has a lot to do with the previous six principles." To uncover the hidden game of learning, learners need to move from the passenger seat into the driver's seat. Skills ranging from problem-solving strategies to time management should be taught explicitly, either as a standalone course or incorporated throughout curriculum.

Our work-integrated learning program already has workshops that help our students learn the game of learning, such as a growth mindset workshop I led. As I continue to read books on how learning works, I'm hoping to compile the fundamentals into an easily-digestible format and potentially a workshop as well. The former could be shared with learners in my courses for employees as well.

Delivering a Technical Course to Busy Developers

At work, I'm experimenting with how to deliver a technical course to my fellow employees in such a way that participants succeed and our team doesn't have to put in too much time on top of our regular duties. Just making them available for self-directed study results in most folks poking in for an hour and never returning. If we can come up with the right delivery model, we can make all the courses we create for other purposes available to our colleagues without adding stress to our already busy schedules.

Many of our courses were designed for students in our work-integrated learning program first. Most material is curated with our own added context and assessment, and courses are intended to be completed in a self-directed manner. For our WIL students, we provide lots of feedback on their work and hold in-person sessions that range from formal tutorials to quizzes to pair programming assignments, all of which require quite a bit of time and attention from our education team.

I chose a Ruby programming course for my first experiment this summer since the majority of our development is with Ruby on Rails. I put together a series of short workshops previewing Ruby to our Dev Degree students and a more in-depth project-based course the same students took later on. The students spent two hours each on five workshops and about 20 hours a week for 3 weeks on the project.

I initially made the new course 8 weeks long, though we added a breather week partway through. Interested learners were asked to get lead buy-in, and were told they'd need to spend some time during work to succeed. I sent students some pre-learning resources both to set expectations of prerequisite knowledge, and to offer help for those who wanted to fill in any gaps. I recruited experienced Ruby developers as mentors who would answer questions, formally review project work, and run weekly tutorials using video conferencing software. Assignments were due each week, but with soft deadlines; getting an assignment in on time meant being paired up automatically for a peer review.

The course started with over 50 confirmed learners. Many have dropped off since, which isn't unexpected. Some realized that they didn't have enough problem-solving-oriented knowledge, and will likely take one of our intro to CS courses when the opportunity arises. Others found the everyday demands of their jobs made it difficult to keep up, and though there are exceptions, it seemed that once someone fell behind, they more often than not just stopped working on the course.

The course didn't end up being too demanding on my time, but it doesn't look like very many students will finish it. We wrap up next week, at which point I'll start to dig into who finished, who didn't, and why. I plan to have some anonymous surveys as well as focus group discussions. It will be really interesting to see whether we can find some tweaks that result in more success stories.

Have you ever tried to deliver a technical course to your colleagues? What did it look like? What structure worked well?

How We Learn: A Book that Understands the Research and Brings it to the Masses

There's a lot of research out there on the theory of learning, so you'd think we'd all know the tricks by now. Unfortunately, due to the relative inaccessibility of academic research by the general public, this isn't the case. Academic writing, when you can find it without needing to shell out a lot of money, isn't exactly designed for consumption by the everyday person (and I say this having been an academic).

Luckily for us, Benedict Carey, a long-time science journalist, has done the work of distilling key learnings (pun intended) about learning science (etc) from the literature. He shares some very practical results in How We Learn: The Surprising Truth About When, Where, and Why It Happens. Even better, he does it in a way we can all understand.

The book climbs the ladder of abstraction of the mind. It begins with some basic neuroscience theory, explaining how the brain works. It then goes through some of the best techniques to remember things, shares ideas behind effective problem solving, and finally discusses how learning happens away from the conscious mind.

There are a few themes that are threaded throughout the book. For example, some level of difficulty is desired, such as forcing yourself to struggle to remember things through self-testing. Another theme is the power and importance of forgetting:

“Compared to some kind of system in which out-of-date memories were to be overwritten or erased,” Bjork writes, “having such memories become inaccessible but remain in storage has important advantages. Because those memories are inaccessible, they don’t interfere with current information and procedures. But because they remain in memory they—at least under certain circumstances—be relearned.” 

Thus, forgetting is critical to the learning of new skills and to the preservation and reacquisition of old ones.

Other important ideas include the role of context in learning (it's best to switch it up!), why testing is much more important than just for assigning grades, and how to know when to stop working on something for a while to let it percolate.

Carey walks through all of these ideas by telling the stories of the researchers who discovered the various principles, and how their ideas can be put into practical use by us today. If you're looking for just the quick and dirty list of what to do to improve your learning, this probably isn't the book for you. Such a list is there at the end, but you might find reading the whole book inefficient. On the other hand, if you like to have ideas reinforced several times and enjoy hearing about the history behind them in an engaging way, I highly recommend this book!

Review / Invent to Learn: Making, Tinkering, and Engineering in the Classroom

While visiting a branch of our city's library system we don't often find ourselves at, I browsed the tiny section on education. I found Invent to Learn by chance, and though the title's font left me a bit skeptical, I decided to give it a try. I'm glad I did.

The premise of the book is that adopting principles of making into formal and informal education is both feasible and worthwhile. The focus is on maker projects oriented around fabrication, physical computing, and computer programming. The book starts with solid learning theory and goes all the way to how to actually teach with open-ended maker projects.

I'm admittedly an education nerd, so I was delighted to see the book start with some relevant education history, learning theory, and discussion on "thinking about thinking." Seymour Papert, creator of Logo among many other things, is a central figure threaded throughout.

Papert coined the term constructionism, which builds on a previously established theory of learning, constructivism. As defined in the book, constructivism is:

...a well-established theory of learning indicating that people actively construct new knowledge by combining their experiences with what they already know. Constructivism suggests that knowledge is not delivered to the learner, but constructed inside the learner's head.

On constructionism:

Papert's constructionism takes constructivist theory a step further towards action. Although the learning happens inside the learner's head, this happens most reliably when the learner is engaged in a personally meaningful activity outside of their head that makes the learning real and shareable. This shareable construction may take the form of a robot, musical composition, paper mâché volcano, poem, conversation, or new hypothesis.

The authors claim that constructionism is the learning theory that resonates most with the maker movement, and build the rest of the book on this idea.

The rest of the text covers what makes a good project, what 'making' means today, the three game-changers in making (the aforementioned fabrication, physical computing, and programming), the practical stuff of actually teaching through maker projects, and how to convince others that the maker approach is a good idea.

Many concrete resources and materials are described throughout the book. It was published in 2013, though, so a lot of the specifics are likely to be out of date. Nonetheless, the suggestions should serve as a good starting point. (As a side note, the book's website, inventtolearn.com, appears to have been hacked, so best not to visit it at the moment.)

Overall, if you are curious about having your students learn by making things (real or virtual), and want to get a taste of the theory behind why it might work as well as the practical suggestions on how to do it, it's worth checking this book out.

Why I Prefer Processing as a First Language to Teach

Once upon a time, almost 5 years ago, I wrote a post about Python vs Processing as a first language to learn. It became my only post to appear on Hacker News and still gets plenty of hits. The reflections in that post were quite early on in my use of either language for teaching, though. Now that I've used both in several teaching contexts, I'd like to explain why Processing still holds top spot for me when teaching beginners about computer science and programming.

(from a demo in my CS1 course using Processing)

Before I begin, I'd like to say that just because I like Processing best doesn't mean that other options aren't also good. Python, for example, is still a good first language in my view; I even use it in some of my course designs and workshops, especially if someone is in a field that will likely only ever use Python. For younger audiences, Scratch is still my go-to. There are many other languages and tools I probably haven't even seen yet that have great promise, too. But for workshops and courses to introduce beginners in high school, post-secondary, and beyond, Processing remains my go-to.

Without further ado, here are some of the reasons why I love Processing...

Processing is easy to download, install, and run. When you open it, it looks clean and simple. You can ask learners to write in one line of code, press play, and see a drawing pop up. This matters, especially when you are aiming to reduce intimidation of learning to program among less traditional groups. I'm always looking to remove any barrier possible that might make a beginner "nope out" of computing.

The fact that Processing's main purpose is to create visual output is also a huge bonus. You need very little code to create something that is meaningful enough to show others. Running home to show your family that your code spits out a number on a console just isn't the same as showing a (usually interactive) visual program. On the console, it's harder to understand that the code does something interesting and that it took effort to do it.

A further advantage of visual output is the ability for learners to see more of what their own code is doing. When you perform a computation with a single result at the end, the code can feel a bit like a black box. If the answer is wrong, which part of the code caused the issue? At least when all your code contributes to what's on screen, you have some more ability to reason about which code is causing the output to be wrong.

Pedagogically, I have a strong preference for introducing as few individual concepts at a time. I don't like the approach of most textbooks and courses I see, where all the fundamentals (variables, branching, iteration, functions, etc) are introduced quickly up front with toy examples before finally getting to the more interesting projects/demos. At the same time, starting with something too complex right away is intimidating and would likely lead to cognitive overload (*cough* Pygame).

I find that Processing allows me to design demos of just the right complexity. Each new demo only needs max a few new concepts (be it a programming concept or something Processing-specific like adding images). I can show the demo, and start working on creating it, introducing concepts just-in-time. It's also possible to design lots of interesting exercises with the same minimal number of new concepts, allowing learners to focus on mastering a small number of things at a time. I find this more difficult to achieve with other languages, even if there is a visual component (for example, I found Python Turtle too restrictive to achieve this for anything longer than a short workshop, while Pygame is way too complicated up front).

As an example, here is a summary of my CS1 course design in terms of the demos I cover for each module and the concepts that are introduced (more detail, including slides and code):

• Drawing pictures with Processing – a static image with several semi-complex entities (basic drawing, variables)
• Interactive painting with Processing – an interactive painting program that allows you to change colours (active mode/interactions, basic functions, switch statement)
• Jukebox – a music player with three buttons to start and stop songs (functions as abstractions, Boolean expressions, if statements)
• Sheep AI – pet sheep that wanders toward your mouse, drinks tea when it reaches it, and emanates coloured rings when clicked; pictured above (state machines, while loops, arrays)
• Foreign student data visualization – visualization of sortable data available on Canada's Open Government website (Strings, algorithms, state-only objects, constructors)
• Social media set cover problem – contextualized example and visualization of the set cover problem for a small set of data (shared data and references, for loops)

For beginners I prefer teaching languages that are statically typed and generally more 'rigid' for lack of a better term. The more the compiler or interpreter can tell you about what you're doing wrong, the better. I've seen so much frustration from my students working in Python because they do weird things that are syntactically correct, but make no sense semantically. Of course this point doesn't limit the choice to Processing, but it's an added plus for me.

It can also be useful that Processing is Java, but with the tricky parts abstracted away in the IDE. Starting this way is great because you don't have to say things like "don't worry about what public static void means, I promise it'll make sense later." Yet students are actually learning Java syntax when they learn Processing, and can even start pulling in more advanced features of Java later on if desired. When a follow-up course is done in Java (as the CS2 course I designed is required to be), the transition is smooth. Even better, you can still use the Processing library in a 'regular' Java project (example), so you can incorporate it into those later courses if you want. For instance, in CS2, I do so to get students using a third-party library and to learn about MVC and event-driven programming (see more).

I could probably go on about how useful I've found Processing in teaching beginners, but I think this is a pretty good list for now. I'd love to hear about how you've used Processing in your own teaching!

A Growth Mindset Workshop

I recently gave a workshop on the growth mindset with first year computer science students working as part of this amazing program. It went well, so it seems worth sharing. What follows is the workshop plan.

 

Take the following quiz and share results: http://mindsetonline.com/testyourmindset/step1.php

Share definition of growth and fixed mindset (read quote, put key parts on a slide):

“When we ask people to tell us what the growth mindset is, we often get lots of different answers, such as working hard, having high expectations, being resilient, or more general ideas like being open or flexible. But a growth mindset is none of those things. It is the belief that qualities can change and that we can develop our intelligence and abilities. 

The opposite of having a growth mindset is having a fixed mindset, which is the belief that intelligence and abilities cannot be developed. The reason that this definition of growth mindset is important is that research has shown that this specific belief leads people to take on challenges, work harder and more effectively, and persevere in the face of struggle, all of which makes people more successful learners. 

It is hard to directly change these behaviors without also working to change the underlying understanding of the nature of abilities.” (source)

Watch TEDx talk by Carol Dweck. Have students write down everything they found interesting, surprising, or useful. Pair up, pick the top three points of interest, share them.

Share printout with the following quotes from Mindset and have them read them individually. While reading, think about times in your studies (especially in the fall!) where you might have approached something with a fixed mindset, and other times you have used the growth mindset.

I [Carol Dweck], on the other hand, thought human qualities were carved in stone. You were smart or you weren’t, and failure meant you weren’t. It was that simple. If you could arrange successes and avoid failures (at all costs), you could stay smart. Struggles, mistakes, perseverance, were just not part of this picture. 

...children with the fixed mindset want to make sure they succeed. Smart people should always succeed. But for children with the growth mindset, success is about stretching themselves. It’s about becoming smarter. 

Why is effort so terrifying? There are two reasons. One is that in the fixed mindset, great geniuses are not supposed to need it. So just needing it casts a shadow on your ability. The second is that … it robs you of all your excuses. Without effort, you can always say, “I could have been [fill in the blank].” But once you try, you can’t say that anymore.
In this course [in our research study], everyone studied. But there are different ways to study. Many students study like this: They read the textbook and their class notes. If the material is really hard, they read them again. Or they might try to memorize everything they can, like a vacuum cleaner. That’s how the students with fixed mindset studied. If they did poorly on the test, they concluded that chemistry was not their subject. After all, “I did everything possible, didn’t I?”
…
The students with the growth mindset completely took charge of their learning and motivation. Instead of plunging into unthinking memorization of the course material, they said: “I looked for themes and underlying principles across lectures,” and “I went over mistakes until I was certain I understood them.” They were studying to learn, not just to ace the test. And, actually, this was why they got higher grades – not because they were smarter or had a better background in science. 

[Benjamin Bloom, eminent educational researcher, says:] “After forty years of intensive research on school learning in the United States as well as abroad, my major conclusion is: What any person in the world can learn, almost all persons can learn, if provided appropriate prior and current conditions of learning.” 

Just because some people can do something with little or no training, it doesn’t mean that others can’t do it (and sometimes do it even better) with training. This is so important, because many, many people with the fixed mindset think that someone’s early performance tells you all they need to know about their talent and their future. 

[Story from one particular student, Tony:] In high school I was able to get top grades with minimal studying and sleeping. I came to believe that it would always be so because I was naturally gifted with a superior understanding and memory. However, after about a year of sleep deprivation my understanding and memory began to not be so superior anymore. When my natural talents, which I had come to depend on almost entirely for my self-esteem (as opposed to my ability to focus, my determination or my ability to work hard), came into question, I went through a personal crisis that lasted until a few weeks ago when you discussed the different mindsets in class. Understanding that a lot of my problems were the result of my preoccupation with proving myself to be “smart” and avoiding failures has really helped me get out of the self-destructive pattern I was living in.

After the exercise, have students pair up and discuss the consequences of using the fixed or growth mindset in different scenarios. Share one or two stories with the group.

GHC16 / Building a Better Classroom: Lessons from Ed-Tech

One of the panels I attended at this week's Grace Hopper Celebration featured women from various companies engaging in ed tech, whether as their sole purpose or as a smaller part of their mission. Panellists included Prachie Banthia (moderator, Google), Lauren Janas (Microsoft), Stephanie Killian (Knewton), Jen Liu (Quizlet), and Sha-Mayn Teh (Teachers Pay Teachers).

The panel began with a discussion of the challenges in getting classrooms to adapt ed tech. Unsurprisingly, cost and difficulties in rolling it out topped the list. Then each panellist discussed what problems specifically they are trying to solve:

• Learning can be static, tedious, and boring. Quizlet makes it more fun. Most users are middle and high schools using it for language learning, math science, etc. Some adults use it too, for things like med school and even bartending. Today, their focus is on K-12.
• Knewton focuses on the problem in ed of 'one size not fitting all.' Standard models of education treat everyone the same (curriculum, pace).
•  Some teachers were really focused on using tech in the classroom, e.g. to scale learning to class sizes of 45. Google Apps tries to support and reach the majority of teachers that aren't currently doing this.
•  MS Office Mix supports developing materials for flipped classrooms. You can record yourself talking over a PowerPoint presentation, include quizzes, and distribute to students. The software provides analytics to improve lessons and see how well students are learning.
• Teachers Pay Teacher helps teachers search for the right resources quickly.

Another one of the challenges faced by creators of ed tech is surviving the peak time of back-to-school. Advance planning is required to figure out how to scale the load capacity based on projected numbers of students. Launching any time after August 1 is really like launching the following year on August 1, because you've missed the critical window for adoption. The holiday season is the down-time, and that's where fixes and be made.

So how do these panellists view adoption of ed tech? They say tech in schools is fragmented, and so it is difficult to target a particular platform. It is very important for a company to earn the trust of teachers and administrators. Teachers are reluctant to test things on students. Too much setup time will make adoption harder: class time is precious. You have to make the barrier to entry as low as possible. And, of course, there are many issues around school networks / wifi. 

When it comes to the fear that ed tech might be trying to replace teachers, the panellists say this isn't the case; they want to empower teachers. Some call themselves teacher-preneurs and they all have such passion, and find creative ways to use technology to make their point with students.

A controversial question: are larger companies like Google and Microsoft more likely to succeed than the smaller companies, thanks to their resources? Having a lot of spare resources does give bigger companies a leg up. Smaller companies with education as a core product need to find a revenue model, which is challenging. Enterprise partnerships can help. All agree that it is good having the larger companies there, but also the smaller disrupters. Large companies have scale, and people already know how to use their products. Even still, monetization is hard for everyone (even Google struggles with this still). Smaller companies have the advantage when it comes to the ability to disrupt: Google can't take a pedagogical stance (65 million users whose trust can be lost), but smaller companies can.

Innovation Needs Computer Science

On Wednesday, I gave a talk at an event called Ignite that brought together government and business folks to talk innovation. There were four lightning talks of about 5 minutes each, and mine was on computer science education. Below is a transcript of my talk.

This event is not focused only on technology innovation, but let’s face it: technology is everywhere. Computers are everywhere. And yet, most of us are just consumers of technology, rather than producers. I’m willing to bet that this applies to many of us in this room.

There is so much to gain from learning computer science, not least of which is to think in a new way: we call this computational thinking. You gain skills applicable to so many areas of life, like decomposition, pattern recognition, abstraction, and algorithm design.

And, if you learn to program on top of it, you can learn how to automate the really boring, menial tasks you may be completing manually right now. ;)

More generally, with some computer science knowledge, you can create things instead of relying on others to do it. How empowering!

Based on the benefits, I believe that innovation will increase as more Canadians understand at least some computer science.

So why aren’t more of us learning it?

There are two big factors that contribute: misconceptions about what computer science is, and problems with computer science education.

One of the biggest misconceptions of computer science these days is that it is just about programming computers. Many people aren’t interested in learning to program for the sake of it. However, computer science is actually not equivalent to computer programming; it’s about solving problems. It just so happens that programming is one of the tools used to realize a solution.

We have some cultural problems for computer science as well. Who do you picture when asked to imagine what a computer programmer looks like?

Perhaps more importantly, what does Hollywood have to say about it?

Even worse, an awful lot of people believe in the “geek gene”: you either have the brain for logic and programming, or you don’t. This is known as fixed mindset, but what we really want is growth mindset: the belief that anyone can do it if they are willing to put in the time and effort. You don’t have to be a genius to learn computer science; you don’t even have to love math.

And best of all, your main job doesn’t even have to be as a computer programmer! Because computers are everywhere, you can pick your passion and use computing to solve problems in that area. (That’s the thing that excites me the most about CS – you can use it to the solve problems you care about and made a real impact on the world.)

Unfortunately, even if we are able to clear the misconceptions of computer science and get more folks interested, we still have the issue of effectively educating them. A lot of people are interested in learning computing in theory, but don’t pursue formal education opportunities. The way we teach computer science just isn’t appealing to most.

For example, women are severely underrepresented in computer science. It’s difficult to recruit women and other underrepresented groups, and it’s even harder to retain them. Members of these groups face issues like stereotype threat and low confidence in their abilities compared to the majority group of white and Asian men.

Ensuring students get insight into what computer science is in K-12 is a big help. But K-12 teachers are generally not trained in computer science, and don’t know how to teach it. Beyond that, the lack of confidence many have of their ability to learn and do computer science affects their students’ beliefs as well, not unlike what happens with math.

Computing education research is also in its infancy. We are just scratching the surface on how to effectively teach computer science, especially to beginners. Pushing this research forward, and finding more effective ways to share results with teachers, is important.

So what can we do?

• We need to give students in K-12 a more accurate picture of what CS is, and teach them fundamental skills so they can become producers sooner.
• We should also scale informal education to help achieve this goal.
• Curriculum and pedagogy at all levels should be carefully redesigned to be inclusive and engaging to a broader range of students.
• Related to this, we need to support and encourage faculty in Canada to pursue computing education research.
• We need to actively recruit underrepresented groups – “build it and they will come” does not work here.
• We need to change the culture around CS and programming. This may be the hardest task of all if we don’t get broad buy-in, including in Hollywood.

At Shopify, we recently started building a new team that hopes to contribute to each of these issues. My role is Manager of External Education Programs.

Since we began earlier this year, we’ve started forming partnerships with educational institutions and experimenting with new learning models for computer science. We care about making learning computer science better for everyone, where “everyone” is as inclusive as possible.

I hope that everyone here today will also play their part, even if it’s just to spread the word about what computer science is really all about to the people you know.

Let’s make change together.

Photo by Matthew Usherwood

'Take Your Kid to Work Day' Coding Workshop with ScratchJr

A new professional development day was recently added to our local school board's calendar. One of my colleagues, John Duff, made the brilliant suggestion to have a 'take your kid to work day' instead of scrambling to find babysitting. Naturally, I suggested we also add a coding workshop.

Little did I know that most of the kids in attendance – my own included – were between 4 and 7 years old. Grade 4 or so was the youngest I'd ever worked with before, and the idea of teaching kindergartners was especially foreign. Thanks to the helpful advice of a few kind folks (especially Kate Arthur of kidsCODEjeunesse), the workshop turned out great!

To prepare, I read through a bunch of The Official ScratchJr Book from No Starch. The book is awesome, and I definitely plan to use it to continue working with Molly. One thing that I especially liked was the curriculum connections listed out at the end of each chapter. If you happen to be a kindergarten teacher, and have access to tablets, I highly recommend checking this book out.

In case you want to run a similar workshop, here's a bit of info on what we did. The workshop was held in our coffee shop. We moved away a bunch of tables and set up our bear beanbags in a semi-circle in front of the projector screen. I AirPlayed an iPad to the screen for demonstration purposes. To get the attention of the kids, we did a "hands on head" thing: everyone, parents included, had to have their hands on their heads before I talked about the next thing.

Before the workshop, I sent out a doc with information for parents containing the following key information.

 What we'll be doing

We will be working with ScratchJr, which is a visual block-based programming tool. While not required, you might like to learn a bit about the tool ahead of time. On the website, you can get an overview of the interface, the sprite editor, and what each block does. There are also videos with tips. 

ScratchJr is officially intended for ages 5-7, but the appeal for this workshop should be broader. That said, older children might prefer being a “helper” for a younger sibling and/or trying out the web-based Scratch instead. The older kids could get the basic ideas in ScratchJr first, and if they get bored, they should be able to pick up the main ideas of Scratch fairly easily. 

We have arranged to bring iPads for those who said they needed them.
We recommend bringing your laptop with you, both to look things up about ScratchJr, and to switch to Scratch if desired.

During the workshop

The assumption is that you, as the parent, will sit with your kid the whole time and work with them on their projects.  If you are bringing two kids, you may choose to have them work together or separately. We are hoping to have extra volunteers who would be able to help if they end up working separately. 

We hope to have those participating in the workshop up near the projector, “circle time” style. We should use comfy chairs and beanbags to sit on in a generally circular shape. 

One of the techniques we plan to use to gain attention of the kids is “hands on head” – when we ask kids to do this, it would be great if parents did it as well. Once everyone’s hands are on their heads (and therefore not touching the tablets/computers), we can starting talking up at the front. 

Super important: Try as much as possible to not do anything for your kid. Make sure that you guide them, ask them questions, perhaps even make suggestions, but not do it for them. 

Try to stop your kids from playing with other apps on the iPad at first (perhaps turning off wifi will help?). Later on, if they get bored of working on their own projects, they might enjoy sharing their favourite apps with the other kids.

General workshop plan

1. How to add a new sprite and edit it.
2. How to add a new background.
3. Example blocks (will ask kids what they think the blocks do before showing them; time to play will be after all blocks):
1. Move right (what does the number change?)
2. Turn left (what does the number change?)
3. Say (how could you have it say your name?)
4. Play recorded sound (try recording your voice!)
4. Example of snapping blocks together (can you guess what will happen?)
5. Start on Green Flag:
1. Have them add this block to the beginning of a script (suggest a bunch of movement blocks to make the character dance)
2. Have them press the green flag button at the top
3. What happens?
6. Repeat forever
1. What happens if you put a repeat forever at the end of the script, then press the green flag?
7. Save your project! Go back to the home screen to save

--

I was pleasantly surprised that we managed to keep the attention of the youngest kids for a whole hour. Later, at lunch, several of the girls excitedly exclaimed how much they loved working on the iPads / playing with ScratchJr. Music to my ears!

My Nonlinear Career Path

I've had a really nonlinear career path. One step forward, two step sideways, new goal, start it all again...

My interest in computers started at a young age. I was lucky that my dad, a government worker, was able to bring home the computers his office was done with. As a result, I have had access to computers, and even had a computer in my own room, from a young age.

I've always loved to create with computers. From writing stories to designing newsletters for my Guiding troupe, I was always making things. Even today, I make digital scrapbook pages!

In high school, I started becoming more and more curious about how things work "behind the screen," so to speak. How do you write code to make a word processor? What's the math behind vector graphics? How does computer hardware, at the lowest level, add two numbers?

I decided I wanted to take computer science in university so I could learn all this and more. I didn't learn how to program in high school; instead, I took drama and music while I still could. But I was pretty sure I'd love the world of code whenever I eventually entered it.

Turns out I was right. I also loved working in the industry during my co-op terms. One of my jobs was at Ross Video, working on software for a video production switcher. The other was at Corel, where I worked on the text engine for Corel DRAW, software I had used for many years in my personal projects.

Nearing the end of my undergrad, the most difficult decision I faced was which of these two companies I would try to work at full-time. I never thought I'd do anything other than go to industry.

I was going to be a software developer.

Until, that is, a professor approached me and convinced me to consider graduate school. The catch? The application for the big scholarship was due in a week. Well then.

Image adapted from Ivory Tower by OfTheDunes

I applied, and I got the scholarship. So I went to grad school for my Masters. I had a great time, and even got my start in outreach, but learned something very important: I didn't care for the low-level, experimental nature of my thesis topic, and wished I did something more applied.

I decided to continue on to my PhD, choosing storytelling in videogames as my thesis topic. I engaged in educational games and computer science education research on the side. I also took the opportunity to gain more teaching experience. I eventually realized that education was my passion and I wanted to teach.

I was going to be a university instructor.

After some contract work, I got a two-year term position as a full time faculty instructor. I made an impact with some innovative course designs and a lot of hard work in outreach and diversity. But when I tried to get a permanent instructor job, I missed it by a hair. Although I was not yet finished my PhD, I didn't really fancy going back to being a full-time student. Instead, I figured: why not go back to industry and be a software developer again?

So off to Shopify I went. I joined the Home team, working on the first page merchants on the Shopify platform see when they log into their admin. I learned both Ruby and Rails, and finally had a chance to try real-world web development.

I quite enjoyed working as a developer, but it was a step sideways from my goal of teaching. However, in the fall, an opportunity arose.

I was going to jump back into education once again!

Starting this past January, I became Manager of External Education Programs. I'm working on some really exciting education projects, including a sponsorship of the Ottawa Network for Education's AppJam. I get to create curriculum, teach, and even create a team of similarly passionate folks here at Shopify.

So while I have taken some steps back in my career, and some other steps sideways, I find myself feeling very fortunate to end up where I am now. So if you ever find yourself on a really windy career path, don't fret: go with the flow, and see where it takes you. You might find yourself ahead of where you expect, even if it you hit your goal at a bit of a strange angle.

Artificial Intelligence Simplified: Understanding Basic Concepts

I am officially a published author!

I co-authored a book called Artificial Intelligence Simplified: Understanding Basic Concepts.  My expertise is not in AI, but I am skilled at bringing technical content to more general audiences.  So my co-author Binto George wrote the text, and I helped transform it into an informal, tutorial-style overview of the basics.

The book grew from what was originally going to be a chapter in a larger volume that touches on many different areas of computer science.  Our philosophy was that learning in context was more effective, so each chapter was going to have its own motivating question.  For example, in my first chapter on data representation (which will likely make it into a book of its own), my question was "How did photography go digital?"  The AI chapter's context was healthcare, which we decided to stick with in the expanded stand-alone book version.  The result is an introductory book that discusses the main ideas of the field in the context of a few problems found in healthcare, such as scheduling surgeries for an operating room.

Here's some info from the back cover of the book.  Go check it out on Amazon (Canada, US).  There's a cheaper student version floating around as well.

Artificial Intelligence concepts explained using real-life examples. No complicated math or jargon.  

Have you ever wondered what Artificial Intelligence, or AI, is all about? Let us guide you through the key concepts of AI with our friendly, tutorial-style explanations. We use everyday language and concrete examples in the context of healthcare to ensure things don’t get too abstract. Whether you’re a complete beginner who’s curious about AI, a student who’s intimidated by the technical nature of traditional textbooks, or even a robotics enthusiast who just wants to get started with AI, this book is for you.

Connections: Learning Science, Games, and Apprenticeships

I'm working on an education project that isn't ready to announce yet. In so doing, I've been taking another look at learning theory, game-like learning, and apprenticeships. Unsurprisingly, there are many connected ideas.

Close connection / Daniela Hartmann

There's a great book called How People Learn: Brain, Mind, Experience, and School that you can read for free online. The introductory chapter aims to separate speculation from science, summarizing some of the key concepts and practices covered in the rest of the book. Part of this is a research-based list of attributes that good learning environments ought to have:

1. "Schools and classrooms must be learner centered." Consider cultural differences between students, and foster a growth mindset over a fixed mindset.
     
2. "To provide a knowledge-centered classroom environment, attention must be given to what is taught (information, subject matter), why it is taught (understanding), and what competence or mastery looks like." Avoid presenting a large number of disconnected facts, and don't design tests that favour memorization instead of understanding. Doing with understanding is more important than just hands-on doing.
     
3. "Formative assessments—ongoing assessments designed to make students’ thinking visible to both teachers and students—are essential." Use formative assessments to allow students to experiment with and revise their understanding and track their progress.
     
4. "Learning is influenced in fundamental ways by the context in which it takes place." Make the norm of your learning environment one that encourages risk-taking, mistakes, feedback, and revision.

Meanwhile, one of my favourite examples of game-like learning (that is, applying what we know about learning in good games to more traditional forms of education) is NYC public school (grades 6-12) Quest to Learn. Seven principles of learning are outlined in the Q School Design Pack, directly quoted below:

1. It kind of feels like play: Learning experiences are engaging, learner-centered, and organized to support inquiry and creativity.
     
2. Everyone is a participant: A shared culture and practice exists where everyone contributes, which may mean that different students contribute different types of expertise.
     
3. Failure is reframed as iteration: Opportunities exist for students and teachers to learn through failure. All learning experiences should embrace a process of testing and iteration.
     
4. Everything is interconnected: Students can share their work, skill, and knowledge with others across networks, groups, and communities.
     
5. Feedback is immediate and ongoing: Students receive ongoing feedback on their progress against learning and assessment goals.
     
6. Challenge is constant: A “need to know” challenges students to solve a problem whose resources have been placed just out of reach.
     
7. Learning happens by doing: Learning is active and experiential. Students learn by proposing, testing, playing with, and validating theories about the world.

I'm sure you are already seeing the connections. For example, the learner-centred theme appears in both lists, formative assessments to revise thinking is similar to failure reframed as iteration, and context and practical experience are important throughout. Of course, this is no accident: The Institute of Play, the organization behind Quest to Learn and similar schools, have done a lot of careful research into both learning and games. Even without the more obvious game-based approach of Quest to Learn, game-like learning principles are useful to apply to any educational initiative.

Finally, I have also been learning more about apprenticeships, particularly for software developers.  In the introduction of another freely available book, Apprenticeship Patterns, software craftsmanship is defined as a community of practice with a common set of underlying values. Many of the values listed tie again to the ideas described above. For example:

• “An attachment to Carol Dweck’s research, which calls for a ‘growth mindset.’” How People Learn calls for a community in which the growth mindset is the norm.  Failure as iteration shows students that they don't need to 'get it' the first time, but instead work toward mastery.
    
• "A need to always be adapting and changing based on the feedback you get from the world around you." Formative assessment provides opportunity to react to feedback, and in game-like settings feedback is always coming your way.
      
• "A belief that it is better to share what we know than to create scarcity by hoarding it." Game-like learning encourages sharing knowledge broadly.
    
• "A willingness to experiment and be proven wrong." Again related to failure as iteration.
    
• "A strong preference for what Etienne Wenger calls ‘situated learning.’" Communities of practice are one part of Wenger's situated learning theory, which relates to the idea of learning in context and learning by doing.

I'll be delving deeper into a lot of these ideas and seeing how they will apply to the project I'm working on. Perhaps the perspective from the three different angles presented above will help you in your own projects, as well.

HLF2015 / Fred Brooks on Software Engineers and Teams

This blog post originates from the Heidelberg Laureate Forum Blog. The 3rd Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place August 23-28, 2015. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

It has been over a week since the end of HLF, and I've been settling back into my life as a software developer at Shopify in Ottawa, Canada.  I often find myself thinking back to what I consider to be an epic conversation with laureate Fred Brooks.  With my husband and fellow blogger, Andrew Carmichael, I interviewed Brooks in what was a joint effort.  Brooks was kind enough to spend over an hour with us.  Since I can't possibly share everything he said in one blog post, I've put together a transcript that you can read online, and I've picked a few tidbits to share here.

Because Andrew and I both work as software developers, we wanted to take a more practical, industry-driven approach to our discussion with Brooks.  For example, we asked early on what makes a programmer great.  At first Brooks simply said "too hard" in his patient southern accent with a smile on his face.  He then explained that being able to visualize complex geometric constructs was a pretty good indicator of whether beginners would be good programmers.  We also discussed the importance of teamwork:

I once worked with a colleague when I was a summer intern… this fellow was extremely difficult to get along with.  He was our supervisor to us two interns, and that was fine, but he could not get along with any other colleagues in the room.  His boss remarked one day to the two of us privately, “You know, if we could put him in a box with two slots, one to put problems in and one to get answers out, it would be great!” [laughter] And he was easily the sharpest person in the room, but I was not surprised to learn three years later that when they had a reduction, he was the first one let go in that group. ... We used to get fractional distillation of the nerds [laughter]. ... Now we’re drawing from a larger population.

We also wondered what companies could do to grow recent graduates into effective professional programmers.  For Brooks, the key is apprenticeships.

Only talk to me about the theory when I’ve encountered the problems.  I’m willing to listen to your war stories, but I need to be able to bring from my own background my own war stories to make what you say to me relevant. 

Therefore I would do rotational mini-projects, and I would do rotation definitely so that...well, you know, the same thing they do with residents in medical school.  Go try surgery, go try pediatrics, go try psychiatry.  It will make you in general a better physician in all respects. 

I’m not interested in making people into better programmers, I’m interested in making people better software engineers.

Once a programmer is ready to join a team, there are many skills to learn.  For example, estimating how long software projects will take is a very difficult task for teams.  When we asked about what could be done about it, Brooks gave us this great quote:

One of my friends who was an electrical engineer on the 360 project said there are promising engineers, and there are old engineers, but there are not promising old engineers [laughter] - they don’t make promises!

Of course, how well a team can produce estimates is not the only indicator of how successful they will be (or perhaps not an indicator at all).  We asked Brooks what he would do if he could spend one day with our teams at work if he had to determine whether we would succeed or fail.

Talk to a lot of people [laughter].  One of the things I’d be looking for is how consistent is their view of the goals.  One is: how highly do they respect each other? One I would be looking for is: do they believe in the goals, or is it something they were assigned and not sure they’re going to be able to do anyway? One is: are they excited about the goals? “Yeah, this is going to a contribution, it’s going to be a great system, and I’d be glad to be part of this team!” 

One question I’d listen for, but my presence would interfere, is when they chat, do they chat about work, or last night’s TV? Which has to do with: are they really excited about what they are doing, or are they just turning the crank? 

Purely subjective.

This is just a taste of our interview.  Our conversation took many different directions, winding through topics like education and Grace Hopper.  We were very grateful, however, to be able to bring all kinds of practical advice and insights to our team at work.  Again, check out the transcription of the interview if you want to see more.

HLF2015 / Sir Antony Hoare — Theory and Practice

This blog post originates from the Heidelberg Laureate Forum Blog. The 3rd Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place August 23-28, 2015. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

As with my interview with John Hopcroft, I was most interested in what Sir Antony Hoare had to say about computer science education. He was, after all, knighted for his work in education in addition to research. I was also particularly fascinated with his effort to tie academia and industry together, for example by setting up an external Masters degree for software engineers.

©HLF/ / C. Flemming­ - All rights reserved 2015

My first question for Sir Hoare was about whether we should be concerned that undergraduate degrees try to address both theory and practice. Most graduates will go on to work in industry, but many academics seem to believe that they are training students primarily for academia. Sir Hoare's belief (and I happen to agree) is that theory is valuable to learn for all students regardless of their future paths. Learning theory helps you better understand what you're doing by noticing analogies to what you've done before, thus increasing your competence. Once you get into the workplace, theory can make your job less boring: it is fun to see real-life examples of the theory you learned in school! It can also help you understand when the code you write is 'good.'

Next, I was curious what Sir Hoare thought of active learning techniques in the classroom. Though he wasn't particularly familiar with recent approaches, he wouldn't say no to the possibility that they can improve learning. As with anything, if it's done well and in moderation, it can be a good thing. Then again, we can also talk about what makes a lecturer effective on their own: a good lecturer, he says, has charisma and motivates students with rhetoric. Further, the lecturer has many existing tools available, such as textbooks, tutorials, exercises, practical projects, and even discussions (sadly, we never had any of these in our undergrad CS classes). I would love to say that I believe all this is enough, but I have seen firsthand that, for far too many students, it isn't. It will be interesting to see what a typical undergraduate lecture hall will look like in a decade or two.

Finally, I told Sir Hoare that I couldn't not ask him a question about quicksort, but that I'd try to put a different spin on it. (This elicited a large smile.) I have used quicksort as a first introduction to recursion for my students in the past, including for my arts and social science students as they learn the basics of computational thinking. I wondered how he felt about its efficacy as a first example. It turns out that not only does he think it's great for teaching recursion, but he even had some fun ideas for how to do it. One is a wonderful video that explains the algorithm via a Hungarian folk dance. I've used the same set of videos in my lectures, and highly recommend them. Another idea is based on the card game Patience (also known as Solitaire).

It's interesting that Sir Hoare began our conversation with an admittance that he hasn't been working on education the last 15 years, so he thought he wouldn't have much to say about it. As you can see, I once again had a wonderful conversation on the topic, and am very glad to have gained some insight into Sir Hoare's thoughts on theory and practice in computer science education.

HLF2015 / John Hopcroft, Diversity, and One of the First Computer Science Courses

This blog post originates from the Heidelberg Laureate Forum Blog. The 3rd Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place August 23-28, 2015. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

I've long had a special interest in computer science education. I recently worked as a full time lecturer for two years, and I have been designing and delivering outreach initiatives for more than seven. So when it came time to request interviews with this year's HLF Laureates, John Hopcroft, who created one of the world's first computer science courses, caught my attention.

I began our conversation by introducing my interests in education, and right away Hopcroft pointed out that there is so much talent distributed around the world, but that educational opportunities are not so widely available. This has been in the case in China, for example, where Hopcroft has been working; he says their educational system needs help, and they know it. Of course, improving education everywhere is important. Hopcroft points out that as we move more and more into an intellectual economy, we need to better prepare our workforce.

John Hopcroft during his lecture at #hlf13 ©HLFF // C.Flemming - All rights reserved 2013

For me, this means ensuring that we educate everyone with at least the basics of computing. Right now, the field of computer science is not very diverse. For example, in the United States, according to the National Centre for Women & Information Technology, only 18% of computer and information science bachelor degrees went to women in 2013, and women made up only 26% of the computing workforce. Hopcroft suggests that one factor in a rather complicated issue is that women seem to want to help people, while men are satisfied by learning more abstract things. This idea validates my own theory that many men are often happy to primarily learn about the tools of computing (code, hardware, etc) for the sake of it, while women tend to want to know what you can do with these tools.

So what was the diversity like in Hopcroft's very first computer science class? Understandably, he wasn't really aware of diversity at the time. After all, there was enough to worry about, like figuring out how to teach one of the world's first courses on computer science despite having a background in electrical engineering. Ed McCluskey asked Hopcroft to teach the course, and in doing so, Hopcroft found himself becoming one of the world's first computer scientists. This lead him to be at the top of the list whenever anyone needed a computer scientist for, say, an important committee, thus giving him opportunities that for most disciplines wouldn't be possible until close to retirement. Hopcroft admitted he feels lucky for the way things worked out, and credits Ed for making it possible.

After learning that Hopcroft's first courses covered automata theory, I wanted to know what he thought the best computer science teachers do more generally. He told me he went into teaching because of the impact his many world-class teachers had on him at every stage of his education – he wanted to do the same. To be a great educator, he told me, it is not about the content, which anyone can specify. The single most important thing is to make sure your students know you care.

I was curious what Hopcroft thought of recently proposed active learning techniques like peer instruction and flipped classrooms. He said he didn't have any experience with them, so couldn't really comment. However, he did reveal that he still uses the blackboard during lectures – that way, he can change his lecture on the fly according to student needs. I pointed out that this could be considered a form of active learning, as there would be a feedback loop in the classroom. He did point out that techniques like the flipped classroom have some hidden concerns. For example, one must consider the credit hours a course is worth. If you are shifting what was done during lecture into videos or reading ahead of time, are you adding more pressure to the students' time?

I quite enjoyed my conversation with Hopcroft, and will leave you with some advice that he gives his students. Don't focus on what your advisors have done in their careers; their work was done in an era where the focus was on making computer systems useful. Look instead to the future, when we will be focussing on doing useful things with computers.

Keynotes and Inspirations at Foundations of Digital Games 2015

I had a great time at this year's Foundations of Digital Games, but it was the talks and the hallway track with narrative folks that really left me inspired.  In this post I'll summarize the first three keynotes and some inspiration I got from one of them; you can check out my raw talk notes and the proceedings for more details.  The sketch notes I'm including are all by Chris Martens, a fellow narrative PhD candidate (though she'll be done soon!).

Tom Forsyth's Keynote

The first keynote of the conference was given by Tom Forsyth, who worked at Valve and then Oculus VR.  Tom highlighted some of the challenges we face when designing all-new experiences for virtual reality.  For example, motion sickness comes from there being an imbalance between what your eyes see and what your ears feel, so having players move up stairs causes issues (elevators are apparently much better).  It's also important to avoid most cinematography techniques, and to use an eye blink transition whenever possible.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

Robin Hunicke's Keynote

The next day we heard from Robin Hunicke, who produced Journey and is seriously inspirational.  She began by talking about Wattam and its designer Keita's inspiration for the game.  The zaniness levels of that game are right up my alley, making me want to get a PS4 even more...

Most of Robin's talk was about her inspiration for Luna, which as she puts it, was kind of a beast.  She talked in depth about the inspiration noted on the game's website: "origami, shadow boxes, abstract sculpture and minimalist illustration."  Near the beginning of the design process, she apparently spent six months alone in her apartment, folding paper.  It turned out that folding paper digitally wasn't very fun, but that didn't mean some of the lessons learned from origami couldn't apply to a game's design.  Luna looks wonderfully whimsical, and I am hoping I was mistaken about it being a VR game (or at least, not VR-exclusive) because I would really like to try it.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

R. Michael Young's Keynote

The first academic keynote of the conference, R. Michael Young is in charge of the Liquid Narrative Group at NCSU.  He described some of the main areas his group looks at in the world of narrative after reminding us that "narrative is big. Really big."

The systems his group builds are evaluated based on whether they produce narratives that can be understood by humans in particular ways.  They break narrative down into story (everything that happens inside the story world), discourse (the choices the author makes in how to tell the stories; what goes into the telling), and interactivity (what happens when a player goes into the role of a character? How do we design the story and discourse?).

The group's most used tool seems to be artificial-intelligence-based planners.  Planning looks at how to automatically sequence actions in the face of a novel set of environmental goals.  In narrative, this might mean anything from having characters scheme to achieve their own goals, to authors planning to mislead then reveal.  Stories are broken down into the smallest possible units (such as individual actions), then built back up.  Many problems arise from the use of standard planners, which often tell uninteresting stories.  One of the ways to improve the outcomes is the group's current work in progress that attempts to express character traits through the action sequences created.

[raw talk notes]

Sketch note by Chris Martens, via Twitter

Inspiration

Michael's distinction between story and discourse got me thinking about my own thesis project (read a somewhat out-of-date description here).  I realized that a large part of what I'm doing feels more like discourse than story.

It felt even more clear to me when I thought about Mieke Bal's definitions of story and fabula from Narratology: Introduction to the Theory of Narrative.  A fabula is "a series of logically and chronologically related events that are caused or experienced by actors" while a story is "a fabula that is presented in a certain manner."  Most of the techniques I am working on actually don't affect the fabula so much as the way the fabula is experienced.

One of the areas I struggled with in my thesis proposal was justifying why I didn't want to use planners.  There are some definite reasons that were easy to articulate, such as difficult authoring.  However, I also had this unarticulated understanding that planners weren't quite right for the design approach I took, but wasn't sure exactly why.

By thinking about story and fabula, I was able to realize that I'm not trying to arrange actions into a story so much as allow navigation through a set of coarser story pieces featuring fixed actions.  I want players to be able to explore a mostly fixed fabula in different ways, leading to different interpretations of it.  In the process, the resulting story should still have a sense of (but not necessarily actual) coherence.

As a result of this insight and another cool idea that came up during the conference, my thesis project's focus is tightening up very nicely.  I'll share more about that sometime in the future.