So this session will be a pretty good framework for the rest of the week to figure out, you know, what it takes to create great iPhone applications. And many of you here today, perhaps you already have an iPhone application currently on the store and it may not be doing as well as you'd like or you want to make sure your next applications really good.

Well we will definitely take care of you today. Whereas the rest of you, perhaps you have yet to start an iPhone application or you have started and you're trying to figure out, what's the process, right? What's the best, what are the best steps to deliver something really great? And we'll take care of you as well. Essentially there are 4 critical phases to successful iPhone user interface design. The first phase is the foundation phase and this is where you kind of understand the paradigm shifts that have occurred on the iPhone.

And this kind of like undoes a lot of the status quo that's in your head and lets you innovate and think of new ways of solving problems for a Multi-Touch device. The second phase is product definition. This is probably the most important phase that we'll talk about today and this is where you chart the course for your application.

Where you figure out what it is that you're going to deliver to your customers. The third phase is design and prototype and this phase actually has 3 subphases to it. And in it we'll talk about, you know, understanding the basics of iPhone user interface design and then we'll tackle paper prototyping, which is a really valuable tool to figure out how to work out your application on paper before you touch the tools.

It will save you a lot of time in the end and you'd be surprised at how many of the most successful iPhone applications took the time to paper prototype upfront. And then the last phase is polish and refinement. This is where you take a stable but average application and you turn it into a solid and amazing application. So let's go ahead and get started. Here we have a great quote by Marshall McLuhan, "We become what we behold. We shape our tools and then our tools shape us." And nowhere is this more true than on the iPhone.

The iPhone truly is a revolutionary device. If you think of it as just another Smartphone, you'll miss out on a wealth of opportunities. Finally we have a persistently connected device, a mobile platform inside of our pocket that has an accelerometer, a GPS, a compass now, a camera, a fully featured web browser, every feature that you would need, every input that you would need to make a great application is available to you guys.

All you have to do is dream up the next great thing. But to truly understand the paradigm shifts that have occurred, we need to travel all the way back to 1970. As you know, shortly after we got done with punch card computing we entered the terminal computing age. And this was marvelous at the time. But the problem with terminal computing is that it's very formulaic and verbose by nature. And because of that it's like acquiring a second language.

It isn't approachable by the average officer worker. So along came a great invention called the mouse and the graphical user interface. And the graphical user interface democratized computing. It allowed that office worker who was used to walking over to a physical filing cabinet and rifling through folders and documents and taking them over to their desk, to approach this virtual desktop with virtual folders and virtual files. It was a 1 to 1 knack.

They totally got it. And the only abstraction or the intermediary that they needed to interact with their files and documents, was a mouse which they could just move with their hand and click, right? So it's totally approachable. And as you know over the past 3 years we have matured the graphical user interface on Apple platforms significantly. But when the iPhone was released we changed many of the rules and today we're going to talk about those changes.

With the desktop, we were guaranteed an accuracy of 1 pixel by 1 pixel square and we were restricted to 1 input, 1 point of interaction at a time. Whereas with Multi-Touch, now we have a variable accuracy rate, right? It's between 22 to 55 pixels depending on the size of the person's finger and how they actually use their finger on the screen.

And not only that we have up to 5 simultaneous inputs at a time to keep track of. So a lot of the interaction metaphors that have just been standard fare, expected, yeah that's what we use, are no longer necessarily relevant. The first are scroll bars. Scroll bars, because they're so small on a small form factor device, they're very difficult to interact with physically with your finger. But more than that, they're unnecessary.

If you think about it, when you sit down to a table with a stack of papers, you don't grab some arbitrary control on the desk to move from page 1 to page 2. You simply slide off page 1 to get to page 2 with your hand and now you can do the same thing on the iPhone.

So scroll bars are now more informational then they are functional. Another great change are dropdown menus. They simply do not scale well and still say finger size friendly. And because of this we had to come up with new controls and 1 of those are Pickers. Pickers are great for predefined datasets and they're very tactile.

They're very approachable, which we'll get into more detail in a second. The most important change that's occurred is we've opened up the opportunity for direct manipulation for our users. Now without requiring the intermediary, the mouse, to interact with your data, now that you can use your hands and interact with your data directly, there's a wide array of possibilities that have opened up to you as a developer. Direct manipulation has different flavors and different implementations. We'll talk about 4 right now. The first is tapping for immediate effect. This is very straightforward. Everybody get this, you know, standard fare button.

You tap a button, something happens, right? Or like a whack a mole game, you tap on the things on the screen and they disappear. This is very approachable and this is kind of like the lowest common denominator for direct manipulation. A second type is sequential tapping. We see this a lot on other platforms and usually when a user encounters an application for the first time, they'll do sequential tapping only after tapping and dragging has failed. This is tapping and dragging.

And the reason why this is so approachable and so expectable that 9 times out of 10 the average customer will try this first, is because it maps to the real world. If you think about it, if you had a table and a pencil on the table and you wanted to put it in a cup holder, you wouldn't touch the pencil and touch the cup holder.

You would pick up the pencil and drag it over and drop it inside of the cup holder. So dragging with a Multi-Touch screen is intuitive. It's what everybody expects and it's 1 of the things that your customers will say, this makes it feel like an iPhone application instead of just another application. With that said, you know, not one of these is the one size fits all, end all, solution. You actually have to figure out which one maps to your application most.

Because you can see sequential tapping in our own application for like mail, where we tap a message and then we choose from a folder, that's sequential tapping. We don't actually drag the message into a folder. But there's other examples where it would be relevant. Here we have abstraction, intentional abstraction and you know I just got done expounding on how great it is that we no longer need abstraction but there's certain contexts and genres where abstraction is really important. One of those is games.

If you imagine you had like a shooting game, right, and all you had to do was tap all the bad guys that showed up on the screen? It would be really easy. It would be approachable. It would be intuitive but it would be really easy. It would become very repetitive really quickly, right? So in some of these scenarios you actually want to introduce abstraction.

So by requiring the user to, you know, drag around a radical around the screen, maybe they're using the accelerometer to move the radical and have a separate control to actually fire the weapon, this creates a heightened level of stress. This is something that you wouldn't want to do in a productivity application but it can be the difference between a boring game and a fun game. So you know don't think that one is better than the other, it's just one is more favorable for a certain type of application. So those are the interaction metaphors that have changed, the paradigm shifts that we've seen.

Now let's talk about the design changes, the way things look. As you know on the iPhone we don't have tool tips and we don't have rollover states. That's something that's very tricky to do on a Multi-Touch screen. So we needed a way to visually represent when something's a button.

And many of you may have noticed that the way we tell if something is a button, the way we communicate to our users that something is a button, is by rounding the corners. Anytime you see a rounded corner, most likely that's a button or you know a linear ingredient, some kind of shine, some kind of sense of tactile-ness to it, that usually connotes that something is a button.

And in places like tool bars where we don't round the corner of every single item inside of the toolbar, we use like again texture, depth, right, because we have an inner shadow inside of each of these items and that connotes that even though this bar is glossy, you automatically think this bar is interactive. Each one of these items are also interactive even though they don't have rounding points.

So the take away would be, you know, apply a sense of depth, texture, weight, lighting, to any element that you want to feel compelling or tappable to your users. So that was the foundation. Super straightforward, it's just nice to get it out of the way and you know kind of like get you to think in a new direction for the iPhone visually.

Now let's talk about product definition. For most platforms the development cycle is comprised of maybe 5 or 6 percent being design and usually that time is spent up front. Whereas with the iPhone, we recommend at least half of your time be devoted to design. Many of you might be thinking, I'm an engineer, right? I'm not a designer. I don't make things look pretty in PhotoShop all day.

So this half is something I'm either gonna relegate to somebody else or I'm just gonna skip. But when I'm talking about design, I'm referring to the process of scoping out your application, figuring out your hierarchy, mapping out the flow, figuring out the objects, all the things that most engineers enjoy. So when I say design I'm not just talking about drawing things or making things look pretty. I'm talking about being intentional. No one manufacturers an object that you buy in the real world without taking a lot of time to design it up front.

You don't build a house without laying out blueprints. No one builds as they go. And yet on so many other platforms that's the way people approach software development. So to illustrate this, today we're going to look at a tried and true example, we're gonna take iPhoto on the desktop and show you its conversions to photos on the iPhone.

Invariably every single feature starts out with a long list of nice to have features. And the problem with this is you end up building a container and shoehorning features into that container. And it doesn't necessarily take care of all of your customers, everybody has a pet feature that they want and everybody is just kind of like lackluster about the eventual product that this produces.

So it's important to remember that your goal is to define a solution and not a collection of features. The very best applications on the iPhone are those that solve a problem for a customer. And one of the best ways to make sure that you accurately define a solution instead of just creating a container, is by crafting an application definition statement. An application definition statement is comprised of three distinct parts. The first part is your differentiator.

This is what's going to set your application apart from all your other customers. Whether it's you know easy to use, visually robust, whatever, this is what you're going to use to make your mark. It's what you do special with your solution. The second component is your actual solution.

What problem are you going to solve for me as the customer? And the final component is your intended audience. And it's really important that you be as precise as possible about who your intended customer is. If your intended customer were a traveling businessman and he spends most of his time inside the airport, then you'd want a very monochromatic, you know, very productivity oriented, scalable, clean application.

But if your intended audience was a fireman and his context is a burning building, you're gonna use, you know, honking buttons that say locate my teammates, locate me or whatever, with overly saturate colors. So identifying who your intended audience is is supremely important in figuring out what your application is going to look like in the end.

So here we have the application definition statement for iPhoto on the desktop, easy to use, digital photo editing, organizing and sharing for casual and amateur photographers. You can see that easy to use is our differentiator. This is what's gonna set iPhoto apart from competitors. It's easy to use.

And we have three solutions inside of this ADS, digital photo editing, organizing and sharing and our intended audience are casual and amateur photographers. And as small as this application definition statement is, that long list of features that you just saw were all the features required to implement this application definition statement. And this is the UI necessary to implement those features or those solutions and as you can imagine most of these would not map well to the iPhone.

It would be very difficult to make these finger friendly. But more than that, when looking at our customers, looking at our users of iPhoto, of the three solutions only one was prime, only one was core to all of our customers. For instance, organizing, everybody loves that their photo -- they want their photos to be organized but very few people actually take the time to organize their photos.

Most people just scroll through a long list, right? That's why we've come up with things like places, faces and events, to take that organization burden off of the user. An even smaller subset actually takes the time to edit their photos. In the digital age film is cheap so people take a lot of photos and if they find one that they don't like, they just delete it.

They don't actually take the time to rotate it, crop it and adjust all the levels. So sharing was the one solution that everybody does, everybody shares their photos, whether it be through a slideshow with people that are around them or emailing or uploading to a mobile media web server.

So with that in hand we were able to craft an application definition statement, easy to use, digital photo sharing, for casual iPhone users. Just circling back on the intended audience, many developers punt on the intended audience. They say, iPhone Users in their application definition statement. It's really important that you be as precise as possible.

The reason for this, if we change the end to professional photographers we'd end up with Aperture for the iPhone, a completely different application, just by changing our intended audience. And to take it further, if we use medical imaging we'd end up with MIMS or some other kind of imaging application on the iPhone. Even though it's easy to use and it's digital photo sharing, right? So it's supremely important that you figure out all three components. Once you have figured out your application definition statement, the very next step is to begin to actively filter out features.

And we have a nice little mantra for you guys that you may want to write down. You want to pick the few features most frequently used by the majority of your users that are most appropriate for the mobile context. This is a great way to see if a feature can hold its own. Basically you're using your application definition statement as like a filter, an ultimate check sum for your entire application.

And here we are back at our original list of features for iPhoto. And our new application definition statement is at the top and once we apply it you can see only a small subset will actually make it in to Photos on iPhone. And everybody knows how Photos on iPhone works, its super straight forward.

You start out with a list of albums, you choose an album and then you browse visually on a grid, you see you know which photo might I be interested in and once you tap one of these photos you inspect that photo in full screen. And the toolbar at the bottom only houses actions that pertain to sharing, the solution that we're trying to provide. You can do a slideshow, you can skip through the photos, you can upload to a MobileMe Gallery and you can email the photos.

And as simple as Photos is, it's one of the most valuable applications on the iPhone. So when you're doing this to your own application and you end up with a little small list of features that you're going to implement, understand that just because your application is simple doesn't mean it won't be very valuable to your customers. So that's product definition, really, really important.

Take the time to craft an application definition statement. I would challenge you that if you look at the most successful applications that are on the store, over 70 % took the time to write an application definition statement, they'll tell you if you ask them. So now let's talk about design and prototype.

First we're going to start out with understanding the basics. Here we have a great quote from T.S. Eliot, "You must understand the rules before you can break them." And how many of you knew that the next slide would be the human interface guidelines? [laughter] There was a mean for a while that the HIG is dead. The HIG is not dead.

In fact it's very much alive and it matters more today than ever, especially with the iPhone. The human interface guidelines contain a wealth of knowledge that have been contributed to by our engineers and our designers. They've taken a lot of time to solve various edge cases for you and implement standardized controls that our customers are used to.

So if you treat the human interface guidelines as a quick reference guide, you'll miss a lot of nuance, a lot of understanding of why things are the way they are. So our recommendation for you is that you read through the human interface guideline cover to cover, read linearly. Don't use it as a quick reference guide. You will gain invaluable insight into why something is the way it is.

But as you know, a book is a book and there are many things that those who read human interface guidelines don't quite understand or they implement incorrectly and so I'm going touch on what we consider to be the basics of iPhone user interface design right now so that there's no confusion, so that you guys can deliver stellar experiences. The basics loosely consist of Multi-Touch input, navigation, lists, tool bars, tab bars and general aesthetics.

So let's talk about Multi-Touch input first. As you know, we've worked really hard to make the standard keyboard that comes with the iPhone as polished as it can be, as approachable and intuitive as it can be for a Multi-Touch keyboard. But one of the best things about a Multi-Touch keyboard is that you can draw any custom controls that you need for your application on the screen at any time. So finally we're away from this age of WASD means up, down, left, right and hitting the 5 key on a numb pad equals select, right? Now if you need a control that is tools, then you draw a tool control.

And if you need another language on the keyboard, you draw another language on the keyboard. This is incredibly adaptive and pretty much the sky's the limit in terms of whatever you need to draw on the screen you can let the user interact with. And the best part about Multi-Touch controls is that it can go away when you don't need them, right? They don't have to be in the face of the user.

They can be immersed inside of the application. So now let's talk about some things you can actually implement inside of your own applications. You want to make sure you minimize the amount of text entry inside of your application and you want to hold it off until the very last minute.

The reason is when someone downloads your application for the first time, they want to get going, they want to explore, they want to see what it is, they want to like -- it's like touring a house. They want to check out every room. They don't want to have to fill out a form to check out your house.

They don't want to have to enter their name, address, email, log in, set up a password, get redirected to a website, all this stuff. If you really need that information from your users, save it until the last minute where they just cannot go any further before they give you this information and try to chunk it out so that it's a little more approachable. Data entry for the most part, whether it's on a Multi-Touch screen or a tactile keyboard, data entry is not fun, no one enjoys it. That's why it's a profession. People get paid to do it.

So minimize the amount that you require your users to do it. A great way that you can minimize it is by assuming what 80 % of your customers are going to enter in the first place. If you can offer a predefined list of choices, then most of your customers can just tap something on the screen and let the other 20 % customize the values for whatever they need. And one last note about entry, remember everything that you can about your customers. If I enter my name and address in your application once, I don't ever want to have to enter it again unless I go on vacation or I move.

So take the time to pay attention to your customers and beyond just like entering your name and address, there's some really nice touches that we've seen only a small amount of applications take the time to do. If you notice that your user every morning at 8:00 A.M. goes to a specific tab in a certain category to look at something, maybe it's like a news story genre or whatever, then wouldn't it be cool when they launch their application at 8:00 A.M. you took them there automatically? Forget about saving state. You can become personal. You can become adaptive to your customer.

You can really make it feel like this application has a relationship with them. All the data's there, you're able to record these things so why not take it to the next level? Now let's talk about navigation. Navigation is super straight forward on the iPhone. Basically we move from left to right with right to left screen pushes when you move down through the hierarchy.

But one of the critical components that we see obliterated time and time again is the title area and then in the nav bar. The title is super, super important to your customers. It's like holding the hand of a child as they cross the street. It lets them know where they are inside of your application at all times. It's like it lets them form a mental array.

If you take the title area away, customers immediately feel disoriented, whether it's rational or not. There's a psychological process that goes on where they feel frustrated inside of your application. I've seen too many applications that I hit their icon on the springboard, I launch the app, I look at their splash screen, I see their logo in the nav bar on the home screen, I drill down 2 levels and I still see the logo in the title bar area.

I assure you if I've gone through all that work, I know who made this application, right? I don't need to see your logo 3 levels deep inside your app. Main menu fine, if I haven't made a choice in the hierarchy, no problem. Put your logo there. But as soon as I move down a level, I need to see where I am.

So make sure that you honor the title bar area inside of the nav bar. The next thing that you want to do is enable standard navigation. If your application is an application that's not a game, then you should use standard navigation. The reason for this is that it's approachable, it's intuitive, everybody knows what to expect. You'll notice that our back buttons don't just say the word back and they don't just have a back arrow. They actually tell you what the name of the previous screen was.

If you find that you're getting into trouble, that the back button is getting too long unwieldy, just truncate it. Say 12 characters and no more or one word and no more or if the previous screen had like 3 different data types like photos, video and audio, just call it media. It just has to be enough of a tell to let the user know what the previous screen was about.

And then one final note, avoid home buttons and breadcrumb trails. Home buttons are usually employed by applications that are very deep and usually those applications feel as though they merit a home button to save the user some time. But the catch is that home buttons are actually very destructive for the average user.

The reason is if you put a home button in the top left hand corner of the screen and I've moved 6 or 7 levels deep in a hierarchy and I instinctively tap the top level of the screen, which almosr every single one of your users will do to move back 1 level, I end up at the main screen and I've lost 6 decisions. This is very destructive. This is very frustrating.

If your application's performant, a user will not mind tapping the top left hand part of the screen 6 times because it will be really fast and it will give them granular control over how many levels they want to move up. So if you really do need to implement a home button, put it anywhere other than the top left hand part of screen and breadcrumbs simply enough do not scale. After about 3 or 4 levels in a breadcrumb tree you start to wrap or scroll and then all you gain is 1 extra level of explicitness beyond the title bar and a back button that reflects the previous screen.

So avoid both at all costs. Another important thing for navigation bars, use standard controls for adding items to a list. The standard location for the add button is the top right hand corner of the screen. This is where users will come to expect it to be. If you have the mutable list, most people instinctively looked in the top right to add an item.

Obviously there's extra cases where you have an edit button or whatever and the add button moves to the toolbar at the bottom but if you can, put it in the top right. And then finally segmented controls are a great way to increase the productivity of your users. It lets you show either similar or mutually exclusive information in the same list and it can rapidly sort and filter based on a segmented control.

So now let's talk about lists. Lists are where you're going to spend a lot of your time if you're a standard application. Lists are how you're going to present data to your users. And lists are comprised of 2 different table types. The first is a plain table and you can tell you're looking at a plain table because the cells stretch from edge to edge of the screen and you're afforded category dividers and an index view on the right so that you can scroll quickly through a list. Plain tables are incredibly performant. They're very efficient.

If you have long lists of information, go with a plain table. Group tables on the other hand are a little more graphically robust. The cells are offset from the edges of the screen and you can have implicit grouping or explicit grouping with labels above each subsection. This is a great way to chunk information.

If you have 3 phone numbers in a group table you don't need to put a label up above that says phone numbers because it's implied by having 3 phone numbers all next to each other and offset from the other items. Another great recommendation for group tables is that you use category icons on the left.

A lot of people view category icons as if they were eye candy, just something that makes things look nice. But they actually have a very tangible benefit to efficiency and productivity of your users. The reason for this is that the human mind, when it comes to a screen, imparts its shapes and colors first and then it breaks down to individual words. And if you're from the United States you go from top left to bottom right reading all the words until you find one that you like.

If you have category icons you can simply go from icon to icon and when you feel like you've found the icon that's right for you, you read the label next to it and if that's right then you tap the row. So you can save your user half the time it would take to find something in a list by having category icons.

And if you employ color then your users can actually take it a step further and develop spatial memory and know exactly where on the screen that item is or where that color is without even having to read or parse any of the glitz. So category icons can be a huge buff for performance of your application in terms of productivity and efficiency.

Here we have disclosure indicators. Disclosure indicators are our way of showing a user that something's tappable, that this row is interactive. On the web the visual metaphor is blue text with an underline but those aren't very finger friendly hit targets so the way we let you know that this entire cell, this entire row is tappable is by using the grey disclosure indicator.

The grey arrow is distinct in behavior from the blue disclosure button. The advance disclosure button has a completely different behavior. We see a lot of apps opt for this just because it's prettier but actually it's supposed to have a different behavior. The blue disclosure button means if you tap anywhere on the row other than the button, you go to that item. Whereas if you tap the button itself, you go to an ancillary or details view for the item, so an important distinction there. Pickers we touched on earlier, pickers are really great for predefined datasets and especially if you have multiple columns in a dataset.

Earlier we talked about how most users don't want to take the time to enter text and so this also solves that problem. You can imagine that how much more difficult it would be for me to enter September on a keyboard, 9th and then 2007 as opposed to just flicking my finger on a picker. Because within 3 swipes on a picker you can go through 12 items, so they're very efficient.

Tool bars house the actions, the verbs of your application and for the most part they shouldn't have textual labels. The icons should be descriptive enough to let the user know what it's going to do. And if the icon's not descriptive enough, if it's too generic, then it's more than likely going to be a container for other actions.

You've seen like action sheet icons and things like that. So make sure that you don't put textual labels on a toolbar and make sure that a toolbar pertains either to the entirety of the application or just the screen that it's above or below. Tab bars are not tool bars.

Tab bars are our highest abstraction in the iPhone. They house the containers, the categories, the modes of your application and when you change tabs there shouldn't be animation in the content area. The content should just blip. And you'll notice that with the tab bar we have textual labels beneath them and for the most part, a solid tab bar icon is one that's like a silhouette, something that you can imagine you know using a flashlight and casting a shadow on the wall. That makes a really good tab bar icon because the mind can parse out the shapes without having to look at a lot of fine grain detail.

So how do you know when to use the tab bar? We have a really good example for this, this is a hypothetical version of the iPod application. Imagine if the iPod application didn't ship with the tab bar. What would the implications be for the user? Well the first is that every single time you launch the app if you didn't have something in Now Playing, you would start with this long list of categories and say your favorite category was genre. Say that's how you like to sort your music. Well you'd be out of luck because you'd have to scroll down.

It would be below the fold every single time you launch the app. And the crazy thing is or the logical thing is that people favor 1, 2, 3 different ways of sorting their music over all the others and they rarely dabble with all these other categories. So why present this visual noise? With a tab bar, a user can customize which categories are in which position. So if I'd like, I can put genre in the first position so that every time I launch the app I'm looking at genres or every time I launch the app I'm looking at songs.

This is a great way to cater to your customers and because you can't guess which one they're going to favor, you allow them to use customization to get which one they favor. Applications however that don't have more than 5 tabs don't have the ability to edit or rearrange the tab bar so it's on you to figure out what the order is going to be for the tab bar icons.

We recommend that the most important or the most frequently used items be on the far left and then you go off from there toward the right. There is another recommendation that we'd like to make and that is if you can find a way of putting featured, live, dynamic, fresh content into a tab this makes a remarkably better experience for your application. The reason is, people will launch your application without having something in mind that they need to do or that they want to do but instead they can launch your application and just browse, hear what other people are talking about with regard to this genre.

And you'd be surprised, you think that you know my app is about power tools. No one wants to talk about power tools. Everybody loves to talk about something and if inside of your application, you facilitate the ability for people to either feature something or talk about something, people will launch your application far more often then if it's only when they have something in mind like purchasing a power tool or entering a new power tool that they've purchased recently.

This will increase the use of your application and the more people use your application, the more likely they are to share it with their friends and family or their friends and family will see them using it and say hey what's that? What are you using? So incorporating fresh or dynamic content into your application is a great way to extend the life and the relevance of your application. And if you were to put fresh or featured content, as you know you'd put in the first position, far left.

You can see that in the iTunes app and the App Store app. So our final section on the basics, general aesthetics. Basically you want to put the most important information at the top of the list and the least frequently used at the bottom of the list. With that said however, just because content is below the fold doesn't mean it's dead like in the web because on the iPhone we have inertia based lists and people love to play with lists.

They'll throw them up and down just as like you know a game. And because of that, if someone comes to a list and they see something that they don't want, if it's not relevant to what they're looking for, they'll happily throw the list. And where this applies is mostly for those of you who are thinking of doing ad generated applications, if you put your advertisement at the bottom of the screen, you anchor it into the chrome.

Then your user is quickly going to learn to just defocus from the chrome and look at the content and totally ignore your advertisement. So instead if you would tactfully, tastefully interleave your advertisement inside the content area, whenever they're scrolling like a long article or whatever and there's a very clean, nice advertisement interleaved every 3 paragraphs or whatever, when it goes by your user is going to pay attention to it, they're going to look at it and the tap-through rate's going to increase dramatically.

Try to use standard controls whenever possible. If there's a control that exists for something that you're trying to do, use the standard control. Not just because we made it and we want you to use our logos but because it's approachable. The average user knows what it means. They don't have to figure out a custom control and there won't be overlap from controls that do something slightly different.

It improves the entire platform as a whole when you use standardized controls. And then finally, make things clean. Make things look really good. If your application is list centric we recommend that you look at the context application and just rip it off, bar none. Look at the labels, the values of the fonts, the waiting, the spacing. You notice how each element is offset from one another? We don't have text flush with the edge of the cell.

We don't have an image flush with the edge of the screen, things like that. You want a screen to look physically sound. Like you could stack these up in the real world and it would make sense, that it would look clean, it would look approachable. So those were the basics, for the most part straightforward. If there's anything that you feel like I rushed through, consult the human interface guidelines.

We cover everything in far more depth than what I just talked about. So now let's talk about application styles. Earlier we were figuring out what type of application you have, right? What your application definition statement's going to be. Once you have that figured out then it's time to figure out what silo, what category do you map to closest? So you can figure out how other people have solved problems similar to yours.

And the best way to do that is to throw your application onto this grid. You can see that the two primary axes are content and usage. If your application were to land in the top right hand corner, you would end up with a productivity application or what we call serious tool. A great example of a serious tool is mail.

Serious tools are highly scalable, highly performant and are productivity-centric. So basically your user is focusing on getting something done, either getting something made, changed or done and because of that you want the user interface to kind of just go away, to just disappear. It doesn't get in the way of the user and it facilitates their ability to work And in mail as you know it's very scalable, right? Not only do we have multitudes of messages but we have multiple mailboxes and multiple accounts as well.

And because of that the UI has to be far more standard than if it were a game. Fun tools are just as productive as serious tools or maybe slightly less. But the thing that's interesting about them is instead of forcing you from point A to point B and know exactly what you're doing, fun tools allow you to explore so like you can be very intentional.

I'm going to the pizza place and give me the address and give me the directions but on your way to the pizza place you can be thinking, what's around the pizza place? And you can see that because it's more graphically rich, you can browse. You can see what are the other elements that are around the pizza place? What other things might be relevant to me? So a fun tool allows you to explore and still be productive and because of that you want to minimize the hierarchy so whereas a serious tool will have a large, rich, expansive hierarchy, a fun tool should have a minimal hierarchy but allow you to kind of almost branch off at any moment, very similar to the web. Fun entertainment, everybody knows its games, right? It's any type of application that's super immersive.

Something that just invites the user in and they have an experience, they experience a story. Because of this we recommend that you use custom controls. This is one of the few categories where we're like, please don't use standard controls. You want to make sure that your controls honor the convention so like perhaps your main menu button is in the top left or your back button is in the top left but you want your controls to reflect the story of your application. They want to visually match the atmosphere of your application and you want to minimize the amount of hierarchy. The best applications are those that you know give you a main menu, play game and you're playing a game.

If you have to go 3 or 4 levels before you can play a game, that's usually a bad sign and that usually causes a lot of frustration and people will stop the game before they even get going to see how valuable the game is. Here we have serious entertainment and even though it sounds like an oxymoron it's really not. Serious entertainment is the most hyper-efficient way you can provide your user to browse content that has absolutely no productivity. We could argue maybe educational content who has productivity but serious entertainment lets you see some things that are available to you but it's very scalable.

You can imagine the iTunes Store and the App Store have lots of content that the user needs to be able to navigate and so serious entertainment lets you parse that information, navigate efficiently but in the end you end up watching a video or downloading a game or whatever, so potential hierarchal and moderately graphical. You can see that this list is a little more graphically rich than the mail list but for the most part it's still very efficient. If you're not in any of the corners, then you're a utility.

And utilities are the fast food applications of the iPhone and that's not a bad thing. Utilities are incredibly successful. When you approach designing a utility, a nice rule of thumb is when you finish with the screen if you can set it on you know a dock and put it on a bookshelf 6 feet away, if you can still understand the user interface, then that's a good utility. You want to make sure that they're super narrow in scope. Usually you navigate among one level of peers, right? You don't have multiple levels of peers.

So like for the weather app we have multiple cities and it's just details for each city and you're swiping, using pagination. The best utilities are gone in 60 seconds.` They're -- you launch it, you get information, you quit the app. So even though we gave you some you know very explicit guidelines around each of these application types, there are no hard and fast rules. Some of the best applications mix and borrow from all the different genres, if they truly are an outlier and they aren't necessarily right in 1 of the corners.

So now let's talk about paper prototyping. Our ardent recommendation for you is that you work out your entire application on paper before you even touch the tools. You can be ramping up with the tools, you can be learning about the tools, but don't write code that you plan on shipping until you've worked out every screen on paper. Many of you are thinking, that sounds like a waste of my time.

Why would I take the time to draw pretty pictures on paper when I could be getting to work? The reason is, paper is cheap. It's really cheap when it comes to the time spent. If you draw out a screen and you work out every single screen in the entire flow of your application on paper and you realize there's an educates there, I totally didn't account for it here, you crumple up 2 pieces of paper and you throw it away and you start again as opposed to throwing away 3 days worth of code. So it's really important that you take the time to work out your interface on paper. And for those of you who feel like you know I'm not an artist.

I don't draw. If you can draw a square and write a label inside the square, you can prototype your entire interface on paper. And we've seen some really great applications that the developer took the time to prototype on paper and it's, I mean I have yet to see an application that the developer took the time to prototype on paper that wasn't fantastic, that wasn't exceptional.

Anybody can do it and instead of me sitting here and expounding on the value of paper prototyping, we have a guest who's going to share with you their experience developing applications on the iPhone by working them out on paper first and forehand and that is Verner Yonik [assumed spelling] from Cultured Code.

Hello, when we develop things for the iPhone we only had 2 months time because we wanted to be ready for the App Store launch last year and what we did to make this happen in 2 months is we spent 1 month designing the app entirely and then 1 month coding the app, 1 of the app. And it really turned out that if you have the entire app designed on sketches first that its way easier to code later on because you know exactly where you want to go.

And today I want to share 3 design stories with you during the design process of things and I'm going to start with tap bar versus tool bar. Since Things is a task management application, it's a utility, sorry, it's a productivity style application and it's easy to use the navigation metaphor. So we knew we wanted to do that and the question was is it possible to have a tab bar at the bottom? We liked this idea very much because it's very easy to switch between your to-dos and your projects for instance.

So that's why we tried this sketch and it turns out there is a few problems with this approach. First of all we knew that the tabs at the bottom wouldn't suffice in the long term. We wanted to add more so we would have to have that... things and we didn't like that as much. The next problem is that switching wouldn't be so quick after all because if you look at the to-dos we offer different lists that you can put your to-do's into.

So even though you tap on the bottom of to-dos you still have to navigate into the different lists place so it's not that quick of switching. One possible solution for this would have been to have a segmented control at the top and then have the user switch lists with that but the problem here is that you don't really educate the user what those icons actually mean.

So we didn't like this either. And then of course the biggest problem is inside a list you want the user to be able to do certain, perform certain actions like moving items to other lists or filtering the current lists by due dates for instance. And even more important you want the user to be able to add to-dos to the current list and where do you put all those action buttons or those actions? Where do you want to put them? You can already see that we had a hack here that the + in the lower right corner actually adds a to-do to the current list so it's a tab bar item that operates on the current list which is not really what you're supposed to do. So we really felt that the tab bar is not the way to go and instead of using this instantaneous navigation that is available at all times, we decided to offer the navigation completely from the home screen. So this is on the left side.

So all lists are accessible from this home screen. And it turns out this worked really beautifully because now we had space at the bottom for a tool bar and inside lists we could offer different tools to the user that he can use. And this is actually how we shipped version 1 out of our app.

The next story is adding to-dos. When you're inside a list you want to be able to add to-dos to the current list and we thought about where to put the + button in the screen and one obvious choice would have been the upper right corner but we knew we wanted an Edit button there because you would have to be able to rearrange to-dos or to delete them so that was no option. The other side is no option either because you have to use that for navigation.

So the only place left was the tool bar and we have different tools in our tool bar depending on what list you're actually in and we wanted a + to be at a consistent position so the user always knows blindly where he has to tap in order to add a new to-do so we chose the left side. And what's even more important when you design a task management app is whenever the user gets out his iPhone and launches the app, he always has to be able to quickly add a new to-do to his data.

He doesn't want to navigate complex hierarchies until he's able to actually add a to-do. So in every screen we wanted to have a + button at the same position and what that meant is that even in the home screen where you're not inside a current list, you still have the + button at the lower left corner and what happens when you press that + button is it just adds the to-do into the inbox by default.

Now inside a list, this is the next list for example, if you press the + button you would assume that that would add the to-do to the current list but if you think about the use case where the user just takes out his iPhone on his way and wants to add a new to-do quickly, he might not want to add it to the current list he's in. He might want to add it to the inbox.

So we thought about how do we offer these two options, adding to the current list and adding to the inbox. And one solution would have been to just have two buttons at the bottom, one for adding to the current list, one inbox button. And we didn't like this approach for two reasons, first it crowds the tool bar.

You already have quite a few action buttons there so that's not that nice and then also both buttons actually bring up a very similar sheet because in both cases you would have to enter a title, a note, a due date to the to-do so it's very similar what comes up yet you have two buttons and you have to convey the difference or you might add an icon and that's not so easy to do. So we didn't like this either.

The solution we went for then is that you only have one + button at the bottom and this is what comes up. At the top you can enter the title, the notes, the due date and at the bottom you can just choose the list you want this to go to and it's always pre-populated with the current list that you're in but you can easily switch to the inbox or any other list if you want to. So this was the solution for adding to-dos. This is how we shipped version 1.0.

The last story is our quick entry sheet. This is the sheet I just showed you. That's how we called it, quick entry. And we shipped version 1.0 with this and our users told us that it's not very quick because a lot of the time what you want to do is you just want to add a title to to-do and then save it.

And the steps you have to perform in order to do that is bring up the sheet, then you tap on title, then you type in the title, you tap Save and then you tap Save again, right? And that's a lot of steps that you have to perform to do such a basic action and so we went back to the drawing board and really tried to optimize for this scenario. And the constraints where we wanted the user to be able to type in the title right away when the sheet comes up and also we didn't want any UI elements to be obscured by the keyboard that is visible. So those were the two constraints.

And this is an initial sketch of how we try to do that. At the top you still have the title and then below that there's only the icons to tell you this is a Tag Notes and Due Date section and then this Create In list element at the bottom. This is a PhotoShop markup we did it from that sketch and this solves the problem but we didn't like this version either because what happens here is first it's not very extensible.

As soon as you add more attributes to a to-do, say a person that is attached to it, you don't really have more space there at the tags, notes, due date part and secondly and more importantly you have to think about what happens once you say add a few tags to this so you tap on the Tags button, then you add two tags and now you're back to the screen and you can't really fit all the tags that the user entered in that small space so you would have to rebuild the UI after you've done that. And rebuilding the UI and not presenting the user with the familiar layout is something we didn't want to do. So we didn't like this and the solution we went for is to simplify this even more.

Right here we tried to just cram too much into too little space. So the further simplification [laughter] was just to let the user type in the title, right, this was the use case that we wanted to optimize for and then you can just press the Add Details button that transform this view into a more complex one if you want to be more specific. We almost like this. We had a slight variation because we still wanted the user to quickly move this to-do to the inbox so we added this Create In field at the bottom. And this is actually the solution that we ship now.

If you press the Add Details what happens is the keyboard slides away and you get the tags notes and due date part. You can tap on those to specify them, you tap Save and you're done. And one question we had, ok so we optimized for the standard pace. You just enter a title and that's it.

But what about if you actually enter more? If you enter text and notes, no, you have to -- there's this intermediary step where you have to press the Add Details button and did this actually make the quick entry slower than it was before? We didn't know that. So we actually counted the taps that you needed. In the old version this is on the left and in the new version on the right. And in all but one cases the new version had less taps and there's one case where it's equal.

So we were satisfied with that and this is as I said how we shipped the current version. Ok so that was three design stories. There's way more to tell and way more sketches. One thing that we really found is that if you sketch out the application first then it's very easy to see conceptual flaws and fix them early in the process rather then spending much time coding and then figuring out oh this doesn't even work conceptually.

And then the coding part, if you have all the sketches done, goes really quick because you know exactly where you want to go to.

So that's Things, a fantastic serious tool for the iPhone. One more note about the value of paper prototyping. Say you are incapable of doing the actual high fidelity design stuff at the end, this is a great product.

Like when you work out all your screens on paper, this is a great handoff to a design firm when you say make this application look great. Or if you are a designer and you can't code, you work out all this and then you hand this off to a programmer and say make this reality. It makes everybody's lives a lot better.

Everybody knows what it's like to work with a designer and a designer comes in an hour before it's supposed to ship and say, about that one screen, that's not going to work so can you go ahead and throw away a weeks worth of code? So paper prototyping is great for everybody involved no matter what kind of shop you have, whether it's a large organization or a small team.

So now let's talk about polish and refinement. Polish and refinement is how you take an average application and you turn it into something that's just a stand out. It's just everybody wants to have it. It's really compelling. And the way that you go about doing that is by taking your finished application and then going through this list and just making sure that you have all your bases covered.

You want to make sure that you employ the latest technologies, add excitement where relevant and then you want to approach application differentiation by employing a few things that we'll talk about in a moment. So the first thing that you want to do is look at iPhone OS 3.0 and figure out what technologies map to your application.

Which technologies would be relevant to your users? Search and scope bars are great. They're new, they let you really quickly filter down search results, they're given away for free so implement them if it makes sense for your application. You want to take the time to do a 29 by 29 pixel icon for Settings and Spotlight.

If people are searching for your application in the new spotlight area in OS 3.0, you want to make sure your application looks as good as it can. First notifications, if your application merits push notifications, make sure that you really think out what kind of notifications that you're going to give to the user.

It's easy to just go you know crazy and have notifications for almost everything but you want to really think out, which things does a user want to be notified? Because when you notify a user you're going to be interrupting them doing something else, right? So you really want to make sure that you think through how is this going to affect the user? Would a user perceive this notification as valuable, would they want to know, would they care? Copy and paste, user's going to expect it really quick so make sure that you take the time to implement copy and paste if it makes sense. And make sure that when you do implement it that you only implement it in places that it really makes sense so like you don't want your users to copy and paste headers and labels and things like that.

You want them to be able to copy and paste content and you can be really smart about how you format that content whenever they paste it somewhere else or insert it into a mail message. Undo and redo, this takes a lot of thought because every application's different. There's no hard line like this is the way you approach undo and redo but really think about the implications of undo and redo inside of your application.

Think about scope, if I do this here and I move up 3 levels in a hierarchy and then I hit undo, what happens? Really think about those edge cases for your users because they're going to want, they're going to want what they expect to happen and not necessarily what you think is ideal. Once you've done that you want to circle back and implement animation where appropriate. And here we have a nice list of animations that ship with the operating system on the phone. Here the example that you can see is the music store.

We use animation in the music store not only to let you know when something's playing but when you purchase an item we animate that track into the purchase tab. The reason why we animate it into that position is to (a) let you know that your purchase was successful and (b) where to go to look for that purchase without necessarily taking out of the purchasing context, right? Other great examples are deleting notes, we have the little genie effect for the page goes into the trashcan.

That's our way of equating crumbling up a piece of paper and throwing it in the trash. Moving mail, we take the same generic mail icon in the top left every time but then we animate it into the folder that you've selected. The reason is you can imagine if you're moving email messages and you don't know where it went, that can be really stressful.

You could be like, did I move it to the right place? And we don't want to throw an alert every time, your mail was successfully moved to whatever folder so we use animation to kind of just get out of the way of the user. Revealing map filters, the map curIs up and it shows these controls and the reason why we curl the map is to let you know that you are still in the context of the map.

These controls pertain to the map that is above it. Changing photos, the reason why we animate our photos when you swipe to change is because if you had a stack of photos on a real table and you swiped the top photo, it would move to the side. It wouldn't just disappear, right? So we use animation because that's what maps reality. A good rule of thumb for animation is, does it make sense in the real world and if it does, does it communicate something inside of my application? And if you can pass those two tests then it's more than likely a good place for animation.

Selecting Pages in Safari, everybody understands the metaphor of an 8 by 10 sheet of white paper as representing a page and so each of these pages represents a web page and each web page has its own sub-navigation. And in Springboard when you press and hold down an icon, all the icons start shaking and quivering, right? And it's either because the icons are excited about being moved to the first screen or they're afraid because they're about to be deleted and rated bad. [laughter] Either way, you know when you're in Edit mode. You know when you know you're interacting with your icons in this level so it's safe, it's communicative and it tells a story for the user.

So here's some good guidelines for animation, use it to educate your user. Use it to inform them without, you know, being just in their face all the time, being heavy handed. Avoid animating everything just because you can. We make it very easy with core animation and avoid gratuitous animation.

Everybody has gone to one of those websites where it says click here and you try to click here and the button moves, right and you try to click there and the button moves? That's a joke on the web but we've seen a few applications that do this unintentionally just because they overused animation.

So make sure it makes sense. Another great thing that you can think about implementing, coming back and implementing into your application, is sound. Sound is probably one of the most valuable and undervalued items inside of third party applications on the iPhone. If you think about it you can watch a movie with subtitles and you can enjoy that movie but how much more enjoyable is it with a soundtrack and sound effects? The catch to adding sound to your application is that if you put it in one place you're more than likely going to have to put it everywhere else because if you launch an application and it's silent, you don't notice that it's silent until you hit one button and a door comes up and it goes [noise] like that and then once you hit the button and it goes away and it doesn't make a sound, something feels wrong. And then the rest of the application automatically feels wrong. So if you are going to approach sound, make sure you go the distance.

You have to make sure that if you put it in one place, you put it everywhere. And with that said, make sure you use the proper audio channels so you can look this up in the human interface guidelines. There's nothing worse then having a customer that just loves your application, say it's a game. They're just in love with it.

They can't put it down, right? And they want your application, say they're in school in a classroom or in a business meeting, underneath the conference table and they launch that app and it goes [noise] even though the ringer switch was off, right? That's going to create this bad feeling for your customer and every time they see your app they're going to feel embarrassed again.

They're not going to want to use it. I mean this is kind of like an anecdote but it's really important that you use the right channels because there's other things like the iPod. You don't want to hijack the music channel. If someone wants to use your app and listen to their songs in the background as well. So think about it, evaluate it, it could be what separates you between, it could be the differentiator between you and your competitors.

If you do everything else right and then you add sound that could just be the last straw. Here we have some really good examples of tactile design. These user interfaces feel physical. They feel tactile and interactive and you can imagine if these were physical objects put on a bookshelf, you'd be willing to pay significant amounts of money for them. You know you have some really nice wood, some leather and some aluminum.

The cost to produce these materials virtually is next to nothing yet when you approach this application on the store, as compared to a white list, you're far more motivated to part with more money just because it's visually robust. And to explain the value of animation, sound, and tactile materials, I have Mark Drudene [assumed spelling] from Tapbots who's going to share with you the process of their development of Convertbot and Weightbot.

Hi my name's Mark and I must disclose that public speaking is basically my kryptonite so [laughter] bear with me. I'm here today to talk about our approach to providing a great user experience in our applications and so to start off, when we build our applications the first thing we do is, the most important part is providing a great story or a concept and basically that story and concept dictates how our apps going to look, how it's going to sound, how it's going to work and even as far as what features go into our applications. And so what is our story? It's pretty simple and we have it on our website on the adopt page.

If you look at it is says we build utility robots that are fun, focused and easy to use and so what does that mean? Well if you look, listen closely I said utility robots. I didn't say we build utility apps or utility robot apps and the concept behind that is we want our applications to become the device. So the way we want to think of our applications is if you are holding Convertbot in your hand, you're not holding an iPhone with our app running on your iPhone.

You're holding Convertbot, this physical device. And so that just, it really allows us to apply a certain look and feel to our application. We don't need to, we're not constrained by the way apps are supposed to look and because we're trying to provide our own story, provide an experience in our application that everyone else can enjoy. And so if you look at our applications what does that say? Well they're very mechanical because we want them to be like robots and they're very tactile-looking so when you look at the buttons we want the users to feel like they want to touch it, you know.

They want to press that button. Like I don't know about you but when I was a little kid whenever I saw switches and like you know any knobs and things like that, I always wanted to touch them and turn them and see what would happen. And so that's kind of the effect that we want with our interface.

We want people to wander, what happens if I press that button? What happens if I turn that dial? And they kind of have an expectation as far as how it's going to work but they're not quite sure so they need to experience it and so that's what we do.

And for example, there's a unit you want to convert from and a unit you want to convert to and you know that the buttons are there but you don't know exactly what they do and so and normally selecting a unit or a category is a very mundane boring task.

You don't really, you know, it's something that you don't really think about. It's something you have to do to get the numbers you want to convert from and to. And so what we wanted to do is provide an enjoyable experience and even just doing something as simple as that.

So what we do is we reward our users for interacting with our device or with our application. So how do we reward them? Well we use sound and animation to help sell our stories. So when they hit that button they hear sounds and they see it animate out and it builds upon that story that this is an actual, physical robot device. This is not just some random application. So we really, we keep drilling down to that focus point that we build robot utilities that are fun, focused and easy to use.

We keep, I usually write that down wherever I'm brainstorming or I even put it on a sticky on my computer and I keep remembering back to that point because everything we do on this application has to say that phrase and that's how we provide this cohesive, you know, it's a single experience.

And I guess as an analogy imagine this, imagine that you saw a poster for a Transformers movie, you saw screen shots, you didn't see the movie, you didn't see the actual trailer and you have this expectation cause it looks great as a still and you expect that these robots to make great sounds, to animate, you know and just be amazing. And imagine if you went to the movie and it was basically stop motion animation and they had no sound effects? You would totally lose that immersion you know.

And we kind of think about that with our applications. When they're using our application and it looks like it should do things, it looks like it should be animated, it looks like it should be based on reality and if it doesn't provide that experience then it's kind of a letdown. So we kind of want to match that expectation. They don't know what's exactly going to happen but we want to match that expectation but we also want to make it even better so that's how we think about creative ways to animate.

And make sure, it's real important that your animations tie in to your core focus, your concept and so our direction is really important. We don't put in random sound just for the sake of it. We don't put in random animations. It's all to a point and it all goes back to this being a robotic device.

So whatever your core concept is, you want to stick with that. And the last thing I have to say is you know the bottom line for us and the most important thing to take away is you've got to have that concept, you've got to know why you're building it and that basically leads to everything that you're doing on the app, even what functionality goes in there.

Because our core motto is, it's focus too. And so we don't add a ton of features. We want to keep it what the core feature of that application is and we want to stick to it and then we can put a lot of polish around that instead of having a ton of things to work with. And so yeah and let's see [inaudible audience comment] Thanks.

So I want to be very respectful to you guys time. I know we're running short. I'll be as quickly as possible. We talked about 2 significant paradigm shifts that have occurred today. The first was direct manipulation and how that applies to user interface design. The second was tactile design and Tapbots just gave a great example of how important tactile design is but there's a third paradigm shift it's really important and it's really valuable and that's called transparent design.

Transparent design has 2 distinct manifestations. The first is design that goes about getting out of the way of the user and being as contextual as possible. So a great example, we get an alert, we maintain contacts. Instead of hijacking the whole screen, we just dim out the background.

It's motile. You have to acknowledge the alert but its transient at the same time. It maintains context. Another great example is when you're writing a text in messages. You get these suggestions, suggestion words, right? They're not where you're typing. We don't hijack where you're typing so you could ignore them if you'd like and as soon as you move on they disappear.

So they're very transient by nature. And when you send a message, everybody has seen this. Very few people take the time to notice it. It's not this way now in 3.0 but previously we needed to keep you from sending another message, keep you from typing another message while we were sending the existing message and so we use this transient modal block that covers up the keyboard and let's you know the status. Even though this is modal and it prevents you from typing, very few users ever notice it or mind that it's in the way.

So these are great examples but the second variation that I was talking about earlier, where it's most important, transparent design is most important, is video games. Because when you play a video game on a console, you don't look at your hand while you hold the controller. You look at the screen. You get immersed into the content and you just play the game. You want the controls to just evaporate. You want the phone to become an extension of your body.

And so to explain this process and to talk about their story, we have Capcom today.

[foreign language] Good morning everyone. He is Takeshi. I am Sareda [assumed spelling] from Capcom.

Capcom is a Japanese gaming company. You may notice us by game title like Street Fighter or Resident Evil.

[foreign language] Over there in Japan also we have a big movement for iPhone. [foreign language] There are many game designers get inspired by the unique user interface of iPhone and they rush into development. [foreign language] But there's one important thing, important fact that unique user interface does not warrant interesting game experience.

We have one question for you, do you really want to tilt for every game?

I would say user interface defines game design and game design defines user interface.

Today we want to talk about this forgettable fact. [foreign language] This is a user interface of Resident Evil for iPhone.

People around us who likes iPhone asked us or said to us, I want to defeat zombies by tapping on the screen.

If tapping can kill zombies then zombies doesn't have enough time to attack.

[laughter] Right? [foreign language] It's actually no thrill, no fun as a game. [foreign language] It's something like real survival in safari. It's more exciting then zoo touring, am I correct? [foreign language] Let's get back to the things about UI, user interface. [foreign language] We apply for this game, we apply virtual path. [foreign language] Actually some people say virtual path is an easy solution [foreign language] but it's not true actually.

[foreign language] The most games apply what is called simple matrix D path.

It's no secret that it's very easy to invent actually but the [inaudible] can be very bad.

Actually users tend to think he is controlling D path by his tip of his finger but actually the ball of finger is center.

[foreign language] So there is a big difference between what it looks and how it walks. [foreign language] To clear this issue, to avoid this issue, we developed analog -n-drag type D path.

A direction can be more precisely detected by dragged picture rather than a single touch point detection. [foreign language] Now we've moved on to the icons.

[foreign language] The icons of Resident Evil changes according to the game situations, the number of button changes, the shape, the graphics of icon changes according to the game situation. [foreign language] Actually this is very, very important. This makes it very easy for first time player to understand how to play. [foreign language] Virtual path with ingenuity like this we like to name Visual path.

Visual path is not physically fixed UI so you can use whole screen like a canvas and you can draw, you can design whatever you want, whatever you need. [foreign language] Today we have three ideas to share with you, actually idea this is what we've come up with, not in consideration but we hope that those going to be something suggestive.

[foreign language] A person icon, person icon chose the game player feels fear. [foreign language] A red colored icon shows the status is in danger. [foreign language] Shaking, moving icons shows the situation is getting tense. [foreign language] In this way visual path has more wider flexibility, possibility.

The most important thing for game designer is to provide users a good gaming experience.

Not showing off the uniqueness of game, user interface.

Appreciate you guys being patient. I know you're eager to go to other sessions. The take away for this session is that crunch an application definition statement, take the time, do it. It will save you a lot of time in the end. Prototype your interface on paper and then polish and refine until you really have something great and don't release until you have something really great. Thanks very much. Appreciate it.