|
From: Wolfgang Kern on 29 Jun 2008 09:51 So far I see no problem to make the dear end users believe in my logic for a pressed button (shown as inset) as 'active'. This works fine for both, single selection, like radio-buttons; list-selectors; color-box, and multi-selectable (check-box styled) option-flag inputs. But when it comes to show the status of bits (users wont care anyway) could this confuse programmers if I'd use it in tools ?? ie: if an EFlags display show clear bits 'outset' and set bits 'inset'. It wouldn't be much work to change my default setting on this, but it will be in conflict with the 'other button logic' then. Sure I could go back and use again Ucase/Lcase indication for bit status display, or use other button borders. I defined 16 types this means 8 active/inactive pairs yet. I like to get a clue about the optimal order of my border-styles, at the moment I got: 0,1: none /single near color00 ;01==grayed 2,3: shadow single close inset/outset ;02==Txt/Num input field std. 4,5: shadow single outer inset/outset 6,7: shadow double inset/outset 8,9: single close color01/02 a,b: single close color03/04 c,d: double color01/02 e,f single outer color01/02 so if I assign an (named single bit yet) input item the borderstyle ie: 5, it will show a (one dot distant) outset shadow border if passive, the same as inset if active and the reverse if I'd set it to 4. I can override all this by assigning any borderstyle for active and passive at any time in application scripts, but I'm afraid those who have to write them may be confused a lot, so I search for the simpler. __ wolfgang
From: Alexei A. Frounze on 29 Jun 2008 10:42 On Jun 29, 6:51 am, "Wolfgang Kern" <nowh...(a)never.at> wrote: > So far I see no problem to make the dear end users believe > in my logic for a pressed button (shown as inset) as 'active'. > > This works fine for both, > single selection, like radio-buttons; list-selectors; color-box, > and multi-selectable (check-box styled) option-flag inputs. > > But when it comes to show the status of bits (users wont care anyway) > could this confuse programmers if I'd use it in tools ?? > > ie: if an EFlags display show clear bits 'outset' and set bits 'inset'. > > It wouldn't be much work to change my default setting on this, > but it will be in conflict with the 'other button logic' then. > > Sure I could go back and use again Ucase/Lcase indication for bit > status display, or use other button borders. I defined 16 types > this means 8 active/inactive pairs yet. > I like to get a clue about the optimal order of my border-styles, > at the moment I got: > > 0,1: none /single near color00 ;01==grayed > 2,3: shadow single close inset/outset ;02==Txt/Num input field std. > 4,5: shadow single outer inset/outset > 6,7: shadow double inset/outset > 8,9: single close color01/02 > a,b: single close color03/04 > c,d: double color01/02 > e,f single outer color01/02 > > so if I assign an (named single bit yet) input item the borderstyle > ie: 5, it will show a (one dot distant) outset shadow border if passive, > the same as inset if active and the reverse if I'd set it to 4. > > I can override all this by assigning any borderstyle for active and > passive at any time in application scripts, but I'm afraid those who > have to write them may be confused a lot, so I search for the simpler. > > __ > wolfgang You don't want: 1. too many elements/too much clutter (borders around individual bits) 2. too many styles (borders or colors) 3. too many or possibly hard to distinguish colors 4. it to work with letters only (CF/cf - OK, but what about l/L vs i/ I? and there're no upcase/locase for numbers) 5. 0s (or 1s) or whatever is one of the two states to be practically invisible on the background 6. it to be confusing/unfamiliar In my opinion, the best would be to draw 0's/cf's as contours (that is, hollow) and 1's/CF's as solid. Same 2 background and foreground colors, same font size, no extra funky borders, case doesn't matter (it would always be CF or just C or whatever that is, just solid or hollow), even if the flag/feature is inactive/reset/off it's very well visible and more of the default background color visible through it would suggest it's off (always the case when the background is gray, but even when it's not it should be intuitive enough). And this would be completely independent of what control is in focus. One catch. You need: good screen resolution and two fonts (or two methods of text rendering). Alex
From: Terence on 29 Jun 2008 18:33 It has become standard usage for home equipment to have a red light ON when the device is active. So STOP the device if this is not what you want. In utility software (e.g. Norton Utilities), a green button message offers a service and a red button message offers to stop the service. A red traffic light means "Stop" in the sense "This is what you must do otherwise you willget hurt". A red berry in the wild usually indicates that wild life should not eat it since eating a red thing usually brings a nasty result and a re- inforcing rememberance. This is why we humans USE red for warnings.. So all red symbols are, or should be, warnings that a situation is active.
From: H. Peter Anvin on 29 Jun 2008 19:08 Terence wrote: > It has become standard usage for home equipment to have a red light ON > when the device is active. > So STOP the device if this is not what you want. Actually, it's becoming more and more common for that light to be green, or sometimes blue. The origin of the red LED for this, of course, is that red LEDs used to be dramatically cheaper than any other LED. I have been told that at least according to European standards, red is supposed to be reserved for failures. > A red berry in the wild usually indicates that wild life should not > eat it since eating a red thing usually brings a nasty result and a re- > inforcing rememberance. This is why we humans USE red for warnings.. Ever eaten wild raspberries? -hpa
From: Terence on 29 Jun 2008 19:39 Er, there used to be glass bulb thingies with a wire inside, like the 2LO red light on a pole when the BBC microphone was active, the bulb was externally painted red. And there was another red one on the wall outside... Even those new TV cameras, after that particularly nasty war, had a red light where one could see it, to know in which direcction to emote or present one's best side... I just checked, and all the new electronicsf we have have all got red lights when curent is present. Electric stove rings, ovens hotplate and rotiserrires all one each. Our TV box goes green only if we have a channel selected, but our non-box TVs turn the red light off and the screen on, if we select a channel. However my Monitors have a green light, but are plugged into a power unit with a red light... I still think red is proponderant.
|
Next
|
Last
Pages: 1 2 3 4 Prev: Why use the C language? Next: Battleships - was:: a compainion book for aoa? |