Teaching with Swift Playgrounds

Teaching can be difficult and teaching programming can be even harder — it's abstract and concrete at the same time, and you must help the learner build a mental model of what code really does. Find out how the Swift Playgrounds content team works through the teaching process, from idea to finished playground. We'll cover lessons learned building the Learn to Code series, and tips and methods we've developed to streamline our current workflow. Come away with valuable teaching insights and a great head start on building your own instructional content.

Related Videos

WWDC 2018

WWDC 2017

Thanks for spending part of your
WWDC with us, talking about
teaching with Swift Playgrounds.

My name's Bill Dudney, I'll be
joined shortly by my colleague,
Elizabeth, to talk about
teaching with Swift Playgrounds.
So, you might have noticed, over
the last few years we started
with Hour of Code, and even some
initiatives before that, that
the whole world is now talking
about people learning about
computational thinking, about
how to program.

In India, in Asia, and Africa,
and the United States.
There's big school systems like
New York and Chicago talking
about teaching all of their kids
how to code.

Even heffalumps are learning how
to code.
Everywhere, everybody is
learning how to code.
And, we are really excited about
that.

It's such a fantastic time to be
in a place where, to be in a
time, where everyone is starting
to talk about coding.
So, our talk today is divided
into two major sections.

The first one, I'm going to
cover, talking about teaching,
and then Elizabeth is going to
talk about designing and
implementing playgrounds.
But, those two sections have
three main pillars in them.
Goal, passion, and audience.
So, let's get started with
teaching, and specifically about
the goal.
Now, as a teacher, you of course
have to have a goal.
What information is it that you
want to impart to your learners.

But, equally important, is your
learner's goal.
What is it that your learner is
trying to get out of that
content?
They need their goal to be front
and center of the content so
that they stay motivated,
because while learning to
program is not hard, it does
take hard work.
So, a place where I'm sure many
of us have been with mathematics
is to either love it, or not,
and I'm sure we all have friends
who don't.
As programmers, probably most of
us are into mathematics.

We've at least played with it,
and done some stuff with it.
The people who don't get it
though, are often, or who aren't
excited by mathematics are often
turned off by it, by some
experience where they end up
with this long list of
functions.

Polynomials, trig, exponentials,
logarithms, their inverses.
Solving for "x."
I remember, when I was younger,
and sitting in my geometry class
with my teacher, Mr. Carlin, I
would ask him, probably once a
week, I was a real pest, "When
am I ever going to use this?"
And, he would look at me and
say, "Please stop asking me that
question."
And, eventually, after I've
pestered him enough, he said,
"Look, you're probably never
going to use this, but it's
really cool anyway," and that
sort of flipped a bit in my head
to go from looking at math as
utilitarian, to looking at math
as something that's beautiful
and fun to mess with, like a
puzzle to solve.
And so, that really struck me,
and it turned my direction away
from being frustrated with not
having some practical
application for it, to enjoying
it just to solve puzzles.
Now, of course, little did Mr.

Carlin know, that I would
eventually become a nerd, and
deal with geometry all the time,
so thank you, Mr. Carlin, for
teaching me geometry despite my
resistance.

So I have a couple of examples
that I use to try to explain
this concept to people, because
I think it's so important that
we think through this, when
we're thinking about teaching.
Now, imagine you're trying to
learn how to do art.

But instead of being artistic,
and spreading paint around a
canvas, instead, you're
encouraged, or forced, to study
the texture of colors, or the
look of the color, or the shape
of the brush, but never able to
apply that paint.
It would be really hard to stay
focused on learning to become an
artist when you can't do art.
People want to create, they want
to build things, or they want to
make things.
And, if you had to study that,
it would be very difficult to
get through it.
So much better to let people,
when they're learning to paint
to make a mess, smear the paint
all over the place without
concern, really, for what it
looks like.
You can worry about that later.

Same thing with music.
Imagine if you had to know what
every dot, every line, every arc
on this diagram meant before you
could pick up a guitar, or start
playing with your piano.

It would be very difficult to
get through all that.
So, I encourage people who are
thinking about teaching to start
with a question.
That question is what drives the
learner's goal.
From that question, the learner
drives internal motivation to
achieve the hard work of
learning the material you're
trying to get across.

Which brings us next, to the
audience.
It is so important that we as
teachers think through the
audience that we're aiming to
reach.

Are they brand new coders?
Do they understand anything with
coding?
Or, are they moderately
experienced and they're trying
to gain more insight into some
particular piece of material?
You need to know who your
audience is and then make your
content communicate to them.
What I often see happening is
people taking syntax and other
things from a computer science
degree in college and then sort
of moving it down to a level so
younger people can understand
it.
So, you end up with this huge
cloud of concepts that you have
to get down, all these syntax
items.

Now, of course, it's very
important that you understand
syntax, you can't code without
knowing what syntax is, so in
Learn to Code, the way we
approach that, is that we build
this engaging world with these
great characters and these silly
animations, and beautiful audio
to engage the learner so that
they'll go through the hard work
of learning what a for loop is.

Here's an example of one puzzle
that we have that takes Byte
around the four sides of this
world, picking up gems.
In order to do that, you of
course use a for loop, and we
have that stated at the top of
the page, but that's not the
goal.

The learner's goal is to pick up
these items and to solve the
puzzle.

And so, we use that goal to
drive an internal motivation to
go and learn what a for loop is.

The next step is often to dive
into something like algorithms
and data structures.

I love all these algorithms.
Half of these names, I looked
and thought, Hmm, I wonder what
that is, and I almost got
distracted from prepping my
slides by digging into what is
Soundex.
So--
I don't know how many of you
have interacted with younger
people, but I doubt very
seriously-- well, many of you
are much younger than me, I
know, but I'm talking about
young learners in school.
How many of them have come to
you with a bucket of integers
and said, "You know, I really
wish you would help me sort
these."
That's never happened.
No one wants to learn about
sorting, they have a goal and
sorting will help them achieve
that goal, so you want to focus
on the audience's goals and then
help them achieve those goals.
So, again back here to Learn to
Code, when we're talking about
algorithmic learning and
computational thinking, or when
we're thinking about using those
concepts to teach people, we
build this content like this
same simple puzzle that we saw
earlier, that's drawing the
learner in to thinking about
what an algorithm is, without
even using the word.
Then, later when we get close to
the end of Learn to Code 1, we
approach this puzzle.
This puzzle is a challenge page
and says to the learner, Hey, go
nuts.
Solve this in any way that you
want to in the most efficient
way that you see possible.
But, this is after a long time
of solving these puzzles where
they start to understand and
think algorithmically, so they
look at this and think, Oh,
there's two diamonds, or there's
two gems, and there's two things
I need to flip.

And, that's just programming the
easy parts.
In the beginning, when I started
programming, I would not have
built the WWDC app, properly.
I wouldn't have made a table
view controller and a cell and a
model.
I would just dump all the code
into the view controller,
because I read MVC when I first
got started, and I had no idea
what that meant.
Modeling is difficult, the
syntax and the algorithms, and
so forth are the straightforward
part.
So, another thing that I notice
that people get bogged down in
when they're thinking about
teaching this stuff is, to focus
on details.
Now, of course, the details,
they're really important.

Several years ago, I thought, I
really want to learn to do 3D
programming.

I've always thought it's really
cool, I love how fast it is, and
the parallel nature of it.

So, I started diving into Open
GL.
Bought a couple of books, and
without question, every one of
those books had this diagram in
it.

So, I'm going to give you a
couple of seconds to look at
this diagram.

Study it hard, there'll be a
test.
Now, here's a picture of a dog
playing with a computer.
Which one did you get more out
of?
So, when you're first getting
started with 3D graphics,
looking at this diagram, it's
very hard to make heads or tails
of it, you might as well be
looking at a picture of a puppy.
Instead, what we want to do, is
focus on fun.
3D graphics is amazing.
If I were teaching 3D graphics,
I would start with fun stuff,
like Byte doing his silly dance,
right?
He's fantastic, this is so
great.
Now, of course, everything in
that diagram-- vertex shaders
and primitive processing and so
forth-- all of that is really
important to getting every
single frame that you see happen
on the screen, onto the screen.

But, you never want to start
there.
You want to start with fun stuff
to get people motivated instead
of bogging them down in details.
Finally, passion.

You, as a teacher, as a
developer, have passion for
particular things.

You love some piece of computer
graphics, or you love to think
about UIKit, or ARKit, or
whatever, and you want to teach
that.
Bring that passion in to how you
approach the teaching.
You want to light the fire of
that passion in the people
you're trying to reach because
that's what will give them the
internal motivation to do the
hard work to learn what it is
you're trying to get across to
them.

I don't even know how to follow
his jokes.
My name is Elizabeth, and I'm a
content engineer, writer, and
storyteller on the Swift
Playgrounds team.

I'm really excited to be here
today, the last session of WWDC
2017 to teach you how to bring
those ideals: goal, audience,
and passion into your Swift
Playgrounds.

So, let's start at the
beginning.
What is a Swift Playground?
Some of you, all our scholarship
students, know intimately what a
Swift Playground is, because you
had to make your own to get
here.
Others of you might have played
with these, might have learned
from one yourself, how the
beginnings of coding.

A Swift Playground is
essentially a collection of
pages, like this one.

You can see on the left hand
side, the prose section.
At the top are the instructions,
the story, whatever concept
you're trying to get across to
your learners.

This is where you're going to
teach them what they're about to
do.

On the bottom, on the right hand
side is the user code section.
This is the fun part where
they're really going to be
creating, manipulating, trying
out what you've taught them.

And then on the right hand side,
the live view.
This is where you're going to
bring your passion to this.
Look how fun this world looks.
I want to dive right in there
and learn how to code in Byte's
world.
It's colorful, it's exciting.

This is where the learner's code
is going to execute, where
they're going to see what
they've created.
This is your point, to get them
interested in whatever it is
you're trying to teach them.
In addition to these collection
of pages that make up a Swift
Playground, there are a few
other features that you can add
to make your experiences really
gripping.
There we go.
One of the first ones is
Cutscenes.
If you're familiar with the
Learn to Codes, then you'll
probably have seen some of
these.
We typically add them at the
beginning of new chapters, or
new sections, to introduce a
concept in a fun, animated way.

These are written in HTML, and
they're a good way to introduce
a new topic before you dive
straight into the code.
Give the learner a sense of
where it is they're going.

You can also add hints to your
playground books.
These are so important for
giving the learner a contextual
sense of where they're going
wrong.

You can do a bit of
introspecting on the learner's
code in order to figure out
exactly what mistake they might
have made, and offer them
tailored help.

It's incredibly engaging to have
software understand what you
need specifically instead of a
one size fits all sort of
experience.
So, use hints.

One thing to keep in mind with
hints is that some learners
really don't like the extra
help, they want to do it
themselves.
So don't put essential
information to solving the
problem in here.
Make these real hints for those
who need them.
If hints aren't enough, you can
also add solutions to your
playground pages.
These are essential.
Think about the first time you
were trying to learn a new
technology.
Could you do it just with
someone explaining conceptually?
Or, did you need to look at a
reference example?
These are so helpful for your
learners that get stuck and
aren't sure of the syntax,
aren't sure how to go on.
The solution gives them that
help they need.

Otherwise they might get
frustrated and leave your
playground book entirely.

You can also add assessments at
the end.
These typically pop up once the
learner has completed the task
that you've set them.
You can also customize these
depending on how your learner
has solved the puzzle.
Maybe you wanted them to use for
loops, but they used repeated
code instead.
Now's your chance to suggest to
them, great job, you completed
the puzzle, but maybe next time,
use a for loop instead.

It's a little bit better of a
paradigm.
Alright. So we're all set,
right?
We know about pages, we know
about assessments and hints,
it's coding time.
Not so. We went ahead to the
drawing board.

Literally.
These are some of my actual
notes in the actual notebook
that I keep when I'm designing
for Swift Playgrounds.
Quick sketches, just getting
thoughts out of my brain onto
the paper.
I might have a thought while I'm
riding the shuttle, or in the
shower, and I just want to get
that down somewhere so that I
can iterate on it later.
Starting out writing code, is a
really expensive way to
prototype.
You might spend weeks getting a
cool working demo ready, and
then show it to a potential
learner, and they are totally
lost, or they think it's boring.

Well, now you're stuck and you
have to redo all of those weeks
of coding work.

Instead, start with cheap
prototyping.
It's just as easy to show a set
of storyboards on a whiteboard,
or in a KeyNote even, to some
potential learners, to some of
your colleagues to get feedback
in that initial stage.
So we're all set now.

We've got the main parts of the
playground book in mind, we
understand we want to start out
with cheap, fast prototyping, so
now let's take those ideals that
Bill taught us about, and put
them into practice.
What is the learner's goal?
I want to take a minute here to
help you separate in your minds
the actual different goals that
are going on.

There's your goal as the author.
What do you want your learner to
get out of the whole playground,
and of each individual page?
Those are separate goals.
Your learner, as well, has a
goal on a per-page basis, and
throughout the whole playground
book.

For example, in Cipher, a
cryptography-focused playground,
we released recently, the
learner's goal is to solve the
mystery over the course of the
pages.

They find this encrypted note
and want to figure out what it
means.

My goal as the author is to get
them interested in cryptography
and give them a few new words,
plain text, ciphertext, just to
spark that interest in a
potential discipline.

So, keep those goals in mind and
figure out how you can make them
intermarry in the best way, to
fully support your learner in
their experience.
So now, let's walk through some
potential goals that you might
have, and that we often use in
Swift Playgrounds on each page.

Completing a task.
This one's probably the most
familiar to a lot of you.

We use this a lot in the Learn
to Codes.
Collect all the gems, flip two
switches, and collect one gem,
place the expert in the right
area.

These are easy for the learner
to understand what you want them
to do.

They have a clear starting
point, a clear ending point, and
these are easy for you to
assess, and offer that
personalized-- those
personalized hints and
assessments at the end.
Experiment.
I love these kind of pages,
because I like to play around
with the code I'm given.
These are a really good way to
introduce learners to something
complex, to give them a sense of
where they're going before they
dive in to the code.
We often use this by showing a
whole big block of code, maybe
new functions the learner hasn't
seen yet, maybe new variables,
even new concepts, and then we
minimize the amount of code
that's actually editable to
them, so they're not overwhelmed
by seeing, whoa, this is a lot
of new stuff.
Instead, they can pick out the
parts.
"I know how to change a color, I
know how to change a radius to
negative."
And, they can experiment, and
have fun with this thing that
they're about to dive more
deeply into.
Practicing a new skill.

I'm hoping you all practice a
new skill right now.
Bill taught us about goal,
audience, and passion, and I'm
reiterating that to you now.
So, that hopefully when you
leave this room, you have those
three concepts in your mind.
Learners won't grok a concept
immediately, the first time.
You might wish they would, but
I'm sure through experience;
think back to when you first
learned a new, complicated
thing.

Could you have written a
definition, explained it to one
of your colleagues immediately?
No, you needed to practice that
skill, to use it in different
contexts so that you can then go
and apply that to some new
place.
So, really important to include
these types of pages in your
playground book.
Think about a concept.

This one is sort of different.
We talk a lot about code and the
learner code on each page, but
often in the Learn to Codes and
the challenges in all of your
playground books, you're
introducing something totally
new.
In the cryptography playground,
I'm introducing all of
cryptography, and there's
complicated words like
ciphertext and key and message.
That's a lot of new information
for a learner to take in.

And, you want to make sure you
give them that space.
To read, understand, and reflect
on what you're telling them.
We have several pages that don't
have any user coding on a page,
because those pages are
concept-heavy.
And, we want to give the learner
that space.
Finally, create.
These pages are awesome.

This is where you really get to
show your skills, show what
you've learned.

We've given you, the author, all
the tools you need, and now the
learner is able to go nuts.

They know how to change colors,
they know how to add functions,
they can make the robot dance,
but they couldn't before.
This is their chance to really
explore, and to feel empowered.

This is why they came to coding.
Why did you all come to coding?
Probably to do something.

To learn something.
To create something.
Keep that in mind, that that's
likely what's in your learners'
minds too.
That they want to create
something.
And so, give them that
opportunity.

Include a wide variety of these
types of pages in your
playgrounds, and you'll keep
your learners engaged,
interested, and excited for
what's coming next.

So, how do we do all of this?
How do we get the learner to
these places?
How to create these pages?
Well, in Swift Playgrounds
itself, you have several prose
tools available to you.
Number one is glossary entries.
These are incredibly important
especially when thinking about
your audience.
Another one of those big,
important points.
Algorithm might be a simple word
for all of you, many of you.

You're coders, you're
programmers, you've been around
the block, and you know what an
algorithm is.
But, a beginner, who's brand new
to coding, that's a difficult
word.
Something they can't just intuit
from reading the rest of your
prose.
And so, offering this glossary
entry, which is triggered in
Swift Playgrounds just by
tapping on that differently
colored word, gives them the
support they need to keep on
with your playground book.
Keep in mind, you, as the
author, are not going to be
there to pop out of the page,
and tell your learner something
when they're having trouble.
You need to communicate solely
via the medium of text.

And so, you want to use all the
tools at your disposal to give
extra help where it's needed,
and support your learner in
their process.
A great way to figure out what
kinds of glossary entries you're
going to need is by user
testing.

Put this in the prototyping
stage when you get some prose
written down in front of
learners, and listen to them.
What words don't they
understand?
What concept did they clearly
not get because they skipped
over a vocab word?
And, include these in your
glossary entries.
It's also worth noting, that, if
you're localizing your
playground, you can add
additional glossary entries in
different localized languages.
So, that if there's something
jargon-y that maybe an English
speaker would understand, you
can offer a glossary entry to
that in another language.

So, keep that in mind.
Take a minute to read this
definition.

You all feel confident about
substitution ciphers?
You could send me a message
right now in substitution cipher
with a shift of 3?
What about if I also gave you
this diagram?
This is much more valuable.
It's helpful to have both,
definitely.
The diagram on its own wouldn't
do it, but just the prose
without this visual, impactful
picture?
Is not going to cut it either.

It's so helpful to have visual
aids in explaining difficult
concepts.

Do keep in mind, that if you add
visual aids, which you can add
in that prose section, right in
the prose, that you want to make
sure they have accessibility
labels, so that your users using
VoiceOver have just as rich of
an experience as those who are
not using VoiceOver.

Here's a wall of text.
Lots of stuff going on here.
Luckily, there's a callout.

I know which part of this I need
to pay attention to.
Right here, new awesome
function.
I'm ready to go.
In a lot of our user testing,
users, no matter what age group,
what experience level, often
skim the prose.

They want to get right into
coding, they don't care about
all the awesome instructions
you've given, you've slaved over
for weeks.
They just want to get in there
and write some code.
And so, support that.
Give people their tl;dr, too
long; didn't read it version, in
the middle so they can get right
in there.

Still, offer them that prose
support, around it.
If your learner does dive right
in, tries out new awesome
function, and it doesn't do what
they expected, they need to be
able to come back and read about
it, and find out what it does.
It's all about supporting your
learner in every aspect you
think they might need support.
Finally, the shortcut bar.

This might not seem like a prose
tool, but it's incredibly
important.

And you, as the authors, have
control over what appears in
this shortcut bar.

This is how your learner is
going to start coding.
This is how they're doing it on
an iPad.
Tapping functions, tapping
keywords.

This is their main toolbox.
So, make it easy to use.
Only include relevant choices.

If your learner's on page tw0 of
your playground book, and you
have functions from page six and
seven in that shortcut bar,
that's going to be exhausting
and distracting.

They're going to have to scroll
through, finally get to the
functions they wanted for this
page, and wonder why they had
all these extra functions in the
middle.

It might even be confusing.
Maybe they thought they needed
to use those other functions.

But, they don't, and now they're
not sure.
And, you haven't gotten your
point across as well as you
might have.
Use concise method names.

This one can be a little tough,
because sometimes the method's
got to say what it's got to say,
but do your best.
The one I have here, "shift word
by," easy, fits on the screen,
and it's easy for the learner to
understand.
Important to keep your audience
in mind here too, in terms of
what kind of vocabulary you're
using in these method names.

Your word choice is just as
important as the concepts you're
leading them through.

And, finally, please provide
common keywords.
We all love autocomplete.

Your learner will love it if
they can just tap "func", tap
"var", tap "if" to put it in
there.
Don't make them type those over
and over.

You want to focus on the
learning, and one of the most
important things about focusing
on the learning is not having
ancillary busyness going on in
your mind of remembering, was it
"func" with a capital F, does
the "var"-- do I need a space
before and after the equals?
Things like that.
You don't want to have to deal
with that, and your learner
doesn't either.
So, just provide these helpful
things in the shortcut bar, and
your learner will be able to
focus on what you really want to
teach them, and that's what
matters.
So, we've talked about the
learner, a lot.

And, that brings us to the
second overarching point.
Who is your learner?
Are they a beginner?
Are they advanced?
Are you writing a computational
biology playground, and showing
it to biologists?
Or, showing it to computer
scientists?
Those people are going to bring
totally different backgrounds
and experience levels.
And, you really need to get to
know your learner and understand
where they're coming from to
provide them the best, richest,
most supportive learning
experience.
I'm going to walk you through
some examples now, of pages from
our playground books where we
had goals in mind, but we also
had to keep our audience
strongly in the forefront.
This is a page from Learn to
Code 3, where we're asking the
learner to add a background
image to the screen.
We say it right there.

Set a background image.
Add it to the screen.
And, that's because this is
targeted at a beginner.
Complete a task-style goal, like
we talked about from before, and
beginner audience.
Set a background image, alright,
I'm primed.

And now, right here, this is how
you do it.
scene.backgroundImage equals
"image literal."
I give the learner the syntax,
because, again, this is targeted
at a beginner who's not going to
have all that far-reaching
computer science knowledge, not
even that far-reaching.
To us, this seems simple.
Everyone knows that
"backgroundImage" is the name of
that property.
But a beginner doesn't.

And since we're all content
matter experts, it's really hard
to put ourselves in the shoes of
a beginner who isn't familiar
with the syntax.
That's why user testing is so
important.
To figure out what kind of
logical leaps you're making,
that your learner needs to be
walked through a little more
slowly.

We then give them extremely
explicit instructions.
Write the syntax we just gave
you, and then choose "image
literal" from the shortcut bar.
Again, we're offering them the
appropriate shortcuts in the
bar, and then choose a
background image.

But, a beginner needs this
support.
Finally, we even offer a
comment.
This is where you do it, this is
where you write the code.

Set background image.
Let's take a look at a page with
a similar goal, completing a
task, but with a totally
different audience in mind.
These are your advanced
learners.
We still have a goal statement,
but it's far more broad.

Use a breadth-first search
algorithm to complete the maze.
There are any number of ways
that I could complete this.
And, I have to have a lot of
knowledge in my brain already to
even understand what that goal
statement means.
We still offer instructions, but
again, they're more broad, more
open-ended.
Start by adding all the tiles to
the queue.
Pop those tiles.
And there you go.

And then, in the user code
section, we just offer an empty
function and ask the user to use
their knowledge that they
already have, that we've taught
them a little bit of, to do
this.
Totally open-ended, overwhelming
for a beginner, but for an
advanced learner, they know what
to do.
They know how to complete this
task, and move on with the page.
What about a different style of
page?
Thinking about a concept.
In this one, we introduce Blink,
related to Conway's Game of
Life, which is essentially a
cell simulator, where cells live
and die depending on how many
neighbors they have around them.
It's a pretty complicated idea,
that can be broken down into
simple rules.
We give the learner a fair
amount of text here, because
we're introducing something
totally new.
And, that's part of our job, is
to explain that in detail, for
those who are interested.
We do have a goal statement, but
it's embedded, and the goal is
just to really understand these
algorithms, to think.

There's no clear end point, no
time where the page tells you
you're ready to move on.

It's up to you, to understand
this, play around with the live
view, which you'll see in a
minute.
And, understand when you're
ready, as the learner.

We still offer this sort of
tl;dr version in the middle.
If you didn't want to read all
that prose at the top, here are
the rules of the simulation.
You can kind of get where you're
going with these.
So, it's somewhat similar
structure to completing a task,
but a totally different learner
goal, and author goal.
And then, finally, we have, kind
of instructions, at the bottom.
They're embedded, again.
Experiment with stepping through
the simulation, which we've
provided on the live view side.
Try it out, and then when you're
ready, go on to the next page to
explore what you'll be doing
with it.

What's the audience of this
page?
Is it advanced?
Beginner? Are they science
students?
Are they artists?
The way you're going to figure
that out is, you have your
target audience in mind, and
then you need to do user
testing.
Find out if this is too
complicated for them.
Figure out what words need to be
defined, what concepts need to
be explained more, or perhaps
less.
Don't underestimate your
audience either.
Is it coding time yet?
We've got all these ideas, we
understand the goal, the
audience.
We know all the parts of the
playground page, backward and
forward.
Surely, it must be coding time
now.
Not yet. I've moved from my
little notebook to my
whiteboard, but that's it.
I have expanded my ideas
somewhat.

I have some prose written down,
I have the coding section, I
have transitions.

Also, in this format, I can talk
to some of my co-workers in the
office.

Hey, Alex, does this make any
sense to you?
What do you think?
Is this a cool idea, Bill?
Would your kids like this?
It's really important to get
feedback from your actual users,
and from your colleagues, your
peers.

This is your prototyping phase,
to figure out what works and
what doesn't.

So, no, it is not coding time
yet.
So, we've talked through goal
and audience, and it's time to
talk about passion.
Passion is so important.

This should be threaded
throughout all your other
playground prototyping and
thinking.
Why are you even doing this?
Why are you writing a
playground?
It's because you're passionate
about something that you want to
share, that you want to teach to
someone else.
If you're not passionate about
what you're writing a playground
about, why are you doing it?
And that, that not passion is
going to show through, and your
learner's not care either.
So, bringing your passion to
this is so important.
How can you do this?
Well, let's take a look at the
live view.
I said this before, this is
where the learner is going to
get to experience their code
running.
This is where they're going to
get excited about creating,
about what they've made.
So, this is your chance to make
that experience as visually
exciting, as auditorily
exciting, as exciting period,
for your users.
Here's Learn to Code, where we
have this adorable character,
this cool, game-style world.
This appeals to a lot of people.
Gets them excited about jumping
into this world and writing
code.
Here's another example of
spirals.
I had so much fun working on
this, I would get totally
distracted trying to de-bug by
just creating cool new spirals
and modifying variables.

That's a great sign.
If you enjoy going through the
tasks in your playground book,
your learners probably will too.
And, on the other hand, if
you're bored by the exercises,
if you wonder why you're
teaching this, how are you going
to get your learner motivated to
go through them either?
You have to be excited about
what you're doing, to bring your
passion to those views.
Here's another cool example,
totally different style.

This is, Blink.
From that page of text you saw
earlier.

We have all that text, but we
also have this rich,
interactive, live view on the
right hand side, where the
learner can play with the
algorithm, they can use touch
gestures to interact with it.
This is the place where passion
can really shine.

So. We have the marriage of
teaching that Bill talked to you
about, and designing that I
talked to you about.
It's so important to keep these
in mind, the teaching aspect,
what you're trying to get
across, and how you're designing
it.

How you're prototyping it.
Who you're talking to for help,
how often you're user testing.

With these two-- when these
powers combine, we are Captain
Amazing Teacher.

So. Get ready for it.
Coding time.
Once you have your prototype, or
excuse me, storyboard figured
out.

Once you've solicited feedback,
talked to your users, talked to
whoever wanted you to make this
playground in the first place,
if it wasn't you.
You've gotten all those things
together, you know what you want
your hints to be, you know what
you want your success messages
to be, how you're going to
assist your learner in all the
best ways.

You've got a storyboard, now it
is time for you to write code,
and make that awesome playground
idea a reality.
And, you don't need me to teach
you how to code.

So, you can probably all say it
with me now at this point, but
the three things to take away
from this presentation are goal,
audience, and passion.
That's right.

And so, with those things in
mind, I say to you all, go
forth, and teach.

If you're interested, the slides
and transcripts and all that
good stuff will be available on
our WWDC website.
There were some related--
awesome related sessions this
year, which have all passed, but
you can watch them online.

And so, thank you all so much
for coming.
I wish you safe travels back to
your homes.
And I can't wait to see you all
next year at WWDC 2018.

Looking for something specific? Enter a topic above and jump straight to the good stuff.