Go Flow

Hey Bruce! I am your biggest fan. When you make a comment, on workflow, or on photography, I really take it to heart. Your comment sowed the seeds of doubt about whether HDR photography is worth the trouble. Afterall, as a hobbiest I have not really spent much time manually manipulating RAW format pictures. My camera (Canon G6) has a 10 bit per pixel sensor, which gets then compressed to 8 bits per pixel in the JPG. That is potentially 10 f-stops (EV) of dynamic range. Somewhere I found a web page listing the G6 as having a luminosity range of 1:650, which is between 9 and 10 EV. I hear better cameras can get 10 to 11 EV. Maybe, as you say, that is enough. Clearly combining pictures taken +2 EV, and -2 EV could potentially potentially add 3 or 4, giving the total range around 13 or 14 EV. How do I know whether I need the extra range?

How important is this dynamic range, anyway? The human eye records an instantaneous dynamic range of 1:30,000, a range of 1:200,000 if you allow a couple of seconds for the iris adjust, and 1:1,000,000 if you wait 20 minutes for the eyes to adjust to darkness. All of these make the 1:1000 of a camera seem tiny. But how much do you really need?

I set out to take a some photographs to see whether I really need to purchase the Photomatix software, or whether this is just a fad promoted by photo perfectionists. The first picture was a tree in the courtyard of the Fujitsu campus in Sunnyvale. I recorded the pictures in RAW format, and took a large number of different exposures, each about 1 EV apart. I then compared two results: the first is from combining all the different exposures into a single HDR image, and then tone mapped that back to a JPG. The second was by taking a single RAW image, the one at the “correct” exposure, converting that to HDR, and tonemapping with the exact same setting.  (I am too lazy to link this photo, sorry.)

First thing I have to say is that the results with the RAW image were dramatically more stunning than doing the manipulation from the JPG generated by the camera. I will certainly do more of this in the future.  I have to say, on this first photo, the results of the single exposure, and multiple exposure were essentially the same! The colors were great, the picture clear, and the dark and highlights were without problem. What I found out is that this first photo did not need the high dynamic range. I think that will be the case in many pictures, just as Bruce suggested.

The second picture, however, convinced me to get the software. This is a picture of a fountain in the sun which is very bright, but includes the dark side of a tree, as well as a lot of dark details on the building in the background. I took a total of 7 different exposure settings in RAW format. (Since then I have found that it is unnecessary to take so many, but this is how I learned that.) Again, I processed two examples: the combined HDR, and an HDR made from the single best exposure. I was careful to use the exact same tome mapping for the output. This is a little unfair because you might do the tone mapping a little different for the single exposure, to bring out the blue in the sky a bit more, but I wanted to be able to exactly compare the results.

First of all, here are the two photographs, reduced to fit on the page. The first is the single exposure, which the second is the photo made from combining 7 exposures. Please see the links at the bottom of the blog entry for links to the full size (7.1 Megapixel) images.

Most of the picture appear the same at this scale. You notice mostly that the sky is bluer in the combined exposure photo, because the single exposure tended to wash out the color a bit because the sky was a little over exposed. But the trees, the grass, the fountain, the buildings look pretty much the same.

The fountain is in the sun, and it is very bright. The biggest difference between these images is seen when you look closely at the fountain:

The difference here is dramatic! The fountain was bright enough that it was completely overexposed in the single exposure shot. The multiple exposure shot, however, used information from the darker pictures to get a clearer impression of the fountain.

How about the dark places? Maybe the original single exposure picture was simply overexposed. This also shows a dramatic difference:

Notice how speckled the rafters appear in the single exposure image. This is noise that is appearing at the dark end of the luminosity range. The multiple exposure image is dramatically cleaner, because the image information for this part of the picture was taken from photos that were otherwise over exposed. Notice in the multiple exposure image you can see some wood grain in the front most board, and how much clearer the details in the vines in the background are.

What this demonstrates is that for this picture, the single exposure could not capture both the bright areas, and the dark areas at the same time, but the image made from combining multiple exposures did this beautifully. That was enough for me, and I purchased Photomatix this morning.

I took these pictures with 1 EV spacing, requiring 5 or 7 images. In hindsight, it should be fine to use 2 EV spacing, and in general 3 exposures will probably do. This will be much more convenient since the camera will do exposure bracketing with 3 photos, spaced 2 EV settings apart, so that all the pictures can be taken without touching the camera, which will reduce the chance of shifting the camera direction. This should be fine for all but the most extreme shots.

If you would like to compare the complete photographs, here are links. Please keep in mind they are big, so you probably want to right-click-save-as to avoid downloading multiple times.

• Single Exposure, 7.0 MB JPG
• Multiple Exposure, 6.1 MB JPG

The combined HDR image was 23.8 MB, and each of the 7 RAW images were 8.8 MB. These pictures were taken on March 15 2007, at about 3:30 in the afternoon, on the Fujitsu campus in Sunnyvale.

A few days ago I found out about High Dynamic Range (HDR) photographs. A short search on the web will bring you lots of information, but somehow I have been living just fine completely oblivious to HDR.

The threory behind HDR is that film (and digital cameras) have a particular dynamic range that they are sensitive to. Light intensity values that fall outside of this range, tend to get smashed together and “washed out”. Yo can see this easily if you take a picture of someone with the sky behind them, but set the exposure so that you can see their face. The sky will often appear completely white and lack any detail. Similarly, if you take a picture of a room, often the windows will appear completely washed out without being able to see what was outside. The same thing happens on the dark end of the intensity spectrum: dark details will completely disappear into the rest of the black areas.

Since cameras are limited, the way to get a HDR image is to take three (or more) images with varying exposure. You take one that is approximately “right” and you take one that is obviously overexposed, and another obviously underexposed. The interesting thing is that these over and under exposed pictures contain additional details that are not present in the “right” picture. Today, March 11, was a bright and sunny day and we decided we had nothing better to do than take a Sunday drive through the countryside. I took a number of such “multiple exposure” photos.

When I home, I downloaded the free trial version of Photomatix from a company called HDR Soft just to try out this HDR process. Does it really work? Does it make photos that are “better” than normal photos. You can be the judge below.

From my point of view, it is “interesting”. An adjective I normally avoid because of its ambiguity. There is no doubt that you can see more in the picture. There are more details. The colors seem to jump out at you, and I have to admit that when I was standing at the original scene, the color were overwhelming. In some sense the result matches an emotional impression. At the same time, the HDR images look fake and unreal. They look like “art” and not “reality”. Is it just that I am so used to seeing photographs with the limitations that normal photography brings?

To appreciate the process, you need to see the three original photos, and then the combined results. Please note, the result is somewhat grainy, which I assume is because I compressed the originals to JPG before combining. The guides say to use RAW of TIFF mode in the camera, and it makes sense because the JPG smoothing will in certain ways distort the actual colors of the pixels, and then when you compare them across three pictures, there ma be some problems. Next time I will try will RAW mode to avoid problems.

Here are the original three pictures.

These are read into Photomatix and combined into a single HDR image. The image looks funny on the screen until you apply a Tone Mapping. The result is an image that can be saved as a JPG file. IT looks like this:

What do you think? THe free version of the software puts the “watermarks” on the photo, so please ignore those until I decide whether this is a worthwhile process. It is certainly an amazing transformation of the photo. You can see the detail in the wooden siding of the barn, while at the same time the sky appears blue. Sometimes I think the colors are a bit too saturated, but then it was a beautiful day which was constantly impressing the eyes with color.

Here is another picture of some houses in Aromas, California:

And here is the combined photo, which clearly shows the sky at the same time as the trees.

Comments?

I heard a funny rumor today: someone heard that the OMG was buying the WfMC in order to put an end to XPDL. I am sure the OMG folks find this just as amusing as the WfMC members do. And I can assure you that no such thing is happening, probably more due to OMG unwillingness to shell out the money than WfMC unwillingness to accept the cash.

It has been a long while since I have made an entry here. We have all been busy, but now that the holiday season is over, there are more serious subjects to attend to.

On Feb 5, 2007, we are holding yet another WfMC Workflow Tutorial Day to be held here in Silicon Valley. How ironic it is that this is the first time in North America! We developed this material last summer, and presented it in September in Mainz Germany, and then in October in Tokyo, and November in Taipei and Singapore. There were sellout crowds at every event — which, to be honest, being a highly technical topic, is a much smaller audience than a rock concert. Now, with the material honed by the rigors of the road, we are bringing the show home where it all began so many year ago. OK, it began a lot of other places as well. Still, it is a day long event discussing existing BPM and workfow standards, and how they relate to BPM technology today. It is a must for those serious about making their business operations more efficient. More information is available at: http://www.wfmc.org/events/BPM_in_practice.htm and you can get the PDF brochure at http://www.wfmc.org/images/BPM_in_Practice07.pdf.

Hope to see you there.

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

Have you ever been using a high tech product or software application, and ran across a command or prompt which you did not know, went to the help, and found a help entry, but that entry actually tells you nothing? For example, you see a menu called “XXX” and you wonder what it does, so you go to the help or the manual, and look it up. The entry says (and I quote) “In order to XXX select the XXX Menu.” This is Content Free Documentation.

CFD is caused by “Documentation Standards”. Someone writes a rule that says something like: every menu item should have a corresponding help entry. This gets assigned to documentors who were probably given too little time to complete the job, or else had to deal with many last minute changes, or possibly were not even trained writers at but instead were aspiring actors who managed to land a tech writer position as a day job. Whatever the reason, they mechanically worked through the program, and fulfilled that rule that every menu item should have documentation. Here is an actual example:

You have a check box which is labelled “Enable Autoplay for CD and DVD Drives”. At this point, there are basically two possibilities. Either the user understands this phrase or does not. If the user understands the prompt, then the user is not going to need to read any further document. Yes, Sherlock, this means that the description is really for those users that do NOT understand the prompt. There are a number of reasons why the user might not understand it: The user might not know what “Autoplay” does — I know it seems obvious, but there is the possibility that the user has no experience with this and really is not sure what this means. The user might not know what CD drives and DVD drives are. Or there might be questions about the entire context, for example when does “Autoplay” get activated and at what time will this setting take effect.

But our faithful tech-writer did not waste time with any of these possibilities. Apparently the writer thought that if a user does not know what to do here, simply repeating things a few times might work better! This is right along the line of thinking that if this foreign person can not understand English, it might help if I simply yell it a little louder in English. I am rather surprised that the description is not in bold, or at least a larger font.

Lets do a little bit of “information analysis” on the description. We know that the user who needs the documentation does not understand the phrase “Enable Autoplay for CD and DVD Drives”, so including that in the description adds no information value. So let’s remove that phrase from the description, and see what is left:

Check “” to

There we go, an excellent example of Content Free Documentation.

Perhaps you think I exaggerate a bit. It is possible that the technical writer thought that user might not know that the little square box is in fact a “check-box” and so was informing the reader that the box can be checked. Ah-ha, some information, you think? No, I am afraid not. Because, if the user does not know that the box is a “check-box”, then the verb “to check” has no meaning to the user. The verb “to check” might be interpreted to “read the sentence again to make sure it is correct”. Once the user has completely and thoroughly checked the prompt, it would still have no meaning for him.

CFD exists everywhere, particularly in help files and software documentation. What is the harm? It wastes time, and people don’t like that. Imagine you are that person who does not understand the prompt. Sometimes you have to open a help window, and hunt through pages of poorly organized text in order to find the help that is relevant to your prompt. If at that time, you find that the help is a phrase that consists only of a repeat of the original prompt, it is quite a disappointment. IT would be better if there was no help at all. As Tom Lehrer said: “People who have nothing to say should at least have the decency to shut up.”

What can be done about it. Well, the rule should be simply: if the documentation does not add any substance that can not be gleaned by a looking at the subject of the documentation, then there should be no documentation. Or better: documentation should contain some phrase or description that could not be picked up simply by looking at the page. People are looking to the documentation because they don’t understand the prompt, the very least the documentation should do is to phrase the information differently in case it is simply the wording that is confusing.

I started looking around for example to include in this post. I am using FireFox just now, so I when to the “options” menu. At some point it says: “You can also click the Check Now button to do a check right now.” Yes this is a direct quote! How about something like “You can also click the Check Now button if you don’t want to wait until the next time Firefox is started.” That actually tells you something you don’t already know.

My experience is that you can find CFD almost anywhere you look for it in modern software. Let me close this post with a simple plea for the technical writers of the world:

Users come to your document to learn something that they do not already know. Please ALWAYS include something in your writing that the user could not pick up by simply looking around at their environment.

And by corollary:

If you can’t think of anything that the user does not already know, then please leave the page blank.

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.