Well, welcome to session one. It's not the first session of the day, but it's number one. We're going to have a lot of fun here. We've got a lot of stuff to cover, and I hope that you learned something really valuable from this in terms of how to create a really complete user experience for your application on Mac OS X.

So I want to begin by sort of defining what the focus is for this session. I want the focus to be primarily on best practices. So we're going to talk about what are the best practices for you as you bring your application to Mac OS X to deliver a complete user experience. And more specifically, what are the actions that you need to start to employ as a developer in the process of developing your product to deliver qualities in a product that are desirable? So everything that we talk about really is about best practices.

And the areas I want to focus on are areas that I see developers having difficulty with. So I want to help clarify some of the issues in these areas and give you some guidance on delivering a great user experience in these areas. And the first is simplifying product installs. The second is leveraging some of the technologies that are in Mac OS X for common tasks to present a really consistent user experience in your application.

Third thing we'll talk about is how do you make your application more Aqua compliant? And I'm going to give you some very specific tips and tricks for doing that. And then the fourth area we'll talk about is cross-platform design issues that people are running into, and I want to give you some guidance there. All right, let's begin with installation.

You know, from the moment a user, a customer, purchases your product, they're dealing, you know, the first thing they deal with is a package. Now, in some cases where it's software downloads or electronic distribution, you're dealing with an electronic package, right? A disk image or whatever. But much software, lots of software is delivered through retail stores and through, you know, traditional shopping venues.

And so there's a physical package there. And the user experience for me in many products, although it's a very small part of the product user experience, right? But there's nothing more discouraging than buying a product, paying $129 or whatever the price is, and then fighting with the box or the packaging to get the software out of there.

I don't know how many times I've opened software that developers have sent me for review or that I've, you know, had to look at for the Apple Design Awards or whatever. And I'm struggling with this box and the CDs fly all over the place when I finally figure out how to open the plastic, you know, insert or whatever it is. And so I want to encourage you, first of all, make your packaging easy to open.

Secondly, make it attractive on the store shelf. Thirdly, clearly indicate the system requirements. There's nothing more frustrating, I think, for users to go to the store, look for software for their new computer or for their older Macintosh and not be clear, you know, for it to not be clear for them to know which product runs on their machine. So make sure that your box clearly communicates what system requirements are there, are required.

And also don't try to grow your market by basically going, "Well, I'm going to buy this and I'm going to buy that." And then you're going to have to go through the process of getting the product out of there. "Well, I think it'll run on every Macintosh." If it doesn't run on some of the lower end Macintoshes, make sure that that's clearly defined and that you indicate sort of what the best or recommended system requirements are.

Believe it or not, there are products out there that are not clearly communicating these things. And last thing is, ensure that users have everything they need to get started. What think about, you know your users, what is it that they need to have when they open the box to get the product going? In many cases, not much.

But in many other cases, what I'm seeing is I open a package and I don't get a lot of instructions on how to get going with the product, but I get a lot of marketing. I get coupons for this, that, and the other thing from third parties. And I, personally, I find that annoying, but, you know, think about what your users want, and I would recommend that that's something you might want to avoid.

All right, software distribution. So we talked about physical packaging, but there's electronic packaging, right? And in many cases, that's how you distribute software over the internet. And software distribution should be done on Mac OS X using an internet-enabled disk image. They are self-cleaning. They do the right thing with Safari. Safari downloads them, mounts them on the desktop, and takes care of everything for the user. So a lot of the hassles with downloading stuff off the internet and then having to figure out which uncompressed file I need to deal with next is taken away with internet-enabled disk images.

Talking about software downloads, there are two areas where you can do best practices or apply best practices. And that relates to avoid compressing the compressed. Right? How many of you have experienced this? You're downloading a piece of software, and you pull something off the internet, and it's a compressed file, and you open that up, and there's another compressed file within it. And even beyond that, I've seen just the other day, someone showed me a great example of where it's just senseless, multi-step, step like that, where you've got compressed files within compressed files within compressed files.

And in fact, I went to a very high-profile printing manufacturer recently to download a device driver for the printer, or a driver for the printer that I'd just gotten. And the user experience sort of went downhill from the get-go. I found the driver okay, and that was great, so the web design for the developer was fine.

But as I started to, as I found the driver and downloaded it, the driver name of the file that I was downloading had nothing to do with the printer model that I was hoping to download it for. So that was a great experience. So that was the first thing. It was like, I wasn't even sure I was downloading the right file. The next thing that came was a binhex file.

And so I opened that up, and then I got a self-extracting archive on that. So I, you know, self-extracted that. I got a disk image. Right? I opened the disk image. Now there's a package, which is okay, but after three or four steps like this. And so I ran the installer, and I had to authenticate. That's okay. I understand authentication is a part in some cases. But, you know, through the whole process, and then I had to register, and then I had to stick a dongle on there.

No, I didn't have to stick a dongle on it, but that was the case. And another product that I just thought I'd throw it on here. But you get the point, right? Make sure that from the get-go, the experience is great for your users. A lot of people think about user interface design in terms of the controls that they put on screen and the workflow for the user once the app is up and running. But I think there's a lot that goes on before that that is equally important.

All right, so we've got the software now, whether it's out of a package or it's, you know, software distributed or downloaded. And now we're into the installation process. And, you know, the guidance I would have for you is make this as painless as possible, right? Allow users to decide the install location.

I don't want my installer to decide where the install location goes, where the install location is. I want to be able to decide that for myself, particularly in the case of applications. In some other cases where you're putting a driver in a certain place in the system, it's different.

But I'm talking about application software. Make sure that the user can decide where it goes. Avoid unnecessary authentication. Don't just require the user to authenticate just for the fun of it. Okay? Only ask for authentication if you're installing outside of the current logged in user's domain. And lastly, avoid custom installers.

The best way to go with installation for an application on Mac OS X, out of the box, if possible, if authentication is required, is a drag install. Drag install enables you to put a background image on the folder and communicate some things to your users about what they can do with this, where it needs to go, if there is some specific location it needs to go. You can do some branding there. It's very straightforward. And it takes advantage of a technology in Mac OS X called bundling. If you're not familiar with bundling, check out the system overview documentation.

But bundling basically allows you to take all of the magic and, you know, required files from your application that the user will never interact with, stick them inside of a folder, and then set a bit for the finder so that folder is treated as a single icon and a single entity. And from the user's point of view, it's great because all of the complexity of your application is hidden for them.

Use an installer if you have to. If DragonStall doesn't cut it, use an installer, but not a custom one. Here we've got one that completely is non-standard for Aqua. It doesn't look anything like Aqua. In fact, instead, opt for the Mac OS X installer, which ships as part of every Mac OS X system, and you can use PackageMaker to build up the packages that you require to be installed.

All right, so now we've got the software installed. Well, what next, right? Well, there's always a setup and configuration step, which is at times extremely painful. I've bought a product. I'm your user. I bought the product, and I've installed this thing, and I've got it on my system. There's nothing more annoying than being forced to deal with unnecessary configuration.

And we'll talk a little bit more about some other technologies that are available on Mac OS X that enable you to simplify that setup process. But if there's anything you can do to make the installation more straightforward, please do that. Only ask the user for help when necessary. Don't bother the user with questions that aren't required at that time. Many users purchase something quickly. They need it to insert into a workflow or get something done, and they don't want to be dealing with configuration. Get users up and running quickly. quickly.

So for the installation here, the best practices for installation are focus on excellence in packaging, provide system requirements where possible, or always, sorry. Make sure the package is easy to open, make sure it's attractive so that you can steal sales away from the competition, all those kind of things. Provide simple, straightforward installations, and get your users up and running. That's the key, I think, with installation.

All right, interaction. So user interface design, the science of human computer action, kind of breaks down into two disciplines. First discipline is interaction design. It's all about workflow. It's all about how many clicks does it take to accomplish a particular action or task inside of a product. The second area of discipline is visual design, the aesthetics of something on screen.

So let's talk about interaction first of all. And in this section, I want to talk about some technologies that you should think about adopting in your Mac OS X product to facilitate or make more consistent, deliver consistent user experience for a lot of the common tasks that your users will be faced with.

First is you're hearing a recurring theme, I think, today. Address Book Framework. It's a great technology built into Mac OS X that basically provides system-wide contact management. If your application deals with anything like phone numbers, email addresses, fax numbers, addresses, people names, whatever, whatever information is associated with a contact, it should be built upon the Address Book Framework. Address Book, the application, is just a client of the framework. Your application, too, can be just like Address Book, the application, and can take advantage of the Address Book database.

Tied in with Adder's Book Framework is the People Picker. We've talked about this. I'm not going to review all the Mac OS X State of the Union material, by the way, but I just want to touch on a few of these technologies. If we're talking about Adder's Book Framework, the People Picker is now available to Carbon and Cocoa, and it enables your application to provide a very consistent UI. Basically, it's the system that provides the UI for users to pick the contacts that your application is dealing with, or that they need to deal with.

While we're on the topic of pickers, there's the font picker as well. If your app allows users to choose fonts or glyph characteristics, let them choose it through the font picker. Don't roll your own UI around this functionality. And then the color picker, same thing. If your application provides for the ability to pick colors, this is where you need to go.

This is where users need to go. And the advantage of using these technologies for your users is that users get familiar with doing this in one application, and they automatically can take that experience and leverage it inside of your application, because it's just the same. All right, Search Kit.

Great technology to build your application upon if you're doing anything related to searching, retrieving, or summarizing documents. There's a session later on this week related to Search Kit in detail about how to take advantage of this engine, this core engine, and something you should think about putting into your application in terms of doing searching for stuff. And we provide the UI on this. Or actually, no, sorry. This is where we use it in the system. You saw these slides in the MacWisdom State of the Union. Address Book, iCal.

Findr, FontBook. So we're using it all over the place, and you can too, because we give you the UI for this. The rounded search field is being introduced with Panther. It's only for searching. Continue using the square rectangular search edit field for all other standard tech stuff. And then the drop-down menu off of this allows you to specify the scope for your search.

All right, Apple Help, another technology that you can leverage to deliver a really consistent experience for reviewing online documentation. The cool thing about Help, and we'll talk about this more again later on this week, the cool thing about Help is that it's built on WebKit, so there's tremendous performance improvements this year in Panther. And Apple Help allows you to put your Help content on remote servers.

So even though your development may have finished and you've gone up to production of your CDs, your Help teams can continue to finalize the Help content and store it on remote servers that users will actually access automatically once they start running your Help through Help Viewer. So Apple Help is for user assistance.

Rendezvous, we were talking about setup, right? Setup and configuration are critical that they be as simplified as much as possible. Rendezvous is one of those technologies that we've talked about a fair bit today and last year as well, but this technology enables you to auto-configure, and it's a really cool technology. You can detect IP devices that are out there that might work with your product.

So leverage Rendezvous to... To take your users, take away from the users the need to type in an IP address. If your application today requires users to type in IP addresses to get up and running, then you should seriously be looking at a rendezvous and figuring out how that can help you get away from forcing users to do that.

Universal Access. Building on the accessibility APIs that are built into Mac OS X, using standard system controls, you can deliver your product and deliver a very consistent user experience to users who are in many ways disabled, or in a variety of ways disabled. So it'll also help your product be Section 508 compliant.

And lastly, Mac OS X provides a lot of international technologies. Your application should be Unicode-based so that all customers in worldwide markets can take advantage of the functionality that your product provides. All right, so we're still on the topic of interaction, which is the workflow of the application. And there's a critical component to this part of the design of your product that often is overlooked, and that is feedback and communication. How do you convey information back to your users? Well, this is not the way to do it. Right? It's important to report errors, but it's really critical that if you do report an error that you say something useful to the user.

Here's a sample alert dialog from an application on Mac OS X. Great application, actually. And thank you to the developer who brought it to the platform. But in this particular case, I want to use this as an example to point out some of the errors that I see other developers making as well. So here we've got a standard dialog that talks about an error condition and basically asks two questions.

Do you want to import the structure? Yes. And then the Yes button is Yes, Continue. So at least it should have been Yes, Import. Or do you want to display the text "No"? "No, cancel"? Is it "No, display the text" or "No, cancel"? I don't know. I'm confused.

Better way to do this, oh, not to mention the fact that there's a wrong icon. So when you're doing alerts in your application, make sure to use standard alert calls to deliver a consistent appearance for your alerts. If you are doing them manually, the alerts manually, make sure that the icon that's displayed is your application icon. And only in the case where there's destructive, you know, some destruction of data that's going to occur, do you want to badge it with a caution icon, which is the small yield sign.

Alright, so the right way to report errors is basically through this example from the finder. So what's right about this? Well, first of all, a good error message has three components. First of all, what happened? In this case, the iDisk cannot be accessed. The second element is, why did it happen? Well, it's because the user didn't have a .Mac member name and password in system preferences.

Okay, so there was an error. What happened? Why did it happen? And the third component is, what can the user do about it? And that's typically in the smaller text, and then directly associated with the button that the user would pick to actually solve the problem. So three important parts to an error message. What happened? Why did it happen? What can the user do about it? And finally, notice the application icon that showed up in this case.

All right, and finally, on the topic of interaction, I just want to leave a few tips of things that I pass on to a lot of developers as I meet with them and review their products. First of all, I think it's critical that no matter what audience you're focused at, whether it's an enterprise professional, enterprise IT person, whether it's a consumer-level iMac user, sort of entry-level iMac user, it doesn't matter what your audience is, it's important that your product delivers solutions and not just be a container for features.

What's great about iPhoto and iTunes and iMovie, et cetera? It's not so much that they're full-featured applications and they do everything that every user would possibly want in every market segment. It's that what they do, they do extremely well, and they typically do the things that most people want to do.

Your application can be the same. It doesn't have to do everything necessarily, but what it does, it needs to do very, very well. And that's all about interaction design. It needs to lead the user through the task at hand. And these are hard problems to solve. It's important that you know your user. Many developers are seeking as big a market share as possible and are trying to aim, pluck a feature from here for these users and stick in another feature over here for this crowd.

We've got a sales opportunity over here, so let's throw in this and that and the other feature. And the problem is that at the end of that, you get product bloat. And really, in many cases, there's nobody that's overseeing the overall user experience of that product. How do all those features operate together? How is the data viewed and interacted with? And these are difficult things to solve, but it's something that needs to be done.

So make sure that you know your user. Target your products at a very specific market. That way, you can tune the product to that market's needs and that market's workflow. Know your application. Understand exactly what your application was designed to do and don't cobble on extra features for a particular market segment that really don't match what your application is capable of doing.

Avoid crowding toolbars. Toolbars in Mac OS X, you'll see in the Finder, for example, have-- there are shortcuts to things like applications, home, you know, documents, this sort of thing. And those are quick shortcuts to things that are multiple clicks away. Your toolbar should really be shortcuts to functionality in your application that your users might want.

Provide things in toolbars that enable users to get at-- to sort of make visible things in your toolbars that users might not necessarily discover, but that once they do use it, solve a lot of-- save a lot of time for them. Don't put things in toolbars that have keyboard shortcuts already associated with them. You're going to overcrowd your toolbars.

And it's a lot easier for a user to learn a keyboard shortcut, in many cases, and they already know many of them, than to populate-- you know, create an icon for that that's yet different from another icon for Save, for example, or New from any other application. So New, Open, Save, Print, Cut, Copy, Paste, all of those things that have standard standard keyboard shortcuts, they don't need icons and menu bars.

And then in the process of developing, simplify your product, work out the best UI you believe is required, and then simplify again. It's a difficult thing to do, but focus on your users. Know your users, know what your application can do, and aim towards that. All right, so best practices for interaction.

Leverage relevant technologies. Just went through a kind of a laundry list of some relevant technologies for some of your applications, but choose the best technologies for the customers you're going after and based upon what your application does. Take advantage of what's already in the system to deliver a consistent user experience for common tasks that users are going to be faced across a multitude of applications. What they know from one application, they can then apply to yours. report errors properly, and deliver solutions, not just features.

All right, so I said that human and computer interaction is kind of-- or user interface design is broken into sort of two disciplines, right? Interaction design, visual design. And I'd like to take some time now to talk about the tips and tricks for delivering a really great layout or delivering great Aqua compliance in your application.

So it's critical that your application focus on clean design. As you work out the UI and the appearance of your product on screen, it's highly important that you focus on cleanliness and space and room so that people can find what they're looking for. A cluttered interface is very hard to navigate. It's hard to find what I'm looking for when stuff isn't related or it's not grouped or it's laid out poorly. Rather, take something like this.

And when you apply the layout guidelines, you get something that's a lot cleaner and much more appealing to look at. And if you do this kind of exercise across your whole application, the effect is dramatic. You don't need to add a single feature to your product, but just clean up the UI if it's already on Mac OS X, and you'll have a brand new product. So, let's talk about how to do that. And to do that, I want to take an example dialogue, let's call it our patient, and we're going to go through the process of operating on this patient to provide a facelift. And we're going to end up with this.

So we're going to go from what's on the left, we're going to transition to the right. I want to talk through the exact steps that we went through to get that from the start to finish. First of all, button placement. I see this over and over and over, a violation of this most basic Macintosh UI guideline. Action buttons go in the bottom right corner.

They're spaced by a specific amount of spacing, and if you don't get that exactly right, that's okay, but it's important that they're, that the cancels to the left of the right of the okay button, I'm sorry. It's important that the OK button is OK, capital O, capital K, not OK, or hunky-dory, or, you know, something like that.

I'm going to use orange in the next series of slides to highlight areas that are white space or that are focal point for the slide. So here, we're using white space to delineate, to create natural dividers between the different groupings on the dialog. So we don't need lines. We don't need hard physical lines. We can just use white space to accomplish that.

It's important to group related items. Now, in the dialogue that we saw earlier, in our patient dialogue, there was group boxes that were used. And in Mac OS X, I'll talk about group boxes in Panther, but group boxes are great for grouping things together, but in many cases, it's not necessary to use a group box, per se. Mac OS X, or in Aqua, we introduced this idea that you take a group box and eliminate the sides and the bottom, and you could just use the top of the group box to group things together.

So here, we're doing that. Basically, we got rid of the group box completely. What that does is it just kind of lightens the UI. And in many cases, white space as a divider is perfectly sufficient for creating, you know, putting together what we want. If you're going to do that single top divider, which is the group title and then the single horizontal line, make sure that the horizontal line is aligned with the baseline of the group label.

So, Mac OS X provides for the ability to group related items by using white space or the grouping title and line. But also, in Panther, we've introduced the group box. And the group box is not something that we've, you know, the issue we had with the group box historically was that it was these hard black lines around the edge. And until we solved that appearance issue, we really weren't pushing group boxes. So, if you want to continue using group boxes, go right ahead. They're available in Panther, but they now have an etched in appearance and have a much, much finer appearance than Mac OS X Panther.

All right, well, how do you deal with alignment of objects on screen? Well, there are some basic tips that will roll into the human interface guidelines, but that I want to talk to you about today. The first thing to remember is, in a dialog box, for example, or whether it's a modalist dialog or whether it's a sheet, in any window that's got labels alongside of controls, make sure that you right-align the labels along the colons, if they're stacked vertically, for example. The next thing is you want to left align all of the controls that are labeled by those labels.

And then in most cases where you have a bunch of stacked objects, where you've got controls that are labeled and they're stacked on top of each other, it's sufficient and it looks good to extend all of those controls to be the same width. Now, that's not always the case, and it's very difficult to roll out very hard and fast guidelines for some of this stuff. In this particular case, there are some pop-up menus here that may have, in the case where they were numeric maybe, there would be a specific length to that number that could be put in there.

And it wouldn't make sense for that pop-up menu to be really wide. So moving the pop-up menu itself to be shorter would be fine. But what provides a very cluttered appearance is when the width of controls and a bunch of stacked items are kind of going in and out and in and out and in and out. It actually looks a lot better when stuff is aligned equally on each side.

Okay, there's another question that comes up, and that is, well, okay, if I've got a group of radio buttons, for example, that have child objects, you know, when I enable or disable one of the radio buttons, the child elements enable or disable. At least that's the way it's supposed to work if options aren't available to users.

The question is, how do you align the items that are children items? And wherever possible, continue that alignment of colons for all the labels across the dialog, and make sure that the label of the child object doesn't extend to the left beyond the edge, sort of the, you know, the edge of the left of the parent label. Do you understand? So the diagram there, tried to diagram this, and hopefully that communicates what we want here.

There's this other concept in Aqua which was misunderstood when we first introduced Aqua, and that was this idea that people thought everything in Aqua was centered. Well, that's clearly not the case. What it is is that things are center-equalized. So within a panel, within a system prep pane, or within a dialog box, or a sheet, or a tab pane, take all of the contents of that tab pane, follow the guidelines we just talked about, aligning labels and aligning objects and all that sort of stuff, and then create sort of an invisible box around it and center all of that stuff inside of the pane itself.

So in this particular example, you've got the center line going down the center of the object, and then the dotted line is kind of the frame, the invisible frame that's there. Here's another example that's not related to our current patient, but just another dialogue that I showed earlier, which shows the same idea, right? You've got the content of this pane centered within the area of the dialogue box.

Okay, so what a transformation. I mean, some basic things, white space, alignment of objects, some symmetry introduced, and there's a major transition, transformation that takes place. And if you can do this to all of the dialog boxes or interface elements in your application, the app will look really, really great.

Another thing that I see as I work with developers to help them create applications that look better on Mac OS X, easier to use, et cetera, is just poor use of labels. Labels tend to be replicated across a dialog box, or there's lots of redundancy in the text on a dialog.

And one great exercise once you're in the development cycle at some point is to get a technical writer from your company or get somebody who's good with the language that you're shipping your product in to look at the UI and make sure that the labels aren't highly repetitive and that you're not overusing certain words again and again and again. Here's a case where we've got a dialog box from a product shipping on Mac OS X where the word argument or arg is used like eight or nine times.

Anytime you see a word used over and over and over in a button label, for example, the question you should ask yourself is, well, wait a second, are those, if they all relate to the same object, and I need to put the object name in the button, then maybe they're not closely, you know, positioned, they're not close enough, they're not positioned close enough to the object or whatever it is that they affect.

Another thing that I see a lot is repeating menu items. New layer, delete layer, you know, print layer, save layer, whatever layer. And sometimes those repeating items aren't in a menu called layer. If they've got enough of them, they could actually move maybe into a menu called layer, and then you could just have new, print, save, or whatever. I mean, those aren't necessarily things you do with a layer, but you get my point.

If there's repeating objects, think about whether the UI is communicating enough about what those objects or those buttons do. And you can often eliminate a lot of this redundancy and repetition. So another problem here is that the title of the window is not very useful. The argv wizard dialog.

There's room on this dialog box for, it's actually an assistant, supposed to help me through the process of setting up something that the software's going to do, but the difficulty here is that there's an area for help text, but there's no helpful text there. It's basically just yet another repetition of the same thing.

I need to, you know, you the user need to put in an argument or something below. If you're going to provide help text, make sure that it's helpful. So if we clean this thing up and apply the same guidelines we talked about previously, we get something that's quite substantially changed.

So we've got better, we've removed the duplication on labels. Just got new edit and remove. We've got a better title on the window. Now, you know, the better title means something in the context of what this application does, but make sure that the titles of your dialog boxes have meaning in the context of your application. And just let me diverge for a minute and, and, uh, Go down a small side road here.

One of the most, the first guidelines we ever published on the Macintosh back in, you know, the first days, and it's still true today, is the fact that the title of a dialog box should be the same text as the menu item text that brings that dialog box up.

So if there's a menu item that says preferences, dot, dot, dot, it should bring up a preferences dialog, a dialog that's titled preferences. It shouldn't bring up something else that says, you know, application setup configuration options. Helpful text, you can't read it. Buttons at the bottom, the navigation, standard navigation, forward, back buttons, et cetera.

All right, and in the chapter of visual design, there is always the topic of using standard controls and appearance. And why this is critical is because, as you saw in the Mac Weston State of the Union, right, Scott Forstall showed you how we've been tuning Aqua. And we're going to continue to do that from one revision to the next.

If you're using standard system controls, you're going to pick up those changes automatically with no extra effort on your part. If you're rolling your own, it means every time you've got to get back in sync with what we're doing. If you can even simulate some of the things that we might do. So it's important to use standard system controls for that reason. The other reason is you get things for free, like screen readers just work if it's a standard system control. And a variety of other benefits.

So let's talk about using system controls and appearance. You saw that with Panther, we've rolled out three different types of controls, or three different sizes now. And this is based on developer feedback, primarily for high-end CAD CAM products. And 3D modeling tools that have got a ton of UI, and they want to fit it into a very small amount of space on screen. We introduced many controls. Be careful how you use these.

What we don't want to see is standard dialogs and standard sheets within your application using mini-controls. If something is modal, like a standard modal dialog or a sheet, where the user is focused on what's going on in that sheet, there's no reason to use small controls or mini-controls. A standard-sized control is perfectly acceptable because it doesn't matter how big that sheet or dialog box is, because the user is focused on what they're doing there. It's a message I've given over and over at WWDC.

Don't mix the sizes of controls. Don't use small text with big controls or big controls with small text, etc. Match everything. But the mini-control is pretty exciting, I think, for some up-and-coming applications. And so, as you saw before, you can take a palette, on-screen, utility window that your application might use. When you use the mini-controls, you get something that's significantly smaller, which is really great. And the difference in size is there.

See, the problem with not using system controls in appearance is not only, you know, do you not get things for free, but you basically look like a freak in some cases. Here's an application shipping on 10 today that just is totally non-standard. What's wrong with it? Well, let's see, non-standard labels. Why the blue background? I mean, if you really want to emphasize the labels, maybe bold it. But even in that case, I would hesitate to do that.

Non-standard display font, Geneva 9 being used across the board here. Lucida Grande is the display font by default on Mac OS X that you should be using. It's antialiased, looks great, different sizes. What else is wrong? Well, non-standard list backgrounds. Lists on Mac OS X, scrolling areas of text have a white background. They don't have the corduroy pinstriping.

"Misplaced buttons. They're misplaced in the context of how this application works, and I don't want to take the time to speak to exactly how the app works, but suffice it to say it's an accounting product that I have to set up my chart of accounts, and then I've got to put in user passwords and access to different menu items, and I have to go through this tremendous, highly complex configuration setup process to get this thing even up and running, and it's just crazy." On the topic of system controls and appearance, there's one more thing. What about metal? All right. So here's the finder, new finder, right? iTunes, iCal, Address Book, Mail.

Mail's not metal anymore. Why not? Well, the guidelines are as follows. Metal is to be used with care. It is absolutely for digital lifestyle, digital hub-related applications, so iTunes for the MP3 players, iPhoto for digital cameras, iMovie for video cameras. Anything fitting into the digital hub can be metal. If your application fits in the digital hub, it can be metal. actually is metal because it links to a cell phone.

Material, it's a heavy enough material that when you've got playlist-type functionality, it enables you to visually separate these related lists of content. And you'll see, as you mock up your own applications, notice that the playlist applications that Apple has are using Metal, and there's very good reason there. Hopefully you'll also notice as you install Panther that there's a lot more consistency in terms of how we're using Metal. Mail is no longer Metal. Mail is a real standard Aqua application.

For example, so layout and appearance, what are the best practices for this area of the design of your product? Focus on clean design. It really matters. From the get-go, when I open the package and start running the piece of software, now I'm, you know, I mean, this is my job, so I look at this kind of stuff, but products that are messy, that have a cluttered UI, and that are poorly designed visually, make me feel like the code quality is of equal, like the code is of equal quality.

Don't get your code judged based on the appearance of the application. It's like anything in our world, right? We buy anything, and if it looks crummy or it, you know, doesn't look high quality, then we start to wonder whether the product actually does what the vendor is claiming it does. Follow the Aqua layout guidelines. We don't publish these numbers for nothing. We've thought long and hard about these things. Use Interface Builder, and if you're not nib-based yet, you should start making that transition to being nib-based. Nibs are the files that interface builder produces.

If you're not nib-based and want to continue doing what you're currently doing, then at least switch into Interface Builder to design the UI and then take out the numbers from there. But my recommendation would be switch to Interface Builder and start being nib-based. It's available. Carbon has support for it.

AppKit just picks it up for free in Cocoa, right? Use standard system controls and appearances. A lot of benefits there. And don't abuse Metal. There are good guidelines out there. We're going to publish those, and please stick with them. So finally, the last area for best practices is cross-platform design.

And this is a thing, here's a statement that I run up against a fair bit, because there's a lot of software coming to Mac OS X from other platforms. Well, you see John, I can't, we can't really do it that way because, you know, the UI needs to be exactly the same across all the platforms that our product runs on. Well, it's a myth.

It's basically not, it's just not true. It's the same thing as saying that, you know, one size fits all. Well, that's not the case. It's the same thing as trying to dress for two types of weather. Try to wear your snowboarding outfit when you go windsurfing. It doesn't cut it. You cannot be doing the same thing in both places or in different weather conditions. You can't dress for all weather conditions.

So for example, here's a developer that has chosen to go their own way and not deliver a Mac OS X compliant appearance. Well, it ain't Aqua. And it isn't Windows either. Wrong wardrobe. Right? You've got a Mac OS X application with buttons that are clipped at the bottom, which is just inexcusable. To me, that says, here's fit and finish that was just left on the table. Right? No polish was applied here.

And also, we've got a tree diagram, you know, the hierarchy of files here that just is straight off of a PC. And it might work on Windows, and that's fine, because that's the way that the appearance is on another platform, or there's maybe another, you know, OS that that appearance is acceptable on. But for a Mac user who's navigating a hierarchical diagram like that, that's not their standard expected appearance. They're expecting something like List View and Finder.

Here's something dressed for failure. Taking MDI, Multiple Document Interface, and moving it onto Mac OS X. Mac OS X users expect, and many of you are probably working with two monitor desktops, right? You've got two systems connected, or two monitors on your machine. You're moving windows from one to the other. The limits of window movement are basically the size of your desktop. With MDI, while it's supported on Mac OS X through the Java interface primarily, this is who I'm seeing doing this, while it's supported for compatibility with Java, it's just not a behavior that's consistent with the overall user experience on Mac OS X.

So the proper appearance for this is, don't constrain document windows to some parent window paradigm. But make sure your docking windows just live on the desktop. The parent window is the desktop. Let users move them around and interleave them with other applications. That's how the window layering model works on Mac OS X.

All right, close but yet so far. I mean, you know, Aqua widgets, the right text, but my soul, I have no idea what I'm supposed to do here. I spend all my time reading the labels in this prep pane, and I don't know what I'm supposed to do or why even I'm asked for these things.

We get back to setup and configuration, right? Make sure to only ask your users for things that you absolutely need to know from them that you cannot figure out yourself. You know your users. You know what they're trying to accomplish and what they're working on. You know what their workflow is. And you know what your application is capable of doing.

Make intelligent choices for the user. Don't force the user to do that. One more thing. on the cross-platform topic, file name extensions. Great way to ensure compatibility between files, between multiple OSs, right? Users in heterogeneous environments are moving documents back and forth. Mac OS X fits into that world a whole lot better than earlier versions of Mac OS did.

What does that mean for you, the developer? A couple things. First of all, the save panel has a hide extension checkbox that the system provides for you. Make sure you're taking advantage of launch services APIs to do the right thing. The system will set or hide that checkbox based on what the user types. Basically, the rule for file name extensions in Mac OS X is what you type is what you see. If you type an extension, you'll see an extension.

If you don't type an extension, you'll never see that extension. to file extension, okay? And it's on a per file basis. So, as a result of that, the choice is in the user's hand. Therefore, make sure that you show the proper display name for a file in your UI, whether it's the document title, or whether it's some, you know, status, dialog box that shows status or information about a document or what have you, anything, any UI that shows information about a document should show the display name.

There's a set of APIs in Mac OS X called Launch Services, and you can say, "Hey, Launch Services, with this file system object, you know, file on system, what's its display name?" And Launch Services will know whether the extension should be shown or not, and just pass you the right string back.

So here's a file that has no extension on it, or at least that's not visible, and here's the same file with the extension being shown. So the user typed it one way or the user typed it the other way. Make sure your application respects that, because that's what the user wanted.

So best practices for cross-platform design, a lot of things. Be consistent, yet platform adaptive. So what users really want is the same functionality in the same locations, but they want the system appearance from the platform that they're running on. So in other words, it's not that they want the pref panel, the preferences dialog, to look exactly like it does on some other platform.

They want the same options to be available in the preference dialog, and they want them to be in the same tabs, for example. Thank you. Provide identical functionality between the platforms. Don't deliver an inferior product on Mac OS X. There's stuff available in Mac OS X now that can enable you to take your product to a whole new level in terms of overall functionality and connectivity and user experience.

Deliver the platform-appropriate appearance. Make sure you're leveraging standard system controls, right, to get the Aqua appearance, look and feel. Platform behaviors. For example, drag and drop. Drag and drop on Mac OS works a certain way. Make sure that your application fits into that world and it accepts a drag from the desktop, if that's appropriate for it to do that, given the workflow users might have. Leverage platform strengths. Wherever possible, take advantage of really cool technologies on Mac OS X. Some of them don't relate to user experience, but many do.

If you're in education, higher ed, there's some good reasons for using text. We have a great synthesizer on Mac OS X that can speak back text and save your application from having to store digital audio. You can reduce the size of your footprint on a CD, for example, and speak back text in a very intelligible voice. There are other technologies. Address book. Don't write your own, you know, contact management system. Leverage address book. So leverage the relevant technologies. Embrace file name extensions and show the display name.

And lastly, avoid delivering a lowest common denominator user experience. The problem that I see in many cases with cross-platform applications is they're not leveraging platform strengths. And yeah, I'm standing up here for Apple, encouraging you to leverage platform strengths from Mac OS X, but the same is true for Windows, if you're delivering on Mac and Windows.

If you deliver a lowest common denominator user experience, your Windows users are going to suffer as well. So do what you can with the architecture of your product to take advantage of the strengths that are on the platform and deliver what the users on that platform really want.

Finally, where do you go for more resources here? Well, a really great place to go and remember is developer.apple.com/ue, which is the user experience portal. There's links to piles of information about address book and speech and help technologies, et cetera. There's some great links to stories of peers of yours who have decided to go out the extra mile and pull out all the stops and take full advantage of Aqua. And their stories tell about the experience and their learning and how it affected their business positively, and lots of other great resources there.

Secondly, always consult the human interface guidelines. We've got a new version coming for Panther, and it's going to include a lot of the stuff I've talked about today, as well as, you know, as we figure out the fine details of Panther, we'll include a lot of that information as it's relevant for you.

Another thing that I didn't talk about but that relates to the visual appearance of your application is the icon design. What do toolbar icons look like? What is your application, the application icon itself, the one that sits in the dock, what does that look like? Does it fit into the world of Mac OS X? What do your document icons look like? A lot of these things need to be redone or done in the first place for Mac OS X, and in many cases, developers don't have the resources in-house to do that. If that's your case, there are some great resources that are linked to Mac OS X.

John Geleynse I think you can see off of the user experience portal of companies that can help you do this. One of them is Icon Factory. They're here on site, I think, today. I don't know if the other companies are. If they are, feel free to stop in and work with them. These guys do great work, and their expertise is icon design and visual design. Their expertise is in programming. That's your job. But go to the experts for some of this stuff.

And lastly, work with me. Take my email address down. Contact me after the conference. I probably do three UI reviews a week, which is where I sit down with developers for an hour or up to a whole day, depending on what my schedule allows. And I can look at every menu, every dialog box, every document window, every aspect of your product from installation, packaging, through installation, through configuration, through operation, and help you craft that product and make it a whole lot easier to use.

John Geleynse And lastly, work with me. Take my email address down. Contact me after the conference. I probably do three UI reviews a week, which is where I sit down with developers for an hour or up to a whole day, depending on what my schedule allows. And I can look at every menu, every document window, and help you craft that product and make it a whole lot easier to use. John Geleynse And lastly, work with me.

Take my email address down. Contact me after the conference. I probably do three UI reviews a week, which is where I sit down with developers for an hour or up to a whole day, depending on what my schedule allows. And I can look at every menu, every document window, and help you craft that product and make it a whole lot easier to use.