Good morning. My name is Jay Capela, I'm the Design Manager for iWork and productivity apps. This is John Geleynse. John is Director of Technological Evangelism at Apple. John?

John Geleynse: All right. Well, let's get started this morning. First thing I want to say is that there is no possible way that we could talk about every User Interface design situation that you will face, designing for iPad and iPhone, and that's not our intention this session.

But what Jay and I put together is some content that we believe is most applicable to you at this stage, based on just our own learning around apps that Jay's team has done internal at Apple as well as my experience working with so many of you bringing your apps to the platform and to these devices. So let's get started.

You know, you're here because you understand that design matters. But let me, just for the fun of it, just get started along a construction theme because design doesn't only apply to software -- design applies to pretty much any great product that's built around the world that we all use or that we live in or drive or whatever. And design really matters.

Take this net-zero energy home. It's got solar panels producing power year-round, it's got insulation, you know, beyond what you would normally have in a home. It's air-tight, great ventilation systems for air-conditioning and heating. I mean, there's just all kinds of levels in the construction of this home that required great design. And the end result is something that's phenomenal.

And hopefully there's lots more of these kinds of homes throughout the country. So that's an example of what you get when you do great design and you follow the plan. But what do you get when you don't, you know, design in the first place? Or when you don't execute on the design that was given you and fall asleep at the wheel so to speak and stay in the construction theme for a minute.

You know, you can get disasters like this: unplanned stairways, unplanned levels, unplanned laundry facilities, questionable construction techniques, right? Clearly there's a problem here. What else can happen? Well, you can have something like this, which is a big problem. So either somebody didn't bother designing this or somebody was asleep at the wheel when they put it together and didn't even notice that there was a problem when they were assembling it. Or this one. Now this is not a Photoshopped image. But you know, clearly -- maybe there was good design because you know, the porch is not too bad, the balcony is not too bad but something went awry along the way.

And all of these examples show that without design, without execution on design, good execution on design, you can end up with total catastrophes, total disasters. Now, we're not talking about construction; this is a software development conference. We're talking about designing for iPad and iPhone. And design is essential. Design really matters and design takes planning. There are some steps that you go through in the design process. There's an iterative process that goes on and we'll talk more about that in a few moments.

But it takes a lot of planning. And it absolutely matters for apps, particularly on this Multi-Touch platform of iPad, you know of iOS on iPhone and on iPad. And I want to begin with this great quote by Adam Engst because I think it sets a great content for this session this morning and for the material that we want to cover. The quote is this: "...the iPad becomes the app you're using...Switch to another app and the iPad becomes that app.

If that is not magical I don't know what is..." And I love this quote because it's definitely been my own experience running many of your apps, as well as our the apps that we have bundled with the Operating System or that I've picked up from Apple on the App Store. It's been definitely my experience. Hopefully it's been your experience with many apps. And I think it sets a great context for what we want to talk about this morning.

So I'll give you a couple examples. Here's Maps for iPad; the iPad essentially becomes a map. You pinch, you zoom, you move around, you set attributes. It's a digital map but it feels almost like the real thing. Here's Notes on iPad; iPad becomes a note pad. Here's Calendars; iPad becomes a Day-Timer essentially.

Here's Contacts; iPad becomes an address book. I mean, it's just you flip through your contacts, you flip through groups, you change contacts, it's just like what you'd expect it to be. And iPad becomes this [inaudible]. Here's Square; this is a point-of-sales system. This is a disruptive product. I mean, what it does is it turns any one of you on your iPhone or iPad, it gives you the ability to process credit cards. You swipe a credit card at a garage sale, you swipe a credit card at a farmer's market.

Whatever you're doing, using Square, you can process credit cards. And you can take signatures on the iPad. And so if you're running a coffee shop, you walk in, you hold the iPad -- you don't have a cash register anymore, you're just holding an iPad and you're letting people sign, you're letting your customers buy products from you off this device that's in your hand and you're issuing them receipts, you're processing credit cards, all these kinds of things. iPad becomes a point-of-sale system.

And so as I said, there's no way we can possibly speak to every design scenario that you will face coming to iPhone and iPad. But what we thought we would do is talk about 6 things that we think are the most that are very important for you to consider and 6 steps, if you will, that you should take in your design process. And there are more.

This isn't meant to be the be-all and end-all list but these are a good starting point and they are the following: it's important to pay attention to the structure of your app, to define that structure; it's important to get the navigation of your application correct; we're going to talk about reduction -- how do you decide what features are in your application?; we're going to talk about appearance -- how do you make sure that your app looks great and what's the standard that you're really pursuing there?; we're going to talk about feedback -- what does that mean for the user, what does it mean on this Multi-Touch platform? and we're going to give you some examples of great feedback; and then we're going to talk a optimization, some things that you can do that you may not have thought about that will help to ensure the delivery of a great user experience within your app.

So let's start with number one, structure. You know -- just let me use this construction analogy again. You know, the structure defines everything about a building, about a home. And it's on that structure that you hang every aspect of, you know, the interior design of that home and it's true for applications -- great applications have great structure. And it's on the structure of your app that you hang the UI, that you hang the features set. And these things influence each other a little bit.

There's an iterative process that we'll talk about later on. But there's no doubt that the best apps on the platform have a very clear structure. And the structure of your app is defined by the user mental model. And this is a term that I've spoke about at WWDC, it's a term that we talk about in the Human Interface Guidelines. But it's a really important concept to get.

And user mental model basically means the way a task it perceived by people. So your app does something and users hear about what your app does or they hear about the "something" that it does and they immediately form a set of they form a mental image. You know, if I say something like "shopping," instantly we have a mental model of what that means -- you have a list, you do things, you go after stuff, you know? Banking, right? There's all these things that we do in life, there's all these things that applications do and as users think about these apps, they form a mental model. And that's what user mental model is all about. And user mental model -- identifying what the user mental model is for what you're trying to do is a vital step in determining what the user experience and the User Interface design is going to be.

So let's say you were going to build a calendaring app -- and we did that, we built Calendars. And here's what Calendars on iPad looks like. The question is: how did we get from this or how did we get to this design? How did we decide that the Calendar dominated the UI? How did we decide that appointments were within the Calendar? How did we decide that the search bar search field was in the top right corner? How did we decide to do the navigation across months, etc. on the bottom on the bottom of the screen? Well, we did this using this concept this exercise Mental Model. And I have shared this exercise with countless developers over the years and it really has been productive every time I've done it.

Now I'm going to gloss over the exercise quickly because we don't have -- in the interest of time -- but let me just talk about the basic steps. So determining user mental model really is all about building some lists first of all and it's about assembling all of -- you know, the stakeholders in your company together by a giant white board or what have you -- and coming up with some key lists.

So as you talk about your app, first thing is: what are the objects that users are thinking about? You know, if you talk about Shopping app, you're going to think about certain objects as I said -- Finance app, Calendaring app, right? You're going to determine what the objects are, everything the user might be thinking about in terms of entities. Then you're going to list all of the tasks that users are going to do with this app. And then along the line, build a list of concepts.

They are sort of larger concepts that users have got around what your application is trying to do. So once you've got these lists, there's 3 more things you do. The next is you identify relationships between all these objects within objects, between all these lists. Within the objects lists you determine: what are the relationships between these objects that we've listed out? Some are parent objects, some are child objects.

In tasks, which tasks are most frequently used? Which ones relate to each other? That kind of thing. Then you're going to identify dependencies -- which tasks relate to which objects? And you're going to group a lot of these things under the concepts. And then the last step is to identify to prioritize these things.

Well, of all the objects that we've listed, which ones are the most important to the user? Which ones are the most frequently used? Largely it's driven Most of the time it's driven by frequency of use or frequency on the mind of the user potentially. All right, so what does this look like for Calendaring? Well, what do people think about when they think about Calendaring? Well, people are thinking about calendars themselves, the objects; they're thinking about days, weeks, and months; groups -- sets of time if you will; they're thinking about appointments; they're thinking about reminders. This is not an exhaustive list but you get the picture.

In terms of tasks, what do you do when you're Calendaring, when you're managing your time? Well, you're filtering, you're choosing whether you look at a week or a month, this kind of a thing; you're creating appointments; you're creating calendars potentially; you're editing things; you're searching; you're managing; you're changing dates, right? It's not a super complex task. I'm going through a simple example here but hopefully you get the picture. And then in terms of the concepts the user's got around Calendaring, you've got searching, managing, scheduling, right? And you can see already that some of these things relate to tasks, they relate to objects obviously.

So next step is: well, what are the relationships between these things? Well, just in the interest of time, I mean, obviously Calendars are a key object and a lot of the other objects, if you will, are child objects, they relate to Calendars -- same thing with tasks. There are certain tasks that relate to scheduling. There are certain things -- tasks -- that you would relate to a concept of searching.

And so you do this kind of grouping -- you organize, you figure out the relationships. And then lastly, the next step in the process is -- again, with this stakeholder team of key people who are going to influence the product -- go through the dependencies, figure out which tasks affect which objects, which concepts manage which tasks. You know, how is all this stuff associated with each other? And then you prioritize, based around frequency of use, or frequency, you know, top of mind kind of concept.

Which things are the most important for the user? Well in Calendaring, obviously Calendars are number one. Appointments are really high priority as well but because they're a child object of, they're a child of Calendars, you're going to end up with a different result, so they have a slightly less priority. Creating things -- creating appointments, creating calendars -- is a priority task, you know? Searching and filtering is an important task but it's sort of secondary.

Well, that process then would result probably in some drawings, some paper prototypes, some whiteboard sketches, which in turn would get turned into something that's more real like this; clearly you don't jump from that to something like this. But what's interesting is you think about that exercise we just went through and the impact on this app.

The UI is dominated by the primary objects, Calendars. The sort of secondary object, which was a child of the primary object was Appointments; it is front and center in the app as well. Changing dates is there on the main screen as well. And then towards the top and bottom -- and we'll talk about placement on screen shortly -- you've got these tasks.

Towards the top you've got some more primary tasks -- you're filtering day, week, month lists, that kind of thing -- and then towards the bottom, less frequently accessed tasks for changing date, maybe changing the month in a way that you might do a lot less than you would just picking a specific day of the current month. So you can see how user mental model informs the UI design and that's a really important exercise. Now, next step or next step next thing to pay attention to is navigation. And structure impacts navigation.

In fact, navigation is basically the floor plan of your application, if you will - mixing mixing these analogies together, mixing metaphors here, this construction thing I talked about earlier. If you're building a home, you're going to come up with a navigation. You're going to come up with a layout for that home.

You're going to decide that there's lots of traffic over here going to that room, there's not much traffic, we rarely go to that room, so let's change the floor plan accordingly. That's what navigation's about. Navigation is the movement of, you know, people within your app between modules and between data data collections, that kind of thing. And there are lots of different navigation techniques on iOS.

Here is the iPhone, you've got the Weather app. It's got a very simple mental model. There's no data hierarchy. And so all of the objects, if you will, that the user's thinking about are simple. They're thinking about cities, locations and all cities are the same in terms of the hierarchy in the user's mind. They just they've got 6 of them or they've got 10 of them or 2 of them.

And the navigation here is very simple, right? You just swipe across the screen and you're moving between these peer objects -- there is no other navigation -- and the page control navigation is a great way to move between frequently accessed items. User wants to get to the 5th city, they want to get to the 1st city; it's a very, very efficient navigation tool.

So think about page controls. iBooks does something similar. I mean, iBooks use a real-world metaphor so you're flipping pages. Obviously it's just like a book, right? The iPad becomes a book in essence. But at the bottom of iBooks, you've got a page changer and so you can tap and drag and choose which page you want to go to; that gives you a higher degree of granularity. It's something you would do less frequently, so it's not always there. But it's a couple it's another example of how you can do navigation within within your application.

Tabs are a great way to do navigation. Tabs allow you to manage complexity. They're pervasive on iPhone and they're also a great thing to do inside of popovers in your iPad app. They manage complexity. They allow you to increase efficiency because it's really simple for users just to go, "Oh, I don't want albums, I want songs. I don't want songs, I want artists," and to quickly sort their information, let's say, in the iPod app. And as a result, tabs allow for an efficient way of switching between modes or collections of data.

And again, out of your mental model you're going to come and see that you've got a lot of tasks so you're more of in a task-intensive app or whether you have lots of objects or groups of objects and certain objects are collections are within others. And so you'll find out whether you're more content-driven than you are task-driven.

All of these things can impact your design. And so in the iPod app, which we're all familiar with, you can see the tab navigation at the bottom. You're moving between songs, artists, albums. So think about tabs if you've got a good structure within your app and you want to move between modules or content sets.

Now, here's iPod on iPad. And the app is essentially the same app, you do the same kinds of things with it but what's interesting here is -- and this is a key take-away: where on iPhone you have a great degree of hierarchy across screens and you're tapping, you're moving between screens, you know that's the way that we design an iPhone because of the screen size; where you've got great degree of hierarchy on iPhone, you actually what you need to do on iPad is flatten that hierarchy.

Try to come up with a primary context, a single focus screen where the user is going to spend most of their time and then use popovers, which are hierarchical in nature to modify that primary context. Here the iPod app on iPad uses a set of collections in list format on the left.

And then in the right on the right side of the screen, which dominates the screen -- two-thirds of the view -- it's the content the user cares about the most. It's the number 1, the top priority content for the user in terms of their mental model. It's their music. So it dominates the UI.

And at the bottom in terms of navigation, there's a segment of control that allows the user to filter that content, the stuff that they're looking at around artist genre, that kind of thing. So segment controls are a great way to to allow for navigation between sets of content.

And navigation isn't only about movement, it's also about placement and I've touched on a few of these points. But if you're designing a home, you're going to optimize the kitchen for the way that you use your kitchen. You're going to optimize different parts of the home for how you use those parts of home. If you're building a factory, assembling cars, you're going to optimize each station within that factory so that it does exactly what has to happen here perfectly.

And the same concept is true for designing your apps. Once you've got the mental model -- you've determined which objects are key, which tasks relate to which objects -- you're now at a point where you're starting to see relationships between things and you may have, like in the Phone app a screen, which is where you store phone numbers and other information.

And so what you want to do as you design this screen is optimize the design of the screen for what the user is trying to accomplish here. And if you're in the Phone app, the most important thing is the phone number, which is why we list it at the top of the set of data because you have the most frequently read items or things that matter to the user the most at the top and as you progress down the screen, you get less and less important information in terms of the current task.

It's still important information, it's just not within the context of the Phone app. And so placement of UI elements and content on the screen is also a function of navigation because once you're in a room, it's like, "What do I do in this room?" Once you're on a screen of your app, what do you do on this screen? So where you place things is a function of frequency of use or importance to the user. So, you know, give it visual emphasis.

Give it the right positioning towards the top or towards the bottom. And focus on the purpose of each screen. Keep asking yourself as you're deciding to put a button on the screen say, "Is this important now? Does this add or detract from what the user needs to do on this screen?" And if detracts, it shouldn't be on there.

And so this is Calendar, we talked about that several times. And so we've got the controls at the top -- frequently accessed. And then you've got less-frequently accessed -- well, you've got the changing dates in the middle of the Calendar -- mentioned that earlier -- and then towards the bottom placement, less important, less frequently accessed by the user, less on their radar if you will. You've got the navigation for things they do less frequently. All right. And now over to Jay to talk about these concepts as they apply to iWork.

Thank you, John. When we thought about bringing iWork to iPad -- that's Keynote, Pages, and Numbers -- the goal was really simple: we wanted to capture the heart and soul of these apps and bring them to a new platform. Now in doing so, we had a couple challenges that maybe most developers won't have. First of all, we're dealing with 3 applications here -- 3 apps that we wanted to have a real consistent look and feel, wanted to make sure they family together, wanted to make sure that they have a consistent set of interactions and behaviors.

So I know a lot of people aren't building 3 apps. We're taking Desktop applications and putting them onto iPad and that may be more relevant to some folks here. But regardless of whether you're building 1 app or 3 and regardless of whether you're already taking something that you've built on Desktop and bringing it over to iPad, there's certainly some lessons here that you can get from our experience.

Now John's talked a lot about organization and structure and that's the first thing that we did when we decided -- or taking a look -- at how we're going to proceed in building these apps for iPad. And essentially for the iWork apps, these are content creation tools. And that was a big part of what we wanted to do -- was show that the platform could really support apps that not just consume content but they were able to build and edit content as well. And in terms of structure, the user's content is key.

We had to make sure that the user's content is going to remain front and center in the whole experience. So as you can see, the user's content is front and center and we've created just a little bit of UI around it. There's not a whole bunch of UI that's kind of imposed on that experience.

And really, the UI is in 2 areas: there's navigational elements that allow you to work within your documents, to get around in your document and then there's a top toolbar. And a top toolbar is essentially all the UI that you need to go about the business of building your content.

And just really quickly to recap what we've done, we've got this down to just a number of UI elements. The first, left to right, is My Documents -- very clear what it does, it takes you out of the current documents, puts you in a place where you can see the documents you've already created, you can manage them. And it's also a jumping off point to creating a new document.

Next is Undo. This is the one command, the one piece of functionality that we thought was so important that we brought it up to the top level surface. It's kind of obvious but the File Name, the document name. This is just a key way to keep the user, you know, informed of where they are in your application. And on the right-hand side, there's 4 buttons.

We reduce it down to 4 buttons that are essentially the stepping off points to all of the functionality that you're going to need to build your content: the first one of these is Formatting -- essentially the inspector where you set all the formatting attributes to the objects you're working on; the second is Insertion -- you can add photos and the native objects, charts, tables, shapes, and text; there's Tools so these are document settings in Tools; and lastly, there's one button that removes all of the UI so it gives you a very clean experience to consume and see your content without any obstruction. Now we also wanted each of these apps to have its own identity and to embrace some kind of metaphor that was true to the application and to the task at hand.

So in Keynote, we took that concept and we bundled it in with the main piece of navigation, the Slide Navigator in Keynote. And the Slide Navigator is one of the hallmark features of Keynote on the Desktop and we thought it important to bring it over to translate it to Keynote on iPad.

So the idea here is that this is a fundamental piece of UI and we will surface it appropriately. The other thing we did is kept the pallet really neutral in Keynote. And again, to let your content come through. In Pages, we took a little more liberty in branding. Your content maybe isn't going to be as vibrant and saturated.

So we have some opportunity here to brand the app and give it a unique look and feel. And we did that by building this Ruler -- still making functional, the user can choose to see it or not but it's something that really gives the app a distinct quality.

Another thing we did for Pages was the Page Navigator. And this is something where we made a conscious decision not to have a concrete or persistent piece of UI for this. You know, we could have had a list of thumbnails but we decided that basic navigation was simple enough; scrolling is very easy. But this is a way now to, you know, navigate long documents and we built this tool, essentially a loupe, and we were able to give it a very distinctive look and feel as well.

In Numbers, again, minimal UI but UI that we were able to craft and give something textural, get some production values into it. And here it's also around navigation and the concrete metaphor is a File tabs. So there you have it. It's a simple philosophy that keeps these 3 apps feeling consistent, yet gives each of them the room to be unique on their own terms. And the bottom line, like John says, if your app is well-organized, it's going to read well, it's going to feel intuitive, it's going to be easy to understand.

Think about this and these concepts as you go about building your app: does your organization support what's going on in the user mental model; are you presenting the main workflows clearly and understandably; are you presenting a UI that's efficient and uncluttered; and are you giving an experience that's going to be just really easy to understand and read? Next we're going to talk about reduction. And really, I boil this down to 3 concepts: simplify, prioritize, and innovate. Simplify -- how many times have we heard this? And as often as you've heard it, it's absolutely true when building apps for the iPad.

It means that you don't have to, you don't have to make watered-down single function apps, you don't have to make underpowered apps. But what it does mean is that whatever you do, keep it feeling simple. There's no need to overwhelm your users with a thousand choices all at the same level. This is Keynote on the Desktop and we're really proud of what we've done with Keynote, Pages, and Numbers on the Desktop.

But there's a lot going on in these apps on the Desktop. We give the user a lot of power, a lot of flexibility, a lot of control. But let's face it, there's a lot to manage: 335 Menu items, 154 Mapbar items, 64 shortcuts, a thousand places to click. There's a lot going on, on the Desktop apps. Now, we think we've done a really good job of disclosing that complexity and offering it to you on the Desktop. But we're still bound by legacy conventions on the Desktop that we don't need to bring to the iPad.

These things simply do not translate, nor should they translate. The iPad is a brand-new platform, the conventions are just emerging, it's an absolutely wonderful time to be developing for iPad -- no Menuing system, there's no Windowing system, there's no File system. Already you've got a head start in keeping things simple.

So whether you bring an app over from the Desktop or building an app from scratch, be true to the platform. So I want to go back to Keynote for a second and talk just about the Inspectors. The Inspectors here are a primary way of building content, setting attributes, formatting things, Keynote on the Desktop.

And we've made some real simplifications when we've kind of doing the same tasks for iPad. So first of all, there's no window to manage; the Inspector's a popover. And already we're kind of taking away some of the complexity. Another thing we've done is we've made the Inspector dynamic, which means it responds to the current context that you're on.

On the Desktop, you can have as many Inspectors open as you want, there's 10 tabs at the top, you get to decide which tab you want visible, there's 9 subtabs underneath, you get to figure out what kind of Inspector you want to have open, how many you want to have on the screen, where they are. Again, it's a lot to manage. On iPad, taking a lot of that away. So if you have an image selected, you get an image Inspector. If you have a table selected, you get a table Inspector. If you have a chart selected, you get a chart Inspector.

It's just a lot less overhead to impose on the user. Prioritization is a key concept as well. One of the things that this means is: well, what features do your app really require? We made some cuts as we brought things over from the Desktop to iPad. And these were hard decisions that we had to make about what's most important in this experience. Another concept of prioritization is how you surface features in the app. So again, going back to the Inspector model, this is a chart Inspector in Keynote.

Here you can see the top level -- very, very simple. You can drill down in, you can get to more complicated options, you can drill in again and get to more options. So this concept of disclosing is very important. In this example we're talking about how to change a chart type of a chart that already exists, in this case, going from column to bar. Now this isn't something that you do all the time; this is not something that's required for creating a chart. It's not at the top level.

You have to drill in 3 steps to get to this but it feels all right because in respect to the frequency of use, there's a good payoff and a good balance. The last thing you need to do is to innovate. I want to talk about one example that we did across the 3 apps, Keynote, Pages, and Numbers. And again, looking back at the Inspector, you can notice the top-level choices we provide. There's 6 icons there, 6 thumbnails. What we did is we decided to package and create collections of attributes, collections of styles.

So instead of tapping 30 times to get to the right selection of, you know, whatever -- a data point label or a tick mark -- and then find the UI to set that attribute, we built these packages that do all that for you. So in this case, it's really easy, really efficient, and really satisfying to tap through these collections and see how they change the look and feel of your object.

And we've done this across the board. We've done a lot of work so that each template, each theme, has defined for every object that the app knows about -- every chart, table, shape, text, we've collected attributes and we've produced these packages that go with the theme. So it's now very convenient for a user to see that they can get very different looks and feels without having to spend a lot of time tapping through, making selections, setting attributes.

But of course, as we showed, we still prioritize and disclose, so that we do offer advanced features -- you can get to them, you just don't have to and they don't get in your way. So when you're looking at how your app is organized, looking at what the top-level user experience is going to be, figuring out what functionality is necessary, keep these concepts in mind: how can you simplify; can you cut non-essential features; can you make sure you've got the right prioritization level for your features -- the ones most used very near the surface, others pushed down a little bit; and how can you innovate -- what things can you come up with to make this feel more natural, to make it feel more efficient, to make it feel more friendly and fun and to make it feel like it all makes sense? I'll have John talk about appearance.

John Geleynse: All right, talk about appearance. You know the appearance of your app is its identity. We said in other Interface Design presentations we've done in the past, we've talked about how your icon is your calling card. Well, on iPad and on iPhone, the appearance of your app is definitely the identity its identity. And you know, as we move to iPhone 4, with the Retina display, the appearance of your app is going to take on even more importance.

Structure influences your appearance as well. Why is that? It's because as you determine your structure, as you determine user mental model, there's going to be certain objects that bubble up to the top as being priority. In many cases, those objects are going to have a clear real world metaphor. Some cases they don't, and that's okay. But in the cases where they do, the appearance and the way that you implement or sort of design for that real world metaphor is going to be key.

Now the best place to start in terms of delivering a really great experience, a great interface design for your app is to read the HIG we say this all the time and yet I still meet with companies who have not really read the HIG -- somebody did but not the people I met with. And so just so reminder: check out the HIG, read it from cover to cover.

It's not exactly a novel but there's a lot of great stuff, there's a lot of great conceptual material at the beginning and implementation material further, further through. And it's not meant to be the be-all and end-all of everything. We can't possibly write a book that just documents every scenario that you're going to face.

But you can come by the HI lab, you can contact me after the show, and we can work with you individually to contextualize the content of the HIG for your app. But it definitely is the first step for everybody. But let's take a look more closely at at some of our apps.

You know, that was, that was Notes. This is Address Book, our Contacts, we talked about that. Here's a third-party app: it's called TabToolkit by Agile Partners. It looks like a sheet of music. Notes looks like notepad, Calendar looked like a calendar, this looks like a bit of sheet music. This is an app that teaches you fingering on the fretboard or on the keyboard as it plays through the sheet music.

You can slow it down, you can speed it up. It's all about teaching you how to play guitar or play the piano or any keyboard. It's an incredible app and it looks like essentially it looks like a sheet of music. That's great design. Great anti-aliasing display, I mean this is a really great app.

Well, what is it about these examples that I've given and earlier on in the session that we've talked about that makes them so great? Well, it comes down to the fact that our human visual system is wired in a sense to understand real world situations, to real world objects. And the apps that reflect that in a sense -- that reflect the real world back to the user in ways in certain ways -- are instantly familiar and approachable because they're like the real world.

Contrast that with the kinds of things that we've seen on the Desktop for a couple of decades. Now, not everything has been like this, and I'm not picking on this app particularly. But think about what you just saw and now look at this. There's hardly anything on this screen that's familiar to you.

And in fact, as a result -- maybe there's a keyboard on here, there's something that looks like a keyboard and so you instantly zero in on that. Isn't that interesting? And it's because our minds are wired to see things that are familiar to them, that are in the real world to it. And there's so many things about this screen that are just wrong. And it introduces, actually, a significant cognitive load for the user.

People looking at a UI like this, whether it's on the Desktop or wherever, are going to be fatigued, it's tiring to use, and you're not even aware of the fact that it is. And that's on the Desktop. Imagine if something like this was on a Touch device like the iPad.

I mean, you would hesitate to touch anything on this screen, not to mention the fact that there are all kinds of design issues here: there's way much on the screen, so to Jay's point about reduction; the elements are too tiny to touch; the keys are too tiny to touch; you have all kinds of mistouched elements and you'd have to revert and there's big problems. So don't do this kind of thing.

Instead, what we're trying to do and what you should be trying to do is to mimic the real world wherever you can. So look at these apps, keep showing you these. But it's just a significant point because the iPad becomes these apps when it's running them, right, to Adam's quote.

Now, as you do your structured definition, as you determine your user mental model, you come up with this key objects and you might in many cases say, "Oh, that's there's a great real world metaphor for that calendaring," you know, these kinds of things. And you should you should build on these metaphors because they make the app familiar to users. But be careful not to force them.

There are going to be times that you might want to use it but the decision really should come down to whether or not using this metaphor -- implementing it within the design of your app -- will enhance the user's understanding of the app or whether it will detract from it. You know, the real world is limited sometimes in terms of what we want to accomplish digitally. And so not every real world metaphor makes sense; it's simply a frame of reference -- sometimes it works great and other times it doesn't it doesn't work so well.

Case in point, Mail -- Mail on iPhone, Mail on iPad. It doesn't look at all like what you would instantly think of as a real world metaphor for mail, which would be envelopes and stationary and these kinds of things, right? That wouldn't work. It's an idea but it's not going to work because the point of Mail is to focus on the content that matters to people, which is the Mail message and to give them the ascalable, efficient UI to move quickly between messages and respond and send them and do whatever they do with Mail, with email.

So this is a great design for that and it's not a real world metaphor. Now, as you implement the UI design, as you implement the visual aspects of your app -- the appearance -- keep in mind some of the attributes of real visual scenes and use them. I mean, for example: non-straight lines -- nature of abhors non-straight lines. Don't look internally at this building. Anything that we build as people, as humans has got lots of straight lines typically.

There's lots of reasons for that. But if you look at the natural world, not a lot of straight lines. So bring that into your design. I mean, take a look at Notes closely. You've got the free-form highlight of the active note. It could have been just a rectangular highlight like, you know, shine or something. It isn't. It's much more relaxed. It's more kind of casual like note-taking is. Same thing with the icons, they're hand drawn. The idea is casual, relaxed. They're not straight, you know, precise icons, photorealistic icons. Take a look at the in the left corner, the angled leather here.

This could have been rectangular, you know, rectangular 90-degree corners. But we decided to put an angle on there to just introduce kind of a sense of familiarity; it feels more like the real object. How about at the top of the Notepad? You've got the torn paper. This is true on iPhone as well, Notes on iPhone. And what that does is it makes it instantly familiar. You kind of get a chuckle out of it because you're like, "What a great attention to detail." But more importantly, it actually breaks up the hard edge at the top. It softens those those hard cuts, visual cuts.

And then around the edge of the Notes app, you've got this double stitching in leather. I mean, it's great. Is it necessary? No. But it's totally delightful and it doesn't detract from the design and it totally establishes this app in your mind as something that's awesome, right? That's the kind of attention to detail that delights and surprises users. And that's the kind of detail you want to build into your appearance. How about gradients and textures and attribute of real world visual scenes? Here's a wood texture -- soft pine maybe, you know? Sanded pine.

Well, where would you use wood in an app? Well, we used it in iBooks for the book shelf as an example, maybe a slightly different wood grain but wood nonetheless. Here's Labyrinth 2 , right? The actual toy is wooden, so it made sense to leverage that real world example and reimplement that digitally. But leveraging a texture like wood totally makes sense. And it looks great.

How about this? Brushed metal. Leather. Think for a second: how would you use those in the Interface design of an app? Well, what we did in Pages -- what Jay's team did in Pages -- is the Inspector button at the top is really a combination of these 2 textures with some different color palate. Isn't that great? How about this? Fabric. A linen texture. Well, Sophiestication with Articles on iPad has a very, very faint linen texture behind the content of their main screen. It's awesome. It just adds a degree of luxury to this app.

And shadowing. This is iBook shadowed down the middle of the page. It gives you the sense of, you know, thickness and page turn, shadowing on the bookshelves of iBooks. And perspective -- turning a page in iBooks. Watch carefully when you turn the page what's happening at the page turn: we are compressing or expanding the distance between pixels to give you sense of, like, the page curving around. It's awesome.

So use metaphors when appropriate, mimic the real world wherever possible because it means that your app is instantly familiar to users, and deliver high fidelity art. And this is no more, you know, this is more applicable today than ever with iPhone 4 on the horizon with the Retina display. Back to Jay.

A lot of times we we talk about the concept of production value and that's just how much polish you're able to bring, how much finesse you're able to bring to the look and feel of your application. John talked about that basic appearance. There's a whole other concept, a whole other axis to consider when building apps for Touch and that's feedback. I've broken this down to just 3 very basic concepts about immediacy, about cinematic feedback, and about appropriate feedback. It's a whole new world, building for iPad. Everything wants to be touched, everything wants to be fluid, everything wants to be responsive.

In terms of immediate feedback, it's a whole different world than the Desktop. On the Desktop, your whole experience is mediated, more than likely by a keyboard or a mouse. On Touch, it is exactly that -- everything is happening under your finger. If you don't give feedback, if you don't give immediate feedback, you're going to fail. It's just not going to feel right.

And there's a whole opportunity here for a whole new type of feedback as well. Just look at the kinds of things that iPad is doing already -- not only our apps but third-party apps. I mean, everything just feels wonderful. It feels rich. And don't forget sound. You can take advantage of sound in your application and feedback.

Already we know what these sound means. You hear it and you know what it means. We all have opportunities to integrate sound in our application design as well.

And lastly, think about what is appropriate feedback. Now here's the third party example -- this is a static example -- just confirmation. In this example it's success on a postcard being sent or failure of that. And obviously this could be accomplished with just a little popover, alert something, text message. But the developers here went that extra mile; they really embraced this idea of production value. They carried through their metaphor in giving you this feedback.

And I want to end on a note of what we did with with Keynote here. And we had a lot of fun. On the Desktop we were pretty cautious about doing animations in the iWork apps. We certainly don't want to get in the way of you using the apps. Here's an example of what we did in Keynote for iPad. And this is very subtle. This shows moving a slide and then we're going to show creating a new slide.

Now, we had a lot of fun with this. We had a lot of fun thinking of ways that we could add value to the experience to make it seem more fun, more rich. Let me play that one again, at least the moving of the slide. So this is not gratuitous.

When you finger down, the slide pops up and it hovers under your finger -- that lets you know that you're in a state where you can move the slide. As you move the slide, we have physics and we have velocity there. There's some intentionality in the direction that the slide it moving.

The other slides move out of the way in a cascade fashion. When you let go, the slide drops, everything ripples. So we thought we're trying to dial this in and get it subtle, rich, but not over the top. This is something you do all the time. When you add a new slide, you're doing that all the time. We don't want it to get in your way. You have to find the right balance of interesting, meaningful, but also appropriate.

So when you think about what you're doing in your apps and when you think about production value and taking it to the next level, there's a whole world of opportunity here in providing feedback, new types of feedback, and really rich feedback. Last, we're going to end on optimization. And optimization means a lot of things, even just more than getting your code to run faster and more efficient.

We hear all the time that the iPad feels incredibly fast. It's very, very responsive. And a lot of that has to do with perception more than anything else. When you're building your apps, you have to launch fast, you have to get very quickly get the user back to the context in which they left, very quickly you have to allow the user to move around the app to get to the places they want. This has to feel just instantaneous.

And you have to sweat the details. You have to get the timings just right. You have to make sure everything works together. If you've got the most beautiful animation and the most beautiful piece of feedback but you can't get it to work just right, you can't ship it. It's going to make a disconnect between what the user is doing and the kind of feedback they're getting. So you have to find ways of making it faster, making it better, making it more responsive.

This concept is about helping the user. There's a whole host of technologies available to you. If you know the user's location, don't make them type it in. You can rely on things to help the user out and not impair them. If you have a discreet list of things that the user's going to have to do, well, don't make them type it in, either; let them pick from a list. Employ autocomplete, autocorrection. These things the platform gives to you to make the user's life easier. Embrace these things.

And see what you can invent to make the user's life easier. See what you can invent to create optimizations in the workflow. I'll end with an example that we have in Numbers for iPad. In Numbers for iPad, we have tables. Here's an invoice example and the table here has cells that are formatted differently. There's some text, there's some numbers, some concurrency, some time, date, and some formulas. And this shows the typical QWERTY glass keyboard.

Even on the in the real world with a physical keyboard, it's really difficult to surface all of the keys that you that you want to have access to. I think we're so used to Shift, Tap, Option, Tap, Option, Shift, Tap. If you can remember those things -- I think we've all internalized it already in the real world. Here you have to find the keys that you're looking for. And even here with the QWERTY keyboard, if you're looking for Numbers, just that one extra step away is too much.

But it's all glass on the iPad. You can do anything you want. So what we decided to do is, "Well, we know the context you're in, why don't we give you the input method that's going to make sense for you?" So here's an example of a time and date keyboard. You don't ever have to type "August" in; you hit the "August" button.

Here's an example of a numeric pad and we also give you format controls. So there's a limited amount of formatting you can do here for currencies, percentages, and whatnot. There's a whole keyboard dedicated to formulas. There's quick formulas here, there's help with formulas, there's access to functions. So we don't make you type anything in to do a formula; it's all tapping and it's all about trying to bring it closer to the surface for you.

In a sense, this is magic and this again goes back to the quote John started with: we can make this thing become anything that we want it to and let's make it become something useful, in this case, for our users and save them save them some effort. So think about this when you're building your apps. Yes, get your code to run as fast as it can but make things feel fast, give the perception of responsiveness. You have to sweat the details.

Think of ways that you could help your users complete the task that they started and see where you can innovate. What can you do to make this all come together in ways that nobody's seen before? So like John said, this isn't, you know, the be-all end-all checklist of what you need to do to build your apps but these are some of the key concepts that we've come up with to try to explain, you know, some of our experience and things that we want to surface as important.

And lastly, we've shown this off in a linear fashion. And you kind of need a structure to get going, you need something to follow. But what we find all the time is it quickly becomes nonlinear. One of the things we do in our group and at Apple in general is we iterate, we iterate, iterate, iterate. We start off with a linear process but we find that decisions that we make in one area ripple out to another.

Things that we learn in one part when we think we're almost done cause us to rethink assumptions we've made or implementations that we've already completed in another area. The one question we're always asking ourselves is: how can we make it better? How can we make what we're doing better? And every time we have an answer to that, we ask the question again. We keep asking it and asking it until we are done. When we have no more questions about how we can make it better, that's when we ship and that's when we know we can make it great. Thank you.

John Geleynse: So just to finish, here's some contact information for myself, John Geleynse, User Experience Evangelist. Feel free to reach out to me after the conference. Please try to come down to the HI lab. We may or may not be able to meet with you because there's tremendous demand but we look forward to seeing your really great apps on the platform. Thanks for coming today.