Good morning.

Good morning.

I'm Bret Victor, I'm the UI Designer and Engineer at Apple. And next hour, we're going to talk a little bit about UI design prototyping. Now I'm sure that many of you have had the experience where you spend a lot of time working on a piece of code and then someone comes along and redesigns the App and you have to take all that code, throw it out and start over.

Maybe even more of you have had almost the opposite experience where a, great design idea has come up but you just don't have time to rearchitect the App or start over, so you end up shipping something that's not as good as it could be. You have to save the good stuff for Version 2. Prototyping is a way of avoiding both these problems. Allowing you to ship the App that you want to ship and ship it on time. But even more than that, prototyping is a way of coming up with those great design ideas in the first place.

Ideas that take your design in entirely new directions. The word prototyping means different things to different people so we're going to start off with the basics. What is UI prototyping? Why should you do it? And who's involved in the process? So we're going to quickly lay this groundwork and then I'm going to take you over to the demo machine to show you how it's done. Prototyping, prototyping is a skill.

You can't learn the skill just by having someone talk at you; you really have to see it in action. So I'm going to start with a Photoshop mockup of an App, I'm going to start, create an Xcode project from scratch and just build up a prototype on stage to let you experience what it's like to go through that process. Let's get started. What is UI prototyping? Prototyping is a stage of the development process. So let's take a closer look at that.

Every App begins with an idea. You get an idea for an App, you get this vision in your head of what the App is going to be, what it should do. Now for many developers, the next step is to start coding. So you fire up Xcode, you say, what's my class hierarchy?

What's my data model? You get into it and we see this all the time. The problem is that once the developer spends all the time building up this App, they finally get to use it and it doesn't match their initial vision at all. Basically they shot from the hip and they missed.

So we always ask developers: before you start coding, at least draw a picture. And this could be a sketch on a napkin, you can do it in Photoshop or Omnigraphal or Keynote, whatever. The point is you get that vision out of your head into a more concrete form where you can analyze it and still make changes easily.

So this is a good process for some Apps, but other Apps, particularly iPhone Apps, where you're really trying to innovate in the UI, it's not quite enough. And the reason is, it could be very hard to predict from a picture in Photoshop how that App is going to behave when it's in your hand, underneath your fingers.

There's a whole range of both ideas and problems, which only come up when you're actually playing with the App. A further issue here is that frequently these stages are handled by different people. The mockup is created by the designer, who hands it over to the developer to build.

Then when it's finally built, the designer comes up with new ideas, notices problems, but by that time it's too late. The developer has to push back on the designer's ideas and so this can lead to tension on the development team So suboptimal designs and suboptimal team environment, the solution is to prototype. Prototyping is something you do after you draw the visual mockups but before you start coding the App.

And what exactly is this prototype? A prototype is a living mockup. A prototype is a living mockup. Now it's executable. You create it in Xcode, you build and go, you run on the device, but it's closer in spirit to that visual mockup than a fully-fledged App. It's almost a facade of an App.

You implement little bits of UI, just enough to be able to explore them and see how they feel. You don't actually implement any functionality. And I'm going to be showing you plenty of examples during the demo. But first, let's take a look at why you would want to create one of these things. Well there are two main goals of prototyping. Two different goals.

You can prototype because you want to explore the design or you can prototype so you to communicate your ideas to somebody else. Exploring the design is about starting with that Photoshop mockup, finding out what actually works, what doesn't and coming up with new ideas. It's an iterative process and it works like this. You have your prototype in some state and there's some UI element in the design that you want to try out; you want to see how it actually feels. So you just throw it into the prototype as quickly as possible.

Take five minutes, hack something together, that's good enough to let you play with it, understand how it feels. And you try it out. And as you do, as you play with it, you're going to notice problems, things that don't feel right. But we're all smart people and in the course of discovering those problems we're going to think of new ideas.

Those ideas that come up feed back to the beginning.

So we try those out; we see what works, what doesn't, come up with new ideas, try those out and it's this polishing process that allows your App to evolve. Evolve from something that looks good in Photoshop to something that feels really great in your hand.

The other reason to prototype is to communicate your ideas. So say you have an idea for an App and you want to pitch it; pitch it to your boss or your client or investor. There are, there are a few different ways of getting that vision out of your head and into theirs.

The most simplest of course is you can just describe it to them. But this is really ripe for miscommunication. Especially when it's an engineer talking to an investor. What you say is not going to be what they hear and that can lead to disaster. So you can try pitching a static picture. This works really well for static media like pitching a website. But if you're pitching a picture of your iPhone App, you're relying on another person to imagine the behavior of your App and imagine it the same way that you do. And frequently it just doesn't work out.

Ideally you'll just build the App and give it to them right? But the whole point of pitching is to get the approval of the resources to build the App in the first place. So you can't do that but you can do the next best thing, which is to build the prototype.

You take a short amount of time, build something that looks and feels like the actual App but you don't actually implement any functionality. You can give this to the other person, let them play with it, let them understand your idea and you can say to that person, if you green light this project, we will deliver this. We will deliver an App that looks and feels exactly like this. And that is a powerful way to pitch.

So two reasons to prototype, to explore the design or communicate your ideas. In the demo today, I'm going to be focusing on the first one. Focusing on prototyping as a way of evolving your design. But keep in mind of the skills that you learn as a prototyper can also be used for making great demos. Finally, who's involved in this process. Well from a design perspective, there are three types of development teams.

There is the developer or team of developers. May not necessarily have much design expertise and that's fine. Developers can use our human interface guidelines, they can use Interface Builder, they can put together a solid conventional UI. But if you want to innovate in the UI, you really need some design expertise. And frequently, that's in the form of a designer and developer working together.

You also sometimes come across the people who can do it all and that's great. But I'm going to be presenting prototyping today as something that a designer and developer do together. Prototyping is a collaboration between the designer and the developer. Ideally sitting at the same desk, at the same time one in Xcode, one in Photoshop, just jamming together synching up every ten minutes to play with the prototype and discuss new directions.

It's an activity that they do together. So that's prototyping from a really high level Now I'd like to show you how it's done. What we're going to do here is going to have a demo, which will last for most of the rest of the session. I'm going to present you with an idea for a great new App.

We're going to kind of work through the design, our hypothetical designer is going to be giving us visual mockups and we're going to use these mockups as a starting point for the prototyping process. We'll go through that and what we're going to find is that the design we end up with is going to be very different from the design we start with.

So let me tell you about the App that we're going to be designing today. You wake up one morning with an amazing idea. Because you have seen the future of human communication.

You know everyone is talking about Facebook and Twitter and whatnot, but to you that's all old news. You have seen further and you know that soon, everybody will be communicating in the form of LOLcats.

So for those of you who are fortunate enough to be unfamiliar with LOLcats, this is an internet fad which involves finding an adorable picture of a cat, sticking a caption on it in mangled English and that's really about it. So there are dozens of websites devoted to collecting these images. There are tools that allow you to make them more easily, but no one has ever thought of -- until you -- No one has ever thought of using LOLcats as the basis of a chat program. LOLchats.

This is a revolutionary new App that allows you to send a message to friends in the form of cat pictures.

I expect to see five of these on the App Store tomorrow morning.

So you come up with this idea, you're super excited you know, you even do the math, it all works out and,

You decide that you have to go ahead with this idea; that you have to make LOLchats.

So let's do that right now. Let's design this App. Where do we begin. Well the way a lot of people, the way a lot of people approach the design of their App is they start thinking about the functionality. What does the App do? In this case, this is a messaging App right?

So it has to send messages and receive messages. And then you know this kind of leads to thinking okay, sending messages means sending to the, sending data to the server, it's a particular format and our backend has to handle it and it has to use a push notification service and you start spiraling through this technology quicksand.

Where you're thinking more about the implementation than the design. Design is about looking at things from the user's perspective. So you have to back up and you have to say okay, our user, let's even give him a name: Bob. Our user Bob. Bob wants to send a message. Bob pulls his phone out of his pocket, he taps on your App icon.

What does Bob want to see at that very moment? Well in this case, we can take a cue from the other messaging Apps on a phone; SMS, email even making a phone call. What's the very first thing that happens in any of those Apps? You choose the message it's going to because that's the first thing on Bob's mind right? He's thinking, I want to send messages to Sarah.

The first thing he wants to do is put in Sarah. Then Bob wants to compose the message. In this case the message consists of a picture of a cat with some text on it. People often like working back to front. They like to establish the scene before putting objects into the scene so Bob probably next wants to choose his background photo. He wants to choose the picture of a cat.

Then he'll type the message on top of it. Are we done? Well no, because if you look at the quick sketch on the right, the text is in front of the cat's face, it's in the wrong place. So there's another step here, which involves arranging these objects. Now once everything looks perfect, Bob will send it off. So you see what we did here.

We walked through a typical usage scenario from the perspective of a typical user and compiled this list of tasks that the user wants to do in sequence. And this task list forms the flow of our application. This is going to be the backbone of our design. Now for the sake of time today, we're going to concentrate just on the middle three of these five tasks.

We already know what it's like to use People Picker and sending it off isn't very interesting, so we're going to do our prototyping around choosing a photo, typing in the caption and arranging them. So we've determined this flow, we hand it off to our designer, who goes off and does her crazy Photoshop magic and comes back with a design and here's what she gives us.

So this is a 4-page design. What's going on in this first page? Well our designer was saying, okay we're probably going to have hundreds of photos of cats, we need to break them into categories somehow. A good category scheme might be by mood. If you want to send a happy message you tap on the happy icon and you get happy cat. If you want to send, if you're sleepy, you can tap on the tired icon and choose the tired cat. It's a reasonable category scheme. So you see, on the first page we choose a mood, choose a category.

So I flip over to the second page where I have an image browser, choose the image we want. Third page, type in the caption and then on the fourth page we can move them around. That looks like a good starting point for the design. Good starting point. So we're going to go over to the demo machine and start prototyping and see what comes out of it.

Before I get started, before I get started, I want to say I'm going to be throwing code around pretty quickly. It's not critical that you follow all, every line of code. This is more about how to approach a project; kind of how to think about it and there are a hundred other sessions at WWDC about coding so don't get too hung up if you missed a line of code or two. Just try to follow what I'm doing and why I'm doing it.

I'm going to create a new project. It's going to be a Windows based application, which is as bare bones as we can get. Call it LOLchats. Going to drag in a couple of things here. I'm dragging a folder called images, which have the art assets. That our designer is going to be feeding us throughout this process. And I'm also going to drag in a little bit of code called UI View Editions, which have some handy methods for prototyping; I'll show those to you.

There's not, there's not too much here. It's, I'm just adding a constructor to iView called view a parent which is, it creates a view with a super, super, super view and then calling out things like XY with height with explicit properties. The reason being that we're going to be moving views around all the time. That's basically all we're going to be doing is moving views around. So it's helpful to have those called out as properties.

Other than that, there are no tricks up my sleeve; I'm starting from scratch. So,

Let's take a look at the view tree; I'm going to be coming back to this a lot because basically our entire App is going to be constructed in the view tree. Right now there is one view; it is the window. We're going to create a subview called root. This is going to be a subclass of UIView, it's going to take up the entire window and this is going to serve as our, our base of operations.

This is where the action is going to happen. Let me do that. Create a file called root. And it's init method which is called when root is first created, I am going to set it sized to the window size and I'm going to give it a nice red background color just so when I first test it we know it's there.

Open the App delegate, I'm going, and the application didn't finish launching I'm going to instantiate root, as a subview of the window and that is the last time we're going to touch the App delegate. Everything from now on is going to happen in, in the view tree. So here we can see our nice red root taking up the entire window and now we're ready to start prototyping the App.

So where do we begin? Every prototype begins in exactly the same way. Every stage in every prototype begins exactly the same way. The first step is always get the picture on the screen. Take that visual mockup that your designer made in Photoshop and put it onto the device.

And there's a number of reasons why we always begin this way and I will show those to you after we do it. So here in the view tree I'm going to add a subview of root, it's going to be a UI image view, which simply displays a static picture, and we're just going to use the PNG file that our designer gave us for the first page of our four page design. Just simply going to put it on the screen. Over here in root's init method, that is going to be one line of code. We're going to instantiate UI image view as a subview of root. And we're going to set its image to that PNG file.

Build and go. So why do we begin by putting this picture on the screen? There's a number of reasons. One of them is that it is already valuable in this state; we can already learn from it. What you see here looked fine in Photoshop, it looks fine up here in this simulator.

It's not until you actually run on the device and try to hit those icons that you realize that those rows are way too close together. The tip of your finger actually covers almost two full rows and it's really uncomfortable to try to hit those targets. You can't tell that from the static, you can't tell that from the picture on the screen.

You have to see that on the device and try to interact with it. So for the sake of this demo, I'm going to be running everything in this simulator just so it's up on the screen and you can see it. But when you're prototyping, you always run on the device because that's the entire point of prototyping is to see how things feel. So we already discovered a problem here. These are too close together; that is easy enough to solve. Our designer gives us a new PNG which has been spaced out a little more. And we run that on the device.

We try interacting with it and it feels a lot more comfortable. The second reason we always begin by putting the static picture on the screen is that it gives us a starting point to build out the rest of the prototype. We can say, okay, given this, what do we want to explore now? What do we want to learn.

And I think what we want to explore right now is navigating among those four pages. We want to see what it feels like to go from page to page to see if there is any awkward transitions. In a real App, the way that you navigate between pages is you use the UI navigation controller.

But that's kind of heavy machinery for what we're trying to do here. You know it requires a bunch of other view controllers and it instantiates views and requires support objects and configuration and you know we just want to get some pictures on the screen and slide them around.

So the easiest thing is to just do exactly that. Over here in the view tree, I'm going to add a few more subviews of root. So we're going to add one UI image view, one static picture for each page and simply use those mockups that our designer gave us. And we're simply going to slide them around. It's going to look like this.

First page is going to be on the screen and the other views are still in the view tree but still kind of hanging out off the right edge of the window. And then as we page through, we simply slide then onto the window, slide them off the left side. This is not how a UI navigation controller works but it's super easy for us to implement. So we're just going to do it that way.

So here in root I'm going to add one UI image view per page. So now we're just instantiating static pictures for each page in the design. And I'm going to add a property to root called page index; which simply says which page is currently on the screen, zero, one, two or three. We implement that here. Again it's not critical that you follow this code but it's pretty straightforward.

When I set the page index, I do a bounce check. I begin an animation block and then go through each subview, each page, setting its X coordinate to either offstage to the left, offstage to the right or right on the screen. And I'm going to set the initial page to zero. So now we have a property which supposedly slides these views around.

How do we test it? Well it's, there's one really easy way of testing anything which is just throw in the touch handler. So here I'm implementing the touch send method which is called when, when a finger goes up on the device. What we're saying here basically is any time a touch is, happens anywhere, we're going to slide to the next page.

Let's see how it works. So a little initial animation which we can ignore and so here we have our first page and I can say oh I want to see happy cats, tap. I want to see this cat, tap. I'm on this page. Maybe I go to the next page. So we're already sliding through views. We, there's just a little handful of code; we didn't have to mess with controllers.

We're already starting to experience what it's like to navigate between the pages. But what we really want to see here is what it's like to go back and forth. Right now we're just going forth. We want to be able to go back. The right way of course of handling going back is you have this button going up here on the navigation bar but I don't want to deal with putting buttons in the view tree. I don't even want to deal with hit testing.

What's the simplest thing I could possibly do? Well why don't we say that any touch above this line, this horizontal line right here, any touch up in this area will take us back. Any touch down here will take us forward. So root right now is one giant button. I'm basically segmenting it into two giant buttons. And that's easy enough to do. Here end touch is ended. I say, was the touch at the top of the screen? Was it up in that navigation bar?

If it was, I go back a page, if so, I go forward a page. Build and go. You can say, oh let's see. I want a happy cat. I want this cat. Wait, go back, I wanted that cat instead. Go to the next page. Oh wait, go back and change my caption. I can see what it's like to navigate between these pages. I didn't have to set up any controllers I didn't even have to create you know, custom views or anything like that. I'm just using those static mockups that our designer gave us from Photoshop.

So here we can navigate around and see if there's any strange transitions between pages. You know, I'm finding that the transition between this page and this page feels really awkward to me. I think the reason is whenever you have a collection of thumbnails, not just on the phone, but in any context, when you have, you have a collection of thumbnails and you select one of them, you select this thumbnail image, the next thing you always want to see is the full-size image. You know, here I, I'm looking around, I choose my cats, a little picture of a cat.

I tap on it, the next thing I want to see is a nice big cat. I want to see the cat I chose. But instead what I get is almost claustrophobic. I have this big navigation bar up here, a big keyboard here, and a bunch of text in the middle and I can't even see the cat I chose. He's all covered up. So this is, this could be a problem with the design. But at the same time this is not a very faithful prototype of this particular page.

Because when we first come to this page, the text won't be there yet. We'll come to this page, the upper half will be empty and we'll type text into it. So I think we need to understand what it's like to come to this page and add text to it. Basically the static mockup of this page is not cutting it.

So here's what we're going to do. The, third UI image view there, we're going to replace that with a custom subclass of UI image view called caption page. And what I've done here, you know it looks simple, but it's an extremely important pattern and it almost forms the basis of this style of prototyping.

You start out by just slapping static pictures on the screen, putting down UI image views. Whenever you need to dive deeper on one of them, whenever you need to explore more than that static picture is letting you, you pull it out into its own class and that gives you a place where you can add behavior, add methods, add subviews as needed.

So let's do that. We're going to create a new subview of UI image view, subclass of UI image view, call it caption page. Going to add one line of code to its init method, which simply sets its page background to the mockup that we're already using. Over here in root we're going to hook it up, we're going to replace the instantiation of a static picture with the instantiation of our custom class.

Now when we run it, it should behave exactly as it did before. The only difference being that this page now has its own class and we have a space where we can start customizing it. So I think the first thing that we need to do is get rid of this text that, this text is currently baked into the image background and we need, we want to explore what it's like to add text when we're coming to this page.

So we need to get rid of this text that's baked in. We ask our designer for a new image and she hands over a caption page background and here we are. Now we're ready to prototype adding text to this page. How do we do that? Well there's actually no API for directly interacting with a keyboard, so we're going to have to create a hidden UI text view or text field and give it focus, trap changes to that text field. Then we want to render the text in our custom font which means that we have to drop down to core graphics and load a a CT font ref and -- time out.

I have just spent more than 10 seconds talking about technology. If you're prototyping and you spend more than 10 seconds talking about technology, you need to stop, take a step back and say, how can I fake this. It's too much hassle to do it the right way. How can I fake this most easily and simply and still get at the essence of that interaction? How do we fake text rendering in this case? Well that's easy. We turn to our designer, who's looking in Photoshop and you, and we say, can you render me out some, some images please.

I need an image that says I and I can, can has, basically one for each word. So our designer takes 10 seconds, creates these five images in Photoshop, hands them over to you. Over in our view tree on our side, we create a subview of caption page, which is again the UI image view, static picture, which simply cycles through those images that our designer gave us.

So let's do that. Over here in caption page I'm going to add an instance variable for the subview and to keep track of which caption is currently being shown, then in caption page init method, I'm going to instantiate a UI image view but I'm not going to give it an image yet.

That's going to happen in this method expand caption, which simply cycles through the numbers one through five, sets the caption to that particular image and then positions it nicely on the screen. Now how do we test this out? The same way we did before. We just throw in a touch handler. So here's implementing the touch and send method. Any time you touch anywhere it's going to call it expand caption.

Now let's see what happens. So here's my App. I can say, I want to see happy cats, I want to see this cat, I'll type in some text, tap, tap, tap, tap, tap. Now there we go. Fake keyboard, fake text, it's good enough. It's good enough for understanding its interaction.

Why is it good enough? Because we already know what it's like to type on the iPhone keyboard. That's not what we're trying to prototype here. What we're trying to prototype is coming to this page and adding text to it and this hack is perfectly adequate for exploring that particular interaction for understanding what that's like.

So we have to still type a loose end on this page. Right now if I tap anywhere, it's going to expand the caption. We still want to be able to go back and forward, so I'm going to do the same trick I did before. Any touch above this line, any touch up in here is going to take us back and to go forward. How do we go forward from this page. Maybe we didn't think about that during the design. Well let's say for now hitting the return key takes you forward. Maybe we'll revisit that later. So we'll say any touch below this line will take us forward.

That's real easy to do. Here touch is ended. We say what's that touch at the top? What's that at the bottom? Is that the top or the bottom? We call super implementation which passes the event up the responder chain to root, the root does the slide pages around thing that root does, otherwise we expand the caption. It goes like this, I can choose my mood. I want this cat, type, type, type, type, type. Wait go back. I wanted this cat instead.

Change the caption, hit return, I go to the next page, go back. We're really starting to understand what it's like to navigate through this App and this is like you know a couple dozen lines of code. So now let's take a look at this page. The arrange page. The entire point of this page is a custom interaction.

We are, the point of this page is that we can drag the text around. And so the static mockup is definitely not cutting it here. So we need to,

We need to dive deeper on this page and implement dragging this text around. I'm going to do it the same way we did before.

Replace the last UI image view with its own class and moving a little more quickly now, we're going to give it a subview, which is going to be a subclass of UI image view called caption, which is just going to be a static picture that knows how to drag itself around. Let me create the arrange page and over in root I'm going to hook it up. So replacing the picture of the arrange page with an instantiation of our custom class.

Over here in arrange pages init method, I'm going to

Set the background, instantiate this caption class which we haven't created yet and position it next to that on the screen and that's all we have to do there. Now let's quickly create that caption class.

We're going to set its background image and implement some touch handlers. Here's three lines of code to make any view drag-aroundable. Basically saying how much has the touch moved since the last touch and adding that to our current position. Now we can get our hands on this view and drag it around. Let's see what it's like. I choose my mood, choose my cat, type in some text, go to the next page, drag it around.

This is really starting to feel like a convincing App. And again, the point of this process is not to just chug through these steps, but at every point you stop, you play with it, you say, what feels good? What feels bad? What new questions have come up? What can I learn from this? Even something as simple as this. Just being able to drag text around on a background. There's so much that we can learn from this. So, so many ideas come up.

For example, what should happen if I do this? Should it rewrap? Should it rewrap and right-justify? Maybe the text should get smaller. Maybe there should be a slider to make the text smaller. Maybe we could use two-finger pinch to make the text smaller. Just, maybe there should be buttons to change the justification from left to right or maybe, maybe it should snap, like Keynote or Omnigraphal where it snaps to the center or snaps to the edges. Lots and lots of ideas can come up, can come out of just being able to drag an image around on a background.

This happens all the time. But you know what's, what's really bugging me about this right now is the transition between this page and this page. This feels really weird to me. Here we have our text on top of our background and then on the next page we have, we also have our text on top of the background, but it's the same thing but it's in two different places, it's on two different pages. Like the only change here is the keyboard sliding out to the left, which is itself kind of weird. And so this feels really awkward having the same thing on two different pages. So what can we do about this? You know this looked fine in Photoshop.

It's not until we're actually feeling what it's like to navigate between the pages that we notice this awkwardness. You know it almost feels like this page shouldn't even be here. Like maybe we could merge this page and this page. Merge the functionality and be able to arrange things directly from this page.

I mean that might not work because there's this keyboard in the way, but maybe we could get rid of the keyboard somehow, like if there's a button to make the keyboard go down or something. Maybe it could go away automatically. I'm not really sure yet, but the point is this idea has come up. We have the idea of somehow getting rid of this page and merging its functionality into this page.

And when new ideas come up, a prototyper has to jump on them. Has to say, let's try it. Don't get dragged into meetings and talk about for hours whether you should have this page here or not. Just try it out, throw it into the prototype, see how it feels, even if you haven't thought it all the way through.

So we're going to do that. What we're going to do, the last arrange page, we're just going to chop it out and then on the caption page we're going to change its subview to an instance of our caption class, which knows how to drag itself around. We're just going to try that out, see how it feels. So over here in root, I'm just going to get rid of arrange page. I realize I've only created this class five minutes ago; now it's already gone. That's how things go when you're prototyping.

Over here in caption page, we're going to instantiate, instead of UI image view, instantiate the caption class, which knows how to drag itself around. And then over in caption we want to get rid of its initial image so initially it appears blank. So three little changes to the code. Let's see how it feels. Change my mood, change my cat, type in some text and I can drag the text around.

So that seems nice. We still have this keyboard problem right? That we want the keyboard to get out of the way when we start, when we're arranging things. But one of the great things about having a working prototype in this state is you don't have to imagine when would be the right thing, when would be the right time to do this.

You can actually play with it and ask yourself, what are you expecting to happen and when are you expecting it to happen you know, because there's all these possibilities here. Maybe there's a button to make the keyboard go away. Maybe it will go away when I touch down on the text.

Maybe it will go away when I kind of drag the text past the keyboard region. But when I'm actually playing with it what I'm expecting to happen is I'm expecting that keyboard to go away as soon as the text is moved. That's what seems to feel right to me because as soon as I move the text, I feel like I'm in arrange mode and I want the App to respect that. I want the App to say, oh he's in arrange mode now, we're going to get out of his way. So that's my hunch. That's kind of what I'm expecting by playing with this prototype.

Let's try it out, throw it in, see how it actually feels. So over here in caption, we're going to add a method called page, which simply returns the page that the caption's on. Basically casts the super view. Then over here in touch is moved, we're going to simply notify our page that the caption moved and end touch was ended. We're going, if it was tapped, we're going to notify the page that the caption was tapped. Then over in caption page, we're going to pick up those methods.

And when the caption's moved, we want the keyboard to go away and then we also kind of decided to make the keyboard come back, let's say if we tap on the text, the keyboard will come back. Again, there's no real easy way to use the real keyboard, so we're going to fake it. We're just going to rip this keyboard out of the background image and basically give the keyboard its own view and now we're able to slide it up and down and we can pretend that it's the real iPhone keyboard.

So here I'm adding instance variable to keep track of our keyboard that we're adding. Over here in caption pages init method we're going to replace the background with a background that does not have the keyboard baked in and instead add the subview for the keyboard. And then let's implement those messages coming up from caption. When the caption is moved these begin an animation block and move the keyboard down off the bottom of the screen. When the caption is tapped we move the keyboard up to its rightful place.

Let's try it out. So I can say, I want happy cats, I want this cat, type some text in, start dragging it, keyboard nicely gets out of my way; I can put it wherever I want. If I want the keyboard back I can tap on it and the keyboard comes back.

So this is a nice little prototype. This really lets us understand all of the basic interactions of this App. And there's a lot we can learn just from playing with this from just throwing static pictures around and understanding how it feels to transition between them. But you know, let's say our designer's playing with this prototype and something feels kind of off about the entire App. It's, this App seems kind of frontloaded.

You know this is supposed to be a silly, fun App about trading LOLcats right? But you don't actually see anything that looks like a LOLcat until Page 3. You have to make all these decisions first. You have to choose your mood, choose your cat, type in text and it's still kind of all covered up and it's not, the App's not fun.

So let's say we go home for the night. The designer's thinking about this. The designer's going to bed thinking about this and then at two thirty in the morning wakes up with this eureka moment. This always happens to me at two thirty in the morning. So the designer's thinking about how we're prototyping this, we merged those last two pages, we had, it used to be four pages. We had a caption page and arrange page, we consolidated that. We consolidated that functionality to a single page.

And the designer's thinking, well maybe we can do that for all of the pages. Maybe we can consolidate all four of them into one single page somehow. So the designer comes into work the next day all fired up and for the next five hours there's just this crazy whirlwind of Photoshop and proudly presents you, at the end of the day, with the new design. And it looks like this.

So it's all one page. You start off with the picture on the left. You know it already, from Page 1 it looks like a LOLchat, it looks fun. And there's these tabs along the bottom. And you hit the first tab and the mood browser kind of slides up from the bottom and you know, you choose your mood.

And the third page, on the third picture you can see the picture browser slides up and you can, like it's got the sideways dial thing going on. You slide it back, left and right. It changes the background image and if you hit on the caption it brings up the keyboard and you know it's all one page and it looks fun and the designer is super excited about this because we're always super excited when we come up with new ideas. And she's basically saying, let's throw out everything we've done and go off in this complete new direction.

I call this moment the revelation. The moment when someone realizes, you know, our existing design is kind of garbage and here's something completely different that's so much better. And one of the purposes of prototyping is to move the revelation as early as possible in the development process. So when it happens, and if you're lucky, it will happen, you're not throwing out weeks of solid engineering effort.

You're throwing out, you know, you're throwing out a hundred line prototype you run in a day. But even more than that, notice that the idea for this new design came out of prototyping the old design. Prototyping the old design let us both understand the problem with it and gave us a hint to the solution.

When we merged those two last pages, that's what gave the designer the idea to merge all of the pages. So we might throw out that last prototype, but it wasn't a waste at all because it served its purpose of generating ideas. I'm not going to take you through the code for this prototype.

It's the same collection of hacks and tricks I already showed you. I do want to show you the view tree at a higher level because there's a subtle difference in the approach. So we begin this prototype the way we always begin every prototype, which is simply getting the picture on the screen. It's already valuable like that and as you're about to see, it provides a starting point to building up the rest of the prototype. What we do, now in the last design, it was four pages. So we started exploring what it's like to navigate among those pages.

Here it's just one page, but one page with a lot of stuff on it. So the approach we use here is to break it down. We basically say, the stuff on this page, what do we want to explore right now? And let's say it's that funny tab bar on the bottom. We want to know what it's like to interact with that.

So we rip that out of the background image, give it its own view. Now in this case we want to interact with it so we would probably call that out into its own class. We can explore that, learn from it. When we're done with that we'd say, okay, what do we want to explore now?

Well how about this funny mood browser over here. That's supposed to slide up and down when we hit the first tab. So rip that out of the background image, give it its own view, now we're able to slide it up and down when we hit the first tab. Likewise when we hit the second tab, there's that picture browser that slides up and down. We want to see what that feels like.

And of course there's the keyboard which slides up and down when you're entering text. So basically what we're doing here is identifying the moving parts of the design step-by-step and pulling them out into their own subviews so we can move them around. And that forms the basis of our layer tree.

And then any of these we want to dive deeper on, say the photo browser, we'd call that out into its own class. Maybe add subviews to that. Basically just kind of drill down until we reach the level of fidelity that we want; that lets us explore what we want to about the App.

So let me show you this proto. It looks like this. So from Page 1 we already have a LOLchat basically on the screen. Maybe it's the last one that you made; maybe it's the last one that you received. Whatever. It still looks kind of fun. We have this little translucent mood browser I can say I want to see happy cats and it brings up the first happy cat and then I have like this little slidey thing down here.

I can kind of slide down through them and see which one looks nice or I can even kind of tap and go through them one by one. This UI element right here, this control is really important -- kind of the entire design is hinged around this custom control here so this was prototyped with some fidelity.

This was maybe, maybe a couple pages of code to get all the interactions here because the App basically lives or dies by this control. We have to know how it feels. But, so I can like choose the cat that I want and I can tap on caption, the keyboard comes up same fake keyboard, same fake text that we had before, same thing that we learned from the other prototype. When I start moving the text the keyboard goes away and I can go back and switch to this cat instead and drag this around.

That's a fun little App. It's a fun little App. It feels really different than the last design. And you know, playing with it we start realizing this feels kind of like, kind of like a canvas. You know, like a mini Keynote or Omnigraphal where you have, where you're dragging around objects on top of a background and then you have like little toolboxes which pop up from the bottom.

It's a very different feel and when we're thinking in this mode, it kind of gives you ideas. You start thinking, well if this is about dragging objects around on top of a canvas, what other objects might we want to drag around? It's just text block right now, but we could drag out, what else could we drag out? Maybe like little bits of clipart or something.

Like if you could grab a hat and put it on top of the cat or sunglasses or you know, pimp the cat out in gold chains or something like that. That could be fun. That could be cool. And so again, when a new idea comes up, a prototyper says, let's try it. Let's just try it.

So the designer takes five minutes, puts together a grid of random clipart, you know, we take five minutes, five or ten minutes to kind of add another tab down here and we get a prototype that looks like this. So same thing as before except we have this other tab down here called stickers. And again this is all fake. It's one big image, no hit testing no matter where I start dragging from here I'm going to get the cool shades.

But look, I can put the cool shades on the cat,

I can put the text down here. I can say, oh what about this cat and kind of move the shades onto him and say oh the text should be up here instead and change the text.

And now this, this is pretty awesome.

You cannot go wrong with cats in sunglasses.

So this little feature almost transformed the App. It really took it to a new level. It's actually a really cool feature because it allows people to personalize their messages.

If they're sending a birthday message they can like put the birthday hat on top of the cat or whatever. But the point here is that the idea for this feature came out of prototyping this new design. And the idea for the new design came out of prototyping the old design. Prototyping generates ideas.

Prototyping takes your design in new directions. I do this every day and believe me I see this happen constantly. I want to wrap up by quickly going over a little of what we've learned. The approach to prototyping that I've shown you today, always begins with the same first step.

Take that static mockup, put it on the screen. It's already valuable like that and it gives you a starting point for building up a prototype. You can say if this static mockup is not cutting it, what more do I need to add to it so I can really understand the design?

And you add behavior where necessary or you break off smaller pictures from that larger picture, give them their own views and then kind of recursively apply this procedure to those pictures you broke off. You add behavior, break those down if necessary, just kind of keep drilling down until you get the, get to the level of fidelity you need to really understand all aspects of the design. This is one style of prototyping.

It's not the only style, but the style that works really well for a designer and developer working together because it's basically about just taking those Photoshop mockups directly and bringing them to life as quickly as possible. But the, the point that I really want you to remember from this talk is more about the prototyper's attitude; the mindset. The three aspects of that attitude. The first one is enthusiasm. A prototyper says, let's try it.

You're going to be surrounded by people who push back on new ideas or people who want to drag you into a meeting and talk about them for hours and hours. A prototyper's role is to just jump on new ideas, bring them to life and show people whether they're good or bad. If it's a good idea, you've proven it's a good idea. And even if it's a bad idea, frequently that will be the seed from which great ideas will grow. So you always say, let's try it. The second aspect here is faking it.

When you're a prototyper, there's no shame in faking it. If you don't know how to pop up the keyboard you simply grab a picture of the keyboard, stick it in and simply move on. You know when a, when a prototyper is faced with a new challenge, you immediately start thinking, how can I fake this? What corners can I cut?

How can I get to the essence of this idea as quickly and simply as possible. You fake it. And the third aspect here, which sounds a little funny, but is a prototyper has to be brave. You know, we're all trained as engineers and when we're given a problem, we can't help but see all of the work that's required to create a complete robust solution. We can't help but understand all the planning that's required to build out that solution. And it takes, it takes a certain kind of courage to understand the scope of that work and still say, I'm going to implement that feature in the next five minutes.

And I don't even know how. I'm just going to jump in and start improvising. Prototyping is a skill. It's a different skill than engineering. It takes practice. It takes practice to learn the mindset, it takes practice to build up your bag of tricks. I hope that I've shown that it can be enormously rewarding and that what you get out of it are ideas and designs that you just would not have come up with any other way. If you'd like more information, you can talk to Matt Drance, he's our App Frameworks Evangelist or Eric Hope, he's our User Experience Evangelist.