Ladies and gentlemen, please welcome Manager of Software Evangelism, Tim Holmes. Hi. Welcome. I hope it's been a good show for you so far. So you've gone over the design concepts for UE, and those are broad and those are important and they're critical for your understanding of how to make an application on the Macintosh.

This session is going to be about adopting Aqua, and that's implementing those design concepts through the tools and controls we give you. This is really critical stuff. This is stuff that if you're not on our platform today and are moving to our platform, you really need to understand to have a successful product. To have a real sellable product.

And it's also critical for our platform because one of the key advantages of the Macintosh is the consistency of controls, consistency of usage, and being able to understand where you are and what you need to do to get something done no matter what application you're in. So I'd like to introduce John Geleynsse.

John Geleynsse is our user experience evangelist. Someone who's familiar to you all, I think, probably. And if he's not, you should get to know him. You should give him a call. Come on up, John. He does quite a few reviews of people's products, and if he hasn't reviewed yours yet, you should get in touch with him. you get in touch with him. So thank you, Tim. Have a good session.

Okay, well, there I am. That's the nickname people have started to give me in the developer community. Alright, I want to talk in this session, carry on from session one, and I want to talk now about how do you take those principles and adopt them specific to your application on Mac OS X. And we're going to get really practical, and basically we're going to come around to discovering what it takes to create a really great citizen application in the environment of Aqua.

And to do that, I want to first define the term citizenship, help you understand what I mean by that term, because I'm going to use it over and over through this session. Then I want to look at what the benefits are to you as you bring your product to Mac OS X and you do some of the things that we talk about today.

Then we'll look at some of the detailed steps that you need to take as you adopt Aqua. And finally, I want to finish with some testimonials from some of your peers who have made the choice to adopt Aqua completely. And they'll talk about that whole process and talk about the benefits that they've seen, etc. And so it's really not only just Apple talking about the benefits here, but it's your peers who have gone through the process of adopting Aqua. And they've gone through the very same experiences that you're going through right now as you bring your product to the platform.

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

As I said, I want to talk about the definition of citizenship first of all. And when I use this term, I use it loosely in terms of the real definition of citizenship, obviously. But I think it's one of the best terms to use to help you understand what it means to belong in this world of Mac OS X. So to start, I want to talk about the first sentence, focusing on the first sentence, and specifically focusing on the fact that a citizen actually has benefits for being a citizen of the land in which they're part of, or the nation in which they're part of.

In this case, it's your software that's within the nation of Mac OS X or in the world of Mac OS X. So what are the benefits that you realize by creating a really great, compelling product on Mac OS X, and a product that implements the principles we talked about in session one? Well, Stan went over some of these, so I'm not going to go into great detail. But fundamentally, the benefits boil down to two. And the two are, make more money and have a competitive advantage.

If you're reducing your tech support costs, you're simplifying your documentation, your product is highly usable, and your customers are tremendously satisfied with it because they're achieving what they set out to achieve, and your product is actually solving the problem it's supposed to solve in a very focused, simple way, the outcome is going to be upgrades, more customers, satisfied customers, all of that turns into money and a competitive advantage. All things being equal, if your product does the same thing a competitor's does, but yet you knock it out of the park from a user experience point of view, you're the winner.

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

And the appearance of Mac OS X. Does your application follow that appearance and adhere to that appearance? So what are the basics? By the basics I mean, and these are basics that aren't even specific to Aqua so much as they are specific to the Macintosh. What does it take to make a, you know, what are the characteristics of a Macintosh application? And believe it or not, there are violations of these and we'll have a lot of fun looking at some of them. So I want to start with one of the most basic characteristics of a Mac application. And that is that the application has menus, right? And that the menus are structured in the proper format.

And the menu layout for Mac OS X is such that if we're starting on the very left, we have the Apple menu, which is system global. It's for commands that relate to the system. It is, it enables the user to do stuff to the system regardless of what context they're in, regardless of what application they're running. They can sleep the system or do whatever, you know, go to system preferences. And the Apple menu is really not for application developers.

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

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

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

And following the application-specific menus, we've got the window menu and the help menu. The window menu in Jaguar, in fact, contains some new functionality, which is the ability to cycle through your active document windows using command-tilde on the keyboard. And the help menu is where you would put your access to your help book and your user assistance, your online help. As we're talking about menus, I want to talk about another fundamental basic for a Macintosh application.

And that is respecting or adhering to the reserved keyboard equivalents that we've set out in the Aqua human interface guidelines. We all use the Mac. We're all used to, without even thinking, doing command-s to save, you know, printing, cut, copy, paste, undo, all of these things. We don't even think about it.

Our hands just go down to the keyboard and we do the appropriate keyboard equivalent, right? Here we've got an example of a shipping application on 10 that has completely ignored these guidelines. And the effect is... that if I start to use this application as a user, I start to use those familiar keyboard equivalents, right? And I'm going to be stymied because it's going to do things that are completely beyond what I would have expected it to do.

And in session one we talked about expectations. And suddenly I'm going to use this product and now it behaves in a way that's very different than what I expected it to do. We've got command P for preview, A, which should be select all, does something else, S, does scan instead of save, etc.

So as you bring your application to Mac OS X, if you're coming from Windows or Java, there are many of you that are doing that. Even if you're writing custom in-house applications, it's important to use the reserved command keys in the appropriate manner. Because it means that as users move from your application to another or from another to yours, some of these basic behaviors are going to be there. And they're going to have this level of consistency between the usage of the applications. And it'll mean that they're very comfortable.

Another basic thing that your application should do is have your windows appear and operate the way other windows appear and operate in the system. Mac OS X introduces this layering model of interleaved windows between applications, and windows have a unique appearance, they minimize to the dock, etc. Your windows should behave the same way. The only constraint in the world of Mac OS X is the desktop. The Mac OS X desktop might span multiple monitors, but they are constrained in that area.

However, there are applications that are being brought to Mac OS X John Geleynse, Greg Dow, Stuart DeSpain, Ivor Clarke very different behavior and suddenly the user is faced with a situation that's, you know, very foreign to them in terms of how the overall system works. So the right way for this to be done on Mac OS X would be to drop the MDI interface and basically put those document windows on the overall desktop and let them behave like any other standard document window.

And if you're a Java developer and this is an issue for you, there's documentation on our developer website, I believe, certainly contact developer technical support to get assistance with that. Contact me, we'll give you the assistance you need to solve this problem because it is solvable. And I don't mean to say that Java developers are the only ones doing this. There are other people who are doing this occasionally as well.

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

There are instances where that is necessary, and so I would encourage you to work with me to get an understanding of that so that I can champion that for you within engineering. But building upon the standard system controls means you're going to get the right appearance for one thing. But secondly, you're going to inherit for free much of the behavior that we're talking about in terms of universal access. So the keyboard navigation will come for free.

Speaking back of the items below the mouse will come for free. You know, focus rings, all that will come for free provided you use the standard system controls. If you don't use the system controls but draw controls yourself using Appearance Manager, for example, in Carbon, it means you're going to have a little... not only a little, but in some cases, you're going to have a lot more work to do to implement the same behaviors that you could get for free. So I encourage you to use standard system controls wherever possible.

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

All right, honoring default folders. Another real basic for an application coming to Mac OS X. Every logged in user on Mac OS X has their home directory. That home directory contains default locations for storing music and pictures, you know, everything that's listed there, movies, et cetera. If your application is a content creating application, you should default to the appropriate location for saving documents from within your product. And while we're on this topic, let's talk about the documents folder, which is part of every logged in user's home directory. The documents folder is another area where we're seeing some difficulty with applications. It is reserved exclusively for documents that users create.

So where a user is inside of a document in your application and says save and puts it in the documents folder, that's the document that they explicitly created. Everything else that's related to your application, that's sort of vaguely user created in the sense that it might be a mail database or it's a contacts database or it's some other thing that you really-- is necessary for application support does not belong in the documents folder. It should be put in the library directory, library folder.

So--and the side--sort of side issue on that is training your users through your documentation or through tech support, et cetera, that if they back up their world on Mac OS X, they need to back up more than just their documents folder. They need to back up their whole home directory because it contains preferences, it contains application support files that are important, important, and it also as well contains their documents.

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

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

First of all, every application on the platform-- and this is almost a basic, but I didn't put it in that section-- every application on the platform should respond to doc clicks appropriately. If your application icon is clicked in the doc, you should always produce a window. If you're a document-based application, bring forward a new untitled document if there are no documents currently open in your application.

If you're a document-based application, but all of your document windows are currently minimized to the doc, then you should bring up the last minimized document window, because that's likely the one the user was-- that's the one they were last working in. That's likely the one they probably want to work in now. And if you're a non-document-based application, say you're in iTunes or a system prefs or something like that where you have a main window, then if that window is currently closed but your app is running, you should bring that window up and activate it.

Respecting the doc's location. As I said before, the doc can be at the bottom of the screen or on the left or the right. Who knows where it'll be in the future? I don't know. I'm not on the design team, but who knows? At the moment, it's in these locations. And as your application windows, as you open new untitled document windows or as the user resizes document windows, you should always honor the doc's position and never allow the user to resize their window behind the doc or never automatically resize a new untitled window behind the doc.

And so in this particular example, you'll see here's a document window from IE that your window should open flush to the menu bar at the top and flush to the doc if it's on the bottom or flush to the bottom of the screen if the doc isn't on the bottom of the screen.

The APIs for that are pretty straightforward. But remember, the users can change the dock's location. They can also change the dock's size. So if they've sized their window and you've honored the dock, and afterwards they resize the dock to cover the grow box from the window, let them do that. Don't resize your windows and move windows around based on the movement of the dock. Once the users set the window size there, and if they change the dock, that's their choice. Let them change their environment without adapting to it.

Something some applications should do is provide meaningful status information via the doc. We talked about this a little bit in session one. I'm going to talk briefly about it here. But the idea is, if there's meaningful information you can provide to your users about the progress of your application, doing something it's doing, or if you're a fax application and you're sending a fax in the background or receiving a fax, providing that kind of status information or progress information through your doc icon is really meaningful and very subtle and yet very effective at communicating what's going on.

So for example, with the mail icon in Mac OS X, we badge it with a starburst that says, "Hey, there's new mail." And if it's sitting down in the doc and your doc is visible, you see that and it's a really cool cue, very soft cue, saying, "There's new mail." And so you don't have to switch the app to look whether there's new mail. So that's an example of what we're talking about here. Providing meaningful status information through your doc icon.

And again, I would say, think very carefully about when you do this. The last thing you want to have is the doc, you know, animating or having all kinds of status stuff occurring constantly. But where appropriate, it's very, very valuable. And to do this through Carbon, it's just look for the APIs with "doctile," the terms "doctile" in them, in those header files. In Cocoa, it's "nsApplication," "setApplicationIcon." Okay, another behavior that's very specific to Mac OS X that's very cool and very visible to product reviewers and to customers alike is Sheets. Sheets are document modal specific dialogues. Use them wherever you have a dialogue box whose contents affect the currently active document.

So think about your product for a minute. Do you have active documents? Do you have document windows? Yes. Do you have modal dialogues that currently open up to affect the contents of that document? If the answer is yes, those are candidates for Sheets. And the cool thing about Sheets is they really implement the principle of modelessness well because they attach themselves to the document title bar of that window.

They move with that document around, so they're clearly associated with the content that they affect. And yet, they allow you to continue working in that application on other documents. So they're only modal to that application. Not modal to the whole application. To that document, rather. Not modal to the whole application.

Another way that we've implemented motorlessness in Mac OS X is drawers. Again, we touched on some of this content in session one, but drawers are great for providing often used controls that don't need to be visible all the time. They're also great for enabling you to provide additional functionality closely related to the parent window. So it's really not a sheet because it's not a case where you go and you do it all the time and then you dismiss it.

But drawers are there for stuff that just sort of hangs around that's sometimes meaningful to be there, but sometimes it's not meaningful or not, you know, effective to be there necessarily. But it's great to have it there because you can pull it out, do something you need to do, and push it back.

So think about where you do that kind of stuff and where this could be useful and implement drawers. I have the pleasure of announcing that Carbon drawers are now available, effective in Jaguar. And in the headers, macwindows.h, just look for APIs that have the word drawers in them. And this is a big deal for Carbon developers who have been waiting a long time for this. So there's no excuse to not implement it. into the drawers now.

Another behavior of Mac OS X is Apple Help. Apple Help is this really effective way of delivering help content to your users in a very rich manner. QuickTime is integrated, AppleScript is integrated, so your users can read through your help and say, "Well, okay, show me," and you can control your application through an AppleScript. It's a really great way to deliver rich help content.

And we've actually extended Apple Help in Jaguar to build on its ability to deal with remote content. So where we are currently with Mac OS X One is that Apple Help can support remote content. So you know how you're developing your product and you run out of, basically the development team is still working on some stuff, but you've got to freeze the help content. And yet you want to document the stuff, but it's still changing. And so anyway, we all understand that situation. Apple Help lets you put some of this help content out on one of your servers and go get it.

The beautiful thing about Apple Help in Jaguar is that now you don't need to know what the structure of that help content is necessarily, because we retrieve the remote index as well. So now you can add and remove help pages on the fly as you change your system or as you understand or realize that your help content could be restructured or something. So really great feature in Apple Help now in Jaguar. Second thing is that Apple Help in Jaguar is internet primary.

In other words, it's going to look to the internet for remote content under the assumption that the remote content is more up to date than the current local files that you installed with your product. So leveraging both of these means that you can do a lot of things. So leveraging both of these means you can really deliver great, really flexible help.

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

Choosing colors is always a complicated process just by its very nature. And we've provided the system colors window in Mac OS X that up until this point has only been available to Carbon. It's a Cocoa, sorry. It's now available to Carbon in Jaguar. And the beauty of it is that it provides a consistent user experience across frameworks for picking colors.

If your application allows users to choose colors in any way, whether it's for, you know, coloring text or some background or whatever it does, don't do your own color picker. The difficulty with doing your own color picker is, means that it behaves differently. The user comes to it with an expectation about how it's going to behave because you might have used the standard, you know, control to get there. And suddenly what's revealed is something very different. It behaves different than what they're used to. And the system colors window is the way to provide for color picking on Mac OS X.

File name extensions are on Mac OS X. They're a way of enhancing the file name to improve interoperability with other platforms. We have specific goals around providing file name extensions. The thing I want to talk about is that our goal with this is to maintain the usability of the Macintosh, or that the Macintosh is always known.

And so when file name extensions are entered by the user, it's basically a what you see is what you get kind of behavior. So if the user types an extension on the file, a file name extension, that file shows up with a file name extension. If they don't type the file name extension, it doesn't have a file name extension. It's appended by the application.

Specifically as it relates to user experience, I want to talk about The fact that there are display names. File names aren't only what the file system tells you they are anymore. So historically you could say to the file system, what's the file name, or what did the user choose, and you'd get a name back.

Now, pay attention to Nav Services, what it tells you in terms of the file extension being hidden or not. It's going to give you that bit. It's also going to give you the full file name. And so if it's hidden, show just the main file name. The save panels will do that appropriately.

But wherever you display a file name in your application, say you've got a list of files, or you're providing detailed status information about a file, make sure that you display the users, the display name for that file. The user is explicitly chosen to either hide or show the file name extension. Your application should honor that.

So if I have a document called lettertomom.txt, but I've hidden the extension, and as far as I'm concerned it's just called lettertomom, when I double click that document and it opens up in the application, the document title bar should say lettertomom, not lettertomom.txt. So the APIs to use are in Launch Services, lscopyDisplayNameForRef, lscopyDisplayNameForURL. These are the APIs you should be using to get the display name for a file.

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

Managing Contacts. Today, we all run multiple applications, we all run multiple tools, and the reality is that if those applications require a phone number or an email address or whatever, we rely on that application to manage those contacts. I'm sure all of you have experienced the case where you're using an email program and you've got all of your contacts in there for their emails, but then you've got another personal information management tool, or you've got some other thing where you're doing mail merge or whatever, and all three of those products or more are pulling from different databases for contacts.

Wouldn't it be great if all of those applications used the same source of information? So regardless of whether I was sending an email or sending a fax or doing some other operation on my machine with some other product, that all of the context would come from the same place.

It's possible with Jaguar. Because with Jaguar, we're introducing something called Address Book Framework. It's a very simple framework available to Carbon and Cocoa that enables you to build on a standard, single, centralized database in the system to manage people, the contacts around, and the information around people. So in terms of delivering a great user experience with your product, and in terms of being a great citizen on Mac OS X, this is one of the things that you should consider building into your application.

Not only does it deliver a great user experience, but it means that you can focus on the value add that your product provides, which is the unique capabilities that it has, versus, "Oh, yeah, we've got to write this context thing and deal with all the UI around that and all the database management," right? Take your development cycles and put them on the things that are unique to your company, the value add you bring, rather than trying to write a lot of stuff that everybody else is trying to write and ultimately confusing and diluting the user experience for that stuff.

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

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

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

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

The right way to draw text, it depends on which framework you're using. There are ways to do it properly in Power Plant. There are ways, certainly Carbon has multiple ways of doing it, but if you're writing directly to the toolbox, using the Appearance Manager APIs, like Draw Theme Text, etc., are going to mean that your labels, etc., are appearing properly.

Using standard system controls are going to mean that your controls, the labels are drawn by the system, so they're automatically going to appear in the appropriate font face and size. So anti-aliased text really matters. And if you have content text views within your documents, consider using MLTE views or the ATSUI engine, which there are sessions about here at WWC.

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

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

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

The other guidance I would give around that is that it's, it's, use it only, use the metal appearance only for your main window. So if you think about iTunes again, or if you're, if you've got a PowerBook sitting in front of you right now, fire up iTunes, take a look at iTunes.

It opens, there are other dialogues in iTunes for preferences, etc., but those dialogues are fully Aqua. They're not metal. So if you're going to use the metal window appearance, use it for the main window only. And all of your other dialogues, supporting dialogues within your application should be Aqua.

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

Palette, layout, and appearance. There are tons of applications today that ship on the Macintosh that have palettes. And there are lots of high-end illustration tools and web design tools and lots of applications that use palettes. Because the cool thing about palettes is they remain on screen all the time. They're easily accessible to the user, therefore.

They don't take up much real estate. And so your application, if you deliver palettes within your application, should adhere to these kinds of guidelines as well. Make judicious use of real estate. You don't want to take up lots of room. You want to use smaller spacings and tighten things up.

But at the same time, you don't want to do something like this, which is-- They've used standard controls. Everything is truly Aqua. The difficulty here is things are kind of compressed and it seems somewhat messy. So remember, if you're bringing things down in size, to continue using the small version of Aqua controls, but also remember to focus on the alignments and the overall layout of the palette.

So what would this look like if it was adhering to the Aqua layout guidelines? We've got more alignment of controls. We've reduced redundancy in labels that were there. We've used verticals or horizontal separators to distinguish sections of this palette. So it's pretty simple stuff, but again, a beautiful tool to do this around, or a beautiful tool to use to do this is Interface Builder.

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

They've chosen to use Carbon because it's easier. And there's just some real difficulties here, and I wanted to point these out specifically. Here I've got a dialog that's got, has no respect for the margins that we define in the Aqua guidelines, so the tab panes are very close to the edges.

We've got multiple tab rows, although the second row is really an inner tab pane, which is okay to do. We do it in System Preferences. But certainly it should be spaced downwards and then inwards so that you know that it's a separate tab pane within a larger tab pane. The buttons at the bottom are being obscured by shadowing, so there's over-compositing there of the tab panes. All of the text in the dialog is non-antelious, and it's all Geneva 9. It's hard-coded font faces and sizes. And I see this a lot as I review applications.

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

Spend the time to make a really great interface on top of it, to put a really great Aqua-compliant interface that leverages sheets and drawers and speech and all of the stuff that we're talking about today to really create a killer application. Because then the users look at it and they go, wow, this is great, and look what it does. Most users really are not concerned about what your product does. I mean, they are concerned about that, but primarily they're concerned with how it does it.

What differentiates you from your competition is ease of use. Think about iMovie. Before iMovie was on the scene, it was really hard to just pick up and edit a video. We spent a lot of time thinking about the interface around iMovie and how do we, you know, who are users? What are they doing? Remember we talked about this stuff in session one.

Who are users? What are they doing? What do they need to accomplish? Simplify, simplify, simplify to the point where we've got this iMovie thing that people are just looking at as an example and a benchmark for creating really highly usable consumer-oriented products. Don't let your interface knock you down in terms of the judgment your users render upon you. You spend a lot of time in your code.

Group boxes. Aqua has a very distinct appearance in Aqua, and we encourage the use of white space. We have margins in dialogs. We encourage spacing between groups of items or a single separator bar. And group boxes are still available in the toolbox. You can still do them. You can define them in Interface Builder, etc.

But I want to encourage you to think about moving away from group boxes wherever you can. Moving away from them means your interface is going to feel lighter. It's going to feel cleaner. You can actually drop the side and the bottom lines from group boxes and have the very same effect where you have stacked group boxes. So here we've got a UI on 10. It's pretty good.

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

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

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

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

Aqua provides for a very rich graphical environment. However, overuse of color and things too tight together mean that it's just too visually stimulating. So in this case, I don't know, there's just too much going on even though it's fully compliant with the appearance of Mac OS X. The appearance for toolbars in Mac OS X is a very clean approach, and the icons we use are high quality in terms of their rendering. The icons we provide are shortcuts to things that are multiple clicks away, and so consider very carefully what you put in your toolbars. Don't put every function of your application as an icon, represented as an icon in your toolbar. You'll just have overpopulation of your toolbars.

Focus specifically on those things that dramatically increase the productivity of your users. And I'm pleased to announce that, as of Jaguar, the toolbar control is now available in Carbon. So Carbon apps can deliver a real system toolbar just like Mail or just like other Cocoa applications you've seen, including the configure sheet and all of that behavior. That all comes for free. If you're a Carbon developer and you're doing toolbars, you need to be leveraging the new control that's available in Jaguar.

So as you sit there and you listen to this, maybe you're at last year's session and you've read the book or whatever, maybe you haven't, you sort of sit and you go, help, I can't do this stuff. I don't know, I'm just a programmer or, you know, I don't know.

I want to just present four resources that are available to you. And the first thing is an update to Power Plant that's going to dramatically improve the appearance of your product if it's Power Plant based. And to do that, I want to introduce Greg Dow from MetroWorks to talk through some of the changes there. Greg? Hi, I'm Greg Dow, the Chief Architect of PowerPlant for MetroWorks.

Just want to give you a few tips here to help you be a good citizen as John has described. PowerPlant, one of its benefits is that it's started back in the system seven days and it's maintained compatibility with each OS. However, because of that compatibility, it's sometimes easy to get lazy and not update your user interface for each system.

And so, if you have a program now that's running on Mac OS 9, it's actually pretty easy to just flip the switch, make it a Carbon application, and have it run on Mac OS X. However, it's not going to look right and it's not going to be a good citizen. And here are just a few quick tips.

Here are just a few quick tips of what you can do to quickly update your Power Plant applications to have an Aqua-savvy appearance. First, make a new menu bar for Mac OS X. On Aqua interfaces, there's the application menu that automatically puts a quit item and a preferences item there. On Mac OS 9 applications, you probably had your quit item in your file menu, and if you had a preferences item, it was probably at the bottom of your edit menu.

If you don't update your menu bar, when you port your application to Mac OS X, those items will appear twice. You'll have two quit items, and you'll have two preferences items in your menu bar. Both items will still work, but it looks sloppy and not polished, and you won't be a good citizen.

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

and use the Aqua Savvy classes. So, there's a little bit of discrepancy here in terminology between what John mentioned. When John talked about standard controls, he meant the controls provided by the toolbox. Power Plant, because it's been around for so long, when it refers to standard controls, it means the System 7 controls. You had four controls back then. You had a button, checkbox, radio button, pop-up menu, and that was it.

When the Appearance Manager came out, Power Plant introduced a whole slew of new classes for using the appearance controls. Those are the controls you should be using. You should not be using the standard button on Power Plant. You should be using the Appearance Manager push button, et cetera.

Similarly for text, Power Plant provided a caption text that used drawing via Quick Draw calls. Don't use that on Aqua. Use either the static text control or the theme text box so that you get proper anti-alias text. And if you want to use anti-alias text also in your edited text boxes, use the MLTE pane rather than the text edit based.

Now I just want to show a quick demo here of two applications. One that was just quickly ported over to Carbon.

Just as a side-by-side comparison now, if I bring up an Aqua Aware program here, now we have the file menu. Oops. I'll skip there. The File menu with no quit item. Edit menu has no preferences item. We bring up preferences here from the Application menu.

And here, The interface has been aquified. Here we have the nice striped background. And if you want to notice some other subtle bugs here, you can see the non-aquified application. Actually, your button is pulsing here in the background. This is the disabled window, but because these are stupid System 7 controls, they don't know to properly disable themselves, so they continue to flash, and it continues to be active text here.

Whereas if I click off over here, you see everything properly dims out over here on the aquified interface. Another point that something different that happened in Power Plant that some people have tripped up on is when you use the static text control, the control manager automatically erases to the background. In this case, you get the gray striped background here.

And if you're drawing your text over a picture, well, you probably don't want that. What you want to use is the theme text box. This still draws anti-alias text, but it doesn't do the erase before you draw. So if you actually want to draw text, you can do that by clicking on the text box.

So if you're drawing your text over a background, use the theme text drawing box instead of a static text control. Another point here, although it's not obvious visually, is something that Apple has recommended, is that the title of your pop-up menu should actually not use the title of the pop-up menu control.

You should actually create your title for the pop-up using a separate, either a static text control or a theme text box drawing, so that the two are independent. It has to do with the appearance and dimming, because if I actually made this the title, it actually wouldn't dim here properly when I deactivated the window. So that's just another quick tip there to get your applications looking right on Aqua. And that's it for me right now. I'm going to switch it over back to John here. So go out and aquify your Powerpoint applications. Great. Thank you, Greg. That's fine.

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

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

Third resource available to you to help you create a great application that knocks it out of the park from a user experience point of view and from an appearance, adherence point of view, etc. is the Human Interface Guidelines. This book is constantly being revised. We've got another revision coming specific to Jaguar. We'll talk about where to use ComboBox.

We'll talk about universal access. We'll talk about speech, where to use speech. We've got a lot of new content and just encourage you to look at this book and read it and review it and reference it. Make sure it's available to the people who are designing the user interfaces for your product.

And the fourth thing is Apple's interface design tool of choice is Interface Builder. Interface Builder, if you've never seen this, is an incredible product for creating the interface on your application. And I consistently run into developers who've never seen Interface Builder. They're a Carbon developer, or they're even a Java developer. They've never even heard of it, or if they heard of it, they didn't realize what it would do.

Interface Builder provides this drag and drop metaphor for dragging buttons and UI elements onto Windows. And as you drag them and move them around, you get guidelines, guides that appear automatically that tell you where to put that button if it's going to be in the bottom right corner, or where to put that tab pane, and how big should it be sized to respect the margins around a window and stuff. If you've never seen Interface Builder, go to session 904, I believe it is, which demonstrates IB and shows you how to use it.

And if you are using it today to prototype your product or to layout your UI, consider taking the extra step if you're a Carbon app, for example, and leveraging nib files instead of being resource file based or using some other mechanism for defining the layout of your windows. Consider using the Carbon APIs to read in nib files, which means you'll be able to use IB to create your UI and then read those files in and use them to display your interface.

Let's go back to the definition of citizenship. We looked at the first sentence and we talked about the benefits that are available to you if you create a really compelling product on Mac OS X. It's not enough to just bring your code to Mac OS X and then sort of ship it.

It is enough, or it's, it's, it's, it's, the thing to do is to move beyond that, to go beyond just the basics, beyond just porting your product to the platform. It's really a question about going way beyond those basics and leveraging and implementing all of the other stuff we've talked about today and a whole lot more which we didn't have time to talk about. But I want to talk about now the other part of this definition which is the conduct as a citizen.

And in this case, I want to bring up three of your peers to share their experiences adopting Aqua and the process that they went through as they looked at Mac OS X for the first time and looked at their current product and decided how would they bring that product to Mac OS X.

And I think hearing their experiences will be very educational for you just in understanding that other people are going through the same things you're going through and also learning some of the thought processes that they went through that you might be able to employ for yourself. So to start off with, I want to introduce Stuart DeSpain from Microsoft to talk about their process with the Office 10 product on Mac OS X. Please stand. One moment. Is it back? Okay, I'm back.

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

In terms of low visibility features that we knew were helpful, the view switcher. PowerPoint and Word both have a view switcher that changes modes to allow you to do different kinds of work activities. Sadly, they were kind of buried in the bottom left corner of the document window, and they're kind of hard to find. So in 10, we brought in a finder-like view switcher that punches those features out. People can see right away, there are big clickable buttons down there, and they're much more successful at finding that feature.

We even wanted to bring Aqua to our product icons, though. We're definitely enhancing usability, but we want things to look great. We want people to know that this is a new suite of applications under a new operating system, and we changed our icons so they had more depth and were more exciting, more new, more fresh.

But beyond the static visuals, we wanted to take that language step a little bit further. So we introduced animation. Now, the formatting palette was something we introduced in Office 2001 as well. Again, very popular feature and we're very happy with it. But we have a slight problem if people were trying to manage their windows, there was a case where people would hide the formatting palette because it was in their way and then they couldn't find out where it went, as you can see here. So in Office 10, we introduced animation so that when people close the formatting palette, it genies into a toolbar and then genies back out.

And this has greatly enhanced the discoverability. We've also enhanced the formatting palette with other animations, for example, when you close and hide panes, and there's a lot more fun stuff we can do in the future. Aqua also gave us the opportunity to redefine our dialogues. You've seen a lot of examples today about dialogues that didn't quite make sense and, well, this is one of ours. This is the FillFX dialogue.

Kind of hard to follow. When we were moving over to 10, we were also bringing in new features. So we took this as a good opportunity to change the look of the dialogue so that it had a better flow. We didn't just aqua-fied it. To a many extents, we ma-ca-fied it so it was much more usable.

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

We had to use a lot of different methods to create a much, much better chart. So, have we been successful? Well, the San Jose Mercury News thought we were the best looking piece of software they had ever seen. From Wired, they thought we were so pretty they didn't believe we were real.

Steve Jobs asked for a round of applause and said that Apple was thrilled with the application, and we're thrilled to hear that. So, have we been successful? Well, there's been a payoff. Eight hundred dialogues later, five hundred icons later, we have a great looking product, and we're very proud of it. And the reviews have been very motivational, certainly for our team.

It's great to get up in the morning and fire up your browser and read these great reviews from people who really enjoy the work you're doing, and then they're getting to use your product and enjoying it even more. And, of course, it translates into sales. The more people are excited about your product, the more they're going to want to go out and try it, especially as momentum builds more and more and more behind OS X and, hopefully, Office 10 along with it.

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

Next, I'd like to invite on stage Ivor Clarke, who's president of Simple Factors, a design agency working with a company called Media Maker. Thanks, John. So as John said, my name's Ivor Clarke. I'm president of Simple Factors. I'm here to talk to you a little bit about the work my company did with MeetingMaker. First of all, a little bit of background.

MeetingMaker, for those of you who don't know, is a collaborative scheduling application. It's been around for a fair amount of time. It's about 12 years old. They're on version 7. It's one of the original applications. There's a lot of stuff that's been hanging around there. And they're now engaged in a two-part release strategy for OS X.

The first is to get out a version that is carbonized, works on OS X, gets full functionality. It's what everyone's been clamoring for. And the second is to really take advantage of it and knock -- take advantage of Aqua, take advantage of the operating system, and really knock a release out of the park. The first portion of that was released just a couple weeks ago. That's version 7.1.

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

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

It's also an opportunity for bigger changes. As you're going in, making the changes to make a great looking application, making the changes to take advantage of Aqua, you have the opportunity to really get in there and reevaluate some of the ways you present your user interface. As I said, Meeting Maker had been around for 12 years.

This was an opportunity for us to go in and ask ourselves, were we really doing some of the right things with the fundamentals of the application? And finally, other platforms. There are some other platforms out there. Meeting Maker ports to them. And they are also, some of them, starting to put an emphasis on the visuals of the applications. And trust me, the work you do to create a great-looking Aqua app will not be lost when you move to other platforms.

So where did we focus? We didn't work to take the list of Aqua features and just sort of make a checklist. Instead, we said, well, what is Aqua about? There are a couple things. First of all, look and feel. I think this is what most people associate with Aqua. It's that high production value, great presentation.

But it's more than that. It's more than just pulsating buttons. It's also a way to improve feedback for the user. When you look at the Dock, the Genie effect, Sheets, all of those are ways to tie what's going on in the system to an action that the user has taken. And it really helps reinforce those actions for the user. And finally, information presentation.

One of the reasons Aqua looks great is because it does a great job of presenting the user's information. If you take a look at the column view in the finder, that's the same type of information shown in the list view or finder view, but they've taken the opportunity to find a better way to present that information, and I think it's what many people are finding the most useful.

So I want to walk through a couple examples. This is the contact window. And when we were looking at aquifying it, there's nothing fundamentally wrong with this. You can see everything. We could have just put a striped background behind it and called it done. But we wanted to do a little bit more than that.

And this really goes to improving information presentation. Rather than just changing all the controls, we also looked at how the information was organized. We looked at how it was presented. And what we ended up with is something that not only looks a lot better under OS X, but it does a much better job of presenting the information and becomes more usable.

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

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

So this is the schedule window. The schedule window is used to Pick a time for your meeting based on your guests' availability. So if you see that red stripe on the left-hand side, that's the availability of all your users. It shows when they're all busy or when they're all free. Well, that can be a little limiting when you're trying to make a decision about when to have a meeting.

So when we redesigned it, not only did we use Apple's dialog layout guidelines, use new controls, make sure the presentation was right, but we also added extra information. Now you can see on a case-by-case basis whether a user is available. You'll also notice that yellow transparent stripe, that shows your chosen meeting time. We took advantage of some OS X technologies to use transparency to improve the ability to see whether the meeting time you've chosen conflicts with anyone. Thank you.

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

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

And customers are really, really liking what we're showing them. They see we're taking Aqua seriously. They see we're taking OS X seriously. And they also see us really putting an emphasis on what's important to them. I mean, administrators are the people who have to take care of this in an organization, so it can cost them a lot of money if the product's hard to use.

They see us taking usability of the product seriously, and they really like what we're doing. That's pretty much all I've got, and I'll hand it back over to John. Great, thank you Ivor. And the last testimonial, so to speak, comes from Microtech, and I'd like to introduce Kristen Lee to talk about their experiences. Hey Kristen.

Hi, my name is Kristen Lee. I am Marketing Project Manager for Microtech. We manufacture consumer and professional scanners and also develop the software that controls them. We have a little bit different story. Our initial plan for releasing our professional scanner, or scanning software, was to port it to Carbon, add Aqua icons to it, and ship it.

While this made sense for us, we have a very complex UI, and we were able to save time and resources for engineering, and we would also be able to reuse our documentation for Mac OS 9. But, last September, we attended an Apple Design Kitchen, and in just a few hours of working with Apple, we really realized what a benefit applying the Aqua guidelines was going to make for us. So, we went to the other extreme. We took full advantage of the opportunity.

We took our application, which historically has had a truly Windows look and feel, and created a unique Macintosh interface. We also took the chance to update and reposition our software to a true high-end scanning solution for photographers and graphics pros. We went from ScanWizard Pro 6 to the new ScanWizard Pro 8. We have a new, well, not new, but a new, well-designed, ScanWizard Pro 6, with a cluttered, haphazard look and feel, bitmap, jaggy icon. ScanWizard Pro 7.0 Clean, professional feel and a fantastic new application icon that really makes sense to our users.

Quickly going through some of the windows that had the most modifications, our preview window. Preview window contains tools, all of the action buttons for our application, as well as a pop-up menu for scanning material. In the previous version, this pop-up menu had an icon that really confused a lot of our users.

So we decided to opt for a very simple pop-up menu. We rearranged all of the information for workflow, and we redesigned all of the tools as well. Wow. You'll notice in later slides as well that we have moved all of the tools to the upper right hand corner, making our application much more intuitive for the user.

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

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

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

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

Great. Well, thank you, Kristen. The end result is it's clear from these three cases and lots more that I could have brought on stage but we didn't have time for it, that if you put the effort in to make a really, really great user interface, put a really great user interface on your application and an interface that makes the product highly usable, the end results are significant and the benefits to you as a good citizen in the world of Mac OS X are significant. Remember, don't focus just on your features.

As the engineering people, typically probably the audience is filled with programmers, you're interested in what you wrote, right? You want your feature to be exposed to the world. But remember, users don't really necessarily care how your product, what it does necessarily. I mean, they do, but they're more focused on how it does it. Ease of use really matters. These interfaces that are discoverable really matter and the benefits are substantial. So the last part of the definition of citizenship is that there are awards for good citizens.