Ladies and gentlemen, please welcome manager of software evangelism, Tim Holmes. Hi. Welcome. I hope it's been a good show for you so far. So you've gone over the design concepts for UE, and those are broad and those are important and they're critical for your understanding of how to make an application on the Macintosh. This session is going to be about adopting Aqua, and that's implementing those design concepts through the tools and controls we give you. This is really critical stuff. This is stuff that if you're not on our platform today and are moving to our platform, you really need to understand to have a successful product, to have as a real sellable product. And it's also critical for our platform because one of the key advantages of the Macintosh is the consistency of controls, consistency of usage, and being able to understand where you are and what you need to do to get something done no matter what application you're in. So I'd like to introduce John Galenzi. John Galenzi is our user experience evangelist, someone who's familiar to you all, I think, probably. And if he's not, you should get to know him. You should give him a call. Come on up, John. He does quite a few reviews of people's products, and if he hasn't reviewed yours yet, you should get in touch with him. So thank you, Tim. Have a good session.

Okay, well, there I am. That's the nickname people have started to give me in the developer community. Okay. All right, I want to talk in this session, carry on from session one, and I want to talk now about how do you take those principles and adopt them specific to your application on Mac OS X. And we're going to get really practical, and basically we're going to come around to discovering what it takes to create a really great citizen application in the environment of Aqua. And to do that, I want to first define the term citizenship, help you understand what I mean by that term, because I'm going to use it over and over through this session. Then I want to look at what the benefits are to you as you bring your product to Mac OS X and you do some of the things that we talk about today. Then we'll look at some of the detailed steps that you need to take as you adopt Aqua. And finally, I want to finish with some testimonials from some of your peers who have made the choice to adopt Aqua completely. And they'll talk about that whole process and talk about the benefits that they've seen, et cetera. And so it's really not only just Apple talking about the benefits here, but it's your peers who have gone through the very same experiences that you're going through right now as you bring your product to the platform.

So first of all, this is the world in which your application lives. This is the Aqua desktop. It has very unique characteristics, right? It's got shadowing and transparency. It uses anti-aliased text. It has quality icons, et cetera. Very, very distinct attributes. This is the world in which your application is going to live. And if your application doesn't feel like it belongs here, your users are going to notice, and it's going to affect you in many, many ways.

As I said, I want to talk about the definition of citizenship, first of all. And when I use this term, I use it loosely in terms of the real definition of citizenship, obviously. But I think it's one of the best terms to use to help you understand what it means to belong in this world of Mac OS X. So to start, I want to talk about the first sentence, focusing on the first sentence, and specifically focusing on the fact that a citizen, actually, has benefits for being a citizen of the land in which they're part of, or of the nation in which they're part of. In this case, it's your software that's within the nation of Mac OS X, or in the world of Mac OS X. So what are the benefits that you realize by creating a really great, compelling product on Mac OS X, and a product that implements the principles we talked about in session one?

Well, Stan went over some of these, so I'm not going to go into great detail. But fundamentally, the benefits boil down to two. And the two are make more money and have a competitive advantage. If you're reducing your tech support costs, you're simplifying your documentation, your product is highly usable and your customers are tremendously satisfied with it because they're achieving what they set out to achieve and your product is actually solving the problem it's supposed to solve in a very focused, simple way, The outcome is going to be upgrades, more customers, satisfied customers. All of that turns into money and a competitive advantage. All things being equal, if your product does the same thing a competitor's does, but yet you knock it out of the park from a user experience point of view, you're the winner.

So there are benefits to being a good citizen, but there are also responsibilities, clearly, right? We need to be law-abiding citizens, which we all probably are, hopefully. And your application needs to be a law-abiding citizen, so to speak. So let's talk through some of these responsibilities. There are three areas of responsibility that your application has on the platform. And essentially, they boil down to the basics, which we'll talk about. They boil down to behaviors, implementing the behaviors that are unique to the world of Mac OS X. And the appearance of Mac OS X, does your application follow that appearance and adhere to that appearance?

So what are the basics? By the basics, I mean, and these are basics that aren't even specific to Aqua so much as they are specific to the Macintosh. What does it take to make a, you know, what are the characteristics of a Macintosh application? And believe it or not, there are violations of these, and we'll have a lot of fun looking at some of them. So I want to start with one of the most basic characteristics of a Mac application. And that is that the application has menus, right? And that the menus are structured in the proper format. And the menu layout for Mac OS X is such that, if we're starting on the very left, we have the Apple menu, which is system global. It's for commands that relate to the system. It is--it enables the user to do stuff to the system regardless of what context they're in, regardless of what application they're running. They can sleep the system or do whatever-- you know, go to system preferences. And the Apple menu is really not for application developers.

Moving right, we have the application menu. This is where you start to get interested, because the application menu deals with the commands that are specific to your application as a whole, as a whole entity. This is where you put things like quit, because we quit applications now. We don't quit files like we did in the past. This is where you put your app preferences, because preferences apply to the whole application. And this is where you put anything that relates to your application as a whole.

Moving right from that, we have the File menu, document-specific commands. This is where you put any command that relates to your documents, the documents that your application manages. So we open documents, we print them, we save them, et cetera. That's where those types of commands go in the File menu.

Moving right from that, remember there's this hierarchy, right? We've got system, global, the whole system. Then we've got the application that runs on the system, commands. Then we've got the commands that relate to the documents that application manages. And then to the right of that, we've got edit menu, the edit menu which affects the content of your documents. And then to the right of that, you might have some other specific menus for your application. But remember, those menus should contain commands that affect the content of your documents so that there's this inherent hierarchy that users begin to understand as they move through the system and use one application after the other.

And following the application-specific menus, we've got the window menu and the help menu. The window menu in Jaguar, in fact, contains some new functionality, which is the ability to cycle through your active document windows using Command-Tilde on the keyboard. And the help menu is where you would put your access to your help book and your user assistance, your online help. As we're talking about menus, I want to talk about another fundamental basic for a Macintosh application, and that is respecting or adhering to the reserved keyboard equivalents that we've set out in the Aqua Humor Face Guidelines. We all use the Mac. We're all used to, without even thinking, doing Command-S to save, you know, printing, cut, copy, paste, undo, all of these things. We don't even think about it. Our hands just go down to the keyboard, and we do the appropriate keyboard equivalent, right? Here we've got an example of a shipping application on 10 that has completely ignored these guidelines. And the effect is that if I start to use this application as a user, I start to use those familiar keyboard equivalents, right?

And I'm going to be stymied because it's going to do things that are completely beyond what I would have expected it to do. And in session one, we talked about expectations. And suddenly, I'm going to use this product, and now it behaves in a way that's very different than what I expected it to do. We've got Command-P for preview, A, which should be select all, does something else, S, does scan instead of save, et cetera. So as you bring your application to Mac OS X, if you're coming from Windows or Java, There are many of you that are doing that. Even if you're writing custom in-house applications, it's important to adhere to these, or to use the reserved command keys in the appropriate manner, because it means that as users move from your application to another, or from another to yours, some of these basic behaviors are going to be there, and they're going to have this level of consistency between the usage of the applications. And it'll mean that they're very comfortable. example. Another basic thing that your application should do is have your windows appear and operate the way other windows appear and operate in the system.

Mac OS X introduces this layering model of interleaved windows between applications, and windows have a unique appearance. They minimize to the dock, et cetera. Your windows should behave the same way. And the thing I want to point out right now is that, in fact, in this world of Mac OS X, Windows, their only constraint is the real desktop on which they live, right? The Mac OS X desktop. And that might span multiple monitors. But the fact of the matter is they're constrained in that area. However, there are applications that are being brought to Mac OS X.

that are not adhering to that basic principle, which is that the desktop is the defining area for the window. And so here we have an MDI interface, which is common on Java applications being brought to Mac OS X, where the document windows that this application manages are constrained to the main parent window that also belongs to that application. So you're getting an untitled one, untitled two, untitled three document window constrained to the parent window, and none of those document windows can move outside of that parent window. So it's very different behavior, and suddenly the user is faced with a situation that's, you know, very foreign to them in terms of how the overall system works. So the right way for this to be done on Mac OS X would be to drop the MDI interface and basically put those document windows on the overall desktop and let them behave like any other standard document window. And if you're a Java developer and this is an issue for you, there is documentation on our developer website, I believe. Certainly contact developer technical support to get assistance with that. Contact me. We'll give you the assistance you need to solve this problem, because it is solvable. And I don't mean to say that Java developers are the only ones doing this. There are other people who are doing this occasionally as well.

Another basic, basic thing that you need to do bringing your application to Mac OS X is build upon system controls. We are doing our best to extend the control set that we have available to you. And so in most cases, there's really no need to customize the behavior of controls or create your own controls.

There are instances where that is necessary, and so I would encourage you to work with me to get an understanding of that so that I can champion that for you within engineering. But building upon the standard system controls means you're going to get the right appearance for one thing, but secondly, you're going to inherit for free much of the behavior that we're talking about in terms of universal access. So the keyboard navigation will come for free. Speaking back of the items below the mouse will come for free. You know, focus rings, all that will come for free, provided you use the standard system controls. If you don't use the system controls, but draw controls yourself using Appearance Manager, for example, in Carbon, it means you're going to have a little, not only a little, but in some cases, you're going to have a lot more work to do to implement the same behaviors that you could get for free. So I encourage you to do standard system controls wherever possible.

And on that topic, I want to just, it's, you know, it's my honor to announce the fact that the combo box control, which has always been available to Cocoa to date, is now available for Carbon. And we'll look at a couple examples later on of where that's being used to greatly simplify some dialogues. And there are the APIs for you. Thank you.

Another real basic that, as I look at lots of applications and evaluate products with developers, where I see difficulty with is the use of standard alerts. Standard alerts have a particular format and structure. They've got an icon on the left, which is the application icon. They've got the large text telling you what the problem is and then an explanation of what the solution is, as well as providing, you know, intelligent choices for what the user can do through buttons. And yet I see just a vast variety of, you know, implementations of alerts. And a lot of it comes because you're constructing alert strings on the fly in your application, et cetera. I would encourage you to use standard alerts. Using the application badging in there tells the user in this interleaved document world of Mac OS X where your application might not be the frontmost application, the application icon tells them which application is giving them the alert. So it's really important that you would badge your alerts with your application icon at the very least. And then the appearance for the dialogue is available through the APIs through Carbon and Cocoa. Thank you. All right, honoring default folders. Another real basic for an application coming to Mac OS X. Every logged-in user on Mac OS X has their home directory.

That home directory contains default locations for storing music and pictures, everything that's listed there, movies, et cetera. If your application is a content-creating application, you should default to the appropriate location for saving documents from within your product. And while we're on this topic, let's talk about the documents folder, which is part of every logged in user's home directory. The documents folder is another area where we're seeing some difficulty with applications. It is reserved exclusively for documents that users create. So where a user is inside of a document in your application that says save and puts it in the documents folder, that's the document that they explicitly created. Everything else that's related to your application, that's sort of vaguely user-created in the sense that it might be a mail database or it's a contacts database or it's some other thing that you really... is necessary for application support does not belong in the documents folder. It should be put in the library directory, library folder. So, and the side... sort of side issue on that is training your users through your documentation or through tech support, et cetera, that if they back up their world on Mac OS X, they need to back up more than just their documents folder. They need to back up their whole home directory because it contains preferences, It contains application support files that are important, and it also, as well, contains their documents. Thank you.

So those are the basics, and I don't mean to imply that those are the basics. I mean, they're the basics I'm talking about today, but there's a whole pile of other stuff I could have talked about, but in the interest of time, those are the ones I wanted to touch on specifically because those are the ones that I see the most difficulty with developers implementing those on Mac OS X. Let's talk about behaviors. You have responsibilities as a citizen on Mac OS X to implement some of the behaviors that are available to you on Mac OS X. Thank you.

First of all, one of the unique behaviors of ECOS 10 is the dock. The dock is there at the bottom of the screen or on the left or the right. And as a developer, you have some responsibilities around working with the dock. There are three things that you can do with the dock. Two that you should do and one that some applications might do.

First of all, every application on the platform, and this is almost, you know, a basic, but I didn't put it in that section. Every application on the platform should respond to doc clicks appropriately. If your application icon is clicked in the doc, you should always produce a window. If you're a document-based application, bring forward a new untitled document if there are no documents currently open in your application. If you're a document-based application, but all of your document windows are currently minimized to the doc, then you should bring up the last minimized document window because that's likely the one the user was, you know, that's the one they were last working in. That's likely the one they probably want to work in now. And if you're a non-document-based application, say you're in iTunes or a system prefs or something like that where you have a main window, then if that window is currently closed but your app is running, you should bring that window up and activate it. Thank you.

Respecting the doc's location. As I said before, the doc can be at the bottom of the screen or on the left or the right. Who knows where it'll be in the future? I don't know. I'm not on the design team, but who knows? At the moment, it's in these locations. And as your application windows, as you open new untitled document windows or as the user resizes document windows, you should always honor the doc's position and never allow the user to resize their window behind the doc or never automatically resize a new untitled window behind the doc. And so in this particular example, you should, you'll see, here's a docking window from, from IE that, that your window should open flush to the menu bar at the top and flush to the dock if it's on the bottom, or flush to the bottom of the screen if it's, if it's not, if the dock isn't on the bottom The APIs for that are pretty straightforward. But remember, the users can change the doc's location. They can also change the doc's size.

So if they've sized their window and you've honored the doc, and afterwards they resize the doc to cover the grow box from the window, let them do that. Don't resize your windows and move windows around based on the movement of the doc. Once the users set the window size there, and if they change the doc, that's their choice. Let them change their environment without adapting to it.

Something some applications should do is provide meaningful status information via the doc. We talked about this a little bit in session one. I'm going to talk briefly about it here. But the idea is, if there's meaningful information you can provide to your users about the progress of your application, doing something it's doing, or if you're a fax application and you're sending a fax in the background or receiving a fax, providing that kind of status information or progress information through your doc icon is really meaningful and very subtle and yet very effective. at communicating what's going on. So, for example, with the mail icon in Mac OS X, we badge it with a starburst that says, hey, there's new mail. And if it's sitting down in the dock and your dock is visible, you see that, and it's a really cool cue, very soft cue, saying there's new mail. And so you don't have to fire up, you know, you don't have to switch the app to look whether there's new mail. So that's an example of what we're talking about here, providing meaningful status information through your dock icon. And again, I would say, think very carefully about when you do this. The last thing we want to have is the dock, you know, or having all kinds of status stuff occurring constantly. But where appropriate, it's very, very valuable. And to do this through Carbon, it's just look for the APIs with "doctile," the terms "doctile" in them, in those header files. In Cocoa, it's "nsApplication," "setApplicationIcon."

Okay, another behavior that's very specific to Mac OS X that's very cool and very visible to product reviewers and to customers alike is Sheets. Sheets are document modal specific dialogs. Use them wherever you have a dialog box whose contents affect the currently active document. So think about your product for a minute. Do you have active documents? Do you have document windows? Yes. Do you have modal dialogues that currently open up to affect the contents of that document? If the answer is yes, those are candidates for Sheets. And the cool thing about Sheets is they really implement the principle of modelessness well because they attach themselves to the document title bar of that window. They move with that document around, so they're clearly associated with the content that they affect. And yet they allow you to continue working in that application on other documents. So they're only modal to that application, not modal to the whole application, to that document, rather, not modal to the whole application.

Another way that we've implemented motorlessness in Mac OS X is drawers. Again, we touched on some of this content in session one, but drawers are great for providing often-used controls that don't need to be visible all the time. They're also great for enabling you to provide additional functionality closely related to the parent window. So it's really not a sheet because it's not a case where you go and you do it all the time and then you dismiss it. But drawers are there for stuff that just sort of hangs around that's sometimes meaningful to be there, but sometimes it's not meaningful or not effective to be there necessarily. But it's great to have it there because you can pull it out, do something you need to do, and push it back. So think about where you do that kind of stuff and where this could be useful and implement drawers. I have the pleasure of announcing that Carbon drawers are now available, effective in Jaguar. And in the headers, macwindows.h, just look for APIs that have the word drawers in them. And this is a big deal for Carbon developers who have been waiting a long time for this. So there's no excuse to not implement drawers now. Thank you.

Another behavior of Mac OS X is Apple Help. Apple Help is this really effective way of delivering help content to your users in a very rich manner. QuickTime is integrated. AppleScript is integrated, so your users can read through your help and say, well, okay, well, show me, and you can control your application through an AppleScript. It's a really great way to deliver rich help content. And we've actually extended Apple Help in Jaguar to build on its ability to deal with remote content. So where we are currently with Mac OS 10.1 is that Apple Help can support remote content. So you know how you're developing your product and you run out of... Basically, the development team is still working on some stuff, but you've got to freeze the help content, and yet you want to document the stuff, but it's still changing. And so anyway, we all understand that situation. Apple Help lets you put some of this help content out on one of your servers and go get it.

The beautiful thing about Apple Help and Jaguar is that now you don't need to know what the structure of that help content is necessarily because we retrieve the remote index as well. So now you can add and remove help pages on the fly as you change your system or as you understand or realize that your help content could be restructured or something. So really great feature in Apple Help now in Jaguar. Second thing is that Apple Help in Jaguar is Internet primary. In other words, it's going to look to the Internet for remote content under the assumption that the remote content is more up-to-date than the current local files that you installed with your product. So leveraging both of these means you can really deliver great, really flexible help.

As well in Jaguar, the help viewer has been enhanced significantly in terms of its user experience. You can now, with the help viewer in Jaguar, look at multiple help books at the same time. So you can have multiple windows looking at help. You can copy text from the help viewer. Lots of people are asking for that. You can enlarge the font display in the help viewer. It's got a customizable toolbar, just like the Finder in Mail. So significant enhancements to the usability of the help viewer in Apple Help. Thank you. Choosing colors is always a complicated process just by its very nature.

And we've provided the system colors window in Mac OS X that up until this point has only been available to Carbon. It's a Cocoa, sorry. It's now available to Carbon in Jaguar. And the beauty of it is that it provides a consistent user experience across frameworks for picking colors. If your application allows users to choose colors in any way, whether it's for coloring text or some background or whatever it does, don't do your own color picker. The difficulty with doing your own color picker means that it behaves differently. The user comes to it with an expectation about how it's going to behave, because you might have used the standard, you know, control to get there. And suddenly what's revealed is something very different. It behaves different than what they're used to. And the system colors window is the way to provide for color picking on Mac OS X.

File name extensions are on Mac OS X. They're a way of enhancing the file name to improve interoperability with other platforms. We have specific goals around providing file name extensions. The thing I want to talk about is that our goal with this is to maintain the usability of the Macintosh or that the Macintosh is always known. And so when file name extensions are entered by the user, it's basically a what-you-see-is-what-you-get kind of behavior. So if the user types an extension on the file, a file name extension, that file shows up with a file name extension. If they don't type the file name extension, it doesn't have a file name extension.

It's appended by the application. Specifically as it relates to user experience, I want to talk about-- The fact that there are display names. File names aren't only what the file system tells you they are anymore. So historically, you could say to the file system, what's the file name or what did the user choose, and you'd get a name back. Now, pay attention to Nav Services, what it tells you in terms of the file extension being hidden or not. It's going to give you that bit.

It's also going to give you the full file name. And so if it's hidden, show just the main file name. The save panels will do that appropriately. But wherever you display a file name in your application, say you've got a list of files or you're providing detailed status information about a file, make sure that you display the user's, the display name for that file. The user is explicitly chosen to either hide or show the file name extension. Your application should honor that. So if I have a document called lettertomom.txt, but I've hidden the extension, and as far as I'm concerned, it's just called lettertomom, when I double-click that document and it opens up in the application, the document title bar should say letter to mom, not letter to mom.txt. So the APIs to use are in launch services, lscopy display name for ref, lscopy display name for URL. These are the APIs you should be using to get the display name for a file.

Speech. You saw this stuff demoed earlier on in session one. Speech is a big part of our universal access story in Jaguar. And so building on system controls and doing things like that are going to enable you to leverage speech. And you get a lot of stuff for free with speech in Jaguar. And I would encourage you to attend the speech session on Friday where we're going to talk about how our speech synthesizer can be improved and made to sound really great. And our recognition is really strong. Thank you.

Managing contacts. Today, we all run multiple applications, we all run multiple tools, and the reality is that if those applications require a phone number or an email address or whatever, we rely on that application to manage those contacts. I'm sure all of you have experienced the case where you're using an email program and you've got all of your email, you know, your contacts in there for their emails, but then you've got another personal information management tool or you've got some other thing where you're doing mail, you know, mail merge or whatever, and all three of those products or more are pulling from different databases for contacts. Wouldn't it be great if all of those applications used the same source of information? So regardless of whether I was sending an email or sending a fax or doing some other operation on my machine with some other product, that all of the context would come from the same place.

It's possible with Jaguar, because with Jaguar, we're introducing something called Address Book Framework. It's a very simple framework available to Carbon and Cocoa that enables you to build on a standard, single, centralized database in the system to manage people, the contacts around, and the information around people. So in terms of delivering a great user experience with your product, and in terms of being a great citizen on Mac OS X, this is one of the things that you should consider building into your application. Not only does it deliver a great user experience, but it means that you can focus on the value add that your product provides, which is the unique capabilities it has, versus, oh, yeah, we've got to write this context thing and deal with all the UI around that and all the database management, right? Take your development cycles and put them on the things that are unique to your company and the value add you bring rather than trying to write a lot of stuff that everybody else is trying to write and ultimately confusing and diluting the user experience for that stuff. Yeah.

We talked about three areas of responsibility. We've talked about the basics that you need to do for delivering a product on Macintosh. We've talked about the behaviors of Mac OS X. Now I want to talk about the responsibilities you have in terms of being a good citizen around the appearance for Mac OS X.

First of all, it's clear that Mac OS X delivers icons in a way that, you know, the Macintosh has never done before. Icons are rendered high quality, in a high quality manner. They communicate a lot about what the application does. Your application icon should be the same. Last year we talked about this idea of a tool and media. There's this tool like a pen, and the media being a piece of paper. And those two ideas in your icon can communicate a lot about what your application does.

Not only should your icons be quality, but the overall graphics of your application should be quality. Think about, you know, taking the existing graphics from your Mac OS 9 product or from your Windows product or from your Java product, taking those graphics and redoing them to feel more like they belong in the world of Mac OS X. Anti-alias text, soft edges, removable black lines, these kinds of things that you'll see throughout the system.

Speaking of anti-aliasing, I want to talk about anti-aliased text. The appearance for Mac OS X is such that the text everywhere is anti-aliased. If your product is running on Mac OS X, all of your text should be anti-aliased as well. If it isn't, your application stands out and feels incomplete. We'll look at some examples. examples. The right way to draw text, it depends on which framework you're using.

There are ways to do it properly in Power Plant. There are ways to... Certainly, Carbon has multiple ways of doing it, but if you're writing directly to the toolbox, using the Appearance Manager APIs, like draw theme text, et cetera, are going to mean that your labels, et cetera, are appearing properly. Using standard system controls are going to mean that your controls, the labels are drawn by the system, so they're automatically going to appear in the appropriate font face and size. So anti-aliased text really matters. And if you have content text views within your documents, consider using MLTE views or the ATSUI engine, which there are sessions about here at WWC.

So what I'm talking about in terms of antialiased text is to not do something like this. Here we've got a window from an application. For one thing, it's got a scrolling area of text that has a striped background, which is not the appearance for Mac OS X, right? Lists and scrolling areas of text in Mac OS X have a white background. So that's one difficulty this developer had. The second is all of the text is not antialiased, and it's so small it's hardly readable. So everywhere we deliver text in your application, it should be antialiased.

Steve introduced this idea of the metal window, metal for the rest of us. As all of you know, Mac OS X delivers several of our applications-- or Apple delivers several of our applications with a metal window appearance. We have iTunes. We've got DVD player, QuickTime player, et cetera. And this metal window is now available to you, the developer community, to use. I'll talk about the APIs in a second. But before I get there, I want to give you some guidance around the usage of this type of window.

Where Apple uses it is in the cases where we have a single window application. Think iTunes. There's a central window. That's where you focus all of your time. That's where we chose to use a metal window. Also, because it kind of reflects a real-world device in a way. It's kind of like a player of music. Think about the QuickTime player. It's kind of like a little TV in a sense, but it's not. But it kind of mimics a real-world device. Those are examples of where you would use a metal window.

The other guidance I would give around that is that it's-- use the metal appearance only for your main window. So if you think about iTunes again, or if you've got a PowerBook sitting in front of you right now, fire up iTunes. Take a look at iTunes. There are other dialogues in iTunes for preferences, et cetera, but those dialogues are fully Aqua. They're not metal. So if you're going to use the metal window appearance, use it for the main window only. And all of your other dialogues, supporting dialogues within your application, should be Aqua.

So the way to do this in Carbon-- actually, you can't do it in Carbon with the build we gave you yesterday, but you'll be able to do it real soon 'cause we're still some stuff being defined, but it's a new window class, and we'll give you the details later in the headers. And in Cocoa, it's just a constant.

Palette layout and appearance. There are tons of applications today that ship on the Macintosh that have palettes. And there are lots of high-end illustration tools and web design tools and lots of applications that use palettes because the cool thing about palettes is they remain on screen all the time. They're easily accessible to the user, therefore. They don't take up much real estate. And so your application, if you deliver palettes within your application, should adhere to these kinds of guidelines as well. make judicious use of real estate. You don't want to take up lots of room. You want to use smaller spacings and tighten things up. But at the same time, you don't want to do something like this, which is... they've used standard controls. Everything is truly Aqua. The difficulty here is things are kind of compressed and it seems somewhat messy. So remember, if you're bringing things down in size, to continue using the small version of Aqua controls, but also remember to focus on the alignments and the overall layout of the palette. So what would this look like if it was adhering to the Aqua layout guidelines? We've got more alignment of controls. We've reduced redundancy in labels that were there. We've used verticals or horizontal separators to distinguish sections of this palette. So it's pretty simple stuff, but again, a beautiful tool to do this around, or a beautiful tool to use to do this is Interface Builder.

All right, missing the basics. We talked about a section earlier on which was the basics. I'm talking about here about the basics for the appearance in the system. Here we've got an application, and I see lots of difficulty with this, particularly in Carbon applications coming over from Mac OS 9, but also Carbon applications coming from other platforms where the developer has leveraged Carbon to do the interface because of the structure of their code.

They've chosen to use Carbon because it's easier. And there's just some real difficulties here, and I wanted to point these out specifically. Here I've got a dialog that's got, has no respect for the margins that we define in the Aqua guidelines, so the tab panes are very close to the edges. We've got multiple tab rows, although the second row is really an inner tab pane, which is okay to do. We do it in system preferences. But certainly it should be spaced downwards and then inwards so that you know that it's a separate tab pane within a larger tab pane. The buttons at the bottom are being obscured by shadowing, so there's overcompositing there of the tab panes. All of the text in the dialog is non-antelious, and it's all Geneva 9. its hard-coded font faces and sizes. And I see this a lot as I review applications.

An interface like this, for example, on your product is going to mean that your users judge the quality of your product based upon what they see on the screen. You've put a lot of effort into writing your code. You know it's great. You want the world to experience it.

spend the time to make a really great interface on top of it, to put a really great Aqua-compliant interface that leverages sheets and drawers and speech and all of the stuff that we're talking about today to really create a killer application. Because then the users look at it and they go, wow, this is great, and look what it does. Most users really are not concerned about what your product does. I mean, they are concerned about that, but primarily they're concerned with how it does it. What differentiates you from your competition is ease of use. Think about iMovie. Before iMovie was on the scene, it was really hard to just pick up and edit a video. We spent a lot of time thinking about the interface around iMovie and how do we, you know, who are users, what are they doing? Remember we talked about this stuff in session one. Who are users, what are they doing, what do they need to accomplish? Simplify, simplify, simplify, to the point where we've got this iMovie thing that people are just looking at as an example and a benchmark for creating really highly usable consumer-oriented products. Don't let your interface knock you down in terms of the judgment your users render upon you. You spend a lot of time in your code.

Group boxes. Aqua has a very distinct appearance in Aqua, and we encourage the use of white space. We have margins and dialogues. We encourage spacing between groups of items or a single separator bar. And group boxes are still available in the toolbox. You can still do them. You can define them in Interface Builder, et cetera. But I want to encourage you to think about cases or to think about moving away from group boxes wherever you can. Moving away from them means your interface is going to feel lighter. it's going to feel cleaner. You can actually drop the side and the bottom lines from group boxes and have the very same effect where you have stacked group boxes. So here we've got a UI on 10. It's pretty good. It's got Aqua compliance, pretty much.

The spacing around the edges of the dialog is a little tight, but it's pretty much there. And yet there's group boxes everywhere. So if we clean this up a little bit, remove the group boxes, we can actually do single horizontal separators. We can use the combo box that I introduced earlier to actually reduce the size of this dialog while still providing the same functionality. So we're trying to provide the widgets you need, but if you use those widgets and adhere to the layout guidelines, et cetera, you can actually reduce your dialogs in many cases and make them more functional and tighter and yet feel lighter and have more breathing room.

Here's an application that another difficulty I see, which is where a developer sees a need for something and they choose to customize it somewhat. And so here the developer has too many tabs for this dialog, so they figured, oh, what the heck, we'll throw a scroll bar above it and scroll the tabs.

The fact of the matter is that it's a non-standard way to do things, and not to mention the fact that the tabs themselves aren't Mac OS X compliant in terms of the appearance. And so as you clean this dialog up, what you get is a slightly larger dialog, because in fact there was only one tab that wasn't visible, but for some reason the dialog can't be resized. I don't know why. It's just a dialog box.

Think about your dialog boxes. Don't make them too small. I see consistently small, tiny, tiny dialogs where people have crammed stuff into, and you ask the developer why. I ask them why, and they say, well, that's the way it always was, or whatever. The fact of the matter is, dialog boxes are modal in nature. The user is focused on their contents, and they invoke them, they focus on their contents, and they dismiss them. and then they're done. Mac OS 9-ish. Bring your product from Mac OS 9. Make sure its appearance is Mac OS X completely.

Aqua provides for a very rich graphical environment. However, overuse of color and things too tight together mean that it's just too visually stimulating. So in this case, I don't know. There's just too much going on, even though it's fully compliant with the appearance of Mac OS X. The appearance for toolbars in Mac OS X is a very clean approach, and the icons we use are high quality in terms of their rendering. The icons we provide are shortcuts to things that are multiple clicks away. And so consider very carefully what you put in your toolbars. Don't put every function of your application as an icon, represented as an icon in your toolbar. You'll just have overpopulation of your toolbars. Focus specifically on those things that dramatically increase the productivity of your users. And I'm pleased to announce that as of Jaguar, the toolbar control is now available in Carbon. So Carbon apps can deliver a real system toolbar just like Mail or just like other Cocoa applications you've seen, including the configure sheet and all of that behavior. That all comes for free. If you're a Carbon developer and you're doing toolbars, you need to be leveraging the new control that's available in Jaguar.

So as you sit there and you listen to this, maybe you're at last year's session and you've read the book or whatever, maybe you haven't. You sort of sit and you go, help, I can't do this stuff. I don't know. I'm just a programmer. I don't know. I want to just present four resources that are available to you. And the first thing is an update to Power Plant that's going to dramatically improve the appearance of your product if it's Power Plant based. And to do that, I want to introduce Greg Dow from Metrowerks to talk through some of the changes there. Greg?

Hi, I'm Greg Dow, the chief architect of Power Plant for Metrowerks. I just want to give you a few tips here to help you be a good citizen, as John has described. Power Plant, one of its benefits is that it started back in System 7 days, and it's maintained compatibility with each OS. However, because of that compatibility, it's sometimes easy to get lazy and not update your user interface for each system. And so if you have a program now that's running on Mac OS 9, it's actually pretty easy to just flip the switch, make it a Carbon application, and have it run on Mac OS X. However, it's not going to look right, and it's not going to be a good citizen. And here are just a few quick tips.

Here are just a few quick tips of what you can do to quickly update your Power Plant applications to have an Aqua savvy appearance. First, make a new menu bar for Mac OS X. On Aqua interfaces, there's the application menu that automatically puts a quit item and a preferences item there. On Mac OS 9 applications, you probably had your quit item in your file menu, and if you had a preferences item, it was probably at the bottom of your edit menu. If you don't update your menu bar, when you port your application to Mac OS X, those items will appear twice. You'll have two quit items and you'll have two preferences items in your menu bar. Both items will still work, but it looks sloppy and not polished and you won't be a good citizen.

The other thing is background colors. On Mac OS X, the Aqua appearance, the background cannot just be a color, but it could be a pattern. And the standard interface has the, you know, subtle gray stripes. If you developed your application for a platinum look on Mac OS 9, you probably set it up so that your window had a light gray background color set up as the window color table. If you do that on 10, it'll again, you'll get that platinum look, but you won't get the proper system look. So use theme brushes, and Power Plant provides classes for automatically setting up your window so it uses a proper theme brush.

and use the AquaSavvy classes. So there's a little bit of discrepancy here in terminology between what John mentioned. When John talked about standard controls, he meant the controls provided by the toolbox. PowerPlant, because it's been around for so long, when it refers to standard controls, it means the System 7 controls. You had four controls back then. You had a button, checkbox, radio button, pop-up menu, and that was it. When the Appearance Manager came out, PowerPlant introduced a whole slew of new classes for using appearance controls. Those are the controls you should be using. You should not be using the standard button on Power Plant. You should be using the appearance manager push button, etc. Similarly for text, Power Plant provided a caption text that used drawing via quick draw calls. Don't use that on Aqua. Use either the static text control or the theme text box so that you get proper anti-alias text. And if you want to use anti-alias text also in your edited text boxes, use the MLTE pane rather than the text edit based.

Now I just want to show a quick demo here of two applications. One that was just quickly ported over to Carbon. I'm just going to run that here. Here's a trivial application here. I just want to bring it up. It's almost identical code to what you could have run on Mac OS 9 or Classic. You would have just taken your application, switched over to using CarbonLib instead of InterfaceLib, defined a single preprocessor global to, say, make it a Carbon build and rebuild. And what you get is an application, and it runs, and it's native on Mac OS X. But, you see, here's the system menu providing preferences. and a quit item, but those items are there, are still in your file menu and your edit menu. And if I bring up here just a simple preferences dialog window here, you can see this window has the gray platinum background. And if you look very closely, you can see that it actually has the Aqua little stripe background here just along the edges here because the window definition is actually drawing that, and it's drawing the proper Aqua appearance, but the content here still has the gray. These buttons here are actually the standard System 7-style buttons. The operating system tries to make it so that they actually have the new appearance. You probably can't see it, but if you look closely here, the bottom of the pop-up menu is actually chopped off a little bit there. You don't get the full shadow effect. And just as a side-by-side comparison now, if I bring up an AquaAware program here, now we have the file menu. Oops.

I'll skip there. The file menu with no quit item. Edit menu has no preferences item. We bring up preferences here from the application menu. And here. the interface has been aquified. Here we have the nice striped background. And if you want to notice some other subtle bugs here, you can see the non-aquified application. Actually, your button is pulsing here in the background.

This is the disabled window, but because these are stupid System 7 controls, they don't know to properly disable themselves, so they continue to flash, and it continues to be active text here. Whereas if I click off over here, you see everything properly dims out over here on the aquified interface.

Another point that something different that happened in Power Plant that some people have tripped up on is when you use the static text control, the control manager automatically erases to the background. In this case, you get the gray stripe background here. And if you're drawing your text over a picture, well, you probably don't want that. What you want to use is the theme text box. This still draws anti-alias text, but it doesn't do the erase before you draw. So if you actually want to draw text over a background, use the theme text drawing box instead of a static text control. Another point here, although it's not obvious visually, is something that Apple has recommended is that the title of your pop-up menu should actually not use the title of the pop-up menu control. You should actually create your title for the pop-up using a separate, either a static text control or a theme text box drawing so that the two are independent. has to do with the appearance and dimming, because if I actually made this the title of the pop-up menu, it actually wouldn't dim here properly when I deactivated the window. So that's just another quick tip there to get your applications looking right on Aqua. And that's it for me right now. I'm going to switch it over back to John here. So go out and aquify your Powerpoint applications. Great, thank you, Greg. - You pressed the wrong button.

Second tool that's available to you is coming soon, and it's AIDAP, kind of a cute little acronym that I came up with, called the Apple Interface Design Assistance Program. Basically, it's a program that I'm pulling together, which is to identify human interface design agencies or visual design firms that can help you implement the things that I've talked about, or help you design a really highly usable application that looks great in the world of Mac OS X so that you can implement it.

Not everybody is gifted in this area, and there are certainly people that are gifted. And so if your company feels that it needs the assistance of these companies, I'm trying to provide the resources available to you so you know who to go to rather than sort of just picking in the dark, saying, oh, maybe these guys know how to do it. So these will be companies that we know have a proven track record on Mac OS X in terms of interface design. So more details to follow in the developer news. Thank you.

Third resource available to you to help you create a great application that knocks it out of the park from a user experience point of view and from an appearance adherence point of view, et cetera, is the human interface guidelines. This book is constantly being revised. We've got another revision coming specific to Jaguar. We'll talk about where to use ComboBox. We'll talk about universal access. We'll talk about speech, where to use speech. We've got a lot of new content. And just encourage you to look at this book and read it and review it and reference it. Make sure it's available to the people who are designing the user interfaces for your product.

And the fourth thing is Apple's interface design tool of choice is Interface Builder. Interface Builder, if you've never seen this, is an incredible product for creating the interface on your application. And I consistently run into developers who've never seen Interface Builder. They're a Carbon developer, or they're even a Java developer. They've never even heard of it, or if they heard of it, they didn't realize what it would do. Interface Builder provides this drag-and-drop metaphor for dragging buttons and UI elements onto Windows. and as you drag them and move them around you get guidelines, guides that appear automatically that tell you where to put that button if it's going to be in the bottom right corner or where to put that tab pane and how big should it be sized to respect the margins around a window and stuff. If you've never seen Interface Builder go to session 904 I believe it is which demonstrates IB and shows you how to use it. And if you are using it today to prototype your product or to lay out your UI consider taking the extra step if you're a Carbon app for example and leveraging nib files. Instead of being resource file-based or using some other mechanism for defining the layout of your windows, consider using the Carbon APIs to read in nib files, which means you'll be able to use IB to create your UI and then read those files in and use them to display your interface.

Let's go back to the definition of citizenship. We looked at the first sentence, and we talked about the benefits that are available to you if you create a really compelling product on Mac OS X. It's not enough to just bring your code to Mac OS X and then sort of ship it. It is enough, or it's... The thing to do is to move beyond that, to go beyond just the basics, beyond just porting your product to the platform. It's really a question about going way beyond those basics and leveraging and implementing all of the other stuff we've talked about today and a whole lot more, which we didn't have time to talk about. But I want to talk about now the other part of this definition, which is the conduct as a citizen.

And in this case, I want to bring up three of your peers to share their experiences adopting Aqua and the process that they went through as they looked at Mac OS X for the first time and looked at their current product and decided how would they bring that product to Mac OS X. And I think hearing their experiences will be very educational for you just in understanding that other people are going through the same things you're going through and also learning some of the thought processes that they went through that you might be able to employ for yourself. So to start off with, I want to introduce Stuart Despain from Microsoft to talk about their process with the Office 10 product on Mac OS X. There you go. Thanks, John. Thank you.

stand one moment is it back okay I'm back Thanks very much. Well, I guess I don't have to shout now. So as I was saying, bringing Aqua to Office. The first question we needed to ask ourselves was, is carbonizing really enough? We knew that we'd probably have to take some significant resources to bring Office 2001 over to OS X and all the benefits that would come with it. But we also knew that infrastructure work alone really isn't a compelling upgrade. And so we needed to look to implementing some new features, foremost amongst them was Aqua. Now we have an old code base, it's been around for a while, which means there are a lot of old tricks around. User interface elements that people have become familiar with.

But Aqua is introducing a new language and we wanted to take advantage of that. So our goal very quickly became to set the bar. We really set out to be the poster child for Aqua and OS X. The first thing we needed to do to get there, of course, was identify the critical areas. What are the high traffic areas?

What are the low visibility features that we wanted to elevate to really exemplify Aqua? And so here are a few examples. To start off with, toolbars. That's a very high visibility area. The toolbars are what we feel the thing that frames Office and lets you know where you're working. Now, we liked our Office 2001 icons. They looked great. But we wanted to do better. So in Office 10, we brought in more gravity, more depth, more 3D real world type icons that were very clickable. And most importantly, we wanted people when they were working in Office to see those toolbars, to see that frame and know that they were using Office under Aqua in OS X.

The project gallery was introduced in Office 2001, and it's been very popular, very successful for us. We were happy with it, but we knew we could do better. In Office 10, we changed our file icons so that they were closer in line with real-world objects. So our calendar really has a calendar in it. Email has a big envelope in it. The slide deck for PowerPoint looks like there are slides you can hold up and actually project to sort of convey to people these are the functions that these documents are going to actually execute.

In terms of low visibility features that we knew were helpful, the view switcher. PowerPoint and Word both have a view switcher that changes modes to allow you to do different kinds of work activities. Sadly, they were kind of buried at the bottom left corner of the document window and they're kind of hard to find.

So in 10, we brought in a finder-like view switcher that punches those features out. People can see right away. There are big clickable buttons down there And they're much more successful at finding that feature. We even wanted to bring Aqua to our product icons though. It was definitely enhancing usability, but we want things to look great. We want people to know that this is a new suite of applications under a new operating system. And we changed our icons so they were more, had more depth, more exciting, more new, more fresh.

But beyond the static visuals, we wanted to take that language step a little bit further. So we introduced animation. Now, the formatting palette was something we introduced in Office 2001 as well. Again, very popular feature, and we're very happy with it. But we have a slight problem if people were trying to manage their windows. There was a case where people would hide the formatting palette because it was in their way, and then they couldn't find out where it went, as you can see here. So in Office 10, we introduced animation so that when people close the formatting palette, it genies into a toolbar and then genies back out. And this has greatly enhanced the discoverability. We've also enhanced the formatting palette with other animations. For example, when you close in high panes, and there's a lot more fun stuff we can do in the future. Aqua also gave us the opportunity to redefine our dialogues. You've seen a lot of examples today about dialogues that didn't quite make sense, and, well, this is one of ours. This is the FillFX dialog. Kind of hard to follow.

When we were moving over to TAN, we were also bringing in new features. So we took this as a good opportunity to change the look of the dialog so that it had a better flow. That we didn't just aquified it to a many extents, we macified it so it was much more usable.

We also wanted to bring the key components of Aqua to our feature set. Beyond the user interface, we wanted to embed it into the actual product. Our graphics in 2001 were nice. Our charts looked nice. The problem is the edges are really, really jagged. Their transparency didn't work really well. And these were obvious clues for us that in Office 10, we wanted to see anti-alias text, anti-alias lines, transparency, and I think the results speak for themselves. Much, much better charts. So have we been successful?

Well, the San Jose Mercury News thought we were the best looking piece of software they'd ever seen. From Wired, they thought we were so pretty they didn't believe we were real. Steve Jobs asked for a round of applause and said that Apple was thrilled with the application and we're thrilled to hear that. So have we been successful?

Well, there's been a payoff. 800 dialogues later, 500 icons later, we have a great looking product and we're very proud of it. And the reviews have been very motivational, certainly for our team. It's great to get up in the morning and fire up your browser and read these great reviews from people who really enjoy the work you're doing and then they're getting to use your product and enjoying it even more. And of course, it translates into sales. The more people are excited about your product, the more they're going to want to go out and try it, especially as momentum builds more and more and more behind OS X and hopefully Office X along with it.

So beyond that even, it's also sparking ideas for our next revisions. We've been very successful adopting the language of Aqua in Office 10, but there's a lot more we can do, and we're thinking about this all the time, so we're really thrilled with it. Thanks, John. - Great, thank you.

Next, I'd like to invite on stage Ivor Clarke, who's president of Simple Factors, a design agency working with a company called Media Maker. Thanks, John. So as John said, my name's Ivor Clarke. I'm president of Simple Factors. I'm here to talk to you a little bit about the work my company did with MeetingMaker. First of all, a little bit of background. MeetingMaker, for those of you who don't know, is a collaborative scheduling application. It's been around for a fair amount of time. It's about 12 years old. They're on version 7. It's one of the original applications.

There's a lot of stuff that's been hanging around there. And they're now engaged in a two-part release strategy for OS X. The first is to get out a version that is carbonized, works on OS X, gets full functionality. It's what everyone's been clamoring for. And the second is to really take advantage of it and knock -- take advantage of Aqua, take advantage of the operating system, and really knock a release out of the park. The first portion of that was released just a couple weeks ago. That's version 7.1. Amen. My company, Simple Factors, was brought in to assist in the designing of version 8 just a short while ago.

So before we talk about anything else, the question is, why bother? They've got a release that's fully carbonized. All the functionality works. You might as well say, job done. Why move forward? Well, first of all, customer feedback. When we started designing version 8, Aqua had been out for two years. Customers are really starting to expect that of an OS X application.

OS X is not about multitasking. It's not about multithreading. It's becoming about Aqua. It's becoming about a great user experience. Second of all, it's a way to get noticed, which you saw from Stuart's presentation. When you do a great job with AQA, the press and others are going to stand up and take notice.

It's also an opportunity for bigger changes. As you're going in, making the changes to make a great-looking application, making the changes to take advantage of Aqua, you have the opportunity to really get in there and reevaluate some of the ways you present your user interface. As I said, Meeting Maker had been around for 12 years. This was an opportunity for us to go in and ask ourselves, were we really doing some of the right things with the fundamentals of the application?

And finally, other platforms. There are some other platforms out there. Meeting Maker ports to them. And they are also, some of them, starting to put an emphasis on the visuals of the applications. And trust me, the work you do to create a great looking Aqua app will not be lost when you move to other platforms.

so what do we focus we didn't work to don't take the list of awkward features and just sort of make a checklist instead we said well what is awkward about their couple things first of all look and feel i think this is what most people associate with awkward high production value you know great uh... great presentation But it's more than that. It's more than just pulsating buttons. It's also a way to improve feedback for the user. You know, when you look at the dock, the genie effect, sheets, all of those are ways to tie what's going on in the system to an action that the user has taken, and it really helps reinforce those actions for the user. And finally, information presentation. One of the reasons Aqua looks great is because it does a great job of presenting the user's information. If you take a look at the column view in the finder, that's the same type of information shown in the list view or finder view. But they've taken the opportunity to find a better way to present that information. And I think it's what many people are finding the most useful.

So I want to walk through a couple examples. This is the contact window. And when we were looking at aquifying it, there's nothing fundamentally wrong with this. You can see everything. We could have just put a striped background behind it and called it done. But we wanted to do a little bit more than that. And this really goes to improving information presentation. Rather than just changing all the controls, we also looked at how the information was organized. We looked at how it was presented. And what we ended up with is something that not only looks a lot better under OS X, but it does a much better job of presenting the information and becomes more usable.

This is the proposals window. This is where you see proposals from other users for meetings or invitations that you've sent to other users for meetings you've created. Now, we could have, again, just put some tool-- put some new toolbar icons in, improved the title bar, scroll bar, that kind of thing.

But instead, we again re-evaluated what type of information do we need to present to the user? How can we make it look better? Yes, we've got the new icons, and we've got the new controls, but we also looked at the types of information that are required for the user here. We gave them a little extra data, and in doing so, allow them to make better decisions when they're using the product.

So this is the schedule window. The schedule window is used to pick a time for your meeting based on your guests' availability. So if you see that red stripe on the left-hand side, that's the availability of all your users. It shows when they're all busy or when they're all free. Well, that can be a little limiting when you're trying to make a decision about when to have a meeting. So when we redesigned it, not only did we Use Apple's dialogue layout guidelines, use new controls, make sure the presentation was right, but we also added extra information. Now you can see on a case-by-case basis whether a user is available. You'll also notice that yellow transparent stripe, that shows your chosen meeting time. We took advantage of some OS X technologies to use transparency to improve the ability to see whether the meeting time you've chosen conflicts with anyone. - Okay, stop, stop.

So my final example really touches on that piece of improving feedback to the user. This is the dialogue you go to when you want to change the view of your calendar, change the appearance of your calendar. Say you can change some fonts here, some other stuff. But of course, what you have to do is look at your calendar, imagine what you want, go to this dialogue, make the changes, click OK, then go back and see if what you changed is actually what you wanted. Hope you're right. So instead, we just tie it in directly. As the users make the changes to colors and fonts, they see them reflected directly in the calendar. And then when they go back, it's going to be exactly what they wanted.

So finally, reaction. Now, as I mentioned, this product has just started the development phase, but already we've begun to share it with customers. First of all, there's an enormous amount of energy in the organization. The development team is getting really psyched about developing this. The test organization can't wait to start testing it. Sales is already seeing this as a huge opportunity to go out and sell a new product to customers.

And customers are really, really liking what we're showing them. They see we're taking Aqua seriously. They see we're taking OS X seriously. And they also see us really putting an emphasis on what's important to them. I mean, administrators are the people who have to take care of this in an organization, so it can cost them a lot of money if the product's hard to use. They see us taking usability of the product seriously, and they really like what we're doing. That's pretty much all I've got, and I'll hand it back over to John. Thanks a lot. Great. Thank you, Ivor. And the last testimonial, so to speak, comes from Microtech, and I'd like to introduce Kristen Lee to talk about their experiences. Hey, Kristen. Hi.

Thank you. Hi, my name is Kristen Lee. I am Marketing Project Manager for Microtech. We manufacture consumer and professional scanners and also develop the software that controls them. We have a little bit different story. Our initial plan for releasing our professional scanner, or scanning software, was to port it to Carbon, add Aqua Icons to it, and ship it. Well, this made sense for us. We have a very complex UI, and we were able to save time and resources for engineering, and we'd also be able to reuse our documentation for Mac OS 9. But last September, we attended an Apple Design Kitchen, and in just a few hours of working with Apple, we really realized what a benefit applying the ACWA guidelines was going to make for us. So, we went to the other extreme. We took full advantage of the opportunity. We took our application, which historically has had a truly Windows look and feel, and created a unique Macintosh interface. We also took the chance to update and reposition our software to a true high-end scanning solution for photographers and graphics pros. We went from ScanWizard Pro 6 with a cluttered haphazard look and feel bitmap jaggy icon. to ScanWizard Pro 7.0, clean professional feel, and a fantastic new application icon that really makes sense to our users.

Quickly going through some of the windows that had the most modifications, our preview window. Preview window contains tools, all of the action buttons for our application, as well as a pop-up menu for scanning material. In the previous version, this pop-up menu had an icon that really confused a lot of our users. So we decided to opt for a very simple pop-up menu. We rearranged all of the information for workflow, and we redesigned all of the tools as well. You'll notice in later slides as well that we have moved all of the tools to the upper right-hand corner, making our application much more intuitive for the user.

Next window is the settings window. This window controls our application. And as you see, with the amount of information, and especially the organization of it, very complex and intimidating. You'll also notice something that John harps on often. On the left-hand side here, we've got labels as buttons, and we've got very unclear icons on top of them.

In the new window, it has a much different look and feel just from clearly aligning the information. We've also taken and reorganized some of the information for workflow, and I would like to point out category. The category pop-up is used to set the controls below it to different custom settings. In the old version, this was very unclear, but now you have a control that shows that it's dominant over the controls below it. You'll also notice that the buttons and the icons have disappeared.

Lastly, one of our correction dialogs. This has a very complex workflow. The dialog is used to create custom settings for some of the controls in the settings window. The icons along the left-hand side here are used to navigate through this multi-panel dialog. And you'll notice that those icons are the same unclear icons that you saw in the settings window. Also note that the tools are floating down within the content of the dialogue.

In the new window, most of the main content of the dialog is still the same. What we've done is made a change to the navigation and the shared controls of this dialog. Navigation moved from the buttons along the side to a simple pop-up menu at the top. All shared controls were also moved along the top, and the tools were moved up into that right-hand corner to, again, create that intuitive feel for the user.

The end result for Microtech, we not only had a software application that really had a rebirth, we also had incredible internal morale. The effect of this change was incredible for us. The energy within our organization, we had support flowing into this project, we had resources given from every department. This was really an exciting project for Microtech. We also got increased visibility within Apple, and who here does not want that? Excited Mac community, they are now seeing Microtech support them truly. And of course, beyond that, we have increased sales. One other note, you know that I mentioned that this has always had a Windows look and feel. Well, now we have our Windows group really excited to make changes to their application based on the changes that we've made here. So put in the time, make the effort, it is really well worth it.

Great. Well, thank you, Kristen. The end result is-- it's clear from these three cases and lots more that I could have brought on stage, but we didn't have time for it-- that if you put the effort in to make a really, really great user interface, put a really great user interface on your application and an interface that makes the product highly usable, the end results are significant, and the benefits to you as a good citizen in the world of Mac OS X are significant. Remember, don't focus just on your features. As the engineering people, typically, probably the audience is filled with programmers, you're interested in what you wrote, right? You want your feature to be exposed to the world. But remember, users don't really necessarily care how your product, what it does necessarily. I mean, they do, but they're more focused on how it does it. Ease of use really matters. These interfaces that are discoverable really matter, and the benefits are substantial. Okay. So the last part of the definition of citizenship is that there are awards for good citizens.