I wrote the following story, borrowing heavily from another well known fable, in order to bring home the concept of “Customer Driven Quality”. Perhaps you will enjoy reading it. I let my kids read it, and they liked it, except they said the end was a little too obvious. Perhaps you will find the end obvious as well.

The Fable of the Five Magistrates

There exists a small island in the ocean, not very close to any other land, and not visited often by foreigners. This Island had five major villages, and each village was was lead by an elected magistrate. The magistrates were wise, and lead by consensus. Also, by an amazing coincidence, the kind of coincidence ones sees only in fables, all five magistrates were blind. Yet they had capable people on their staff who acted as their eyes and ears, and they had not problem with the daily running of the island.

The island was a prosperous one, and the custom was that every Tuesday afternoon, there would be a parade to celebrate the prosperity. This parade time was always cherished by the people; everyone could be expected to be there. So long had the custom of holding these parades, that those who attended and watched the parade were called customers. Over time a grandstand had been built to allow these customers to sit and watch the parade in relative comfort. If they weren’t involved in putting on the parade themselves, they would come every Tuesday afternoon to relax and watch the parade go by.

While it was extremely rare, one week a foreigner came to visit who brought with him an amazing and exotic animal: an elephant. Seeing that it was Tuesday, and seeing that the visitor needed to leave the following morning, the visitor suggested putting the elephant on a float in the parade. It was an instant hit. What an amazing spectacle this became! The customers were enthralled with such a sight they had never see before. The entire island was abuzz with impressions of the the elephant.

The five magistrates were aware of the interest in the new addition to the parade, and were sad to hear that the foreigner had to leave right away. Each magistrate thought: “If my village could present next week a float that is as exciting and noteworthy as this, everyone will notice, and I will surely get re-elected for the next term!” Such thoughts are common for elected officials everywhere. Each of the five magistrates set out immediately to make a float that could capture some of the interest that this elephant had, but without an elephant they would have to be creative.

The first magistrate went immediately down to see the elephant, but being blind had to walk up to the elephant to experience it. The side of the elephant felt like a great wall. So he said: “Aha, I know what these customers want, they want a great big wall.”. He brought in the best wall builders from all over the island and set about to make the straightest, most perfect walls that had even been on a float in a parade.

The second magistrate did the same, but encountered the legs of the elephant, which felt very much like the trunks of massive trees. He said: “Aha! I know what these customers want, they want to see huge trees in the parade.” He immediately send for all the best arborists on the island to custom build a float that would display trees.

The third magistrate encountered the tail of the elephant, which felt like a rope. He said: “Aha! I know what these customers want, they want to see ropes.” And he sent for all the best rope makers on the island to start immediately on a lavish display of ropes for the following Tuesday parade.

The fourth magistrate encountered the trunk of the elephant, and said “Aha! Elephants are like snakes! We might not have a real elephant, but I should easily be able to thrill the customers with a vast collection of snakes.” And he immediately sent for the most famous herpetologist on the island and set about to accomplish his goal.

The fifth magistrate did not go see the elephant at all. He instead went to talk to the people who were in the crowd during the parade and who saw the elephant. He found that while these people were clearly thrilled by the sight of the elephant, since they had never seen one before, they had no way to describe it to him. For example, they had no word in their language for “trunk” or for “tusk”. He invited them to come by the grandstand again on Friday afternoon, where he drove potential floats by them, and listened to their response. Knowing that the elephant had four legs, he started with a float with a desk on it. From their reaction, the crowd was not very impressed. A table was similarly disappointing. Then he tried a float with a pig on it. From the reaction, this was clearly more interesting to the customers. Then he tried a cow, which gave a greater response, and he came to the conclusion that “bigger is better”. So then he tried a moose, but found that the moose was less popular than the cow. He tried many different things, each time listening to his sample crowd carefully to see what they liked and did not like. Finally, he ended up with a float that elicited a large response, not quite like that from the elephant, but still very close.

The weekend passed, and Tuesday came, and the grandstand was filled with customers hoping to see something like, or possibly better than, an elephant. The float from the first village came by, and it included very impressive walls on it. They were straight! They were soundproof! They were covered with vivid, yet tasteful, wallpaper. Everything a wall should be, but the crowd was not impressed at all. The crowd responded similarly to the next three floats. The second float had an small forest of trees of all types from around the island, the third had ropes woven from a dozen different fibers, with colorful strands threaded through, the fourth had a hypnotizingly lavish display of snakes. While these floats were perfectly executed, none of them yielded the a response like that of the elephant. Finally the fifth float appeared. Riding high and in plain view was a beautiful black race horse. The crowd went wild. They had seen horses before, but never displayed like this in a parade, and this was a magnificent horse.

The elation of the crowd was not lost on the other four magistrates. They complained bitterly. “This horse is NOTHING like an elephant. The elephant was like a wall, and this horse is nothing like a wall.” Another said: “Elephant legs are like trees, but this horse has skinny legs, nothing at all like trees!” The experts even went so far as to analyze and cross check all of the ways that this horse was not at all like an elephant.

But, the magistrates were wise, and quickly realized that the fifth magistrate was on to something that worked. They asked him what his secret was. The fifth magistrate answered: “It is easy. I did not go to look at the elephant. I did not analyze the qualities of an elephant in an attempt to isolate the distinct and unique features of an elephant, and then try to duplicate those same features. Instead, I realized that the important qualities are in the audience, not in the elephant at all. I knew that my impression of the elephant might be different from those of the people in the grandstand. Instead of focusing on the elephant, I focused on the audience excitement. I showed the audience a lot of things, the first of which were not at all pleasing. But every time I showed something, I measured the response. I kept trying different things in control groups until I got the best response possible. It is true, the horse is clearly NOT an elephant. But the main goal should not be to produce an elephant, but rather to produce a pleased crowd. So listen to the crowd, not the experts who know the elephant.”

So the magistrates, who were wise, learned from this, and continued to put on better parades. They also continued to be re-elected. The island continued to prosper. They even changed the motto of their little island government be:

“The important qualities are in the Audience, not in the Elephant at all“

A notable quote I ran across today:

He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property. Society may give an exclusive right to the profits arising from them, as an encouragement to men to pursue ideas which may produce utility, but this may or may not be done, according to the will and convenience of the society, without claim or complaint from any body.

—Thomas Jefferson, letter to Isaac McPherson, 1813

Well, I am back from a wonderful vacation in Tuscany. Just a week in a small apartment in the countryside there, I highly recommend it. But back to work: I started this post before leaving, and it is time to finish it up……

One problem has bugged me for many years. It is another one of these things where the “conventional wisdom” is misguided. There must be other people hold my position, but because all of the terms are so generic, it seems to be impossible to google for other pages on this topic. So please, if you know of other discussions on this topic please make a comment with a link.

Background

Early 1980’s saw the first modern graphical user interfaces. The Macintosh sported menus that drop down from the top of the screen. One UI guideline was ingrained into the common GUI consciousness:

If a menu option is not immediately available for use, disable the option, and indicate this by changing the color to grey.

Is this good? Is this bad? The visual indication is clearly good. By why do you have to disable the menu? Menu options that are disable can not be selected; they can not be acted upon; they can not tell you why you don’t need that option. Disabled menu items are completely dead and silent about why they are disabled.  It can take minutes or hours to figure out why an option is disabled.   I hate this.

User Protection

Why do we disable menu items? The response is usually along the line of “protecting” the user. People (users) are afraid of computers and applications; people can accidentally do the wrong thing and cause problems, so in order to make a more friendly and comfortable environment, we should only offer them operations that make sense at the time. Thereby preventing people from accidentally using the wrong option. In summary, we need to protect people from doing the wrong thing.
Protecting the user makes sense, but it ignores a critical aspect: users need to learn the system they are using. No, Virginia, people don’t read the manual. The point of a friendly user interface is that you can use the product without attending a training course. Just start using it and learn by experimentation. If you want to (graphically) re-size the object you are working on, look around for a menu option that looks appropriate, and try it. Oops, it was not what you wanted, no problem there is the “undo” command. A well designed application can be learned by trial and error.

If I do something completely ridiculous, it is not because I am a “bad” person who needs to be restrained or punished, but it is because I don’t understand the model/metaphor that the program is presenting to me. Therefor, the appropriate response that a friendly program should make is to explain: (1) what the operation does, (2) what it requires to operate correctly, and (3) why I have not met this condition. Through my exploration of the program, this kind of response will actually help me have a better understanding of the program, and it will help me use it better. I was still prevented from doing the ridiculous operation, but instead of a simple dead menu item, I got a pop-up error message that explained why I can’t use that operation. Once I learn that a particular path of action does not make sense, I will not use it, not because I was prevented, but because I will understand the program.

Simply disabling the menu option does not help me in this way. Due to my misunderstanding of the system, I THINK I need to use a particular command, but it is disabled, so I now believe that program is wrong (not me). A disabled menu gives me no information to teach me what I should be doing instead. I am forced to go outside of the system, maybe even look something up in the manual, or most likely bug a coworker who knows the program, and find out externally why the system does not work for me. In the end, my misunderstanding of the system will be corrected, and I will come back to use the system.

An Example

Some simple examples. I use a photo-graphical program that allows you to increase and reduce the color depth of the image. For example, a JPG is 16 million colors, and you have an option to reduce the image to 256 colors. Once you reduce the image to 256 colors, the option to reduce becomes disabled. This makes sense to anyone who understands what is going on, but what about who does not understand? The user wants to do something, and thinks it is called “reduce colors” but the menu is disabled. The user is left on his own to discover why the menu is disabled. Maybe the user (1) thinks the command does something other than it does, or (2) does not know that the image is already in 256 colors. Imagine how much nicer the program would be if when he chooses this option, it pops up an explanation about how the picture is already 256 colors, and this operation only works when the image has more colors than this. It is nice to have the menu gray as an indication, but disabling prevents me from learning how the program works.

The same program has filters (smoothing, etc) that work only when you have a 16 million color image. With a 256 color image, when you try to use a filter is it not disabled. Instead, a window pops up telling you that the filter options only work with images with 16 million colors. This is so much more helpful than simply disabling the menu.

Preventing Error Messages

It gets worse. Many software QA people believe that “preventing users for making mistakes” is extended “preventing users from ever experiencing a pop up error message”. I don’t know how many times I have heard someone say: “If the user is only going to get a pop-up error message, then the button should be disabled.” This is actually a codified rule in the Fujitsu software quality standards.

What is the matter with users getting harmless pop up error messages? The answer is simply: usually these error messages are completely useless. They do not explain anything about the program, and often end up blaming the user for being “bad”. They often use techno-jargon, or worse, simply contain an “error code” which is meaningless to the user.

So in summary, our programs are so poor at teaching users how to use them, that we go and prevent the most important way that people learn: trial and error. Please note: trial and error does not work without the error part. When my dad took me skiing when I was young, he always said “if you don’t fall down at least once every day, you are not trying hard enough.” It is impossible to design a program where everything that can be tried will be successful. It is those error messages that are the learning experience.

Common Lore, Fighting the Good Fight

Most intelligent people can understand the above reasoning, and will agree that good, well designed error messages are helpful for people to learn the program. But the rule to disable menu items still exists.

Try searching google for “disable menu” and you will find thousands of messages from people seeking to find ways to disable menus, and to find code support for disabling menus. Here are some examples:

• “As user security may not permit a user access to a specific menu option(s) we need to disable them so if the user clicks on the option nothing happens.”
• “I am working with the BasicMenu sample and would like to disable my menu entry, when no document is open.”
• “You can use system policies to disable menu commands and their corresponding toolbar buttons. When you disable a menu command and toolbar button through a policy, users cannot use that command or button.”
• “Does anybody knows how to disable the menu when you click the right button on your mouse? This is to control the desktop display for PCs meant for the public. Do we need special software?”
• “if there’s nothing in the clipboard (state), then the Paste command should be disabled (menu).”
• “if your program is in read-only mode, then commands that edit should be disabled…”
• “Obviously, if there is no selected object at all, you’ll want to disable the menu item, thus reinforcing the connection between the item and its object.”
• “visually disable menu item(s) which the user not allow to activate.”
• KDE UI Guidelines: “If an action should not be executed (e. g. Cut when nothing is selected) then you should disable the entry in the menu.”
• Eclipse GUI guidelines: “A command should only be enabled if it can be completed successfully. If this is not the case, the command should be disabled.”
• GNOME UI: “Sometimes it does not make sense to allow the user to interact with a control in the current context, for example, to press a Paste button when the clipboard is empty. At these times, make the control insensitive to minimize the risk of user error.”
• NASA UI Guidelines: “Dim (or gray out) unavailable or invalid options.”
• Apple UI Guidelines: “When a menu item is unavailable—because it doesn’t apply to the selected object or to the selected object in its current state, or because nothing is selected, for example—the item should appear dimmed (gray) in the menu and is not highlighted when the user moves the pointer over it.”
• SGI UI Guidelines: “In general, disabling entries when selecting them would give the user an error message. For example, if a menu entry works on a selection (such as “Cut” and “Copy”), disable it if there’s no current selection. “
• Sun GUI Guidelines: “Disabled commands have dark gray text (instead of the usual black) on the usual light gray background. They are completely inoperative and are not highlighted in response to user actions.”
• Java Look and Feel Design Guidelines: “If an application feature is not currently applicable, make the corresponding menu item unavailable and dim its text. When menu items do not apply to the current context, they are dimmed and cannot be activated. Keyboard navigation skips over them.”
• Microsoft Official Guidelines for User Interface Developers and Designers: “If a menu item is not appropriate or applicable in a particular context, then disable or remove it. Leaving the menu item enabled and presenting a message box when the user selects the menu item is a poor method for providing feedback.”
• Smith and Mosier HCI Guidelines: “When function keys and other devices are not needed for current control entry, and especially when they may have destructive effects, disable them temporarily under software control so that they cannot be activated by a user.”
• “On the other hand, if the option is not available for a reason the user has no control over, then remove it. Otherwise the user will go nuts looking for the magic way to enable it.”

Everyone is looking for ways to disable menus, and disable means to make it non-functional or “dead”. I would claim that in everyone of these cases, the program would be far more helpful to people learning it if a pop-up message would tell them why the command is not useful at the moment, but the code libraries to support menus do not work this way!

How do we change this? Disabling menu items seems to be one thing that the common programmer pick up, but misapplies. It seems to be a simple thing for Quality Assurance people to check for and insist be changed.  How can this be corrected?

There may be guidelines existing that concur with my position, but I can’t find them! Searching the web only yields millions of cases of people trying to figure out how to disable menu items. I am looking for something telling people to NOT disable them.

I did find some things:

• Bruce Tognazzini calls this the “Mysteriously Dimmed Menu Items” problem: “Bug: Designers offer no way for users to discover why a given menu or option has been dimmed (grayed out), nor how to turn it back on.    Proposed Fix: Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.”
• GNOME UI guidelines: “Do not disable menu titles. Allow the user to explore the menu, even though there might be no available items on it at that time.”
• Palm OS Guidelines: “Never dim or gray out a button to show that it does not apply to the current situation. If the button depends on a certain user context, display an alert dialog that explains why the button does not apply. For example, To Do List has buttons at the bottom of the main form that apply to the currently selected task. If the user has not selected an item, tapping one of the buttons results in an alert dialog explaining how to select an item”
• Sun UI Guidelines: “When an application is in use, it is not uncommon for commands to have no valid function. For example, when a text editor does not have any documents open, its Save and Close commands have no function. In situations like this, a menu command that has no current function should either be disabled or it should open a panel explaining the function is not currently available.”
• Apple Guidelines suggest a help balloon to explain why a menu item is dimmed: “Remember that the help balloon you provide for a dimmed menu item should explain why it isn’t currently available or, if more appropriate, how to make it available.”
• Mark Levinson agreed: “we gray out menu items when they’re not available but don’t do anything to tell the user why they were greyed out.  So the user is expected to use their innate genius and grok why the item is greyed out.  What we really need is for industry behemoth (is MS listening) to help solve this problem.  We need both a standard UI guideline and BCL classes that implement it. “

Call to Action

I can’t be the only one with this opinion. Please use the comments on this message as a way to collect links to UI guidelines that concur with this position. If you know of a good UI article stating when it is bad to disable menus, PLEASE enter a comment with a link to that article. If you know of a discussion of this topic anywhere, PLEASE make a link to that discussion in a comment. I would greatly appreciate it.

Hmmmm, I just spent 15 minutes typing in a post, and pressed the "Publish" button, and it came up with a blank page. After waiting a while and seeing that the browser was no longer active, I pressed the "back" button to go back and try again. BUT, the page is constructed with on page java script that refreshed the contents of the page to an empty box, and all my work was gone.

-> Rather Disappointed

(1) Is this really what I want to spend my blog time on?  Tag-language.  I spoke with someone else today who said that he felt that the JSP tag library phenomenon had kind of faded, and that the fadhad been replaced by other approaches.  I dont know.

(2) I am certainly not going to have a blog about blogging, which seems to be the narcissistic tendencies of so many bloggers.  So I will stop this one here.

That last post was too long. The discussion around pesudoprogramming is too complex to contain in a single post, or a single essay of any form. I feel it utterly fails to clarify anything, because it is built on so many other axioms which have not been clearly stated.

I was challenged by someone on the stance that use of tag-language in a JSP was less powerful, less convenient than just sticking to Java. So it is me against him, can I find some third person support for either position? I searched the web. The ONLY mention of tag libraries were from people promoting those tag libraries. They always include a page of reasons why the tag library is superior. Many "reasons" are unsupported assumptions about being better. Other reasons unfairly compare a very poor Java example to a tag; the Java could be written much better and it would be a better comparison. Most of the arguments don't hold water.

I was thinking, *somebody* must have done an unbiased comparison of using tag-language or sticking to pure Java. No matter how I searched, I could not find any evidence of a careful controlled study comparing the two approaches. Then I realized that the flaw is my assumption that there would be a such a study.

Who would do such a study? If you like tag-language, you are motivated to write a page expousing the benefits of tag-language. But if you don't like tag-language, you pretty much just ignore them. It is reasonable to assume that tag-language works in a particular domain of the programming space, and those who like it are in that domain, and those who do not are in a different domain.

Who am I, then, to rain on sombody's parade simply because tag-language is not useful for my purpose? I am a system architect and must set the direction for many people, some of whom are less experienced. These programmers are trying their best to do a good job, so they see the arguments and are persuaded. I guess what really bugs me is that the arguments are fallacious, and nobody corrects them! Only one side is presented, so people do not dig to see the what the truth should be, they simply accept the arguments.

I guess I am not done with this subject. I will have to address each argument for tag-language, and see if it holds up to scrutiny.

Alright, this is my first post.  Frankly,  I have looked into a number of blogging software sites, and I am not sure which one I want to use.  But someone else I know uses this one, so I am trying it.

Goals:  the purpose of this blog is to comment on what I see in the enterprise software field, with the possible result of making things better.  Continue reading →