Prototyping: Fake It Till You Make It

Good morning everybody.

Welcome to Prototyping. I'm Jeff Bernstein. I brought along Linda Dong, Julian Missig and Mark Hauenstein from the team. So who is this session for today? Well, it's for developers at companies. Show of hands. Excellent. To be expected. Solo developers.

All right.

People who don't code at all, anyone? All right, great. Very brave of you. And designers, designers? Yeah, all right.

And management types? Sort out you guys, yeah.

So our plan today: We're going to design and prototype an app. We're going to go through the steps we would go through to try something out.

And we're going to show a variety of different prototyping methods. All of this is going to be with a focus on prototyping an experience, not trying out an API or testing out some kind of technical feasibility. So who are we? Who are we to come here and tell you how to make your apps? Oh we're a small secret team at Apple. We work across all of Apple's products.

We explore what new interfaces mean to our devices, operating system and applications.

And we do this by making interactive prototypes every day, sometimes 24 hours a day. So today, you're all very lucky. I'm going to unveil to all of you today a world-changing, disruptive application, and I'd like to show it to you right now.

This is an application to explore and discover artisanal toast on the streets of San Francisco.

Browse for toast that's near you.

Find the top toast in town. Go and get some toast. Share the toast with your friends. Take a picture.

Share it with your friends and loved ones.

Today, I give to you ladies and gentlemen, "Toast Modern." Thank you. Thank you everyone. And it's available now. So go and get it.

Except it's not.

None of this is real. It's just a prototype. So why? Why would we go to the trouble of creating this beautiful, world-changing, disruptive application that is completely fake? Well, this is the picture in most people's head.

I have an idea.

Then, I build my application, and then, step three, profit.

Except, what I see frequently is that people have an idea, they build their application, and somehow they're disappointed by the result.

Maybe the experience isn't what you've hoped for. Maybe it just doesn't resonate with your customers.

And building applications are difficult. You guys know this.

It takes time. It takes money, people, sleep, heartache.

And frankly, it's a lot of typing. So, that's a lot of work for something that you're not happy with in the end.

So instead of going from an idea directly to building your application, we're going to go from an idea to a prototype, and then build our application.

And it's best if we can do that over and over again. The more prototypes we can put between our idea and our application, the better the result is going to be.

And the way that we do this is by beginning with something fake and then gradually adding elements that are more real along the way, sprinkling it with interactivity. So there are two important reasons to prototype I want everybody to keep in mind throughout today.

Number one is to test ideas, to save time and money building the right things for your application. And number two is to get new ideas, to make the experience of your app even better in the end. So how do we do this? It's actually really simple. Make fake apps, show people and learn from their feedback.

Again, make fake apps, show people and learn from their feedback. Do that over, and over, and over again until the experience of your app feels great. So how do we make fake apps? What does that mean? Well, we want to ask ourselves three questions before we begin.

The first one is what needs to be more real? Everything else is going to be fake, but what one element are we trying to explore and get feedback on? The second question is what can we fake? And that's everything else. Everything else will pretty much just be a picture. The third important question is where will they use it? We want to make sure that if we're making a prototype, it's something that we can try out on the device in the place where people will be using it.

So, we've made a fake app; now it's time to show it to people; we want to ask them three questions as we're showing them.

Do you know how to do this one particular thing that we have prototyped? Is it easy to do that thing? And in general, how can we make this better? We want to solicit kind of freeform input on how we can improve our app.

You'd be surprised what interesting things people have to say. So who do we show our fake apps to? Makes sense, the people your app is for. So, if your app isn't for engineers, go and find some people who are not engineers. Don't argue, defend or dismiss. You're not there to debate the pros and cons of what you've prototyped. You're there to get information from people and learn from them. So we've showed some people. We've probably taken some notes. We've probed. We've asked a few questions. Now we ask ourselves three questions about what to do next. What's working in what we showed them? What's not working? What did people did not understand? What did they stumble over or was confusing in some way? And what other ideas does this give us about what we might want to do next? So again, make, show and learn, and we do this over and over again until the experience of our product is great.

Now today, we're going to do that in a few different ways for you guys.

We're going to prototype with pictures, just drawing for the device.

Then we're going to prototype with animation, so we can see how different screens that we've drawn work together. And then we're going to prototype with interaction, so we can see how the entire experience feels in our hand on the device. Now to prototype with pictures, we're actually going to do it in Keynote today.

Keynote is fast, easy and cheap and a lot of you probably already have it on your computer. But in practice, you can use anything that can chop up pictures and draw a few basic shapes.

For animation, we're actually also going to prototype with Keynote, which is a surprisingly sophisticated animation tool. But you can use anything that can move pictures around on the screen over time. And to prototype our interactions, we're actually going to use -objective-C and Core Animation. That's what we use frequently to prototype concepts. And it's actually easier than you think if you're not a developer. If you are a developer, you're going to see us use it in a slightly different way than you might be used to. So, I'd like to recap for you the key features of "Toast Modern," our beautiful, world-changing, disruptive application.

We want to find toast to eat near me, want to find the top toast to eat, post toast, rate toast, and review and discuss toast with my fellow toast aficionados.

These are a lot of toast features. So, we're actually just going to pare it down to talking about the first two, finding top toast to eat, and finding toast to eat near me. To begin the prototyping process, I'd like to ask Linda Dong to come to the stage.

Thanks Jeff.

Good morning. So, to figure out how finding toast in our app is going to work, we're going to begin by making pictures.

So here we start off by drawing just a ton of different sketches to quickly get down all the ideas in our heads for ways we can show nearby as well as top-rated toast. Now, on our team, we always start from hand drawn concepts. I'm going to really emphasize that you guys all do it too if you're not already doing this. There's just no faster or cheaper way to get ideas flowing, to explore a whole slew of directions than through drawing.

And drawing is fun. Like who doesn't want to dream of a ton of crazy disposable ideas. Not you guys, right? And keep in mind. You don't have to be an artist to do this. Maybe your drawings look more like this.

Whatever. I mean don't go showing this to like board meetings or anything, but the point remains that we're trying to emphasize that you should not start prototyping from just a single idea.

You want to explore and understand the whole space in order to figure out the best direction for your app.

So when we were comparing all of our ideas, there were four that stood out as really compelling: this list, grid, map, and gallery.

So why did we choose these four? Well, not only do they convey our type of information really well. They also, unlike some of the other ideas, aren't overly complex or too elaborate. We want to start simple.

Also, they represent four distinct directions that our app can take as opposed to being variations of a single idea. And great, isn't this awesome that we found all of this out super quick on paper before devoting a lot of time exploring just one concept. And so, I've got my sketches and it's no big deal now. They're just sketches, so I can just throw away all the other ideas that didn't work out to just focus on making these four more real.

And to do that, we're going to turn them into some fake apps. So, the first question we're going to ask ourselves is, what needs to be more real? Why are we making these fake apps? What's our goal? So right now we just have drawings. So before we even think about touching any code, we're going to determine how these ideas will look on the screen in our hands.

Second question we're going to ask ourselves: What can we fake? What shortcuts can we take? Well, we can fake pretty much all the content. We don't need a database of toast photographs or locations, we can make up filler text and we're going to use temporary icons.

And lastly, where will we use it? Well, we're going to put these screens on an actual iPhone and use them outside.

So, we're going to start off with the sketch of a toast list view sorted by rating. Now, before we dive straight into translating this to the screen, we're going to see if we can save ourselves some time by borrowing elements from existing iOS apps. And just from browsing on my phone, I've noticed that the music app actually has a really similar structure to our sketch. So let's use this as a way to kind of lay out our idea.

And the way we're going to do that is we're just going to take a snapshot of the screen from our phone and import it into Keynote for Mac.

Now, we on our team use Keynote really frequently to make super quick prototypes because it has a ton of really useful tools that make aligning photographs and images really easy.

But you guys should be using whatever image editing tool you're most comfortable in. So if you've done this type of stuff before, maybe you're in Photoshop or Pixelmator or Sketch.

If you're a developer who's never done image editing before, a great place to start off is Preview for Mac. So we've got our screenshot. What do we do next? Well, we want to block off the main areas of the UI in order to create ourselves a type of template to drop in our own content into. So the way we're going to do that in Keynote is actually open up the Shape Menu and drop in just a ton of boxes to block off the navigation bar, all the photographs, the borders and the background.

So great, now we have a basic structure to work off of.

Next up is to get that navigation bar to be the right color. So to do that in Keynote, you open up the Color Picker, and using that magnifying glass tool, sample the color of the status bar above it. And now we've got ourselves a blank navigation bar. Now, that was really simple, right? Well, that's because we're using a screenshot. So, you don't need to know exact pixel dimensions or even colors of UI elements in order to re-create them, which saves us a ton of time. And so, the next thing I want to do is just add in some content. And in particular, some images.

So, here's some photographs I took this morning on my daily toast excursion, and I'm just going to put in this good looking one. And now that I'm looking at that photograph, I'm thinking, maybe instead of just a plain square thumbnail, we could do something cool where we crop the image to a circle so all you can see is the plate and the toast.

And so, luckily for us, Keynote actually has a great set of options to be able to mask an image to any shape.

So, we're going to choose the Oval Mask here, and now we've got a perfectly cropped plate of toast that we can - yes, thank you guy - that we can put into our placeholder, and we're just going to repeat that same process for other images. Now, notice, we're just using the same three images over and over again, and that's because we don't want to spend more time than necessary creating content. Three pictures of toast for all of your screens, totally fine.

And so, once these images are in place, now we can get rid of those placeholders. And right off the bat, I'm sure you're noticing this, you can't see the plates of toast on that background.

So, how do we fix that? Do we add borders? Do we add drop shadows? Do we change the background image? Like what are the parameters that we use? Well, hold on. Those are all visual design decisions that we can make further down the line if we even decide to go with this direction. For now, we're going to do something super basic and just add in a simple one pixel border around all of our images, and done. We're - it's already more visible. We can worry about the details of it later. And so now I've got my images of toast. I want to label them.

And so to help us out with that, we're actually going to take that white box we were using as a background and make it transparent. So, this way the music app is now peeking through, and we can see how the labels in that screen are laid out in order to help us lay out and size our own text. And now notice, these locations don't exist. You can't get toast with goat butter and trout on it. That's not a thing.

We're just faking text because it's quick and we don't have to worry about it. So, cool, this is actually really coming together.

We just can up the opacity of the background again and make some little tweaks and adjustments so that the layout works for our composition. So, the only thing that's missing right now is ratings.

And so, for this, I'm actually going to go into the Special Characters menu, which some of you guys may or may not be already familiar with.

So here, we actually get a giant list of pre-existing symbols and characters that we could repurpose as icons for our layout.

So, I found myself a really nice star symbol that I want to use to represent ratings. I'm just going to drop a ton of those in, align them together, and we've got some ratings, awesome.

Now, I think this looks pretty OK, but I think those stars could really use a tint color because I want to make them look active later.

So, what particular color you use now doesn't matter.

So, we're just going to go into Keynotes default color palette and choose a color that makes sense. So, here I chose orange because it's the toastiest color of the rainbow.

Great, now I've got some orange stars and they look more active already.

And I really like that color so I'm actually going to change the borders around my image to be the same color.

And now we've got a nice relationship going between the picture of the toast and its rating through color. And so, last but not least, I'm going to add a control to the top right-hand side of this app so that someone can add in a new photograph of a piece of toast.

And here, we could get all fancy with custom shapes, and masking, and doing all sorts of intricate stuff. But remember we only care about temporary icons right now. So instead, we are literally going to add in a text box, type in the plus symbol, and now you've designed an icon in five seconds. Congratulations.

All right, yeah, plus signs, cool. And last but not least, just scribble on a title for your screen, and there you go. One freshly baked screen ready to be tested. Now, one thing to really keep in mind when you're making screens on any program is to remember to zoom out to the physical size of the device that your screen is going to live on. It's really easy to get caught up working at a zoom level where everything is big, and clear, and legible.

So, remember, every time you added a new element onto the screen, to zoom out, and check if that piece of text or that picture is both readable, legible, and tappable, and catch that early on. So, now we've got one screen ready. And that screen took us about 10 minutes to make.

If we were to have worried too much about all the visual nuances that the screen could have, we would be here for the next hour and this would be a really boring presentation.

Instead, we took shortcuts.

And that's fine because these aren't going to be our final screens.

And so, I'm going to rinse and repeat that process of screenshotting, masking, arranging objects, and adding basic content to the rest of our ideas, like our GridView idea, which looks like the camera roll. And in practice, it's like, ah, kind of too much toast. That's a lot of toast to look at. Or our map idea which - I don't know, that looks pretty interesting. I think that would be really fun to play with. Or our gallery weather app idea, which just like looks really cool.

And so, now I've got my four screens, and again they're not going to be our final designs. There're many places where we could refine the visual appearance and/or the styling of all of the screens.

But we're not going to do that because it's OK, because we didn't make these applications to become gorgeous hero shots. We made them so that we could test out how successful each concept will be.

That way when we do devote our time and effort polishing the visuals of our final screen, we'll know we're doing it to the right idea. And so, what's next? Well, we have our screens, we're going to drop them onto an iPhone and give them to people to test out. So, the way we're going to do that is we're going to go back into Keynote and export our presentation into images, and specifically PNGs. And then use whatever method you want to get those images onto your phone. So that might be Photo Stream, the new iCloud drive, or you can just email them to yourself. And then once you've got them on your phone, give them to your friends, give them to your coworkers, give them to a variety of people and just observe them like looking at the screens for right now.

See if they can even figure out what this app does.

See if it reads differently indoors as opposed to outdoors - it probably will.

And then once you've just observed them for a little bit, you want to ask them three questions: "Do you know how to find top-rated toast?" "What about nearby toast?" And the feedback that we got was, "Yeah, ratings, the star icons make it really obvious how to find top-rated toast. But, nearby toast is really hard to figure out if it's not laid out on a map." So, that's really useful information for you to have in order to make iterations of your screen. Second thing you want to ask, "Is it easy to browse through toast?" And it seems that, yeah people are having a pretty easy time reading through all the screens except for of course that grid view that no one likes because it's hurting the retinas. And then lastly: "How can we make this better?" "How can we improve?" And maybe we just got the consensus that, you know, you guys should really go through the list and the Mappy, that seems to really resonate with people. We should probably refine the interactions of those two screens more.

And so, to tell you how to do that with animation, I'm actually going to invite Julian Missig on to the stage. Thank you Linda. Now, that we've gathered some of this feedback, I'm going to take you through another spin around this prototyping cycle.

So, we should take a step back and learn from some of the feedback we got. What's working so far? Well, we have a variety of methods of organizing this information. We have lists and galleries, grids, maps.

We don't yet have one best way to find and discover toast. We have a couple of them.

Sometimes, people seem to prefer to look for toast by rating. And sometimes, they just want to find the closest toast.

So perhaps, our app could let people choose.

Sometimes, people could search for toast by rating, and sometimes they could look for it on a map.

So we'd like to make a prototype to try to understand how this could work.

The thing that we want to make more real in this prototype is the connection between a screen that has top toast and a screen that has a map on it because our app is going to have both of these things in it at some point in time. We don't yet need to make fully interactive screens. We don't need to be able to tap on each piece of toast. We don't need to scroll through these lists. We actually don't even need to have final designs for these screens.

Because, if we're doing things correctly, we're probably actually going to go back and redraw some of these screens based upon what we've learned. As we make a more realistic prototype, we should also make our context a little bit more real.

So in this case, this is not the part of the app where we're in a restaurant taking pictures. We're still trying to find the restaurant we will be at.

So, I'm probably walking around on a busy sidewalk starting to get really hungry looking for a piece of toast to eat. I'm going to be kind of distracted, not paying a lot of attention to my phone.

This means that I'm not going to spend a lot of time trying to figure out how this app works and navigate through it. I'm just looking for those restaurants.

As I was mentioning before, the thing that we want to make more realistic in this prototype is the connection or relationship between two difference screens. At one point in time, this app is going to have a screen that will have Top Toast, the ratings. At another point in time, this app will have a screen that will have Nearby Toast or a map.

So this app is going to be changing over time between these two screens. And a change over time is an animation, right? Now, there are variety of tools that you can use to make animations. If you're a designer, you might be familiar with tools such as Motion, AfterEffects, or Quartz Composer.

If you're a developer, you might use tools such as HTML, CSS animations or Processing. Either way, we think you might be able to use tools such as Hype, iAd Producer or Keynote. As Jeff mentioned earlier, we're going to be building these animations in Keynote.

We can actually run Keynote on our iPhone and see the animations live there. We can make modifications rapidly back on our Mac and see those changes reflected on our iPhone. It's really quick, and it's a tool that we use a lot in our team. So, we're just going to open up Keynote, and we will grab the two slides that we made earlier and drop them in as the only two slides in our presentation.

We will go over to the Animate palette and choose a transition. Here, we'll just choose Move In from Bottom to Top. Let's just see what that looks like.

So, this slide in from bottom to top is perhaps like some of the sheet animations that iOS has where it's some temporary information laid on top of other information.

Maybe let's move out horizontally. Well this looks a lot like the navigate back animation. You're going back up the navigation hierarchy. Maybe we could flip it over.

Maybe this is some kind of setting or information behind that other screen. The thing that I'm trying to get across here is that any animation you choose is communicating something about the relationship that these screens have with one another.

Even if it's no animation at all, if it's just a pop, that's something that shows almost no relationship between the screens. They're just being replaced by one another.

But in this case, that's not really what's going on here. What we have is two different views of the same information. Perhaps those three restaurants that are in the map are three restaurants from that list. So that's something we want to communicate as we transition between these screens. Now, before we get a little bit further within Keynote, I just like to explain something about two different types of animation within Keynote.

The first is called a build animation. These are animations that happen on objects or shapes within a slide.

You can build in a shape, perform some actions on it, build it out.

You can use the Build Order palette to set up a pretty sophisticated sequence of build animations all within a slide. But there's another type of animation called a transition.

And the transition is an animation that happens between two slides. Those were the animations we were just playing with now.

There's a particular kind of transition called Magic Move that's really interesting for our purposes. What Magic Move does, is it tries to identify objects or shapes that are the same on the two slides and it will create an interpolation of the position, sizing, opacity and other properties of those shapes. So for example, if Magic Move identifies the three circles as the same on these two slides, it might produce an animation like this. Now if you're familiar with animation tools, you might recognize, we're starting to use these slides as if they are key frames in a larger animation. That makes it a lot easier to sequence out and separate the different steps of our animation. So we're going to go back to Keynote and choose the Animate palette. Now that you know about Keynote's two types of animation, I'll just note here real quick, if you have a shape selected, the Animate palette will show you Build animations. If you have no shape selected, if it's just the slide, that's when you'll get these transition animations that we're using today. We're going to change the transition to Magic Move.

And without changing anything at all about those two slides that we've dropped in, let's see what Magic Move gives us. So you can see there's already a lot more interesting than the transitions we were playing with earlier. Because we built these slides in Keynote and use the same images on both the lists and the map, the Magic Move transition moved those images over, and we can start to see that maybe those restaurants are the same on those two screens. Maybe that's an interesting way to do this transition. But there are a couple of things that we can make better.

The first thing that I noticed was that, within our prototype, we don't really even have a fake way to get between these two screens. So to make it a little bit more realistic so that we can kind of imagine how you would navigate between these screens, we'll just drop in a tab bar for now. And this tab bar, similar to the things Linda was showing you earlier, is just a rectangle from the Shapes tool in Keynote. The star could be from the special characters, the star shape, and that little map icon, that's just using the Line tool to draw a quick little placeholder. These don't need to be perfect just yet because we don't even know if this is the direction we're going to take.

I also noticed how the list faded out.

We had white for a while, and then the map faded in.

This is because what Magic Move is doing is fading out shapes that won't exist first for the first half of the animation. And then after that midpoint, the second half of the animation is fading in new shapes.

So we can get around that by making sure that our shapes exist on both slides.

So I'm going to copy that map image that I want to fade in throughout the entire duration of the animation. I'm going to copy that from the second slide, paste it on that first slide, move it all the way behind all the other shapes, and then, just for fun, I'm going to make it a little bit larger than it is on the second slide. So, what the Magic Move animation will give us will be maybe a little bit of a perspective shift as the map is shrinking as it's fading in.

Let's see what that looks like. It's pretty neat.

But there are a couple of other things we can do to make this even better. Because right now, we're not writing any code, so we can try out some- maybe over-the-top animations and take them out later, pare it down to just what it needs. But for now, it's so little work to explore a lot of interesting alternatives that we should just try everything we think we might try. In this example here, I am looking at the title of those two slides. The title was another one where we faded out that Top Toast title and then faded in Nearby Toast. Then it faded through gray.

But I didn't really like how that looked. So, I'm going to copy the Top Toast label from the first slide. Paste it on the second slide. Do vice versa so that both of those labels exist on those slides. I'm going to shift the one that should be fading out horizontally off to one side, drop its opacity down to zero. Here I have it a little bit higher just so you can see it. But the effect that it will give is the title will be fading in and sliding horizontally at the same time as the other one is fading out.

I also wanted to do something about those restaurant names in the list.

I didn't like that they just faded out in place.

So I copied those restaurant names from the first slide, that list; pasted them on the second slide, the map; and I shift them way off of the side of the screen. It'll drop their opacity a little bit. So look on a slide out. Now, a little bit of a pro tip here. If you stagger them horizontally a little bit, the animation speeds will be a little bit different for each item. So they will feel like distinct items, not like part of one sheet sliding away, because these are distinct items in a list and we'd like to reinforce that.

Finally, once I've built up both of these slides to the point where I'm pretty happy with them, I will have an animation from the list to the map.

But to get an animation from the map back to the list, all I have to do is duplicate that first slide, that list, and place it at the end as a third slide. And now, without doing any extra work, I have an animation back in the other direction. It's important to test out both directions, and it really didn't take much to do this.

So let's see what we have after we've built up all that animation. In the back. And I'll show it to you a little slower so you can see some of the details. Maybe this isn't as slow as we would have it in the real app.

We did all of this without having to write any code.

And you can see how - maybe some of it is a little over the top. Thank you. Maybe some of it is a little over the top. But it's so much easier to pare down and take away things when you don't have to throw away code. It's just moving shapes around. That's a really great way to try out some really sophisticated animations. We also really like this very graphical gallery view that Linda called out as pretty cool earlier. I wanted to see how it would work if we have these angled plates of toast and we zoom in on one of them just to see a detail view.

And then back out. When we tap the Back button. And I'll show this to you again a little slower.

Thank you So how did we build this animation? Well, it really was not all that different from the process I showed you earlier.

That one piece of toast that we zoom in on? That's an angled image behind all the other shapes.

The other pieces of toast are similar images but they're masked out and on top.

That navigation bar that slides in? That's a black rectangle that we've shifted off the top of the screen. So, we shifted it off a little ways up there so it slides in a little bit later in the animation. And that detail view of the toast? That's that same toast image rotated back straight, made a bit larger. The other pieces of toast are just shifted off the top and bottom of the screen. That's really all there is to it. It's moving some images and shapes around until you get an animation that feels pretty good.

So now that we've built these animations in Keynote, we're going to launch Keynote on our iPod touch here. And either through iCloud or email, however you prefer to get them across, actually open that same presentation in our hand on the device to get a sense for how it feels.

We can hand it to someone and see what they try to do. Now, here you'll notice that we're tapping on what seem like interactive elements. Those aren't actually interactive. It just so happens that you can tap anywhere on the screen to advance a sliding Keynote. So you can kind of pretend that the interactive elements work. Of course, if you tap anywhere else, it's still going to advance the slide.

Or you can still get a sense for where people are trying to interact with your screens and animations and what they expect to happen. We can do a similar thing with the tab bar.

And after we show people and let them express what they think these animations and these screens are about, we can ask them a couple of questions to try to get specific feedback.

So we ask if they know how to find nearby toast. Well, they were able to find toast although they didn't understand our placeholder icons. But that's fine because we knew those icons were placeholders, and if we decide to go in this direction, we can refine them.

When we ask if it was easy to switch between these two screens, certainly they were able to use a tab bar. They've seen those before. They could tap at the bottom and switch screens.

But when we asked, how could we make this better? That's where we got some really interesting feedback. Someone suggested they might want to be able to see restaurant names while they're looking at the map. Another person suggested they'd like to be able to see the map while they're looking at the ratings. Perhaps they want to make their own calculations of highest-rated but closest toast. So those were both really interesting bits of feedback, and I think I'm going to invite Mark up to discuss how we can explore these interactively.

Thanks Julian.

Good morning.

Let's have a look at what we've learned from the feedback so far. What's working? The transitions between the map and the list feel great. Julian showed us how we can do some really cool animations without writing a single line of code. What's not working? We still have to switch between two screens to get to all of the information about toast.

So what other ideas does this give us? Well maybe, we can put the map and the list on the screen at the same time. A list, a map on one screen.

Great. Now we've got all the information accessible on one screen.

Problem solved.

But wait a second. Is this really a good idea? If you think about it, the map is only half of its original size; so is the list. We have to pan the map more. We have to scroll the list more in order to access the same number of information.

To figure out whether it's a right thing, we need to really try it out, and that's why we create an interactive prototype. We make another fake app. And we start off by asking what needs to be more real? Finding nearby toast on the map needs to be more real, and scanning the list for the best toast should be more real. We want to be able to pan the map and scroll the list.

Now, what can we fake? What can we do to speed up our process of making the prototype? We can fake the map and the list by making - using draggable images, but more to - more about that later. And where will we use our app? Let's keep that in our mind while we are creating our fake app. And of course in our case, it's when we walk the streets of San Francisco trying to find the hippest toast in town.

Now making fake apps is really easy.

We are following one principal guideline.

That is, to make pictures move in response to touches.

And one more thing, is to make pictures move in response to touches on the device that you are prototyping for. Use whatever you want that can do this.

If you are from a web background, you could use HTML, CSS, a bit of jQuery.

If you're a game developer who happens to use Unity 3D, it's another great program to make some pictures move around in response to touches. Or, you could use Swift.

We are super excited about Swift. But today, we're going to use Core Animation and Xcode with Objective-C.

This is because that's what we've been using in our prototyping group so far. Quick word about writing code for our prototype: It's different from writing code for a real app. The idea is not to engineer it, just hack it together as quick as you can.

It doesn't have to be good code or reusable code.

Because the idea is that you make your prototype to make a better decision about whether you really want to spend the time engineering the real thing. We generally use three steps to build an interactive prototype.

First step: Put the picture on the device.

Once you have a picture on the device, it's a good indicator that you have got your workflow sorted out. Second step: Break up the picture.

You want to prepare the picture so you can apply interaction to selected areas on the screen.

And third step: Move the pictures when you touch them. This is all about implementing the interaction. All right.

First step: Get the picture on the device.

We create our picture in Keynote.

And the one thing we have to consider is that we work to the actual pixel dimensions of the device.

We export our slides as a PNG and save it into the folder structure of our Xcode project. Now it's time to write a little bit of code. And what you see here is the setup function in a classical screen.

Now, another class that you will see a lot, in our case, is a class called Layer. And for those of you who know about coordination, it simply just inherits from UIImageView. So it also has got all the functionality of UIView. All we did is add a little bit of convenience functions to make our lives easier to position a layer and to load an image into that layer. So by default, we have a Layer called screen. It stretches across the whole of the physical screen.

And so to get our picture onto our screen, we create another Layer called picture and we load our image into it.

That's it.

We press Play in Xcode and here it is.

Our first Fake App.

Looks pretty real already doesn't it? Thanks. All right. Let's get to our second step.

We want to break up the picture.

In our case, we break it up into a navigation bar into an image of a list and an image of a map. Let's start with the list.

I use Keynote again.

And Linda showed how you can really quickly create a fake image of a list. Now this time we want to apply some interaction to the image. We want to be able to scroll the image up and down. So let's make sure that it's much longer than the screen height of our device.

Next thing, we want to create a fake image of a map.

Where do I get it from? We improvise a little bit. I've got the OS X Maps App. I open it up. Make it full screen. Take a screenshot. Put it in to Keynote. And there it is.

We also want to display a few shared toasts on the map.

So, let's sprinkle a few icons onto my toast map.

Just kind of in an artisanal way.

No need to be precise or work with latitude, longitude values. Just get it done.

Again, make sure it's large enough so we can implement some direct behavior on it.

And fast forward, here we have our three discrete images. Now it's time to rearrange the images so they become one screen again. Same type of code, create a Layer called Map, load my map image, position it a little roughly.

Create another list layer - or a Layer called List rather.

And this time, I'm going to position it roughly down half of the screen height. And I realize actually, OK, it already masks my map.

And so does the Navigation bar at the top.

Cool, we are ready to go. Let's make some pictures move when you touch them. Now I want to talk to you about the drag image behavior.

What happens is, you hit the map, a touchdown event happens. Then you move your finger and you get a series of TouchMove events. And on each TouchMove events, we are actually moving the underlying image with it.

And the last event is a TouchUp event. I lift off my finger. Now in order to make that image move, we essentially go into each-- well, within each TouchMove event, we can deduct the data translation between the previous touch position and the current touch position, and that's what we used to move the image.

It probably becomes more clear in code.

So, this is a bit of - this is the code block that gets called every time a TouchMove event happens on our Map layer.

What we do there is we get our touch object. From there, we can retrieve the current touch position and the previous touch position. And we calculate our delta by subtracting the previous touch position from the current touch position and add it to our map position. And we do the same thing for the list. But in this case, we only apply the translation to the y-coordinate because we are just going up and down. Quick look at how it looks like.

Cool, we can drag the map, and we can scroll the list.

Now, we have cheated a bit here. You can see a little bit of inertia, and we're also constraining some movement with some bit of a spring behavior. If you're interested in that, you can download our Xcode project after this session. Let's move on. I want to divert a little bit to the part of our prototype where we can share a toast.

So the idea is that you take a picture of your toast, you add a little bit of information, and then you post it. First thing is I need a camera view. For now, I'll just hide it at the lower edge of the screen. And now, I need a button. But I realized Linda already created a lovely Plus button in my navigation bar.

So what I do is, I hook up a TouchUp event onto my Navigation bar. And so, when you tap that Plus button, it will trigger this line of code which animates the camera image back in.

And this is just an example of how your code doesn't have to be beautiful, but you can just hack things together with what you've got on the screen. Here it is. Tap the Plus button, you see the camera image.

Now, you saw probably that there was a live camera preview.

We added that to add a little bit of realness to it. But that's where we stop. When you press or tap the Shutter button, we switch to a fake image of a toast. And that's what we continue with. You add a few information about your toast and post it.

Now how did we do the keyboard typing sequence? Probably already gave it away.

Of course, we just used a sequence of images. I didn't bother about using any dynamic text fields or a keyboard sliding in.

I did all of these images just from one slide in Keynote.

And this brings us back actually to what we're actually doing.

So, we're creating a prototype by making pictures move in response to touches. And we're doing this to help us make better decisions about whether we really want to pursue an idea.

And part of this decision making process is to show your prototype to people. And if it's an interactive prototype, it's really important that you let people try it out with as little explanation as possible. The first impressions are really important. Look at where people are struggling with the interactions that you created, and also look at what delights them.

And ask some questions like, "Do you know how to find nearby toast or top toast?" So value your feedback is one which is critical. "Is the toast on the map and the list the same?" This is something we didn't really think about when we had our genius idea of putting the map and the list onto one screen. Something we should resolve before we build the real thing. "Is it easy to explore toasts?" is another good question.

And ask for suggestions, "How can we make this better?" "I wish I could sort a toast in a few more different ways." Yeah, it makes sense. Not everyone wants to spend $4 or more for a slice of bread.

By this, I want to reintroduce Jeff to summarize our session and conclude it. Thank you. Thank you, Mark. So, we learned some very important things from Mark's interactive prototype.

Quick recap. Drew a bunch of pictures, then we saw how the pictures worked together using some animations, and then we built an interactive prototype. So, we could see how the whole thing worked together in our hand. Now, a couple of quick comparisons to hit this home. This screen on the right takes a lot of real code. For our prototype, all we did was move a picture around in 2D and move a list up and down. That was really quick.

This grid view of toast would've taken a whole bunch of real code. For our prototype, we just made a quick drawing, which was enough to realize that this concept sucked.

What have we learned today? Well, we prototyped with pictures, and we learned how to take screenshots, mask them and rearrange them so we can make a lot of different options. We prototyped with animations, and we learned how to animate pictures using Magic Move and Keynote so we could see how different screens work together. And, we prototyped with interactions, and we made pictures move on the screen in response to touches so we could see how the whole thing felt together.

Why do we do this? Two reasons, hope that you'll remember. Number one is to test ideas, and number two is to get new ideas. And how do we do it? This one I really hope you guys remember. Make fake apps, show people and learn from their feedback. And do that over and over again until the experience of your app feels great. So here's what I want all of you to go and do now.

If you're a developer at a company, I want you to tell your management that prototyping saves time and money by helping you build the right things. If you're a solo developer, I want you to draw, animate and hack before you go and build something. And if you can't code it all - again, thank you for coming - draw and animate. You don't need code yet, but the person next to you might be able to help you with that part.

Designers, don't just draw pictures, also make animated and interactive things to fully understand your designs.

And our management types, please, go and make time for your designers and engineers to prototype.

Thank you.

There's a lot of toasty code on the web. Go check it out. Thank you very much everybody.

[ Applause ]