...I must be a bad designer because I do just what you are saying is a no-no, which is to leave a small amount of real estate blank. The error indicators stay invisible until an error condition occurs, so that the panel is not cluttered with indicators for rarely occurring things. Sometimes I use "ugly" error indicators, and more often I use more elegant indicators, like a red or yellow square LED's with text...
From the operator's point of view, I like to know what's coming and dislike having things pop out at me from nowhere. The "Disabled and Grayed" state is my favorite. The indicator is subdued until it is needed, but everyone knows it is there. Sometimes I'll stack infrequently used indicators on top of each other with one grayed and the others invisible. The user doesn't know what might pop up but at least knows something is there.
For your more elegant design, I'd suggest that switching an LED indicator from off to on is nearly as attention getting as making it appear but not so startling.
From the programmer's point of view, invisible indicators are more easily misplaced and hidden under others or off-screen than grayed-out ones when a program is upgraded, especially if the upgrade is done by someone other than the original author.
Michael Aivaliotis wrote:
... I think in general, any input that accepts a boolean should accept the error cluster and operate based on the error logic.
The Select primitive is one function that does accept the error cluster as an input. I often use it to choose between enabled and grayed constants. Showing labels for these constants neatly documents the diagram.
--
EnWirementally,
Paul F. Sullivan----------------------------------------------------
SULLutions (781)769-6869
"when a single discipline is not enough"visit http://www.SULLutions.com
----------------------------------------------------
