Topics

Status colors vs icons in Decoder Pro II

Svata Dedic
 

[again a long e-mail; sorry. Continuation of the original discussion around boders and colors]

Re. colors vs. icons. I think we have a classical situation:
1/ most people are used to colors
2/ most people can differentiate between the colors in the JMRI current color scheme
3/ SOME people don't see colors so they're BLOCKED: the information is not presented elsewhere
4/ MOST people would be baffled if 20+ icons would pop up suddenly
5/ at least two individuals (me and my colleague ;)) find the state colours too contrast

I suppose I am missing some obvious (but critical) piece in the puzzle. But usually it's possible to, based on e.g. some central Preference ("enable assistive technologies -> emphasize states") add pieces to the UI, which would be otherwise hidden (not present) - unless that pref is enabled.
It does not work "out of the box" for everyone. But if you teach the user to trust JMRI in that will (gradually) honour the "assistive" option on other places that are problematic, it will be fine. Consistency and reliability (to provide assisitance) is the golden egg; not "out of box" behaviour. I would however suggest to implement it as one 'grand' "Assistive technologies ON" option and then - if even necessary - revert certain aspects/pieces to "normal".

Could it work for JMRI ?

The current state can be the "ground level". When AT enabled (going up), the UI will become more assistive - with some tradeoffs. When going down (i.e. explicit color scheme or customization mentioned below), the UI would become more "desktop common".

Result: groups 1,2,4 untouched, group 4 can get virtually ANYTHING imaginable, even if seen obtrusive to groups 1,2,4 - the 'cost' is paid when the user chooses to. But still does not answer a question HOW to present the state (in addition to colors).

---

@Randall:
as I wrote elsewhere, I think that having validity AND state represented by the same UI is not good. Here are some approaches I have seen already (= didn't tried in JMRI, no working example). Not super-clever, some could be crazy. Assuming the behaviour will be opt-in as outlined above.

- add icon as you intended. Selfishly said, you have "your" users; if they will be satisfied, excellent. With opt-in behaviour "mine" users won't be affected. I will be happy to provide a slot for the additional optional annotation as part of the decoder pro layout works.

- place state icon elsewhere, not at the end of input lines. I have no clue what to do with combo boxes and checkboxes.

- reseve cells in gridbag layout, put _textual_ status there, can use e.g. italic to differentiate from regular text. Without 'AT' enabled, the cells would be empty -> no effect. Will not work for individual checkboxes in tables; but usually whole row or column changes state.

- add hotkeys (buttons ?) to decorate controls in a particular state. Can use glass pane to paint around control when the trigger is pressed. Could require more spacing in the dialog. Decoration could be transient and stay visible until the hotkey (button) is released.

- stable border-like decoration (solid, dashed, dotted, double) around controls, or better label-control pairs - provided there's more space between them

- overlay very small icons on the top/bottom left of controls; can use glass pane painting, similar to JGoodies

- provide baloon state tooltip for the _focused_ control - does not give an overview for the pane

- add prefix / suffix character to a label, as in the days of ASCII art in UI: (*), (#), (^), (v)

I would personally go for the label decoration (very easy, works for any L&F), or the styled rectangles painted on glass pane. Or, to better support A11Y, I'd add text status on the grid as JLabel, and link it using AccessibleContext.getAccessibleRelationSet().add(AccessibleRelation.LABEL_FOR) to the control.

---

Since (5) is negligible (me and a colleague who mentioned he patches the color to some other one), but willing to contribute code ;) I propose to:
- No UI visual changes.
- define UIDefaults keys "jmri.decoderpro.staus.{error,fromfile,unknown...}", initialize the keys on startup and change the current COLOR_ initialization to read the UIDefaults.

If I contribute color scheme customizer into Preferences, everyone can tune "jmri.*" colors to what he sees fit for his/her desktop theme. Synergy: if someone else adds UIDefault key "jmri." of Color type (to be used in other part of JMRI), the supposed customizer will work for him automatically, too.

-S.

Bob Jacobsen
 

Adding assistive technologies via some preference (doesn’t need to be hidden) seems fine. I’m not sure about having a grand “on/off” vs more detailed tuning: I doubt you’ll find a _single_ set of assistive controls that work. But that’s to be seen.

A first one, which can also be used just as an adjustment for what people prefer, might be the backgrounds in DP: Allow selection of the various color values via a color selector, so people can select the ones that work for them.

If the use of color per se is an issue in DP values, there are also other approaches possible: Background pattern (which could be in B&W) for data values, backgrounds (ditto) in an island/border added to checkboxes/radioButtons/selectionBoxes, etc. That might be an example of a separate assistive control.

I’m still not certain what you mean by “validity” vs “state” which keeps coming up, could you amplify that point please?

Bob


On Oct 9, 2019, at 3:17 PM, Svata Dedic <svatopluk.dedic@...> wrote:

[again a long e-mail; sorry. Continuation of the original discussion around boders and colors]

Re. colors vs. icons. I think we have a classical situation:
1/ most people are used to colors
2/ most people can differentiate between the colors in the JMRI current color scheme
3/ SOME people don't see colors so they're BLOCKED: the information is not presented elsewhere
4/ MOST people would be baffled if 20+ icons would pop up suddenly
5/ at least two individuals (me and my colleague ;)) find the state colours too contrast

I suppose I am missing some obvious (but critical) piece in the puzzle. But usually it's possible to, based on e.g. some central Preference ("enable assistive technologies -> emphasize states") add pieces to the UI, which would be otherwise hidden (not present) - unless that pref is enabled.
It does not work "out of the box" for everyone. But if you teach the user to trust JMRI in that will (gradually) honour the "assistive" option on other places that are problematic, it will be fine. Consistency and reliability (to provide assisitance) is the golden egg; not "out of box" behaviour. I would however suggest to implement it as one 'grand' "Assistive technologies ON" option and then - if even necessary - revert certain aspects/pieces to "normal".

Could it work for JMRI ?

The current state can be the "ground level". When AT enabled (going up), the UI will become more assistive - with some tradeoffs. When going down (i.e. explicit color scheme or customization mentioned below), the UI would become more "desktop common".

Result: groups 1,2,4 untouched, group 4 can get virtually ANYTHING imaginable, even if seen obtrusive to groups 1,2,4 - the 'cost' is paid when the user chooses to. But still does not answer a question HOW to present the state (in addition to colors).

---

@Randall:
as I wrote elsewhere, I think that having validity AND state represented by the same UI is not good. Here are some approaches I have seen already (= didn't tried in JMRI, no working example). Not super-clever, some could be crazy. Assuming the behaviour will be opt-in as outlined above.

- add icon as you intended. Selfishly said, you have "your" users; if they will be satisfied, excellent. With opt-in behaviour "mine" users won't be affected. I will be happy to provide a slot for the additional optional annotation as part of the decoder pro layout works.

- place state icon elsewhere, not at the end of input lines. I have no clue what to do with combo boxes and checkboxes.

- reseve cells in gridbag layout, put _textual_ status there, can use e.g. italic to differentiate from regular text. Without 'AT' enabled, the cells would be empty -> no effect. Will not work for individual checkboxes in tables; but usually whole row or column changes state.

- add hotkeys (buttons ?) to decorate controls in a particular state. Can use glass pane to paint around control when the trigger is pressed. Could require more spacing in the dialog. Decoration could be transient and stay visible until the hotkey (button) is released.

- stable border-like decoration (solid, dashed, dotted, double) around controls, or better label-control pairs - provided there's more space between them

- overlay very small icons on the top/bottom left of controls; can use glass pane painting, similar to JGoodies

- provide baloon state tooltip for the _focused_ control - does not give an overview for the pane

- add prefix / suffix character to a label, as in the days of ASCII art in UI: (*), (#), (^), (v)

I would personally go for the label decoration (very easy, works for any L&F), or the styled rectangles painted on glass pane. Or, to better support A11Y, I'd add text status on the grid as JLabel, and link it using AccessibleContext.getAccessibleRelationSet().add(AccessibleRelation.LABEL_FOR) to the control.

---

Since (5) is negligible (me and a colleague who mentioned he patches the color to some other one), but willing to contribute code ;) I propose to:
- No UI visual changes.
- define UIDefaults keys "jmri.decoderpro.staus.{error,fromfile,unknown...}", initialize the keys on startup and change the current COLOR_ initialization to read the UIDefaults.

If I contribute color scheme customizer into Preferences, everyone can tune "jmri.*" colors to what he sees fit for his/her desktop theme. Synergy: if someone else adds UIDefault key "jmri." of Color type (to be used in other part of JMRI), the supposed customizer will work for him automatically, too.

-S.


--
Bob Jacobsen
@BobJacobsen

Svata Dedic
 

Dne 10. 10. 19 v 0:37 Bob Jacobsen napsal(a):
I’m still not certain what you mean by “validity” vs “state” which keeps coming up, could you amplify that point please?
Randall has developed a web-like border - works for JTextFields well at this moment - that dislays feedback "OK-waring-error" within textfield's border. Can be seen in New Turnout dialog - attached picture.

DecoderPro does not use (yet!) these, but should - IMHO this is better than auto-correction in DecoderPro, as the use see what he did wrong and can do better next time.
<decval/> entries can be constrained to min/max and turned to spinners, but there are still some CVs with more complex rules.

Suppose 'state' _icons_ would be used to amplify colors used by DecoderPro:

1/ Consider an edit box (i.e. some PWM, where min/max setting is not a sufficient restriction) that displays "warning" (value out of range) AND an icon that represents the edited/file/stored state at the same time
Not an usual thing, so I would prefer, especially if the icons are next to each other.

2/ the 'invalid' icon (incorrect user entry in field) actually prevents operations on the dialog. 'stored state' icon is 'just' indicator.

IMHO it's better to stick to the desktop/web behaviour that an icon next to control "means problems" - least surprise. Colors except red are not perceived as "problem" usually.

-S.