Ladies and gentlemen, please welcome User Experience Evangelist, John Geleynse. Well, good morning. Welcome to session one and to the second day of WWDC. I hope you had a great day yesterday. Today we're going to begin the day with two sessions focused on user experience for Mac OS X. And the first one is going to focus on the principles, the human interface design principles that we employ at Apple as we put together the operating system, as we put together some of the applications that we produce.

And the focus of this session is around these principles, and really the content for this session is chapter one from the Aqua Human Interface Guidelines book. And then we're going to follow that up with part two at 10:30, which is focusing specifically on adopting Aqua. But to talk you through the principles, I want to introduce Stan Taylor, a member of the human interface design team at Apple.

Stan? Good morning. This morning we're going to talk about human interface design principles. Human interface design principles are basically statements of policy about designing interface that work most of the time, and that's gained from concrete experience. But as I was thinking about how to gel the concept of HI principles down, I thought I'd illustrate it with a riddle.

This riddle is about three salespeople in your organization who are on a trip trying to sell your software. And they get done with their job late at night and they have to check into a hotel. Turns out it's a very inexpensive hotel, but they have to get up early the next morning for a flight.

So as they're preparing, as they're on their way up to the room with the bell person, they ask him, "How much is the room?" And he tells them, "It's $30." I told you the room was cheap. So that meant that they each gave him $10 for the room.

Well, the bell person takes the money back down to the clerk and the clerk says, "The room is only $25. You've overcharged them by $5." So the clerk on the way back, the bell person on the way back up is thinking, "I don't know how to split $5 evenly three ways." He gives them back one dollar per person and puts two dollars in his pocket.

So let's see what we've got so far. They each paid $9 to the room, that's $27. The bell person kept $2, that's $29. Where did the other dollar go? Now it's early in the morning hopefully and at least some of you aren't quite sure where that dollar went. And the reason that you're not thinking about this problem right is I created an expectation in you by telling you something that wasn't true.

I told you that each person paid $9 for the room, and that was $27. And in doing that, I created an expectation in you that led you to think about the problem in a particular way. As a matter of fact, each person paid $8.3 for the room, $2/3 for the tip, that's $27, they each got back $1, that's $30.

But by mismanaging your expectations, I cause confusion in you. When we create interfaces, we don't intend to confuse people, but we may. And so, HI principles are about setting and managing expectations that help the user use the software. And that's what we're going to talk about this morning. Why are they important? Well, first of all, the user benefits.

Applying these principles will make your software more usable, and that turns out to be one of the top predictors of satisfaction. So of course you want satisfied users, applying these principles will help you get there. In addition, think what happens when they can't use a particular piece of software.

What do they do? After they've exhausted the manual and help, if they go there at all, what they're going to do next is go find someone else in their organization that they think knows how to use the software. And that person is going to sit down with them and they're both going to start working to figure out how to solve the problem. At that point in time you have two people who aren't doing their job.

Turns out that that costs a lot of money and lost productivity each year. So you want to set the right set of expectations so that users can learn the product, they can work well with it and get their work done without losing productivity. And what's that mean for you? That means that you're going to spend less money.

It's going to reduce your support costs. It's going to simplify and, therefore, reduce the amount of documentation that you have to produce. And in addition, you're going to produce less UI. As we go through the principles, you're going to see that an application with less UI is actually a better one. And that, of course, is going to lead to revenue.

So this is a win-win situation. Now there are a lot of principles. Don't memorize this chart. This is just to give you an idea of the ones that we're going to spend a little bit of time on today. There's one that's very big and we'll spend particular time on that one to get things started.

But these principles are documented in the Aqua Human Interface Guidelines. They are available on the web. If you don't have a copy, download it. It's free. And the early part of that will deal with the human interface principles, and the rest of the document shows how we've extended those principles and actually created a UI, and it tells you how to use them. And a lot of that will be the topic of what will be in the next session.

So the first principle is know your users. And if you haven't heard it before, you are not your user. You have to find out who they are and what they can do. and you have to find out what they're doing because uh... they come in all sorts of different flavors and What you learn about them will help you create a user interface that meets their expectations.

And kind of a rule of thumb that we use, and you can adapt it however you want, is pick your favorite victim. Could my niece, my nephew, my mom, my dad, my kid, and my favorite one, the irritating neighbor, for those of you from California, if you've seen the Pac Bell commercials, you know about the guy next door that comes over to borrow your DSL, could that guy use your interface? One way to identify who your users are and what they can do is to create a usage scenario.

Simply set down in writing or in a document by examining your users who they are. For example, is it a child in school using their first computer? Is it an ex-Windows user? Is it a person creating a professional movie? All of them come to the interface with different expectations. And what are they doing? Are they creating a website? Are they creating a family tree? Are they creating a movie, as I suggested? Again, this will determine what they think about when they approach the interface.

And their background and what they have to do will also determine how they approach the task and the interface. So the time you spend getting to know them will allow you to adapt the interface to their particular skills and expectations. And when you do that, keep in mind that what you're going to be doing is taking their job, what they want to do, and making it easier for them to do that.

So you're not just going to go and say, "They do this, then this, then this, then this," and mimic it in the interface. You want to find out what they're doing, think about how can you make them get their work done better, and then that's what you'll do.

We tend to think of users as falling on a dimension. On one end we have what we call the low end users. Typical of that would be the person who has a new mini-DV camera and says, "I really like that iMovie. I want to use it." And they go out and buy their very first computer. They would be a relatively low skilled group in terms of using a computer.

Another example might be the children in school that are handed an iBook and said, "This is what you're going to do your homework on." On the other end of the spectrum we have what we sometimes call power users. These are the very sophisticated scientists, professional designers, IT professionals, the ones that tend to use what we sometimes call the high-end apps. But keep in mind that that new user, the so-called newbie, is going to learn over time and become more proficient in performing certain tasks, particularly the tasks that are involved in getting their work done.

And the high end user, the power user, they really become masters at the applications that are used in getting their work done. But when they use a new piece of software, even though they may bring more sophisticated approaches to using it, they're still novices at that point in time. Both of these groups are going to be very frustrated if they can't get their work done because yours or our software gets in their way. So, know your users. Fundamental basis for all the rest of the principles.

The next principle is kind of the basis for graphical user interface. We're calling it C and point. Basically it says that everything a user can do is visible in the interface. And in particular, there's a model that says, first I pick an object, and then I pick a verb to act on that object.

And that's the basic model of graphical user interface. They can pick the action in a couple of ways. And we'll discuss direct manipulation in a minute. But the most classic way is to select an object, as you see here, selecting the folder, and then selecting an action to perform on that object.

And the idea is that the user doesn't have to know any syntax. They don't have to know, they don't have to memorize any commands. It's all visible to them in the interface. We mention this because we still see some applications that don't quite get the principle right. For example, they might ask someone to pick a property, then pick an object, and then pick something else that causes the property to be applied to the object. And it gets complicated and confuses the users. So that's a basic fundamental principle, C and point.

Metaphors is another one. You can take real world objects and use them as a metaphor in the interface. For example, menus are something that people are familiar with in restaurants. They know they can pick items from a menu to, in the case of a restaurant, choose food. We can take that, put it in the interface, and help them out by something that's familiar.

They know how to manage files and folders and coordinate them. So we can use that knowledge and build folders into the interface. They know that they can use a trash can to throw things away. So we know that we can create a metaphor on the computer as a way of getting things off the computer or throwing it away.

So metaphors allow us to take real world, familiar objects and take advantage of what the users already know about those objects in getting work done.

But in the early days when people created their work, saved it on a diskette, they weren't very comfortable about taking that diskette then and putting it in the trash can. You know, I don't want to throw my work away.

And you'll notice, by the way, in Mac OS X now, I don't think many of you use diskettes anymore, but if you drag a CD around or a zip disk around, you'll see that the trash can turns into an icon of the eject button to help people who have trouble with that metaphor. So metaphors, use them, but put some thought behind how you use them in the interface. The next principle is Direct Manipulation.

Whenever possible, let the user act on the object the way they would in the real world. It saves them having to scan the menus to find something. In this case, for example, what's illustrated is taking a file and dragging it and dropping it into a folder. In fact, drag and drop is probably the most common form of direct manipulation.

And when you use drag and drop, try to use it, you know, wherever you use copy and paste, use it for dragging files around, but use it for other things as well. Like if a user selects text, let them drag the text around. In general, you want to use direct manipulation wherever it's expected. And users actually expect it more than just moving things around.

So support it whenever they use it. In this example, we have a text document and we have the color A little chip from the color picker is being dragged around. The chip knows something about its color, maybe the color space it came from. The text document knows that it can take information from that chip, that is the color that it wants, and change the text to that color.

Another example would be if you used a name and an address book that contains phone numbers, email addresses, all sorts of things, but you could drag it into some other application, and that application would know that it could take from what was being dragged information that it needed about the user. Not all of the information, just the pieces that apply to that application. The best way to see what users expect is to observe them.

The next principle is Flexibility. Let different users at different times do things in different ways. I've listed seven possible ways of selecting a verb, for example, here. Now, we're not suggesting that every single case you use all seven of these. That would be horrible. But for example, if there's a very frequently accessed menu command, give it a keyboard shortcut. Don't give all of your commands keyboard shortcuts. That overwhelms the user, and they never remember them anyway. But if it's frequently done, give it a keyboard shortcut.

And for those things that are very, very commonly done, you can put them in a toolbar. Here we show our View Switcher widget, which is in the Finder toolbar, that allows the user to switch views. We know that's done frequently, and putting it in the toolbar makes it even more accessible to the user and requires even less memory. Again, we're relying on recognition memory as opposed to recall, but you can save them the need to go to the menu bar to find the action. Contextual Menu is another example of something that you could do.

You can provide very frequently used commands in a contextual menu on your files or folders or objects and again support the user and different user styles in interacting. So try to keep the interface flexible. At this point in time, I'd like to invite Pat Coleman to come up and give you a demo of how C and Point, Metaphors, Direct Manipulation, and Flexibility have been applied in Mac OS X. Pat? Thanks, Stan.

In order to show these principles that Stan has been telling you about, we decided to pick one of the finder elements that was added in Mac OS X, Favorites, and demonstrate these principles, not because you won't know anything about this, you probably use this all the time, but the point is to analyze this particular feature against these principles. The first folder, I want to add this to my favorites. The typical activity would be to go through the menus and find the command that would let me do that. It's in the file menu, of course. Here it is, add to favorites.

In order to find out, did it really get there? I can scan the menus and find the favorites. The favorite menu, and again, looking at what we're doing so far, the menus of course is the metaphor that Stan was talking about that you could, that everybody could utilize because it's so familiar to people. And the words are there and people can make that connection. So here in the hierarchical menu, we have listed the fact that best of web folder has been added there, but we could actually go there and make sure it is indeed there.

So, That's the first method. So what we're talking about here, okay, we want to add more flexibility to this. The second folder we could add to favorites by using the command keys. Now, as you all noticed here, Command-T is indicated in the menu, but if I use that off the keyboard, And then use Command-Shift-F To go there, I'm not sure why the two commands are different letters, but we could talk about that later. When you get there, you see indeed, Movies and Birthdays has been added.

So, this is the power user element, and we've added that So if you analyze and say, "Okay, here the flexibility has been utilized and more, instead of just using the menu, somebody that's a power user can remember the command keys, can actually do this quite quickly." The last method, of course, is Direct Manipulation. You pick the folder and you drag it to favorites. It's in the toolbar. The heart is familiar.

It's used for things that you really like or love. And in this case, we've used it as the icon to represent favorites in the toolbar. Clicking on favorites This session teaches the basic human interface design principles that make the Macintosh what it is. Learn to implement Modelessness, Direct Manipulation, User Control, Forgiveness, Feedback and Dialog, and other interface design principles to create applications that users find intuitive, friendly, and powerful. Stan Taylor, Robert Kondrk, John Geleynse Basically what we're trying to show here is that a familiar thing in the Finder is actually using the principles that Stan has been talking about. And I'll send it back to Stan. You can hear about some more. Thank you, Pat.

Okay, the next principle is called User Control. Basically, the user should drive the computer, the computer should not drive the user. So you want to make sure that the You're providing an environment where the user feels that they have control over what's happening in the computer. One way to do that is make sure you don't send them down a path.

For example, a calendar application might say, allow the user complete control on when to pick the people, the place, the time, and there was another aspect of the calendar which I'm forgetting right now, but the point is, rather than say, do this, then this, then this, it allows the user to do it in any order they want. Now, sometimes... You do want to assist the user by providing them a sequence of steps. We do that with assistance. But always we allow the user to change the things that they're setting up in the assistant in other ways.

So the user needs to be in control. Now one way of doing that, because there are times when there are things that they can't do at the interface in a particular time, is to show, to enable or disable UI in order to tell them that something isn't available. But it's not gone. It's still there.

So that's an example. The other way is provide a warning or an alert, particularly if the user is about to do something horrible. If they want to, for example, trash their hard disk, that's their right. Give them a warning, but let them do it. And then the other thing is to provide a working context, such as a set of tool palettes that are appropriate to the task being done at the time, so the user doesn't have to hunt for them. They feel they're in control of the system because the tools they need are always present at the time they need them.

Toolbars is an example. These are favorite things that the user wants to access frequently, and we can sit here and decide for the user what those are, but better is letting the user decide what they are and be able to tailor the menu bar in terms of the actions that they're going to do most frequently.

The next principle, Consistency, is sometimes overemphasized, but please don't underestimate how important this principle is. This is probably the fundamental principle that allows users to build up an expectation of how a system works or how an application works. In this example behind you, or behind me, we were showing an example where if you drag an icon from the dock, we show a little poof icon. And the user learns that that means that the item is gone from the dock, but not gone from the system.

Well, to build on that experience and to be consistent, we do the same thing in toolbars elsewhere. Here in the System Preferences, for example, if you drag the icon off the toolbar in System Preferences, you see the poof. And by consistently doing that, consistently using that metaphor, the user learns that this is how -- this is what it means. It means the item's gone from wherever I took it from, but it's not gone from the system.

Consistency is a difficult one, so when you think about it, consider whether or not you need to be consistent with, for example, your application itself. Now, that's, I think, is actually a fairly important one. It's often the case that we can identify the timeline of development of a major application or the organizational structure of a large company that produces applications just by looking at how differently things are done in different places.

This allows everybody to be creative, but it also confuses users. Users are then not sure, how do I accomplish this goal here when in another place it's done in another way. Another element to consider is if you're building an application that's based on some concept or model from the real world, either in terms of the real world or something that you did in a previous version of your application, or applications that are similar to yours do it, at least consider whether you want to break that expectation that the user has by being inconsistent. Because if you are, you may make it difficult for them to use your product.

And finally, this is going to keep coming up, the Aqua Human Interface Guidelines. It's very important to be consistent with what you see in the guidelines that are provided in the Aqua Human Interface Guidelines. The reason is the user is going to build up expectations based on their interaction with the operating system and other applications that have followed the guidelines. If you don't follow the guidelines, then not only will users have difficulty using your application, but this will break down their expectations that they've built up from the operating system and other applications and will lead to possibly confusion in general.

What you see is what you get. Very well known principle, WYSIWYG. It has two aspects. And in terms of output, I wanted to point out that it was originally talked about primarily in terms of printing. But we're now creating all sorts of different media that we then send to some other--we create something on the computer and send it to other media.

For example, we create movies now. We put them on DV or QuickTime. We create music and it goes on iPods or in games or other places. And pictures that go on albums. In all cases, what the user sees or hears or possibly sometime in the future smells, what's on the computer should be the same thing that they experience in the final media that it's taken to.

The other aspect of what you see is what you get has to do with the interface itself. What the user needs to get the task done should be visible to the user. They should always be able to find all the functionality of your product. Now you don't necessarily want to show all the functionality at the same time, but always make it obvious to the user how to get to the additional functionality.

And now I'm going to ask Pat to demo User Control, Consistency, and What You See is What You Get. Pat? Okay, we're going to use mail to talk about user control and to talk about consistency.

And in the main mail window, you have a toolbar. And the way you operate on the toolbar to customize it is the same in both.

So not only are you talking here about the user having complete control over how they want their toolbar to be, In both cases, it's the consistent interface that they're interacting with. So how does this work? Well, you know, maybe you want attachments to be at the end, or maybe you want separators to organize things for you. Maybe you don't really like color, so you want to get rid of that, and that could be your compose window. In the mail window, maybe you want the mailbox to be at the end instead of delete.

You know, whatever the, but the user has complete control of this, and that's the whole idea behind the idea of a toolbar that isn't determined by the developer, by us at Apple. It's determined by the user themselves. I'll bring this back to sort of a default state here in both cases.

and, um,

You can go through all the options that you have for your toolbar. So what you see is what you get here. Maybe you don't need to have labels underneath the icons to tell you what to do. In this case, maybe you want them to be there, maybe you want the icons to be larger. It's under the complete control of the user.

It can also go away completely if you don't want to see it at all. It's at your and the user's determination. So keep those things in mind. We've gone through about six principles now and there's more to come, so I'll hand it back to Stan and we'll keep moving along. Thank you, Pat.

The next principle I want to talk about is Feedback and Communication. This is essentially the computer gives information to the user, the user makes requests of the computer. And there's various ways to do that, but the one I want to emphasize now is to use your main window, the primary interface, as much as you can.

Don't Users don't like to have to go off to dialogues or other places to get things done. So in this example here, I have a mail window and I made a request in the mail window to see all the mail that has in the body of its text the word "special." And I made the request in the primary interface. I didn't have to go to a dialogue to say that's what I want.

In addition, the mail app is giving me back the results in the primary interface. Again, I don't have to go someplace else to see what the results are. So here we see the number of hits and they're ranked in terms of likelihood of being what I was looking for based on that word. So it's using the primary interface. That's what I want to emphasize as much as possible as opposed to sending the user somewhere else.

And the users want to know what's going on. So always provide status and progress. The worst thing in the world is when the user just hits a key and then sits there, "What's happening now? I don't know." There are times when you may want to get the user's attention in the application, and if you're not the frontmost application, use our notification system because we will gently and subtly get the user's attention by bouncing the icon When you do have to tell the user there's something wrong or get their attention when you are the frontmost application, use a good error message, and I'll talk about that in a second. The other thing I wanted to say is don't bury the user in dialogues.

Again, the worst thing is when a user gets a modal dialogue to do this, and then the next thing they have to do is get another modal dialogue, and then another modal dialogue, and then they have to back all the way out again. So try to keep that as flat as possible. I would say never more than two levels, and the best is one or none.

When you write an alert, use our standard alert. You need to provide your application's icon because we have a new window layering model, and they have to be able to keep track of what application is telling them that there's a problem. In addition, if you use a standard alert, you'll have a place where you use the large system font to kind of summarize briefly the condition or error that you need to alert the user to, and then in small system font, you can give them a fuller description, the consequences of the condition, and how to get out of it. And then finally, providing them meaningful push buttons where it's very clear exactly what to do to correct the situation.

So, we all know this one, forgiveness. The worst thing in the world is when the user does something that they didn't intend to do or they do something and the result is not what they intended to do. And they're sitting there saying, "Now what? I'm in trouble." The principle of forgiveness says you're going to give them a way to deal with the problem.

One way to do that is to track the steps visually, and I'd like to call attention to one of my favorites. I think it's a very good example of user forgiveness, and that's the history palette in Photoshop where you can undo an awful lot of, in my case, terribly egregious mistakes. So, and in other cases, let the user exit a sequence of steps to is another way. But if you can't do anything about it, if you know they're about to do something that you simply can't fix, warn them.

Again, user control says let them do it. But as this example shows where the person's about to erase the hard disk, you can't do anything about it. Again, user control says let them do it. But as this example shows where the person's about to erase the hard disk, tell them, "If you do this, we can't fix it for you." But when you can, provide a way for the user to fix it. Undo and redo is the simplest way.

So after a user performs an action, have an undo choice that allows them to undo that action. And then of course there's the, "I did this. No, I didn't really want to do this. Yes, I do want to do it." So there's redo, which is an undo of an undo.

When you need to, provide alerts. And we showed you a good alert. But if you see that you're providing a lot of alerts, revisit your interface because you're probably doing something that's making it more difficult for the user. Alerts are provided when needed, but you shouldn't see a lot of them.

Modelessness. In general, don't trap the user into a particular mode or way of doing things. And that's a general rule to follow. And the first thing people are going to say, well, there are times when I have to. And yes, it makes sense. If, for example, in the real world metaphor that you're copying, the user would be in a mode. Let's say in a paint program, you pick a brush. Well, you're in a brush mode now. But make it visible to the user how to get out of that mode. And into the next mode.

Generally speaking, you would like the user to be able to do whatever they want at any time. There are ways to improve the modelessness of your application. And I've listed several here and we'll go through them. One of them is modeless dialogs. For example, when you're setting preferences or settings, put them in a modeless dialog. That way the user can interact with the--your application or other applications. And the other advantage of a modeless dialog, such as this utility palette, is that it allows the user to see the results of the settings that they're making immediately.

Another way that's new in Mac OS X is Sheets. They've been around for a while now, but it may be curious to put that as a way of modelessness since they're essentially modal dialogs. The point is they're modal only to the document or window that they're attached to. And while they're up, it allows the user to go to other places in your application or other places in the system and do things. So, use sheets as a way of promoting modelessness.

Another is drawers. Drawers take possibly big chunks of the interface that might always be in the user's face and allows the user to display them or not. So, they're not stuck in the mode of always seeing it. They can choose whether or not they want to be, to have those things present. So, it increases the modelessness of your application. And now we'll let Pat Demo feedback, forgiveness, and modelessness. Pat? Thanks, Stan. We sort of prepared a number of documents here that I'm going to use to show you these principles. I also need the font picker.

It's okay, we can make some more. Let's just have maybe a couple choices. All right, so what I want to show in this is One of the things that Stan talked about, and that is if you change something in your document, for example here, if I want to change this from Helvetica to, well, let's use the system font, Lucida Grande, and let's make it bigger, really big. And the reason for the color picker is because, let's try changing that.

Ooh, ugly. But, so if I really don't like what I see here, instead of having to go back through all the operations Stan pointed out in the undo, redo,

Feedback to the user, forgiveness to the user, always available so they're not stuck and they don't get mad because somehow you've put them down a road that they can't get out of and they haven't got any way of figuring out how to do that. To demonstrate modelessness, I want to bring down a sheet, a printing sheet here. We actually hooked up a printer, so I hope this works. And this document is huge.

So here we have a print dialog and here we have, I guess I dismissed it, or I sent it to the printer too soon. I can print this document or I can print this one. It's not, so it's modal to the actual document, it's not something the application is working on. So that's kind of important because it's great for users to be, to have that control. We're going back to a principle we talked about previously, but user control is essential.

I'm going to send this to the printer again just to show you if you can see that. I guess it's still trying to... It must be either done or crashed. Anyway, what I wanted to talk about is, in feedback, you have the opportunity to add to your icon some kind of badging or some kind of animation. You've all printed, so you know that there are sheets that come through, and if you have a USB printer that's directly hooked up to the CPU, you'll get numbers that appear on the pages.

Like this document was 12 pages, so you could, just by looking at the icon, figure out where you were in the process of printing. That kind of communication with the user is vital, something you should think about when you're developing your application. I'll send it back to Stan so we can move on to the next... Oh, well, let me just try one more thing here. If I can... Everything crashed. Oh, there we go.

The perfect dialogue. Writing alert messages is very difficult because you really do want to communicate to the user what the problem is. And of course, this is something that you really want to warn the user about if they're going to lose their data. So I guess that's also in the guidelines. So this is another plug for the guidelines. Thanks, Stan. Back to you. Thank you, Pat.

The next principle is Aesthetic Integrity. This is one where I think Aqua has raised the bar very high, and happily so. You can think of it as the quality that allows the user to sense eloquence and beauty in the interface. To do that, of course, you have to have the highest quality imagery, highest quality icons, follow the layout guidelines, because this is going to produce an interface that engages the user, and is something that the user feels very good about using. It's not just its appearance, though.

But to get the appearance right, make sure that you use our Aqua System widgets. If you don't, you won't be getting the ones that we spend a lot of time designing to make sure that they do have the highest level of aesthetic integrity. And follow the layout guidelines.

In a minute, we'll talk about why the layout guidelines are so important. So again, it's not just the beauty, it's the composition of the interface. The layout guidelines, combined with our Aqua widgets, provide, you know, they support the control hierarchy, they support the, you know, what's important, and help the user to see what's important in the interface. They eliminate clutter.

You know, if you have really great features, that's nice, but if it's buried in a bunch of other stuff, the user might not see it. So the judicious use of white space, which is documented very well in the Aqua interface guidelines, will help you there. And basically, it's a business of trying to keep the interface simple.

Taking stuff out of the interface that's only going to be noise to the user and distracts the user from their task. It's going to provide balance. So, and the user can see where, you know, where everything fits and they can find what they need when they need it. To do that, you're going to have to apply these guidelines consistently and you're going to have to attend to a great level of visual detail. So aesthetic integrity, and again, I think this is probably the one thing that stands out most about Aqua.

in designing your icons. Look at this particular set of icons that represent applications. They represent many different kinds of applications. The one on the left is for creating documents with text in them. The one in the middle, preview, is for looking at images. The one on the right is the new iChat icon.

They all look -- have a general principle that you can see, though, that there's a certain orientation in the background object, and then there's a tool located in the lower right. The tool in iChat, I guess, is the person who's conducting the chat. But you can see that even though the one on the right is -- and others have provided a number of examples of how to implement the basic human interface design principles. They are all highly detailed. In addition, to support this level of aesthetic integrity, there will be interactive graphics that you want to provide.

Here is an example of some that we have provided: the view switcher, the toolbar icons, and the back and forward buttons. Again, providing very lush, high-level, high-quality graphics will support your users in performing their task. I mentioned these two. In addition, in your own product, don't forget your splash screens, documentation, screen grabs, wherever you use those. Make sure they are of the highest quality.

The next principle is Simplicity. Again, if the user is trying to get something done and they can't figure out how to do it because there's so much garbage on the interface that they can't find the thing that they need to work on, that's going to cause them to not be able to get their work done. They're not going to be very happy. So make sure that the basic features are immediately apparent. That way the user can focus on the task that they're performing. Basically, reduce clutter.

Now, in saying that you should keep the interface simple, you're going to say, "Well, I've got a lot of advanced features I want to give them, too." Well, you can do that. We did it here. This is the simple save dialog that shows them how--provides a place for a name, a pop-up for recent and favorite places, and the button.

It also has a disclosure button that allows the user to access the more advanced view of the entire file hierarchy so they can save the document someplace other than the places that are provided. And that pop-up menu. This is called progressive disclosure. And progressive disclosure allows the user at their own pace to discover the advanced features. It's not that the features are hidden from them.

If you do progressive disclosure correctly, you will make sure that there's always something visible to the user that tells them where to go to get the advanced function. But it says, "I'm not going to put it all in your face at the same time." You can progressively discover it as you mature in using the application. Thank you.

And the final principle that I want to mention is Accessibility. Users don't all have the same abilities. As you see the list here, visual impairments, hearing impairments, difficulty in performing fine motor movements, those three alone account for roughly one out of five users. Twenty percent of users, or would-be users, have difficulty in one of those areas. And in addition, there are people with learning impairments. You can support them in large part by following the guidelines because a well-organized interface will help people who have learning difficulties. There are 52 million people in the U.S. with disabilities.

Now, in a minute, we're going to demonstrate some of the built-in features, which if you went to the keynote, you may have seen some of those as well. But as you design your interface, keep in mind that we didn't do everything for you. You have to think about the fact that users don't all have the same abilities.

So, for example, if you provide-- Is there something that you can hear? Is there something that you can see that provides the same information? If you use color, what happens if a person can't see color? Can they use the interface? And so we've built a lot of things into the system. And the other thing I would like to mention, there's a session on Thursday that will tell you also how you can make your application able to use the new-- The new system.

--assistive APIs that will provide the ability for assistive technologies to--

We've chosen System Preferences to talk a little bit about aesthetic integrity. One reason is because it's one of the places where there's a large collection of icons that we've

To separate these things, although we've used separators here to draw attention to the various categories, it still is Using a lot of space on either side of that separator.

If I go into an actual In the account section of preferences where you actually establish the various accounts, I wanted to point out individual pains and how we've actually set those things up. One of the things that we've done is we've been clustering everything toward the center, aligning the labels to the right and the content to the left, so it sort of creates these axes that the user can be drawn to. It's sort of the center of focus idea.

One thing that seems to be somewhat confusing to developers, we've gotten a lot of questions about it, is that there's this idea of centering everything within the space. What we're really talking about here is once you've established the layout of your content, it's equalizing it within the pain that you have available for your use. This is being established, this size, by all the pains that are here. We've constrained ourselves a little bit, but for the most part, it works out pretty well.

If we go to the accounts, this is utilizing that whole idea of progressive disclosure, something that's very simple. We're just showing what the accounts are, but if you want to go in there and start editing them, then you get something that's very similar to the My Account layout. How to change your picture, how to change your password is available there.

If you're a new user, you also get a lot of information about this. The next thing that we're going to talk about is the layout of the content. We're going to talk about the layout of the content. We're going to talk about the layout of the content. We're going to talk about the layout of the content. We're going to talk about the layout of the content. We're going to talk about the layout of the content. We're going to talk about the layout of the content. We're going to talk So I'll leave that to you to go in and investigate what those actually are.

I'm going to go to the general controls pane because one of the things that Stan mentioned is this idea of possibly color not being something that everybody would be able to see. We've created two different appearances. One is blue. And when you are in the blue mode, the title bar controls are the red, yellow, and green.

In this case, the zoom isn't available because this isn't available to be zoomed. But if you change to graphite, the color goes away, but the glyphs are still there. So the rollover effect is still present. So we can't really... The reliance on color is something that you should avoid, basically. The last thing I want to talk about is something that gets into this idea of accessibility, and that is keyboard navigation that we've added in the system that you can take advantage of in your applications.

So, if I just go ahead and show you the keyboard navigation. Let's see. I'll make sure it's turned on here. It is not. Okay. Now that it is, and all controls can be navigated to, go back to the main pane and you'll see that it's there. And through the arrow keys, can you see how it's focusing around the icon of the controls up there? Well, actually I wanted to stay on the general controls thing so we can... How do I get into the actual pane, Stan? I think you have a demo effect going on. Oh, there we are.

So, now I can use the arrow keys to pop the menu, and if I wanted to... Select blue again. It does that. Highlight color if I wanted to pop the menu for that and then navigate through the different colors. I can change the highlight color by hitting the space bar and continuing on through the...whoops.

I'm going to demo some of the built-in features that allow people with disabilities to use the computer. I'm not going to demonstrate all of them, but one of them is mouse keys, which simply allows the user to use the numeric keypad to

Again, we paid attention to all of our principles when we designed that, so we built some aesthetic integrity into this as well.

If the user, for example, presses a command key, A little glyph appears that shows that the command key has been pressed and all the keys, let me move this aside so you can get a good view of this, all the keys can show up and then as soon as they hit a key that's not, The key is a key that is not a modifier key, then those glyphs go away.

So we provided some aesthetic integrity in terms of some engaging feedback for the user who wants it. Slow keys, I'm not going to demonstrate, but that allows a user who has to have a delay between the time a key is pressed and when the key actually registers. For hearing impaired people, they need to have something that shows them when there's been a system beep.

And the problem is we've always used a flashing menu bar, and with screens getting larger and larger, it's sometimes difficult to see that. So we've come up with a new way of showing the system beep. The screen simply has a little flash. And so if a user does something that would cause a system beep, they get the flash.

Finally, for users who need to enlarge the screen, we have a new zooming feature, and this allows the user to use the numeric keypad to zoom in and out. And one of the nice things they can do with this is they can say -- let's say a user needs to zoom into here to be able to see the interface, and they can't see anything when it's zoomed out here, but they can maybe navigate a bit if it were zoomed not quite so far.

Then we allow them to do that, so now with that set, I can zoom right in, and then I zoom out to that intermediate position, zoom back in, zoom back out, and if I want to keep zooming out, I just hold the button, and it zooms all the way out. So that's -- And then finally, there are users who have difficulty with screens. They can't tolerate bright environments, and so we allow them to... To see the display in an inversed grayscale.

So those are some of the built-in accessibility. There's also a kind of a low-level screen reader that's been built into the system to get people started. Professional screen readers will be built based on that application API. So a lot has been done for you, but keep in mind as you develop your applications that there are people who have difficulties using the computer.

We've been talking about the operating system and the applications related to the operating system, but Apple also designs other solution applications. How are our principles applied there? Well, to tell us, we're inviting the Senior Manager of Application Software Design and Production, Robert Kondrk. And I'll give you this.

Thanks, Stan. My name's Robert Kondrk, and my team creates the visual design and content interfaces for many, many of Apple's applications. These applications run from iPhoto to Final Cut Pro to the new Webmail application that was just launched for iTools. The technologies that these applications use include Cocoa and Carbon and WebObjects. And of course as we're designing we think about what those underlying technologies are and their capabilities are as we work on the design.

Pat and Stan just spent a lot of time going through the different principles with examples of good best practice user interface design. What I'd like to do is spend a few minutes and just kind of zoom out, if you will, and remind us all of design's little secrets.

Know your user and know your application. From the first date, otherwise known as the first launch, to a happy marriage, otherwise known as, "I cannot live without this application," user interface matters. Good interface designs the user and the application. So you need to know and remember who your user is and what the application is built for.

Is your user a casual user? A dad creating an iMovie on the weekend of his daughter? Or is your user a pro user? Someone using Final Cut Pro whose livelihood depends on the use of that application? Is the application meant to be and designed to be very, very easy to use? Or is the fact that you need to be a power user and have many, many features available to you and many, many options more important? Know your user, know your application, choose your user and your application design targets, and then design with conviction.

Think about the user using your application. Use cases are important. User profiles are important. Workflow is important. Just take the time to go through and again focus on the user, focus on that use case, what are they actually doing with the application, and run through it. And as Stan said, and I can't remind you enough, you're not the user for your application.

Few applications are islands. So think about your application in relation to other applications and data types. What does the application need to interact with? Think about the metadata around the content. Can you retain it? Can you easily do workflow from one application to another? An application that doesn't munch other people's data is a good, good thing.

Simplify. Then simplify again. And less is more. These statements are so terribly true, and it's one thing that Apple does very, very, very well. Clutter confuses the casual user and annoys the pro user. Force yourself to simplify until it hurts. When it hurts, you know you've probably got to the right place.

The best tools are ones that you don't remember you're using. We all need to strive for this. It's not about your tool, it's about the work that could be done with the tool. And if we remember this one thing, I think we'll all design much, much more useful applications. We all want to thank you for your time, and I'd like to ask John Geleynsse to come back up, wherever you are, John. And he's going to take you through the rest of the session. Thanks.

Okay. So first of all, who do you contact about this stuff if you have questions related to how do you-- related to implementing this material or the stuff that we covered in this session? That's me. My role at Apple is to help you create really great applications in the world of Mac OS X.

And so if you have questions about the content in this session or you want to talk specifically about your product or you have issues with some of the APIs that we provide that enable you to implement some of these principles or whatever, feel free to send me an email and let's correspond after the show.

The roadmap for sessions related to user experience is essentially this. The most important one, in a sense, is the follow-up session in about 15 minutes. I'll be presenting the follow-up to this material and we'll talk specifically about adopting Aqua and what are the detailed steps that you need to undertake to implement a really great application on Mac OS X. We'll also be presenting the follow-up to this material and we'll talk specifically about adopting Aqua and what are the detailed steps that you need to undertake to implement a really great application on Mac OS X.

There's the Address Book Framework that wasn't referenced specifically in this session, but I'll be talking about it in detail in mine in session two, coming up in a few minutes. There's Speech Technologies as well, so there's a whole set of sessions here at the conference that relate to delivering a great user experience with your product, and that's what this roadmap is about.