Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)
Sorry for the delay with this continuation response. It took some time to sort out thoughts, and one needs also do some coding, not just dicussions. There's a lot to say on several story lines.
Let's start with some implementation observations.
BTW the reason I am so obsessed by validation, icons, colors etc isn't that I want to be a moron. I wanted to make an UI experiment with DecoderPro, and adding validation w/ feedback was on the list.
Dne 01. 10. 19 v 2:40 Randall Wood via Groups.Io napsal(a):
Its meant for any scenario where the state of something needs to be shownI attempted to use Border in that API as suggested. I was already playing with some tweaks to the PaneProgPane's layout - just experiments. So I've at least aligned some controls, but I didn't space them according to JLF guidelines yet. So the 'standard' Basic panel looks like: https://www.dropbox.com/s/tsub76fit7697vx/controls-aligned.png?dl=0 (red line shows control alignment)
When 'status border' is applied, the tab comes up like this: https://www.dropbox.com/s/1a8t2odmyy4xyj1/startup.png?dl=0. Also alignment of the control's active area seems broken; see the red line. Only when hovering the mouse over combos, dropdown buttons are painted like: https://www.dropbox.com/s/7z539metrca0s2y/partial-combos.png?dl=0 . That's on the Metal L&F, which may be not a focus, but is the Java default. In GTK L&F, it's even worse as combo dropdowns do not appear at all.
There are other drawing issues with controls other than textfields: right margin gets misaligned, icon appears *within* textfield border, but *outside* of combo box leading line - at least on Metal L&F. I wonder how a JTree would look like.
While I absolutely agree that "just color backgrounds" are not complete solution, I (repeating myself, sorry) need to strongly disagree with preenting DecoderPro statuses as icons. Not only because the support is not ready yet, but because validity and CVval state are different concepts. Imagine two nested Borders around an edit box, providing two icons. The user would need to get used to differentiate between icon categories, yet next to each other.
In addition, I remember that our HIE/UEXes insisted in the past, that we should use graphics sparingly, to attract the eye to important parts of the UI. Having 20+ icons in a dialog is (in *standard* conditions) not a good idea.
For statuses (not validation results !) I've got some idea(s), but would like to have two or three completely different approaches to compare/evaluate/discuss/combine so it will be probably incremental. More in a separate message.
JInput-Validator is a rather young and tiny library. I still isn't t obvious to me why it's built again from scratch, but concepts seem very similar to old good JGoodies Validation - maybe that was an inspiration in fact ? Some other concepts from JGoodies could be investigated as well; for example their idea to tag components with meta-data, which allows dialog traversal to collect & present issues in a concise list is something to consider.
I have touched briefly (in Github issue) the topic the *non-standard* glyph paint approach, taken because of supposed need to scale images, thus the image is painted from a vector font. I remember being told in the past to avoid painting "just to the Graphics2D", but use proper objects in Swing hierarchy, if possible. We were required to use Swing A11Y support at that time, which is (I think) an overkill for JMRI, but anyway: since the screenreaders etc can read the accessible description and relations - is that par of technology already dead or superseded ?
Is there a consensus an established (developer rule) that this particular style of feedback is to be spread through the UI ? Or the JInputValidator impl rather a 'slow start' experiment (introduced only recently) ?
I need to emphasize here, that requiring all(?) icons to be drawn using font glyphs may be a barrier for UI polishing development. Is it absolutely necessary to have scalable iconographics in the entire UI ? Is there a consensus that developers are required not to produce regular icons that Swing has already support for, but have font resource as primary ?
Dne 02. 10. 19 v 1:10 Randall Wood via Groups.Io napsal(a):
we didn’t concern ourselves (and maybe some developers still don’t) with making the application behave as normally as possible on Windows and macOS and GTK-based Linux.Focusing on native-like appearance is a great idea. Consistency is another one.
I took a tour trough https://docs.microsoft.com/en-us/windows/win32/uxguide/mess-error, but there are also other resources, which I think generally recommend to reserve an extra space in the dialog layout directly for feedback.
What style guide or desktop app UEX design was taken as basis for the JInputValidator ? I didn't find any such examples in MS UX or JLF resources; and I don't know GTK or MacOS enough to know where I should look.
Maybe I can find some other inspiration in that guide that will pass the consistency review at JMRI. Microsoft's idea to popup modal dialogs is not the way to go.
Dne 29. 09. 19 v 22:42 Bob Jacobsen napsal(a):
please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacyTwo observations:
1/ the red.brighter() actually obscurs the input / combo text. The color is easily recognize, but the text isn't much readable. See the picture (https://www.dropbox.com/s/0gjpotufyltf275/error-with-text.png?dl=0). The fact is that jawa.awt.Color.red is 0xffff0000 (alpha-rgb), and red.brigter() is ... 0xffff0000 to my surprise (and it's that way on JDK6..JDK11).
Whether it is necessary to have red.brighter() (not just red) for proper contrast, I can't tell, but if so, should be derived differently (and maybe the black text would be more readable).
1/ yellow seems actually too bright (I am used to work with white background and light color themes, and it shines even there). It is good for *highlight* to call attention; but even Google uses #ffeb3b, rather than #ffff00. Various visual guidelines suggest, that a yellow (or orange) should be used for something like warning or alert states.
Please do not take the above as the red/yellow "do not work". They do, because JMRI wants to cover as much users as possible by default.
Implementation-wise, I'd suggest to consider reading the colors from UIManager, then fallback to hardcoded defaults. Maybe some abstract naming, that could allow to share colors across the application.
A weird idea how to combine "pastel" mild colors (bad heritage from my HIE/UEx colleagues), intensive colors (eliminate color vision issues) AND icons (works for b/w vision) could be combined will follow (after/if it settles a bit).
Thanks to anyone who managed to read up to this line,
Working through all the great info in the email while on a phone, it’ll take a bit to compose a reply, but want to make two points:
1) Maybe it’s time to allow embedded graphics on the developers list? Spam filtering has advanced a bit since 2003… If anybody wants to discuss that, please start another thread.
2) JMRI is not a word processor. It’s more like a process control system. As such, certain user expectations (which mostly come from document-related UIs) make sense, and others don’t. Coloring to represent status of controls and values has a _long_ and well-understood history in process control. It predates computer screens (here’s where I’d embed a picture of a 60’s process panel, see item 1) but has lasted through them to even now (would embed another picture). I think a unified methodology for presenting the status underlying values is fine, having common code is great, but not being in some set of HI-specification docs is _not_ sufficient reason to move away from color as a way of indicating actionable status (and, yes, I’m am very color blind).
On Oct 4, 2019, at 4:25 PM, Svata Dedic <svatopluk.dedic@...> wrote:--
Bob,toggle quoted messageShow quoted text
From what I see, attachmenst are allowed in this group. The below is from the group guidelines.
Messages, Files and Photos
Messages in either plain text or HTML are permitted. Attachments are allowed also but, where appropriate, please upload any relevant files to the Files section.
Please sign messages with your name as it makes the group friendlier and much easier to follow messages. Nicknames or Handles are fine, just try to stay consistent.
Any pictures that you wish to share should be uploaded to the Photos section. Large photos will be resized to a maximum size of 2048x2048 pixels.
Archives of messages are publicly visible, but email addresses are hidden within the online archive.
Files and Photos are only visible to group members.
There are limits for the amount of Photos and Files that can be stored. As a result, old Photos and Files may be removed from the archive to keep within these limits.
On Fri, Oct 4, 2019 at 05:55 PM, Bob Jacobsen wrote:
JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/