All right, well good morning. We got a full house here today. My name is John Geleynsse. I manage the software evangelism, software technology evangelism team, sorry. And I'm also the user experience evangelist at Apple, so I'm sort of the interface police, Aquaman, you know, call me what you will. But hopefully, I bet you I've worked with many of you in the audience here. I'd love to see a show of hands of people that have already talked to me in the last year.

So we got at least 30 people in this room. I would say over the last five years of my being at Apple in this role, I've worked with close to, I would guess about 125 to 150 companies a year, and so I've touched about 600 developers. And we have worked, you know, through every dialogue, every menu, every window, and it's just been a great experience.

And I love doing this job, and I hope that comes across in the session. And if you have not met with me, I encourage you to find me sometime during the show or send me an email after the show. I also encourage you to go to the Interface Design Lab, which is down at the end of this hall on the right.

We start today at noon, and I want to encourage you to go there, sign up for half an hour if you've got just a couple of simple questions, or sign up for an hour slot. You'll be meeting with either myself or people who are far more talented than me, who are the guys and ladies who created the interface for Mac OS X, the Aqua Design team. And they can give you fantastic feedback. Don't feel shy. They're not going to kill you.

In fact, they're probably going to be gentler on you than I will be. Which is why this session is called Cutting Edge Interface Design. I hope no one bleeds in this session, and we'll have a lot of fun. And the point of the whole thing is to teach you guys how to create really great products.

Alright, we're going to go about this with sort of three major steps. Alright, to create a really great product on the platform, which of course is going to have a great, you know, sensational user interface, you need to start with something, you need to start by defining your product. And defining your product is deciding what to do and who to do it for.

The first step in this process is understanding your users. If you were in this session last year, I touched on some of this content. Don't worry, this will not be a repeat of last year's session. But this stuff is so important, I want to cover it again. Understanding your user base is critical. And this doesn't mean you have to do $100,000 studies, doesn't mean you have to get two-way labs with mirrors and all this stuff, like you may have read about elsewhere. It just means taking the time to do the analysis and think about who your customers are.

What are their goals? What do they hope to accomplish with the product that you're building? Right? What is their workflow? What are they trying to finish? You know, at the end of the day, what's the problem that they're trying to do? What are their needs? What's required for them to get the task done, basically? Don't try to be everything for everybody. Figure out exactly what you want to do, what your product is going to do, and develop it specifically for that goal. Users often don't know what they want.

If you're in consulting, you know what it's like to talk to a customer and they say, oh yeah, here's the spec, you need to build this and that and the other thing, and so you go off and, you know, like a good contractor, you build it, and then you show it to them. What happens? That's not what they wanted. Well, that's because the whole design process is a really complicated thing where people tend to have to look at something tangible and interact with it and then they realize, oh no, this isn't what I wanted.

Once you understand the market you're going to go after, and you've kind of hit the bullet points of which attributes you want to aim for, then it's critical for you to sort of prioritize those things. Because at the end of the day, you've got a bunch of work to do, and you've got to decide what you're going to do first and what you could potentially leave off to the end, right? Now I would say, you know, first, second, and third priority items, none of those get dropped to the end or left off entirely. But it's just a great exercise to go through. This is not a big academic thing. It's just take the time, get the right people in the room, talk about these things, and let these things start to drive your product design.

So, understand your users, understand the market, determine the attributes you want to go after with your product, prioritize those things. The next thing is understand yourself. Figure out what your strengths are and what your weaknesses are. Who can you partner with? Determine who you can partner with to leverage their strengths. You take the guys at Delicious Monster with Delicious Library. They decided that their expertise was one thing, and that if they wanted to get information about books and DVDs and CDs or whatever, that they would go out and partner with Amazon.

Perfect partnership. What do you do? What does your product do that really, at the end of the day, is not your strength? Find those areas and get rid of that code. Partner with somebody else who does it real well. At the end of the day, you'll have a partnership of innovators, or a partnership of, you know, kind of like the Apple Intel thing. Get the right people together on the project, and you're going to have a better product as a result.

Another thing to do is look at other successful applications or the competition. What are they doing right? What are they not doing right? What can you take advantage of in terms of their weaknesses? And if they're doing something right, why are they doing that right? What do they know that you don't know? All of this analysis, this doesn't take years.

This is-- you know, you can do this quickly. But a lot of companies I meet with, when I ask these basic questions, I say, who are your competition? Oh, they state the competition. I say, well, so what are their strengths? Well, what are you guys good at? Write some Cocoa code, or whatever. So I'm going to joke around, but I've seen a lot of companies I've been with do great stuff. But I like kidding around in this session. All right, so you've done all that stuff. Now the question is, all right, start to define the solution.

You've all got great ideas. I don't think I've met with a single company over the last five and a half years that didn't have a good idea. Maybe one. But when you start to define, you've got a great idea. You're very, very-- there's lots of great ideas out there.

Now the challenge is, all right, so what is this idea? How is it going to become a product? What is it really going to do? What are the problems it's really going to solve? And then a really great exercise is to work cross-functionally as a team and define a mission statement for your product. I put it here as a product definition statement. But a mission statement for your product.

And then hang it up. Print it out. Hang it up amongst the design team. And everything you do should come back to that mission statement. Every feature you consider, every aspect of the product should be run through the filter of that mission statement to say, hey, hey, hey, is this really part of this product? Is this really what we meant it to be? Does this need to be here? The tendency is, as you guys know, I'm sure, the tendency is to fall victim to the need to kind of glom on another feature, like, oh, yeah, yeah, yeah.

Hey, somebody wanted this thing, let's put this new feature on. And it kind of gets glommed on. And at first, you don't notice it. But after you develop a product, a couple revisions, and you've done it that way, suddenly you think, man, we're getting-- it's kind of out of control. Or it's just not what we thought it was going to be originally.

And so this is a great way to keep yourself in line. Keep in mind things like usability, efficiency, the desired workflow. How are your customers going to work with this thing? And what other applications does the product interact with? Do you need drag and drop interaction with-- Final Cut Pro? Or do you need cut, copy, paste? Or how does data move from your product to the other products? And if it doesn't, then maybe you can drop the need for some of that functionality. So anyway, lots of stuff to do.

Last thing is keep things simple. We're going to go through this stuff in detail. But keep things simple. Boil down the large concepts to their essence, to small, discrete functionality. The tendency is to say, hey, we've got this great idea. And then suddenly-- actually, there's a great-- let me just illustrate this with a cartoon.

I saw it one time years ago. And it was this comic strip. And there were a bunch of guys, people sitting at computers. And they're ready to code. And the boss is going out the door. And he says, you guys get coding. I'll go upstairs and see what they want us to make. And too often, that's the case.

So get these ideas down. Figure out who your customer base is. Figure out who your market segment is. And then define a mission statement and go from there. And anyway, so at that point, you've got a good idea. You understand all those things. You've got a sense for what the product is very specifically.

Now you start to figure out, well, what's your feature set? How will the product work specifically? If you're a time billing product or you're a music player, well, what functionality do you want to have? And that's where we start to bring in the features. Define the core set of features required, but avoid feature cascade. Don't just glom on things and look at the competition and say, oh, we have to do everything they do.

When it comes down to it, some of the best products today on Mac OS X, for that matter, some of the best products in the industry, most usable products in the industry, are not the most full-featured products in the world. You take the iPod. Why is the iPod successful? Yes, it's got great marketing behind it.

Yes, it's got a great music store behind it. But at the end of the day, the iPod is what it is because it does exactly what everyone wants it to do. Is it the most full-featured music player in the world? Does it have the most wheels and dials and buttons? No, but it doesn't matter.

No one cares because they want this music player to do just what it does and it does it perfectly. Is iTunes the most full-featured music jukebox software in the world? Not at all. There's lots of other products out there that have way more bells and whistles on them.

For new users, it wasn't intuitive enough. We found that people that were new to the product were spending too much time looking for the common commands they needed. They were spending too much time trying to find things. They were getting lost in the user interface.

They were having trouble finding things. So that needed to be solved. And finally, our user interface was showing its age. You know, we shipped our version one of our product in 1998. And the user interface that we designed at that time was appropriate for the user interface of that time. Well, things have changed dramatically since then. I mean, the user interface of Mac OS X, for example, is dramatically different from the user interface of classic Mac OS. So we needed to bring our user interface, you know, to the market. you know, into the modern age.

So this is our previous version, Real Basic 5.5. And it's got a lot of windows and we carbonized it and we made it, gave it the Aqua user interface. But the thing is, is the Aqua user interface isn't the same thing as the Mac OS X user experience. Those aren't the same thing at all. Aqua is just a component of that.

So it's not enough to simply give it the Aqua interface. You've got to think about what is the user expecting on Mac OS X. And this is not what they're expecting. So we decided that this needed a change and needed a dramatic change. So this is what we came up with. This is the version that we're going to be shipping later this month. It's a single document window. It has a toolbar, which we didn't have before. Actually, it has a couple of toolbars.

And it just, you know, it also accomplishes the most, the oldest feature in our database, which was the ability for the user to have multiple projects open. And it's a little bit more complicated than the previous version. So we decided to make it a little bit more complicated. And it's a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version.

And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version.

And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version. And we decided to make it a little bit more complicated than the previous version.

And we decided to make it a little bit more complicated than They navigate a lot. And so we asked ourselves, well, what knowledge does the user have of navigation? What do they already know about navigation? Well, they navigate the file system from the finder, and they navigate with a web browser.

So we decided to take that knowledge that they already have, those skills they already have, and use those with our new user interface. So you can see that the new user interface looks somewhat like a web browser. There's forward and back buttons. There's a location field in the middle where you can type in the name of something in your project, and bang, it takes you right to it. There's a search field in the upper right corner, right where it is in a web browser.

And we've got tabbed browsing as well. There's tabs right in the middle, so the user can see everything that they're working with. And so when someone who is coming to Real Basic for the first time, if they've used the finder, if they've used a web browser, they're going to look at this interface, and they're going to see things that are familiar. And they're going to say, hey, I bet you that search field works similar to a search field in a web browser. I bet you those tabs work just like the tabs in Safari, that kind of thing.

So in our previous version, too many windows, way too many windows. And this isn't even close to what a typical user actually deals with. I've only opened a few of them here. And what happens here is, as I mentioned earlier, the experienced user winds up rearranging these windows constantly and resizing them. And the new user, windows get in front of other windows.

I was watching a user use this version of our product, and the project window, which is the little window in the upper left corner, it got lost completely. It was like, well, wait a minute, what happened to my project window? I can't find it anymore. And they're moving windows around to try to find it. So way too many windows.

So we solved that problem with a tabbed interface. Since we have a single document window, a single window document model this time around, we added tabs. And now the user can't get lost because everything that they've got open appears as a tab, and it's all right in front of them, easy to find, easy to use.

The other problem we had is, you know, we had concepts that we displayed in multiple windows. For example, we have a view editor or window editor, and when you double-click on an item to look at the code behind that item, we open another window. And as you can imagine, this just leads to more and more windows.

It's more confusing. So we changed the concept here. The user can still double-click on an item to get to their code, but rather than open another tab, we stay within one tab because a tab represents an item. And the user can use a little widget in the upper left corner to switch between the view of the layout of the window and the code.

So important commands in Real Basic that were in the previous version hidden on menus, running your application, building your application, those are pretty important. What we did with those is we moved them right into the toolbar where they're easy to get to. The user doesn't have to move their mouse all the way up to a menu or remember a keyboard shortcut.

I'm a mouse person myself. Some of you may be keyboard people. But we built the interface for both types of users. And so these commands are right up front, easy to find. The new user can find them right away. The experienced user isn't spending a lot of time mousing around trying to run or build.

Some other common commands, things like adding a new window to your project, adding a class interface or a module. These kind of things previously were hidden on a menu. Now, So, we created this toolbar under each tab for the common commands. And so, for the new user, once again, they're right in front of them, easy to find.

For the experienced user, they're, you know, right where they want them to be. And the other thing about this interface that's different from our previous user interface is that our previous user interface was really not customizable at all. You pretty much had to use it exactly the way it comes.

And, of course, that's changed. User interfaces are much more customizable these days. I mean, look at the finder, for example. And so, what we did with this user interface is made it customizable as well. So, you can add your own commands to the toolbars. You can change the way the toolbars look. You can use small icons, labels only, that sort of thing. Thank you.

Another common command, a lot of common commands are in dialog boxes. Searching is something that users of Real Basic do a lot. Searching clearly is something that Apple feels people do a lot in all their applications, in Mail, in Spotlight now, in Tiger, that kind of thing. So having this hidden away in a dialog doesn't really make sense, so we've moved it in the interface right up to the toolbar. And again, it's right where people expect it to be. We're reusing that knowledge that people already have of other products.

Now we still have a find dialog in Real Basic 2005, but it's for doing the advanced sort of finds that the expert user is going to do occasionally. You know, earlier John alluded to the idea of, you know, you have novice users, you might have novice users, you might have advanced users. Expert users, well, with a product like Real Basic, we have both.

We have people that are professional programmers that have been writing code for years, and we have people that are novice users that have never written a line of code in their lives. We have professional developers, and we have, you know, 10-year-old kids learning programming. So we have to have an interface that works for that very diverse group.

We also made improvements with our previous version of Real Basic when you used the find dialog and it found something, it would open the window for that item and show you what it found. Well, imagine in this case we found, what, 156 items. Okay, if you kept doing find, find, find, find, find, you'd end up with 156 windows open, which is really crazy. So, when we rebuilt our interface, when we redesigned it, we didn't just say, let's just rebuild all the functionality over again.

We looked at each function to say how, if we could, since we're going to do this over again, how could we do it better? So, we, in this case, when you do a find, you get a batch list of the results, you can see everything, they're categorized by type, and the user can even highlight items and do a replace in this dialog as well.

We have a tips window in Real Basic, and it's for context-sensitive help. And it's really great. Our customers love it. It's pretty innovative in that our tips window actually watches what you're doing and only offers advice when it's appropriate. It doesn't just bring up the random tip of the day that people ignore. It's actually watching the behavior of the user. And once the user learns the behavior, it stops presenting that tip.

And if you go back, maybe you've forgotten a certain way of doing things, it'll notice, hey, they've forgotten the behavior, so let's teach it to them again, and the tips window will give you that information. Well, the problem is, as much as our customers love the tips window, because they're constantly moving their windows around, rearranging them, etc., well, the tips window is also getting in the way. They're constantly having to move it around.

So they had kind of a love-hate relationship with this. So what we did for 2005 is we moved it to the bottom of the main window. It's in, like, the equivalent of the status bar in Safari. So it's always there. It's always in the same place. Nice, consistent interface. And it never gets in their way.

In our previous version, we had too many modal dialogs. Sheets are a great improvement over the modal dialogs we had in some cases. Like in this case, the dialog you're looking at is the method declaration dialog. Well, the user needs to interact with this information and the code behind it, but in this case, it's covering up about half the code.

The user can't see both at the same time. So we changed that in Real Basic 2005 to make it less modal. That information is now a pane inside the code editor, which can be expanded or collapsed. So the user can work with it, work with their code, collapse it quickly, and they're not in a modal state anymore. In fact, I think we probably only have one or two modal dialogs in all of Real Basic 2005, and they're the kinds of things that the user is going to rarely interact with.

So what did we learn going through this process? Well, first we learned that we need to watch our users. You need to watch what your users are doing. John said this earlier. Watch how they work. You don't need a $10,000 or $100,000 lab to do this. You don't need two-way mirrors and video cameras and all the scientific way of monitoring what a person does.

Bring them into your conference room and just sit next to them and watch them use your product. You will see when they get frustrated or when they're confused. And we did this ourselves. We brought users into our conference room. We sat there and watched them work. New users and experienced users. And we were surprised at the things we learned.

John Geleynse I guarantee you, if you do this, you better have a pad of paper or you better be the world's fastest typist because you're not going to be able to take notes fast enough. You're going to actually ask people, could you stop for a second because I'm not able to write all this stuff down. You're going to learn a tremendous amount about your product, about your user interface.

Don't be afraid to make big changes. You know, as developers, we pour our blood, sweat, and tears into building our products. And we love the way we do things, and we've poured a lot of energy into it. But that's not really what's important. I mean, it's great to do that. But at the end of the day, what's important is that the product be usable. I mean, we're not doing this out of the kindness of our hearts.

We want to make money. So the more usable your product is, the more intuitive it is, the more of it you're going to sell. So that's really important. And in our case, there was really no way for us to make incremental changes to arrive at what we needed to have, this new user interface. We really had to make a dramatic change. And we accepted that. We spent two years doing it.

And in fact, as a side note, the previous version's user interface was written in C++ on top of our cross-platform framework. This version, Real Basic 2005, is written in Real Basic. So when people ask us, well, give me an example of what you can do with Real Basic, now we can say, well, Real Basic. So don't be afraid to make big changes.

Consider the knowledge the user already has. I mentioned this earlier. It's not always the best thing to do. It may be creative, but it's not always the best thing to do to invent some new way of doing things. Sometimes it's good to innovate, but other times it's good to be consistent.

And consistency really should come first. If there is no consistent way of doing something, well then you're going to have to come up with something new. But if there is a way that the user is used to working, then do that. I mean, imagine if you got into an automobile and the steering wheel was different and the way you shifted gears was different and the way you turned on blinkers.

I mean, you can get into any car and immediately use it because you're reusing knowledge you have, right? It would be very frustrating if it didn't work that way. Well, software is exactly the same way. And I think that Apple has got to be the kings of consistency and excellent user interface. So, look at what knowledge the user has and reuse that knowledge.

Read Apple's Human Interface Guidelines. The guidelines aren't just examples of what to do. They don't necessarily say this, but there was a tremendous amount of thought and care and logic that went into the user interface guidelines. That logic may not be presented in the document itself, but trust me, it's all behind the scenes. Read the Human Interface Guidelines. Know them well. You'll learn a lot from that.

and visit the H.I. Lab. John mentioned this earlier. It's down the hall. You can sit down with user interface experts at Apple. They'll give you plenty of great feedback. A couple times during the development of our user interface, we sat down with John Geleynsse, which we really appreciate, John.

He went over the entire user interface with us and gave us a tremendous amount of feedback on big things, on little things. There was a lot of stuff that we would have missed if we hadn't done that. As developers, Apple provides this to you, so take advantage of it.

John said not everyone is an expert at everything. That's absolutely true. You're not necessarily going to be an expert at user interface right away. The people at Apple are. Take advantage of that resource. So I'd like to thank you for having me here today, John, and enjoy the rest of the conference.

All right, that's great. I'd like to invite one other guy on stage. Adam Baker is an intern for me a couple years ago. He's going to talk quickly about what they did with their product, and then we're going to get into some cutting-edge bleeding stuff. Thank you, John. So, as John mentioned, I am a user interface designer for Market Circle, and we just released a product called Billings, which as you may be able to tell from the icon is a time billing application. So you can track your time, send invoices, track payments, and so on.

So this is Billings' main window, and it's not especially exciting software because it's basically accounting software. You know, this is not really glamorous stuff. Nevertheless, somewhat mundane or boring software can still be well designed. And we think that Billings works. Now the question is how does Billings work, or why does it work? And when we looked at the competition, we found that they were just too complicated. So our goal was to keep Billings simple. Now this is also kind of misleading because keeping something simple is harder than it looks. It's really about focus.

So, focus is really about saying no to things that don't belong, rather than finding the right thing and saying yes to that. It's about saying this doesn't belong. One way to frame your application to focus it is to ask a few questions about it. The first is who's going to use it? John and Jeff talked about this already. This is the most important step. Then find out what will it be. This is really talking about the functionality, what the application will do for these customers. And next is how will it work? And this really is about the actual user interface of the product.

So in the case of Billings, the first thing we had to find out was who's going to use this product. We had to identify our users. And one thing that we knew about our users is that they're independent professionals who track and build their time. So these are people like lawyers, like designers, like housing contractors. They do work. They work at a particular hourly wage. They need to send accurate invoices to their customers.

We know that they spend most of their time in other applications or not on the Mac at all. Which means that in the case of a designer, for instance, she might spend 8 hours a day, or 7 hours a day, or 12 hours a day in QuarkXPress, in Photoshop, in InDesign. You know, Billings is going to be a secondary app, even though it's doing something very important.

Our users aren't accountants, so they may not be familiar with accounting terms, they may not like keeping track of expense receipts, and making up invoices, and calculating taxes, and markup and discount. This is not fun stuff. Some people aren't very good at math. Programs should do this for them. Understanding the users leads to this concept of a solution. Going point by point, our users need a solution that makes time tracking simple. It needs to be easy.

They need something that's easy to learn and lightweight. In the case of the designer, remember that our application is secondary. If it takes up a lot of screen real estate or if it's very imposing on the user, they're going to find that it gets in the way of their normal workflow.

So in our case, we do have a main window, a big window, but the core functionality is provided in a smaller window, a timer window, that floats above all other applications or can be hidden completely and still run. And the most important thing, perhaps, in a case like this, really has very little to do with user interface per se, but everything to do with user experience, which is that the solution that we came up with had to do the heavy lifting for users. So users aren't doing the accounting themselves. Billings is doing the accounting for them.

Second question, what will Billings do, is all about defining the functionality. So a very common way of developing is to come up with a list of features like this. So an application like Billings needs to do all of this stuff and more. But it's almost impossible to look at this and distill a really compact statement that describes what the solution is. Yet you could begin with this and actually implement all of these features one at a time. You could string them together into some kind of user interface.

Best thing to do, as John already mentioned, is to come up with a mission statement. In our case, all of these features can be condensed into estimates, time tracking, and invoicing for the Mac-based professional. This is our solution. This is like a box. We know what stuff goes in the box. We know things that don't belong in the box.

The last part, how will Billings work? This is really about the user interface design, and so I'm not going to go into detail about what we did per se, but I'll share with you some tips. If you want to see what we ended up with, you can download Billings.

So I figured that there are three big tips I can share with you that came out of what we learned when we're doing Billings. The first is to think Aqua. As Jeff mentioned, Aqua and the whole Mac OS X user experience is something that is very complete. It's got a very specific feel. And a lot of work has been done by other developers and by Apple to come up with the human interface guidelines, great examples of applications. So thinking Aqua is really important. If your app doesn't look and feel like a Mac OS X application, users will reject it right away.

Second tip is to design on paper. And the third tip is to keep learning proportional to your application's importance. This is also really, really important. If your application is like Billings, one that people use maybe 10 minutes a day, you don't want to make it difficult to learn. People need to be able to get in and out really quickly.

But, you know, there's a big focus on ease of use and you might feel that if your application is one that people use all day, that it's the main part of their business, that you don't, it might be confusing to you to say it needs to be easy to use.

You know, this is a complicated app, it does all of these complicated things and it's really helpful to our users. In that case, people will be willing to learn more about your application because it's their bread and butter. But in the case of something like a calculator or time tracking app, you know, it has to be obvious right from the start.

So the first point about Aqua, I mean these are just some screens from Billings. In the vein of keeping it easy to learn, we had to make sure that every dialogue, every window was easily digestible. So one thing that the Aqua guidelines talk about that good Mac OS X apps do is they take advantage of white space. They intelligently group controls. No matter what kind of dialogue you're doing, you can keep things easily understandable by leaving a lot of space. Don't crowd anything. Use standard controls and so on.

This point about starting on paper is really important to me. This is a scan of a sketchbook page. And there's this line, the pen is mightier than the mouse. Yeah, it's very cheesy, so my apologies. But it's really important. When you are planning your application, it's great that, you know, for instance, IB is so fast.

You can drag out your controls, you can start thinking about your bindings right away. You can think about making an app almost, you know, instantly. But what you're not doing is you're not thinking twice or three times as you're pulling out your app. You're not pulling out these controls.

You know, I can lay out a dialogue like some of the ones I showed you in five minutes, maybe less. But to actually draw it on paper takes quite a bit more time. And as I'm committing my pen to the paper, drawing each button, or drawing each window, as the case may be, depending on how detailed you are with your sketches, you're thinking twice. It's really hard to draw and write out eight radio buttons on paper.

And as you're writing those eight radio buttons out, you'll be thinking, do I need this one? Maybe not. You know, maybe I can skip this one and get by faster. Maybe this one doesn't really make sense. So starting on paper is a really great way to plan your app.

And the most important thing about this, really, is that you can make mistakes now, and you don't have to recode anything. You can just make mistakes and show it to someone, say, does this work? No, no, you've got to move this around. You haven't actually invested in code. You haven't invested in nibs. You can just change it on paper. And once you have it planned, go digital.

And so the point about keeping learning minimal, if there's anything extra in your UI, it means that people have to learn something extra. So focus on your core functionality. Anything extra, get rid of it, because people are just going to have to learn what that thing does, and it's away from the main purpose of the app.

It's not focused. Progressive disclosure makes it easy for users to get started. So like Jeff was just saying, put certain things right up front, but keep other things that maybe are fringe case or for the 20% of users available but hidden away. We'll show these things later as people become more comfortable with the app.

and use context-sensitive help. Also, Jeff showed that they have the tip window or the tip status bar in Real Basic 2005. We do something kind of similar in Billings, which is we have a help box. When you first open the application, certain areas of the interface are described for you in an unobtrusive box that will go away the next time you use the application, unless you want it. What it does is it says, "This is what this is for. This is it. Now you know what it does. Now you don't have to go get help anywhere. Now you don't have to try to figure out what this button does. It's already explained for you.

So again, keeping it simple, like we did with Billings. Focus on your users. Focus on a solution to your users' needs, not a list of features. And focus on a clean and well-planned Aqua UI. Planning is everything. Get it done on paper first, make sure that you're happy with it, that your users are going to be happy with it, and then move digital. So I'd like to thank John for having me up today.

All right, that's part one. We've got to move fast. Determining your features. Once you've got all that stuff taken care of, the next question, of course, is which technologies do I use in Mac OS X, and how do I prioritize them? And I'm going to bring back something here, which I did years ago, and I still today get requests for this chart. And this is a modern version, a new 2005 version of the chart, and hopefully it's a lot more accurate than the one I did before.

But as you look at Aqua and over the overall Mac OS X user experience, you've got your thing figured out, you know what features you want to put in. Now it's like, well, okay, there's all this stuff in Mac OS X. How do I decide, do I go for address book, or do I go for, you know, font picker, or do I put, you know, standard controls? What about drag install? You know, how do you prioritize all that stuff? And I want to show you how to prioritize it with this chart, which is basically three screens.

The first screen is what I call the bare minimum. If you're bringing a product to the platform, this is the bare minimum. In other words, this is the fee you pay to get into the club. And if you're not doing these things, you're not going to win the Apple Design Awards. I'm going to be all over you, and to me it's like, well, then you're not, you don't have a finished product.

And I'll be pretty brutal about that. Use reserved keyboard shortcuts. We have a single menu bar in Mac OS X. You know, the nothing up in the menu bar with menus in the window thing doesn't cut it. MDI, like the old, the thing where you've got a parent window and you've got all the child windows constrained.

So, I'm going to be pretty brutal about that. Use reserved keyboard shortcuts. We have a single menu bar in Mac OS X. You know, the nothing up in the menu bar with menus in the window thing doesn't cut it. MDI, like the old, the thing where you've got a parent window and you've got all the child windows constrained.

Nothing more annoying than having to hide the docs so you can get that window again, right? Multi-window environment. There's all kinds of stuff about how windows are interleaved on Mac OS X. You should respect that and do the right thing. Use the proper APIs for that. Put files in the proper places. Don't throw turds all over my system, right? Put preferences in preferences. Put user double-clickable documents in my home directory documents folder, et cetera. Use standard AQA controls.

Support the clipboard. At the very minimum, every application should do these things and support cut, copy, paste.

So that's what users expect. So we've already talked about 15 things, I think. Well, what else is there? Well, you know what? Just because you do the bare minimum and what users expect, if you do that, you'll have a great app on Mac OS X.

But you know what? At the end of the day, the best products on the platform do a whole lot more. And they do a whole lot more because it differentiates them. And I want to encourage you, in terms of user experience, that it's all about surprise and delight.

So do the bare minimum. Also do what users expect. And then go above and beyond. Things like adopting sheets and drawers from for less modality, more mode-lessness, or inserted panes, the way Real Basic was doing it. Do things like Doc Icon badging. Integrate Spotlight. Spotlight plugins are great because I can find the documents I created with your product. But think about integrating Spotlight in terms of smart playlists.

What if your product had the ability to do backups, let's say, and instead of forcing the user to back up the hard drive based on the physical location of a folder or a file on the hard drive? Let the user do some kind of a Spotlight smart backup folder thing so it goes and gets all my pictures.

From a user's point of view, all they want to do is back up their pictures. Your product knows what all my pictures means. And it goes out, calls Spotlight, does an MD query, gets all this stuff, throws it into a container, and boom, backs this thing up without me, the user, having to worry about where the physical location of all my pictures is. So integrate Spotlight in terms of smart folders and that sort of thing. Internationalize for all the customers around the world. Add accessibility and voiceover if the market segment you're aiming at, which is education or for government, it's a priority. It is a criteria for purchase for them.

Integrate where appropriate. Great medical imaging product called Osiris integrates with iPod, integrates with .Mac, integrates with all of the right things to enable doctors to collaborate. If there's something your app can do above and beyond what users expect in terms of integrating with other applications. If there's something you can do above and beyond what users expect in terms of integrating with other applications, you should be doing that.

So that you address their needs and really surprise and delight them. And then of course there's the whole visual rendering of stuff on screen. So prioritize your stuff. Make sure you've got the bare minimum, then do the rest, and then go off and surprise and delight. All right. Let's get into the real meat of this stuff.

So design your user experience. Design the interface for your product. This is all about applying good techniques. The first thing which is really critical-- excuse me-- is to take-- you understand who users are now. The question is to ask, all right, well what are they thinking about when they're approaching this task? What are they thinking about when they're starting to use this product? What are the concepts and workflows and hierarchies of objects and all of the things? What are the terms they're using, and et cetera? Get a handle on these things because your main window, your main UI, the organization of your menus, the names of your utility windows, your palette windows, everything that you do should be modeled, should reflect that mental model. If I'm doing music jukebox stuff, if I'm designing a jukebox player, like iTunes, if you ask somebody what should that product have, or what are the ideas and concepts you've got, workflows, they're going to talk about playing, controls for playing the thing.

They're going to talk about collections, predominant, well-positioned in the main UI. They're going to talk about the actual tracks that they play, very, very dominate. It dominates the UI of iTunes. The main object users are thinking about is music tracks, and it's there in the interface. And lastly, some users might bring up the idea that they have to search for stuff. And so that's in the main UI interface.

But notice, there's four components to iTunes. And that models the hierarchy and the objects and the mental model that users have when they approach this product. Here's another example, iCal. Think about iCal. It's a calendaring tool. Well, you need to have the ability to have multiple calendars. So that's featured very clearly in the interface. You need to have the actual calendar itself. Well, that dominates the interface. And then you have other things like changing the month. And then simple controls. The most primary, most important, most frequently accessed controls are in the UI. That's it. That's it.

All right, what else? Another example. Connoisseur. Great recipe management tool. You think about recipe management on the computer, it's been the holy grail of software since computers started. Everybody's writing about how computers are great for recipes. Well, it seems like it's taken forever for somebody to come up with this, and this product I think comes really close.

They've got a great module for displaying the recipe instructions in huge text, so you can have your power book down on the countertop and you can be doing stuff and just look over. You're not looking at tiny text like this. But this is their navigation window, and they've got the ability to organize all of their content in these playlists.

They've taken the iTunes and iPhoto playlist model. And then when you think about recipes, well, you've got cuisine and the type of courses and the ingredients and the actual recipes themselves, and that dominates the UI. That's it. They could have approached this in a very different way, but they went about it this way, and it really works for the product. SoftRaid. Software RAID solution. When you're talking about RAID, you're talking about physical hard drives.

With hard drives with wires and power supplies, and then on those hard drives you've got logical volumes for the file system. Well, this is so dominant in the UI. It drives the point home. Hard drives there, connected to the disk menu. Left to right hierarchy of menus. So the first thing is the disk, the physical device. On that physical device I've got volumes. So those are represented in the UI very clearly.

And there's no misunderstanding by the user which logical volumes are connected to which physical drives. The UI does a great job of understanding that. The UI does a great job of driving, of supporting the user's mental model. And you need to be doing this. Every time I meet with a company to do a UI review, I talk about what's the user's mental model? How are you reflecting that in your product? And it's amazing.

We kind of do this churn, and people think about it, and they don't know what I'm talking about, and I explain it, we go through it, and eventually a light bulb goes on and they go, "Oh." And then suddenly when you get it, you realize your menus are disorganized, the whole thing just falls into place.

How many times have you looked at your product and wondered, "Where do we stick this feature? Which menu does it go in?" You know, and if that's ever occurred to you, you've got something wrong with the user mental model. Or with the way you're reflecting the real world metaphors of the user mental model.

So when you're designing your main windows, keep things simple and clean. Don't overload the user with too many controls and too many things. Think about what's the most important. Why is it on screen? What should be on screen relative to what's not on screen? In other words, if it's on the main screen, it should be something that is frequently accessed. Either every time you launch the application and the window opens, every time the project is open, let's say, or every time a selection is made. If it's highly, if it's frequently used, it should be on the main interface. If it's not, then it should be elsewhere.

Second point here is basically if it's not important and shouldn't be on the main interface, then it's a secondary item. It could be a tertiary feature. But for some reason, even though the human eye reads from top left to bottom right, in other words, the top left corner is the most important part of your application's interface, the first thing I see in so many apps is a preferences toolbar icon. It's like, well, how often do I go to preferences? I shouldn't have to go there often at all. And you've got the preference icon in the most important spot on your interface? It just doesn't make any sense.

So when you start to look at this stuff, you realize, you know what? We can get rid of half these icons. They are so infrequently used, they don't need to be there. So always ask when you're looking at this whole process, what's important now in terms of the context the user's in at that point? Anyway, there you go. Don't overload. Keep things fresh. And I'd like to bring up a last third party here, Mike Mattis, who's the designer for Delish Library, and he's going to talk about how they've done some of this stuff in their application. Thanks, John.

So I'm the president of Delicious Monster Software. I also design our icons, like this one right here. And I design our interfaces. This is the interface for Delicious Library. It's our media cataloging software. And how it works is you take a movie, or a book, or a CD, or a video game.

You hold your iSight up to the barcode on the back of it. And it scans the barcode. It goes out on the internet, downloads a ton of information about that item, and puts it into this catalog where you can browse through it. You can search. You can check stuff out to friends from your address book and keep track of all your stuff. So it's really nice.

It's a really simple interface and this is really important. We wanted to make a program that anyone could use. Not something that hardcore collectors would only like or public libraries would only use. We wanted something that anyone would appreciate and anyone who didn't even think they would like this program would pick it up and immediately see the value and have fun using it.

So our interface is made up of these five different pieces here. And each one of these pieces is like a home for our features. And each feature lives in this home with its brothers and sisters. And this way if you know one feature, you'll intuitively know where the brothers and sisters for this feature live.

It's like a... It's like in your kitchen where you have your knives and your forks next to each other and you have your spoons next to those. And so if a friend comes over one day and they want a spoon, you tell them go to this drawer and get a spoon. The next day they come over, they don't need to ask you where to get a fork because they know it lives next to the spoon intuitively. And so that's the concept behind grouping your features like this.

And so the first group we have here is the collections area. And this is where our most broad categories are stored. Stuff like just all your books, all your movies, any collections that you've made. Then we have your borrowers area where people you've added from your address book go and you can check stuff out to people right here. You just drag a book onto their name and it checks it out to them.

Then we have your bookshelf area and this is where you browse all your books. And like John was saying, this is the heart of our program. This is the star of the show right here. And in a screenshot you can just look at our program and you immediately know what the software does. Because it jumps right out of you and it's right in the center.

And then we have the details area. And this is where you view all the details about an item. And there's tabs at the bottom. There's three tabs. The first tab shows you all the information we download from the internet. The second tab, it shows you any information that you put in yourself.

You can rate an item, you can put notes, you can say if it's a rare item. And then the third tab gives you similar items so you can find new items that you want to buy. But those are all grouped under one group because they're all information about one item. John Geleynse And then we have this button bar at the bottom.

And this is where we thought really hard about each button we're going to put on here. And we really refined this. So like John was saying, we're putting only buttons that we use every single time you launch the program. And stuff that 20% of the people use, we'll put up in the menu bar, you know.

You don't need to put all those right on your interface. And another thing to note here is they're all underneath the group that they apply to. So you know when you click the edit button, it's going to edit the details. And you know when you click the edit button, it's going to edit the details.

And you know when you click the add collection button, it's going to add a collection. Some of our competition, they have a big toolbar at the top. And they dump every single one of their features into it. And it's in a total illogical order. And so you have no, when you click something over here, it does something over here. You click something here, it does something over here. With this, you click it and it does exactly what you want right above it.

So, our interface is made up of these five pieces, and I think that makes it really easy to figure out and learn and predict where features are going to be once you start learning the interface. So on top of having these groups, these groups also flow in a logical order. So when you click on Movies here, it brings up all your movies in your bookshelf.

And when you click on a movie, it brings up all the movie details in the details area. And so as you move left to right, we go from more general to more detailed, and you drill down on the information you're trying to find. And this makes it really simple for people, once again, to predict the flow of your application.

So once you click on Movies and you see all the movies appear under the bookshelf, when you click on a borrower beneath, because it's right below the collections, you'll intuitively know you're going to see all the items that are checked out to that person, right? Then our bookshelf area here, like I was saying before, it's the star of our program. It's what people first see when they launch our program and it's how people interact with the main part of our program, which is browsing all your collections. And lots of our competition looks like this.

And to us, this was really just unacceptable. It wasn't going to do it, you know? If we put this out, I think our program would have just blended in with everyone else's. It wouldn't have clicked. And it didn't click with us. You know, you look at this, and this is how you're thinking of it as a developer, right? When you're writing the software, you have all this information, all this metadata on each one of these items in a big list. And so you immediately think this is the easiest way. You just drag it in from Interface Builder and put all this information in a big table. But we immediately realized this isn't how people are used to interacting with Mac OS X. their media collections.

They just took this item off their bookshelf, scanned it, and--

So we grouped our features. People understand where to find features once they start using the program. And they're all in a predictable flow. And we use these real world metaphors. And it makes our program really easy to use, really simple. And I think we've opened this kind of product up to a much larger market now. Because it's much easier to use and people are having fun with it. So thanks a lot. I hope you guys can learn from this.

All right, lots of stuff so far. You've seen three examples of how developers have put this stuff into practice. Now we're going to get really nitty gritty. The basics. Here's a checklist that any man, any designer, any woman, any person, I call it every man's checklist, but then a bunch of little women I work with said, that's not the right name. So let's just call it The Checklist. This is The Checklist, capital The. You're going to get these slides eventually, but this checklist is what you should, anybody can do this.

You know, not everybody is a Mike, Mike Matos, right? Guy's incredibly gifted. Not everybody's an Adam Baker, incredibly gifted, you know, designer. There's lots of gifted designers, but you guys maybe are, maybe aren't. I don't know. This list is the basics. If you get this down, run through this checklist, every time you create a product, you're going to get something good. Avoid using solid black, 75% black instead. You can read the screen. Use white space effectively. I'm going to show you the specific examples.

Second part of the checklist is label properly. Do the right thing with the text on screen. Put colons after the, you know, the label preceding a control. And then we're going to show you how to align those things. Capitalize effectively. Avoid mixing text sizes, etc. I still see this stuff today, even though we've made great progress in the last five years. And last point on the last bullet was use user-centric terminology. When you've determined the mental model the customer has and their terminology, use their terms, not your terms.

Avoid mixing control styles, sizes, text sizes. Avoid overriding and changing behaviors. If a push button, if something looks like a push button, it better behave like a push button. So let's apply this checklist to some real world examples. Here's a dialogue from a real Mac OS X app. Great app. Appreciate the developer being on the platform. But there's a whole bunch of issues here. Well, you know, at first glance, you guys might say, well, it looks pretty good to me. Well, if you took the checklist I just showed earlier, for example, don't use solid black.

Here's a redundant heading, first of all, because the list already tells us what we're looking at. It tells us the name of the panel, so why put it up there again? And it's unnecessary use of black. It's this big black bar. It's like, well, that's not the look and feel of Mac OS X.

Mac OS X is much more subtle, much softer in terms of presentation of information. What else is wrong here? Well, this list actually contains a non-standard font. It's not the bolding of the headings inside of the list. The font itself doesn't match the font on the right side of the screen.

Another part of the checklist. Missing colons. I told you put colons after labels. So there's missing colons on those labels. By the way, did you even know that those were labels? Misaligned and orphaned items. I don't know what those items belong to. I don't know which checkbox they're connected with. They're just sitting out there in the middle of nowhere, and I don't know what they are.

So as a user, this is a problem. Because I glance at this dialog, and I see lots of stuff, but I don't know, it's not clearly organized. I often can't see things, even though they might be right there. And it's a concept in interface design called invisibility of items.

You don't want things to be invisible, and that's why the use of white space and margins is so important in Aqua. Because it lets you group things so that people can find them. If they can't find them, they're effectively invisible, is my point. Random non-standard spacing between controls. You notice that each of these highlighters is different sized. Just makes for a sloppy appearance.

Misuse of white space. There's just honking, I mean, just freeways of white space on this screen, right? Why is that? Lastly, random button placement. I don't know why. I don't know why, right? This is the fun part of the session. So it's just, it's, and, and, you know, I'm not picking on the developer, okay? I mean, really, we appreciate the product. We really do.

This is just a good example for illustrating some of this stuff. Margins are too small. Stuff's too close to the edges. Alright, let's look at a renovated version of that. So this is the same dialog redone. We did it here at Apple. And let's look at what's right. Proper margins. Notice the green means good. Go.

Proper font. Right aligned labels. Notice the labels are all right aligned. They all are jagged on the left, but the right side is nice and straight. Left-aligned controls. Notice they all stack up real nicely there. It looks really clean. How about spacing between items? Equal spacing between items.

larger spacing between unrelated items. Now you'll see that the thicker green bar is actually the same green bar as those upper two, but it's on either side of that white, of the gray line there. Interesting. Same spacing, but just put in there twice, and it shows you that there's two distinct portions to the screen.

and then finally we got rid of the OK cancel in fact, and we just put a close button on the window, right? Adds more modelessness to the application, less modal dialog. OK and OK cancel is fine, but in this case it was OK to do that. Here's another panel for this dialog.

Big problem here, as soon as you see repeating interface like text that repeats over and over and over, red flag, red flag, okay? You should instantly start to say to yourself, what's wrong with it? Why am I doing this? In this particular case, well anyway, we're running out of time and I don't have time to explain it, but A lot of stuff going on here and the solution was, you know, there's too much redundancy.

The solution was to kind of redesign this thing and throw in a list because the list allows for an unlimited number of items. We can actually turn on and off the item on the left with the checkbox. We can click on the row item and add--click on the plus, minus to add rows, and add the specific path by name or go and choose it from the file system. It just addressed a whole bunch of issues.

Big change. Here's another typical scenario for clean up. If you look at this screen, it looks pretty good. Sort of. But when you clean it up, you get this. Boom. New toolbar. Boom. New sidebar. Let's look at that sidebar for a second. Notice how there's the Your Computer tab. There's one tab. Don't have one tab. Tabs are supposed to have, you know. And then it's got a group box around that. And it's just like, well, isn't that just a label? Right? So let's change the toolbar again. Boom.

Sidebar. Right now it's just a label with a folder, navigation, standard awkward controls, nice clean layout of that list. And then the right side, we've got a bunch of non-standard tabs up there. Local host, local host one, some clipped controls, etc. Just a little bit sloppiness. So if we clean that up, boom. Beautiful.

All right, here's a total disaster. You know, this is a big problem. Let me talk, I mean, for one thing, the screen is blue and there's absolutely no reason for it to be blue. And this developer, I talked to them and I explained and they got it. They're going to make the changes.

But I got permission to talk about this and so I'll have to be gentle. But, you know, right side, the scroll bar up there is just going off and never, never land. I don't know what's happening there. Just a complete, I mean, look at the buttons down at the bottom.

Okay, number one, you know, number two, number three. I mean, you should not have to number anything in your interface. People should just get it. Mike gave a great example on the left side how Delicious Library moves you automatically from left to right. That's the way to design UI, not this way, you know, where you're forcing, you're labeling things so users know what to do first and second and third. And let me tell you how this works.

You first type in, this is a, you generate, you go and do a query into your whatever thing database and you get some stuff back, okay. And then you do some more stuff and anyway, I can't even explain it. Actually, I could but I'm running out of time. So anyway, you type in your report up there, the search name, you know. And then the next thing you do is you click that button so it goes out to the main window and gets some information.

And then it pours it into that screen, into that box right there. And then you go from there, you look at that and you find the keywords that you actually want to search on because you can't find them in the real, in the main interface. And so you go over to the left side here and you type in your query and so you go down and you say and, or null, null, the software is too dumb to realize you didn't type anything in the edit field so you have to tell it there's nothing in the edit field which is a, so then you type in all this stuff, then you go back up to the top and you click the find button. Then you go back down here and you click the number one button and then you go across and click number two and number three. And you have to get it that way or the thing doesn't work. You know? Yeah.

And if I could just make a note to the room director, I'm just going to go slightly over time, so fire me later. And so what we did is we took that abomination and we cleaned it up. We applied the white spacing. We made good use of white space. We put the margins around it. We put standard control. We changed all the text to the right font and everything. Looks great.

Right? It's lipstick on a pig, right? This thing is ugly. It's still ugly, and it's ugly not from a visual point of view, but it is ugly from the way it works. It is a disaster from an interaction point of view. And this is the hardest part to teach. I mean, I've run out of time here almost. And I haven't even, you know, I wasn't going to cover interaction, but I couldn't because people study this for years and years and years, but it doesn't have to be that complicated.

Interaction is like what Delicious Library did, like what Billings did, like what Real Basic did, and like what so many other developers have done. And if you think you've got some screwed up software, it's probably not this bad. And secondly, it's, you know, come see us in the Interface Design Lab. That's what we're there for, and that's what I can work with you over the course of the year for. So it might look great, but it doesn't mean it is great. All right.

And another area that you can do in terms of designing your interface, you know, we talked about main window. We talked about these dialogues and the flow of stuff and the look and feel and all this stuff. All of that's important. But another area that's really important to deliver a great user experience in your product is communicating effectively. And there are multiple ways of communicating. The first thing to understand is that this should parallel the human interaction, the human experience, right? If you have somebody reporting to you, you don't want them telling you about everything they did. Hey, boss, I went to get a coffee.

Hey, boss, got some staples for the staples. Hey, boss, stapled the report. Oh, hey, excuse me. I photocopied the report. Excuse me. I photocopied that thing for you, right? It's too much information, right? And the same thing is true for software. And actually, equally, on the human experience side, you don't want an employee, you know, you don't want to task somebody with something, and then they run off, and you never hear from them for three and a half months, and suddenly they're showing up at your office door saying, well, actually, it's not going to get done, you know? So that's too little information.

And the same thing is true with software. Sometimes software just puts up too many progress bars and too much information. I don't need to know the byte count of the transfer. I just want to know whether it's, you know, I just want to know whether it's going to take another five minutes or something. So you can communicate non-intrusively and non-interruptively. It's important to keep users informed about what's going on, but you don't have to be modal and jump in their face all the time and tell them what's going on.

And so there's some appropriate mechanism for communicating progress. A standard progress bar. A spinning gear. But just make sure you position it in a place that's consistent and near maybe what the progress, what specific is going on. So for example, the download window in Safari or the spinning gears in Mail.

You always look in the same spot to see if Mail's going to do something, or beside the inbox when it's checking Mail. iTunes has a voice level indicator. It doesn't keep putting up a modal dialogue saying your voice is at level five or your voice is at level six. It does this kind of thing. It's non-interruptive.

You can badge your dock icon. Hey, there's mail. You don't get anybody's way. The user notices the red dot. They pay attention. These are great ways to communicate status to the users. But then there are times where there are things occur, and you need to tell users specifically what's going on. The first thing is if you run into this situation, you should stop.

If you get an error in your product, you should stop and say, wait, can I redesign this thing so that the error doesn't occur in the first place? When the original Mac was being designed, there's a great story about how they were looking at the error messages that came when people would pop the floppy disk out. And so people were saving, saving, and they'd just go, oh, give me the CD.

Boom. And the thing would go, oh, error. You can't save the file because there's no floppy disk. So the designers started to think, well, no, no, no. What can we do? And can we eliminate the condition for the problem in the first place? And they ended up with the original floppy disk drive that required you to first dismount the-- it locked the thing in the drive. And so that just solved the whole problem completely.

So look to see if there's anything you can do to get rid of the condition that caused the error in the first place. But if it has to be there, because there are lots of cases where it is, you should give good error messages and explain what happened, why it happened, and what's the solution. All three of those are key variables in that formula. So for example, proper way to communicate. What happened? The trip document request cannot be saved. Why? Because the disk work stuff is full. And then the solution is that. This is the wrong way to communicate.

This is equally the wrong way to communicate. There was a problem syncing your .Mac account error code EFMS error 114. Oh, I get it. And then it says close. Close what? My .Mac account? You know, get rid of the close buttons, folks. They don't mean what users think they-- I mean, users are getting used to it because they're adapting, but quite honestly, it doesn't make any sense in light of the text on most dialogs where the close button is.

Good one. Feedback error. It's just a funny joke. Come on. So this is poor communication, but it's okay. I mean, you know, I wouldn't get you too bad. It's an error message. This is better. Same error, but a little bit more text. And finally, this is the best way to communicate. So that's designing the interface. It all matters because it generates high customer productivity when your product works the way they expect and delivers the experience they want. You get customer satisfaction because they love it.

You get great perceived value from your customer base. There's lower cost of customer support. Costs you money to answer the phone and address stupid problems that your product could have addressed and gotten rid of. Faster and simpler implementation. If it's easy and simple and focused solution, you've got less code to write. It's competitive advantage, all things being equal. One library management, media management product against delicious library. Delicious library wins, right? Why? Because they went above and beyond, surprised and delighted, integrated all the other stuff.

Brand loyalty, simpler manuals and online help. And there you are. Online is the interface documents, Mac OS X human interface guidelines, Apple University guidelines. Please send me email, set up a meeting with me either at the conference or after the show. Come see us at the Interface Design Lab. Sign up for time. May you have a great week. Look forward to great products from you. Thank you.