Hello!

Thanks for being here. 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. So, teaching with Swift Playgrounds. Focus on goal, audience, and passion. And, that's teaching. I'd like to invite Elizabeth onstage to talk through designing Swift Playgrounds. Thank you.

Thank you, Bill. For that awesome introduction. 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. By now, you are probably all, like, I know, background image, I'm good, move on. 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.