| View previous topic :: View next topic |
| Author |
Message |
Wolfgang Kern
Guest
|
 Posted: Sun Jun 29, 2008 6:51 pm Post subject: The Logic of Buttons |
 |
|
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 |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Sun Jun 29, 2008 6:51 pm Post subject: Re: The Logic of Buttons |
|
|
On Jun 29, 6:51 am, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Terence
Guest
|
| Posted: Sun Jun 29, 2008 10:33 pm Post subject: Re: The Logic of Buttons |
|
|
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Terence
Guest
|
| Posted: Sun Jun 29, 2008 11:39 pm Post subject: Re: The Logic of Buttons |
|
|
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. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Mon Jun 30, 2008 2:13 am Post subject: Re: The Logic of Buttons |
|
|
On Jun 29, 5:07 pm, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
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.
Oh that's why I had to modify a lot of equipment which come from
US to Europe ... must change the power-led into a green one :)
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.
Yes, text in red should mean a warning ie: error-messages.
But I'd see green as the 'active' (open road) color while gray can
mean 'passive', and I use yellow to catch the users eye for the
current focus like caption highlight and active input-fields.
__
wolfgang
|
I didn't call it out explicitly, but unless it's needed to draw a huge
solid box indicating some state or warning that has to be noticeable
from afar, many colors aren't very good: stylistically, because they
may unnecessarily draw attention or even distract, there may be poor
light conditions or the user may have some kind of color blindness (or
it could be hardware malfunction, say all red goes out), it's often
hard to distinguish colors of small objects, so the color information
may either be lost/unnoticed, or create extra problems. IMO proper
brightness/contrast is more useful than colors.
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Mon Jun 30, 2008 3:25 am Post subject: Re: The Logic of Buttons |
|
|
On Jun 29, 8:51 am, "Wolfgang Kern" <nowh...@never.at> wrote:
| Quote: |
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'.
|
Inset as active makes sense to me.
| Quote: |
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'.
As far as color, or colour schema goes, consider inset (on/set) |
indicated by color, outset (off/clear) as greyed. This sidesteps the
issue of which of red/green is on/set, because both colors are often
used to indicate 'hot'. jmo.
| Quote: |
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 |
|
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. Peter Anvin
Guest
|
| Posted: Mon Jun 30, 2008 4:08 am Post subject: Re: The Logic of Buttons |
|
|
Terence wrote:
| Quote: |
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.
| Quote: |
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 |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Mon Jun 30, 2008 4:48 am Post subject: Re: The Logic of Buttons |
|
|
Alexei A. Frounze replied:
[about...]
| Quote: |
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
|
Right, I just made all those variants to have some opportunities.
My idea was/is to have editable items either as button or field,
where both create a mouse-rectangle on the fly by copying the
relative border rectangle values (also if border-style is 'none').
| Quote: |
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).
|
Good idea,
I implemented a font doubler (bold or shadowed text) anyway.
It isn't as fast as a shadow rectangle around the text, will be
limited to a certain color-set and I have to create a mouse-rectangle
(my buttons do this on the fly), but the effect seems interesting and
may fit many other desires as well, so I'll give this a try.
Thanks Alexei,
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. Peter Anvin
Guest
|
| Posted: Mon Jun 30, 2008 4:48 am Post subject: Re: The Logic of Buttons |
|
|
Terence wrote:
| Quote: |
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...
|
Haven't spent too much time in broadcasting, but the little I have there
were two signal lights: green for "equipment on" and red for "on air".
-hpa |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Mon Jun 30, 2008 5:07 am Post subject: Re: The Logic of Buttons |
|
|
Terence wrote:
| Quote: |
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.
|
Oh that's why I had to modify a lot of equipment which come from
US to Europe ... must change the power-led into a green one :)
| Quote: |
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.
|
Yes, text in red should mean a warning ie: error-messages.
But I'd see green as the 'active' (open road) color while gray can
mean 'passive', and I use yellow to catch the users eye for the
current focus like caption highlight and active input-fields.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Mon Jun 30, 2008 4:10 pm Post subject: Re: The Logic of Buttons |
|
|
Alexei A. Frounze wrote:
....
| Quote: |
Yes, text in red should mean a warning ie: error-messages.
But I'd see green as the 'active' (open road) color while gray can
mean 'passive', and I use yellow to catch the users eye for the
current focus like caption highlight and active input-fields.
I didn't call it out explicitly, but unless it's needed to draw a huge
solid box indicating some state or warning that has to be noticeable
from afar, many colors aren't very good: stylistically, because they
may unnecessarily draw attention or even distract, there may be poor
light conditions or the user may have some kind of color blindness (or
it could be hardware malfunction, say all red goes out), it's often
hard to distinguish colors of small objects, so the color information
may either be lost/unnoticed, or create extra problems. IMO proper
brightness/contrast is more useful than colors.
|
I think colors may be the best method to increase contrast.
Perhaps I use too many different colors in my default setting, but
every user can define (except error/system msg) an own color-set,
even most of my clients accepted my style and use the default.
For my worn old eyes I find colors extremely convenient,
ie: my debug-plate, call it a box, but never a window :)
* the plate itself is gray with an outset (other grays) border.
* its caption show the current mode (RM/PM16/32/Big..) and is
white on dark gray with a thin black border while passive and
turns into yellow on black if this plate is in focus.
* the status field is normal black on white (EDIT/TRACE/RUN/DONE)
but will become red on black if an exception occured (EXCnn).
* editable fields (almost all Regs and debug bits) are organised
on an X/Y input grid and display values in green on black
with a thin inset border when the grid-cursor is elsewhere
(this colors indicate an editable item; bit status use button-styles
but also change colors with focus)
and change to Red on Yellow if the active input, the digit-cursor
within the field just reverses this colors then.
For List-selectors like the file-browser, I just use black on white
and reverse colors for the actual line.
So I immediate can see where the damned Cursor is, regardless
of how many boxes may be on the screen.
And I really have 'some' problems with ie: OE6 and similar to find
the actual text-cursor beside the always funny hiding mouse-cursor.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Mon Jun 30, 2008 4:17 pm Post subject: Re: The Logic of Buttons |
|
|
Steve wrote:
| Quote: |
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'.
|
Inset as active makes sense to me.
| Quote: |
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'.
|
As far as color, or colour schema goes, consider inset (on/set)
indicated by color, outset (off/clear) as greyed. This sidesteps the
issue of which of red/green is on/set, because both colors are often
used to indicate 'hot'. jmo.
Yes for message type display, but when things become editable they
are kinda 'hot', so I use green on black to indicate 'input item'
and red on yellow if on focus. I think adding more colors for the
status of the bits may easy lead to confusion.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Matt
Guest
|
| Posted: Mon Jun 30, 2008 9:15 pm Post subject: Re: The Logic of Buttons |
|
|
Wolfgang Kern wrote:
| Quote: |
Alexei A. Frounze wrote:
....
Yes, text in red should mean a warning ie: error-messages.
But I'd see green as the 'active' (open road) color while gray can
mean 'passive', and I use yellow to catch the users eye for the
current focus like caption highlight and active input-fields.
I didn't call it out explicitly, but unless it's needed to draw a huge
solid box indicating some state or warning that has to be noticeable
from afar, many colors aren't very good: stylistically, because they
may unnecessarily draw attention or even distract, there may be poor
light conditions or the user may have some kind of color blindness (or
it could be hardware malfunction, say all red goes out), it's often
hard to distinguish colors of small objects, so the color information
may either be lost/unnoticed, or create extra problems. IMO proper
brightness/contrast is more useful than colors.
I think colors may be the best method to increase contrast.
Perhaps I use too many different colors in my default setting, but
every user can define (except error/system msg) an own color-set,
even most of my clients accepted my style and use the default.
For my worn old eyes I find colors extremely convenient,
ie: my debug-plate, call it a box, but never a window :)
* the plate itself is gray with an outset (other grays) border.
* its caption show the current mode (RM/PM16/32/Big..) and is
white on dark gray with a thin black border while passive and
turns into yellow on black if this plate is in focus.
* the status field is normal black on white (EDIT/TRACE/RUN/DONE)
but will become red on black if an exception occured (EXCnn).
* editable fields (almost all Regs and debug bits) are organised
on an X/Y input grid and display values in green on black
with a thin inset border when the grid-cursor is elsewhere
(this colors indicate an editable item; bit status use button-styles
but also change colors with focus)
and change to Red on Yellow if the active input, the digit-cursor
within the field just reverses this colors then.
For List-selectors like the file-browser, I just use black on white
and reverse colors for the actual line.
So I immediate can see where the damned Cursor is, regardless
of how many boxes may be on the screen.
And I really have 'some' problems with ie: OE6 and similar to find
the actual text-cursor beside the always funny hiding mouse-cursor.
__
wolfgang
Certain colour combinations should be avoided because they are |
unreadable. For example, yellow on blue or yellow on black. Generally,
avoid light text on dark background because it is a lot more difficult
to read and causes eye-strain. Certain other colour combinations can
cause problems if the colour isn't bright enough, like red on grey,
which can easily vanish at a distance.
Basically, the best combinations are Black on a colour, or black on grey.
As for red or green being 'on' I get annoyed about this all the time.
Green should mean 'working correctly' or 'do something safe', amber
should mean 'something is wrong but not catastrophic' or 'do something a
bit dodgy', and red should mean 'danger', or 'things have failed' or 'do
something dangerous'.
Lights for information (Power is on etc.) should come under the category
of 'working correctly', unless the light is indicating something like a
power socket, where it means 'danger, this socket is live'.
Matt |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Tue Jul 01, 2008 4:12 pm Post subject: Re: The Logic of Buttons |
|
|
Matt replied:
....
| Quote: |
Certain colour combinations should be avoided because they are
unreadable. For example, yellow on blue or yellow on black. Generally,
avoid light text on dark background because it is a lot more difficult
to read and causes eye-strain. Certain other colour combinations can
cause problems if the colour isn't bright enough, like red on grey,
which can easily vanish at a distance.
Basically, the best combinations are Black on a colour, or black on grey.
|
Yes, I checked the readability from a more distant view (~1 meter)
and just changed my default for passive captions to black on gray(75%)
while active (highlighted) will remain black on yellow.
| Quote: |
As for red or green being 'on' I get annoyed about this all the time.
Green should mean 'working correctly' or 'do something safe', amber
should mean 'something is wrong but not catastrophic' or 'do something a
bit dodgy', and red should mean 'danger', or 'things have failed' or 'do
something dangerous'.
|
I agree on that one, and I'll check if I can find another 'crying'
colour-pair instead of yellow/red for menu-grid and field cursors,
even this two swow also a good contrast if reversed.
But I find green on black for passive input items extremely good
readable, perhaps because I'm familiar with old Logic-Analysers.
| Quote: |
Lights for information (Power is on etc.) should come under the category
of 'working correctly', unless the light is indicating something like a
power socket, where it means 'danger, this socket is live'.
|
Yes, and that's why I prefer inset/outset shadow-rectangles over
colours for status display.
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Terence
Guest
|
| Posted: Tue Jul 01, 2008 11:58 pm Post subject: Re: The Logic of Buttons |
|
|
I think the current human acccepted status is
Green = "OK" or "proceeding"
Red = "Warning" or "there is a potential harmful outcome"
Yellow = "be advised"
I couldn't think of a situation opposed to this arrangement. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
125 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
