All right, good morning. Thank you for coming out on this Wednesday morning. Sorry we had to start so early, but you know, when you're doing design, you got to get going quickly. My name is John Geleynse. I'm the Director of Technology Evangelism here at Apple, and that's my team that put on the iPhone Tech Talks, the Leopard Tech Talks, a couple years ago, the Tiger Tech Talks. We're the guys who take the message from WWDC out onto the road to your hometowns. And so if you think that we need to come to your hometown, let me know.

And maybe we will. But we met some great people on the road. So this morning, we're going to be talking about iPhone. And All of you can attest to the fact that your iPhone is awesome, right? We've all experienced what the iPhone is like because we've got one.

And anybody who's interacted with an iPhone falls in love with it pretty quickly, because it's a very compelling device. And it's not just because of the industrial design, it's largely because the fact that this is a revolutionary device with multi-touch technology and all the other stuff that makes up iPhone, this thing really delivers a great user experience.

What's important here is that as you consider designing for iPhone, as you think about bringing an application to iPhone, that you have a plan. Having a plan means that you're going to aim for something very specific, and that you're going to deliver something really great for your users.

All right. I do want to acknowledge that it's very hard. We've been working on this at Apple for quite a while, and it's proven to be a very difficult task. It's hard to design something that's perfectly suited for iPhone. It's hard to design something that has just the right amount of features. It's hard to do something that is a very specific solution.

It's not the desktop. And so that's where the challenge lies. It's a very unique device. It delivers a very unique user experience. And it's got all kinds of characteristics that determine how you design for it. And it makes it very different. These characteristics make it very different than what happens on the desktop.

Secondly, I want to acknowledge that it takes a lot of time. Designing for iPhone, as I said, we've been working on this a long time. We've had a design team at Apple working on the user interface, the user experience for iPhone for three years, probably more. And if it was more, I didn't know about it. But I only found out about it three years ago.

So we've been working on this for a very long time. We're learning a lot about how to do it, but it takes a lot of time. And we've got a lot of very, very bright designers working on this. And the end result was amazing. But I think the first takeaway for you is you have to assign, you have to prepare, to allocate time to designing for iPhone.

The last thing is, it requires dedication. Designing something really awesome for the iPhone requires dedication on your part. And by that I mean, you have to pull together a team of folks who are dedicated to putting all of their energy, all of their talent, all of their time into this.

It's not something you can do just as yet another platform for your application or set of applications. It's not just, you know, ah, something that you'll work on on the side, yeah, yeah, by the way, we gotta get that iPhone product out of the way. The best results on iPhone are from teams who have dedicated, you know, put a lot of dedicated folks onto the task and worked really, really hard for a long period of time and come up with something really great.

And finally, if you've done all those things, the payoff is huge. I mean, you look at the results that we've gotten in terms of product reviews for iPhone, the customer feedback that we've received, your own experience, you know that iPhone is great. And I think that's the payoff.

And certainly, as I've worked with developers for the last, certainly, well, with iPhone, we started the iPhone Tech Talks last fall. I began working with developers creating web apps at that time. And so probably the last eight months I've been working with a lot of companies designing for iPhone. And the payoff for those companies who did the right thing, who spent the time and did something really great was big.

They felt great about what they have produced. So it's absolutely worth it. So today, this session is all about design. And what I want to talk about this morning is the process that you're going to go through to go from concept to something a little bit more tangible, a little bit more real, and then finally to reality.

All right, so what is that going to require on your part? Well, the first part of what it's going to require on your part is a change in how you do development overall. And I'm saying these comments, all of the comments in this session really come from my experience working with all of the companies that I've worked with over the last eight months for iPhone, and over the last nine years of being at Apple working on interface design for Mac OS X.

The first change you need to make is rethink your development cycle, because the typical development cycle for most companies that I've worked with is there's a very, very small amount of time allocated to design. Now, maybe not that small, but certainly the time allocated to coding is much more.

There's a ton of time allocated to writing code, and the typical experience I've got is I meet with companies who want to get, you know, discuss interface design, and they're all writing code. And there's a great comic strip. I saw one time years ago, and I think I've shared this on stage before, there's a bunch of guys sitting at a computer, at computers, clearly programmers, and the manager's going out the door, and he goes, "You guys start coding, and I'll find out what they want," you know, and he's kind of going out the door.

And so there's a natural tendency among engineers, among all of us, to quickly get to brass tacks and go, "Oh, what's the API," and get going. And the key thing for iPhone, creating something great on iPhone, is to change that and dramatically increase the amount of time that you put in.

So I think that's the key thing that I've been working on. And then I want to make sure that's a part of the process. So I'm going to go ahead and go ahead and talk to you about this. So I'm going to go ahead and talk about this. I'm going to go ahead and talk about this. And then I'm going to talk about this. So I'm going to go ahead and talk about this.

All right, so the process of going from concept to reality is this. We're going to go through these four stages this morning, and I want to explain each one of these in detail. So get ready to take notes. We're going to move through a lot of content really fast.

All right, the first thing to do is to familiarize yourself with iPhone. And this is accomplished by basically living with the device. It is key that everybody who is on your design team spends time with iPhone or iPod Touch. I can't tell you how many times I've gone into meetings where the primary coders have an iPhone because they needed one, or they had one already and they convinced management to do an iPhone product, and the rest of the team is sitting around the table interested in Apple's feedback on what they should do, and none of them have ever really interacted with an iPhone. So it is vital that everybody on your design team have played with iPhone, shared content with it, listened to music on it, received calls on it, browsed the web and experienced what it's like to be on iPhone.

The second thing that's important is to understand the characteristics that make iPhone different. So one of those is the fact that there is no mouse on iPhone. Thankfully, the interaction with the iPhone is through the finger. So it's this multi-touch technology, and it's gestures and tapping on screen get things done. That's very different from what you might have been familiar with designing for the desktop.

For the desktop, you've got, whether it's a web app on the browser, whether it's a native app on the desktop, you've got the mouse tracking the scroll bar. You've got rollover effects that you can do. You've got drag and drop with key, keyboard modifiers, all kinds of things you can do with a mouse. You cannot do those things on iPhone. As soon as you design for iPhone, you need to keep that in mind. That's a big difference.

Another thing to keep in mind, another unique characteristic of iPhone is the fact that you've got an on-screen keyboard, but it's not the same as the primary keyboard you'd have on the desktop. And that changes dramatically how users interact with your application. If you're heavily keyboard intensive on the desktop, you have to change things dramatically to work properly on iPhone, because entering the same amount of data with a finger on an iPhone is not nearly as efficient.

Another characteristic of iPhone development, or characteristic that makes iPhone different, is the fact that the screen size is different, obviously. Things you can get away with, the amount of real estate you've got on the desktop, is not nearly what you've got on iPhone. And while iPhone is a 480 by 320 screen, and it's 160 DPI, it can do a lot of things on this screen, it absolutely limits what you can do in terms of visual design, in many ways. But it doesn't limit it, it just constrains the amount of stuff you can put on screen. It actually, given its characteristics of that small screen, lets you do some really interesting things visually to add richness and a lot of value there.

In addition, the last set of characteristics of the iPhone that are unique are the fact that you've got a camera built into iPhone. This means that you can do things with the camera within your application and let users take photos and do something with them relative to what your application does. In addition, you've got location, so you can add the where variable and think about how the location of your user affects how your application works. Maybe they care about where other users are, this type of thing.

Wi-Fi. Wi-Fi means that you can create Bonjour-enabled applications. Maybe you're a chess game and you can start playing with other players nearby. Maybe you can hook up and exchange information with other users very quickly using Wi-Fi. Bonjour is a great technology for doing this kind of thing, and the fact that your iPhone is always connected means that your application can get data and keep things live and dynamic and interesting for your user in a way that you can't necessarily in a disconnected device. And the last characteristic that's interesting that makes iPhone different from the desktop is the fact that you've got this accelerometer. So you saw some of the demos in Keynote where people were driving Chromag Rally, and the accelerometer lets you do a lot of interesting things with input.

So a lot of characteristics for iPhone that make it unique. A lot of things that you need to consider before you even begin the design process. And that's the familiarization stage. Next stage is to conceptualize. Once you know what the iPhone is, and you know what users are experiencing with it, you have an understanding of what to do.

Now is the stage where you can get going with conceptualization, which is really turning your ideas into reality in many ways, or at least beginning that process. All right, and this is done by defining your solution, defining your feature set, determining what your users are-- how they're perceiving that feature set, and then developing some initial sketches. Let's talk through each of these one by one.

When you begin the process of designing for iPhone, you're going to come from one of two places. You're either going to have a great new idea, or you're going to take an application that's already on the desktop or on the web, and you're going to bring it to iPhone. So let's begin with the new idea.

Let's say we come up with this great idea to do an interior decorating application. So we scratch it on a napkin, and now the question is, well, what are we going to do with this thing? What's it going to do? And so the natural next step is a deluge of features.

And so we can do all things like layout planning. Like for example, I mean, we could do floor plan layout. We could have this app, and we could move chairs around on screen. We could place tables. We could have a palette of furniture on the side and pick things, just like Enigma, the game. You can move pieces out. That'd be a cool feature.

We could do things like paint color coding, and we could manage molding. We could have a molding chooser for kitchen cabinetry. And we could go on and on and on. And there's lots of stuff-- tile management and color management, paint choices, fabric selection, curtain selection, light fixtures, right? And it goes on and on and on. And all of this is great, because you have to start with something. You've got to have this idea, and then you're going to build a really great collection of features that you're going to decide at some point whether or not you're going to keep them or not.

The second way of coming to iPhone is you've got an app from the desktop that you want to bring to iPhone. Now of course you can't port the application to iPhone. The code can certainly move over in many ways. You've seen some examples of that over the course of the week so far. But bringing an application from the desktop to iPhone requires a lot of design applied. So let's take an application that we brought to iPhone and look at that as an example. So this is iPhoto.

Well, iPhoto has a ton of features, right? And if you're bringing an app from the desktop to iPhone, you're going to inherit those features. And the question is, how are you going to decide which ones to put on iPhone? So you either brainstormed an idea, you've got a great idea, and you brainstormed a bunch of features, and you've got a bunch of features over here, or you're bringing an app from Mac OS X, or from Linux or Windows, and you've got, from the desktop, and you've got a pile of features that you inherited.

What are you going to do? Well, I'd like to caution you, first of all, that all of those features are wanted. There's a bounty on them, and we want to pretend that they are, not, we don't want to pretend, we want to go after these features, because that's not what you're going to be building.

You're going to use those features to enhance or augment or help define what your solution is, but that's not where you finish the conceptual design phase. So these features are wanted, and that's not the direction we want to go. So we need to stop at that point, once you've brainstormed or inherited these things, and focus yourselves back on the need to define a solution and not a collection of features. Applications should not be hosts for features.

Well, how do you decide, of the features you've got, how do you decide which ones to bring to your iPhone application? We do that with an application definition statement. If you've been to WWDC before, you've seen me on stage before, you've heard me talk about this for Mac OS X, it's completely applicable to iPhone. The key thing here is that it's important for you to have this statement, a single statement, that defines what your application is going to do.

This statement is going to capture your primary focus. It's going to capture the primary, the core, you know, the core set of functionality that your application is going to bring to the user. And it's going to basically enumerate and define all of those things for you. As well as identify your user audience.

Because it's very different, your application will be very different if it's for pilots, as opposed to teachers, as opposed to presenters, or biologists, right? An application for those four different audiences is going to be very, very different. And you take a thing like iPhoto, and you say iPhoto for amateur photographers, versus iPhoto for professional medical researchers, that's a different application.

So let's go through this exercise. Let's go through this process of bringing iPhone-- sorry, iPhoto for Mac OS X to the iPhone with photos. So iPhoto on Mac OS X has an application definition statement that reads this: "Easy to use digital photo editing, organizing and sharing for casual and amateur photographers." Right? That's a great, succinct statement defining what that application does.

And if you dig deeper into that application, it's got a lot of features, a lot of menu commands, a lot of palettes, a lot of toolbars, and yet it's bundled on the Mac, and most people use iPhoto extensively. Most Mac users spend a lot of time in iPhoto.

And in fact, when you dig down into what they do, because ultimately you're after the core feature set or the core value add that this product provides, turns out that most users of iPhoto actually spend most of their time in iPhoto sharing their content. It's not so much about editing. It's a little bit about organizing, but mostly it's about sharing. Creating full screen previews, so looking at things yourself. Slideshows with music.

Calendars with photos. Photos on it for family members. Coffee table books. Publishing to .Mac gallery. And then photo casting. A big part of iPhoto is sharing. And that in fact is the primary focus for most users within this application. So that's a key point, right? Take your existing app on the desktop and analyze it from this perspective and say, what is the core functionality? What do users spend most of their time doing in this application? And then go to the solution you've defined for your iPhone application, which in this case is Photos, and finalize your application definition statement based on the primary functionality, the core set of capabilities of the application on the desktop. And in essence, it's easy to use digital photo sharing. For iPhone users, that's it. That's all it's going to do, and that's who it's for.

Now at this point, you've got an application definition statement, you're going to start to boil features down. You're going to start taking these two sets of these groups of features, depending on which side of the fence you are, if you're a new app or you've inherited an application, and you're going to run them through that application definition statement, and you're going to pick the key features that are most frequently used by the majority of users that are appropriate for mobile. There's a lot of stuff that a desktop application does that doesn't make sense in the mobile context. It's too complicated.

For example, floor plan layout, CAD functionality. There are certain things you're not going to do on the iPhone, because most people just pull an iPhone out of their pocket or their purse, they interact with it for about 15 seconds, and then they move on to the next application or they put it back and they keep going with their day. And that happens a lot over the course of the day. So everything that you define for iPhone, every feature you consider putting on the iPhone, has to be run through that kind of a filter.

What do most of my users want? What are they going to be using most frequently? And is this appropriate for a mobile context? So let's do that with the feature set for iPhoto. Let's run it through an application definition statement, the one that we created for the iPhone version of this, and let's see what it does to the feature set.

So let's go back to this huge set of features for iPhoto. And you can tell that features don't define the big picture. They don't show you the big picture. They just really are a list of stuff. Now let's bring our definition statement in for the iPhone application we want to create. So digital photo sharing for iPhone users.

Let's move that to the top of the screen and let's filter things through. And what you get is, as you go one by one, you say, is this about sharing? No. Is this about sharing? No. Is this about sharing? No. Is this for iPhone users? Mm, that's not a feature that's going to work in the mobile context, so no. And you just go through one by one by one by one, and what you end up with is a dramatically smaller set of features. Now we're making progress.

And in fact, what we did for photos on iPhone is we created an application that lets you look at albums, drill down into those albums, and then go into full screen preview and either flick through them or start a slideshow with a little bit of music playing and some transitions that you can define. And that's pretty much it, except for the fact that there is a toolbar at the bottom that lets you forward those photos on to someone.

And that's another component of sharing, right? You can turn it into a context photo, you can set it as wallpaper, or you can put it up to .Mac Mobile Me or whatever you're going to do, but it's all about sharing. Every feature of photos on iPhone is about sharing.

Okay, now you've defined your solution, you've got a clear statement about what it is, you've boiled your features down so you've got a much smaller pile of features that you're going to work with. Now the question is, how does the user perceive this solution? What are they thinking of when they consider something like interior decorating? Let's go back to the idea for a second.

Take a moment to think about interior decorating. What pops into mind for you? This is the exercise you need to go through with a cross-functional team of folks in your organization to look at your solution, look at your collection of features, and sort of get a sense for what that's going to be, and then say, all right, how are our users going to think about this? What are immediately what comes to mind for them in terms of objects, tasks, relationships between these things, commonalities between elements on screen, or between these objects and their mental model of what they're trying to build? This is a great exercise that I've told, I have no idea how many companies, I mean, hundreds of companies I've gone through this exercise with.

Just get some pizza, lock people away in a room for three hours on a Thursday afternoon, and say, okay, guys, here's the definition statement. Here's what we're going to build. We're thinking of building sort of conceptually. How do our users think about this? And once you've got this, you're going to end up with a result something like this. So if you think of interior decorating for a moment again, you're going to end up with something most users think of, things like fabrics, paints, wallpaper.

lights, furniture, tiles, right? The next thing to do is ask yourself, what do these things have in common? Because often understanding the commonality of these things is going to get you to the next stage, which is identifying things users are going to do with this. So what do these things all have in common? Well, it turns out color is what they have in common.

It's a great commonality between these objects. And so once you've defined this commonality of color, then you can do an interesting exercise, which is to say, all right, well, what things do you do with color? What things could we do in this application with color? We can organize it.

We can annotate it. We can blend it. We can rate it. We can share it. We could do a community of color palettes, and we could push out certain collections of colors for people to use. Now, certainly, you might not put that in the app, but it's an idea. And so the exercise is to identify primary objects and tasks, understand commonalities between these things, and start to pull these things together and prioritize that list, and decide what is it that you're going to do, which one of those are you going to actually implement.

Great exercise. And of course, the last step is to turn everything that we've gotten so far-- our primary definition statement, our collection of features, our understanding of how the user sees these things-- turn those into some preliminary sketches. So here's the interior decorating application sketches and some interesting stuff there. We've even got some paint mixing going on with the finger. And we've got some paint cans going on over here on the right.

So some great ideas. It's a good place to start. But you've got enough material. You've got enough raw goods at this point to start building something preliminary. And this is where you need to be. And then you can iterate on some of these with what you've got already. And you can end up with something a little bit more solid, maybe a little bit more defined, a little clearer, which is more of a blueprint model.

And at this point, I'd like to invite a company on stage who went through this process in preparation for the launch of the iPhone SDK. We had them on campus, and they worked to develop an iPhone app, and I'd like to invite AOL on stage to talk about their experience.

Thank you, John. Good morning. I'm Todd Branham from AOL. When we first got a hold of the iPhone SDK, we knew immediately we wanted to bring AIM to the iPhone. I've been asked to spend a few minutes to talk about the design process we used. At first, we were really concerned about our schedule, since we were really starting from scratch.

But in retrospect, I think this is actually quite liberating. So the first thing we did was we took a look at our existing AIM product on the desktop. Here's a summary of some of its features. This is just a subset. I'm pretty sure you could send IMs with it as well.

It didn't seem likely that we're going to bring all of these features to the iPhone. And even if we did, it didn't seem like it would make it more valuable. So we started to think about AIM on the iPhone as being an AIM experience away from your desktop. It didn't have to replace the desktop.

What makes the iPhone so amazing to me is the number of tasks I can accomplish while standing in line somewhere, just in a few seconds. So it was important that we kept our application quick and simple. So what features do we really need? We kept it just the basics. A buddy list, conversations, and buddy profiles. Then we took a look at existing applications running on the iPhone to try to identify common UI concepts and paradigms.

Some people have hundreds of buddies on their buddy list. So we considered using the concept of favorites or favorite buddies. So you can have a subset of buddies that are more relevant to you while you're using your phone. Then we again looked at our desktop products and tried to identify how platform differences would change how the user would use AIM. For example, on the desktop, typically a user is asked to manage several windows, a skinny buddy list, or one or more conversation windows.

Then we sat down and started sketching what our AIM application might look like. Doing this with paper and pencil allowed us to quickly and cheaply iterate on our ideas without committing ourselves to a course of action. Using our UI concept document, or our UI concept sketches, we were able to quickly identify the core objects required to implement the UI. Only after we defined our feature set, had a concept UI, and identified our core objects were we ready to start coding.

We spent a lot of time thinking about how to build aim for the iPhone. And what we learned was that building a conceptual model prior to coding really pays off. We learned that we needed to keep our application very simple. and we learned that we shouldn't let existing code or application design direct our thinking. Take this chance to rethink your application for iPhone. Thank you.

Okay, great example, great learning experience for both Apple and for the folks at AOL. So that's the conceptual design stage, and there's a lot to do there, and we haven't started coding. Next stage is to realize. You take your preliminary sketches, you take everything, all these raw ingredients that you've pulled together and you've got a clear direction with, and you're going to turn these things into something real, but you're not going to start coding yet.

So we're going to do this by assessing the application type, your application type, because that's going to do, it's going to give you a direction that you need to go. It's going to help to find a direction you're going to go. The second thing we're going to do in this stage is to develop a navigation model. And thirdly, you're going to design your specific screens. So you see this progression going on. You start big, and you're progressively getting down to more and more detail as you go through this process. So let's begin with application type.

Understanding what kind of an application you've got on iPhone is going to help to determine the behaviors of your application and the appearance of it. Knowing what type of application you've got is going to help to define the visual and behavioral characteristics. This is really important. And I'm not talking about whether you're a design application or a communications application or a social networking application versus a mail application. That's not the kind of application I'm talking about. I'm talking about the genre of application that we've got on iPhone.

There are basically three types of applications. Now, this is not a hard and fast rule. This is just an exercise that helps point you in the right direction. So don't interpret from this that there is, like Apple has defined, three types of applications. We're just saying that at this time, we see sort of clearly-- there are three clearly defined application types, being productivity, utility, and immersive. And there are certainly going to be more in the future, I'm sure. And there are certainly places in between these. And we'll talk about that now.

So the first example is productivity, or first type is productivity. This is the application that you would find on iPhone called Mail. It's a great example of it. Second type is utility. Utility is just like the Stocks app, or just like the weather application, or just like Notes maybe. Notes kind of falls into that realm.

And an immersive application would be something like an Enigmo, which was demoed in the keynote on Monday, or any type of full screen game that takes over the entire screen, has custom UI, and has those kinds of behaviors and appearances. So let's talk more about these in depth.

And the way to do that is we're going to talk through a grid. But understanding the type of application helps you to orient your design. It's going to determine-- you're going to say, I'm more like this kind of an application. And so you can use it as a model for what you do with your preliminary sketches. And it's going to help define the direction that you head.

So let's talk about these application designs with a very, very simple graph. Across the bottom, we're talking about the usage pattern for your application. And on the one side, we've got entertainment. The usage pattern for your application is going to be more entertainment focused, versus the opposite end of the scale, which is that it's more task oriented. It's more tool focused.

And on the vertical, we've got what is the content type that your application works with. Is it serious versus fun? And let's map some of the existing application types to these different quadrants. So the first is Serious Tool, upper right. You're talking about an application that is very purpose driven.

It does or changes something. Users interact with data, and they do something with that data. It's hierarchical in nature. It's multi-window. You've got cascading hierarchy model. And typically, these types of applications have minimal graphics. They're not very rich visually. It's really not about how they look. It's what you can do with them. So that's an application that sits up in the top right.

In the bottom right, we've got a fun tool. What's an example of a fun tool? Well, this could be a social discovery application like Whirl from Pelago. Or it could be something like Looped, or anything that kind of connects you with fun content, but that is still task oriented. And these applications can be visually richer than the serious tool applications, because there are components of their content that are interesting or more visually rich. But they're largely about interacting with the content in a very task oriented way. And they tend to have a smaller information architecture.

Let's go to top left. This is serious entertainment. So the content is serious, but the use case is more entertainment focused. What's an example of this? I don't know. Maybe an application for students that lets them learn about the Civil War or about some historical event with very rich content. Video, photos, you know, these kinds of rich elements. And yet the task is serious, but the content is interesting.

tend to be more visually rich than some of their counterparts. And lastly, bottom left corner, we get fun entertainment. This is the immersive type. This is where you get applications that are very rich visually. They don't really have, from the user's perspective, a complex hierarchy, because the user is focused on gameplay, not on data.

They're just moving through levels, but the screen doesn't seem to change other than maybe the characters or the elements on the screen. Overall, it's not like they're cascading through and navigating through multiple screens. So you can see how each application, or each type of application, has different visual and behavioral characteristics. And understanding which one you're like helps you to model yourself after that type of application.

But there's a middle ground, obviously, because not everything in life is black and white, and so applications don't necessarily land cleanly in any one of these specific quadrants. So what about that middle ground? Well, we still measure it across the same scale, obviously, but that's what we would call the utility type of application, and they have unique characteristics as well.

Some examples of those would be notes, stocks, photos, right? iChat, iPod as well. Some of them sit right on the line between a quadrant, some of them are close to the line. But definitely, the closer you are to a particular axis, it helps to define differences in your application versus something that's much further away from the axis.

Now how do you deal with a utility? What kinds of questions can you ask yourself? Well, here's four that are useful for figuring out where you are within the scale. What does the user do with the application? What kind of work do they do with it? Or don't they do work? Do they play with it more? What content does the application use? What type of information do you display? Is it very rich visually? Is the focus of your application more just kind of finding information at a more leisure pace? Depending on the different scenarios that you play out or that you talk about, you're going to have the dot moving around on that graph.

And that's going to help you determine where you're closer. Are you closer to mail, productivity serious? Or are you more closer to a game style application? These applications are graphically rich, typically, if you think of weather or stocks. They have pretty discrete functionality. They only do one thing, and they do that really well. So discrete functionality, they're narrow in scope, they're consumption oriented, they're largely about just launching the app and looking at something, checking the weather, checking the stocks, checking a flight, arrival time, that type of thing.

So those are the three types of applications. The whole point of this exercise is not to define rigid silos in which you develop, but it is to give you a sense of thinking about iPhone design from that perspective, and understanding which application you're like so that you can orient yourself towards that.

Now, the next step is to determine your development, your navigation model. Navigating through your information is a critical part of designing for iPhone. Understanding how your users are going to get from one level of your application to another is what's called the navigation model. And this navigation model, of course, depends on your application type. If you're a serious tool, like a productivity application, like mail, you're going to go through a hierarchical screen model. If you're a game, the way users navigate is by gameplay. They move through different levels of the game. game, and et cetera.

So, some questions to ask yourself are, what application type are you, first of all? How deep is your object model? How complex is that object model? And by object model, I'm talking about information architecture, right? Behind the scenes, behind the UI, you've got an information architecture that determines which module you're in, what collection you're in, how the objects are organized behind the scene. And the complexity of that object model is going to determine your navigation model as well.

So if you're like a serious tool, a productivity application like mail, you're going to have a navigation model that's very close to mail, if not identical, where you're going to move from screen to screen. And as you move down a branch of your information architecture, right, as you get towards an endpoint, you're going to traverse across screens on the iPhone. So think of how mail works. You start with a mailbox, then you drill down into the mail messages, then you click there, you drill down into the specific message, and that's the end node.

If you're in the settings application, which is what this example comes from, you're starting at the highest level of what groups of settings you are, then you drill down into general, then you get into network, then you choose your network, then you go down to specific things like setting up boot P and other details about the network. So you progressively move down towards an end node of your information architecture branch. So this is a great principle to keep in mind, which is this movement from general to specific as you move down that branch.

Now, as you're doing that navigation model, you're going to have views. And the best way to do this, of course, is to provide for free from UIKit is these nav bars. And navigation bars let you communicate clearly to the user which screen they're arriving at, because they tap an object on screen, and then they traverse to the next screen, and it's named after the item that they tapped. And so you go through the sequence. This is automatic for you if you build an iPhone app with the iPhone SDK.

And as you move back through the levels, the nav bar automatically, as part of the navigation controller, the nav controller object, tells you what the previous screen was named. So you can point back to that from the user's perspective. They know where they're going back to. That's how the navigation works, and that's a perfectly functional navigation model for iPhone applications. But again, it depends on what application type you've got.

A nav bar, we figured out that maybe this is the way we want to do navigation, so now a nav bar is where you're going to put certain types of controls. You can put controls in here that manage the view. For example, in this particular case, we've got the plus button. So you can add, let's say, a contact to the contacts list.

Or you can add, there's different applications on iPhone that have got a plus button there, and you can tap that, and now you can create one of those objects. It's in the nav bar because it's probably something you would do no matter where you are in the hierarchy. It should only be a command related to something that's primary, an object that's really primary. But you can certainly put controls in the nav bar like that.

You can also put controls in the nav bar that relate to managing the view. So if you think of the phone application on iPhone, you have a segmented control at the top that lets you toggle between all missed calls or just-- sorry, in the Recents tab, you're looking at all calls or the recent calls. I'm sorry I said that wrong, but you know what I'm talking about. You all have iPhones.

One thing to avoid when you're putting nav bars on screen is that you have home buttons. So avoid having a home button that's going to jump the user, shortcut the user, all the way to the top of the hierarchy. The problem with this is it's very disconcerting for the user. They've moved down through multiple levels, and mentally they're kind of following the progression. And to jump them all the way to the top makes them lose context from where they are.

Another thing to avoid is any kind of a breadcrumb trail. The main problem with this is you don't have enough screen real estate to do this well. So in this case, I've only got two here, and I've already clobbered the title of the screen. And it's also not a scalable solution, because as soon as you get three or four levels deep, you've got a breadcrumb trail that extends across the entire screen.

So it's not a good idea to do a breadcrumb trail. The navigation controller, the whole hierarchical model on iPhone, is a great model, because users are familiar with it across all applications. And so getting around is not a big deal for anybody. Doesn't matter what application, you know that hitting the back button is going to move you to the previous screen. And lastly, be very careful to not put too many controls in the tab bar.

You don't want to clobber the title. You don't want to make things so cluttered up there that you can't tap things efficiently from a user's perspective. Now, that's the simple navigation model for iPhone, which is the cascading hierarchical screens. But there's an alternative way, which is to use tab bars.

These are for free in UIKit. These are going to mirror the user cognitive model, because if you've come up with an interior decorating application, and you identify these primary objects or tasks you could do with color, those are going to be expressed probably most effectively with a tab bar. So tab bars are great if your information architecture, if the user mental model as well, is oriented around collections or categories or sets of information.

They're not a toolbar alternative. Toolbars sit at the bottom of the screen. I'll talk about this in a moment. The main thing I want to say about tab bars is only use them when you have a complex information architecture, and don't change them when they're on the bottom of the screen. Once you've put them there, they're solid. They should never move, because they're an anchor point for the user to move around within your application and to navigate throughout your application.

They also add a lot of efficiency, because if you think of how the click wheel iPod works, you navigate down, you pick playlists, you click and you navigate through each level. You start with, say, artists, and you go down to the middle screen, and then you choose an artist, and you go down to the song screen, then you play, and you go down. That's how the iPod works, and it's great. But the problem with it is that it gets you through this back and forth navigation model. Now, on iPod, it works because you're not really going down too many levels.

But I've seen applications from developers that are fairly complex medical applications or what have you, and they're going down many, many levels, and this kind of a model doesn't really work, because their information architecture is complex, and it's deep, and it's broad. And it means that users are going to be moving up and down and up and down, and so it's not that efficient.

The better way to do this is to use tabs. This is a great example of where tabs introduce an efficiency to the navigation on iPhone that your application can benefit from. So as soon as you put tabs in, boom, users just go songs, playlists, videos, whatever they're interested in, whatever the modules or categories are of your application, and they're good to go. And they're within that module very quickly.

Another thing to think about in terms of navigation is to get users to the things that are most important to them. Now sometimes they don't know what's the most important to them. It's kind of like retailers put end caps on in the store to say, hey, you really want to be interested in this product.

You walk into the store and boom, there it is. Well, we do that kind of thing in the iTunes store. We're like, hey, here's some new music for you. It's interesting to the user. It's always different. It's always engaging. The same thing is true with your application. It's really important that your application always take the user to what's the most important for them as quickly as possible.

In some cases, you might want to put up some featured content. In other cases, if you launch for the very first time, you could do what the Stocks application does on iPhone, which is the very first time you launch Stocks, it actually has some stock symbols already loaded on screen. Very cool. Do not launch your application with nothing on screen.

And lastly around navigation, keep in mind the fact that your application only runs, it only runs by itself. There's only one app running at a time on iPhone. And so the key thing here is that from a navigation perspective, you want to save state and restore state so that you can bring the user back to what's most important for them as soon as they relaunch your application.

Because you know how iPhone works, right? You're doing something, you get an SMS and you switch over to SMS. You're doing something and you get a notification of an event and you look to the details of where that event is, the meeting is. You're doing something and you get a phone call and then that switches your attention, you switch out the applications and when you come back to the one you were originally working on, you want to be right back where you started.

Or right back where you were, rather than have to come into a home screen and navigate down through hierarchies and this kind of thing. So running one application at a time on iPhone is, directly impacts the navigation model. And so it's important to restore a save and restore state.

And the final point about navigation is that, and I made this comment before, the fact that you've got a built-in keyboard on iPhone, it's a touch screen keyboard, it's not the desktop keyboard. And so you can move users through your application and get them to what they are most interested in much quicker if you minimize text entry. You can do this with lists, a cascade, these are free. We've talked about this extensively. You can do this with, pickers. Pickers are great for multi-values and for constrained sets. They let you just quickly choose times and dates and specify the details of each of those.

And a great way to minimize typing is to use presets whenever possible. So think of where on screen the user is going to be filling out information in your application, and if there's a list that you could pre-populate with all of the options that the majority of your users are going to be interested in.

It's much faster to pick from a list, or slide to another screen to pick from a list, or flick through a big long list of 100 items, than it is to actually type in a city name, or a pharmaceutical drug name, or some kind of molecular name, or whatever. It's very hard to type on an iPhone screen for long amounts of data. Not very hard, but very inefficient.

Segment and controls are part of the navigation model, but now we're really getting down to the nitty gritty, right? We're down to individual screen design almost, and I've talked extensively about segment controls, so I'm not going to belabor the point. They're really mutually exclusive items, and they let you manage what's on screen, or within the body of a screen, they're useful for like a radio button set that you would do on the desktop. All right, and at this point, I'd like to invite another guest on stage to talk about their experience with this part of the process, and that's Handmark.

All right, thanks. Good morning. My name is Doug Dickerson. I run the product management team at HandMark. HandMark is a leading developer and distributor of top quality mobile games and applications. We have a successful history of developing some of the most popular titles on the market today, including household names like TV Guide, Monopoly.

Earlier this year, we acquired Astroware, which really added a lot to our games portfolio. Some great titles like Bejeweled, Sudoku, Casino Games, etc. But our flagship product is Pocket Express. Pocket Express provides users immediate access to personalized news, sports, weather information, and more across a variety of devices, from flip phones to PDAs. And we have several million very addicted users on BlackBerry, Palm, Windows mobile devices.

So the decision to take Pocket Express to the iPhone was really a no-brainer for a couple of different reasons. First, we literally started getting calls the day the iPhone was announced from our customers asking, is Express available? When's Express going to be available? Second, we all fell in love with the device. So last summer, we took turns standing in line, waiting to get the device on day one.

Once we got it, we kind of ignored our families for a couple of weeks and played with the device. One thing became immediately obvious to me, and that was that the bar had really been raised. That it was clear to me that from that point forward, everything our team designed was going to be ultimately compared to the core applications on the iPhone.

So we actually have a lot of experience taking Pocket Express to new devices. And one of the things that we run into every time is we really have two competing goals. That one is we want to create a Pocket Express signature interface across all of the devices. But on the other hand, we want Express to feel like it's part of whatever device it's running on. So what I want to share with you today are some of the challenges that we ran into in designing a Pocket Express experience that feels like it's part of the core set of iPhone applications.

Based on our experience, there's a few tips that I would give you as you start designing for the iPhone. The first thing is to really spend some time studying the core iPhone applications and try to figure out how to relate what they're doing to the problem that you're trying to solve. And then second is to spend the time up front to define all the conceptual objects of your application and how they relate. What's the hierarchy of those? Once you've done that, then embrace tabs as a method of navigating the top level of your hierarchy.

And then when you get to your base level object, if there's more information that you can display on one screen, then use the segmented control to allow the user to kind of manipulate and figure what point of view they want to look at that object. And finally, just keep it simple. So as you're making design decisions, err on the side of making it easy for the first time user as opposed to fast for the power user. Thank you.

All right, thank you, Handmark. Two great examples, AOL and Handmark, of going through this process themselves and learning exactly what it was that they needed to do, and iterating through multiple designs and learning from that process. So at this point now, we're moving through this conceptual, and we're getting down to the brass tacks.

Right now we're looking at, OK, we've got our navigation model in place, and Handmark just explained their process there of realizing how that all works. And now you're down to an individual screen. And I want to give you some guidelines for putting together, assembling those screens. Now you'll notice I'm not talking a lot about immersive applications today.

That's because for games, you have a lot of freedom. You've got the whole screen to take over. And so most games are doing that fine. They've got a great model. It's very unique to this specific game. I want to spend all my time talking about basically the utility type of application and the productivity types of applications, because that's what the vast majority of you are creating.

And that's where the focus is. That's why the focus is on this today. So as we talk about individual screen design, there's a few things to keep in mind. At the end of the day, the entire process of designing an individual screen is all about keeping things clean, clutter free.

It's all about readability. If you pull an iPhone out of your pocket, you're in line like the OL example, and you want to do something for 15 seconds, you don't want to spend a lot of time like flicking around and, you know, what does that say? And there's too much on screen and all these kinds of things.

It's all about readability and quick navigation of the eye on that individual screen, and then navigation model across the entire application. So clutter free design is key. How do you do that? Well, first of all, you need to understand that each screen represents an end node, right? So you have to ask yourself questions like, what's needed for this entity? If we're on this screen, what is the most important thing for this screen? How does this screen map to the solution? Now we had an application definition statement.

We chose our either brainstorm features or inherited features. We boiled those down. We came up with the conceptual model, some preliminary sketches. We build a navigation model. And now we're down to-- it's getting exciting, right? Because we're down to brass tacks. We're ready to code. I can tell you all want to code. And at this point, it's really easy to kind of forget everything that you just went through, to forget the application definition statement.

But you can't, because at this point, you have to keep filtering. Keep filtering your features through what the few features are that the majority of users want, that are appropriate for mobile context, and that map to your product definition statement, and that are exactly what are needed for this object, for this entity on this screen.

This is the hard part, actually. Actually, it's all hard, but this is particularly hard. So review your application definition statement. Keep your features in bounds. Don't go off into a tangent because this screen kind of looks cool, and suddenly now you're adding camera functionality and it makes no sense.

Focus on the purpose of this screen. I'm just saying sort of the same thing over and over so that you drive home the point. Additions to each screen should enhance what's there. Don't add something because there's a little bit of room in the toolbar, and one of the engineers spent a lot of time last night working on something, and so you really want to reward them by putting an icon in the toolbar.

Avoid cramming too much on the screen. Again, think about how what your experience has been with iPhone. You've familiarized yourself with this device. You know exactly how it works and what you love about it. Make sure that whatever you design for iPhone as well fits into that mold, and that other users are going to go, oh, they're using your application. They go, this is what's great about iPhone, this third-party app that they bought.

So does it make sense for something to be on screen? Is it critical functionality? Some other questions to ask. Is it frequently used? Well, let's define frequently. Is it used every time they're on this screen? Almost always? Or sometimes? Or is it just when a selection is made? What's important now from the user's perspective? When I'm on this screen, what do users need to do? Prioritize items most frequently used as well.

As you're laying out these screens, put the most important, most frequently used, definition of important is frequently used, things at the top of the screen. Notice here in the contacts page, this is in the phone application, and so we're looking up a number because we're going to call somebody.

It makes sense that the telephone number is at the top of the screen, because that's the thing we're going to probably most likely, most frequently, most often, most of our users are going to want to get to. If we listed the street address first, what would happen? What would happen in terms of the interaction model for iPhone? Got to phone my friend, look up friend.

Page the screen-- oh, there's the phone number-- and dial the phone number. So think about how the screen is used, what are users trying to accomplish with it, and how can you lay out the data so the most important stuff is at the top. Group related items. This seems obvious, but I can't tell you how many times I've sat down with people and it's like there's a number up here that relates to a number down here, and in between there's a lot of text and stuff, and it's just kind of randomly put on screen. Not the buckshot stuff that we've seen on Mac OS X in past years, by the way, but anyway. So group related items. You can do a great job with group tables on iPhone.

And another part here, broken slide here, is to, another important thing is to eliminate extraneous content. So minimize the number of grouped item titles that you've got on screen. We really only do that in settings. The rest of the time you can tell that it's phone numbers, etc., by the data itself. Provide fingertip size targets. So when you're designing an individual screen, make sure that everything that's tappable is at least 44 points square. That's going to pretty much do it. define what you can put on a given line.

Use standardized built-in controls. We bundle these. They're all part of iPhone SDK. There's a rich set of controls built into UIKit. Some examples of these are here. A lot of them are accessories to the table view object. You can't do them on your own, but you can turn them on as accessory views, and a lot of other stuff that's available. In addition, on this screen, some more examples, and some more examples here in photos. Now notice in photos, the bottom bar, there's only five icons. I'm sorry, that's in mail. I'm looking at mail messages there.

All right, a couple of key little controls I want to talk about very quickly to make sure that we get consistent use of these. The disclosure control, this is the disclosure indicator. It's a single arrow at the end of a row. It tells the user that when they tap the entire row, anywhere on that row, they're going to go to the next screen in the hierarchy. That's the action of that row.

Alternatively, there is the detailed disclosure button, which is the arrow in a circle. And that can live on a row, or it can live elsewhere on your screen. And that, it does a separate action from the host row that it's on in this particular case. And so it just says, if you tap this user, you're going to get more detail for the object on this row, rather than if you tap the row, which does something else.

Goes to the next screen in the hierarchy, or selects the network, or whatever the example is. Toolbars are key. So you've got toolbars here in Mail. This is where you can put commands that directly affect the things on screen. Typically, you're only going to have controls that affect the content on screen.

And as you go through this process of designing an individual screen and choosing the elements you want from UIKit and the standard controls that are built in the iPhone SDK, you're going to run into a dilemma. I guarantee it because I've seen it almost every time I've worked with a company.

And the dilemma is, which control do I use? So I want to talk about the experience that we went through with AOL on one of their screens as it applies to this. So they had a settings page for AIM on iPhone. And the settings page had a username. The question was, well, do we just display the username or do we group it with an icon? Hmm.

They had a buddy icon. Should they put it on the screen or not? They had looked at the context page and they knew that the photo was very useful, but what about it? They had the ability to set online status, but that could be done in multiple ways.

They could do a list. They could do switches. They could group items. There's multiple ways of doing these things. And as you get down to the level of designing a screen, you're going to have to iterate through this process to kind of figure out what's the right thing for your application.

And they wanted to change away settings. So here are these things that they wanted to do. What could they do with it? And that could be done with a predefined list or with a text box. So they came up with a preliminary mockup. And here you could see that they've got some switches up at the top for status, and they've got a text box for status message. Yeah, it's a great first sketch, but it's not quite right.

So next iteration, they went through, they switched to I Interface Builder at that point, started to Mach things up in a way that looked more real so that it felt closer to reality. And here you've got, it looks more like the context page in the phone application. It shows message, and that saves room right below that, you know, the two things are grouped together. You've got grouped status now. And invisibility is separate though. And the question is, should it be?

At this point, I'd like to invite my last guest on stage, Myspace, to talk about their experience designing with some of this stuff.

Good morning, everybody. My name is John Faith. I'm vice president of engineering for Myspace. One of the teams I work with closely on a daily basis is the mobile team. And I'm really excited to be here this morning to talk to you all about our design and development process, and also to be a part of this development community.

So, Myspace Overview, a little bit about our company. We were founded four years ago in Santa Monica, California, with the intent to connect people, content and culture on the web. As one of the early social networking sites, we've seen a lot of growth and success. In April alone, we signed up over 250,000 users a day, had 117 million monthly unique visitors, and had over 50 billion page views.

One of the interesting facts that recently emerged about our company is that 12% of all time spent online domestically is spent on MySpace. We continue to look for growth opportunities, and when something like the iPhone SDK comes out, we get really pumped up, and so I want to talk a little bit about that.

Prior to actually developing for the iPhone SDK, we have launched our own website, m.myspace.com, with the intent of having a ubiquitous solution that is targeted to all carriers and all devices. We did so by paring down the core functionality of a social network, of our social network, and coming up with the core communication aspects of it. And users totally like this. We get over 1.5 million unique users logging into m.myspace.com a day.

But we realized that the iPhone users want a little bit more out of their experience, and so we designed specifically for the iPhone. We came up with something that we believe is natural, intuitive to users. Our real core goal out of this is if you are a MySpace user, and if you are an iPhone user, the first time that you log into our application, you're going to feel like it's home. You know what to press, you know where to go to get your data.

So how do we go about doing this? First and foremost, we came up with our core design mantra. And the primary thing that we concentrated on was understanding our users. MySpace users are a digital generation. They grew up with the internet. They grew up with mobile phones, with digital cameras. And the iPhone really blends the best of all of that together.

Secondly, we streamline the experience. Even from the WAP experience that we create on m.myspace.com, we had to rethink that because this is a different architecture that we're working with here. Third, we've put together some cognitive design into this process. And finally, it is Myspace, it's the iPhone, so we wanted to create a really cool, rich and fun application.

So John spoke a lot about paper prototyping in this presentation, and we were fully on board with this. This is the wall from our Atlanta office where all the design went into our application. I must say that we had a really cool experience with this, and our Atlanta team are rabid iPhone users. So they were the ones that were really into this.

And what you're seeing here is day one of paper prototyping. Day two, we were applying different navigational flow and figuring out how the screens fit together. Also, it gave us the ability to put different standard controls to MySpace features and make sure that you're applying the right control to the right feature set for the intended functionality of your application.

This was all on a wall. It was done really cool. And then finally, within 48 hours, a lot of caffeine later, we were able to come up with our final flow and present that back to product, back to engineering, and really start rocking and rolling on the application itself.

Couple of slides from our application. MySpace has always been about connecting with your friends. What I'd like you to take a look at on this slide is the iconography we're using. This is a friend request slide. Each table row has four different actions that you can do on it. It was very important to us to port over the icons that users are familiar with on our website. And spruce them up a little bit, but really stay core to what you have if you have an existing application or website.

Secondly, MySpace users, check out profiles. What was our challenge here was to basically deconstruct a standard profile on MySpace. If you guys have been on MySpace, you know that there's a lot of information on a profile. So what was correct to port to this application? Finally, what we're really stoked about is the ability to interface with the iPhone camera SDK, and it provided a very easy experience for us to provide the users an experience to upload, snap and upload pictures to their MySpace account.

A couple things that I'd like to leave you all with. Read the human interface guideline. That provided a wealth of knowledge for us before we started coding, before we started designing, and I cannot emphasize enough the importance of checking that out. Secondly, use the UI kit and prototype.

Like I said, by using the standard controls, it really gives you the ability to think about what your application should be and what the UI object hierarchy should be in it. And finally, stay true to the device. The iPhone is a very unique experience, and you want to make sure that you're designing specifically for this hardware and for this SDK. Thank you very much.

Great, thanks John. Alright, let's wrap things up here with one last step in this process. The last step is to finalize. This is where you're going to polish and refine your design and really make it iPhone. Now this isn't the last thing you do at the end of everything in terms of the overall product development.

This is the last stage of the design process, but it's kind of like washing your hair, right? It's like shampoo, rinse, repeat. This entire cycle is going to go back around as you kind of refine and iterate through your design process. But let's talk about the last few things you could do.

At this stage, you need to think about how can you integrate the key characteristics of iPhone that you familiarize yourself with way back at the beginning of the process, and that you may have heard other applications taking advantage of. You can enhance your application with photos and imagery. You can augment with animation. And you can use alternate input mechanisms.

First of all, enhancing with photos and imagery. If you look at the contacts application of iPhone, it is dramatically enhanced by the inclusion of the contacts photo. Why? Because if it wasn't there, the users would have to navigate and read a lot of information. Because if a couple of contacts that shared a name lived in the same area code, you'd have a lot of parallel and duplicity between phone numbers and other things. And so you'd have to get into the specifics and a lot of reading to pick the contact. So adding their photo lets you go, yes, this is Jane Smith. This is the one I want.

Same thing with iPod. We added album art. And album art does the same thing as contacts. You pull your iPhone out, you're like, oh, which-- oh, it's on that album. Yeah, yeah, yeah, that's the one I love, right? Quick recognition, visual recognition. The brain does that far faster than it does processing individual glyphs, turning those into characters, and then turning that into a word.

The same thing is true with maps and real world objects that you can incorporate in your application. Augment with animation. Think about how the iPhone uses animation today, and think about ways, figure out ways to integrate that into your application to augment the user experience of your app.

Animation makes your application realistic, fun, and very approachable, right? And that's what's a big part of the iPhone, is that it's very fun and approachable. Animation adds physicality and realism. It makes the thing feel like it's right there, and you're interacting directly with it. How many times have you sat and pulled like a Safari web page all the way to the bottom and then had it bounce back up, or the opposite? Or I mean, sometimes we just play with our phones this way because of the animation effect and the direct manipulation that's there.

Some examples of where we augment iPhone today with animation are we do it for deleting mail, right? You get the animation effect that's there. We do it for deleting notes. You get the genie effect that goes down to the trash can. We do it for moving mail to folders. Not many people necessarily organize their mail that way, but if you actually go into mail application and move mail to a folder, you see the mail message icon fly to the folder you've selected.

Same effect for purchasing music. You go to download a song and boom, you get a little animation that just, it drives home the point to the user, gives them feedback that the action they initiated is actually underway and was undertaken. We do animation for revealing map features and showing map options. Now this feature, this particular page curl, isn't yet available in the iPhone SDK, but it's a great example of where animation can augment the experience and not detract from the main task.

Yet another example is changing photos. With the multi-touch UI and the gesture, we're also animating that change. So there's this great feel. I mean, that's one of the first things you show someone who doesn't have an iPhone, is you say, oh, check this out. And you go into Photos and you flick through Photos. That's the power of animation and direct manipulation going on.

Same thing with Safari. You choose a page, you want to navigate to a different site or a different page, you just flick and you get the feedback and then it animates forward so you get that scaling effect. It's not these hard, dry changes of state. Animation lets you morph between states. And finally, we do animation for customizing icons.

So all the icons wiggle on the home page to tell you that there's a state difference, you're in a different mode, you can do something different, and yet there's not additional all kinds of new UI and controls and button bars and all this stuff. Just changing state with animation or conveying that to the user is really valuable. So as you consider adding animation to augment your application, be careful to only use it to enhance an existing task or concept. And make sure it carefully clarifies a process and that it gives valuable feedback to the user. Don't animate everything on screen just because it's cool.

Lastly, there are ultimate input mechanisms, which I talked about briefly at the beginning. And they come down to accelerometer for detecting orientation of the phone and doing something interesting with that. Using location to add the where variable to your application, helping your users understand where they are, where other users are, and how that might impact your application. Only do these things if they make sense and augment the experience of your application and its capabilities. Don't do it just because it's cool. And lastly, complex gestures. And I'll finish on this.

This is beyond standard tap and drag. I know that there's a lot of interest in doing some really cool, innovative, new, complex gestures. But I want to caution you to take care with that. Start with the first version of iPhone that's built on everything that's there today, and use the gestures that we have, which is the swipe, and basically it's a drag, and tap.

The problem with creating your own and innovating with your own gestures is that if we come up with a standardized gesture for iPhone S in the future, that does something similar to yours, but it's slightly different, your app is going to stand out as being different from what we've done for that same type of gesture from the user. So only do it if you really, really have to, and if it makes total sense. And there's a great example of an app that was demoed in Keynote, MIM, from MIM Vista, that does some unique things, and appropriately so, I think, for their space.

So that's the last step in this process, and I want to drive home one final point. I made the point that the iPhone development cycle requires a huge design phase. And I hope that you see now that there's a lot to do in terms of design, but the end results of that design process are great.

You're going to come up with something phenomenal, just like AOL did, just like HandMark did with Pocket Express, and just like MySpace did with everything that they learned through the process. So one call to action for you is, make sure that you're allocating enough design time, and you've got dedicated resources, and then get into the coding, then get into debugging, then get into testing to make sure that you've got the right design, and it works exactly the way your users want it to. You need a blueprint, you need a design, you need a plan when you're designing for iPhone, and I hope that you've learned enough today to set a plan in motion, and to aim yourself in the right direction.

One of the best resources for you to go to is the iPhone Human Interface Guidelines. There's some really talented people contributing to that. There's a wealth of resources there and information about how to use specific UI controls, when to use them, when not to use them, and I encourage you to go to that as well.

And lastly, I encourage you to contact me either during the show if you can find me, or after the show, send me an email, and I would love to hook up with you and work with you one-on-one on your application to make it as great as it possibly can for iPhone. You can do this, it's hard work, takes a lot of dedication, a lot of time, but the end result is absolutely worth it. Thank you for coming today.