Welcome to session 103, User Interface Design. We've got a bit of an echo in the room, so I hope they correct that in a few minutes. My name is John Geleynse. I manage the Software Technology Evangelism team at Apple, but I'm also continuing in my role as User Experience Evangelist. And we've got a lot of stuff to cover today. It's going to be a lot of fun. And I would like to begin by just sort of setting the stage for why this session matters.

Why does it matter to create software that looks great, that operates efficiently, and just delivers a really great user experience? One of the things is it generates higher user productivity, right? Well, everybody likes to be productive with software. So if your software is well-designed, your customers are going to be productive. And as such, they're going to be satisfied, right? Increased customer satisfaction, great apps. We all have great apps that we use, that we love. They're well-designed apps, typically.

There's greater perceived value, all things being equal, the app that looks better, certainly, and operates more efficiently, and has a better user experience is going to be perceived to be the better product. Lower cost of customer support. Think about the cost of customer support in your organization. The industry rates, you know, average is about $45 to $75, depending on the company that's providing the support, per minute of customer service.

And so you think about the cost of goods of your box, and then the amount of profit that you make on every piece, on every version that you sell, and you figure out the cost of customer service and the amount of calls you're getting, and you can easily correlate the relationship between how much support you're providing to your customer base, you know, versus the profitability that you've got in your product. And so if a product is well-designed, you're going to have less customer service, less customer support. Faster and simpler implementation. Sometimes creating a really great product, a well-designed product, takes less effort. once it's designed and you're implementing it.

Competitive advantage, of course, as I said before, all things being equal, same feature set on two applications, the one that's got a better design is going to be the winner in that competition. Brand loyalty. Customers stick with companies that create great products. And so we all know great products. I think of software from some of the Panic guys, Panic Software, they create some great products.

Net News Wires are another great product. Some of these small companies have done a great job with the user experience of their products. And the net result is they've got customers who are ready to buy the next thing they produce. And so brand loyalty is really critical. And I know most of you are programmers and engineers, and so maybe profitability or brand loyalty is not something you think about, but it really does matter to the company that you're working for. Simpler manuals and online help. Of course, it's easier to document something that's straightforward and easy to use, right? Now, today in this session, you know, that's pretty much the boring part, the startup piece.

Today in this session, what I would like to do is something very different from what I've done in past years. I've been up here about six years, I think, presenting here at WWC. And in the past, I've kind of gone through a process of explaining our interface guidelines and talking about different examples. Today, I'm going to redesign an app here on stage in front of you and just sort of weave the principles into that process.

All right, well, the experience, sort of where I get this information from and the experience that I bring to this session comes from having worked with close to 900 developers or 900 products over the last seven years at Apple. I came to Apple in 1999, began in this role at that time, and since then have averaged about two or three interface audit meetings or interface review meetings, user interface review meetings, per week on average, except when WWC kicks in and we have to prepare for that, you know, starting in March.

But on average, I'm doing about 120, 150 of these design reviews and redesigns a year, and so we're coming up on about 900, not including all of the HI Lab reviews that we've done at WWC over the past years, and so there's a lot of experience that I've gained over the years, and I'd like to share that experience with you.

Now, interesting thing is that despite all of the effort, despite all of the talks that I've given at WWC and elsewhere at other conferences, and despite, you know, multiple revisions of the design, I've been able to get a lot of feedback from a lot of people. I've been able to get a lot of feedback from a lot of people.

I try and I try. And we're making great progress. And I'll show you some great progress that has been made at the end of the session. But I want to start off by sort of giving you the state of the union of software on the platform. This is a shipping app today.

And I don't know if you can pick it out from the back of the room, but hopefully you can. This is a shipping app today. And the problem with it is, if any of you here have been on Mac OS early versions of the system software, system 7, system 8, we've got an app here running on 10 that's completely faked the scroll bars and all the controls and all the buttons. It looks exactly like a system 7 application. So that's not acceptable.

Here we've got an application. It's a chatting tool. It's shipping today. Again, the point here is not to drive people into the ground and roast them, but this is a little bit of fun. I mean, we appreciate the products on the platform, but there is some need for some good design here. So here's a chatting application. The issue here is just some really garish colors. Some of the layout could be optimized. We've got giant controls, huge double-sized pop-up menus, if not triple-sized. Red text, which is a real red flag. Lots of problems.

Here's an application. A bazillion buttons in the toolbar. I have no idea what to click. Where do I start? Which one's important? Which one relates to the task that I want to accomplish? Not to mention the fact that the rest of the UI is completely custom and probably looks exactly the same on Windows.

Not a great experience. Here's a really cool app, actually, which we're thrilled to have on the platform. But it's just lacking, you know,

If I could go to the D machine. Yeah, all right. And just let's have a little bit of fun here for a second.

I want to zoom in and just show you a couple more disasters that, you know. Okay, these are great error messages that are just useless. There's not enough room on the disk FW8 gigabyte hard drive to copy Mac OS X. An additional seven bazillion, you know, terabytes are needed. Okay, here's another great dialogue. Do I give a damn? Attempting to give a damn. Okay, check this out. OK, it's attempting to give a damn.

Unable to give a damn, it should stop me. So great error message. All right, let's see. OK, here, this one. This one's great. How about this for an error message? The updater reported that it is not the memory the diff was created. Go figure. Here's another one. I love this stuff. OK, here's a great one from Windows. Some random data is needed to generate a cryptographic identity for you. Please bang on the keyboard like a monkey.

All right. I love this one. Here's a sad device. Your software is trying to be emotional. Unable to open a stream to the sad device. Okay, and here's one from Vista. Trying to install Vista on my, on one of the, I guess a MacBook or something. It says, you know, I guess I don't have what I need, but it's just a real, it's real hard to read this dialog box or this error alert. I haven't got any more. This one's great. So I've got to select an adapter here, and then the error message I get at the bottom is, "wubba, wubba, wubba, wubba, wubba," and it just keeps going. Okay, back to my slides, please.

All right, so clearly there's some design sense lacking. So what can we do about this? And that's what this session is all about. Well, there's a design process that you need to follow to end up with a really great result on the end. And to explain that process, I'd like to give you a demo of the product that we're going to redesign this morning. So think of this as kind of like extreme software makeover, and this is our contestant. So if we could go back to my laptop again, demo machine.

All right, and a colleague of mine who professes to just totally not care about interface design has written this application. And so when I found out about it, I thought, you know what, this is a great app to demo in my session and redesign. So, okay, so let me zoom in a little bit just so you can see a little bit what's going on.

So this tool is, it's an application that allows you just to basically open a file and look at every byte in the file and examine it and look for, you know, patterns and what have you, and analyze the data because maybe you care, okay? So it doesn't matter whether you think it's a great application or a useful application, that's not the point. The point is that this is a real app that we're going to redesign in this session, and it does enough for us to get the point across.

So the app, basically, I've opened the source for apple.com. I saved it as an HTML file, text file. And so here I can just, you know, I can click on the different bytes in the file, and you see I've got an ASCII display on the left here. Actually, I've got a real cool tool that lets me highlight what I'm doing. Isn't that cool? That's OmniDazzle. You guys have done a great job with that little tool.

Here's a hex display, so I can look at the hex value of a given byte over here. It's just interesting. And, you know, in fact, if you want to hack a game and figure out where the high score is and then just change the high score, this is the tool to do that. Now, I'm not saying you should do that, but that's the kind of thing you'd use this for. Or you might say, oh, you know what, I've got a right.

It's an RSS, you know, thing, and I need to find out where in this HTML page the RSS feed URL is located because the page changes, but I'm looking for a particular set of bytes. And anyway, so you can scroll through the file, and you can look at the different byte values and et cetera. Okay. Now, say you wanted to make a change. You could switch to modifiable, and now I can go in and say I want to modify the ASCII or the hex.

If I change the hex, I can click on a particular item, and I can change it to, say, a 45, and then I have to hit the apply button. But, of course, it doesn't map to the return. It's a return key, which is bad. So I can hit to the apply button like that. I can change another value. Let's change it to 45 again. And, of course, it changes it over here, and it does highlight it in red to show me that things are changed.

Okay. And anyway, that's kind of the basics there. I can do something else. I can flip the bottom of the screen open, and I can create a note. I can say, okay, let's see. Right here is something about expires. I don't know. Say this is meaningful. Okay. So I'm going to make a note about this thing expires, and I say expires location.

And then I can do some wabba, wabba, wabba. And so I've created a note. Of course, you'd type something useful. But in this case, it's kind of a cool feature. You can kind of go through the file, and at different byte locations, you can tag the byte location with a note, and notes and their commentary are stored in a separate file associated with this one.

So you're not actually changing this file with those notes. So that's kind of cool. I can scroll, you know, elsewhere so that my selection goes away, and I can hit a button, just scroll to selection, and so now it brings the selection, you know, where the cursor was. It brings it back into display. Not bad. I can toggle a side drawer, and this drawer comes out, and there's a whole bunch of stuff in it.

And the stuff in it at the top is sort of I can look at a given selected byte, and I can see its byte value, its unsigned value, little Indian version of a word. I can look at the long equivalent of that byte as well as a string of hex bytes starting at that point and ASCII, et cetera. Okay, so you get the point, right? It's basically just a file sniffing type of application. And I think that was all I wanted to demo, so let's go back to slides.

It's enough for now, anyway. OK. So the problem with that app is-- I mean, I pointed out a couple of things verbally, but I hope you paid attention and noticed the fact that there were small buttons, big buttons, square buttons, round buttons. There was different sizes of text, different font faces being used. And just the general layout kind of looked like the shotgun had been loaded, and the stuff was shot onto the screen.

So to redesign something like that-- and all of you have, I'm sure, some part of your application that needs some love. And to redesign those parts of your application, you've got to begin with user-centric design. In fact, the whole process, the whole redesign process, or writing a product from scratch, has got to be done with the user in mind.

So we'll get to the specific redesign in a minute, but I want to begin by sort of saying that in order for you to have user-centric design or user focus, you've got to first understand who your users are. You've got to know what their problem is, which in turn is your opportunity with your software, of course, right? You've got to know what's required for them to get the task done. In other words, do you really understand who your users are? As time goes by, more and more people have computers. Computers become more and more part of our society.

And what was true 10 years ago about computer users is no longer true today. We've got a whole new generation that's text messaging, that's doing a thousand things at once with all their little devices. They're not tolerant. They want instant response. They want this stuff to work fast. And many of them are less sophisticated than computer users were 10 years ago. So you can't assume that, you know, the world is the same as it was previously. And so you really need to understand your user as you design a product and design it for them.

Secondly, of course, in the redesign or in a design from scratch, you need to understand what your solution is. What are you trying to build in the first place? A cartoon I shared last year, and several times, I love this cartoon I saw one time, is a bunch of programmer guys sitting at machines, and the boss is going out the door, and he goes, hey, I'm going upstairs to find out what they want. You guys start getting coding, right? You start coding. And so many of the companies that I've met with over the years, that's almost what's going on. Everybody starts writing stuff.

Writing a list manager, and writing this and that, and no one really is quite sure what they're building, ultimately. Everybody's talking about how they'll figure it out, but there's too much work going on in terms of the engineering and building of the product before it's even designed. And so you need to define your solution. Decide what it is you're going after, what users are you aiming for, and what are their capabilities. And then, as you go through the process of defining your solution, it's important to stay conceptually broad initially. Come up with a general mission statement for the product.

I call it a product definition statement. The definition statement, I'll give you an example in a minute, is what's going to summarize the intended purpose of your application. It's going to guide everything you do, and you should use it as kind of a filter for every new feature that someone brings to the design meeting that they're suggesting you add to the application. You stick it through this mission statement, and if it falls through, great. But if it bounces off for some reason, and you'll see why in a few minutes, you need to reconsider either re-architecting the statement, or ditching the feature that's being asked.

So a lot of times when I talk about this, or as people go through this exercise and try to define the solution, they think of their product, the end product, in terms of the features it is, and the things that users can do with it. And so you end up with a list like this. Now, it might be nicely formatted, but you end up with these huge lists, long lists of what the app can do.

What are its features? Well, for the app that I just demoed here, these are the features, some of them, anyway. It can open a file. It can show contents byte by byte. It can add, edit, or delete formatters, which I'll explain later. You can define ranges of bytes. You can go to a note location. You can revert to the original. You can commit changes.

You can display byte as an unsigned integer, a string of text, or a string of hex in little Indian or big Indian formats, et cetera. You get the point. All of your apps, the apps that you're working on, have lists and lists and lists of features that users can, you know, things that people can do with the application.

And as you take those features and boil them to specific steps, the lists get even longer, of course. You know, click here, do this. All of those are actions. But those don't define the product. And you can't build a product using that list as your filter for what gets in and what gets out, because it's just a list, and there's no priorities assigned to it.

So what you need to do is come up with a product definition statement based upon this, sort of, but that refines this, and that gets to the point very succinctly. So in our case here, the app that I demoed that we're going to recreate, rebuild this morning, it's a file snooping and editing tool for highly technical users.

So in one sentence, I've defined my audience, highly technical users, which is going to impact things like the terminology, some of the gestures, and the UI that I design. It's also a file snooping and editing tool. It's not a file synchronization tool. It's not a file, you know, whatever tool. I mean, it's just these things. All it does is it opens, reads files, and it lets me edit the bytes, the individual bytes of them.

So this, as you can see, this very succinct statement is a great starting point for your entire design team, because everybody should have this in their mind front and foremost as they figure out what features they're going to put in the application, and as they think about what, you know, as they design the application, they run it against this.

Okay, now, you've figured out your users, you know the solution you're going for, you've come up with a product definition statement or a mission, you know, mission statement for the product that the whole team has bought into, but how do you get from there to a design? Well, you get from there to a design by beginning with something called a mental model, which is sort of the user's perception, you know, of the product. Actually, I jumped ahead of myself. Mental model is not the way the application is perceived and designed from the programmer's perspective.

Of all the meetings-- I mean, pretty much every meeting I have gone to over the last seven years, it's been clear that most product teams are developing software with their view of the world in mind. And so you get programmer terminology showing up in the UI. You get the sort of programmer class model, the hierarchy of objects in your Objective-C or your C++ code. All of that is kind of being presented. It's drawn out, and it's somehow finding its way into the UI. So things are structured in the UI according to how you've architected the product. And that's not the right way to go about it.

The problem with that is that it puts the burden of learning your application on the user. Might be a great app, might be great performance, very performance tuned, and it might be very responsive. But the problem is users are going to come to that app, and they're not going to know what to do. They might figure it out, but ultimately they're trying to kind of wrap their mind around what this app does, because it's your view of the world in terms of how you designed the product from an architectural point of view.

What I mean by mental model is that it's the way the application is perceived from the user's perspective. That's user-centric design. And you've got to constantly kind of take yourself out of your design mode, your programmer mode, and look at the application from the user's point of view. And that's why it's important to understand who your users are.

Well, how do you determine the user's mental model? Well, this is a great exercise, and this is fundamental to this session today. It's fundamental to this process. You have to first go through an exercise, and it could be a cross-functional exercise with your help writers, documentation people who understand the app from that perspective, with your engineering team, key people in the engineering team, of course, who understand what the application is going to be able to do and what the technical constraints are.

It could be comprised of some product marketing people who are going to have to pitch this to the customer base. They probably know some of the audience you're going for better than maybe you do. You've got product managers who understand some of the constraints that are going to go on.

There are all kinds of cross-functional skills within your organization that are going to be part of this process, or that are going to be part of this product development that you need to bring into this initial design meeting to come up with the user mental model. And the mental model exercise is basically, OK, take that cross-functional team.

And work through a brainstorming day. Begin the day with brainstorming. OK, guys, what are the objects and object hierarchies and object relationships inside of the application that we're going to build or that we're redesigning? And you list them on the board, on a whiteboard. And you just whip them out.

Whoever says whatever, you just write it down. Don't worry about prioritizing. Don't worry about cleaning up the list, whatever. You just get those objects out there. Then you come up with another list, concepts. What are the concepts the user's thinking about as they're going to use our application? Then you list them. Then you list tasks and workflow.

Tasks and workflow are synonymous, basically. But you could build two different lists, because sometimes the people you're working with in the room are going to use different terminology in their own mind. So they're going to throw things up. And eventually, you can consolidate the lists. And you want to list roles. I was recently with a developer. They were doing sort of a pre-press thing. And anyway, the application-- I don't want to be specific. So the application we were redesigning in this meeting was it required different types of users.

There was kind of the midnight type that was using this tool. There was the day shift that was paid a lot more money to use the tool to design certain things. And then the midnight shift would use the designs that were created during the day to generate output.

And clearly, there were some roles. And the roles had access privileges associated with them. And there were parts of the workflow that would be shut off to different roles. And so it was important for us to list the roles, because that impacted the ultimate design of the product.

Once you've got these lists in place, then you go. You take a coffee break, or you take a lunch break, you come back as a team. You go, OK, let's prioritize these lists. What are the key objects? What are the key tasks? What are the key workflows? Who are the key roles users of the product? And you prioritize the process.

This is critical because once you've got these lists in place, and you've scratched off the things that you all agree don't make sense. You know, that's not an object. That's the wrong term. It's this object. And once you've kind of finalized those lists, then you're going to use that as the basis for everything you do from then on. And we're going to illustrate this in the session this morning. It's going to affect the presentation of information on screen.

It's going to affect the interaction model of the application, how you use it and what it does. It's going to affect the structure and organization of Windows, the organization of your menus, the hierarchy of your menus. It's going to affect terminology, of course, because you understand who your users are.

And in our case, it's a snooping editing tool for technical users. So we can use words like data and default and stuff, because we assume the users understand that. And it's going to affect even the toolbar contents and labeling that you put up there. Mental model affects everything you do. And you'll see that this morning.

We're going to get into the redesign now, and I want just to put something into your minds for a minute as we begin this process. As you start, now you've done the mental model, you've prioritized the whole thing, now you get into the step where, OK, guys, as a cross-functional team, you kind of kick around some ideas. Well, how would we represent this stuff on screen? It's important to keep thinking about what is important now.

You're going to talk about different steps of the process of your application, what the user does at one point, what do you do at the next point. And at each point, you keep saying to yourselves, what is important now? Because if it's important right now, it needs to be right there on the screen for the user to access.

But if something is not-- if a particular feature or something that your app does is not important now at that particular point, then perhaps it's sort of secondary. It's a nice to have. If they clicked here, that would be really great. It would augment what they're doing in our application. But it's not to die for. It's not critical at that point.

Well, if it's secondary like that, then it could potentially go in a drawer. It could go into a lightweight panel that's floating on screen. Or even if it's not even secondary, it could go elsewhere, like just in the menu bar. And you'll see what's going on. OK, so let's start with a really, really simple example. Say you were designing a calculator.

Let's look at iTunes. If you think about the mental model for iTunes, and you come up with a mental model, you have to go through this object concept brainstorming process. So if we define the objects for iTunes, if you were creating a playback software, an audio playback, whatever you call iTunes, music software, what are the objects and concept the user is thinking about? Well, they're thinking about songs, collections, or albums maybe. They're thinking about devices potentially, an iPod, some MP3 player.

What are the concepts? Rip, mix, burn, playback, searching, organizing, right? Those are concepts. They're not specific tasks. They might be, but just in terms of this stage of the design of this process, let's just keep it very vague. Or not very vague, but let's not be too specific.

Well, we've got the list. Now let's prioritize them. What are the most important objects from the user's point of view for music management, music software like iTunes? Well, I would propose that it's songs and collections, songs and albums. And from a conceptual point of view, the key concepts that the user has come to the application with is playback, search, and organize.

Well, how does this now impact-- once you've gone through this exercise-- how does this impact the presentation of the design of the interface? Well, first of all, songs are one of the key objects for the user. And so they dominate the interface. In fact, they are the number one thing the user expects to see when they launch the application.

And so they dominate the interface for iTunes. Collections, albums, which is really-- those objects correlate directly to a concept which is organized. I take my songs and I pull them in. So that's a big part of the interface as well. It's resizable. It's on the left. It's very present and accessible.

Playback. Playback is key. It's a key concept. It's right there in the top left corner. The human eye reads from top left to bottom right. So your top left corner of your screen is like the top real estate for your application. That's where you want to put the things you want users to do right away or see right away. And so playback belongs there.

Secondly, status. I didn't have it on my previous list, but status, communicating status to the user is really important. And so status belongs in the UI. It's at the top of the iTunes window, not so much because it's primary, but because iTunes has another feature, which is you can shrink it to the little playback window, right, the small little thing that's floating on screen. You don't need to see the full UI.

And it really is valuable for that status message to not be jumping around and for UI to change positions. It's much more valuable for users, and from a good design point of view, that these things stay anchored where they are. And so the rest of the window kind of changes, but these two items stay there.

And then search is a powerful concept that users have in mind. And so that's up there in the toolbar. It's front and center, so to speak. And it's readily present. And then, of course, there's lots of other stuff that iTunes does. But it's down on the bottom. It's miscellaneous. It's secondary or tertiary functionality. It's there. It's in the main window, because there was a design philosophy to make this a single window app. But it's very much at the bottom. It's just, you know what? If you need it, you can go get it kind of thing.

So you can see how the mental model, the list that you've built, the list that you've built, that you've decided on as a cross-functional team, directly impact the presentation and layout of the interface that you ultimately come up with. OK, so what about our makeover contestant? Well, this is the screen I showed you earlier when I was on my demo machine. And if we look at the concepts and objects for this product, I'm just going to-- I did the brainstorming by myself. So the objects are files, bytes, and notes.

Concepts are NDNS, display formats like Hex and ASCII, patterns, formatters, which I didn't demonstrate, but I'll talk to you about shortly. And then some of the tasks are not specific actions the user can do, but they're sort of the general features of the application. Viewing file contents in ASCII, Hex, or other formats, editing file contents byte by byte, revealing byte patterns, et cetera. So that's the app I showed you.

And so if I prioritize this list, I'm going to come up-- I propose that bytes are number one in terms of objects. If I'm doing a file editing snooping tool, it's all about the bytes in the file. It's the data of the file. The concepts that are important are the display format. How do I show those bytes to the user? And then patterns. Patterns turn out to be really cool. And then some of the tasks are to view the file contents in the different formats and reveal the byte value patterns. OK, so we've got this list. It's prioritized.

Now let's look at the current app, the shipping version, and see how they're currently presented in the screen. So we've got the big block of ASCII data. That's fine. That matches. We've got the big block of Hex data. That's fine. But we've got patterns in the drawer, which is interesting, because-- and you'll see later how this kind of works, but trust me, patterns are key.

And then we've got sort of in the middle of the window, down underneath the Hex view, we've got these two radio buttons that switch you between read-only or modifiable mode. And I demoed that earlier. You could switch to the modifiable, and now suddenly you can edit the file.

I've got the bytes, ASCII data. I've got hex data. And I've got my patterns right in the main screen. And up in the toolbar, I'm going to put two buttons that allow me to hide the hex view and hide the pattern view. And so the result would be that the patterns would disappear and the hex view would grow and that kind of thing, like this. So I can switch different views. You're always going to have ASCII data in this application. OK, let's look at formatters. And in order to understand formatters, they offer great functionality. I'd like to do a quick demo of formatters.

Okay, so what formatters do, let you do, is you, let me just zoom out just slightly here. I can click this awful tab thing at the bottom here, and I can create a new formatter, and actually I need to go to their window, open the formatter window, and now I can create a formatter and call it, you know, foobar, and then over here I have to, for that formatter, basically a formatter is like a record definition.

I can say, you know, long, and then I can specify that it's, you know, look at this horrible UI. It's four bytes, it's unsigned, yes, I can specify, you know, a string here, I gotta click the plus sign, notice the plus sign characters and stuff are totally, total hacks.

So how does that impact the design? Well, the top of the screen, which was proposed a few minutes ago, I'm going to propose that formatters belong on the main screen, and that essentially we have something like Network Crafts, where we've got a pop-up menu that lets you create them, edit them, delete them-- sorry, create them and edit them. And then you would just-- you'd name them, and you'd choose them from that pop-up.

And as soon as you change it, you'd change the view of the data down below. And it turns out that in the drawer of the app,

Tertiary objects in the app are notes. Well, how do notes work? Well, they're currently in the main window, right? They don't belong there because they're really not used that often.

So remember this at the bottom of the window? I think it could go in a drawer. So let's take it out of the main window. Let's put it in a drawer. Let's clean it up, make it look nice. Let's take a 3M Notes approach where they're colored. So let's give it a yellow background, the right font, the whole thing.

And notice that I've got some additional capabilities in there, where when I select a note, I see the commentary for the note, and then inside the main screen, I've got these yellow dots for behind the byte where the note is associated. Currently, the app doesn't really give you that kind of feedback. And if it does, it's some ugly, ugly color.

So here are the dots, and they spread across the different views. And again, patterns are just another way of looking at the data. So let's look at the toolbar. What's going on in the toolbar? Well, sorry. I've got the lock icon. I've got the hide pattern, hide hex, which we talked about a few minutes ago. I've got a few other things, edit formatters and add note. But do you remember this thing, the read only modifiable? So we put that into the lock icon. So we've got a little lock unlock so that it turns it from read only or modifiable mode.

We've got the notes. And so when I turn on-- sorry. When I unlock the application or the file, and now it's modifiable, I've now put edit fields behind some of the value fields down below. So there's some change in the UI that occurs when you unlock the window.

We talked about these before. These expose useful shortcuts. Just edit formatters, add note. You know, some of these things are going to be off in a drawer. They might be in the pop-up menu down below. Putting things up in the toolbar that just expose useful functionality in your app is OK, but it's important to not go too far with that and populate your toolbar with just so much stuff that users don't even know where to begin. You really only want to use it for key things. And then, of course, hide notes, which when you click these, all of them would change their labels appropriately to say hide show, that kind of thing. OK.

But we put notes in the drawer. It turns out that we can get rid of the drawer, because notes are pretty interesting. When you defined a note and assigned it with a particular byte position, you can use the notes list to navigate your file. So that's interesting. So I'm going to change the plan.

And again, going back to the user mental model, how this thing works, as your cross-functional team would talk about these things, you'd say, oh, wait a second. You can use notes for this. And you guys are going to talk about the features of your app and how people use them, because you understand your user base. And so that's going to directly impact the design. So we're going through an iteration here. We're changing the design as we go.

I'm going to propose that notes actually come out of the drawer. They could go back into the main window. But let's put them down at the bottom in a tab view, because a tab view allows combination of features into one space. And it lets us get rid of the drawer thing on the side. And it simplifies our toolbar slightly, too, because we get rid of an icon.

So that was the Notes tab a few minutes just prior to that. This is the Formatter tab. Again, same structure as we had before, but it's now just living in a tab at the bottom of the window. So we've consolidated everything into the main window, and it's pretty slick. We've gotten rid of the clutter of a drawer. It really isn't necessary, and we're moving forward.

But wait, are tabs really needed? I see a lot of developers, I talk to lots of companies, and there's a tendency to kind of just go, yeah, let's stick it in a tab. You know, it combines stuff, and it's all down the bottom. You know that argument I just made a few minutes ago. Sometimes it works.

But again, are they really needed here? I don't think so. I think we can grow this window just a bit and put these two things side by side at the bottom. So we can have our default formatter on the left and the notes on the right. And it provides a simpler interaction, because features are available simultaneously and with a whole lot less clicking around of the mouse.

See, previously, if I wanted to go to notes and I was looking at the screen and I had the formatter tab, I'd have to click the Notes tab, then click a note to navigate with a note, right? If I wanted to go to formatters and it was the reverse, I'd have to click around.

So there's extra clicks required, and that's all about interaction design. Try to come up with a design that requires the least amount of interaction from the user to get something accomplished. So let's combine this stuff together at the bottom without a tab. We've changed the layout slightly. We've got more of a vertical layout around the formatter stuff.

And it looks good. Now, how did we get this great look? Well, there's some basic Aqua layout and design guidelines I'd like to share with you. First of all, avoid using solid black. Use 75% black if you have to draw a black line somewhere. I would advocate that you don't need to draw a black line anywhere.

In some cases when you need to do that, avoid using solid black. Our design, the look and feel for Aqua is all about more muted, more grays, and a softer presentation. Avoid random alignment of interface elements. If you go back to the app that I demoed earlier, there's just this disaster going on at the bottom of the screen with big buttons, little buttons, square ones.

They're not positioned. They're not aligned. There's different fonts going on. It just looks like a mess. Group-related items. So the screen previously-- and we'll come back to it-- notes are nicely on the bottom. Formatters are nicely on the bottom. The displays, the viewing of data on the top.

Use white space effectively. You don't have to put group boxes around everything. You can actually just separate items with enough white space-- and I'll show you a couple examples-- to get the effect that you need. And you don't need a line. You don't need a group box. You can achieve the end result that you want.

Reduce clutter. Get rid of duplication and redundancy. One of the things that I see pretty much in every app I look at is there's some dialog box or some window or some element of the app where you see a whole bunch of labels, and the same word is repeated over and over and over and over again.

It's like, okay, if you see a word repeated over and over in labels or in different elements of the UI, start to think about, that should be a red flag, which is, why are we repeating this term all the time? It's taking up real estate. We could just use that as a title, you know, a group box title, perhaps, or some sort of a parent label, and then group stuff underneath it, you know, with the same term.

Eliminate extraneous content. So just, again, what's important now? Only put the stuff in the UI that's important at a particular-- at each point of the workflow. And ensure close proximity of controls to the data they affect. By that, I mean-- a great example of that is, you know, the plus/minus buttons at the bottom of lists that you're starting to see in iTunes and other places.

That's a great-- it really works, because you just glance at that, and you realize those controls are kind of bumped up against that list. They probably affect the list. And yet, time and again, I review apps, and I see, you know, I'll notice buttons that are way over on the other side of a dialog box or inside of the main window that affect something way over on this side of the window.

And, you know, as much as you can, try to put stuff close together that affects each other. Use standard interface elements correctly. Again, avoid mixing control sizes like we saw in the sample app that we reviewed. Avoid mixing text sizes. If you're going to go with standard size controls, go with standard size controls and standard font face, lucid or grand, across your whole interface.

Use user-centric terminology. Again, this comes back to mental model, right? What is the user's term for this object? How would the user express what they're doing right now? And build that into the terminology that you use. Avoid programmer terms, unless you've got a real technical audience and they're programmers, in which case that's the right term to use for that audience. Begin checkbox, radio button, and push button labels with verbs.

Capitalize the first word of labels or strings. Use colons and labels preceding controls. Avoid mixing text sizes. Again, that same one. So let's look at these in practical examples. And let's take the design that we made, and let me show you how we applied those guidelines to the design we made.

First of all, on the bottom, what was it? The left corner of the screen of the window we designed, we had the formatter pane at the end. And here we've got is everything is nicely centered, center equalized. You know, the edges of the controls, the farthest right, the farthest left, the farthest top, farthest bottom, is inside of a box. And that whole box is centered within that area.

And this is center equalized. Seems easy enough, right? Interesting here. No. While this is mathematically correct in terms of the bounding box being centered in the window, center equalize really means visual balance. And so if we drop the box down again, You'll see that visual balance does not mean centering the box either. It's all about visual balance. Actually, if you pay attention for a minute, look closely to the sort of weight of the-- imagine there's a scale.

And on the left side or right side of the line, you've got so many characters on the one side, and you've got so many characters on the other side. But you know what? Checkbox controls are way a little bit more, and so they kind of tip the balance this way. And so this is why you need a visual designer involved in interface design, because there are people who are sensitive to this stuff, like me, who can pick it out in the dark.

We can just go, ah! And anybody who's been in a meeting with me knows that as soon as you start talking, I'm like, hey, what about that? Hey, what about that? But this is a great example of it. It's center equalized. So if you did the first version where you just put it in the box and centered it, you'd be good. I'd give you good marks. But to get it right, it's about balancing things across the center line.

All right. Another thing I talked about is right aligning labels. I still see this getting-- you know, people are getting this wrong. You-- where you've got a whole bunch of things vertically stacked, whether it's in a main window or a dialog or any sort of interface container, you want to make sure that what is labeled has got colons on it and it's right aligned. Everything that's stacked is right along the colons. And then their associated elements and controls are left aligned.

OK? It looks great. If it's done well, it looks great. It's very clean. In fact, I just read a study-- just going back to the previous slide-- I just read a study on the web where some interface designer, scientist guys, walking around lab coats, very expensive labs, did some kind of a test where it was like, OK, are right aligned controls easier for users to discover what's going on? And it turns out that it takes your mind about-- it's five times as fast to associate a label with a control when it's right aligned than when it's left aligned or aligned. or aligned otherwise. So it's interesting what we've done in Aqua.

Left-aligned dependents. Here's a different dialogue from another app. But here's a case where you've got a dependent-- the size edit field, particular number of pixels or what have you, is really a dependent of the radio button above it. And you can see how I've left-aligned the text of the S for size with the edge of the text for the radio button above it, its parent radio button. Just little tips. Goes a long way. Space items and groups adequately. I was talking about using white space.

So here we've got between each of the individual items in the bottom of our display, we've got kind of this section for bytes, section for word values, and longs and strings. And each of those sections is separated by the same amount of space. And there's no-- I don't need any gray lines. I don't need group boxes.

Your eye just kind of separates out things, and it sees the groupings. And it's a much cleaner design. And then that group, that space there, is really from the bottom of the pop-up menu to the top of the characters in the edit field, not the edit field itself.

Again, something I see over and over and over, a lot of this is just, I guess, people coming over from Windows, bringing apps to the platform, and we love that they're doing that, but it is a standard on Macintosh that the action buttons are in the lower right corner, and the most action item, the OK button is in the rightmost side of those two.

Begin checkbox and radio labels with verbs. If you scan the human eye, you will scan UI constantly. Users are always doing that. That's the way your mind works. And if you can begin checkboxes and radio buttons with verbs or action words, you will quickly be able to go down this list and just go selected, reposition, remember, copied, you know. You don't even have to read the whole label. You could just go, ch-ch-ch-ch. And you've seen it before, and so then your mind fills in the missing blanks.

We've got the top left corner, you've got the application menu. So about is there, and preferences, great. The right keyboard shortcut, perfect. Everything else is great. So that menu is good to go. The next menu down just below that is the File menu. New, open, recent, close, apply, yeah, yeah. It's pretty good. On a first pass, I would say yes, it maps great. These are all commands that associate with the file, and the file is a key object in the application.

Next menu, above that one in the center of the screen, is the Edit menu. And we've got standard edit commands, undo, redo, copy, text bigger, smaller, sure. It's good enough for now. Let's jump to the, I think, the one below it, the Find, which is associated with the Tools menu at the top.

This is probably the menu that would need the most work in a redesign meeting with me, because it doesn't map to the mental model we've talked about. In fact, the menu bar should change. Tools should go away completely. There probably should just be a Notes menu, and then perhaps a Formatters menu, and then perhaps another menu for maybe one of the other objects that we would talk about and come to agreement on. And you really want to just have menus for those objects that have commands associated with them specifically. So Notes absolutely have commands. There are Notes management commands.

Formatters have-- there's stuff related to formatting, you can see, but all of this stuff is jammed together in this one menu that the developer just sort of said, ah, whatever, just call it Tools. Right? And I don't know how many Tools menus I see in applications that I review, but there are lots. And I bet you've got one in your app, or at least some of you.

So that one needs some work. But the last one, specific to Notes, actually it's great. It's good. It's all about new Notes, go to Notes, open Notes, manage Notes, et cetera. Now I might work on some of the terminology, because just like radio buttons and check boxes need to begin with action items and verbs, so do menu items. So that you can just go to a menu, choose an item, and just understand that it says, like, open, save, print, you know, format, whatever. And so action items at the beginning of text menu items is great. So tool menu would have to be redesigned. You're beautiful.

All right, I want to honor some products on the platform that have done a great job in this regard. And these are beautiful apps. And so clearly, you know, when we started, it was obvious that there's certainly lots of design sense lacking in the community, right? There's still lots of people creating a pretty useful software from a functional point of view, but from an interaction usability point of view, it still needs a lot of work.

But there are lots of developers also who are doing great work, and this is to honor them. So the first is Delicious Library, the guys at Delicious Monster have done a phenomenal job. These guys have won an Apple Design Award in the past, if not a couple. And this app does a great job at just sort of representing the user mental model and communicating very visually in an elegant and delightful way what's going on and what data it's representing.

And from left to right, interestingly enough, it goes from general information that you would click on, you know, like I want movies or books, over to the right. From left to right, you're going general to specific. So as you make a general selection on the left, then you go to something more specific in the middle, then you go to something very specific about that selection. And so that's a great model, from left to right, general to specific.

Here's another one, Fuzz Measure Pro. It's a product that does, it's for acousticians. It's for acousticians to determine the sort of the acoustic configuration of a room, a home theater perhaps. You put a microphone in the center of the room, it generates a sound tone, and then it tells you exactly what you need to do to your speaker arrangement or furniture arrangement, and it looks at the flow of the audio response and all this sort of stuff.

And anyway, it's just a real simple to use, highly complex, very very cool application, well, well designed. Photo Magico by Boinks. The guys at Boinks have done a phenomenal job at creating an app that just, in a moment, you can just put together these really cool visual effects for photos and put together some really compelling slideshows. Great, great, where they have customized controls, which I don't generally encourage, but they've done it because they needed to, and they've done it in a really, really elegant way for rotations and for zooming and stuff. Great product.

This is iBank, great banking software. It is everything that banking software should be on Mac OS X. It's a great, simple, clean, well-designed Aqua app, and it pretty much does everything that you would need for personal banking. Looks great. The Body Journal, phenomenal product. It looks gorgeous. This is a standard, this is just a straightforward Mac OS X app, but for the audience that they are going for, which is people with medical needs who need to track, you know, blood sugar levels, and, you know, heart monitors, and all the stuff that you need to track when you've got medical conditions, this app lets you keep track of all of the data for your situation, for anybody in your family, for that matter.

Doctor visits, everything is combined here, and because you probably wouldn't be in this app on a daily basis, they've sort of upped the ante in terms of the visual presentation. They've made it gorgeous to look at. The entire app looks like this, and then where there's actual data entry, you've got standard Mac OS X controls, but this is a really, really gorgeous app, and it's completely appropriate for the audience they're going for.

NetNewsWire. This guy, not a lot of sex appeal in terms of the look of this app, but this is probably one of the best RSS readers, in my opinion, on the platform. And I say that from a usability point of view. This app does exactly what you want it to do, when you want it to do it. And these guys have spent all their time making this thing do just the right thing at the right moment. It anticipates what you want to do.

From a usability point of view, these guys have done a great job. It's a great, clean look and feel. It does exactly what it's supposed to do. Guys at Panic-- and again, these folks did not pay me to do this. This is totally my top 10 list or top 12 list.

Folks at Panic with Transmit, great FTP product. It does exactly that. It just does FTP, and it does it really, really well with a really clean UI. iSale, folks at Equinix, great application for doing eBay, for designing eBay auctions and getting them up there. Just a much more pleasing approach to the process than it would be if you were just using the standard web, more bland web interface.

And then on to jobs, something written by a student. Just the cleanest, simplest time tracking tool you have ever seen, with a really great startup mechanism for just pointing users to what to start at first in a non-modal way. It's at the point where the app certainly needs a couple more features. But from a student point of view-- and I'm not telegraphing ADA winners. By the way, Apple Design Award winners here. I'm just talking about usability. But this is a great app. This person has done a great job keeping the UI very simple, very focused, very clean.

Sandbox. Great. It's kind of like an iWeb type of web authoring tool, but it goes beyond the capabilities of iWeb to deliver a really powerful functionality. And the interface is just clean, straightforward, no extra crud on the UI. Very, very well designed app. Yojimbo from the guys at Bare Bones. Really, really great. I am totally impressed with the layout, the visual appeal of this app, the coloring. It is as clean and simple and straightforward as you could want for an application that does this type of thing. And applause to all of these folks.

So again, that's kind of my top 12 interface choice list. We have covered the process of redesigning an application today by looking at an existing app. And we've kind of gone through the mental model process. But we have only touched the tip of the iceberg. This process is a long process.

I'm not talking about years, but it's certainly more than 75 minutes. And we've only touched part of it. But if there's nothing else that you remember, remember some of the things we talked about in terms of mental model. If you would like someone to go through this process with you during this week, the HI Lab is just behind me here, right in the same room at the back of the Graphics and Media Lab in the ADC Compatibility Lab. Feel free to stop by and sign up on the sheet for a time slot this week. We'll give you a one hour consultation. It's not going to be with me most of the time, because I have other responsibilities at the show.

But you can certainly get on a waiting list, and I will follow up with you after the show with your company. I can come visit you and do this kind of presentation in front of all of your organization. But the folks at the HI Lab are the actual interface designers at Apple who created the look and feel of Mac OS X, the Aqua interface. They're not from our apps division, they are from the OS division.

So they are kind of guys that you can talk to and not worry about sharing industry secrets with. And if you're concerned about that, then work with me, because that's my job, is to work with third party developers. But please, work with those folks. They're going to do a great job and help you kind of navigate this process.

Apple Design Awards tonight. A plug for this is a personal invitation to attend the Design Awards. It's a great ceremony. We're going to have a lot of fun. And we are basically going to applaud and award excellence in software design. And I look forward to seeing you there tonight, and Presidio.

Here's my contact information, [email protected]. That's G-E-L-E-Y-N-S-E at apple.com. Find me at the show. Once I'm done today in the Apple Design Awards, I'll be much more relaxed. I'll be available just to sit down with you in the hallways if I'm free. Come by the HI Lab, and then check out the interface guidelines, which have won awards numerous years in a row for great quality. So thank you for attending the event. Hope this was valuable. Remember, mental model is critical. Get that right and everything else will fall in place.