May, 2003 – Web Design Standards: 10 organizational secrets

Dr. Eric Schaffer: Welcome to this broadcast from the usability broadcast network and what we're going to do today is we're going to be talking about usability in the area of standards. We're going to talk about user interface design standards, we're going to give you some insights in terms of the organizational secrets. And we're really amazed, we've had quite a few of these broadcasts and today we've had more downloads of the white paper on standards than any other broadcast in the last 2 years. We've had an incredible amount of interest. And that amazes me because standards are so terribly boring. You might want to go away now. I mean I remember going and teaching classes, and I've done it for the last 20 years on standards, and I'll ask people how many people in the audience are excited about doing all your interface design under a strict set of screen design standards. And often there's one person in the back who kind of half heartedly raised their hand and everyone else looks uncomfortable. And so standards is kind of a boring topic and a kind of a scary topic. And yet standards are key to making good user interface design. They are key to efficiency and they are key to consistency and quality. So we're going to find that standards are in fact not a miserable, bureaucratic mess. They are something that's efficient. It's a facilitator of creativity, and they're really worth while. And so what we're going to do today is dig into that. I'm going to share first of all the right kind of standards and approach to standards that you want to do good website design to do good applications, web applications. I want to share the secret of what a standard should really be. And then what I'm going to do is go into some depth into what makes the standard get really well implemented, the organizational issues in getting acceptance of a standard, and the way that you go about creating a customized standard. So I'll share with you a lot about how we do it here at HFI and as we're working through that I'd like you to please ask questions. Because the format of this, I know there are some new people here, the format is we're going to go to the main presentation and during that time you're going to see there's a button here where you can click on it and ask questions. After that presentation, which takes about half an hour, I'll be taking those questions and answering many of them right in this broadcast. And so please participate in that. We have a couple of surveys, please participate in those as well. So we're going to go ahead now and go into our main presentation on standards and going into the 10 secrets of standards from an organizational view point.

We're going to be talking about doing user interface design standards, and the first thing I want to bring out and it's really important is that user interface design standards are not the full solution to the issue of usability. You can have the very best user interface design standards, you can even implement them well, and still have very poor applications, very poor web sites. You can fail from the point of view of usability engineering because the standard needs to be part of the holistic program. And this holistic program has to include having training, having methodology, having infrastructure standards, having the right staff to work on the projects, and so if it's not integrated into the corporate culture, if it doesn't have the right infrastructure, it doesn't matter how good this standard is because it's not really going to solve your full problem. But it is a critical step and I would go so far as saying that there is no professional user interface design group, or organization, or individual who would proceed in developing user interface without the user interface design standard. It's unprofessional to do that and I think you'll see why as we go through. And I'm going to start, I'm going to talk a little bit about what a standard is, what role it plays, what makes a good standard give you a feel for that, and then I'm going to talk about some of the secrets that we've discovered over, we've done over 155 standards projects at this point, so we're actually really bored with doing standards projects and please don't know. But we've gotten good out of - we've learnt a lot of things and so what we'd like to do is share some of those insights about getting the standards to work organizationally.

So the first thing I'd like to bring out is that there are actually three different things that people mean when they talk about standards. And those are methodological standards, design principles, and design standards. Now one of the things that sometimes happens is that those things get muddied up. People miss-communicate and even worse, people try to cover all three in one big document that's not very well organized and you get something we talk about as standard stew.

So when we talk about a methodological standard, we're talking about what is hopefully a user-centered development process. It's a step by step job aid that tells us what we need to do to develop a good usable application. And that's critical to have. It's critical to integrate into the technical process. It's critical to be a part of the organization, but it's a different kind of standard than the other types of standards. And it needs to be made separate and presented separately and supported separately. And I'm not going to talk more about that today.

There's a second kind of standard, and that standard gives what I think about is fatherly advice. So it might say things that I've seen one that actually says things like right clear error messages. This is not very helpful. Good ones read use short words, use short sentences, write in the active voice, left justify your fields and labels. So it's the design principles that go into that type of standard. And design principle standards are very nice. We can sell you one sheet, but for the most part they don't work. Because nobody ever sits down and reads the 563 principles to good user interface design. We've had books like that for 15 years now and it has a very marginal value. In fact what I would say is generally, rather than investing in putting those kinds of design principles into a document, you are far better off doing training and so wide spread training, specific training for practitioners, and certification those are things that really make a difference because that allows people to internalize the ideas and the skills that go into a design principle standard. And it's very tempting as we go into doing the design standard that we will be talking about to what to put in, a list of studies that support the design, the rationale behind every design decision and what you get is a huge great thick book that no one ever reads. And so the next type of standard and that's the type we're going to be talking about is a design standard and design standard is more like the letter of the law. If a design standard works, what you find is that as people move through a website, move through a family of web sites, as people will go to different pages within a site they have the experience, oh I have seen pages that look like that before. Oh yeah, it works the way I expect. And so when you see examples like this where you have a huge amount of creativity, but in this case creativity is really bad because the user is going from place to place and can't generalize their nudge from one place to another. And so the redesign of that what's happened is we have much less creativity and we have a standard being applied and that standard means that as people navigate every time they go to a new place they don't have to discover the navigational paradigm or the controls for that place. It works like the last place they were in. And that means people can concentrate on the content. That means people perform better. So that's the idea of what we want to accomplish with the design standard. If we have a good design standard, as people go from page to page they have that sense of consistency and that's a very good thing. So how do we get that done? There's a trick to it that I came up with at the end of the 1980s. And this trick was really important. The way I came to the trick was that I looked at the way that coders that the programmers try to makes strings consistent in the main frame environment. And what I found was that what they would do is they would copy examples. And so people tend to make consistent interfaces by copying one page – now the bad thing is sometimes those pages were really awful and so they were copying bad practices. But the copying told me that that was a natural thing to do and I started looking and I realized that there were only may be 10 or 15 types of pages that accounted for 85% of the development that had to be done. So the task became to piece the pages together into making this whole website or in that case a main frame application. And then we had the desire, the concept of design templates. And that's really the key. Good design standards always will be based what we have as their pillar as their foundation. They'll always have these templates. So when you look at your environment, you're going to find and in the web world it might be a little bit more of the main frame. But you might have 20 different types of pages. And those pages are representative of the different kinds of tasks that people do. So if you look at what people do in any kind of environment, there are only so many things they do. So they might do tasks like taking data and putting it into the computer. Then I need a page that's a form that allows people to do that. And so the design process moves from I'm going to try to think about what I want the user to do we hope and then design each page in detail to looking at what the user's task is and based on the user's task picking the kind of page that really makes sense. And so that change is huge in that it makes it so much more efficient to design, it makes it so much more consistent at the end, you go through you say the user's task is this, what page type do I need. And then you pick that page type and the first thing you need to see is a good example. And most developers will look at that example and go oh I get it, that's what a button menu should look like. And they copy that example. End of the day that's the main thing that happens. And that means that that button menu example needs to be really representative of the very best practices. And that means a lot of things. It means it's going to have certain things that are standard, that will cue the user that it is a button menu and allow the user to have the sense that it operates the way they expect it to operate. So you'll never have a button menu something that looks like a button menu that has fly out menus built into it. Because that's not allowed. Because this is a button menu and I expect it to work like that. I need some cue if you're going to have a fly out menu that tell me that that's what you're doing. It needs to be good beyond just the standard things though as well, because it needs to be an example of best practice. So the wording, and layout, and color, and highlighting, and all of that needs to be representing what you want it to do, because this is kind of like the DNA. And DNA doesn't get better as it gets used. So it tends to degrade if anything. So people are going to copy that and not copy it perfectly. So it better be good to start. You better have thought through all of the pieces. So if we're doing designs, the designs that we show if we need to be 508 compliant, then that design better be 508 compliant. If that design is going to accommodate elderly users, then I better do that, I better make sure the fonts are a little larger. I need to make sure that this represents what I really want.

And as I have these different page types, here's another example of wizard. I need to go beyond just showing the example. I need to tell people what the standards are and I need to document when to use it, how it operates. We need the standards. We even provide a prototyping tool that means I can just go click in and now I can very quickly mark up the page like that and reusable code to go with it as well, html, cascading style sheets, image mask and all that so that I can develop it faster. So that's the core idea of what a standard should be. We have three kinds, but we want to isolate that design standards for people.

I have a question that I'd like you to answer. Which of these kinds of standards do you currently have? Do you have a methodology that's user centric and we only count it if it's user centric. Do you have a template-based standard like we've talked about? Do you have both of them or neither of them? Go ahead and select it on the screen and let us know what your status is. And we'll share when we get to the end of the web cast what those numbers look like. So go ahead and pick that now.

When we provide prototyping tool, one of the things that we've done is we've just put it in power point. Now that's strange. Whey did we use something that's sort of simple and (inaudible) as power point. We did that because that way even somebody who is may be a marketing may be doesn't know html can mark up a screen we'd just they didn't copy over and get something that's reasonable that'll fit on the page and they start with a standard page type so it's a much better position to be in.

The last thing I'll say about standards is that what they are is you need these templates. You also need general presentation rules. There are things that go across the types of standards that you've got. So if I'm talking let's say like error handling, error management happens on forms, on wizards, all kinds of pages and I don't want to document that for each one so there's a separate section that covers these general principles. A lot of times these things get called style guides. And style guides are useful to a point, but it's really secondary to keeping these template based standards. That's what makes the difference.

Now why are the standards worth while? The first thing I'll say and I'm going to make an offer to you right now. If you contact us we will send you a copy of this little demo because it is so powerful that I love doing it. And it's a little maze it's like a little toy. And you run it and you bring one of your managers up you say here, take Herman up here through the maze to find the cheese. And the first time it works very properly. You press the right arrow and Herman goes right, left arrow Herman goes left. It's great and it takes about 17 seconds. Then when they get done just press enter. And say now do it again. Level two has something different. Now the keys are all jumbled up. Like left arrow may be goes down. And the right arrow may be goes left. And it's very difficult. It takes about twice as long to do it. And then they makes lots of mistakes, but you're manager's going to be able to adapt. And then there's a third version where they get done with that press enter. And the third version, the keys don't work the way you'd expect, but they also work differently in different parts of the maze. And so what you find is you can't adapt to what the rules are and it's really hard to get through. And also sometimes you're almost up through the maze and it will move you all the way back, because sometimes bad things happen to you when you do things that would otherwise be perfectly normal. So if you contact us, we'll give you a copy of that. It's one of my favorite toys. So one of the things that it illustrates is that standards are critical for end users. And there may be a huge difference in terms of how users can perform on a system, how much training they need, and all of that. The second thing is the development cost. And we had a web cast recently with the Royal Bank of Canada and they put in this kind of template based standard. And they're saying that it saves more than 10% of their overall development cost. And it makes sense if you think about it, because you don't have to sit down well how am I going to make a wizard work, how it should be laid out. And then once you say, well, I have a template for wizards, you can go code so that putting a wizard in place is really efficient. And so in a sense, just the inside of having a good standard will save you enough to have a real complete usability effort. It costs about 10% of your overall development budget, just that. So it's good for users. It's good for development. It's unique that, I want to try a little exercise. So here's the type of page you've probably seen before. You put in search criteria and then you pick this button and then you get a list of hits. Now there is a button that you need to press in order to get those hits. And what would you name the button that users use there? Go ahead and take a second, write it down, what would you name it. Okay. Now I'd like to try something. Which of these did you pick: find, search, submit, fetch? Hope not too many fetch but may be or some other word. And we're going to go ahead and answer that question and we'll take a look at the results at the end. But I'll tell you that I did this with a group of 120 people at a major bank and what we found was we got 22 different names for that button, 22 different names. And so if you think about it in development, somebody is sitting out there you have to pay them to come up with that name and then the user is going what does fetch mean? We should take off like 2 points if you picked that.

The last thing is the maintenance cost. So it saves users, saves development time, it also saves our maintenance. Maintenance cost, if you think about it, technology keeps moving. There keeps to be new ways of doing things and so what happens to your template based standard when there's a new control and there's a new ability. It may have to change. And that's a bad thing, but think for a minute. If you have a design like a wizard, and you have may be 50 or 60 different layouts and solutions to how a wizard will work in your internet or in your public web, if (inaudible) that may be a public thing, and then something changes, when you go to implement that change, isn't it much easier if there's just one way that it's being done? So even though you may have to change the template-based standard, it's going to be much easier when you have a good solid template with just one way of doing things than if you have a lot of waste and you're trying to chase that on every way it's gotten done. So we see hawing a standard is critical. In many cases you need to have a customized standard that's going to fit with the way your company brands with a task flow, with the conventions people have in the past. And we have a methodology for building a customized standard. And that methodology has been refined over many years and it starts with a kick off where what we do is learn about what the environment is and what the conventions have been, and what kind of tasks people do which helps us pick the page types and design initial pages. And then we use an internal committee to review the pages and make decisions. And I'm going to talk a little bit about how this works in the social environment of a corporation or any kind of organization, a government organization and what the success factors are from that point of view. And the first thing I'll say is that going into the standard you need to identify the stake holders and make sure that they feel listened to. There are two kinds of stake holders you got to think about. One are people that are your executive stake holders. And there are people perhaps they are your chief user experience officer, perhaps somebody in marketing, but these people have insights about where the company is going, what kind of task will be done in the future, what kind of brand values are needed that are critical and you need to listen to those people, but by the way, you don't put those people on the committee. Because you don't want an executive vice president marketing sitting there discussing whether there's going to be a contact us link at the bottom and it's going to be simply called contact us or email us or saying comments and that's just not going to work. So the committee people are very different from the stake holders, okay.

The second thing is we need to find who the executive champions are and we need to make sure that we have their support. You know, one of the questions that comes up a lot is what can the scope of a standard be. Can I have a standard that covers my entire public web? Can I have a standard that covers my entire internet? Is it possible? Yeah, it is. How about the extranet? Can I include that? Can I include all three of those? Can I include applications? Well, there are some limitations in terms of how far you can go, but the main thing is what is the span of control of the top person. At least one of the big factors is what is the span of control of the top person who cares about standards, because sooner or later issues are going to come up and if you don't have somebody who's going to support the standard across their full range of responsibility, then it's going to be pretty tough to get the right kind of decisions made. So if you're going to leave somebody who's responsible for the internet, the extranet, and the public web, then you actually can make a standard that covers all of those things and get it supported. By the way, it's hard to make a standard that goes across a browser environment and a window system because they have somewhat different conventions. But getting support from the top, getting that push is very important to getting the standard implemented.

We also have to go through a process of data gathering that really guides us to fit the standard exactly to the environment. And there are all kinds of things that we discovered. For e.g. we were doing standard for a bank recently, and we realized that the bank has so many times when customers need to confirm that a transaction's going to be done. And so we created a confirmation page type for them. They needed it because that was the nature of their task flow. We also have to know people's conventions like at the social security administration have you ever seen a button that says clear? Where you press the button that clears the window or screen? At the social security administration clear as a button means clear the payment to be made. And so there could be some buttons that say clear and wipe out the screen and nothing happens, some buttons that say clear and pay it. And if you have that case somebody's going to be hungry. So what we need to do is change their button to erase so that we don't have that conflict. And so understanding what the past conventions have been is very important. And finally we have to make sure we understand where things are going, because you don't want to write a standard for what is now because you'll miss it. I remember I was working for a major auto company, and we had a very complex page type that was built for complex web applications called a working list. And the working list, everybody in the committee looked at it and said we'll never use anything that complicated. And I suggested you know you might want to keep it. But they said no we don't think so, and so they made that decision and we took the working list out and then about 3 weeks later they got a request for exactly that task and they put it back in because that growth in the web utilization moving from the sure ware to mission critical applications requires more sophisticated page types. We better try to reach into the future so that it's not absolute when it first comes out.

The next thing is the committee members are some of the key staff in the development community in the company. There are people whose time is very valuable. The committee members should be people who are the key opinion leaders where if you had a user interface design question you would go to them and ask. And that's important because they'll help make good decisions. And it's also important because it will help to gain acceptance for the standard because if those people are saying this is a good standard, if they've bought into it, it will help acceptance. In any case, when we do a standards customization project realizing that these people are very valuable, they don't have extra time, and they can get a little bit impatient, we make sure to half the process to minimize the amount of time that we require. In fact, the whole committee process is only 6 days long. And then there's a training process. So making sure that we use those people's time to make good decisions, but not to do the light work is very important. In doing the light work for the committee, what we want to do is make the process really efficient in this way. So I remember going to my very first standards committee meeting. It was the BSP the Bell System Practice on Human Factors. And there were about 15 of us in the room. And we sat around and first went okay a standard, what would that be. We have to make rules. This wasn't the early age. And then we said, well, hm, okay, let's start making rules. I think menu should be normal having 10 items. And then somebody else would say 7 items plus or minus 2 and we would argue about it. And it was working from scratch and it was a long and painful process and we never knew when we were done. If we go into a committee and we say okay, here's a list of the 15 types of pages that we think are needed in this environment, is it complete or is there anything in there we don't need, we've done the work of setting up an initial straw man and the committee can react to that. It's very efficient. We also have the case if each of those designs I come in and say here's an example of a form, is this the way you want a form to be. And you can say no, no. I think we need to use an asterisk, we'll have a triangle, or you can say no submit is a terrible word. That's fine, but you have some place to start and it's a very concrete process. So having that starting place important is very key and making sure that we do the work of writing the text and so on is very important.

Then sixth, we have a fixed process and an iterative process. It's scary getting on a standards committee. I mean history says standards committees go for years and never seem to get done. And so when you can say look it's going to take 6 days total and it's going to take 6 to 8 weeks, that's very different. And so being able to make people confident that it's going to be done in a limited amount of time, and at the same time have an iterative process where we are going in and we have getting feedback or making changes so we get the right kind of design, that's really a critical success factor.

I remember having a lot of committees where people would be there who'd never had interface design training. And what we found was that we would teach interface design piece by piece and painfully through the class. And I never ever want to do that again. What we want to do is make sure that the committee has at least had basic training. We'd love them to all be certified usability analysts who've been through you know a solid program, the more they know the better, but at least a 3-day web class that we need to put the people through. Because I don't want to explain why I want to left justify and I want to be able to do we can't do that because that creates chromostereopsis and then have everyone go of course and not have to explain chromostereopsis again. So giving training is key to making the committee go quickly and that's part of why we can learn in 6 days and not more. One rule we have about standards that's worked very well is that HFI never gets a vote. We don't really build in standards committees anyway, but the idea is that the standards committee owns the standard and I'd much rather have a standard that's 70% right ergonomically and people buy into and feel that it fits their environment than something that Eric likes a lot, but nobody's going to use because they don't feel that it really is going to work in their environment and they don't really feel that it's theirs. So the committee owns the standard and getting that – and this by the way, committee you are seeing as one of the largest you really want more like 8 or maximum 10 people in a committee. This will have quite a few more.

It's scary putting in a standard in terms of the cost limitation. Have you ever thought about what it would take to take every page in internet and suddenly convert it into pages that fit a standard? It's going to be ridiculous. You can't do that and because of that we always grandfather in standards. And that's to say the rule that usually works is if you have a page that you're designing from scratch, you must follow the standards. If you are redesigning a page, and you are changing a substantial amount of it, 80% of it or whatever, then you must follow the standard. But if you are not changing the page, then you don't have to go in and suddenly try to change everything, because it's just not practical. So a grandfather in clause is essential to reasonable implementation of the standard.

And the last point that I want to make here is probably the most important. A lot of people come to me and talk about wanting to put a standard in place. And one of the things that I always ask is do you have the resources? Do you have the game plan? Do you have the will to implement the standard? If you don't, don't build it, because it will be shelf ware. And that means that the standard needs to be disseminated. It needs to be supported. It needs a process of training so that people understand what the standard is. It needs consultative support so if questions come up there is some place to go. It needs to be a living document. And I'll use the word enforcement. There needs to be some level of enforcement. Now that will vary depending on the corporate culture. Some companies, you can ensure that it fits with the corporate culture to have rigid rules. You do not proceed unless you follow the standard. Other companies, you can't do that, but the least you should do is have feedback. So if somebody doesn't follow the standard, they hear about it. We notice you've reinvented how to do a wizard. And you might want to follow the standard for this reason that if they've been trained, they'll go oh okay, yeah, I really understand why that's important. Because I played that maze and I didn't want to play the level 3 of it. So implementing the standard has to be on the agenda. One of the things that I think is very important about the quick way that we develop standards at HFI is that by the time you're done with a 6 or 8 week development process, there's still energy left in the committee to support the standard. By the time a year is done or more, I've often found committees that you know, we're getting the standard out and we never ever want to see the document again or talk about it. So it needs to be much more emphasis particularly in the internal staff on implementation, dissemination, and support, and don't have all your energy used developing the standard in the first place.

So I've given you some insights into a few insights anyway into how to get a standard to really work in an organization. We have a white paper on it as well and the last thing I want to say before we go into questions and as you are going to I hope you have been submitting questions, is that standards are a critical part of design. But they should always be thought of like the standards in Jazz. You know how there's a standard in Jazz like the Saints Go Marching in is a standard. And you can sit and write down the Saints Go Marching in these are the notes of the Saints Go Marching in. But it takes a great musician to take that standard and make it really art, to make it really work, and to make a great tune out of it. And that's something that's also the case with user interface design standards. You need to have a standard. But you need to have great artists, great user interface designers to use that standard well, use it in a way that really works for the end user.

Okay, so we've been getting questions throughout the web cast, but I'd like to ask you right now if you've got anything that you're wondering about that you'd like to hear a little bit more about. There's a button over here and please we're still taking questions and will be for the next few minutes. So please give your questions in and we will address all that we can. So I've got some questions here and let me chat about them.

Dr. Schaffer, is there any reliable research on cross cultural factors in web usability? In other words, does the audience in Taiwan or Mexico have the same usability concerns as the audience in the United States?

And the answer is that there's a huge amount of research, and let me say if I can pull it together for you a little bit. First of all in terms of usability and design, there are a number of things that are basic psychophysics and are independent of cultural context. All people throughout the world will experience chromatic aberration red text, blue text if it's highly saturated, it's going to look fuzzy. If you put red text on blue text you'll have chromostereopsis. It will look like it will float. So the physical aspects of human beings, the psychophysics, the basic human information processing is very much the same internationally. However that said, there's an enormous field that's known as I 18 N Internationalization and you'll see it abbreviated I and then 18 and then N. And that field looks at cross cultural differences and HFI has a group that works really solely in that area and the results are fascinating. We've looked at the issue for e.g. of what's important to people in a web site design and we looked at a cell phone design and what people cared about in 8 different locations around the world. We found that there was no overlap. There was no factor in the design of the web page which was very important in all of the different locations. We found cases where features of a web page that were most important in one were least important in another. So there were great differences in what people prefer, what people care about. There are differences in color preference. There are differences, of course, in language and fonts and in data representation. Even things that we thing about in the United States as you know obvious like the way that we would write a million with the commas that's not the way they do it in other parts of the world. So there are so many differences that it's really foolish to think that you can build one interface and have it work well internationally. The differences just go on and on. So there's a lot of research on it. We could start you reading now and keep you reading for months. So that's an area that's fascinating, an area with a lot of good research depth. So thank you for that.

On the issue of social security administration, and that was what I talked about earlier with the clear and erase button, would you not advise them to change the clear terminology that they use internally to suit the needs of the user who may not equate clear to submit? This is instead of changing clear to erase.

Okay, so the question is this. If you are doing a standard and you've got a group which is not following the international standards the de facto national standards, whatever it might be, should you get those people to change or not? And the answer is it depends. It depends how firmly entrenched those conventions are. It depends how expensive the change is. Let me give you a couple of examples. For e.g. at the social security administration, the idea of the error of pressing clear and thinking that you'd made a payment and it didn't happen was pretty severe. It means somebody would go hungry literally. And that's not acceptable. So in that case we hesitated to make that change. In other cases, I remember when we went from the main frame world and you pressed what was let's say tab, tab, tab, tab, enter and then we switched when that changed, a lot of companies said we are going to fake it in GUIs and we are going to do it the old main frame way. I think it was the enter key. It was actually enter that moved the tab and then in GUI suddenly enter entered the whole page. So they said well that's too big to change. We're not going to make it. That wasn't such a good idea, because you had the whole world moving in that direction. People started experiencing some applications doing it one way, some applications doing it another way, and so there is a strong rationale for going ahead and converting and doing it the way that the world is doing it. The thing I would say there is that's a decision that you need to make in context and with the standards committee working actively from a business point of view making the right decisions.

Okay, very good. Okay, another one. We think we should have a standard to save our sales time like you said, good, and to make our interface consistent, that's a good thing too. However, we cannot convince our managers to allow us the time to make one. They also won't spend money for someone to help us. What can we do?

I guess the answer there is that a standard is such a clear no brain or business decision that it's just a matter of sharing with executives and managers the rationale for having a standard. One of the things that you can do is to give them experiences like show them the actual examples in your interface where you have the same basic kind of page and sometimes you have enter and sometimes you have submit and sometimes you have next and so that they can see the inconsistency and I think that conveys a lot. I think that maze example, and by the way, we've now we had enough requests that we'll very quickly now be putting the maze on to our main website. You can actually use it from there and if you go to the humanfactors.com website and pick goodies and downloads, you'll see mouse maze listed there. So that should be up and running by the time you try it we hope. Then so it's really a matter of education of managers. Now the other side is that sometimes standards are so very time consuming and so very expensive that I can understand why a manager would hesitate. I know that I just met with a group in Washington and they'd spent a year working on standards and that standards committee so far has agreed to only the design of I think it was 8 different widgets, 8 different controls and displays and that's it. And they're still working on all the issues of templates and still not anywhere near where it needs to be. It's been a full year. We were just talking with a colleague who is actually a usability specialist and wonderful, but he's been at a particular company for years, 4, 5 years now and still doesn't have a web standard in place. So in cases where the managers look and say this is going to be many years to get a standard done I can understand it. But at HFI we have a process that puts a standard in place in 6 to 8 weeks. And it works reliably. And when you look at that kind of level of expenditure, it ends up being a no brainer for a company of any kind of size. So I'd suggest that it's really a matter of communication. And standards are definitely, definitely worth while. They are worth while in terms of the development time, maintenance, and also the user experience.

Let's talk about the audience surveys and we've got a couple here. The question one was what do you currently have and 13% have just a user centered methodology. That seems to be a rare case. 30% have just template based standards. So that's good, that's actually coming up and I'm very happy to see that. That shows some real growth in the industry or at least a more sophisticated audience. And 38% have both. So we're really seeing some good movement towards one of the key elements for institutionalization of usability. We also have 19% that have neither and I guess those folks need to get moving. So interesting results there and encouraging I think for the industry.

We also have an audience survey where we said what push button would you pick? And 75% picked search, 9% find, submit and 3% picked fetch. So we got a pretty good distribution and I think I may have slit and said search at some point in the briefing. That's my suspicion because most you get a more of a slit between find and search. But you can see how you do get that diversity of design decision. So that was interesting too. More questions.

Are we still taking, I think we are still taking questions. If you have any more questions, we'll just take a couple more here because it seems like we've got quite a few coming in, so. Would I please explain again who should be on the committee?

Okay, the standards committee is not a group of executives. Don't let any vice presidents on the standards committee end of story. These are people who are the key opinion leaders in the design. They may be some technical people, some development people, some business people, some human factors engineers, but they are the people who if you are sitting in the organization and said I have a question, is it better to use tabs or a left navigation preview. And you want to ask somebody that question who would you sit down with? Those are the best people and you'll usually find somebody like that in all the major areas of the organization. So you try to get a distribution in terms of expertise so you need somebody technical, you need somebody with a usability background and so on. And then you need people also spread throughout the organization so it isn't just from one area. So as representative of the group as it can be, you do not need and it is best actually not to have users, end users on the committee. On the first place you may thing well that would be a good thing because they are really able to say what it's like in the field. But they tend not to have the expertise to make the types of decisions that have to be made. So in the data gathering process before the committee will often get a sense of who the users are and learn about them, but you don't want to take somebody who's been working as an accounting clerk or a marketing manager, a strategic manager or something like that and bring them in and say okay now we're going to sit and talk about whether to use tabs on the screen or not. Because it's not their expertise and not their interest and they'll be bored. So those are the people on the committee.

How do you suggest implementing a standard when the development is outsourced?

Okay, so couple of pieces of that. When you say implementation, I'm not quite sure what you mean. And there may be a couple of different interpretations. One is implementation in terms of the actual creation of the standard from a problematic point of view. So whoever is outsourcing and if you've outsourced your standards, the vendor should deliver the standard as an internet site. We've gone back and forth on this, but today and really for the last 5 years it's made sense to have it on the internet. It means the updates are easier. People are able to access and find. You can get it in the electronic form. A paper book doesn't make sense any more. So we want to get from the vendor a deliverable that'll go on the internet. But the other thing is the issue, perhaps when you're talking about implementation is how do I get people to actually use the standard. And you need, the great thing about having, outsourcing of standard is by the time the standard is done, the committee isn't exhausted. I've seen so many cases where it's a little bit like getting a doctorate. By the time you get a doctorate in the field, you kind of never want to talk about that subject again. And it's like that by the time you spend a year working on a standard, you never want to talk about anything about standards ever again. But if you come in and you spend 9 days on a committee and that's what it really takes and at the end of the time there's a standard in place, then you have the energy to get it into the organization. And that means disseminating that, letting people know about it, supporting it, providing reusable codes to support it, providing consultative support, and even levels of enforcement. So being able to get it out in the organization is key. Don't ever do a standard unless you've got the vision of doing that and making that investment. And those are the key pieces.

How do you suggest dealing with territorial issues where designers think the standards should be one way and IT professionals think it should be another way and neither side will budge?

Well, I've done a lot of standards projects and I've never had a dead lock. In all that time I've never once had a dead lock. And I think there are a number of pieces of that. Part of the key is the training we've talked about where if everybody is trained at speaking the same language, and there's not that disconnect of two totally separate views. The other thing is the standards committee needs to be all about user centric design, which is to say the question of how to design it best is not a colloquial question of – this is the way we do it, this is the way we do it, it's what's best for the user and what's best pragmatically for the business community. And so getting everybody talking about that and with everybody really understanding the value of standards and wanting a standard, I've never had a case where a committee dead locked. I've never failed to come up with every single design decision. And there are many thousands of them in the standard. So it's definitely a it's definitely something where we've seen success. I guess the other thing I would say is that there is a big value to having an external facilitator. Because if you have somebody inside of the organization, just the nature of the politics can lock it up. But when you have a facilitator who's an external person who comes in the objective they're schooled in usability I think that that helps a lot too. So that's something that seems to be a reliable successful experience so at least from my point of view.

You've talked a lot about standard functionality, but how do you convince an oversight group about the importance of design elements so simple even as horizontal line dividing body and title on every page. Is it important?

So what's important in a standard? Okay, when you design a standard, it's critical to know what to standardize and what not to standardize. When you make a template, that template is your example of best practice. So every single pixel needs to be perfect. It's the DNA. It doesn't get any better. You have to really sweat every detail on those standard templates. But then what things do you standardize? Do you standardize that horizontal line? Well, the answer is you standardize the things that the user is going to need to be able to look at the page and go ah okay, I've seen a page like that before. And I know how it works and oh yeah, it works the way I expect. So things like controls, if you have an advanced search and there's a link called advanced search, it should always be a link. It shouldn't be a button sometimes, it shouldn't be a radio button sometimes. It should always operate the same way and it should always mean the same thing. And then it's okay. On the other hand something like a color or the exact font, that may not be very important. In fact you may want to leave the flexibility. So show a good example, but then if somebody feels you know a yellow background conveys what this site is about or supports the theme or metaphor, that's okay as long as the user isn't going you know well what does continue mean here. So that's really the key thing is knowing what to standardize and what not to. Okay.

Comment, good web cast. Thanks. Is the question answer format real or pre recorded as well (laughter)? I guess you know the answer to that now (laughter). Okay. But now you've also confused me.

What types of enforcements do you suggest?

Okay, I guess it depends on the corporate culture. I've been in some environments. I was working for an insurance company in New Jersey, and the client became a good friend and he had a beard too and we would walk in to the projects and review adherence to standards. And we were supposed to stop the project. Stop the project if it didn't follow the standard in every way. And I remember walking in one day, it had been raining so we both had little folding umbrellas and we folded them up and we walked in and it was like the police have shown up with their truncheons. And everybody was very nervous about that. And that was appropriate to that environment because it was a very hierarchical somewhat autocratic environment and that's the way they operated. Other environments you can't do that at all but all you can do is review the pages and make sure that those pages have been looked at, at least the designer know if they are violating the standard. They can decide to violate it. But they need to know about it. One of the things our centers of excellence are doing, we have the ability to provide staff for companies long term at very good rates and so what those are being used for many cases is to review every page that's being created in the company to ensure that it follows the standard and to give feedback at least where it doesn't. So enforcement can go many levels. The other trick though now if you try to enforce it all by telling people it's wrong or policing kind of action doesn't work, you want to be proactive. Proactive means giving people the standard, giving people training, and one of the really cool things is tools to support the standard. So if you have reusable code like I mentioned in usability central there's reusable code for the templates, that means I have to do work to violate the standard. And if we make it hard to violate the standard, that helps too. So be proactive as much as you can, but sill have some level of enforcement.

Do you have a main set of standards that you use for every project and then customize it for each project? Or you just come up with a new standard for each project when you get it?

At HFI we have our core set of standards and that's in usability central, the ones that we make available to our clients as part of the usability central goal package we also use internally. And those provide – I can't count the number of times in a day many times that I'll go to usability central and pull up an example. Then I don't have to think through how a wizard should work or how we're going to indicate required fields or error handling. I just pull these things up and I use those. So we have our general standard that we use at HFI and that we provide to clients. But then for a particular client, for a particular project, we may customize usability central in order to create a standard that really fits their environment and that means we can do it quickly. That's why we can do it in 6 to 8 weeks, because we have a starting place. And that starting place is very much refined with so many different projects and pulling together best practices from our work all over the world. But certainly, we at HFI will go and say okay here's now we've customized that for a particular client or sometimes for a project.

Our websites have become political footballs no one else has ever experienced that. Ownership is up for grabs after the committee disbands. How can we correct this?

In terms of the standards, I would say it's essential to have the standard be a living document and part of an ongoing usability effort. If you saw that chart on how to make usability routine, you'll see that one of the things that we recommend very strongly is having a central usability group who has a whole set of activities. They are the main evangelists, they are the main consultants, they are the process improvement people. They support the methodological standards. And they also need to support the design standards. And support again means partly doing the consulting work of telling people how to follow the standard properly and giving some level of enforcement. But it also means that they update the standard. And so I'm often amazed at how robust standards are. I remember I did one standard, it will be almost 15 years ago now, it was for a financial company. It was a main frame standard. And I went back after 10 years and they only had one screen that violated the standard in the entire company, which they called the ugly screen. And it was actually not a bad screen, but they really followed that standard and they hadn't modified it at all. And in many cases I'll see a standard which has been in place for 4, 5, 6 years and has had only limited modifications required. Usually the page types work well even with some technological change and it's more a matter of sometimes adding a page type. But that still needs to be done and it's part of the responsibility of the central usability group. I think that one of the things standards does is help reduce the level to which design is a political issue, because when there's a standard there, there's less to push around and have politics about...

How in the world do you get stake holders to sit back and not be on the committee when they must have it the way they want?

In other words red text on a green background, no kidding why I feel for you. By the way, red text green background chromostereopsis, bad thing, don't do that again in the story. So what would I say, the thing is that when you put together the committee, it's a good idea at the beginning to go in and listen to the stake holders. So I'll go in and I'll interview those stake holders, and they feel listened to. And then if they say I really want to be on the committee, make clear the committee is going to sit there and spend an hour talking about whether to have it say contact us, or about us, or our email, and they don't need to be in on that. It's even better, I know, if I'm involved in the process or HFI, we set requirements really for who needs to be in there. And we're more than happy to go and explain to anybody in the organization why this needs to be decided by the people who are in the trenches doing the work who really understand the detailed issues, who've been trained, they have to be through 3 days of training and it's hard to get a repeat through that anyway. And so I guess I've never seen it be a problem once we just presented it that way.

Are we still taking questions? No, we're done with questions. So we're actually done with questions, sorry. Okay. We've been working on our standards for our company. Good. Our problem seems to be the balance between standards for the sake of the user and the strict adherence to the standards in spite of the user. How do we set a standard on having to follow a standard? When is it alright to break the standard?

Standards are primarily about meeting user needs. And if you have a well-designed standard where you've made the right decision about what things are standard and what things are just good examples that you're free to follow or not, then really most of the time you're fine. On the other hand, when you write the standard you need to make it clear the standard is intended to cover only may be 85% of the pages that will be designed. And so if the user has a unique task flow, a unique set of needs, then you don't follow the standard. You design what they need. The standard is like Jazz, right. And so you don't mindlessly follow the standard. What you do is you use the standard as a foundation to ensure to help speed design and improve design quality. I mean if you think about it, you're going to design a form. Well, okay you have somebody who sits down in a corner in their cubicle and they have 20 minutes to design the form, they're not going to do as good a job as the whole committee, hopefully with the usability vendor working hard on the process may be for hours and hours. That's, it's not a fair match and we want to use that level of expertise to make those decisions. So it's good to follow the standard, but know that when the user has a unique task flow, some special need, it's okay to not follow the standard. Many companies set up an exception process where if you're not going to follow the standard, you need to go through and have some process to get approval to do that. And I think that's a good thing really for one main reason. And that's if you have that process go by a central person on the usability team, they can see if there's some kind of page type that needs to be added to the standard. And so there's a real advantage to that.

What does 508 compliance refer to? How do you recommend getting management buy in for standards usage?

Those are two separate questions or at least somewhat. 508 compliance refers to section 508. It's a federal requirement for meeting accessibility guidelines for web pages. So we want to make web pages that can be accessed by people who can't see and are using screen readers like JAWS. And so if you don't design with certain things in mind, what you find is it is awful. You go through JAWS, it's like you know tab, row, tab, row, tab, row, and it is just awful. So the thing that we want to do is follow those guidelines and it has mostly to do with the coding. You might not even see it on the web page, but if you follow those guidelines and those people can use it too, and that's something that's very important to government sites and many other kinds of sites as well. It's something I'm happy to see and in many cases it makes sense to follow those kinds of guidelines for accessibility or even exceed them.

How do you get management buy in for standards usage, we talked about that, but I guess I would just say it's an educational process. And once a manager understands the value of standards, it doesn't take any complicated calculation to see that it is worth while.

Okay. Aside from design standards what things should usability designer consider when incorporating icons into a design?

The first thing I would say is why do you want to have icons? And the designer needs to know why. And there are actually only two reasons for using icons. You can use them to save space for expert users and they'll learn what the icons mean. You can make a whole bank of icons and they can just click on the one they need. But if they are not regular users, they won't know what the icons mean and then it's pretty awkward. They have to use tool tips or they have to look it up. It's kind of a mess. So only for expert users. And the other thing is to support a theme, a metaphor to improve the graphic appearance because they are two. And icons can be very nicely – but if you're going to use icons for that reason, then you make sure that they're labeled as well because people aren't going to understand what they mean. So that's the key issue in working with icons. The other thing is that there are a set of principles about how to design an icon well. Things like you don't use puns. There was one icon I really liked that was a dragon and it was like what does a dragon mean. And it was like drag on. You know that's so that's bad. You try to design puns and families of puns I'm sorry design icons and families of icons so that they fit together and make sense as a coherent whole like a pencil and an eraser fit together as a concept. So there are lots of principles in designing icons and then definitely with icons if you're going to use them, particularly if they're supposed to mean anything, or support the meaning, you want to test them. You want to test them for whether they are self evident, test them for whether they confuse people, and test them for the graphical appearance and when they create the brand value you're looking for.

Okay, it seems like the current standards are conglomeration of designs based on the capabilities of html. Do you think that it will be difficult to update these standards with the evolving technology, more powerful programming, more languages, multimedia plug ins etc.

And that's right. That's a really good point. So when you design a standard, you design it for the environment you're in. And if you don't have a slider, you have to find something else. What happens when we get a slider? Well, one of the things the committee needs to do is say okay now I've got a slider. I don't need to use 12 push buttons in a row I can use a slider and say that's definitely better. And I'm going to update the standard because of this new technology. And that's a good thing because you can have one place where they look at the technology and add it. It shouldn't happen ad hoc throughout the organization. That's expensive, it's inefficient, and it leaves the user getting it all different ways. So you can have that kind of retro fitting happening. The other side is that if you think about the implications of a change like now we have a slider and there is no standard and we don't have 12 buttons across the screen as our standard way of doing that, but sometimes there are 12 buttons, sometimes there are 6 buttons, sometimes there are radio buttons and we don't know what they are doing, then you got to go through everything in the organization trying to figure out the places where it fits in and it is a mess. So the changes in technology help the user if we identify where those really make a difference we can add them to the standard and that will help. And the standard makes it less painful to make those changes. Okay.

Dr. Schaffer, for our web applications we provide page templates to automatically define high level navigation, page titling etc. Do you feel that this is too limiting? For the content of page we use style sheets and standards to guide the layout for look and feel.

I remember the early days of companies trying to get consistency. And it was interesting. One of the approaches they had and I saw this again and again. So I got all these main frames and I've got a complete blizzard of different conventions out there. So what do we do? We want consistency. So they would design a main menu for the whole thing and they put the main menu on it and they say now see it's all coherent. Well, once you got past the main menu, it was a total nightmare. Now if you want to have a consistent header and footer, that's fine. But that doesn't really solve the problem. It's a good thing to have but the core is what's in the body. Now the other thing though is when we talk about high level navigation, one of the things that I'll sometimes see is people go beyond just the standard header and footer and may be things like an intranet, a directory, in a public website contact us, an 800 number, go beyond that but into the actual navigation of how the home page is designed. And for some reason they always tend to use a left nav with a tree view or with just a list and then tabs. And if you try to make everything work in that one page type, that one navigational page type, it will not work. And I've seen it blow up a half a dozen times. You'll see pages where it's like okay, here's this page. I have a left nav there's one item on the left nav, it's like why do I have a left nav with one item on it and select it? Well, it's our standard that we always have a left nav navigation. Don't do that again. I mean that's a real mess. So it's okay to have a header and footer standardized, no problem. If you're going to have navigational standards that go deeper than that in to the real structure, then you need to have multiple ways because you need actually 5 or 6 different types of home pages in order to cover the different contingencies and navigational structures. You can't do it with just one. And then the key to the standard is, is the content standardized and we're not going to do that with a cascading style sheet. Sorry. It needs to say either a we submit or is okay. That level has to be dealt with. And so that's why the template idea.

Is it a requirement that standards are based on the lowest common denominator? Is it acceptable to create a standard that contains user requirements, browser level screen size, or media plug ins?

Okay. In terms of the technology you are targeting, you need to know what that is when you design a standard. Now if you're in the public web as of this moment, you're going to be designing with 800 x 600. You're going to make it work as well as you can in an integrated environment 64 x 480 or you're going to have 1024 x 768. That's going to be hopefully a bonus and you'll design with that in mind, but 800 x 600 is your main target. And you design for that. And you can't go to users in the public web and say ah you can't come to my site unless you're browser's this and all that. It won't work. We just have to know what is out there. We know that a huge now almost everybody has you know Flash. And so I can use that. If you have something asterisk, you're making somebody download and that's a bad thing. In an intranet environment it's different. In an intranet, what we can do is we can say our technology team has a standard that they've set up and we use 1024 x 768. Oh okay, and then you can design for that and that's a good thing. So if your situation allows you to have users that actually use a given kind of browser or a media plug in or whatever, then it's great. Other than that you need to know what's in the public domain and we publish it every year in our practical putting research into practice course. And that really is something you need to track, because you're designing for it.

Based on your previous comments regarding internationalization, would you say that an internet (laughter) needs usability testing in all countries and a different home page for every country?

Oh my goodness! That would be a really good thing, but it may be impractical and it depends on the company. Some companies have requirements for English throughout. Some companies don't have enough users in a given environment to justify a home page for each region or each area. I would say that if you really want to design something that's optimized for a user population, it needs to be in their language and built for their cultural context. And so if it is important enough, then yes. And one of the things I'm working on and I think I've got solved is the ability to do remote usability testing and that's something which will allow us to more efficiently test world wide, whereas right now it's really impractical in many cases to do more than sampling and translation. So it's a good idea and we're not where we'd like to be on that yet.

Earlier you mentioned that creating a set of web standards for a cross browser cross platform community would be very difficult. Can you briefly speak about how you would approach this daunting task? Would you try to convince your clients to try to comply with W3C cascading style sheets, xhtml, or would you try to accommodate for other non-compliant outdated web browsers?

Okay. So first of all, what I said about the range of what you can cover on a standard is that when you go across environments, say from a browser environment to a windows environment to a hand held, you can't have one standard that goes across there. It ain't going to happen. Okay, so you have different conventions in the windows environment. You have different conventions in the browser environment. And you need to follow that. But if you're within a browser, then you really need to be able to cover a wide range of browsers. In only a very, very specialized environments can you demand particular kinds of technology, particular kinds of capabilities. In the public web it's just not going to happen. And you shouldn't consider it. You should design for the target population. So that's a reasonable target. We've covered, you know you're not going to go back to ancient browsers, but you'll cover may be IE, Netscape, 4X onwards. Something like that may even 3X onward. And that's a reasonable target and we can do that.

What's a good resource for some sample pages so we have a starting point?

That's a good question. HFI has a product usability central goal which provides a full set of page designs as a starting point and that's been refined over many, many years and it is a great thing to have. I know that you're from a university and so we'll give you special discount or something if it's a little expensive for a university. But for an institution, it makes a lot of sense. I'm not sure what to do without that. Without that you really have to start looking at your environment and picking the best example pages you can. And it tends to be a very long process and a politically charged one because you're picking certain people's designs as best practices which starts to inflame things a bit.

What is a certified usability analyst?

HFI last year created a program where what we said was in order for institutionalization of usability to happen, in order to be successful in having a repeatable solid process for usability, we need to have people certified. You can't have what we have now is people walking around going well, I'm a human factor specialist. Why? Well, I am a human so I must be a human factor specialist. That's not going to work. You need to have people who have a solid foundation in usability. Now there was and still is a certified professional ergonomist certification by the board of certification in human factors in ergonomics. And that's great, but it's really a general certification. It's not in software or alone it looks at work space design and factories and all sorts of things like that, consumer products. And so there wasn't one for software. So we created one and we have a test which you can take and if you take that test and pass it, then you become a certified usability analyst. And we do have a training program 10 days of training that's good to get you ready to take the test in many cases, but you don't have to take that training program. It's a test which is available for anybody to take and so that's something which is part of what I look at as the transition we have to make as an industry or we're moving away from people just saying okay, well, usability, yeah, I've got some training in that and I'm going to go do something good to we have a methodology, we have trained and certified staff, we have the tool set, we have standards, we follow those and because of that we know that we're going to have a usable design, and we're not just hoping something good happens. So it's a key part of the maturity of the usability field and that's the reason why we've taken the loss of building that certification. We've also taken the Weinschenk Consulting Group certificants which date back about 10 years and we've got them folded into the CUA. So we now have the I think the core certifying capability for usability analysts. And if any of the other organizations would like to help us out with that, that would be great.

Have you any research on the adaptability of non-computer savvy users and web interface changes? There are pages on our internet that require too much scrolling, but compressing results in clutteredness. Changing the page flow is a training cost. How adaptable are non-tech savvy people to changing web interfaces?

When you look at putting people through a change, it's really critical that you understand the effects of proactive inhibition, okay. Proactive inhibition says if I learnt to do something one way, and particularly if I over learn it, so I do it a lot, then every now and then even I know perfectly well it's done a new way, I'll go back the old way. So those of us who learnt a manual typewriter, we used L instead of 1, there often wasn't a 1 there. And it could be 20 years later we still might hit out for 1 every now and then. And so if you make a change that takes people out at that level so I've been using d to move down a page for the last year and I've done it you know thousands and thousands of times and all of a sudden you make d delete the whole file irretrievably, it's a very bad thing, because I guarantee you I'm going to do that periodically. I'm going to go nuts. And we've had cases like that when we switched from the enter key to tab as a way of going from field to field create a lot of those kinds of errors and great frustration. On the other hand if you write clear error messages, nobody is ever going to call you up and say I just can't get used to these clear error messages. I liked it when it said you know syntax error 46 and you know I knew that taxman I have to pay for it and I knew it (inaudible) too. So you know when you make that kind of changes, never a problem. When you make structural changes that physically reduce the amount of work it takes and the number of steps then it's not a problem. So I had many clients go well you know you're making these radical changes in the interface, won't that be a terrible training cost? No, it's self evident. Won't that be a slow people down? No, because it makes it quicker because we've reduced the number of steps to do things. We've made it more efficient in terms of everything in the visual, intellectual, memory, and motor activities of the user. And we've made it so that we don't have problems with proactive inhibition. Okay.

I so want to work for you guys. Is there a correlation between the life span of standards and the technological capacity or lack thereof of, of both my organization and / or the audience?

Okay. Well, thank you for that. I think we're HFI sort of has to be one of the coolest places on earth to work if you are in usability. One of the few places where the CEO is born and bred and of the blood. So but the life span of standards how does that inter relate with the technological capacity? I would say that the standard stands changed when you interface form factor and paradigm of operation changes. Then you're really in mode of throw that standards and start again. So when we went form main frame to GUI, we had a lot of main frame standards and they just didn't apply. GUI was another paradigm of interface operation. Also when we went from GUI to the web world again it's another paradigm of operation. It's another way that people think. Is the GUI in the main and the web coming together? Yeah, that is kind of happening. I'm not sure that will create a case where we need to throw out the standards, but if you think about what will happen when we go to hand held units with the baby faces the real small interfaces, with the foreign factor, perhaps no keyboard but using graffiti or small keys, then we end up with another interface paradigm and another set of standards just like we have standards for a voice response system. They're different.

Top