Ladies and gentlemen, please welcome Manager of the Worldwide Developer Relations Mac OS Technology Group, Tim Holmes. Tim Holmes: Good morning. Welcome to session 111. I'm not going to be speaker today, fortunately. There was a chance of that due to an impending childbirth coming. This session's gonna be a little different than many of the sessions you've been to. You've been to a lot of details about technical hurdles you need to get over to move to Mac OS X. You've learned about the technology underlying Mac OS X. But this one is important in a different way.

This isn't just about coding. It's not just about moving your Macintosh application-- or your application to the Macintosh or to Mac OS X. It's about truly making it a Mac OS X experience. There's a lot gonna be covered today. It's a long session, so I won't take a lot of time. I simply want to introduce a man who I consider a true evangelist, the user experience technology manager for Mac OS X and Apple Computer, John Galenzi.

All right, well, good morning. As Tim said, we're going to take a different tact with this session and look at some sort of conceptual ideas relating to user interface design and how to create a really great product on Mac OS X. We're not going to be looking at APIs. We're not going to be talking about coding.

We're not going to be looking at data structures or I/O Kit or any low-level stuff that, you know, a lot of you are looking at in other sessions. We're going to be looking at the high-level ideas behind what does it take to create a great citizen product, a true citizen on Mac OS X under the Mac OS X--the user experience for Mac OS X, which is Aqua.

We're going to do that by first looking at building a foundation for why that's important. By looking at some of the benefits that users are going to gain from this and that you as a developer are going to gain from creating a product that has great design. Next thing we're going to do is look at what are some of the scenarios that you're going to face as you consider adopting Aqua.

How do you allocate your resources? Where do you spend your time? Because there's lots of stuff to do when you bring a product to Mac OS X. And so we're going to look at and help you sort of set the priorities for those decisions. And the third thing I want to do is go in depth on what some of the building blocks are for a great product on Mac OS X under Aqua.

So this is the Mac OS X desktop. We're all familiar with this. We've all, you know, you're all running Mac OS X. You've seen this. You've interacted with it yourselves. But you know, when Apple released Mac OS X back in, what was it, January 2000 at Macworld, we revealed to the world an interface that was unparalleled on any computing platform.

And the reviews that we've seen to date have really attested to this fact, right? I mean, the reviews we're getting are fantastic. They're talking about Aqua in using words like "awesome" and, you know, "fabulous," etc. And, you know, they wrote it. I didn't write it. So, but the reviews are attesting to the fact that this is a phenomenal interface. We use transparency and shadowing and anti-aliasing to create an environment that's incredibly attractive. And that really is the new world in which your apps on Mac OS X are going to live. And that's why I'm going to keep talking about this idea of citizenship.

If you treat Mac OS X as if it was a country that you were going to belong to, that your product is going to belong to, it's going to relate to the citizenship. Are you a stranger in a strange land or are you really a full class citizen and a true citizen of this country? So the benefits of creating a product with great design are many, right? The first benefits for users are they're going to learn your product faster.

A product that's well designed, that has a great intuitive interface layout that leads them through the process of arriving at the solution that your product offers is a product that's going to allow users to learn the product faster. If they can learn the product faster, they accomplish tasks more quickly, because things aren't getting in their way.

They're not confused about where they're going to find some given feature in your product. Windows that are laid out nicely, that are organized properly, that have proper spacing-- and we're going to get into all these details shortly-- are applications and products that are going to enable users to get on with the task that they're trying to get on with. And the software is not going to get in their way.

As a result of those things you're going to increase productivity. So users are going to gain a great return on investment. They purchased your product. They wanted to get a solution from your product. They're getting the solution. They're getting their things done. And so they're going to have great return on investment, which is going to save them time, which is going to save them money as a business or a small business.

All of this stuff matters. And sometimes, when we're developing software, we forget about those end users out there who are using the product. They don't care about all the features, per se, as features. They care about how those things enable them to get the solution that they're trying to arrive at to the problem that they're facing with their business or with their life or whatever.

All of us have introduced Macintosh to somebody, right? We've all sat down with a family member and we started to, you know, we've been preaching them or whatever, we've been talking to them for months or years about how great the Macintosh was. And so we sat them down, finally we had an opportunity to sit them down over Christmas, holiday, vacation or whatever, and we sit them down in front of the machine and we, you know, it's that first experience that matters, right? And I bet you half the audience here will have chosen the wrong product to introduce the Macintosh with.

I've done this several times with people and I remember certain times I chose a product that I will never choose again. And I sat them down and I thought this was the product that would get them to choose the Macintosh. And they started to interact with this thing and they got all confused about what they needed to do next.

Those were products that were not well designed in terms of leading the user into the task at hand and into the solution that they're after. So increased self-confidence, it comes about when products are designed in such a way that users accomplish the things they're trying to do and they feel good about it.

And ultimately, if the users have done all these things, if they're getting things done, if they're getting return on their investment, a positive return on investment, if they're feeling good about themselves in terms of using the computer, they're going to have real satisfaction in the purchase they made from your company.

The developer benefits come right out of this, of course. If you've got satisfied customers, you've got increased upgrade revenue. The chances are that a happy customer or satisfied customer of a previous product of yours will buy a new product is very great, if they have a great experience with that.

Not only that, but with Aqua, specifically on Mac OS X, if you do nothing but clean up the interface on your product, follow the interface guidelines completely, and add all of the functionality that Aqua offers, and add no additional features, people will buy the product upgrade. So you don't even need to add new functionality specifically for Mac OS X, because people are looking for the Mac OS X user experience within your product. And if you just deliver that alone, you'll get a product upgrade, potentially.

So anyway, based on the user experience benefits that we've seen before, you're going to have reduced support costs. If customers are getting things done with your product, Why would they call you? The software's not getting in their way. Why would you have complex documentation if the product just sort of leads the user through the task at hand? Right? So reduce documentation. More positive product reviews. Probably the single most, the single manner in which customers and reviewers are going to evaluate your software on Mac OS X and the quality of your product on Mac OS X is based on the quality of your interface.

If your interface is half done or shoddy or just doesn't feel like Aqua, you're going to see it reflected in the reviews. All of us have read, certainly those who've been on the Mac platform for, you know, a number of years, know about those typical reviews, product reviews that sort of say, "You know what? This is kind of a cool product from a functionality point of view, but it sure feels like a Mac port." Two stars. Right? Don't have that happen to your product on Mac OS X when the reviews start coming out about it.

And gaining a competitive advantage. I'm taking a few minutes on these slides because it's really important to build this foundation for why the rest of the stuff in this session matters. A competitive advantage can be earned by your product. If you deliver a product that has a fantastic user experience, because if you consider all things being equal in a given software category, right, your competitor has the same functionality that you do, you essentially read and write each other's files, you do all, you know, all things being equal, the product out of those two that has the better user experience that builds on Aqua the best is going to have the competitive advantage. Not only for that, but because you're going to have reduced tech support costs, simplified documentation, all the other things as a result.

So how do you decide what to adopt? You know, what attributes of Aqua do you want to adopt in your product as you come to 10? Well, the way to do this, I think, is to sort of lay out a good, better, best scenario. Kind of like we do on the Apple Store with our software, with our hardware, right? Good, better, best configurations. Let's look at it that way in terms of adopting Aqua.

The good scenario is really the minimum. What does it take to create a great product or a good product in Mac OS X? Well, it takes native code for one thing, right? And then it takes these six things. It's not enough to bring your product to Mac OS X, to bring your code over to Mac OS X, to carbonize or to Cocoa, bring your product right in Cocoa or bring it over in Java or whatever you do to get your code onto X. It's not enough to bring, to port your code to X because that just gets you to the operating system. But it doesn't get your product on the operating system, if you know what I mean.

So native code is one step, but it's not the minimum. That's not what we would consider the minimum. The minimum is native code plus these six things, quality icons, respecting the doc-- we'll get into all these in detail in a minute here-- but adhering to the system appearance, adhering to the layout guidelines, adhering to the new windowing model on Mac OS X, if that's going to affect you, and providing user assistance through Apple Help.

That's the minimum. That's what it takes to ship a great product, or a good product on 10, sorry. A good product on 10. A better product on 10 is going to have all of those things, native code and all of those things, plus adhering to the file locations that are default for every user on Mac OS X, saving files in the right places as predefined by the system. Adopting Sheets and doing things like help tags, going to the next step, next level in terms of providing user assistance. And of course the best delivery of a great product or the best way to deliver a great product on 10 is to do all of these things.

Which is add dock animation where it makes sense. Implement drawers, take advantage of drawer functionality. And then do speech enabling your application where it makes sense as well. So, really what I'm saying is that to provide a fantastic user experience on Mac OS X under Aqua, you need to adopt the human interface guidelines. This is a document that's been evolving over the last year. We've continued to, we've had, I don't know, I think it's three updates now.

As of today, there's a new update that's available for download off our developer website. I'll give you the URL at the end. But this document is a dynamic document. It's going to continue to be updated as we continue to add functionality to Mac OS X and as we continue to view what developers are doing and help give you guys guidance in terms of what you're doing on the platform.

So step one, let's go in depth on some of these building blocks for creating a great Aqua application. Step one is native code. You all know how to do this, and if you don't, that's why you're here or whatever. And I'm not going to go into this in great detail.

Step 2: Quality Icons Why quality icons? Probably the single most visible attribute of your application on Mac OS X is the icon that shows up in the dock when the application is launched. Icons in Mac OS X can be extremely large. 128 by 128 when you're looking at the browser view in Finder and you select an application, don't double click it but just select it or a document, you see the enlarged application icon in Finder, right? And application icons and document icons on Mac OS X are extremely rich in design, in visual appearance. And they have lots of characteristics. And if you look at this particular slide on the top row, you've got user applications which are highly, you know, they have lots of color, they're inviting, they're attractive, they communicate lots about what the application does.

That's the first genre of applications, first type of application icons. The second row is utility applications. They're monochromatic in color. They're viewed in characteristics, visual characteristics, right? In fact, there's a lot to say about icons and I'm not even the expert there. And I don't want to go into any great detail because I could talk this whole session about it. So we've actually put a session specifically aside to talk about icons here in Hall 2, 10:30 on Friday.

And the biggest takeaway from this session is going to be that you will learn how to critique icons in Mac OS X. So that when you're working with a graphic design agency or graphic designer, or in-house graphic designer, and they produce a first turn of an icon and say, "Hey, what do you think of this new icon?" You can say, "Well, you know, I don't know.

Either it's great, or it's not, or it needs some more work." So I think coming to this session is going to give you that information, give you some insight into how to critique icons and make some good choices. Icons are very different on Mac OS X, and they're a very visual component of your application, so they're really a big deal.

Conversations about the icon inevitably lead to the doc, because the doc is the keeper of icons, right? And there are three things that you need to do with respect to the dock, or that you need to pay attention to with respect to the dock, in terms of delivering a great user experience on 10 with your application.

The first two things are things that you must do. Every application on the platform should do the first two things, and we're going to talk about these in detail. The third thing is something that some applications should do. In some instances, it really makes sense to animate a dock icon, but not in every case.

So the first thing that every application that ships on Mac OS X should do is to respect the doc's location. Why does this matter? Well, Everybody's been caught currently, because lots of applications don't do this, currently with windows that size behind the dock and now suddenly you're caught because you've got to move the dock or size it down or whatever you do to get at the resize box for the window.

So every application on Mac OS X that ships should respect the dock's location. There are APIs available for Carbon and Cocoa, and when you open a new window or open a user window or zoom your window, make sure that you don't zoom it or size it behind the dock. So this is the behavior that you want to have. Not this. This.

users will be a lot less frustrated, and you're going to provide a greater user experience for them. The next thing that every application should do to provide a great user experience on Mac OS X is to have dot clicks always produce a window. Why is this so important? Well, one of the things that we're trying to get around with in Aqua is to move beyond where we were with Mac OS 9 and provide a better, more streamlined user experience. Not all the features are there yet. We know that. We're consistently revising the operating system. We're going to add new functionality.

But one of the things that's an experience that we've probably all had with someone on the Macintosh is where people close the document window thinking that they're quitting the application. And suddenly they're sitting there now and there's no windows open on the machine. They click on the background, the desktop on Mac OS 9, and they're lost. Where'd my application go? Where'd my document go? I don't know what I did.

And one of our design goals for the doc and for this particular principle is to make sure that that doesn't happen anymore on Mac OS X. And if every developer out there shipping a product on Mac OS X does this, The problem's going to be gone. Because what happens is if you follow the rules, if you're a document-based application, if you have no document windows open, a click on the doc will result in a new, untitled document.

If all of your windows are minimized, a click on the dock is going to activate the last window that was minimized. And if you're a non-document-based application, like System Preferences, for example, and you close the System Preferences window, when you click on the System Preferences icon, the app is still running, right? What it does is it brings up its main window. That's the behavior that every application on Mac OS X should be doing.

Animating Doc Icons This is the third thing that relates to the doc and this falls into the category of things that some applications should do. Every application could animate, it's possible to animate your application icon and your document icon. And this should only be done in the case where you want to provide meaningful feedback to the user. You want to provide status and some operation that's occurring. You want to provide some update as to, you know, progress on some, maybe a high-end rendering process that's taking place with one of the documents.

So when you consider animating your doc icon, whether it's your document, a document icon, or an application icon, think very carefully about whether this is going to provide great value to the user in terms of indicating progress or status, or whether this is just something cool. This is the kind of functionality that we dread making available sometimes because there's always developers out there that go, "This is just too cool." And they call home and they say, "You know what? I've got to work on something really important." And then they stay up all late, late real night, making something really neat.

And yet it has no value. And the last thing that any of us want is firing up a bunch of apps and having the doc animating every single icon in the doc animating. So do this where it makes, it lends value. And don't use garish colors. Don't use blinking. Don't use, you know, just some crazy animation that's constantly going. Use it where it adds value.

So for example, in Mac OS X, if you look at what we're doing with the mail application, the mail application icon looks like this. And when you receive new mail, that's a status that we want to communicate to the user. That's a situation we want to communicate to the user. So what we do is we tag the application icon with a red badge.

The red badge happens to have inside of it the number of new unread messages that you have in your inbox. But that's not what's most important here. What's most important here is that there's a red visual cue that your eye picks up on, even if you're not even looking at the doc. You're on screen. You're interacting with your computer. And yet you see that red icon up here, certainly if the doc is up.

right? That's the kind of guideline that we're looking to lay out for you, before you. Be very careful how you do animation. Do it in a way that's minimal, minimalist, that doesn't get in the way and stand out in a way that's going to distract users, but that also communicates volumes. So what happens is your eye sees a red dot and it goes, "Oh, I got new mail." And then you zero on in the details as to how much mail and whether you really care about reading it or not.

So be careful how you choose to animate your icons. And we're going to have sessions later on this week that go into detail about how to do this from the API point of view, but I don't want to get into those details here. So before we get into the next session, I want to talk about what's your citizenship.

I brought this up because I recently moved to Silicon Valley from Canada. I'm a Canadian. And it's a great place to live here, it really is. But you know, and I'm not an American citizen, I'm a Canadian citizen, proudly so, but I have a work visa here. But the thing about citizenship is, When I go around here, particularly when we moved in and I started to drive around the valley and find my way around, I couldn't find things. There were certain things I was looking for and I couldn't find them.

And it really came down to a cultural difference or kind of like a citizenship. I mean they do things differently in the States than they do in Canada. They do things differently in Europe than they do in Canada or in the States or whatever. And so some prime examples of looking for something and not finding it when I expected it to be there were three things. First of all, service stations, gas stations. I'm driving down the highway. I'm expecting a gas station to be at an interchange where there's another highway or whatever. That's where they are in Canada.

And so we've gone on trips here and we've, you know, been near running out of gas. And there's no service station. It's not the visual cues that I expected are there, but there's no service station. The other thing is a 7-Eleven. I can't find 7-Elevens. They're not working. we're expectant to be.

Usually in Canada, or in eastern Canada, certainly the ones that I knew about, 7-Elevens were by the local strip mall, right? The small shopping plaza that's in the neighbourhoods or whatever. There's always a 7-Eleven right there. Well, that's not where they are here. So I'm looking for things in certain places, and I'm not finding them. And the other thing is lakes.

Where I come from, in eastern Canada, there's lakes everywhere. And so when I go into the woods, go for a hike or whatever, and I'm walking around over the hills, I expect to see a lake. And I do. And yet when I go for hikes here in the Santa Cruz Mountains or whatever, there are numerous instances where we've been at a children's camp or something, and we're walking around, and we expect a lake to be somewhere, and there's no lakes. And it really disorients you. And the reason I'm talking about this is, we showed the Mac OS X desktop at the beginning, right? That's the world in which your application is going to live.

The question is, will your application show things in the right places where users expect them to be? What's your citizenship going to be with your Mac OS X product? And the way to show what your citizenship is through the next several building blocks. The first is system appearance. Aqua has very specific representation of on-screen interface elements, right? Pop-ups look a certain way, push buttons look a certain way, bevel buttons, radio buttons, all of the interface widgets that we're used to have a particular appearance that's unique on Mac OS X.

They don't look grayscale. They don't look just white or whatever we're used to previously on the Macintosh. They don't have other platform appearances. They're very unique to Mac OS X. Your application needs to follow this appearance if it's going to look like a full-class citizen on Mac OS X. The reason that's important is because users are going to come to expect a particular appearance for controls, and they're going to use that as visual cues for visual cues as they search out things on the screen and know what to click on, et cetera.

So one of the new things that was introduced with Mac OS X is toolbars. Toolbars in Mac OS X have a striped background appearance. They have icons that are up on the toolbar that have a shelf-like perspective on them. We're going to talk in detail about what toolbar icons look like in the designing icon session on Friday. But Mac OS X toolbars have a very special appearance. They're very cleanly laid out.

Nice use of white space. The icons sit on a striped background, as I said. There's text below the icon, anti-alias text of the system font, right? Carbon, sorry, Cocoa developers get this for free by using the NS Toolbar class. They just get this stuff for free, plus the configuration sheet that comes down to configure the toolbar. Carbon developers need to do a little bit more work in assembling some of the pieces, but essentially can easily do this.

The other thing about these toolbars is they don't really show status. They're used for selecting, you know, making a choice and moving on. And so when you make a choice, when you select an icon, it darkens 50%. So when you look to roll your own toolbar through Carbon, for example, make sure that the icon is darkened 50%. So if you have toolbars in your application, this is the appearance for them on Mac OS X.

Square Bevel Button The Bevel Button is nothing new. The Square Bevel Button was created specifically on Mac OS X to provide for the situation where you want to have multiple buttons that are related that show status. The Square Bevel Button does a really good job of showing which one is selected. So you have text attributes, you know, bold, italicized, underlined, or alignment or whatever. The Bevel Button does a great job of that.

The Square Bevel Button also is great for in the bottom left corner or anywhere along the scroll bar edge of a window because it fits in there. It can be any size. It can have a pop-up menu associated with it. It can have an icon in it. It can have a whole bunch of things. It's a great use of it there. Great for toolbars, et cetera. So this is another way of doing a toolbar in Mac OS X or doing collections of related items that need to show status.

Another thing on Mac OS X is the appearance of text. It's anti-aliased. It's anti-aliased everywhere. And the font that's provided through the system is lucid or grand. When you specify a particular font face in your application, when you're drawing text yourself, you should select text through meta font specifications through the appearance manager for your Carbon. Avoid hard coding font references. Avoid hard coding font sizes. Specifically saying, "Use Geneva 9 for my interface," is something you should avoid. Those fonts may not even be available in the future.

Lucida Grande is a system font. You need to specify the font that you're going to use to draw the text on your interface by using meta specifications. Let the system draw it wherever possible. In one of the sessions here, 119, session 119, Carbon Controls and Appearance, we're going to get into detail as to what are the common API changes that you need to make to get your text to draw properly in Mac OS X.

So one of the great ways of learning is by looking at pictures of what not to do. or what to do. And in this case, because this is just so, as we look at applications that are coming to Mac OS X, we're seeing lots of great examples of what to do. We're also seeing lots of common oversights.

So rather than fabricate some fake screenshot that we put together in Photoshop to communicate some idea, I chose to use some real developer examples from out there, maybe some of these are your products, and show what some of the common oversights are with respect to creating a great appearance for your Mac OS X product. What are the typical things that developers are doing today on shipping products in Mac OS X? So that you can learn from them. And this is not an effort at picking on a developer. This is all about learning from each other.

First one is wrong window background. Windows in Mac OS X come up, certainly under Carbon, by default come up with a white background. So you need to use theme backgrounds to get the striping, the pinstriping background that's common on Mac OS X. So windows on Mac OS X, dialogs, palettes, utility windows, you know, whatever, all the window types have a pinstripe background. Your application needs to have pinstriping on the background of your dialogs in your palette windows and utility windows.

Not only does a white background look, well basically what this does is it makes it look incomplete. Aqua controls in fact were designed to look best on a striped background. And using the wrong background, although this is a really little thing, leads to bigger things like this. Custom backgrounds, controls that don't even look. This is a Mac OS X product.

It doesn't even look like Mac OS X. It's using not even Mac OS 9 pop-up menus. There's no little down arrow indicating that those are pop-up menus. These look like System 7 pop-up menus. Or not even. Um, the tabs that are being used, those three buttons in the top are tabs. Non-standard tabs. So what this does is it makes this product feel, even though it has fantastic functionality, it makes it feel like it's not a full class citizen.

Antialiased text or not, one of the most common things that we're seeing with product shipping-- these are all shipping products in Mac OS X. In fact, this product comes from-- this dialogue comes from a product that's in fact the company's done a fantastic job moving to 10. And yet, in this particular dialogue, for whatever reason, we have a mixture of antialiased text and non-antialiased text. We have a mixture of system font and hard-coded font references. So if you look at the right side of this screen of this particular dialogue, we've got controls that have the Helvetica font.

They're not using the system to draw the font in the controls, so they must be drawing the controls themselves with Appearance Manager maybe, but the font is not correct. We've got the labels down the side are Helvetica. So we've got Helvetica font on some controls and on some labels mixed with Lucida Grande font that the system drew on some of the controls. If you look, even there's some other lack of attention to detail. Even the baseline of the text on the labels and the controls doesn't even line up.

So one of the messages I want to communicate really clearly here is that your customers... Hold on, one of the messages I want to communicate here is that you've spent a lot of time writing your product. You've spent a lot of time investing yourself into the code behind your product and all of its functionality.

If you put on a half-hearted effort for the user interface, people are looking for a fabulous interface on Mac OS X because it's set a new standard for interface. If your product doesn't deliver that, that's how they're going to judge the quality of your product. And that's highly unfair probably for the code that you've written, because your product probably does some great stuff.

But the same way that we buy cars and we buy other things, we look for attention to detail. If there's no good icon in your product, if it's just got a Mac OS 9 grayscale icon that's scaled up to 128 by 128 in the dock, The first impression I'm going to have is, whoa.

You know these, wow, they, looks like they rushed to market. And then you get this kind of stuff, which, which further, you know, aggravates that, that idea. Or pushes that idea. Here's another common mistake. Too small text. Every developer, pretty much in this room probably, every one of you, is going to argue that I need to use small text in my interface.

It's got to be really small because my users want lots of functionality on the screen and there's not enough screen real estate and I've got to cram all this stuff on the screen. Well, you know what, that might be the case for some utility windows and for pallet windows and productivity applications that might, there's probably some good arguments in certain instances where that matters. And where that's valuable and where that's important.

But the vast majority of cases, That we see and that I interact with developers, vast majority of cases it's completely not important to, in fact you shouldn't do small text. I'm stumbling over my words here. The problem with this particular dialogue for example is this text is so small, it's hard to read on a 1024768 display. What happens if I start running this application on my new iBook that has 160 P.I. running Mac OS X? I can't read it.

So be very careful where you choose small text. Dialog boxes like this one are transient in nature. You display a dialog because the user told you to display the dialog. They chose something in the interface. A dialog appears. It could be much bigger. This dialog could grow 25% or 30% and use the full-size system font, large system font, everywhere on it, and it would be equally usable.

And because dialogues are transient, they can be much bigger. You can use standard-sized controls. You can use standard-sized text, large system font. Because I'm focused in that as a user, I'm not interacting with other stuff on my screen typically. Careful how often you use small text. Another common problem: mixing small and large text. Here we've got a dialogue, or a portion of a dialogue, that's got standard font in the pop-up menus, but it's got small system font for the labels.

If you're using small controls, then use small labels. If you're using large controls, standard controls, use large system font. Because what this does is it looks incomplete. It looks unfinished. There's another thing. It might be a list. I'm not sure what this is. In fact, lists on Mac OS X have a white background. This one's got a striped background.

This list is using non-standard font for the contents of the list. So it's a Helvetic or something. I'm not even sure what it is. The OK and Cancel are in the right place, but we're going to get to that shortly. And along the top here we have, what are they, white bevel buttons? Oh, they're column headers. Well, on Mac OS X, there's a particular appearance for list headers.

For Carbon, if you use Data Browser APIs, the Data Browser will give you the right appearance in Mac OS 9 and on Mac OS X. It just does the right thing for column headers and it takes care of a lot of other stuff, like cool animation of columns as you move them around.

It does the right thing for you, saving you, helping you, or allowing you to focus on the value add for your product and letting us do the UI code. And in Cocoa, lists can be done with NSOutlineView and NSBrowserView and some of the other classes that are available. So lists have a white background, the dialogue has a striped background.

This is common. And that is where we have a duality in character for controls. And the most common of these is button labels or label buttons or... I'm not sure which it is. So as I look at this dialog, it's laid out great. It's followed the interface, you know, the layout guidelines, the spacing and stuff like that. It's got full Aqua, you know, the right pinstriping, got the right controls, everything like that. The problem is... Is gradation a button? Or is it a label for the pop-up menu beside it? Well, it's both, actually.

For people who are used to the computer, they could probably figure this out, and it's not that big a deal. We probably wouldn't even think, you know, very much about this. But for new users, new customers, it's confusing. A button is not a label. A button is a button. A pop-up menu needs a label. Interface elements were designed for specific reasons. Use them for what they were designed for, and don't make them do two different things.

Going back to a dialogue that we looked at a little bit before in terms of the font size mixing up, something else I want to bring attention to is something else I see fairly often in products that are shipping on 10 today, and that is this button that has an ellipsis in it. What does it do? I don't know.

What they really want this to do is essentially be the last item in those pop-up menus where there's a separator that says more or other. Right? Maybe it's a font list or, well in this case I forget what's in these menus, but maybe it's a list of font sizes and then there's a separator spacing, right, and then it says other, dot dot dot.

So unless something has to be elevated to the primary level, you know, to the highest level in the interface, a dot dot dot button is not something that users are going to understand. And the problem here is that it cuts down on productivity because the user has to click on this thing to see what it does. Oh, okay. And then they make a mental note about what this does and hopefully they remember what it does in the future.

Too many group boxes. One of the design goals in Aqua was to eliminate black lines and hard edges and move to a softer environment that has lots of breathing space and white space, and that sort of thing. And this is a fantastic product on Mac OS X. They've done a fabulous job with this from a technological point of view. But here's a great example of a dialogue box that has way too many group boxes in it. And in fact, the goal for the developer, probably, was to make the group boxes help the user navigate the dialogue and find the things that they're looking for.

But in fact, they've not accomplished that. They've gone, it's in fact done the wrong thing. It's gone the other way. In fact, all the lines now make it very confusing to read. And we're going to get into some examples later of how to avoid using group boxes but use separator lines and white spacing to accomplish the same goal.

And yet it makes the dialogue far more readable. If you do have to use group boxes, which are available in Aqua, there's a primary group box and there's a secondary group box, which have both different appearances. So in the case where you might have a group box within another one where it's warranted, there's another appearance for a secondary group box. So look in the interface guidelines for details on that. Mixing Platinum and Aqua. A lot of you are coming from Mac OS 9 to Mac OS X. You're carbonizing your products. And here's a product that's shipping on 10 today. They've got it inside of a Mac OS X window.

But the contents of the window are completely platinum. The disclosure triangle on the folder is the platinum, the Mac OS 9 appearance. The folders themselves, Mac OS 9 appearance. The list background is gray and white, Mac OS 9 background. So what this leads me to believe as a user is that, well, is this a native Mac OS X app? Or I'm not sure, because it feels like kind of 9.

Make sure that every interface element that you draw is native for the platform on which you're on. What's your citizenship? Another example of mixing Platinum and Aqua, here's somebody who decided that the progress bar was, you know, I don't know, they were going to draw it themselves, so they figured out what the pixels were, and they're drawing this thing by themselves. But the problem is that on 10, it draws the same way it always did on Mac OS 9. So there's a progress bar control available in Mac OS X and it will draw the pulsing, you know, sort of the animating, not pulsing, the animating progress bar.

Common issue. Wrong tabs. Tabs, you know, and some of this is because Apple in the past didn't have a tab control. So developers had to come up with another way of allowing users to switch the pane in a dialog box. But here are three examples of ways in which people have customized tabs, in which they continue to customize tabs on X. And for example, on the right side, we've got two rounded bevel buttons that they're taken out of context here, but in context, you would have no idea that they switched the pane of the window.

They just look like two buttons that happen to be really close together. So if you've got a tabbed interface, use the standard Mac OS X tabs, which look like this. They're available north, south, east, west side of a pane. Top, bottom, left, right. and they're available in large or small, a standard or small size.

Toolbar overdose. This is actually a real product shipping on 10. And when you fire it up for the very first time, you get-- well, I think it's nine toolbars showing up on screen. And not only that-- well, first of all, what that shows me is that the programmer or the programmers or whatever felt that every single piece of code that they wrote was extremely important and needed to be connected up to an interface element. Because they wanted the user to use that cool feature.

That's not what usability is about. Usability is about progressive disclosure to your users to allow them to move through the process of solving a problem that they're trying to solve, and you providing a great solution for your software. Don't just expose every feature in your application to the interface. Don't populate the menus with every possible hook into your code. It just makes for a completely confusing environment. This is synonymous with taking every control in an automobile and putting it on the steering wheel.

It becomes highly unusable. You can't find anything. How would you possibly drive? How would you do stuff? Not only that, but we have appearance issues here. It doesn't look like a Mac OS X toolbar, right? We talked about the toolbar design for Mac OS X. It's clean, straight background, nice icons up on a background, although this is the bevel button, which is another option. That's true. But we have the font inside of some of the controls here is Helvetica or something. It's not Lucida.

We have a pop-up menu at the top for percentage, which looks like it's trying to be a combo box, but it's a pop-up, but it's an edit field. So we've got this multi-characteristic schizophrenic control, which really becomes highly confusing for users. And why is it confusing? Because it doesn't look like anything they're used to. It kind of looks like something they're used to, so maybe they'll figure it out. But it doesn't lend users to self-confidence and to encourage them to move on and learn the product.

Step 5 about being a good citizen is layout guidelines. We publish very detailed information about the spacing between interface elements. And we've thought long and hard about why this is important. It comes down to readability. It comes down to navigation of content of your dialogues. It comes down to localization issues. It comes down to the overall appearance of Mac OS X. Lots of white space and breathing room and a light, friendly, kind of lively feeling to Mac OS X.

So it's important to follow these. And we're not suggesting that you memorize this stuff, because we've got a great tool that's available that you've seen already probably, called Interface Builder that lets you basically draw your interface, drag and drop elements on screen, and as you drag these things on screen, you get guidelines that sort of snap in place that say, "Hey, this is the right place for that," with respect to that other control or with respect to the edge of the window or the tab panel or whatever. Interface Builder is a fantastic prototyping tool.

Not only does it let you draw this stuff, but it lets you hook it up to code. And you saw in the keynote address where Scott Forstall demonstrated this. Fantastic example of how this is a really, this is a prototyper with a kick. It's the UI design tool of choice and we're going to continue to extend this tool so that it becomes the premier design tool for interface design at Apple.

Carbon APIs are available to, this is not only just for Cocoa developers. Carbon developers can use the output from Interface Builder and extract the resources in the windows that are in there. Those APIs exist and we're going to talk about those in some of the other sessions. So let's look at some common scenarios that we're seeing as products come to Mac OS X of developers who are not adopting the interface guidelines in terms of layout, you know, guidelines. And we're going to look at why this matters and how you can transition a dialogue that doesn't follow this stuff into a dialogue that does and how dramatically it affects the overall usability.

Here's a preference panel from an application that's available on 10 today. Fantastic application. And yet it's very hard to navigate this panel. It's very hard to tell what's here and you have to actually read every single element and think about it in its context relative to the other elements to think about whether it's the one that you want.

The alternative is of course to apply the interface guide, the layout guidelines and you get something like this, which has grouping of elements that are related, it uses a separator bar, it uses white space, and suddenly now you can quickly scan the categories and zero in on the category that you're interested of the setting that you're after, right? So go to this or go to this.

And the dramatic effect that you see here, if that is applied to every single dialog box in your application, every single palette window or utility window or whatever you want to call them, but if you take these guidelines and apply them to your application, you could ship that application simply by applying the guidelines and people would buy it because it looks so much better and it's so much more navigatable and so much more usable.

So the effect on your application moving to Mac OS X, applying these guidelines is dramatic. We've seen developers who have taken the time to do this and they're blown away by the results. Their quality assurance teams look at these things and go, "Wow, this is great." And yet the developers haven't done anything. They've only modified the layout guidelines or the layout of their dialogues. Here's another example. This is a shipping product on Mac OS X.

We've got a bunch of problems here. We've got check boxes way too close to each other, although they're on a white list, so we'll give them credit for that. We've got some big buttons on the right, which we're not sure what they do, but we'll talk about that in a second.

And then we've got some text at the top, which is the list label, I guess, but the text is clipped. It's cut off. This is shipping on 10. So what does that say to you as a user? If you buy a product, you spend 200 bucks or whatever you spend on the product, and you fire this thing up and there's text that's cut off.

The effect it has on you is that you have an immediate impression and you make a decision, you form an opinion about the quality of that product based on what you're seeing in the interface, and you maybe haven't even done anything with the product. Maybe it does provide a great solution.

Maybe it does have highly functional characteristics. And yet you make a decision about its quality based on the interface. So for all of you out there who are writing code, if you're not one of the UI designers at your company, get on the UI designers to make sure that they do a good job because otherwise your code will be misrepresented to your users.

So when you apply the layout guidelines, not only do you adjust the spacing and get rid of the clipping text, but you end up thinking about the overall functionality. Does this need to be a modal dialog? In fact, if we make it a modalist dialog, we can simplify the dialog and make it a lot cleaner. So we end up with this. Check all, uncheck all. Turns on and off all of the check boxes in the list. We've had the spacing list, put the right font at the top. Dramatic change from this to this.

If you apply the layout guidelines using Interface Builder or whatever tool you want to use, you get dramatic effects in your product. Dramatic usability increases, productivity increases. So the cumulative effect of a lot of these oversights is an interface that's very confusing. Here's an example of a product shipping on Mac OS X. It's a great product, it really is. But it's hindered by a really clumsy interface.

We've got label buttons or button labels at the top. We've got features that are just sort of existing in space. I don't know why we have a checkbox up there below the buttons. We've got overuse of group boxes, which, you know, aren't even laid out nicely, so I don't know what's grouped together really and why. There's no labels. We've got interface elements like a slider control that talks about scale that goes from a scale of nine to 4,000.

266. I don't know what that means. So the developer does, and there must be a reason, but you know what? The user probably doesn't care. So be careful of elevating things to the primary interface that are meaningless to the user in the context of what they're doing. Not only that, we've got something else. Halfway down the screen you see some bevel buttons that have icons in them. They're disabled for this particular screenshot, but they're actually the title of a group box that's connected by a reset control. What does that mean? I don't know.

So here's an example where someone had a creative idea and yet when they, if they had done usability testing or whatever, they would have realized this is just non-standard. So group boxes have particular appearances. The contents of group boxes or whatever, you know, groupings you have This is just a stranger in a strange land. And add to that a whole bunch of other stuff and you get an interface that's highly unusable.

You don't know where to go first, although they've tried to show you where to go first by making the push button at the bottom very big, okay? And we see that a lot. And this is not to pick on this developer at all. I see that a lot. So when you apply the layout guidelines to this, you end up with something that's highly more navigatable visually. There are visual cues, there's groupings, dramatic change.

Tab along the top, labels and pop-ups, you don't have duality of meanings and controls. You've got groupings, original image, scanned image, image quality, you know, the center alignment of sort of center orientation of stuff in Aqua, great white spacing, the proper help button, no more closed box, all that stuff.

Big difference in usability between that and that. So it does matter to apply this stuff. And I interact with a lot of developers who go, oh yeah. You know, what does it matter? Well it really does. Because we see lots of examples as we interact with you, looking at your products on 10, and it affects the usability. It affects the self-confidence of users. It affects their productivity. It affects all those things that we talked about at the beginning that ultimately user benefits roll into developer benefits.

You want to make money on Mac OS X, make a product that is so easy to use, and so navigatable, and so visually gorgeous like this, you will make money on Mac OS X. It's not about just bringing your code to Mac OS X and making it native. Because that just gets you to the platform, remember? It doesn't get you on the platform.

So don't be a stranger in a strange land. I've talked about this message a lot. I'm not going to carry on about that more. Let's talk about the new layout in terms of the layout guidelines. This is a little bit different, but there's a new layout in Mac OS X for menus.

And this came about, again, to try to solve a problem, an age-old problem that we've had on the Mac whereby we've become so used to-- certainly those in the audience who are from the Macintosh background-- have become so used to quitting an application by going to the File menu Quit. They haven't even thought about the fact that that makes absolutely no sense.

We don't quit files. You quit applications. You close files. You save files. You print files. You open them. But you don't quit them. Although that's a term that people say, I'm going to quit this document. But that's a misuse of the term. We quit applications. And so we've taken the opportunity in Aqua to introduce a new hierarchy in the menu bar that starts on the left with the Apple menu, which is system global. This menu shouldn't be populated by you. This is not for developer features, developer commands. This is for the system.

And the new Apple menu is accessible everywhere in the system, regardless of what application you're in. You can get the same functionality in the Apple menu, unlike what you could do in Mac OS 9, which was highly frustrating. Now that once you see the new design, you go back to Mac OS 9, it's like, ah, blast. I've got to click on Finder and then go to the Apple menu to find about this Mac. In Mac OS X, you just go to the Apple menu, boom, about this Macintosh. Or this computer, whatever it says.

The next one, moving right. First one is the Apple menu, system global. Now we have application global. So the things that you put in the application global menu are the things that relate to your application on a global scale, like preferences. An application has preferences. Sometimes documents have preferences. And what we're encouraging you through the interface guidelines is to put a preference item in the application menu that is hierarchical in nature, that says preferences, application, preferences document.

But in most cases, applications have preferences and they should go in the application menu. And therefore, with the application menu in place, we now have a great place to put the quit item, right? We quit processes on X. We quit applications. That's where the quit menu should go.

So as you move from Mac OS 9 to Mac OS X, one of the first things you need to do is make sure that your menu structure adheres to the Mac OS X menu structure. Move your preferences item from wherever it was before. In many cases, it's the edit menu, but in many cases, it's elsewhere and it's not even called preferences. Call it preferences and put it in the application menu.

Moving right, we have the File menu, which is document global, in a sense, document centric. So you put into the File menu the things that relate to your application documents. Saving, opening, printing, page setup. You actually close, we put the Close one in here. We didn't put it in the Window menu, we put it in the File menu because you actually close files. And a lot of people think of it that way, and so that's where the Close command is. The Window menu is really for manipulating windows and tiling them and arranging them, but this is where we put Close. So pay attention to that too.

Some people overlook that. Next, moving right again. So we've got, so starting at the left, just to remind you, right? System global, app global, document specific. Now we're looking at document content specific. So the next menus are all about document content. And then you've got the window and help menu at the end.

For the system, which the system takes care of in many cases, and the help menu is where you're going to hook up your user assistance. Remember we talked about how a good application delivers help through, delivers user assistance? This is where you would hook up your user assistance for Apple help on Mac OS X.

Predefine file locations. On Mac OS X, every user has an account, right? And in that account, in that setup, they've got a default directory, a predefined directory for movies, for documents, for music, for pictures. So don't put your application support files in the music folder. Put them in the library folder in a folder that's titled according to your application. If you save music, make the default location the user's music directory. And after that, if the user chooses to make another place for you to save as a default location, fine. But that's the user's choice.

But a well-behaved application of Mac OS X that delivers a great user experience is going to respect the default predefined file locations that are available on per user basis. And the new interface guidelines, by the way, they're published today and available on the web, talk about when you should use those locations, what they are, and when they're to be used, and that sort of thing.

Another building block of a great user experience on 10 is Apple Help. Apple Help is a lightweight HTML browser. Basically, we've been talking about this for two years and it's not a memory hog. It's there. It's written in a way specifically to deliver quick content, feature-rich content. You can put QuickTime movies and sound in there.

We've got a great announcement to make in the Apple Help session on, I forget which day it is, session 125. Anyway, I think it's Thursday or it might be today. I'm not sure. Look on your calendar. But session 125, we've got a great announcement about moving some content from other platforms into Apple Help format. But Apple Help is the way you should deliver user assistance.

We're going to be extending Apple Help functionality in the future, of course, as we're going to extend everything in the operating system. But this is where and how you should deliver user assistance on Mac OS X. It's going to provide an anti-aliased display. It's going to provide really rich content. Do it this way. Don't roll your own.

Let us deliver the services that are user experience related wherever we can so that you can focus on the things that are going to be used in the future. Don't just focus on the solutions that you need to be providing to your users. Don't spend time writing a help viewer. We already did that. And if it doesn't have the functionality that you're interested in or that you need for a particular case, work with me and develop relations to get that functionality added.

Talk about that in a little bit of detail later on. The new window layering model. Here's another example of where in Aqua we're trying to go beyond the experience that we've had before and solve some of the problems we've had in the past. In Mac OS 9, when you have multiple applications open with multiple document windows open, it becomes really confusing and frustrating sometimes to move data from a Finder window into an application window.

Because every time you click on one of the, you know, whether you click on Finder or the app, all of the windows come forward from that application and maintain their, Z order. As a Canadian, I would say Z order. But they maintain the ordering that's there, that the user put in place. And that becomes really frustrating for moving data back and forth through drag and drop, for example.

So one of our design goals with Aqua was to enhance that functionality and solve some of the usability issues there, create a more modeless environment that'll support Sheets, which we're going to talk about in a second, but have this interleaved document model, which allows you to have multiple applications open with multiple documents and interleave an Excel window with a MetroWorks window with a WordPro, whatever. Interleave your document windows, and it makes for a whole lot easier movement of data between windows, among other things.

10 is sheets. Sheets are fantastic. They're probably one of the things that's mentioned the most often in a review of Mac OS X. This new interface behavior, new interface element, which is called sheets. Well really, sheets are just dialogues. They're document-specific modal dialogues. So wherever today you have a document, when you have a document open, you would bring up a dialogue whose contents and whose settings affect the current document, the active document, that's a perfect candidate for a sheet.

And the benefit of sheets is that it moves the user into a more modeless world where they become modal only for that document. Today, in most cases, if you put up a modal dialogue for a document, I'm now forced into this modality within the application. I'm modal for that application. I can't do anything else in that application on Mac OS 9.

Sheets allow me to put up the sheet, this dialogue, that is connected with the title bar of a document so that there's this immediate association. I can move that window around and the sheet just follows along with it. And yet I can still interact with all the other documents and work on the other documents in the application that I'm on.

So this is a move, a deliberate move on our part to move even more closely to some of the design principles that are laid out, software design principles that are in the beginning of the human interface guidelines document. I know a lot of people that just sort of open that book and they go, software design principles.

Oh, that's what a button needs to look like. And they go on and they make the widgets look right, and yet they haven't paid any attention to the software design principles. Here's a great example of how we are paying attention to the software design principles in Mac OS X with Aqua, and moving one of those principles is mode-lessness. Don't force users into a mode where they're stuck and they can't do anything else but what they're focused on. Sheets does that. So use Sheets only where it's document specific.

Help tags. Help tags is another, is the next level of user assistance on Mac OS X. HTML help is really just delivery of content, right? It's sort of like, I need to read about, you know, making a movie, or whatever it is that you do. And so the user goes off and reads the HTML document and looks at some interactive stuff and hears some sound clips or whatever it is.

But help tags are all about sort of saying, letting the user move around the screen and say, let's see, what's this? Ah. What's this? Oh, okay. So it's, what's this? User assistance. And the interface guidelines talk in great detail about how to write the content for a help tag. It's pretty straightforward, and help tags go a long way in providing a really rich, really informative user experience for your customers.

Speech Enabling: We've come a long way with our speech technologies at Apple. There's a session here called Session 127. It's speech recognition and synthesis. We all talk. We all listen. These are things that we don't even think about doing. Wouldn't it be great if your application could enhance the user experience by speaking to the user where it made sense? Say you're in K-12. Say you deliver educational products. Or say you're a graphic design tool and you want to just... Right now, you say you're drawing something. In today's applications, if you're drawing something, the mouse button is down and that's my input device.

Wouldn't it be cool if I could say while I'm drawing, "Thicker pen. Color red." That's another input device. And the speech technologies at Apple allow you to do that. And so think about ways in Mac OS X, all of the APIs and all the functionality that was there before is available in 10, and we're going to extend this stuff further as we're going to do a lot of other stuff.

So speech enabling your application can greatly enhance the user experience and make you even a better full class citizen or a better citizen in the country of Mac OS X, in this world of Mac OS X. Not only speech recognition, which sometimes is difficult to do and get right, given the environment that your product is used in or whatever, but speech synthesis is actually fantastic.

You can actually embed in the text string that you give to the speech synthesizer, you know, little codes that say emphasize, change the intonation, pause, so that the speech synthesis you get is actually very, very realistic. So imagine you're a K through 12 customer and you want to use speech in your product.

You can actually greatly enhance the user experience by having this product talk back to the kids. Or if you're a game developer, instead of storing tons and tons or megabytes and megabytes of digitized speaking, you know, digitized voices, use speech synthesis. You just have to store the ASCII text of the string that the synthesizer would speak with some of the, you know, encodings inside and you'd save tons of space on your CD, which would in turn translate into lower cost of goods and et cetera, et cetera. So speech enabling your application can make sense in a lot of cases.

The last final building block, which wasn't on the chart in the beginning but I want to mention, is consistency everywhere. As we look at products coming to Mac OS X, and this is true on Mac OS 9, but particularly on Mac OS X as products are coming over, we still see developers who say, "Ahh." Well, I want to give it a different way of picking colors. I've got a better way of picking colors.

So they choose to offer a different way of picking colors. I don't need to use the system font picker. You know, I don't like it, or I can't figure out the APIs, or I don't know where the APIs are, or I didn't even know it existed, so I wrote my own font picker.

Well, the problem with that is that users who come to Mac OS X are going to be expecting a consistent experience. It's like me looking for a gas station or a 7-Eleven. I want a Coke or a Mountain Dew at 11 o'clock at night, and so I say to my wife, I'm going to go to the 7-Eleven. So I go bombing around. Well, an hour later, I still don't have a Coke or a Mountain Dew or whatever it was I wanted to get, and I'm still looking for this thing because the visual cues weren't there. The things I was looking for weren't there.

If I'm looking to change a font in all of the applications I've ever used on Mac OS X, do font picking in a certain way, and now I get into your application and your font picking is in a different way, it's not that I can't figure it out, it's that it impedes my productivity.

It slows me down because now I'm going to go, "Oh, where do I pick fonts in this product?" Where do I choose a color? How do I choose a color? How does this color picker work? We have color pickers on Mac OS X. Yes, they're different between Carbon and Cocoa. We know that. It's a known bug. We're going to fix that. That's no excuse to not use the color picker that's available in the system. Because when we do make them the same, they'll be the same.

Your application will just offer color picking the same way that every other application does. Yes, the FOD Picker might not be available to some of you, depending on the framework that you're in. But it will be eventually. That's certainly our goal. We're investigating that. So build your code in anticipation of it coming.

Support Unicode in international customers. Mac OS X, I mean, we made a big message in the keynote, in obvious keynote about the localizability of Mac OS X, the multilingual aspects of Mac OS X. If you're going to provide a great user experience for all of your customers, which are worldwide, hopefully, you need to think about all the international issues. Use Unicode encoding for your fonts and stuff like that, for your text. Application bundles. That point is up there because it's about the double click experience on Mac OS X.

Remember years gone by back in '84 when Mac Paint was just a single file? This application that we all love to use, it was a single file on the desktop. It was in a folder and you just double-clicked it and that was all. And if you wanted to move it to another system, your new Macintosh, you just copied it on a floppy disk and moved it across. It was just one icon to move.

Mac OS X not only does it provide bundles that give you a single icon that users move around, and that icon is really just a folder containing lots of stuff. But the bundle also gives you a lot of other functionality that we're going to talk about in one of the sessions here, 114, app packaging and document binding. And in other sessions you're going to hear a lot about the bundle, the application bundle. So consistency everywhere.

The point of this slide is, wherever possible, build on system services and system behaviors because users are expecting those things. They're looking for things in certain places. They're looking for the common visual cues. And if they're not there because you just decided to do something different, it's going to dramatically affect the usability of your product. It's going to affect your performance. the product reviews that you get. It's going to affect all the things that we talked about at the beginning.

So in closing, and I wish I had a slide here that was the the original slide of the building blocks for Aqua. Focus on the basics before the advanced. We've talked about a lot of stuff that relates to Aqua and providing a great user experience in your Eccles 10 product, but what we want to clearly communicate with that chart is don't go off and do cheats before you have the layout guidelines in place. That chart is really important. Do the layout guidelines and a quality icon and adopt the system appearance before you go off and do some of the other stuff.

Respect the doc before you go off and do doc animations. And don't do doc animations unless it makes sense to do that. Don't do help tags before you've delivered basic user assistance through Apple help. You understand? So there are priorities there. Focus on adopting the system appearance and getting the layout guidelines in place. Because of all the apps that I've seen out there, the vast majority of them don't yet yet do those basic things.

As I look around many of the interface design discussion lists that are out there, some hosted by Apple, some that are not, we see all kinds of weeping and wailing and gnashing of teeth about different features in Aqua that aren't there or how can Apple change this or that. But I want to just turn it, we're aware of a lot of those issues and we're going to address them. But I want to turn the challenge back to you. As Steve said, create products that are going to delight.

Your users. What is your citizenship? Are you going to exist in this world of Mac OS X and make your product look like a true, you know, citizen of that world? Or is it going to be a stranger to a foreign land? A great way to do that is to follow the checklist for creating Aqua applications, which is in the back section. It's one of the appendix, one of the back sections of the interface guidelines. It's called the checklist for adopting Aqua applications. And it's a great checklist.

Follow that checklist and if you can do all those things or many of those, you're going to have a fantastic product on 10. Work with Apple to enhance Aqua. If you're thinking of creating a control that you think is absolutely important and key to the success of your product, don't just keep it to yourself.

Work with me and Developer Relations, I'll give you my email address shortly, to convince me and I can work as an advocate on your behalf to get Apple to add that functionality in the system potentially. And then everybody can benefit from that functionality and the whole platform will benefit. Thank you.

So what's your legacy? Mac OS X has the capability, has an interface that's unparalleled of anything we've seen before and the reviews would attest to that. You have an opportunity to release a product that on X sets a new standard in interface design, sets a new standard in terms of appearance on Mac OS X.

What's your legacy? What do you want your legacy to be as a software developer? Do you want to be known for having, you know, yeah it does a lot of stuff, but man, I don't know how to use the product, you know? Or do you want to be known as a company that delivers fantastic solutions that delight customers and that feels like it's part of the OS? Oh, who made this? Wow. You know, I thought this was part of the OS or whatever. What's your legacy going to be? It's not only about APIs and features and elevating all those features up into a toolbar that's completely overloaded.

Last thing, I want to do a plug for the Apple Design Awards tonight. The Apple Design Awards is four categories. One of them is Best Mac OS X User Experience. We're going to highlight a runner-up and a winner in that category, as well as other categories, where we're going to say these products set the standard to which every other product in Mac OS X should be coded towards, in terms of user experience. So come to the Apple Design Awards tonight. It's going to be a fun event. Last thing, just some information for you. Inside Mac OS X, Aqua Human Interface Guidelines, they're available now. A new version is available on the website.

There's a new web page up there that went up a few weeks ago. It's from developer.apple.com/ue. It just basically links to all kinds of discussions about windows and dialogs and icons and all this stuff. It's great to sort of drop into that one page and you've got contacts out into the Carbon and Cocoa worlds for all the different interface elements that I've talked about today and a lot more.

And then there's an interface discussion list that's hosted by Apple, which is up there. And you don't need to write down these URLs because in fact, in the last slide that I'll end up on, there's a single URL you can visit. It's got this session number with all of that information below it.

Just point you to a few more sessions that are coming up. Session 119 and 120 that are tomorrow in hall two right here. They're going to talk there in those sessions specifically about how to get the right appearance If you look at some of the common oversights we looked at, how do you get beyond, you know, striping that doesn't line up, which isn't even an example I showed. How do you get beyond a white background? How do you get beyond, you know, the wrong halo around your controls, or controls that animate, you know, all those sort of things.

That's a session to come to if you're a Carbon developer and you want to get around those issues. Designing and using Aqua Icons, again, great session to attend to learn how to critique and decide whether the icon that somebody's made for you is the right one or not. Apple Help, again, straightforward. Speech Synthesis Recognition, please visit that one.

Session that's going to be very interesting and I would encourage you to attend is Session 114, where we are going to set clear, as many of you have asked us to, make a clear statement about what is going on in terms of file naming and document binding and application packaging. What are the rules? What should I do? All these sorts of things.

Come to that session, please. And Interface Builder. Learn about Interface Builder. If you haven't played with it, go to Session 702, even though it was yesterday, but you can watch it on the DVD or something. And the last thing is feedback on Aqua. We love to get feedback on Aqua. There's a feedback forum. It should be a really fun event. It's this afternoon. Please come to that.

I've actually run out of time here, although I've got about five minutes. I think I could take a couple questions. So if I want to ask the Interface Design Team, a couple of you want to come up front here. We'll take a few questions, but there's a feedback forum for Aqua and then for the high-level toolbox. And here's my contact information. Please work with me as you look to get a few things added to the system when you consider adopting Aqua.