Ladies and gentlemen, please welcome Manager of Software Technology Evangelism, John Geleynse. Hey, good morning. Welcome to the second session of the second day of WC 2004. I hope that this is turning out to be a really great conference for you, and I hope that at the end of the week, you look back and say this is an incredibly valuable week for you, and you've gained a lot of experience developing software on the platform.

Let's see, is this the right slide? There we are. This is the one I want to start on. This session is all about how to distinguish your application on the platform. We're going to talk about UI stuff, designing for Aqua. We're going to talk about technology, choices. We're going to talk about planning your product.

I just want to say up front that a lot of this content is based on my experience and the experience of my team working with many of you and your peers over the last year or two years, helping you to understand what's going on in the platform and how do you take your product to the next level. This content really comes out of all of those conversations and all of those meetings and is an attempt on my part to just clone those conversations and share the information that we've shared with so many other developers with you.

It's not meant to be all-encompassing in any way, shape, or form, but I think it's touching on the areas that I think people have the most difficulty with. I hope you find it valuable. I'd love to hear your feedback after the session, either through email or through conversations directly with me.

I want to talk about what it takes to create a great product on the platform, and I want to do that by drawing an analogy with the food industry or the restaurant industry. And I want to begin with the fast food experience, right? What do we know about the fast food experience? Well, we know that there's a lot of unskilled kitchen staff, right? We know that there's a lot of frozen mass-produced ingredients. It's all about getting lots of stuff out there really fast, getting this material prepared quickly for the customers, and a lot of mass-produced ingredients.

Poor nutritional value. By and large, most fast food joints aren't in existence for good nutrition, even though there's a lot of advertising around that. But that's sort of a fact. And these are John's sort of statements about the fast food industry. They're not, you know, anything more than that.

But take it for what it is. A lot of artificial flavor. I read a really great book recently that said that chicken McNuggets and such were, you know, produced in a lab and the aromas that you smell are completely fabricated. It has nothing to do with the food itself. So interesting.

What else do we know about the fast food industry? Well, a lot of poor presentation. Most of the time, stuff is slapped together by unskilled kitchen staff, thrown on a plate or in a container, and there you have it, right? It's all about the speed with which you get the food and address your appetite than it is about the presentation.

And lastly, we know that mostly the fast food experience probably isn't that good for you, right? I say bad for you, but maybe that would be misrepresenting things, but it's not necessarily that good for you. Now let's compare the fast food industry to the fast food industry. experience with fine dining.

Well, unskilled kitchen staff is certainly replaced by highly skilled kitchen staff, people who have trained their lives for this stuff, trained to learn how to cook and put this stuff together in a really, really great way. Frozen mass-produced ingredients. The Mac OS X is a great way to develop your Mac OS X experience. You can use it to create your own Mac OS X app, or you can use it to create your own Mac OS X app. You can use it to create your own Mac OS X app.

Good nutritional value. By and large, you know, if you go to a great restaurant, it's all about good food, right? The flavors are mouthwatering. They're really good. It's not artificial flavors. It's the real stuff, right? The real McCoy. Attractive presentation. I mean, some of the restaurants that I've been to, and I'm no guy for haute cuisine here, but I've been to some nice places here in San Francisco, and the presentation has a whole lot to do with the enjoyment of the meal. The food is fantastic, but certainly the presentation is great.

And lastly, by and large, you know the fine dining experience, the food that you eat, the whole experience, in fact, is probably, in a holistic sense, really good for you. It's probably good for you in terms of nutritional value, but the overall experience of going to this fine dining evening or what have you is good for you. And so I want to draw this analogy between the fast food experience and fine dining experience and software development on the platform.

I ran the Apple Design Awards this year, and I do that every year, and we get a ton of submissions. This year we had less time to judge even more submissions than we've ever had. And I'll tell you, a lot of submissions fell in the category of fine dining experience.

It was a fine software experience. But there was a percentage that was really fast food. It was somebody just threw something together, shipped the product, and threw it into Design Awards. And I think, not I think, this session is all about teaching you, giving you the insight and expertise to create a really great fine dining experience on the platform with your software.

So, what does it take to create a great experience, a great dinner party? Or if you're the manager of a great fine restaurant, what does it take to pull this all together? Well, essentially there's kind of five steps. And again, I'm in the software industry. I don't run a restaurant, but this is kind of my perspective, so take it for what it's worth. But I think to create that kind of an experience for your customers, it takes these five steps.

Planning your menu, extending a warm welcome, creating a great ambiance, sweating the details, right? Choosing the right silverware, utensils, choosing the right linens, picking the right music, and all of the stuff that goes into an evening that you might put together for your friends or if you're running a restaurant, right? All of those things matter, and if some of them aren't there, the experience can go downhill pretty quickly.

And lastly, ensure quality service. A great restaurant can totally torpedo in your opinion if the service sucks. If nobody's there to get what you want, when you want it, or get rid of stuff when you want to get rid of it, your opinion can go down really quickly. Well, let's take that and compare it to the software development process. To create a great application on the platform, you don't need to choose your menu, but you do need to plan.

You also need to create a great first impression. As you walk to a restaurant with your date or whoever you're going with, that first impression, as you walk into the restaurant and you smell the aromas and the temperature is right and the ambiance is just great, that can set the evening off either to a great start or it can totally ruin the evening right from the get-go.

Sweating the details for software development is all about paying attention and choosing the right fundamentals, including the essential ingredients, the essential elements in your product. And we're going to talk about all of these. Creating an attractive ambiance in the software sense, I'm talking about creating a great ambiance with your software through Aqua. And we'll get into that detail.

And lastly, I think great service, the analogy to software, is delivering a really responsive, high-performance application. And if you think of the experience that you've had running software, the products that are less likely to be on your top choice are the products that are not really responsive, or they're either lagging somewhere, that don't really respond in the way that you want them to.

And I think that's a lot like the experience we have at restaurants, where the waiter isn't there when we want it, and our needs aren't met exactly. So, let's go through these individually. First of all, planning. This is about deciding what to make and whom to make it for.

There's about four or five steps here, and this is not the all-encompassing list of what you need to do for planning your software. This is, based on my experience working with developers, these are the areas that most developers, I think, don't spend enough time on. So the first thing that's critical, I think, is understanding who your users are.

First of all, first and foremost, you're not your user. You might come from the experience of your users. You might have been a teacher previously in your previous life, and now you're a software developer for K through 12, or you might have been an accountant, but now you're writing software for personal finance or what have you.

So you might have some sense of who your user is, but you are no longer your user. You're the developer, and you have business pressures, and you've got all kinds of things that are going to influence the decisions you make. It's important for you to understand who your users are and what their needs are, what their priorities are, what their expertise is.

And understanding, based upon their expertise, that some users who aren't that sophisticated are going to become proficient in certain tasks, and your software needs to lead them towards that proficiency, and they're going to graduate to more complex tasks as well. But highly sophisticated users on the computer with your software are going to be masters at some tasks, novices at others, and are going to be frustrated mostly when your product gets in the way.

John Geleynse Well, this seems like common sense, right? Truth of the matter is, I think most software developers are trying to aim for whoever the heck will buy their product. It's like, okay, let's just throw everything into this puppy and hope that anybody in the world, you know, whoever can buy it will buy it because it's just another customer for us.

But the truth is, I think some of the best products on the platform are the ones that are focused, very focused on a particular market segment and at a particular set of users. And they address the needs of those users, and they address the needs of those users.

perfectly and those products totally dominate that space. And think for a minute of some of the software that you use that fits into that space. I mean, I think all of us could probably identify a product or two that fits into that. So it's critical, I think, to pick your audience and know what their needs are and pay attention to how sophisticated they are. And a great example of this, for example, is if you were going for less sophisticated users and producing an iMovie type product.

I mean, right from the get-go, Apple said, you know what, iMovie is for home users. They're infrequently on the computer. They're going to be bothered or hindered in some way by the multi-windowing environment of Mac OS X. We'll just give them a full screen experience because they're totally focused on that exercise of editing video.

That was a very deliberate decision on our part to create a product for less sophisticated users. Clearly, the experience with Final Cut Pro is different than the experience with iMovie, right? So there's two examples of how the product design was influenced by the user base, and that's kind of the point I want to make for you guys. So the first step in planning was understanding your users.

The second one is sort of knowing your application. Understand your application. Understand what it is that you really want your app to do and get a good grasp of that. And I think as you come to define what it is you want your application to do, you need to take into account the fact that you have a lot of experience with the app.

You, your company, you as an individual, you, your company, have certain value add that you can bring to the market with your product. You have certain expertise. You have certain inherent strengths as a company or inherent sort of assets that you can bring to the product. And your product should be built around those primarily.

It's important to design for usability, understand what the workflow is of the users. How do users expect to work with this product, and how can we make the product map to that experience? Think about the interaction with other applications. If your application is aimed for less sophisticated users and you're a single window product like iMovie was originally, it's unlikely that the user's going to be interacting with other applications at the same time. They're editing movies. They're not doing drag and drop.

They might do cut and paste, perhaps, but not likely. And so within the application, they might do cut and paste, but not any data exchange with other applications in that sense. Interaction with other applications is important to think about as you consider who your user base is. And all of these things, in terms of planning, help you to craft what your product will be and what its feature set will be.

I find as I meet with developers that everybody's trying, you know, most people are trying to do everything for everybody. And so then they're demoing the product for me as I do a UI review and they're showing off how, you know, the app can do this and it can export and import and drag and drop and, you know, it can stand on its head and it does all this stuff.

And I keep coming back to them saying, well, who's using this product? Well, you know, we've got some customers here and say, well, you know, who's using this? What are their needs? And as I keep driving on that point, developers realize, you know what? Actually, we don't need that. We could drop that whole feature. No one would care. And the usability of the product might increase. So I don't want to belabor the point. I've got tons of stuff to go through today. So let me move on. All right.

Deliver solutions and not features. I hammer on this every year at WC, and I think we're getting better in this as a community, as a platform, we're getting better in this regard. But still, and there's some examples I'll show you later on, still there's this tendency to just pack in the features because there's pressure from your marketing team or whoever it is that's giving you pressure as an engineer to get those checkboxes on the side of the product box, right? It's not about features for the user. It's about whether the product delivers on the promise. It's about what it can do. So you need to be producing products that deliver an end solution for customers that is the be-all and end-all for them.

Use the 80% solution. This is really all about designing for 80% of your customers. Once you identify who your users are, then you can sort of aim for trying to please 80% of those well-defined, for that well-defined audience. A lot of people spend most of their time developing for 20% of their audience, who tend to be the vocal minority. It's the people who tend to be a little bit more sophisticated who can get that feedback into the developer through a blog or through an email or whatever mechanism there is.

The less sophisticated users kind of go, "Well, you know, I'm not sure how to get the feedback to the developer," so they're kind of silent. They're the ones you kind of want to design for rather than the vocal minority, so keep that in mind. Don't always design for the vocal minority.

The best tools are the ones you're not even aware you're using, right? If you think of a carpenter or a mechanic or any of the tradespeople out there in the world, they have whole vast collections of tools. Why? Because every one of those tools is properly balanced, it's tuned exactly for what it does, and I think it's no different in the software industry.

I think I would much rather have a computer with hundreds of apps, all that are tuned for what they're supposed to do, all that are scriptable so I can use something like Automator to start connecting them together and create a great workflow, than having three apps that are just, you know, got thousands of features in them that I can't even find half of, half of the features for. All right.

Third thing to do in terms of planning your product is understanding your market needs. If you think about the characteristics, for a moment, of some of the best software you've used on the platform, what would you come up with? Some of the characteristics of the software and the best platform, I think, are the ones down here on the left.

Some of the best software I've ever used was high performance, very responsive. It was elegant. It was attractive. It was dead easy to use. I got into the thing and I was able to do what I wanted to do. It was compatible. As I started using it, I realized, hey, I need this image from over here, this whatchamacallit from some such other application. And boom, I could get it in there, no problem.

Very mobile, right? Launches quickly in my PowerBook, has no issues going to sleep. It's just a really mobile application. It's accessible. We'll talk about that a little bit more. I think these are some of the characteristics that we all want in the products that we use, whether they're the ones we write or whether they're the ones we use.

So if we look at some of those characteristics and then contrast them with some of the market segments that many of you are participating in, and certainly Apple is participating in, it's interesting how some of them map to those market needs. This isn't meant to be the definitive statement of where Apple's participating, doing business.

This isn't meant to be the definitive statement of what the characteristics are for any. Again, it's John's perspective on this point, and I think the whole point here is just to get you to think about what are the characteristics that you want in your application and how do those map to the market segment in which you're participating.

As you understand who your user is, you're going to identify them and place them within a market segment. So let's just take the first two columns. If you're developing a game for the platform, what are likely to be the highest priority characteristics for you that you have within your product? Well, high performance is key for games, right? Great responsiveness, great fast rendering of stuff on screen, attractiveness.

A lot of the sex appeal of games is how cool they look and what the audio is like and how attractive. The game is a game of games. That's what the whole experience is. And easy to use, I think, is important for games, too. If it's too hard to play, it's like, well, forget this.

Contrast that with the home user, with the home market, you know, high performance isn't as big a deal for them. In fact, I chose not to put it on the slide as an option for them. I would say for home users, for the home market, infrequent, less sophisticated users typically, elegance, attractiveness, and ease of use are key. Once you identify which characteristics you want to go after, it's important to prioritize them.

So take those same markets. Again, this is John's opinion. This is not meant to be the authority. But I would say for games, number one is performance. So if you're writing a game and you haven't run some of the performance analysis tools and tuned that product for Mac OS X, I think you're missing the boat in terms of your opportunity to stand out and distinguish your application on the platform relative to your competition.

Responsiveness is, again, key. I think the two go together. And attractiveness. Home users, I think the number one thing for most users who are less sophisticated is ease of use. If you don't get that right, your product, I think, isn't going to be nearly as successful as it could be. All right.

So once you've done all those things, you sort of throw it all into the pot, you stir up the soup, and I think out of that comes a great starting point and a great understanding for what your product can be. And then it's from there that you go on to your development plans and you sort of figure out what you're thinking about. What your feature set will be and how are you going to end up delivering the solution that you think that market needs.

And again, you know, I touched on this a little bit before, avoid the market buckshot approach, buckshot market approach, which is kind of like stick the product in a gun and shoot, you know, and hope it hits as many users as possible. It doesn't work, I don't think. And most of the developers I've met with agree that if you focus the product, you're going to get a great, great experience and great business. So that's planning, step one.

The second thing is creating a first... Creating a great first impression. This is all about surprising and delighting users from the start. Remember, you go to this restaurant and you get this great aroma and the music is great and you think the people you're with are great and the whole thing is awesome. I think that is true for software as well. And I've reviewed tons of software in the years at Apple and I'll tell you, some get this right and some do not.

I think first of all it starts with packaging. What is your physical packaging like if you're in a retail store? Clearly some of you might be developing for enterprise or for in-house or for schools. There may not be a real package, so that's fine. Just ignore this. But for those of you in a retail store, I think packaging is a big deal.

If you're not communicating the system requirements in the package, you're setting yourself up for a tech support call, which costs money because a user's going to call in and say, hey, I bought this product and it doesn't run on my machine. So make sure that system requirements are really clear. If it runs on Mac OS X, put the badge on it.

Distribution. A lot of software goes in retail stores. It's on a CD. It's in a box. But equally, there's a lot of you selling software directly on the Internet, and that's great. Disk images are the way to go. Put your software in a disk image. It's already compressed. You can put a password on it if that's important.

But avoid compressing the compressed. I have seen some really, really awful, really scary situations where I've got, you know, I get a CD or I download something, and there's stuff inside, you know, there's a stuff inside an HQX, inside of a DMG, inside of a... I don't know how that happens, but it just does, and it's something that we should all avoid.

Installation is a great way to create a great first impression. Make it dead easy. Users buy the product, they spent money, they want to get this thing up and running, they probably have a real need that they want to satisfy, and if your product is a pain to install, it's going to just knock down their impression of the product.

Drag installs are great. Disk images support drag installs. The thing mounts and you drag your icon over to the applications folder. The user can put it wherever they want, which I think is really critical for installs. Disk images, I don't know if you knew this, but disk images allow you to display a software license agreement or a EULA.

It's a little bit hokey getting it to work, but you can make it happen. And so if that's the only reason you're using an installer, so you can display some sort of legal license agreement, you can actually get away from installer, go to a disk image, and put that license agreement in the disk image.

or go with the Mac OS X package installer. So there's a session later on today, I think, about using the installer. I think it's important to avoid shutting down other processes. Recently, I installed some software for the Apple Design Awards, and the blasted installer forced me to shut down everything that was running on my machine, my browser, my mail, everything, just so it could install the software.

I'm not sure why, and it was a total pain. Avoid unnecessary authentication. If you're not installing outside of the current logged-in user's domain and just put stuff on that inside their home directory or what have you, there's no need for authentication, so don't ask me to authenticate. It's a bother. And avoid custom installers.

Don't write your own thing. Just use what's available today on Mac OS X or from some third parties. There's some good software installers that are available. And the other thing is consider first-time launch initialization or configuration. So allow for a drag install, but then the first time your app is launched, build in sort of your own custom installer at that point, but don't make it look like an installer. Just sort of display an alert that says, one moment, please, while we get set up.

Or if you're a game for kids, say, one moment, please, while Mickey Mouse gets ready to play with you or what have you. And in the background, you're installing some stuff. So I have four little girls, and there's no more frustrating thing for me than when my wife calls and says, we got this CD from you that you brought home from work to try. And she says, we can't install it. And my nine-year-old calls. And there's multiple installers.

It's a total pain. And I think this is a great way to create a great first impression. So I don't want to belabor the point. Now, I was going to do an install, a lousy install demo. And I decided not to in the end because to save the face of the developer. But I'm going to tell you about it so that there's no logos displayed. This is an app that is an installer from a very well-known manufacturer of printers. And it is.

It's actually for a scanner. And so you download this disk image, and you run this thing, and it mounts on the desktop, and there's a single icon. And you think, okay, great. But it's clearly not a drag install. It's got a crummy icon. It looks like Mac OS 9. And you double-click this thing, and you get a license agreement. And you say agree.

And then it says it runs this funky, custom, totally non-Mac interface look and feel. And so, okay, you figure, okay. And you click accept or whatever the question is. And it says it's going to go. And it says it's going to go off and install all this stuff. Remember, it's just a scanner installer, okay. It's just making the scanner work that I bought.

And. Eleven minutes later, seven authentications later, and 2,700 files later, the software is installed. And you know what? I got a Rolodex software, and I got this image editing thing, and I got all kinds of other software, some of which applied to scanning, most of which did not.

The fundamentals. This is all about the essential elements that your product should have. And I think pretty much every product in Mac OS X, if you're shipping to end users and you're an application, this is a big section that I'm going to talk about here. But you know what? This is the stuff that your app needs to be leveraging.

If it's not, you're going to be totally, you're going to be, somebody else is going to stand above you in terms of the competitive space. Your competitor is going to come out and adopt some of these technologies, and I think they're going to stand head and shoulders above you as a result.

So, understanding what the essentials are means that you need to understand what the Mac OS X environment is and what it brings to the table. Mac OS X environment has a single menu bar. There's just one. So don't stick other ones inside of windows. It's a layered multi-windowing system. MDI doesn't cut it.

We don't want child windows inside of a single parent window. That's what the desktop is, right? We want multiple windows that we can minimize to the dock. Don't create some other dock inside of a window, you know, the MDI experience. That just doesn't cut it. So if your app's shipping on the platform, this is a basic that you've got to adhere to.

Another reality of Mac OS X is the dock. The dock is there. It's just there. Users can move it around the screen, but it's a reality, and it is there, and your application needs to respect where the dock is, because there's nothing more frustrating than unplugging your PowerBook from a large display at work, going on a trip, opening up your display, and suddenly now this app window is hidden behind the dock, and you can't resize it, and, you know, little things like that. So respect the dock's position and size your windows accordingly. And there's some standard behaviors for when your app icon is clicked. Mac OS X is an always-on environment.

Don't rely on rebooting to clear out caches or clear out temporary files. It's an always-on environment. My PowerBook stays live. I think I probably reboot every couple of days for, well, I'll tell you why in a moment on my next slide. But there's a reason why I reboot.

But you know what? If I didn't have it for that situation, I probably would leave my PowerBook on for days and not have to restart. It's always sleep, wake, sleep, wake, sleep, wake. The system is always on. Don't rely on login items to be the way that stuff's going to start up.

If users cancel a process somehow, and you're relying on login to start that thing up, and there's no other way for the user to start up that process, I think you're in trouble. Well, actually, the user's in trouble, and they may not know to get you in trouble, but... Another thing about Mac OS X's environment is that it's highly adaptable. The beautiful thing about Mac OS X is it adapts to all kinds of changes.

I take my PowerBook on my bike to work every day, and I plug it into a cinema display on my desk, I plug it into the Ethernet network, and I often unplug it throughout the day, probably 16, 18 times. I'm going in and out of my office, plugging this thing in, unplugging it, going to meetings, unplugging from the wired hard LAN, you know, the Ethernet, and going on to airport. So I'm detaching and attaching displays.

I'm detaching and attaching the Ethernet. I'm unplugging and plugging my USB printer, and that's the reason I have to restart my machine, because it doesn't realize that it's an adapting environment, and eventually, it just kind of craps out, and my machine has to be rebooted, because I can't print anymore, because this driver hasn't adapted to the fact that I'm going to be unplugging and plugging constantly. If you're developing software for the platform, understand it's a highly adaptive platform, and therefore, your app needs to be highly adaptive, too, and I'm sure you can all identify products you've used that are not adaptive.

Another key element of Mac OS X is multiple users. This is true multi-user stuff. It's not, for those of you who came from Mac OS 9, it's not pseudo multi-user environment. Mac OS X is a truly multi-user system, and there's some implications for you, the app developer, because of that. If you have shared resources, shared blocks of memory, or what have you, understand that-- well, first of all, if you allocate memory and you expect that if you have multiple instances of your app running that they're going to use that shared block of memory, then you can use a little trick called identifying those blocks with session IDs. But understand, because of multi-user environment and fast user switching, a user could launch your app in one session.

Somebody else could come along and say, oh, hey, can I just borrow the machine for a second? Or, you know, can I borrow the machine? Get on it, switch out to their environment, and launch your app as well. So now you've got two instances of your app running. What are you going to do with some of those shared resources? And can your app handle that? Can it run in multiple contexts? Don't assume exclusive access to resources. You might be running in multiple contexts.

If your app is using the iSight camera right now, and another user comes along and swaps out fast user switches to their account, you need to give up that camera so that if they're using iChat, or some other software that needs the camera or some other resource, that that's freed up.

Don't lock it and hold it so that nobody else can use it in any other user context. Not all users have the same access privileges. So in one context, if your app is making some assumptions about privileges on the hard drive, it can't necessarily make the same assumptions in the other context in which it's running. Not all users can write to the applications directory.

Multiple users, if your app is running and users save, default to their home directory. And while I'm talking about home directories, let me just make a point here that the documents folder is only for user-created, double-clickable documents. Don't stick anything in the documents folder that relates to supporting application support files.

Fast user switching introduces or brings to light an interesting user experience, which is I might be working currently on the machine in a bunch of software, and I'm editing a bunch of documents, and I didn't save them yet, because that's how a lot of people work, actually. And someone comes along to that machine.

Think of the classroom, context of a classroom or higher ed or even in an office. Multiple users using the single machine. Current user is editing stuff. Another user comes along, switches out to their, logs into their account, so these files aren't saved, right, because the context is just switched out. And now the second user shuts down the machine.

Well, your app can do some basic stuff to deal with that and really create a great user experience. And the Mail app does this today. Basically, it's called Fast Logout and Auto Save. As long as your app handles the standard quit Apple event, you're going to get notification that the machine is going down or that your app has to quit, basically. And at that time, make sure that your app can deal with saving a file to a temporary location provided by the system without any user interaction.

So just assign it some name, untitled or what have you, put it to the temporary location as a draft, and then when your app restarts next time, check that temporary location for any files that are of your type and open those things up automatically. Try it with Mail. It does a great thing. You're drafting some emails, boom, the system goes down. Next time you launch Mail, those windows open up. How cool is that? Every app on the platform should be doing that.

Another thing about the Mac OS X environment is that it provides consistent interface for common tasks. The beauty of common interfaces is that users have the experience of picking people or fonts or whatever they're interacting with from other applications, and so they bring that experience to bear in your application. If your app then allows them to pick fonts or choose colors in a completely different way that's custom for your app, the user has a problem.

So I think just using all of the APIs that are available in Mac OS X for common interfaces is just great. It's just good. It's a good thing to do. Some examples here, Address Book Framework, Disk Recording for standardized UI for that, Apple Help for user assistance, and many more. I didn't even list half of them here.

Yet another fundamental and essential on Mac OS X for every application on the platform is the accessibility and spoken interface feature of Mac OS X. Spoken interface today is in a public or beta preview. It's going to be shipped and built into Mac OS X Tiger. If your application, if your product is shipping into education at any level or into government, you need to understand that Section 508 is a big deal. Most customers aren't going to be purchasing software that's not Section 508 compliant, and there's stuff you can do today to prepare for this capability coming in the future. It's actually a lot of this is in Mac OS X Panther today.

The accessibility stuff in Spoken Interface was designed for users who are blind or have low vision or other vision disabilities and other learning disabilities or learning disabilities. It's built in, not bolted on. There's no extra installer, no licensing to be done from you. It works the same way in every application.

It leverages the keyboard shortcuts that you have in your app. It just works with everything that you've done, provided you follow the rules. And there are rules for how to develop accessible applications for Carbon, Cocoa, and Java. Every developer can do this, and the experience is basically that everybody can participate and use your product, all inclusive. John Geleynse Another reality on Mac OS X, and this is really cool stuff, is the multilingual capabilities.

The international technologies and Unicode support in Mac OS X enable you to ship an app that is deployable in dozens of languages. Mac OS X, out of the box, ships with, what, I don't know, 16 languages? Your app doesn't need to do anything extra. You don't need to license any extra fonts. You don't need to create any extra code for rendering these fancy characters, Japanese or Chinese or Hebrew or whatever language you want to display in.

It's just there, and it's for free, provided you adopt Unicode. Well, some of you might sit in the audience and say, well, it doesn't matter. I just ship in the UK, or I just ship in North America. Well, you know what? There's more and more schools, for example, that have students coming in from other countries who don't speak, in North America here, for example.

More and more students coming in who don't speak English, who have a foreign, you know, mother tongue, and they're coming into an English school. How cool would it be if the software they used, displayed an interface in their language, in their mother tongue, and the curriculum in English? Well, let me show you what that would look like.

It's a real quick demo, but this shows off just how a standard app that's currently available in Mac OS X can show multiple languages in a single document. So I'm just launching this RTF file. It's showing in TextEdit one document. No extra code in TextEdit to do this. It's just Unicode compliant. Your app can display all of these languages. It's all selectable text-- Thai, Greek, Hebrew, Arabic, Korean, Russian, Hindi. Hey, something happened there.

It worked last night. But anyway, you could select this stuff, drag and drop it to the desktop. It's just standard behaviors, and your app can do this. And I don't have time, but we could switch out TextEdit to the Finder, change its default language. It would launch in Japanese, and this content would display exactly the same. And I was just recently at NECC, which is the Education Computing Conference, or whatever, anyway. It was for educators.

And this really hit home for the developers there, the fact that they could deliver an app on 10 that could display curriculum in one language or multiple languages, and the interface of the application display in the native tongue of the student. So just because you're not necessarily sending your product to multiple countries, you might have users right at home who are multilingual, and your app can take advantage of that and deliver a great experience for them.

Another reality of Mac OS X is gorgeous graphics, right? Quartz 2D and OpenGL deliver some of the great stunning effects you saw in the keynote. And all of that's great and all of it's coming in tiger, but the truth is A lot of developers are nowhere near developing products that look like some of the stuff we showed in the keynote. The reality is a lot of developers that I've interfaced with and that my team have met with over the last couple of years are still struggling with this cross-platform thing.

And the problem with cross-platform, I mean, from a business point of view, I understand completely, and we're going to do everything to help you deploy on multiple platforms. But the struggle from a user experience point of view with cross-platform development is that you typically end up delivering a very sort of a lowest common denominator experience, whether it's through the visuals or the interaction or the quality of stuff on screen. It typically isn't optimized for the platform.

The great graphics on Mac OS X enable everything you see on screen, the transparency, the shadowing, the animations that are going on. All of that stuff now is going more and more through the OpenGL pipeline and onto the GPU. If your app isn't leveraging that stuff, you're not going to get that great experience.

And the truth is, if you take education, for example, in the education space, K through 12, students are are getting gorgeous graphics and surround sound and a fantastic multimedia experience on their game machines, Game Boy Advance, Xbox, right? And so they're having that experience at home and then they come to school and they're running with your product in the classroom and you're you know, on Quick Draw, or you're doing something cross-platform. So it's just, it just doesn't cut it.

And let me just show you, I don't have stunning, you know, rippling water kind of demos, but I want to show you three products that I think really demonstrate this well. So the first is, I just want to contrast Quick Draw with Quartz. Let me get rid of this.

And here on the left, we've got a fine product called Apple Works. And on the right, we've got a product called OmniGraffle. and OmniGraffle does diagrams and stuff. Anyway, the point is it draws with Quartz, Quartz 2D. And so I'm just going to zoom in on this stuff here and show you what's going on a little bit. So first of all, support for Unicode text. I don't know what this says in Japanese, and for the Japanese in the audience, I apologize if this is anything... Anyway, I just put some characters in there.

But this is the same text in Apple Works. Great Unicode support. So there's a problem there. Notice this. Let me zoom in even more here. Look at this gorgeous anti-aliased text, right? Look at the great smooth line here that's drawn, and the circle, fantastic, nice smooth edges, right? Knot.

And you contrast that with great anti-aliased text that displays beautifully at any rotation, any size, any effect you apply on it. Notice the circle is, sorry, didn't mean to make you seasick there. Notice the circle is transparent. This one is not. No transparency support in QuickDraw. It's free in quartz.

Gradient fills, a little bit more banded here in Quick Draw. This is a really pixelated graphics. This is a rotated JPEG. Quickdraw can't handle that very well at all. This is rotated in quarts. Now the picture itself is a little pixelated, so I apologize for that. I whipped this together and I'm not a graphics demoing guy. But the point is, these curves, the text, it's all great, and when you contrast that with Quickdraw, it just doesn't cut it.

So it's up to you, right? How are you going to differentiate your product? This is a great way to differentiate it by leveraging Quickdraw 2D. Another app that I want to show you is This application, it's Curvus Pro. If you think of on Mac OS 9, there was the graphing calculator.

Pretty cool app in its day, right? But totally quick draw based. This is Curvus Pro. It takes full advantage of Quartz, 2D, and OpenGL to do 3D models. Formulas, based upon formulas that I have no idea what they mean. This is stuff I failed in school, but nonetheless. You know, here's another one.

This is pretty cool stuff. And you know what? Because this app developer-- and this was submitted to the Apple Design Awards, by the way, and it was written by a student-- Because this developer used Quartz 2D, this stuff, they can print to PDF from an OpenGL context. How cool is that? Suddenly, that means that students can take this stuff, print it to PDF, send it off to somebody who doesn't even have the app, and say, Hey, teacher, look at, you know, the formula that I came up with last night, and is this right? And what about this? And, you know, whatever. They can distribute this through PDF, so I think that's pretty cool. And so using the right graphics technologies enables that.

And lastly, I want to show you the use of OpenGL. I think that really enhances the student's experience. This is a product called Starry Night, and I'm just going to go to... A dark time of day. And essentially what you've got here is you're in a field and there's some, you know, some stuff in the background, mountains and stuff.

And as you point to the night sky, any star, you're getting information about that star and stuff is moving along in real time. And so you see the night sky moving. This is a cool product, by the way, if you just want to go out in the backyard with your power book and your children and show them what's going on in the night sky. You can even turn on light distortion from the city lights.

Turn that on and it hides like a light. It's like most of the stars, but you can get at some of the brighter ones. Very cool stuff. Well, what you can do is using OpenGL here, I can just say go to, let's say, Neptune. So let's just say go there. And it takes us off from the earth. We go through the atmosphere. And hopefully this is going to work nicely.

I don't know if you can see, there are stars flying by. Might be a little bit difficult to see on screen here. I don't know, maybe it takes a long time to travel to Neptune. Here we go, here we go, here we go, here we go. Here's Neptune. Not a very exciting planet. I don't know why we're a little jerky all of a sudden, but let's go back to Earth.

We're heading towards the sun. And while that's running, let me just keep talking, and then we'll switch back to the slides in a moment there. But you know, for students, this is so compelling. This is so different than looking at a textbook. And you couldn't possibly do this kind of stuff in Quick Draw.

So taking full advantage of the graphics on Mac OS X are going to let you distinguish your application like crazy on the platform over your competitors. Okay, let's switch back to slides. I'm not sure. You know, the problem with demos is sometimes they run great, sometimes they don't. That's probably my fault.

Another reality on Mac OS X is stuff that you heard about in the keynote. It's the spotlight technology. This is certainly coming technology. It's not here today, but I think there are things you can do to start planning for this. You've seen the demos a couple times. I'm not going to go through that. There are some things you can do today to support it. There's support for standard stuff right out of the box, but if you've got custom proprietary file formats, you can begin to think about writing an importer for that.

You can start using the standard keys that exist in Spotlight, but then you can help work with us as we build a community around this technology, help us define some of the custom keys that we need to have for file types that we maybe didn't think about or for some workflows that are key in the market segment in which you participate. So more information on the community stuff that we're doing. So those are the fundamentals, and that's a lot of stuff. But you know what? When you bake bread, you cannot leave out the key ingredients.

If you create a great dinner party for people, there's some fundamentals that have to be there. You've got to have silverware on the table. You've got to have napkins. You've got to have a cup, right? If you leave some of that stuff out, the experience could go downhill pretty quickly. It's the same thing with software development. There's some fundamentals, I think, that are going to enable you to distinguish your app from the competition.

All right, designing for Aqua. Making things attractive and easy to use. This is all about the ambiance, right? First impressions, now I get this product going. Now how do I feel about it as I use it? Is it great to look at and compelling? Is our information organized well? And is the usability, is it good? And it's so important that it's almost like the real estate expression when you're selling a house or buying a house.

I forget which it is. I'm not a realtor. I'm a software. But it's all about location, location, location, right? You can sell pretty much anything if it's in the right location. And it's important. Location is important. Well, you know what? Adopting Aqua and creating a delivery. a really great user experience is that important.

There's lots of stuff you need to do, and we're gonna get into this specifically. First of all, age old design principles. And you think, oh yeah, I've heard this before. I read the human interface guidelines, you know, 10 years ago, 12 years ago. Well, you know what, this stuff is really important. We're still thinking about these things as we design Aqua. And you should be, as you design your application for the platform, you should be thinking about these principles. This stuff is not old.

It's true, as true today as it was when it was first, you know, thought up and presented. And I'll give an example. Feedback and communication, I think one of the key characteristics of Aqua today is the fact that it uses animation through sheets and drawers, the genie effect, and different types of animations through expose and stuff to communicate status to users. It takes us to a whole new level in terms of communicating status and giving feedback as to what's going on. That's a real characteristic of Aqua.

Modelessness. We've gone from being app modal for many dialogues to being document modal. That's a trend towards modelessness. We're less modal now within the application as a result of Sheets. So modelessness is a key goal for us within Mac OS X. Aesthetic integrity. Aqua is just gorgeous compared to what we had on Mac OS 9 or compared to anything else elsewhere, I think. The aesthetic integrity, the gorgeous, the beauty of Mac OS X, I think, just stands head and shoulders above everything else. And if your app can't fit into that world, it's going to stand out like a sore thumb.

And if you've been in my sessions before, I've showed lots of examples of how that's true. Now, designing a good interface requires that you follow those principles, but also think about getting organized. And by getting organized, I'm going to talk about something called the user's mental model or their conceptual model.

What I mean by that is that it's important, as you understand your markets and your users and what your feature is going to do and the solution it's going to provide to your users, it's important that you start to think about, now, what is the user's conceptual model or mental model as they approach the task that your software is providing? What are the concepts they're thinking about? What's the workflow that they're experiencing? What workflow have they experienced? What objects and object hierarchy exist in your product? What expectations is the user bringing to the table? These are big questions to ask. And a lot of developers that I've interacted with haven't even thought about this stuff.

They've kind of just, you know, their impression of what the software should do and they've put it together. And while it's compelling, it's not nearly as compelling and doesn't register, I think, with a lot of users. This is a really important concept to get down. Once you've figured out what that conceptual model is for 80% of your users, it's important to reflect that model through the menu organization and layout and organization of the main window, toolbars, utility windows, et cetera. We'll go through a couple of examples.

And when you design your product to reflect that conceptual model, it's important to keep these kind of five points in your mind as well. Make sure that there are affordances. If something doesn't look clickable, users won't necessarily know that it is. Design for simplicity. Keep simplicity in mind. Frequently accessed items should always be accessible. Some of the best software that I've ever used, just instantly the stuff I needed was right there when I needed it.

And some of the products that won the Apple Design Awards that you'll hear about tonight really reflect that concept well. Familiarity. People's mental model is based on their previous experience. We talked earlier about leveraging the existing UI that's delivered through some of the APIs in Mac OS X. Take advantage of that because it provides for a familiar experience for users.

Availability. It's a whole lot easier for people to see something on screen that they need to interact with than for them to recall some menu command that's two levels deep or some button in a dialog. So expose the features that are critical to users so that stuff is available. And provide good feedback to users, and we'll talk about that more specifically.

So, how does that apply in the real world in terms of the design that we've implemented for some software? Well, if you think of iTunes and consider the mental model or conceptual model that most users have as they approach this, they understand that it's a music management piece of software. It manages their music.

And so they have an understanding that there's going to be songs in there. There's going to be some way of organizing those songs. They probably have this idea that you could play the stuff, and then maybe they're searching. And so the UI is modeled completely around that. There's songs. It's a dominant part of the UI.

There's the collections where we organize the music into playlists, smart playlists, etc. There's the playback controls, right, very clearly on the interface. And lastly, there's the searching functionality. It's all there. So the UI reflects completely, or almost perfectly, the mental model that users have as they approach the task. And so users just get up and running with this product really fast. They just get it. That's what getting it means.

Next example. This is a product called Unison from Panic. These guys do great stuff. This is a product that totally revives the Usenet for Macintosh users. Now the Usenet's got lots of content, and we'll not talk about any of that specifically, but there's some good stuff out there. And the mental model that you approach Usenet with, if you know what it is, you understand what its hierarchy is.

There's groups and there's messages within groups, and messages contain pictures and other stuff. If you don't know what Usenet's structure is, Unison's product is so, Unison is so well designed in terms of the mental model that it basically communicates the model of the environment to you, the user, and so you get it right away.

And so here, basically Usenet is all about groups, and so the main groups window is structured in a way that you just kind of go through the browser view. And there's a menu that supports that key concept. And then within a message, we've got the four elements of message, files, images, music. And so there's a message menu that is part of this. So the UI really supports the model that exists.

Soft RAID, another great product in Mac OS X. If you're doing RAID stuff, you basically have a simple mental model, which is you've got physical devices, Which it calls "Discs." You've got logical volumes on those discs called-- You've got logical volumes called "Volumes." And there's a menu to support that, sorry. And then there's a utilities menu, which I don't highlight.

Sorry, I run through these slides again. There's a utilities menu, which basically is, you've got these hard disks, you've got these volumes, and then you do some utilitarian stuff to these drives or these volumes, and you format them, or you partition them, or what have you. And that's it, that's the UI. And yet it's a highly complex, highly functional product. It does a ton of stuff, but most of it is hidden behind the scenes for you, the user, because you don't need to be concerned with it.

Another great product, Bike Route. If you're a cyclist, this is a really cool product. It basically lets you download, take map formats, there's a certain map format out there, I can't remember the exact details, but there's maps out there about cycling, biking paths or routes that exist in the world. And you can load those maps into the product and then come up with custom bike trips. And you choose different nodes and then it's got this concept of a map but then a route.

And then within a route you've got the profile of that route, which is the altitudes you might cycle around and what the instructions are for following that custom thing. Anyway, the point is the UI totally supports this model that you come to, which is that I've got a map and it's got routes on it.

And so the route could just be between those two points, and there's a menu associated with that, and that's it. And so the mental model the user comes to this product with is supported by the UI, and the hierarchy of objects and such is set up in the main menu bar as well.

But it isn't always that easy. It's easy to get this wrong. Here's a great product, and this is in no way meant to belittle the product in any way, shape, or form. Mac Journal. It won an Apple Design Award years ago. I think this is a really cool product. But there's one little thing that I think is wrong. And that is that as I approach this product, and as most users approach the product, they have this concept of a journal, which is kind of the container object, right? And within a journal, you've got entries.

Well, the hierarchy of the main menu bar doesn't reflect that at all. In fact, if you think about app menu, document menu, right, file menu, edit, and then other stuff, which is where you kind of go parent object, child object, sub-child object, et cetera, that's the hierarchy you should be reflecting in the menu bar. That's not reflected here. So the journal, which is the parent container object, is actually further down the menu bar than the entry.

itself, because journals contain entries, entry is really in the place of the document. And I just -- personally, I think that's backwards. So the change, I would say, is just flip those around. They call -- the window is called the Journal Window. It's actually the document format, et cetera. And so I hope this drives home the point that the menu bar needs to reflect the hierarchy of your objects. Let's take another example. If you're a multimedia authoring application, you probably have your document format, which is your project.

Within projects, you've got a background. Well, you might have scenes. Scenes have backgrounds. Scenes also have layers. Layers have, you know, characters or objects. Objects have attributes. And so you could imagine the menu bar going, you know, app name, projects, edit, scenes, you know, characters, format, you know, for attributes, et cetera. And so your menu bar needs to reflect that hierarchy from parent down to the -- to the to the smallest child sort of container element.

And if you don't get the mental model right at all, basically you go back to what I was talking about earlier in the Knowing Your Application slide, which is you get just feature creep. Your product is all about features rather than a solution. Here's a product that is supposed to be a to-do list manager, but it's so laden with features and buttons in the toolbar, and I didn't even show the menu bar, I don't even know where to begin.

I don't know what the model is that this application works on. And so it becomes a problem. The feature, while it's a very, very capable product, and I'll just side note, I'm working with this developer to make this thing pretty cool, but I wanted to show an earlier instance of this window because it's just messed up, and you have no idea what you're supposed to do.

A to-do list manager product, to me, should be very lightweight, not in my face, be there when I need it, and then go away when I don't need it, and all that kind of stuff, and this app doesn't do that. I can't size the window beyond a certain small size, which basically takes up my whole screen, and there's too much stuff all over it. So, all right, another element of designing a great interface is providing great feedback and communication.

You know, this is, in my opinion, providing good feedback to your users is like the feedback and communication we need to have in good relationships in our life, whether it's to our bosses or our teammates or spouses or children or what have you. I think there's a great parallel that can be drawn there. And if you think about the feedback that you provide in your application, how you report errors or how you give status updates or communicate progress, it may not be so non-intrusive, non-interruptive.

John Geleynse You know, this is a must for anyone involved in developing a Mac OS X product. And if you think about the feedback that you provide in your application, how you report errors or how you give status updates or communicate progress, it may not be so non-intrusive, non-interruptive. John Geleynse You know, this is a must for anyone involved in developing a Mac OS X product. And if you think about the feedback that you provide in your application, how you report errors or how you give status updates or communicate progress, it may not be so non-intrusive, non-interruptive.

in your application. You want to figure out what are the reporting points? What are those milestones that the user really wants to know about? And then how do we effectively communicate the reaching of those milestones or the not reaching of those milestones? So only communicate status that matters. Use appropriate progress indication. So either an indeterminate bar or a determinate progress bar or the spinning gear thing.

And related to that, I think consistent placement of those little gauges or dials or whatever you're using to communicate status. It should be consistent placement. If you look at mail, the spinning gear is always in the same place. And users get accustomed to looking in that location for an update as to whether or not the machine is busy or the application is busy. Consistent placement of progress indicators. Another way of communicating feedback is through badging your dock icon. You can, like mail does, you can show the number of mail messages that are there. And other apps are doing some really cool stuff with their application icons.

And then providing users with useful error messages and disabling commands that don't apply in the current context. I want to zero in on these because I still see a lot of difficulty in this area. So it's important to report errors, but not this way. And this is out of a shipping app on the platform.

It's important to report errors, but always check spelling. So this says, in case you can't read at the back of the room, it says, aim error. Could not add mformic at mac.com, guy on my team, to your buddy list. Feedback error is zero. I'm not sure what a feedback error is.

It's important to report errors or report a situation that's occurred. It might not necessarily be an error, but it's something that's occurred that hinders you from proceeding further. Here's an app that I was playing with the other day, and it requires that you drag and drop an image onto each side, into these kind of giant image wells or whatever. And so I dragged an image in out of iPhoto, and that was great. And then I dragged another image, which happened to be oriented differently than the first.

The one was portrait, and the other one came in at landscape. And I didn't know. There was no indication in the UI that I couldn't do that. And so I did that, and I got this sheet came down, and it said, drag the image as a different size, extend or crop.

Well, I just dragged an image in here. I don't want to extend or crop it. And I'm not sure where distort came from, actually. At this point, I'm thinking, OK, but I can't cancel. So now what's going to happen? Now, in this case, it's not a big deal.

But you know what? If this was some crazy 3D rendering task that I just started and I couldn't cancel, I'd be screwed. Because this thing would go off for a period of time, and I'd be stuck because I couldn't stop the thing from processing, doing whatever it's doing. So I'm not sure what I'm supposed to do with this message. It doesn't communicate enough.

I don't know where distort came from. It's important to report problems effectively and provide users with useful error messages. I've talked about this every year, and I feel compelled to talk about it again. I apologize if you were here before. What happened is what you should say to the user, then tell them why it happened, and then tell them what they can do about it. What's the solution to the problem? Avoid yes and no buttons. There's a lot of ambiguity.

It's often very difficult to write a good error message and then have a yes or no button associated with it, because the user can't, well, we'll talk about why. There's that problem, and then there's the other problem, and that is that users tend to scan the error message, looking for kind of keywords, you know, that indicate the problem, and your button labels should kind of capture those keywords as the user scans that message to know which button to click. You know, there's something about preferences, and then there's a button that says open system preferences. So you just kind of go, whoop, hit the button. and boom, they're off to solving the problem.

And then, of course, you could prevent problems from occurring in the first place by just disabling menu commands or buttons that don't make any sense in the current context, but heaven forbid that that would happen sometimes. So here's a way of reporting an error, you know, error writing file to disk.

Well, it's a good sentence. It's a complete sentence. Everything is there that you need to have there to be good English, but it's a little, you know, it's not too outgoing. So a better report would be this one. The document cannot be saved because the disk is full. Okay, so now I know a little bit more about what's going on.

And I could probably, from this message, figure out what I need to do, which is if I want to save this document, I've got to go to the finder and get rid of something so I get a little bit more space on the drive. But a whole lot better would be to do something like this. And why is this better? Because, first of all, it communicates what happened. The document trip request could not be saved.

Why did it happen? Because the disk works stuff. Not only is the disk full, but it tells me which disk. A lot of us have partitioned drives, multiple hard drives, iDisk, etc. And now what do I do about it? Try deleting documents from that drive or saving the document on another disk.

That's a good error message. And I wish I would get this kind of stuff in all of the applications that I run on the platform. And it means a little bit of extra work on your part as a developer, as an engineer, because you've got to start looking at some of those error codes that are coming back from the APIs. And that's hard, but you know what? The end result is a great, great experience for customers.

And again, prevention is the key. Rather than display a dialogue or an alert that's like this, that says, "You must select at least one student "before printing the student attendance summary report," Disable the menu items. So I can't go up and say print student summary report if there's no student selected, right? It's easy. You can do this, and a lot of apps are doing it, and I hope to see this happening in 100% of the apps on the platform. So prevent the problem in the first place, then you don't have to look at the error messages and report the alerts.

All right, I've got a few minutes left. Use standard controls. If you're delivering software on the platform, it should look like software on the platform. So there's a ton of stuff in the system, whether it's AppKit or HIToolbox. And these are just some examples of the different sizes of controls.

Many controls were shipped last year. They're available in Panther today. They should be used not in your main dialog boxes, but they should be used in your utility windows. And don't mix and match control sizes within the same window, whether it's a main window or a dialog or utility window.

John Geleynse All right, laying things out. These examples are dialog boxes, but they could equally be main windows. And all of this is true for any window type that you're designing on screen. John Geleynse So there's a tendency in Aqua to center equalize, and I see people getting this wrong over and over, so that's why I feel compelled to talk about it for a moment. John Geleynse Center equalize doesn't mean that everything gets center aligned, you know, so that you've got kind of the centered effect on screen. This is a tab pane.

John Geleynse So you basically lay out your content according to the layout rules that are in the human interface guidelines that I'm going to touch on shortly, but then you take I draw a bounding box around all of it and then sort of center that box within the tab pane. And each tab pane might have different edges, sizes, but it all gets centered in there. Here's another example of where it's done. Notice if you drew, notice the orange box around the content, that box is centered within the dialogue, and then everything else is organized around that.

Here is another thing that needs to be done, and that is to right align all of your labels. If you're labeling groups or labeling radio buttons or what have you, those labels need to be right aligned along their colons. They also need to have colons behind them. Equally, you left align the controls in those sets.

And when you do that, it looks great, actually. Oops, my apologies. The last one was basically showing that within, under the size points there, that that stuff is indented, but it's left aligned with sort of the parent controls that it's under. This is all about providing appropriate spacing.

I still see stuff crammed onto dialog boxes and no margins, and, you know, it just, it doesn't feel like it's cleaned up nicely. And so there's appropriate margins that need to be there. There's standardized spacing for between items, between related items in groups that are there. There's a larger spacing between sort of less related groups.

And then there's a larger spacing between sort of distinct groups on screen. And you don't even necessarily need the line, the horizontal line that's on that screen. Action buttons go in the lower right, nowhere else, lower right. And the OK button is on the right side, and it's OK, O-K, not okie dokie or OKAY or different variants of that, which I've seen. This is really something I see, and if you get it right, it's great.

It produces a really great design. But start your labels and check boxes and radio buttons with verbs so that all the user really needs to scan at a just glance, and they know that if dither is off, it means it's not dithered, right? So it's really easy to figure out what the check box or the radio button really represents.

And there's a ton more I could talk about, but I'm already down to like five minutes left in the session. But things like quality icons and, you know, quality rendered icons and well-organized toolbars, you know, not populating your toolbars with hundreds of icons, or even 30 or 15 is too many in many cases.

You know, we can't get into that. File name extension support, always display, use the display name for the document. If the user didn't name it with an extension, they don't want to see the extension in their document window title. Quality graphics, all of the graphics that you draw on screen, whether it's static images or anything else should be drawn with quartz, or at least if it's a static image should be drawn by a graphic artist, a visual designer.

And reserved keyboard shortcuts. Please honor the reserved keyboard shortcuts that are... identified in the human interface guidelines. So, that's the fourth thing you can do, the fourth area that you can focus on to create a product that's distinguished from the competition. And the last area is really about delivering quality service.

Right? There's no bigger turn off than going to a great restaurant and getting really crappy service. And I think when it comes down to applications, the analogy I'll draw is performance. And you're going to get a lot of content on this at other sessions. If you hadn't thought about this material before, you need to think about this stuff, because it makes a difference.

And I think when it comes down to applications, the analogy I'll draw is performance. And you're going to get a lot of content on this at other sessions. If you hadn't thought about this material before, you need to think about this stuff, because it makes a difference. Because it makes a difference. It's a big difference.

Performance is measured in two ways. I think when you talk to users about performance, they think about either number crunching, just raw data processing. How fast does the app blur an image or do whatever transform it's doing or whatever data processing it's doing. And other users think of performance as kind of productivity and interaction responsiveness.

All of those things can be tuned on Mac OS X using a ton of tools that are available. But really it comes down to you need to build into your development cycle time to do the analysis using those tools. Your engineers or you the engineers need to be using these tools because the results are dramatic. In developer relations, we hold workshops.

If you've been to one, you know what the outcome is. But if you don't know about them, there are workshops that are held at Apple. And we run developers through these programs for two days or three days or four days. And we teach them these tools. And at the end of three or four days, we see dramatic, dramatic increases in the productivity or the performance of products.

Just by running these tools and identifying bottlenecks in your code, identifying where you could optimize for velocity engine, identifying older APIs that you shouldn't be using. There are more modern versions and that type thing. If you're a Carbon app, There's a bunch of things you can do today. And the reason I bring up Carbon Apps specifically is it's the Carbon developers, in many cases, who need to spend a little bit more time on these kind of things.

There's a lot of stuff you can do if you're a Carbon App today on the platform to optimize for Mac OS X. Certainly, Cocoa developers can optimize, too. I'm not saying that. But be lazy. Don't start up your app and initialize every single buffer that your app's ever going to use that the user's going to potentially run into.

Don't load all the movies and get all the files ready to go so that when the user clicks some feature, it happens instantly. Be lazy. Do all that stuff when the user does it, because it makes startup times really slow. Reduce your memory footprint. All this stuff. Maco binary format, pre-bind, thread. There's a great session on threading this week by Xavier Legro on my team. Really, really good stuff. There's good content here at the conference for making your apps totally, totally fast on the platform.

So that's high performance, great service, deliver great service. And so in the end, There are five areas you could focus on, and I think if you did these, you'd deliver great applications on the platform. And the pushback we get from developers as I meet with them often is, yeah, but you know what? At the end of the day, you guys have really small market share, and so it's really hard to get this done.

Why would we do this stuff? Why would we go the extra mile for the platform? And I always counter with the fact that, well, whatever the current stat is, but Steve released, the current stat that Steve released yesterday in the keynote is that there are 12 million Mac OS X users today. Sure, there could be 200 million.

But there are 12 million users today. How many of you would like to have even half of those as your customers? How many of you would like even a quarter of those to have a copy of your product and run that product? Right? The reality is there are lots of users out there on Mac OS X who are not running your product, and they're probably not running it either because they're not aware of it or because they've run it and they had a poor user experience or what have you. There's a variety of reasons, but there's a lot you can do to elevate your profile in the Macintosh community. And partnering with Apple and doing stuff through developer relations, we can help raise that exposure.

Make sure your product is listed in the Mac Products Guide. Make sure you're posting on the right websites. Make sure your app is optimized for the platform and is designed in a way that distinguishes itself from every other application. Think of the apps that you found out about just by reading a review about them that were totally awesome on the platform. Why are they totally awesome? Because they leveraged Quartz.

They were optimized for the platform. They have gorgeous UI. They've done everything right or most things right. And I would encourage you to look at these five areas and a lot of other areas that are covered in the conference and deliver this stuff, and you're going to have a really, really great, you're going to have a really great, I think you're going to get more customers and your business is going to go up.

So lots of documentation available for you on the DVD, I believe. And if it's not on the DVD, it's certainly available on the developer website or on the disk image that's downloadable off of connect.apple.com for this session. Great document is Apple Software Design Guidelines. Check it out and the Human Interface Guidelines.

And then tonight, come celebrate here with the developers who did a lot of this stuff and really produced great products because we're going to highlight them on stage, give them an award, give them a PowerBook or a G5 and a cinema display as a recognition of the great software and the great work that they've done. So thank you for being here. I hope this was valuable for you, and I look forward to your feedback, and I hope you have a great conference this week.