 Seriously, you can't hear me? Okay, can you hear me in the back now? Talk louder. All right. I am welcome to Interface Design for Hacking Tools. My name is Greg Conti, and I just finished up three years teaching computer science at West Point. So if I have anyone in the crowd who's under 22 that wants to go there, come see me afterwards. I'd be happy to talk to you about it. Or not. First off, I'd like to thank Dark Tangent and Black Beetle and all the people who are working so hard to keep this event going and keep us out of the fire marshals, bad graces. All right. First, I'd like to start off with a couple of quick questions. Just a quick show of hands to see, just to get a feel for the vibe of the audience. Who thinks if someone wants to learn a tool, they should learn how to use the command line? You know, like the command line is the center of the universe. And if you don't know the command line, you ain't crap. Okay? And the next question is, who thinks the GUI is something you do at the end after you've done all the hardcore back end coding? The GUI is something you put together at the end? Okay, kind of. If it works for you, that's all it counts. Okay, last question. Who likes the paper clip in Microsoft Office? I see one. Okay. First off, this is United States Army Disciplinary Barracks at Fort Leavenworth, Kansas. This is where I'll end up if I don't do the disclaimer. Jack-booted thugs and black helicopters will land on my front lawn. This is my own. I'm here as a private citizen. I don't represent the Army. I don't represent the government or West Point. First, we'll have a little bit on what Dilbert thinks about interface design. Do engineers normally design user interfaces? Yeah, we'll try and talk about how to avoid interface poisoning. You don't want your users dying on you. First, we'll take a quick look at, I need to defuse the whole command line versus GUI argument. Or I might as well paint a big bull's eye on my chest to start off. Then we'll cover a quick run through some of the basic principles. And this is a 101 track. So what I tried to focus on is a survey of what's out there. Because in 50 minutes, there's not enough time to cover the whole field. But I'll give you a broad brush approach. And then we'll go in depth. I've done some redesigns of a couple of hacking tools that are out there. And we'll also critique some tools. Finally, I'll end up with some pointers. And the pointers are also on your CD. I'll leave the links out there of where you can go to for more information if you're interested. First off, you always have to begin with a textbook definition of an interface. But I think what's really important here is this is the public face. This is what your users see. If it looks good, then that really matters. If it looks like crap, and what do you think? Are user interfaces and security tools out there well designed? You can just pick them up and just go to town? It's a very painful process where you have to work your way through it. And I think most of the people in this room are the advanced users that you can figure it out. You enjoy figuring it out. But if you have a product or if you're giving your tool away for free and you want to get a large degree of acceptance, if there's a competitor out there that has something that's easier to use, even if yours might be a little bit better and on the back end, you could run into some problems. People tend to gravitate towards software that they can actually use. First off, I'm going to diffuse this whole command line versus GUI thing. There's a time and a place for each. I'm going to talk about GUIs today. Traditionally, the command line is for power users. It's very flexible. If you're good at it, it can be very time, very efficient. And it's best for, like I said, advanced and heavy users. Clearly you can write, and I use Pearl in these examples, arguably command line stuff, but you can write passwords in one line of Pearl. You can crack DVD encryption in just a few lines. Trinity was able to hack the mainframe in Matrix 2 with a command line. All sorts of good things. We'll take a run through. Now, if you take nothing else away from this, this is what to take away. You start off with your tasks. Look at the tasks your users are going to accomplish. Take a look at who your users are. Your users aren't necessarily just like you. And then the technology follows from that. First, the graphic here. This is a traditional Army task of painting rocks in front of the battalion headquarters. So I thought that would be good, for example, of a task. But bottom line is take a look at, when you're writing your code, think about it. What are your users trying to do? What are the common things they're trying to do? In Black Hat, Phil Zimmerman was talking about PGP and the difficulty people had making it work because hiding the infrastructure, the encryption and decryption infrastructure was difficult. But that's the task. I mean, people love to have one button encrypt, another button decrypt. And the closer you can come to that goal, the easier it can be on everyone involved. So taking a hard look at the tasks is the starting point. Next step is to take a look at your users. Like I said, your users aren't like you necessarily. Or they may be just like you. Your user may be just a small group of people in your immediate town or something like that. That's okay, but what you want to do is give them a chance to sit down and take a look at what you're coming up with earlier in the design process rather than later. And a little bit of time up front can go a long way. A half hour, two hours sitting them down and letting them look at it can go a long way to saving a lot of time and effort down the road. And I took these off Usenet. I had a couple of others, but I didn't think profanity. I didn't want a lot of profanity in there talking about. So you could have beginners or you could have advanced people. You have the whole range of people. You may have unexpected people using your program. If it gains wide acceptance, you could have a whole range of people trying to use it. You want them saying good things. You may have international users. This is an example from a McCaffey's virus scan. It's targeted to an international audience, another audience. And then once you've taken a look at the task and the users, then the technology follows. So generally engineers, myself included, I like to sit down and start. And then down the road add these things in later. But if you can spend a little time up front, it can be time well spent. Okay, and this will be a quick survey through some of the core principles of design. And no, I don't own a Macintosh or anything like that. Which are the traditional machines for graphic designers. This, but we'll take a quick run through this. Each one of these is really, there's like whole courses in each of these areas. But I wanted to give you enough so you're familiar with the term, the basic terminology. If you want more information, you'll know how to look for it. Cognitive science is what's going on in the user's mind. What type of framework. And there's also, I'm going to be giving you rules of thumb as we go through. These rules of thumb are essentially our best practices. And they've evolved by a variety of testing people, lab coats, videotaping people behind silver mirrors, observing how they react with different pieces of software. So there's a whole body of research out there. We're not going to cover it, but I did want to show you some of the rules, quote, rules. And then from there you can, at least if you're going to violate the rules, that's fine. But at least know you're violating the rules and you're doing it for a reason. A good example is Fitz's Law. Fitz's Law, and I know this sounds like rocket science, but when you're writing software, or if someone's trying to click on a region on the screen, the bigger it is, the easier it is to acquire. Imagine that. So the bigger it is, the easier it is to acquire. And if you look, for those of you staying in Caesars Palace, there's one big button on the elevator. Can anyone tell me what it was? Yeah, the casino button. It doesn't say hotel lobby. It says casino, and it's about six times bigger than all the other buttons, because they want you to find that. The hotel's been in business here in Las Vegas a long time, and a lot of psychology goes into trying to separate you from your money. This is an example I pulled off the web of just a real complicated interface that sometimes advanced users have a hard time with. We'll go into more depth in a little while. But the idea is you want your user interface to be intuitive and to allow exploration without people sticking a finger in their eye accidentally reforming their hard drive or crashing the system at the other end, if possible, to give them a way out. And also the idea of consistency is if you have commands throughout the program, they should be named the same way. You shouldn't, you know, change terminology, change placement of buttons, anything like that, it can confuse people. This is an example. This is a parody by Dak Rangas, who actually I asked him about using it in this, he gave me permission, but it's a parody of the Amazon tab navigation structure. Sometimes you'll see tools out there with all sorts of navigation all at the top level, and this illustrates that, you know, beware going too far. And we'll talk about techniques to counter that, but the bottom line is you can put the core stuff up front and provide some of the additional functionality, maybe an advanced section or something along those lines. This is also a parody website about color, and I know there's certain, like, classic hacker website colors, and, you know, that's your decision, but at least here's the textbook thoughts on it. People need contrast. That's why it's harder sometimes to drive at night. Actually, people prefer light backgrounds with dark colors. If you get away from that, you can run into problems. Color choices. If you have too many colors, then it looks like a technicolor vomit, and people have a hard time. If you selectively use your colors, then you can bring drug people attention to what you want to draw their attention to. And here's a couple of examples. In the top left is, again, from the parody website, and I have all these documented, and on your CDs is the briefing, and there's links to all of these if you want to go out and mess around with them or not. The top left has, with the cross flags and green lettering, a very busy background. Probably the people in the back have a hard time reading it. Actually, probably the people in the front have a hard time reading it. But you see websites that look like that. But then you look at some of the other websites, like, you know, professional ones focused on hardcore, just basic functionality. The bottom left, Google, very clear, very straightforward. And if you look to the right, and first a word about Jacob Nielsen, I don't know, who's heard of Jacob Nielsen? Yeah, Jacob Nielsen, in the graphic design community, I've heard him described as the Antichrist. Because he is bare bones functionality, nothing that detracts from usability needs to be there, and that's his website. It's very easy to use. It's pretty boring, but it's very easy to use. And also, if any of you decide to be a Jacob Nielsen fan, you can visit his website, which is useit.com. He has 57 high-resolution pictures of himself. I think they'd make great wallpaper or t-shirts. Seriously, I counted them all. They're 57. But anyway, if you're looking for more inspiration on more, putting some more design into it, the left are just two examples. And on the right, I'd recommend coolhomepages.com. It's not so much, it's more web-focused. It's not focused on, generally, traditional applications. But they've got a tremendous amount of websites, all categorized and ranked. So you can go out there. If you're looking for inspiration, I highly recommend taking a look at the site. Fonts, again, the rules. The rules are limit the number of fonts. What you're trying to do is avoid the ransom note situation. And with the fonts, a couple of fonts, limit them, use bold. If you bold everything, nothing's bold. If you use all uppercase, it's harder for people to read. But those are the basic ideas. But be conscious of the fonts you're using and limit them if you can, if you want to. Metaphor, metaphor is something that's very powerful. It allows people to map from a known concept to an unknown concept. But they can only be pushed too far. Two examples that are way overdone are on the right. The top right is the town metaphor. And if you take a look at it later, it's very confusing. Some labels are hard to figure out what's the difference between the conference center and the training center and the learning center. What's the difference? Bottom right is another overused metaphor, the library. So a lot of real estate's being used up for something that's confusing. But metaphor can be very powerful. Take the classic tape deck. It maps very well. People can pick up Winamp and immediately use it. Even if you put a snowboarder on top of it and distort the buttons, you can still pick up and figure out how to use that particular Winamp skin pretty easily. So if you can find a way, other metaphors, control panels, dashboards, those are things that people can relate to. And Microsoft was big on the desktop metaphor. We already talked about consistency, so I'm not going to go into it a whole lot. But there are certain expectations people have that things will stay in locations. They look for them in the past. The keyboard shortcuts. Keyboard shortcuts should be consistent throughout the program. If you've seen people say in Photoshop, really proficient at it, they can make it sing and dance. And it's because there's tremendous amount of keyboard shortcuts that have been consistent through all the versions generally. And it's extremely powerful. Feedback. And I'm sure you've all encountered this certainly on the web. There's different tiers of feedback that, again, this is driven by psychology experiments. But at the lowest level is 0.1 of a second. People expect, if you click on a button, that button's going to give you some sort of feedback at over press in 0.1 of a second. What happens if there's no response in a short period of time? People just start clicking, clicking, clicking, and then God knows what will happen. The next level is about one second. After they've clicked on the button, people are going to start looking for the reaction. Should the button come a window pop up or some sort of immediate reaction? If you get beyond that, beyond one second, say up to 10 seconds, that's when you should start thinking about some other type of feedback. And generally what's recommended is turning the cursor into an hourglass, but not forever because you don't know if the machine's locked up, but generally for about 10 seconds. Beyond about 10 seconds, that's when you start looking at some other type of feedback, like the progress indicator on the bottom right. Sometimes it's hard to figure out exactly how long it's going to take, but something, it can be a rough estimate or refine it as the code goes along. It can be extremely powerful though to let them know, hey, I can go get a cup of coffee, I can work on other things, and that type of thing. Testing is another area that you can take a look at, and actually if you're keeping a short list of things to take away is testing. It doesn't have to be extremely painful, it can be quick, down and dirty, but the idea is finding users, people who are going to be the type of people who are using your program, sit them down in front of it and observe how they use it. Maybe give them a list of things to do and see what they're clicking on, what they're thinking. Get some feedback, it can be quick, and if you do it earlier in the design process rather than later, it can save you time down the road. I know a lot of people in here are doing extreme program and getting their code down and dirty, getting it out on the street, but if you are really trying to make an impact, then think about iteration. You see next versions of software, so you can take the feedback the second time around and make it better. Another big, big area is information visualization, and this is just raw data from the command line, but information visualization struggles to find ways, better ways to present information to the users. Here's the same information presented on the X-Trace route in Neotrace, and you can see that, depending on what your application is, it can be very powerful to give people a better idea of what's going on versus the raw data. Same thing, here's a dataset from TCP dump, but then as you've seen that type of data in ethereal, it's broken down by the different layers of the OSI model. You can see really what's going on, much more functional visualization of the data. We don't have time to go into it. I'll point you to more information, but this is extremely powerful area, and it's worth thinking about. Another way, again, to look at it, not just ethereal way, is an etherate, same basic set of data, and it shows another visualization of it. Okay, we'll take a quick run through with GUI components, and like I said, these are just the rules and quotes. I'll take a quick run through, then we'll get to taking a look at some example programs. Radio buttons. The idea is it's a one to many control. Only one can be active at any time, and trying to limit them to six is the general design guideline, as well as setting a default. So I have some examples here. This up here, there's no default set. That's something to think about. One radio button really doesn't make any sense. What you're shooting for a checkbox is in that case, if it's just an on-off function. And then if you have a long list, it can be a problem. That's not in a particular order. If you did have a long list, then you put them in alphabetical order or something or group them by functionality. Put some spacing in there to group them logically. Again, a checkbox is just basic true-false true-false statements, and the general guidelines 12 per group. So you can see here, I used, I just grouped them a little bit better. It makes them a lot easier to take a look at. And on the right, these examples are an improper use. And the background, you only have one background color, so it can be confusing to people if you're not using a radio button. And there's just an obvious example of putting too many. You think I'm making this up, but if you come out of here a little more tuned in, when you leave, take a look, you'll see these things out there. So it does happen, it's good to know about it going into it. As you're designing the GUI, you can put it off the bat. The big thing to take away with dialog boxes and Windows makes it very painful is too many levels. So what some people do is they'll sketch out a tree of what Windows connect to what, and trying to limit the levels. Generally, the levels should be limited to two. That's the rule. And other concepts are, say, in Visual Basic, you can code it either way, are two terms, modal and mode less. And modal means it forces you to... It locks everything up and you can't take any other action until that window's been acted on. And a good example of that is in the lower left, right here. That's in, say, in Microsoft Word, if you want to send it as an attachment, there's an option file send as attachment. It locks up your outlook and it locks up your Microsoft Word. You can't do anything else. That loses focus. And it's behind some other window. You don't know what's going on. They're also... Well, yes, this is a good example of a modal dialog. Just kidding. You can only talk about GUI components so long before people start passing out. So I thought a blue screen of death would wake everybody up. Menus, the thing here to think about is the wording that you use very long. This is an example from UltraEdit. Very long menu list. And they have grouped it. They've put lines in there, gray separator lines that help alleviate some of the problems. But you can also see some of the terms they use can be confusing. There's open and quick open. They don't have shortcuts for all the different options. So if you're going to do that, at least think about what you're not doing, the menus are a little long. Another thing, and it's not just with menus, it's anything on an interface. If it changes, users expect it to be where it was last time. If things are changing on them, and the textbook example of it is in Microsoft Office again, you have the short menu. That's what's on by default. If you... That's what's on by default. But it's hiding all that other functionality. So the first time most of the people I know set up in Microsoft Office is they turn that off so they can see the whole thing. So think about it. If you have buttons and the labels are changing and that type of thing, it can confuse people. If you're going to do it, at least be conscious that it can confuse people. I won't go into too much depth on labels, but the big thing here is trying to be conscious that your programmer jargon doesn't necessarily meet equal what the users are going to be thinking it means. The user's terminology, not your own. They may be the same thing, and that's okay. The other key component here is the labels are... users associate the label with a certain component on the form or on the GUI, the closest one to it. So you want to put the labels closer to your... that component relates to rather than a lot of spacing because they may think it belongs to something else. Again, this sounds simple, but you'll see it. Key problems here in text fields are making them large enough. You sometimes see people with a file... loading files and that type of thing are selecting files and they'll give you a little window. One inch window for six inches of information. So if possible, make them larger rather than smaller. And if there's a common default, if it's the same thing over and over and over again, you can pre-fill that out for somebody. This is real. This is from Microsoft Excel. I went in and... I didn't move anything around. I just turned on all the different menus. Icons... you can overdo it. And this is something you'll see. If you have to... one school of thought is, if you're using a program and you have to use the tool tip over and over and over to figure out what the icon means, then maybe you don't want to use an icon. Maybe you want to just put the text there or something like that. And a good example of this, too, is icons don't translate very well between cultures. What does this mean for Americans in the room? What number, for example? Two. Okay, and Brits in the room? What does this mean in British? Yeah, it means FU in Great Britain and it means two in England or in America. You'll be surprised how things don't translate very well. A good test would be print out your... if you're going to use icons, print them out and ask a few people to tell you what they think they mean. That'd be a good start. Now that we just talked about specific components, now you're going to lay them out on the form in different places. The key concept here is the dominant reading order of the people that are going to be using... the culture that's going to be using your program. In America, we read left to right, so we look at programs we tend to look to the upper left, up there, as a starting point. So the most important thing, the first step in the task, often should be up there. Also, frequency of use. You look at the most common things, people read left to right and then down the page. So on the upper left, that should be the first thing, to the right of it should be the next thing, and so on. Okay, we're going to talk about... take a look at some different different projects, and I redesigned a couple and we'll critique some others. But the first thing I want to do is tell you that my stuff is weak, too, at times. And I wanted to give you an example, tear apart my own stuff before I start talking about anybody else's work. Yes, the question was when you're putting... and tell me if I got this right, when you're putting a man or help section associated with your program, where do you draw the line referring the user to that area? My recommendation would be you give them some immediate feedback, small, clear, concise, what the issue is, and then a common technique is you put a link to more information if they want more information, something along those lines. These are two programs I wrote several years ago. And I was into usability and interface design at the time and put some thought into it. But I did do some things to them that I would make differently. I would change now. This is a frequency counting program. And the idea is for basic manual crypt analysis it'll go through a text file and count up the characters and display a graph, a histogram of the results so you can see where the most frequently used characters are. The idea is what's the logical task that I'm trying to accomplish? I'm trying to take a look at a text file, calculate some frequencies and see the results. So where did I put my button to the first step where you select the file that you're going to use? I made it very small in the lower right corner. What I would change is I'd move this whole bar off to this side because the dominant reading order people would look over there first. And I'd put this select file very big up here because that's the first step. Underneath it I would put the calculate frequency button because that's the next step. I would also, and you've seen I think everybody's familiar with it, you can gray out buttons or gray out menu items when they're not active. I would make the select file active because that's the first step and the calculate frequency grayed out until you've selected a file. So it prevents the user from doing something they can't do. You can't calculate the frequencies if you haven't loaded the data. This is another variant where I wanted to take a binary file and do the same thing and take a look at 0 to 255 and again do a histogram across the top. But again I made the same error. I put the select file options down at the bottom. I would make those changes. And I made a conscious decision and I understood it was probably for me it worked. Can you read this? Can you read the results? Now I used the smallest, barely legible font size to fit it all in. That was a conscious decision. Another way that I'd probably do it differently now is filter out the results that didn't apply. A lot of these there were zero. You could gray those out. You could have it pop up in another window with larger and you could scroll through the list or something like that, maybe sort the results and I went out and actually asked the artist for permission to use these and the links are down there so there are other interesting graphics. First off I want to make it very clear that the programs we're talking about are great works of technical expertise. People put a lot of effort and a lot of time into it and I'm here because I use these tools. I've used them to teach and I want to contribute something back. So I'm not getting on anybody's case with cheap pot shots. Like I said, my own stuff has plenty of errors but we as a community can move forward. So I thought WinNUC could be a good starting point and what's the task here? What are people trying to do? You're trying to WinNUC a Win95 box. So what are the components of the task? You enter an IP address you enter in a message and you click the button. So what I tried to do thinking back to the topics we talked about I tried to redesign it and I put a small initial state up there and then a bigger one and some of the thought I went into it is I tried to make the labels a little more intuitive and again this is a bit of overkill on a straightforward program like this made the font sizes bigger made the text box bigger and then one big hunk and nuke button and tried to line everything up to the items they referred to. This is another example and this is a Netbus 1.6 There's a Netbus 1.7 where the interface is very much similar and then they've come out with a totally redesigned interface a greatly streamlined interface for the Netbus Pro. So I took this what do you think about this? Anything jump out at you? Yeah lots and lots of buttons and I used this in the classroom and had people try and figure out what use it for the first time and it's kind of confusing they have different functionality mixed in together so what I did was a simple redesign when you look at the task you're trying to connect to a server so you need an IP address where you're just entering the IP address you connect to the target and then the remote activities area button until you're connected is grayed out then if you look at the next one you click connect the red turns to the green arrow points them towards the remote activities and away you go so then it pops up and I've grouped the different activities on a separate pop-up window so I hid the functionality until it was relevant and that's what this is the next window that opens and I've grouped it by I sat down and put some time into it how to logically group the things and this is just a partial implementation I just want to show you some of the concepts we were talking about and another thing a decision I made is up there I decided on the first version I had the connect button you click once it connects you click it again it disconnects but what I did is separated out where one will gray out and the other will turn on based on whatever state you're in okay sub seven what are your thoughts? what's that? yeah it's a lot better than that bus the things are grouped into a menu and that's what I thought would be something it would be interesting to take a look at again I used this to teach so I stood over people as they tried to use sub seven and I broke out the menu here can anyone tell me the difference between advanced miscellaneous fund manager and extra fund as the menu options so something to think about if you're going to redesign this would be to take a look at what the options are underneath those underneath those areas and make the change labels around a little bit to make it a little more clear that would be my recommendation super scan by foundstone they put a lot of thought into the interface and you can see they did things a little different they have a clear background they group things together into logical groupings and they have a host name lookup it depends on their usability testing what's the first step in this process is it entering an IP address if it was entering an IP address I would probably put the IP area up here as the first step and try and follow the logical flow and see there if there's some options and you see this on other programs if there's all sorts of advanced options that people never use or rarely use then you can hide them put them under advanced option area get them out of the way, prevent people from getting confused and again I want to reiterate these people have written some awesome code it does amazing things they give it away for free so I'm really like I said they've done some amazing work this example of zone alarm which is a it's a given way by zone labs and with their purposes here it's a good example of conflicting goals because if you're trying to make money with your software this thing is half add for zone alarm pro and it's also firewall so they've mixed in this functionality it can be very painful you think you have this option if you would click this button in zone alarm pro it would have done what you asked so there are tradeoffs that you'll have to be conscious of alright where to go for more information one book I'd recommend that's written for people who actually do things write code it's very well written, lots of real world examples very light on the painful theory underneath is the gooey bloopers book here and I'm not going to kick back for anything like that but I've read all these Jeff Johnson's gooey bloopers if you read one book it can be time well spent if you're interested in design not just not just user interfaces but big picture design how things are a good example is has anyone run into a door you go to the, okay I'll tell you I have I've hit doors you think they swing one way Caesar's palace has a big handle on the door a big honking handle this big that looks like you should pull it and they have a little label over the top that says push so it's filled with examples like that again that's one of the classics it's quick reading again separating us from our money the humane interface is the next level below gooey bloopers so I probably read them in the order I just went through them information visualization is another area that I found a lot of people who are into programming enjoy these books this is Edward Tufty he's a classic these are this whole field is art and science so he his books are half art book half science and they're very interesting very highly rated and fun to read he also has a traveling road show that I went to if you get your employer to pay for example they'll buy all three books are included and again that's time well spent a good example that he uses is the challenger explosion he shows the actual slides that the engineers used to brief the managers of the decision makers to whether to launch challenger or not and it was clear there's no way you could figure out from how they displayed the information that they could have made a logical choice not to launch but then applying some of the techniques he goes over very powerful stuff and it's clear there's a problem that the overings fail at certain temperatures and then just some other books that you can take a look at if you're interested and there's websites associated with all of these well they have some good information for free web pages that suck by Flanders and Willis as well as two by the great Satan Jacob Nielsen and if you're interested engineers in design don't necessarily go hand in hand but I'm throwing this out here the non-designers design book our non-designers design book is a good starting point as well if you just want some basic concepts it reads very quickly if you're interested in deep knowledge the next level below what we were talking about designing the user interface which Schneiderman at the University of Maryland is a good, it gives an end-to-end coverage of the whole field with lots of deep links into the actual research of why those rules exist and then if you're looking for cutting edge stuff that's where you get into the association for computing machinery the specialist interest group for computer human interaction and those conferences that site will point you toward other conferences of the cutting edge stuff alright that's all I have and I've got a couple minutes so go to your questions yes the question was is there a better way if you hide things under advanced options is there a better way to word that extra options more options you could put it in a different location maybe not as visible or something like that other thoughts on how to relabel it use very, yeah do you mean some like rite of passage wording or something like that what else generally people respond to having light or pale background colors it's just clear and easier to understand people have problems discerning there's colorblind people for example have problems discerning between red blue there's red blue colorblind and there's a large actual percentage of people out there I think it's 10% of people are red blue colorblind what's that 14% if green letters on a black background can be very hard to read take a look at it there's a certain, if you're designing it that's fine, if you want it to look like that that's fine, I've seen it work quite well if you're trying to emulate the old school CRTs or something like that but understand it is easier if the background is like white or very pale colors with dark letters like black letters that's easier to understand yes that's the idea that you place it based on if someone reads right to left that's where the most dominant controls are it's awkward for us as English speakers, as Americans to feel comfortable with that but that's what's been proven to work better for those people and it'll be in their language I mean if it's an English version generally it would make sense I think it depends on who your market is if you're looking at a market where you want a different tier of users to actually have ability to use the program that can be worth the cost if you're trying to sell to a different market that isn't comfortable with the command line that could be worth the cost because they wouldn't be able to use the command line another way to look at it too is if someone else comes out with a product that has the same functionality that they could have an advantage in the marketplace I'll take one more question if anyone has one what's a good percentage the question was at what point along the design process do you bring in users to take a look at what you've done and really from the start before you even hit one key you bring your users in some people actually bring a user in on the design team and let them work with the designers, a domain expert that they're comfortable they and their peers will be using it so you can bring them in early so really the best answer is through the whole thing earlier is better than later and earlier is cheaper than later as well because you don't have to go back and make changes that's all I've got for you today and thank you for your time