It's early in the morning. Most of you were probably having a great time last night. So I appreciate that you're coming here just to relax and not get into anything deep. We are not going to cover any major APIs and you do not have to look at a lot of code. We are going to do something a little different in this session which is cover high level guidelines for how to design a great application on Mac OS X, and I'm going to cover specific things that you need to know for designing an application for Leopard.

We are going to talk about what's new in Leopard specifically so that you kind of get a sense of where things are going and how it affects your application and what you can do about it. I want to talk about how to transition your product from Tiger to Leopard and give you some insight into that if you have an application today that is shipping on Tiger.

And then we will talk about user-centric design because while you can do something specific for Leopard, if your application isn't structured correctly and you haven't set things in an intelligent fashion and an appropriate fashion for your user base it really doesn't matter what paint you put on the walls so to speak. So we'll cover sort of how to make an application that is really well designed and it's really sort of platform agnostic in many ways in that regard so we'll get deep into that.

Then we're going to talk about issues on Leopard sort of beyond the application window. I think the first thing is to sort of set expectations here. You are just going to see the tip of the iceberg in terms of guidelines and tips and tricks for creating a great user application experience and there is no possible way that standing up here I could give you everything you need to know about creating to make the greatest application on earth. User experience you know user interface design is a really difficult thing to do and the long and short of it is that it is a really hard to do.

And I have met with a hundred of developers, probably close to a thousand developers in my 8 years at Apple and in every single case I have take the expertise that I've got, the understanding and knowledge that we've got at Apple and really bring that to bear on each individual situation. So each of you has got a product or set of products that has specific set of features and functionality and that set of functionality and features is tuned or should be tuned for your audience of viewers.

But what your audience is, is not necessarily the same audience as someone else's. And your functionality and capabilities of your product are not the same as the next guys. So interface design principles have to be customized and tailored to each individual situation. And you know I follow very closely the conversations on the web and I'm on pretty much every HI discussion list out there. I'm the main contributor for content to the interface guidelines at Apple. I know that many of you sit out there and go I've read those and they don't apply to me anymore.

Well, you might think they don't apply to you because they are maybe not up-to-date and I take full credit for that. We have not done what we need to do in some areas with the interface guidelines. We have some great plans for forth coming and I think you'll like what you see in a certain period of time.

But understand that there is a lot of great stuff at the front of that book in particular relative to design principles that is always a good read but again, has to be tailored to your individual situation. So there is no single book in this world, there's no single presenter that is going to give you all the answers that you need and be able to give you everything you need to create a good user experience on Ten. Just to set expectations here.

But, that being said, we are going to touch, we're going to see the tip of the iceberg here sort of scratch the surface but you are going to get a lot of great content this session anyway. Then I encourage you to come to the HI lab or follow-up with me after the show and we'll spend some time with you and tailor this stuff to your application situation.

Let's begin in the Leopard desktop. You saw this stuff in the keynote and you saw it in the State of the Union. You've seen it in other sessions and probably installed the beta on your machine by now. This is the desktop that you have seen and that you are interacting with. You know it's changed. Windows pop. It's a very, it's changed in a number of ways.

It's definitely a step, a natural evolution in user interface of Mac OS X. The question, of course for you, is how is your app going to fit into this environment on the desktop. Well, the simple answer is use standard controls and windows and don't do customization. The apps that are going to have trouble on Leopard, you know, on the beta right now and the release version of Leopard are the applications that have got customization through and through. They do not use a single standard control. They've changed help, pop-up menus look, you know they've done all kinds of customizations because they want to stand out to the crowd. They want to do something special.

In most cases that is why people customize. In some cases you customize because we didn't give you the controls that you needed and we understand that. We are doing everything we can and I think you'll like what you hear later on the session in terms of what we are providing you in Leopard.

We probably have more to do and we continue to solicit your bugs and feedback. We'll do our best to give you everything you need in terms of a widget set, you know controls and UI elements. You know a lot of developers customize for customization sake. A lot of people sort of want to skin their app in order to stand out from the crowd.

I would say that is not the way to stand out from the crowd. That's not the way to get people to acknowledge your app and use it and sense or feel it's a lot of better. Because, a lot of time, skinning an app doesn't make it better it just makes it look different.

If you are app is still not reliable and doesn't have a cohesive user experience, if it doesn't give good feedback and status communication and if it's not organized and if it doesn't have a good interaction model then it doesn't matter what it looks like it is going to be a dog to use. So the way to fit into Mac OS X Leopard is to use the standard system controls and windows.

And Leopard makes it easy. If you have done that and many of you are on Cocoa today, many of you even on Carbon have done standard system controls and no customizations in terms of windows. All of your customization is just inside your value added window content ad area. Your app is going to transition pretty much in a straight forward manner.

Tiger windows will automatically adapt, etc. So we've got the Leopard desktop and I want to point out what's new if you haven't paid attention yet this week. There is a new menu bar you've see, got lots of feedback about already into my inbox. People have stopped me in the halls.

You know, keep using it, keep playing around with it and give us feedback we would love to hear from you. And by the way, there is a great feedback forum on Friday afternoon at 3:30 Mac OS X user experience forum. We'd love to have you there. We look forward to your feedback there and of course we encourage you to log bugs at bugreporter.com.

What else has changed? Well, we have a new inactive secondary window appearance. So may be difficult to see on the projector here but if you have been running the beta you can tell there is a big difference between windows that are active now versus windows that are inactive, right. So real active windows, the new doc on this on this slide.

So active windows, the active primary window, pops up from the screen and that's mainly because we've got this heavy shadow on it. A larger shadow on the window that really sets it out in front of everybody else. There is a lot more depth to the Leopard desktop than there was previously on Tiger or any earlier revision of the Mac OS X.

And that is really going to be key for usability. I think the usability for users knowing which window is active versus which windows are inactive is really key for them knowing what's going on and hopefully for all of us it will solve some of the usability issues that we may have experienced in that past.

So that's the desktop, you've all seen it and all been interacting with it. Let's all dig deeper into what's changed on the window level in Leopard. So there's a new window look. It's called the unified look. We've unified tool bar and title bar. There is no longer lineation between the title bar of the window and tool bar. It's just a smooth sort of finish there.

We've got no side margins. There is a bottom bar there now which is available to you as developers and you can take advantage into that. There are new controls in Leopard and we've got more standard images in the system that are available for you to use as well. Let's go through all of these.

In Tiger we had a textured window appearance, we had the, what was called textured in appearance in Tiger. So that window type it had rounded corners that you are familiar with. It's got the appearance here but what's going on here is that we've got custom controls used in the toolbar and they weren't available to use. So if you want to use this you have to customize things yourself. We had the metal appearance. We've gotten lots of feedback over the years about the metal.

Side margins in this type of a window, we had Tiger splitters. So the splitter views between different views. Probably the biggest issue here was that across the system I think there were about seven different splitter views. Carbon had a different set. Then Cocoa did, and even within the individual frameworks there were different variants, and then developers were doing their own version. So across the system, if you just sort of took a random selection of multiple applications there was a lot of variation in terms of Window splitters.

And then there's a bottom bar in this particular window, this metal window, and it had custom controls, custom buttons, and you all saw these first in iTunes way, way back, and you know, I got lots of feedback around, hey, how do I do that? Well the answer was, you can't, you need to do this on your own.

And so that was sort of the situation in Tiger, but if we transition to Leopard, I won't bounce back and forth between the slides, but on your own machine, just pay attention, just look at the corners, the corners are tighter, they're smaller, they're a little bit, it's a little bit of a square window, but it just kind of brings it in and we've got other changes on here.

So we've got Leopard tool bar controls that are available to you so you can do this exact same appearance on your applications. We've got the unified title toolbar so there's no delineated line, as I was saying before. There's no more margins on Windows, that's the design pattern that we'd like to see in lots of applications, although you're welcome to put a margin there but the tendency within Leopard is we're removing those margins. We have a Leopard zero with splitter, so between views the mouse is going to roll over these splitters, standard between carbon and cocoa, high level toolbox app.

kit and they're now a single pixel wide and the mouse, the cursor's, going to change over top and you're going to get a consistent experience between all applications with splitters. And lastly, you've got a button bar at the bottom with Leopard button bar controls, which are the same ones that you use in toolbars. So again, you've got access to all of these, you can do exactly the same appearance and be completely consistent with everything else in the system.

Okay, here's the Finder in Tiger, and we had, you know, you've got the sidebar, the shelf on the left there, you've got the wide splitter custom controls and the toolbar, the whole thing. The Leopard finder window is tighter, we've got a source list on the left, which I'll talk about a little later, how to do source lists, when to use them, that sort of thing, we've got live, you know, the thumbnails that have got the actual images in them, the content for the file using quick look. So all of this is just a lot more, it's tighter and it's giving you more information, and it's more consistent across the system.

Safari and Tiger, same thing, you know, the Tiger window-type metal appearance, custom window controls in the top in the toolbar, and in Leopard this transitions, not a lot of change, pretty much the same thing, just now it's got the unified look and it's using the standard system controls that you can get access to as well.

Let's look at iTunes. No, sorry, Calculator in Tiger. Calculator in Tiger, pay attention to the corners if you're interested in little, little details like how we change things. This is the calculator in Tiger, we transitioned to Leopard and it's just a slightly smaller corner curve and the whole window has the Leopard appearance to it. Here's iTunes. So iTunes went through some changed in Leopard as well.

Okay, now pay attention, look very carefully at the changes that are going to occur between this Tiger window and iTunes and the Leopard iTunes window, okay? Are you ready? Did you notice anything? Yeah, you didn't notice anything because not much has changed. So, I'll just help you out here. Watch the blue circles, what happens inside the blue circles.

That's it. So, a big part of the appearance of Leopard, in terms of the unified window look and the control style and everything has been informed heavily by what we did with iTunes over the last couple years. And you saw lots of changes going on in iTunes and of course, there was lots of feedback in the community around well, what's Apple doing with iTunes and why isn't it like the rest of the system, and you know, in many ways we were sort of testing the waters with iTunes, seeing what worked, what didn't work and what the community felt about it and I think that definitely carried forward to what we've done on Leopard, as you can see, not a lot of changes there.

Okay, so new window look, unified toolbar controls available to you, and etcetera. And there's nothing you need to do. If you're well behaved today in the sense that you've used standard system controls and you've just standardized on windows and you've got minimal customization, carbon and app. kit are going to do the right thing for you and your application should transition without a lot of difficulty over to Leopard.

Now let's get even deeper here. So in Leopard there's only one window type. Now, we're talking about document windows, right? You've still got dialog boxes and you've got sheets and that type of thing and those haven't really changed from Tiger to Leopard in any big way, but the window area's where we really wanted to work hard to get a lot of consistency for the system. So in Leopard there's one window and it has some options, some accessories you can put on it and it can be with or without a toolbar, with or without a bottom bar.

So, here's a one window without a bottom bar, it's just the title bar of the window, it's just got a view. This is the kind of thing you'd see in like Text, Edit kind of thing, right? This same window can have a toolbar. So this is the standard window without a tool bar, with a tool bar, no bottom bar on each, they're both resizable, very, very clean design. Or you can have this same window appearance with a bottom bar, but no toolbar.

Or, you can have it with a toolbar and a bottom bar. And that's it. That's the window appearance in Leopard. So your application, as a designer, you know, you need to know as a programmer/designer, you need to figure out, okay, what am I going to do, do I need a bottom bar, why would I have a bottom bar? And we're going to cover all of that in a few moments here.

Just want to drive home the point that there aren't multiple types of windows. There isn't a textured and a metal something or other, and a non-metal, there's only one window type in Leopard, you can have a toolbar, you can have no toolbar, you can have a bottom bar, you can have no bottom bar.

Okay, how do you create on of these in Leopard on the builds that you've got now? Well, in interface builder you drag out a textured window from right here in the palette and you drop it right on the window that's there. And if you want to leave space, if you add a view within that window, you can, if you leave space at the bottom, you can get the bottom bar that you need if that's interesting to you, if it's useful in your application. So, here we can take this view, which is just standard window with a bottom bar but no toolbar, and you can drag in from interface builder a toolbar.

And now you've got one window type with a toolbar and a bottom bar. Straight forward in interface builder. And by the way, just in case you wonder how we do calculator, calculator just the one window type without any kind of a main content area view that would give the white coloration that you would see in like a word processor, you know, there's no lists in there or nothing, it's just the background, the window type, with the gradient fill and then it's got the standard toolbar, or button bar controls, on top of it.

Okay, so that's the window type, now let's drill down into the components of a window. So each window's made up of three parts. We've got the toolbar at top, toolbar, title bar, we've got the content area which is the part that you have the most control over. I mean, you have control over the toolbar and the bottom bar as well, but the content area's where really the magic of your application occurs in a big way, and then of course, we've got the bottom bar here.

So let's talk about the toolbar. So, toolbars in Leopard have a unified appearance, they are connected with the title bar and there's some elements here that you need to be aware of. There's certain things that you cannot change, there's the title bar, the unified look that you can not change, it's got the Leopard gradient, that's nothing that you can change, we've got the hide/show button on the far right side, we've got the close/minimize/zoom buttons, you have some control over those obviously, that's not changed, but these are things that the system provides and it's part of the window appearance.

The things that you can do is that you can add things like search fields and the toolbar controls. So, as I was telling you before, the appearance of controls and toolbars is available to you, these widgets are available to you, and they're called Leopard buttons. We tried to come up with creative names and, basically, we decided no, they're just Leopard buttons. Search fields are provided in app. kit as well as they're available to you, and so, we recommend that they go on the right side, just for visual balance, and we'll get into visual balance discussions later on in the session.

Just in case you care, and you follow some of this trivia, what we called Tiger textured buttons in some of the headers are referred to textured in the constant names and stuff, that's really referred to now in Leopard as rectangular style, okay? All right, so, let's talk about toolbar control behavior.

We just looked at what a toolbar can look like, now what do you stick up there and how are they supposed to behave? Well, let's pop this one out and go through each one of these controls. So, here on the left you've got the segment control, segmented Leopard control, you can have these segment control can be a single segment, in which case it's a single button, or it can be multiple segments. So here we've got two and these operate as a button toggle, they basically operate as a set of radio buttons, right? They go down and they're mutually exclusive, you click one or the other kind of thing.

In this case, we've got the same control, it's called the Leopard toolbar segment control, it's got a force, it's a four segment version, and these work like checkboxes, they maintain state, they stay down and, sorry, in this case they work like radio buttons because you're choosing one view or other, but they do stay down, they maintain state and they show you which one is selected until another one is selected. So you have radio button behavior, you have checkbox behavior, and you have standard pushbutton behavior with the Leopard rectangular toolbar segment control.

Here's the same thing, one segment, but it's behaving as single push button. You click it and it does something immediately, it doesn't stay down, it pops up immediately. And here's the same thing, one segment, but it has a pop up window associated with it, so if you use this standard control, you can pretty much simulate any widget scenario that you need, you can do pop up menus, push buttons, multi-segmented controls that act as push buttons, that act as radio buttons, check boxes, whatever behavior you want, you set it all up in IB, or programmatically, of course through the API's, and you can get all of this behavior with the same control.

There's another control available to you for toolbars in Leopard, it's the capsule toolbar segment control. So rectangular, capsule. Let's pop this thing out and look at it. This is what you're familiar with in mail, this is now available to you as a developer to put in your application.

So this works similar to the rectangular control, here's a set of two, you determine how many segments you want, you can have a single one, you can have multiple segments, here, this set of this two segment version works as a toggle, so they flip off and on. This set is a segment as well, these are just individual buttons that you would push.

In fact, I think in every case on this, in every one of these instances, these are all push buttons now that I think about it, but you've got it multi-segmented so you can group them together and say all of these controls relate to navigation, or these other two related to grouping items, or something, but with the capsule button you can group them together. Now what about other toolbar controls? Well, here's a toolbar that I created and you can't do this. You can't use a standard aqua control in toolbars in Leopard, that's our guidance. So you can't do a standard translucent, standard aqua push button in a Leopard toolbar.

You can do icons on the background, the unified background. It looks great, there's applications out there today that we ran, we took some, you know, I download lots of applications, people send me lots of apps for the App Design Awards, we ran a whole raft of the App Design Award submissions against the Leopard beta build and most of them just transitioned without an issue. And for many of them that had just icons on the toolbar background, in Tiger it looked great on Leopard. So that's cool, you can do that. So use only Leopard rectangular or capsule toolbar controls in your toolbars.

I know this is a little bit minutia and we're kind of plodding through here, but we need to just communicate this to you so just bear with me for a few minutes and then we'll get real exciting and get into design techniques and stuff. So how do you design your toolbar appearance? You want to make sure that you are using system provided icons when possible, we've opened up a lot more imagery for you, so we encourage you to look through the system, use what's available to you inside the system, but, of course, work with folks like icon factory and lots of other companies, Iconizer, etcetera, who do great icon design, and, of course, get them to do custom icons for your application if you need them. For example, a standard image that's in the system would be the gear that's on the action menu and you should use that for your action menus rather than something else, a customized version of the gear.

Create icons using familiar shapes and real world metaphors. So, if you work with a design agency like I mentioned, or other ones, typically visual designers understand this, they're going to get it right, don't do this yourself if you're a programmer. You shouldn't be designing icons for your application, leave that up to folks who understand visual design, who understand what it means to represent a concept, or a task, as an icon, because otherwise you end up with some of the disasters that we'll see in a few moments.

And by default, your application should display icons, have your app launch for the very first time with the regular sized labels and toolbar controls, don't came up with no labels under your icons, teeny tiny little icons in the toolbar, on top of teeny tiny little buttons, make sure that for the first time user of your application that they can immediately see, oh there's grouping of functionality in my toolbar, we're going to talk about that in a few minutes, and they can read the labels and all of that stuff. Make sure that your default appearance is something that's very, it presents a lot of information to new users.

Once users get up to speed they can customize the toolbar and go off and do their own thing, whatever customization they want. Here I've got an example of the keynote toolbar, and you see there's some really great grouping going on here, there's some standardized imagery in the right side, if you're going to do an inspector, pick up the standard eye, the blue eye, that says that's inspector. If everybody does that then every app on Mac OS 10, users will know that if they hit that button in the toolbar they get some sort of inspector.

Same thing with fonts, bring up the fonts panel with the slightly italicized A, bring up the color panel with the color wheel there, with the same label. Use the same labels, use the same icons, let's get some consistency there across all apps on the platform and it'll really be a boon to the platform, in terms of users knowing what to do and having standard expectations inside of any application that they're in.

There's some other icons here that are not, sort of, system used, or used system wide, but they are pretty generic so they are appropriate to be used in other applications that sort of do the same thing. For example, adding a comment in keynote with a little sticky note icon, that's a great icon to use for that type of functionality.

A common question that I get at Apple all the time is, somebody will send me a screen shot, or a portion of a toolbar from mail or from finder or whatever, and they'll say, hey can I use the some such icon from this or that app that's shipped by Apple? And you know, in some cases it's an easy answer, it's like sure, no problem, that's just a generic delete symbol, it's just delete mail, or delete an item or something like that. In other cases, it's an icon that has a particular place and has a particular meaning inside of a particular application on the platform.

At the moment I'm drawing a blank and I should have had a slide for you for this, but if you look around the system, ask yourself if you have this question about which icon you can use, look at the icon you want to use from the system and decide, and figure out for yourself, whether this icon has a particular meaning inside of this app, does it mean one thing inside of this app? And it wouldn't mean the same thing somewhere else.

So, for example, and I just thought of one, which is the home icon. A home icon inside of finder in the past, you know, was a little house with the roof and whatever, that meant go to the home user's, to the current logged in user's home directory, and that icon means that in the Finder, so taking that icon and putting it somewhere else and using it to go to your base web page, or going back to the front of your app, it's overriding the meaning of that icon.

But there are other icons, kind of like a no smoking sign, or a plus, minus that are generic, they mean add, delete or add, remove and in the context of where, you know, they mean the same thing regardless of where they sit as long as they are near a list where you are adding items or they're near a view where you've got, you know, you add things and delete things, they make sense in that context. So certain icons work and they're generic and you can move them around as long as they do the same behavior. Add should always add something, delete should always delete something. Enough on that.

So how do you decide what to include in your toolbar? You now know what the appearance is, you can use rectangular Leopard control, you can use the capsule control, you can use icons in the background, you shouldn't use standard aqua, right? How do you decide what to put in your toolbar? Well, clearly some people have problems with this, and other people kind of get it, but the main thing is, you always want to think about putting things in your toolbar relative to the frequency of use by the user. So if there's something that you want the user, that the user's going to do all the time, you want to give them a shortcut in your primary UI, and the top of the window is primary placement for things.

Same thing for a webpage, if you're designing a website, you put important navigation stuff at the top of the page, because that's sort of the first place people look, in a sense. People don't always read from top left to bottom right, but it's a good rule of thumb to remember that guidance, which is, top of the window, most significant stuff, towards the bottom of a page, towards the bottom of an application window, you do sort of secondary, tertiary functionality, and then you know, frequency of use.

Think about whether the command you want to create an icon for and put in the toolbar, is it global to your application, or is it specific to a particular portion, or a particular view, elements on the window, or particular a mode of the application? And, so, what you'll see in some applications is, you'll have a toolbar, which is perfect because all the commands in the toolbar are sort of global in nature, and then you might switch into a certain mode of the app.

So, for example, the other night, and I don't know if this is exactly the case, but in the Apple Design Awards I demoed Coda from Panic, great application by the way, and congratulations to those guys, but Coda has these sort of modes, your either in edit mode, or in CSS editing, style sheet editing, or you're in terminal mode, or books, and it's great because those modes are up in the toolbar, they're global to the application and then when you choose one of those modes, further down the window you've got a secondary toolbar that has functionality, looks kind of like a toolbar, it's got functionality for that mode specifically, so it's sort of progressive revelation.

You've got this global stuff as users decide the mode, or they do something, now the app changes its state and then you offer users more capabilities. You used to see this in iPhoto, as well, where you had the secondary toolbar and remember, way back you had import, organize, edit, share kind of thing, then if you were in those modes, share then you could create a coffee table book, it's that kind of an idea, where as you drill down in different modes you show different UI.

So not everything belongs in a toolbar. Don't put view zooming controls in the main toolbar of the app if the view isn't always on the main window, or if it's not something users do a lot of, or very frequently. Maybe it belongs below the view, and we'll talk more about that later. Avoid creating a toolbar item for every menu command in your application.

However, make sure that you've got a menu command for every toolbar item, because you can hide toolbars and if you only have functionality exposed in your toolbar, and you don't have equivalent commands for those icons, what happens when the user clicks the top right corner of the screen and they hide the toolbar? Now they can't get at the functionality that was exposed through your toolbar.

It happens a lot, trust me, I look at lots of apps. And the main thing here is, and we'll talk about user mental model in a few moments, but the things you want to put in your toolbar should directly relate to the primary tasks and key objects that the user has in mind as they approach the task that your application solves. This is true for web pages as well, if you're designing a website, a web based application, you want to show, you know, you want to put controls and things in the menu eye that relate to the primary tasks and key objects that the user's thinking about.

Remember, you're designing an application for your users and you are not your user. Even if you've just been, you've moved out of industry and decided you were a fantastic scientist and now you're going to write the best science app on the platform, you are no longer a scientist, you're a scientist programmer and you've started to write code and now it's too easy for your to express the architecture of your code in the UI, and I can't tell you how many times I sit down with companies and people show me their app and it's not designed for the user.

There's too many cases where the structure of the code, the hierarchy of the classes, and the objects inside of the code is expressed in the UI, and it's the wrong way to go about it. What you want to do is come up with a UI, which is user centric in nature, and then you want to take that and have that inform the architecture of your code.

And avoid contextual menus in toolbars. Don't hide functionality in some contextual menu for a toolbar item. For one thing, very, very few users understand contextual menus, it's typically sophisticated users and frequent users who are on the computer constantly, who once they've seen a contextual menu, they get it and they look for it elsewhere, but the majority of users do not know what contextual menus are and how to use them.

Here's a toolbar, and I'll just finish the designing a toolbar thing, here's a couple of principals, again these are principals, they're not hard and fast rules, okay? They're guidelines and we provide these guidelines to you because you're busy writing code, you don't all have interface designers in your companies, so that's what the interface guidelines document is about. It's to provide you with something, some kind of guidance, so that if you don't have anyone else that you can refer to you can look at the interface guidelines. But here's a set of guidelines for designing a toolbar.

From left to right you want to group your items by default because users can customize things their own way, of course, but by default, present the UI that has things grouped this way, which is more frequently used items on the left, less frequently used items on the right.

So if you think about Keynote, in this case, I don't know if this page is keynote, I can't remember, anyway, on the right side you don't always click the fonts panel, you don't always open it up, you actually create slides a lot more often, actually it's keynote, you create slides a lot more often than you would open the fonts panel. And so, just in general, it's sort of a more frequently used, less frequently used type of thing.

But that's not always the case because this stuff is, you have to contextualize this for the given, each individual application, but another way to think about it perhaps is, it's not about frequency of use, maybe it's more around the user mental model. More high profile tasks are on the left, less high profile tasks on the, lower profile tasks are on the right side.

You kind of just want to think about what's the most important thing? If our eye reads from top left to bottom right, then the most important corner of your main UI, of your window, your web page, whatever, is the top left corner, okay? Now your eye scans all over the place anyway, so it's not like your eye - you have to put things in the top left, but it's a good guideline to keep in mind.

Your eye will find things that are bright and shiny and all that stuff automatically, but it's good to keep this in mind. Now that being said about bright and shiny, your eye finding these kinds of things, that doesn't mean you should put honking buttons in your UI so that people find them.

I mean, I have seen so many scanning applications that have horrific UI with huge controls because no one seems to find them so they made them bigger so you would see them. That is not how you design UI, you want to design it in such a way that there's a natural flow in the window, there's a natural progression and it's just there, people find it.

So let's talk about how to group things in the items. So you've got it laid out correctly, you've used the right controls, you've chosen your icons, you know, you've decided which controls or commands and items you want to put in your toolbar, how do you group things? Well, again, this is very subjective.

You kind of have to deal with each one on a case by case basis, but let's just zoom in on this one. New and play, these two controls, top left corner of the window, the first items in the toolbar, they relate to primary tasks in Keynotes, when you're creating a slide deck, you're constantly creating new slides and you're constantly checking what the transitions look like, etcetera, by playing the thing, right? And then you've got grouping here around tasks and options related to the creation of secondary options. Slides are primary objects, slides contain objects and these are secondary controls.

So as we move down the toolbar, we're kind of going down the hierarchy of objects in the application. A slide deck contains slides, slides contain objects, so slides are the first controls in the toolbar, the objects themselves to create them are the second, as we move down the toolbar there are sort of down in the hierarchy, they move to the left, okay? And let's keep going.

Here we've got things, grouped items related to arranging secondary objects and lastly, we've got things that relate to options for opening accessory windows. You don't always open accessory windows but you want to have them visible and available to users because it's a great shortcut to go, oh, I want to change the font, boom, font panel, or I want to change the color, boom, color panel, etcetera.

Some people get this, here's a great CSS Edit, great app, won an Apple Design award, great toolbar in terms of what this application does, great, nice, clean UI. Here's another one, Sandbox. Great UI, great organization of the toolbar, if you use this application you'll understand what I mean, but nice, clean design, the primary objects are over here, creating pages for the website, creating page lets, creating collections and then there's sort of all the inspector stuff over to the right side.

Great design, clearly these guys get it. But, some don't, so here's a disaster, I love showing this one. It's just, you know, everything's all over the place. This dates way back, I think this developer's changed it since now, but it's just such a great slide, I wanted to show it.

Here's another one, you know, just hodge podge whatever the sort of programmer's working on that day became a toolbar icon and you just stick it in there. So, we've got top left corner, remember the most important corner of the application, is preferences icon. How frequently do people changes preferences? Not frequently at all.

In fact, they should probably just do it once for your app and that's it, it shouldn't be in the toolbar, in my opinion. And then just, you know, from down there, just more and more there's no grouping, there's no organization, there's no stylistic, even the visual design of these icons doesn't group them together.

Colors, you know, I wouldn't say colors all over the map, but lots of colors and lots of different designs. Bottom bar, bottom bar in Leopard, you used the rectangular toolbar controls or you use the capsule controls, you've got the Leopard gradient appearance, which you can't change, but these controls are now available to you in Leopard. These are the same ones you'd use in the toolbar and no capsule buttons are allowed, in fact, I've just contradicted myself, sorry. Rectangular buttons only in the bottom bar.

There are two sizes of a bottom bar. You can do standard size, regular size, which has the 32 pixel high regular controls, the rectangular Leopard controls and you can do a 22 pixel high if you want to do small controls. So depending on your UI you might want to choose large or small, and two examples of this are address book in Mac OS X, Leopard, this is the small bottom bar and you wouldn't know that until I put up the big bottom bar from iChat buddy list, okay? So you can see the difference in height, it just really comes down to whether you want the bigger controls, rectangular controls, in there, or you want the smaller ones, really depends on your UI, either one is fine.

Bottom bar guidelines, you know, think from top to bottom, most frequently used items at the top typically, less important items, more secondary objects, at the bottom and so think about that in terms of what you put in the bottom bar. Use only the Leopard controls, avoid custom controls, standard aqua controls, contextual menus, don't label things down in the bottom bar because you don't have enough height there. You could potentially, sometimes, put a label beside it for certain items, but not underneath like a toolbar.

And use the standard system plus and minus icons and stuff. Now, let's talk about the window body. This is where the guts of your application is represented. This is where you put controls and you put collections and you put photos and you put all this stuff that your app does, obviously. You have full control over this area.

Now, a lot of the applications that I look at are well traveled, got to lot mileage on them, been around for a long time, been around the block a few times, got a little beat up, a few broken windshields, kind of thing, and if you just do, sort of, a blind application of the guidelines, you're going to have an app that looks like this, a bit of a beater.

And if you don't think even about placing the toolbar icons and stuff, you'll have this kind of vehicle, so to speak, software vehicle. What you really want is something like this, right? You want to totally make an app that's totally great and that's why this next section is so key.

It's important, regardless of what paint we put on Mac OS 10, and how closely you adhere to that paint, so to speak, to take a renovation analogy or home building analogy, you have to have things structured correctly, so let me take a few moments to talk about user centered design.

First of all, you're going to decide what is your app going to do, what problem are you going to solve? Do one thing and do it really, really well, don't ship everything and the kitchen sink in terms of features. Do one thing and do it really, really well. Sandbox does a great job in that regard, CSS Edit nails it, Coda has five modules, but they combine all this stuff to do one thing, which is to be a web IDE, and there's lots of other examples as well.

So the best way to do this is, figure out what you're going to do and then come up with a product definition statement and whatever you come up with, that should define and drive everything that you do. It should act as the filter through which you decide whether or not features are added to your application, or whether they're left off.

So, here's typically what your app does, right? If you think about what you're application's going to do, next application, or what your current application does, you could list all the features. And here's just a version from last year's presentation where I had an application on screen that was a file editor hex byte, you know, thingamabob. So, first of all you could list all of your functionality of your application, but that's not a product definition statement, that's what the app does, and it's all of the features of the application.

A product definition statement takes those things and boils it down into a single statement about what the app does, and that statement determines everything about what you add and what you don't, you know, in terms of functions, what you add and take away. So in this case, a file snooping and editing tool for highly technical users, hmm, highly technical users, that's going to impact the terminology you use onscreen and it's going to determine the functionality that you add to the application.

But notice, it's not a file decompression tool, so you don't want to add, anyway, you don't know the application because I didn't show it to you this year, but just think about what you're app does, or what you hope to do in your next application idea and first just kind of list all the stuff and then kind of, summarize it in one statement and use that statement to filter everything.

And I can not emphasize this enough, and if you come to a certain point in the design and development process and you go, you know we've got this new thing that so and so suggesting last night, a feature, and it doesn't really fit into this product definition statement, what are we going to do? Then you need to get together with all the decision makers and decide, perhaps the product definition statement is a little bit too tight.

Maybe you do want to expand it slightly, but always go back and double check everything because if it doesn't fit in and you're absolutely certain that that is what you wanted to build, then leave it out. The best solution's today on Mac OS X, or any platform, best products, everything, are the products that have the best usability, best user experience, not the products with the most features.

So, user mental model is key in this whole thing, understanding what your users are thinking is critical. So the user mental model is the way the application is perceived and designed from the programmer's perspective. No, it's not. You do not want to express your architecture design in the UI, it's not about you, it's about your users.

This puts the burden of learning your application on the user, they have to figure out what in the heck you were thinking when you created this thing. Why is this button here? What does this view do? Why do I have to drag this and hold this key? Etcetera, etcetera.

Mental model means, the definition of mental model is the way the application is perceived from the user's perspective. How are they thinking about the task that they're trying to get done with your application? That's the right way to do it. Okay, so how do you in 60 seconds here, how do you apply mental model to your design process? Well I've got a very simple self help formula, very simple technique that I teach to people in the HI lab and anytime I meet with people, and that is first, number one, identify the objects and the tasks that your user is thinking about.

So, if you were designing a music playing software, this example I always come up with is iTunes, if you're designing a music playback tool, you want to think about what are the things the users are thinking about when they're considering a piece of software that would play and organize their music.

Well, they're thinking about things like tracks and songs and albums and iPods and maybe a store, and searching, okay, searching is a task and so you list the objects, albums, songs, devices and that sort of thing and then you list, equally, a second list, you build a list of the tasks that people are going to do. They're going to burn, rip, mix, equalize, search, play back, control, you know, fast forward, etcetera, those are tasks.

Then you prioritize those tasks, you don't just do this by yourself, call together a cross functional team within your organization, get documentation writers, get product managers, get decision makers, get all kinds of people together, sit down for two hours, three hours, a whole afternoon, whatever, and explain the task, send people off for some homework, get everybody back together, have each person present their ideas and collectively come up with, okay what is the definitive list of objects the users thinking about? What is the definitive list of tasks that this application's going to do? And then you prioritize those, which are the primary tasks? Creating a slide might be a good one, you know, etcetera, in terms of Key Note.

And then you take that and that's going to inform the UI that you create. And this is going to inform everything, it's going to inform the presentation of information on screen, how much space things take up, it's going to inform the interaction, what you do next and how it occurs.

It's going to inform the structure and organization of your menus, because from left to right you want to do primary to secondary, remember that diagram I did for the toolbars? Same thing for your menus. It's going to impact the terminology and labeling, you're either for very technical users or very non-technical users, that kind of thing.

Always ask what's important now when you're designing the UI. What's important now? Think about the mode your application's in and only put UI elements on the main screen, or in the dialog box, or in the panel, whatever, relative to what the user is doing now. Don't put stuff in there that they're going to use later on in the workflow. If it doesn't apply now, don't put it in the UI.

Your main interstate is the most valuable real estate that you've got and you've got to be careful to not overload it. There's too many applications today on multiple platforms, but all I talk about is Mac OS X. Too much UI. The hardest job for a designer, the hardest job for as an interface person; somebody that cares about this is to simplify.

There's nothing harder than simplifing and I think Apple does this really, really well. It's a brutal process of doing something, coming up with prototypes, then saying to yourself, what can we take away? What's not necessary right now? And there's always the urge internally as a programmer particularly and perhaps as a product marketing person and there's probably managers here. It's very, very hard to fight the urge to take away features, and just because it comes off the UI doesn't mean your taking away the features, you're making it more approachable by the users, so keep that in mind.

Here's iTunes. Let's go through this mental model exercises, okay? So, here are the tasks and objects or concepts, so objects, songs, collections, devices, concepts, tasks/rip, playback, search, mix, burn, organize. These are al the things you do with iTunes. It's not a comprehensive list this is just illustration. So, then you figure out what are the priority tasks, well play back and search is key, organizing is key, burning and mixing well you may do that, but it's not always done, collections and songs are key devices, I don't know actually it turns out that devices are just collections.

They are just containers of songs. Play lists are containers of songs, the music stores is a container for songs, iPods are containers for songs. Shared users are containers for songs, so collections are big on iTunes. So, songs are a key object. It's a primary; it's the number one on our list.

We just went through the exercise as a team. It's the number one object, so it dominates the UI for iTunes. The most secondary thing is organizing. It's an important task and here's where the science of UI design comes in, because sometimes objects and tasks are related, anyway you have to think through those sorts of things, but in iTunes organizing is a key task and collections area key object so they go in the left.

Why? Because from left to right you want to go general to specific options. You want to make choices over here that percolate to the right, that flow to the right. That's why column view and finder goes from left to right. You pick the hard drive, then you pick the folder, then you pick another folder, trial folder, etc., etc. Now a key task primary task for users in iTunes is playback, top left corner. No preferences icon.

Status, communication of information to the user is it primary? Well, you know one could talk about it or probably six different ways, but we put it there because it's important when you shrink the window down that it stays in the same place and it definitely is important to see what's going on and see progress, so in terms to visual balance a whole bunch of reasons why it's where it is. It is important for users, so it is in the primary UI. And searching, searching is important.

It's appropriate to put on the right-side of the tool bar just from a consistency point of view and a visual balance point of view and it's a primary task as well, because finding your music is key. And then, the bottom bar in iTunes you know you can hide it, it's got stuff in it that you do access, but it's not critical functionality it's miscellaneous, so keep that in mind from top to bottom, frequently used primary, secondary.

Don't put whatever the word after tertiary is fourth level importance down at the bottom. If it's fourth level importance it shouldn't be in the main UI, it's should be up in a menu command cause it's rarely accessed. I get all passionate about this stuff. Okay, so once you've gone through this exercise what is the next step? Pull out Photoshop and start making mock-ups, right? Pull out interface peeler and start clicking and ragging bottoms and building list and doing all this stuff. Answer is no. My personal opinion is no. Some people do it that way great, that's your thing and if that works great.

I recommend something called Paper Prototyping. There's a great book on Amazon called Paper Prototyping. Buy it, read it, it's great. Basically once you've decided your primary tasks, primary objects; you've got your basic you know prioritization done; all that stuff. Now a good exercise for people on your cross-functional design team and don't just give it to once person, get everybody involved in the design process, because everybody has got ideas and good insight into the product.

Not about everything, they don't necessarily know the code, but they might know the user, they might know the kind of tech support calls you get, they might know the issues the users run into. If you're a documentation writer is involved they can provide al a lot of value. Why? Because they understand what it takes to explain how to do something.

So, if they've tried to document something for you in your current shipping version and it took eighteen pages there's a problem there and they can highlight what the problem is, and they might be able to say all this extra stuff here, if you just put this there and blah, blah, blah it would solve it. It would be a lot simpler.

That's good insight. So anyway, decide who the key people are good-smart people, and then takes these designs and start drawing them on paper. Everybody can draw box, everybody can draw a straight line, everybody can write you know a label and everybody can print. There's no/nothing getting in your way to doing the UI with a pencil and paper.

And the reason I emphasis this so heavily is because most companies, most people jump...unless you're a design fine. If you're a designer go into Photoshop, because you live in PhotoShop, but most of you don't necessarily live in PhotoShop. It's not your primary, you don't really know how to use the thing, you don't really know how to use necessarily Interface Builder to its full extent or it doesn't do what you need it to do in terms to prototyping the UI that's very possible too. And the problem is when you start to use these tools to do your mock-up you get bogged down in the fact that the application you're using to build the prototype doesn't have a particular control.

Right? How many times have you tried to do a prototype in Interface, but were not had the things you needed, and so you get bogged down and it's unbelievable how much time you waste fiddling with the application to get it to do what you want and in two seconds you could have drawn what you wanted. So draw it on paper, cut out all the pieces.

Each little icon, each little list, each use acetate, color paper or you know transparent paper to do the high bars on lists and all this stuff and I'm not kidding do this then lay it out like this. This is from a session that I did with a developer. I told him to do this, they went off, they did it, they came back with an envelope full of pieces of paper, we dumped it on the table and we started to build this thing.

Build it as a cross-functional team, build multiple-paper prototypes and give them to people who are designers or who are part of a design team and get everybody to go away for a week and do a homework project, and then come back and have each of them present what they think the design is, and then get consensus on what the design should be.

Now once you've got this thing designed and it's easy to move around, you can have conversations, you know the boss or whatever comes in and says no, no, no that list has to be over here, well he can just grab it and move it. That's easy, but you come up with a great result. I'm not kidding.

The results I've seen through this process are fantastic and then once you've got consensus and everybody agrees, then you take a photo of this or something; digitalize it and now give to someone who can build this in PhotoShop or Interface Builder. We've got to keep moving. Oh, my goodness.

Feature groups, so when you're designing this thing think about feature groups, think about the primary objects, the primary tasks, secondary objects, secondary tasks and construct you UI based on these kinds of concept areas, these tasks, functionality, work flow blocks. Think about your application not from, Eww I need a blue button here, think big, think concepts, think block and get that down right first. It's like when you renovate your house you don't say I would like to have a pantry here that is 3 feet by 7 feet by so many feet.

You just say hey babe we need a pantry right here. You know wouldn't it be great right beside the okay right and we need to move the stove here and we need to do this and you do these big picture things first. You say you know w hat let's put the kitchen over here, so we can look into the back yard. Okay great that's a modular bid picture move like in one of these feature groups.

Okay you know where the kitchens is going to be, now you can start to eventually focus on what are you doing in the kitchen? Oh well let's put the pantry over here, let's put the stove over here and you get more and more granular in that block, in that space. Same thing with software Interface design.

Have a predicable workflow left to right, general to specific. You choose collections, you populate that way. It's a guideline so lock into this, but it's a good guideline. General to specific, left to right, top to bottom, you're going higher frequency/lower frequency, primary/secondary okay. Left to right, top to bottom. Think that way.

It isn't actually like this, but these are great guidelines to work with for people who are like designers trust me these are what you need. Okay, when your building the consent for your main window, whether it's a dialog box, a sheet, whatever these still exist in (inaudible) nothing changes, there's some basic things are that in the interface guidelines, but I'll just talk through them very quickly.

And that is there is a concept of center equalization, it's about visual balance. You know so you take the is one and say and you say it seems easy enough The window in half and I'll balance everything around that, right? If you put a box around everything, which is what you should. Design your UI, then put a box around sort of a bounding box left most, right most, gilfs, etc. Seems pretty straight forward, center that thing in the window, its mathematical correct, but it's not correct.

Now I know this is a designer talking and it's like okay big deal most of you are probably gee I'm just glad it works, and there's no bugs, but that would be good enough. If most you did that I would be a happy guy, but just to get it right, this ain't right.

Okay it's mathematically correct, but what you want to do is take the visual weights and you want to sort of balance if you weighed the text on one side of the line versus the text in there control like check boxes and stuff, they are heavy. You're kind of teetering around. You want to get visual balance, okay? You don't want to center align everything for sure, which is what's happened here.

You get his like jagged edge, you want to take this and you want to get this balancing, this weighting, weight on either side of this balance, so you build a box around it, remember what we did before, now I've actually shifted everything over beside the weight of those long lines there is a little heavier you know it's balanced now actually with the weight of the check boxes. If you imagined that pixels had a weight sort of a collected weight of the pixels on either side of the line. Keep that in mind. I know most of you will probably forget it, but hey it's on video now.

It's really about a visual balance. Here's another example from an application that I redesigned last year in my session. You know bounding boxes around it and it's centered in the window and this isn't only for techs, these are my examples, but even if you go to very visual UI lots of graphics and thumbnails, you just put a bounding box around it and balance it visually. Kind of funny to say not just for techs in the slide and just have techs in this slide.

Okay, a line labels and controls, so when you're labeling anything in sheet or a dialog always write a line, the labels along the colons like this left the line that controls. Same thing here, you want to left the line the dependants so you see size and points there is at left edge of the S glyph and the left of the A for add is alliance. There is a clear indentation, okay? And Interface Builder doesn't always do this exactly that way I think so you have to anyway, please try to remember and we'll try to fix the IB as well. Maybe it does it right now.

Use white space to group items and controls. Don't always put group boxes around everything, don't always put separator lines everywhere and if you do, if you do draw lines in your UI make sure they are not black. 75 percent black please. It's a little softer, it's happier, it's more comfortable. So use white space to group items and controls so here this big blocks of kind of big separator areas between these items, and that's okay that's all you need. Your eye need to kind of break up these blocks and it realizes that they are grouped.

Here's a different spacing up there, but it's a spacing none the less. There's not uniform spacing between everything along here. Put controls near the objects they affect, so here we are whether it's a window or a dialog box with a list or whatever I can't tell you how many times I find applications like an add button for a list and it's like way over here and the list is over here or something and there's not connection between these things. Place things you know, it's like in your home okay.

There's some homes with great old Victorian homes or whatever and they were wired like rewired sixty years after the place was built. IF you've ever been in a house where you walk into a bedroom and you flip the light switch and nothing happens, but hey light comes on in the hallway or something. That's kind of the same experience you have sometimes in software.

You click a button and something over here happens or it's a bit strange. Generally what you want to do is group. Put the controls, so adding to that list we kind of have a standard were come do on here Mac OS X put the controls near the list. They don't have to be at the bottom.

That's kind of s standard we are doing, but put the controls that effect a view near the view. Maybe above, maybe beside, but hey should be near it. In this case we are doing little single splitters, so we are grouping them all together. Here is an other one joined with that list, here's the added button joined with that panel.

Controls near the objects they effect, again the controls down here that effects with the play of stuff over there, but not entirely, but generally. Control pay back status; these controls effect the view there. Now one can argue they should be down below that one. It's a bit of visual balance, it's a bit of well that's what iTunes did, but keep the general principle in mind.

Okay, can I put new Leopard controls in the body of my window? No! Only standard option controls goes into the body of you window. Leopard, rectangular, and capsule controls go in tool bars, Leopard, and rectangular buttons goes in bottom bars. No aqua in toolbars, no aqua in bottom bars only aqua is in the body no Leopard specific tool bar or bottom bars in the body.

Use standard aqua in controls, so here's an example: standard scroller, standard combo box, standard scroller over here, slider thingy. Source lists. Source list are new they are now available to you in an API and Mac OS X, so that you can do what you see happens in iPhoto, iWeb. This is me at the Design Awards like year, pretty chic. Hugo Boss suit I'll say and you see source lists everywhere, you can now do these. A source list is a great file system obstruction that's why they're so great.

You can drag imagines into a collection, into an album and the ser doesn't need to worry about where the images were, right? iPhoto takes care of that. iWeb worries about where the files are in the system, the user doesn't. In the Finder now you can have these collections in the source list. The user doesn't need to worry as much about where these things are cause the smart folder aggregates stuff from all over the system based on some spotlight query.

That's great for users, so think about source lists were you want to obstruct the file system from users. Think about source lists when you want you've got an application that team more novas users generally because sources are great for protecting complexity, also you know we could have done iPhoto as a document based application where every time you open the photo album a new window opened up wit thumbnails.

It would work, it would be fine, but there's efficiency gained with a source list, so think carefully about whether you can do source list to gain efficiency and whether it makes since in terms of your user mental model that there are collections of objects in as soon as you do your mental model and you realize there are collections of objects and there is a great hierarchy you know what source lists are great anytime there is a collection of objects. That's sort of the primary way of thinking about how things get done in the application. Don't always do sources lists, but in many cases they work really, really well. Could be genes, you know human genes stuff. Could be photos, could be all kinds of stuff.

The appearance of source lists is pretty much dictated by the system, but you do have some degree of control over it. If you're a single source list window and if you have a single source list in your application make sure you are using the white background, you can do blue or white. Make sure you use the blue background for a single source list.

If you have a window with multiple source lists like the font book and Address Book there are two lists you chose the group and you get the name and you get the V card type scenario, then you want to go with the white background. Now, you can do a single source list as a white background in Leopard where we that's fine, but I would say only do that when the overall look of your application is maybe compromised some degree by the blue. You might have a color scheme inside your application were blue is like yeah, white is a much more neutral color that will fit in better in that case. Multiple source lists here font book shows you that.

If you have two level of hierarchy in a source list go ahead and use a disclosure triangle, but if you have more of two levels of hierarchy go to multiple source lists, so you've got this cascading kind of column view please, otherwise you'll have a source list with like you know tweedy down, tweedy down, tweedy down, now you have these honkin' wide source lists to kind of capture this hierarchy and forget that stuff.

Scope bar new in Leopard, it's now available to you as developers. This is a great tool for restricting and refining the searching that the user is doing, so you've seen these before in mail, they're now available to you. They're now in the Finder, they're in Safari, they're all over the system and you can do exactly this appearance and the same behavior and you can restrict this search, so it only appears when the user initiates a search. Don't have the scope bar sitting there the whole time, only show it when they start to search in your search filed.

Use mail, you'll see what the behavior is, and it provides a simple way for users to trick their search. Again, only do a search bar if searching is key to your application if it's a fundamental sort of aspect of how your application is structured where users are searching for objects in a hierarchy.

Scope bar and Leopard works like this. Basically start typing, scope bar appears, and you get the results that are restricted by the scope bar where you can find the search to a particular volume of particular collection or something like that and now you get the results down there that match the search. You've all seen it before, so I won't to spend time here. Animation. And I'm running out of time, but I will get through this section.

Animation is new in Leopard and it enhances the user experience. By adding sort of physicality and realism to the UI in a way we could never do before. It communicates progress, it conveys valuable feedback to the user, it clarifies a process or concept in the since that it shows the user what's going to happen sometimes before they complete their gesture.

It shows for example in iWeb you are creating a website now and you move your thumbnails around; you've all experienced that, that's pre-Core Animation, but it's a great example of where you move this around and you see the impact of your move before you even drop the photo there.

We've actually had animation in Mac OS X since day one and a lot of people didn't realize the genie effect was animation, moving things to the dock where icons separate was animation, sheets and drawers moving in and out, and up and down, and all that. That was animation and it conveys a lot of useful information to the user about what's going on.

Here's a great example of animation in Leopard or it was in Tiger as well. Watch this item, okay the guy appears online, it animates the list very suddenly, very you know very nice touch just shows you to come online in a non-intrusive fashion, so animation is great for placing items in a list.

Animation is great for navigating collections. Cover flow is a great example of that, but it doesn't; have to be left to right, it can be up, down, yes I was talking to a developer great idea for jazzing up what is basically a pretty boring experience in with cover flow type scenario.

Animation when showing it shows results of a not yet committed user action, so here I'm dragging stuff down to the dock and you see this thing moving around the icon are sliding left, right, and center perhaps you're application does some kind of a design and you're moving objects around in your content area you could shift things about of the way if it was appreciate just like iWeb does.

Very, very compelling, very, very useful for users. You could use animation to switch the interaction mode of an application, so here's front row and you get this dramatic UI change and I get this stuff circling around and it's a very engaging great way to use animation. Be careful to not do this thing if you don't need to, doing it just for sex appeal, but it's very valuable in the appreciate context. Time Machine is why you see animation there. Okay, it's also useful for when you change the properties of an object. You could have things animating and you know moving around very slightly so that users understand that something was applied.

It's useful for giving feed back about an action. Sheets, drawers opening, closing this kind of thing. You might have things inside your application were you create a new object and beep the thing just slides, suddenly you know zip moves over kind of thing. It's really, really compelling Now, void the temptation to animate everything.

This isn't like we don't have the experience with animation that we had with fonts back in the 80?s where everybody's newsletter was completely unreadable, because people went completely crazy with all the fonts they could do, so be careful how you use animation. Avoid creating this extreme or distracting animations.

Front Row isn't suitable for most applications. You don't have massive mode changes like that. Animation isn't necessary when you're switching tabs or closing views necessarily. Now Coda does this really cool, you know you choose this site and they turn. That's cool, that's just a nice view transition that makes a since, but I think that's sort of the realm in which you need to be doing this. Create meaningful motions that provide live feedback, but don't do stuff that's you know, extraneous.

Now we've talked about images and bottom bars and tool bars for years you've seen them all over the system the plus/minus button, the action menu all these things you just wanted them so badly you couldn't get them, well it was a ghost town for getting images and it was pretty rough in those days. You have to customize everything, well you know none of them we available for you, but now I'm happy to announce today in Leopard you have access to lots of images in the system including these.

These are the constant mains. You're never going to have time to write them down, because I only have two minutes left. You have these which are in PDF format. Actually back here these you have to use as is. You can not customize these icons, cause they're icons format. Don't change them.

These are PDF format they're scalable, they're tin table you can make them big, small, change their color, they're fine, but just scale them and tint them that's all. They are useful for doing views, so you can you know and these are great examples of icons that are generic in nature they don't have a particular meaning in Finder only.

They're generic to everybody and they should be useful in most cases; locks and unlocks, etc. Alright, I've got 38 seconds left and I'm going to run about one minute over, so hopefully the room director will give me a bit of grace. That's the window and I want to just talk very briefly about some other stuff you're seeing in Leopard that I want to give you some guidance on.

You're seeing more and more transparent panels in the UI. In Leopard you can now do these, but we haven't given you all the transparent window widgets and stuff, so you still have to do some work on your part, but you can get the window appearance. And transparent panels are appropriate, they weren't in Tiger obviously so this was kind of the experience you had, but in Leopard you could do this type of effect. You get the transparent panel.

Well, why is this a big deal? Why are these cool? You know they are sexy, okay. They do look great. I agree, but they're not appropriate in every context, so please help us you know do this right, because I think then they will bring the ultimate you know value that they can bring.

They're appropriate in a immersive environment if you're a photo editor and you live and die by the hours and photos that you know by the number of photos that you produce everyday and you process and do you know your videography live inside a final cut, your world in full screen okay.

Having a very bright panel in white sitting on the screen you know that's not moving eventually kind of burns into your retina. It's a bothersome thing and it takes always from the content you're working on. So putting these transparent panels and notice I'm not using the word HUD.

They're transparent panels that's all they are their just panels. They're not floating windows, not windoids, not palettes, not all these words we used to call them. Let's get consistent with terminology they're panels and they happen to be transparent. Users don't know what a HUD is. They're like a what? A hut? Here's another fully immersive application right transparent panels work great in this environment they don't detract from the content you're working on.

Here's another one, but he point here is do transparent panels when your application is very visual. When you've got video, photos, you know that kind of stuff. Web pages that are very rich visually, perhaps, but it's really for media centric products. Here's some other ones from us. More this is Aperture, here's sort of visual environment of Time Machine.

We've got a transparent panel for QuickLook, but that's because we do it everywhere in the system, so do them if you want to allow brief adjustments to the content without obscuring the window and they immediately apply the users adjustments to the content, so make sure if you do one of these that you don't have an apply button all over them okay. They should just if you move the slider they apply immediately. Media centric applications should do this.

An opaque panel would distract users from the content that they're working on and only do this if you panel contains simple adjustment controls please. Don't pt word processors like huge lists of renaming field and all this stuff in a transparent panel that's the wrong UI for this kind of thing? So here's a great example of that. Here's transparent panel on a full screen mode right down of in the application and then it's in full screen mode.

Now that's the point, if you have a full screen mode transparent panels are appropriate and if that application also have a non full screen mode if you've already done transparent panels for full screen mode do them in non full screen mode, okay. So once you've done them, if you're in an immersive environment, your very media rich, and you've done them everywhere in your application, but don't switch back and fourth between Aqua and transparent, okay or non transparent opaque and non transparent.

So, you don't need transparent panels here, because the application doesn't do an immersive environment it's not visual rich necessarily these are fine, because the system provides them even or here in the Finder, get info. It doesn't need to be transparent. It doesn't need to be there just because, so don't do it just because. Use white or grey text and a small font size.

Create small white controls, use high contrast colors, but in very small amounts. Go into iPhoto full screen mode and look at the little dock that pops up. There's color in there, but it's very small bits of red, small bits of yellow, small bits of green like a few pixels not huge swatches of color in this dark environment, because that would be the same thing as the white, in fact.

So, the transition to Leopard is pretty easy if you've been a citizen so far, you've done the right things, you've used the right controls, you've not customized too much. If you've done some customization the transition won't be to hard necessarily, but there's a lot of stuff you know that we've provide you and we hope you feel really good about scope bars and source list and all this the bottom bars, tool bars, all this stuff we've given you so much more and look forward to meeting with you each individual at some time in out careers so we can look at your application so we can look at your application and make it great on Mac OS X. Thank you for being here, sorry for running over time.