Topics

Preview: alignment in gridbag layout

Svata Dedic
 

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Todo:
- Add colorized background for spinners.
- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip
- generate "range" tooltips for numeric fields, from min/max.

Future possible experiments:
* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

-Svata

Dave Heap
 

Comments;

On 16 Oct 2019, at 6:57 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

The design philosophy when I created <grid> in JMRI was to allow use of all  GridBagLayout features supported by Swing. Discarding (making unavailable) a previously-available feature because you don't like the results of using it is not your call. It's also not fair on other custom definition developers who may already be relying on it in ways you don't expect/forsee.


2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

We have to remain aware of the fact that other custom definition developers may have used techniques to overcome the existing shortcomings and your changes could break existing things.


3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

I'm undecided on the readability merits of that, given the widely-varying label length in some panes and the resulting wide gaps between some labels and their boxes.

Personally, I find your modified Basic and Lights panes harder to read than the old versions.

We have to remain aware of the fact that other definition developers may have used techniques to overcome the existing shortcomings and your changes could break things.

Do we need a "justify" attribute for labels?

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

That's probably a good move, given it doesn't break existing layouts.


5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

Again, we have to remain aware of the fact that other definition developers may have used techniques to overcome the existing shortcomings and your changes could break things.

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

I'm not sure what you mean by "punctuation"? Do you simply mean adding a ":" in the definition  to the end of some labels (as in your sample) or that the ":" punctuation will be added to all labels by default?

By "accelerators" I'm guessing you mean the underlined shortcut keys to gain focus on a field?

Related question: We explicitly support embedded HTML in pane text, and I'm assuming that embedded HTML is also supported in our labels:
We don't want to break that.



7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

I'm quite in favour of spinners provided we allow text-field editing of the value (JSpinner.NumberEditor).

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Not sure how you plan to decide on when and how far to shorten? Assume some extra attribute(s) to maintain compatibility.

Todo:
- Add colorized background for spinners.

I assume you mean STATE colour?

- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip

Make sure any merges to tooltips uses "jmri.util.StringUtil.concatTextHtmlAware" in case existing and/or added text uses embedded HTML.

Also be aware that Preferences->Roster->Programmer->Show CV Numbers in Tooltips uses StringUtil.concatTextHtmlAware to append CV number(s) and bit allocation(s) to tooltips.

- generate "range" tooltips for numeric fields, from min/max.

See above.


Future possible experiments:

* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

Provided it doesn't break existing...

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

Provided it doesn't break existing...

Some of these suggested changes look good to me, but not all.

I'd certainly want to see the results of applying your Java code changes to untouched existing custom panes I wrote for the LokSound V4 and 5 definitions. Your changes need to pass the "don't break existing" rule. We've far too many definitions out there that we don't want/need to check and change, not to mention users who have their own private not-submitted definitions.

Dave in Australia





Bob Jacobsen
 

A couple high-level comments on this:

It would be helpful if you would push a branch with this to your GitHub repo so that we can run it ourselves. Understood that it’s not final. The idea is to see how it works with various existing definitions, etc.

We might want to have a discussion about what kind(s) of compatibility is going to be required. There’s a spectrum:

4) _All_ existing decoder & programmer definitions validate and display exactly as they did before
3) A manageable (which is an operational question, it’s manageable if we get it done) number require updates to display exactly as they did before
2) _All_ existing decoder & programmer definitions validate and display all the content reasonably, but not laid out as before
1) A manageable (which is an operational question) number have validation issues, which we correct, and they all display all the content reasonably, but not laid out as before
0) A manageable (which is an operational question) number have validation issues, which we correct; they all display, but some are Really Ugly and we don’t have the time it would take to fix them right.

i.e. (3) might be because we added an attribute that has to be specified to get them to look the same, and somebody has to decide how to set that. Reasonable people can differ on the ordering of e.g. 3&2, and what the definition of “reasonably” vs “Really Ugly” are.

I think “everything has to display exactly as it did with no changes” is too high a standard. On the other hand, having any significant number of decoders too ugly to use isn’t going to be a success.

I think there’s certainly room to _improve_ the display, even if that means people have to get used to some changes. But perhaps others differ.

Bob





On Oct 15, 2019, at 12:57 PM, Svata Dedic <svatopluk.dedic@...> wrote:

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

2/ extend with (height) to match the column. Makes rows in a column visually aligned. Spacing according to "related" spacing (will yet recode that to match L&F behaviour).

3/ labels left-justified: recommended for complex dialogs as the user can scan top-down starts of lines to find the one of interest.

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.

5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)

6/ Added puctuation to labels, support for accelerators (see the basic new pane).

7/ Spinners instead of decimal-value inputs, where there's min+max range. Consistent with GTK+.

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.

Todo:
- Add colorized background for spinners.
- provide tooltips for individual ComboBox items + selected item. Merge with combo's own tooltip
- generate "range" tooltips for numeric fields, from min/max.

Future possible experiments:
* Support some "merged" attribute for rows/column: layouter could make a grid from adjacent columns (rows). I don't want to turn it into <grid> directly, as the column (row) emphasizes flow of the components. A two-column (three-column) newspaper like layout is different from a grid.

* Think about three-cell variable layout: label, control, explanation. Could be useful for *some* (or all ?) layouts.

-Svata



<basic-new.png><basic-old.png><lights-new.png><lights-old.png>
--
Bob Jacobsen
@BobJacobsen

Dave Heap
 

Update,

On 16 Oct 2019, at 9:49 AM, Dave Heap <dgheap@...> wrote:

Do we need a "justify" attribute for labels?

4/ Panels anchored north-west. Makes content of the tab positioned at the same place, the user need not to look where the center is on each tab.
That's probably a good move, given it doesn't break existing layouts.
Looking again at the north-west alignment, I'm not sure it sits well with the centre alignment of the action/status panels below. I'd prefer a north alignment rather than the current centre alignment.

Likewise, the more I look at the samples, the less I like the enforced stretching of the input fields to all match the longest field and the detachment (by variable-length whitespace) of the labels from the input field.

I'm afraid that in both sample cases I find the old versions easier to read.

But I certainly don't like the current way multi-column format (e.g. The Basic pane) pads every column to fit the panel, resulting in a disconnection of columns if the tab size is expanded in order to easily view other (wider) tabs.

But these are just my opinions and others will no doubt have differing responses.

Dave in Australia

Dave Heap
 

My apologies,

On 16 Oct 2019, at 9:49 AM, Dave Heap <dgheap@...> wrote:

On 16 Oct 2019, at 6:57 AM, Svata Dedic <svatopluk.dedic@...> wrote:

Just a sneak preview of the changes. Done the following:
1/ discard ipadx, use insets.
ipadx adds to minimum width affecting the component itself. Inset is a gap between component boundary and the cell. The goal is to make visual separation between the components not to fill an entire cell with it.

The design philosophy when I created <grid> in JMRI was to allow use of all  GridBagLayout features supported by Swing. Discarding (making unavailable) a previously-available feature because you don't like the results of using it is not your call. It's also not fair on other custom definition developers who may already be relying on it in ways you don't expect/forsee.

I've just realised you were talking about my use of ipadx in "switch (layout)" block at lines 2294ff of PaneProgPane.newVariable().

Yes, changing those to insets sounds a good idea.

My apologies again.

Dave in Australia

Svata Dedic
 

Hi,

Dne 16. 10. 19 v 1:19 Bob Jacobsen napsal(a):
It would be helpful if you would push a branch with this to your GitHub repo so that we can run it ourselves. Understood that it’s not final. The idea is to see how it works with various existing definitions, etc.
Will do, in a couple of hours.
I wanted to finish some of the TODOs, but I can wrap up and commit. Note that the code may contain shortcuts, it's a prototype. Feel free to make a PR against the branch, even to just add "FIXME" or "TODO" alert.

We might want to have a discussion about what kind(s) of compatibility is going to be required. There’s a spectrum:
4) _All_ existing decoder & programmer definitions validate and display exactly as they did before
Re. validation: I didn't changed the XML format _yet_, didn't even add an attribute.

Is it required they _look_ exactly as they did before, or that they _display items_ they did before ? Bcs. if they should _look_ as before ;) there's no point in chaning alignment, or sizes :)
If so, please tell me -- I'd better invest my time to writing new code than trying to retrofit the JMRI master branch.

3) A manageable (which is an operational question, it’s manageable if we get it done) number require updates to display exactly as they did before
IMHO all the *layout* changes can be made pluggable. The prototype directly changes the (refactored) GridBagLayoutBuilder to make changes visible in diff, but ultimately there can be more Builders.

The baseline should be a refactored GridBagLayoutBuilder verified to provide no visual changes, just refactoring (I've talked about that in some of the previous mail).

Then there are e.g. editbox -> spinner change. The controls creation could be factored out (to be pluggable) as well, I thought it would be over-abstracted, but can be IMHO done, if required. OR the (let's discuss in a separate thread) label+combo values shortening.

To achieve the 'old' behaviour I would suggest rather to invent "compatibility" mode rather than retrofit the XMLs, if possible.

It's a pity that decoder XML schema does not seem to have an element that describes the target JMRI release. There's schemaLocation URL (not namespace URI !), but the schemaLocation URL is not an identifier/identity in XML world, should not be misused for that purpose.

2) _All_ existing decoder & programmer definitions validate and display all the content reasonably, but not laid out as before
1) A manageable (which is an operational question) number have validation issues, which we correct, and they all display all the content reasonably, but not laid out as before
I planned for a test that ensures that all content (that is: control for the VariableItem displayed in the JMRI release (a snapshot of 'golden' test data from the current release).
This kind of test would become even more important if some additional ideas (communicated privately so far) would be prototyped.

This could ensure that data is visible, but (naturally) not the are "pretty".

0) A manageable (which is an operational question) number have validation issues, which we correct; they all display, but some are Really Ugly and we don’t have the time it would take to fix them right.
I thought that these will be treated as bugs, and I should adapt them to be 'as pretty as possible', contacting the most recent author(s) for a review.

-Svata

Svata Dedic
 

Dne 16. 10. 19 v 0:49 Dave Heap napsal(a):
1/ discard ipadx, use insets.
[...]
The design philosophy when I created <grid> in JMRI was to allow use of */_all_/*////GridBagLayout features supported by Swing. Discarding (making unavailable) a previously-available feature because you don't
I considered the use of GridBag with particular constraints, to implement <row>, <column> or <group> instructions an implementation detail as the XML gives "abstract" directions. I didn't change <grid> processing at all (except possible bug, see at the end).

We have to remain aware of the fact that other custom definition developers may have used techniques to overcome the existing shortcomings and your changes could break existing things.
Sadly there's no real way out of it. Individual changes can be analyzed and sorted to "desirable" and "experimental", the later can end up in some opt-in plugin, for example.

The drawback is two code lines to maintain, new features (like Randall's validation) working only in the new one - so a "transition plan" is needed so that does not last forever.

Personally, I find your modified Basic and Lights panes harder to read than the old versions.
Yes, this is why UI is hard. Everyone uses has a way of using it, and everyone feels that way is the best. I don't have an UX certificate, so I simply use other's knowledge as much as I can.

I can offer basically three arguments:
1/ Microsoft guideline. https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-layout, see "Label alignment section".

I've concluded that
* "scan vertically to find a specific label"
* "labels vary significantly in length"
* "There are many controls"

are more important than
* Users are likely to read in a left-to-right, top-to-bottom manner
* There are many columns

So from the relevant options, I've decided that the prevailing operation in DecoderPro is scanning to find the appropriate setting(s). The general two - column layout suggests it as well.

2/ Java Look and Feel Guidelines. Simple, unconditional ("Labels that identify controls", "Label Alignment and Spacing".

3/ not a good argument, but count some years of my NetBeans IDE development in. We were always asked to left-justify; but life was quite simple: we had UX engineers (before Apache) to decide. I don't pretend I fully understood the explanation at all times.

Actually I looked at some other GUIs - for example tabs in Windows control panels align labels left. LibreOffice is not consistent (does both, even in the same dialog - different tabs).

The bottom line is that the left/right label alignment is not important. If not agreed on a change "left", I'll change the code to use UIDefaults as usual (defaulting right); and will let my distribution to override these. In any rate, the placement should be _uniform_.

5/ Labels anchored baseline-leading (that is baseline of the 1st line of a multiline control)
Again, we have to remain aware of the fact that other definition developers may have used techniques to overcome the existing shortcomings and your changes could break things.
Yes, need to test. See also JLF Guidelines "Label Alignment and Spacing".

The reason was that the label does not communicate the *height* of the multiline (i.e. radio button group) well anyway - even if centered; if the control group extent should be emphasized, it should be done other way.
So I've sticked to the standard, having the label to mark the _start_ of its control, which it can do clearly.

I'm not sure what you mean by "punctuation"? Do you simply mean adding a ":" in the definition  to the end of some labels (as in your sample) or that the ":" punctuation will be added to all labels by default?
Currently, ':' is added automatically to labels (in variable display only) placed left to a control.

Yes, this has to be tested, as "one size does not fit all". Suggestions are welcome in this; this (minor) tweak originated from the fact that there are labels with ':' and many without - yet they're presented in the same layout style -> inconsistency.

By "accelerators" I'm guessing you mean the underlined shortcut keys to gain focus on a field?
Yes; this requires a change in decoder's XML processing (not the schema); as the standard "&" hint does not work well with XML, I've grepped decoder XMLs and selected '_', which seem to not appear at all in labels.

Related question: We explicitly support embedded HTML in pane text, and I'm assuming that embedded HTML is also supported in our labels:
https://docs.oracle.com/javase/tutorial/uiswing/components/html.html
We don't want to break that.
Good point. For mnemonics, I've used a relevant code from NetBeans IDE that contains some JDK bug compensation already.

I'm quite in favour of spinners */_provided_/* we allow text-field editing of the value (JSpinner.NumberEditor).
Done, in "JFormattedTextField.COMMIT" mode; consistent with my previous e-mails, I'd like to have validation in place + leave incorrect input (marked) for the user to correct.

8/ Shortened narrative items in combos (see Lights pane). Will implement per-item balooon / tooltip longer explanation. Backwards-compatible schema change.
Not sure how you plan to decide on when and how far to shorten? Assume some extra attribute(s) to maintain compatibility.
Some can be abbreviated. E.g. usual FO instead of Function Output. Or if *all* the items are starting with "Function Output" (perhaps with "off") item AND the variable's label itself suggests it handles outputs - then the can be abbreviated to just a number.

In other cases, I'd like to provide compatible extension - turn <choice> content model to 'mixed'. Prose text should not be in an attribute - in element body, one can use <![CDATA[]]> to wrap xml-unfriendly content and avoid various replacements.

I would however separate that from the base layout changes - to another offspring branch. It's rather a separate feature.

I assume you mean STATE colour?
Yes. Implemented that for JSpinner last night.

Make sure any merges to tooltips uses "jmri.util.StringUtil.concatTextHtmlAware" in case existing and/or added text uses embedded HTML.
Thanks for the hint! Already noticed that when going through JRMI code.

BTW - I'd recommend to somewhat 'steal' NetBeans HtmlLabelUI, which contains tweaks for different L&Fs; it's used primarily for CellRenderer, but could work well (if adapted) for plain labels, too.

Also be aware that Preferences->Roster->Programmer->Show CV Numbers in Tooltips uses StringUtil.concatTextHtmlAware to append CV number(s) and bit allocation(s) to tooltips.
Thanks.

The original idea was to get rid of many decoder overrides, where the tooltip was changed just to give the range - this should be done centrally.

I planned to add the decoration based on getClientProperty() of the control: either opt-in or opt-out for the automated "enhancement", so CV table can disable (or others enable).

Future possible experiments:
* Support some "merged" attribute for rows/column: layouter could make
[...]
Provided it doesn't break existing...
An additional attribute, so it should not break existing anything, except "new decoders" in "old JMRI", which is hardly to be desirable anyway.

In some panels, I was tempted to use <grid>, but then I'd need to provide all the align + anchor + fill + weight, which seemed error prone (for me) and too hard for a nonprogrammer: I expect the goal of XMLized description is to avoid coding.

BTW - An extension point to actually _replace_ the entire panel with custom code would help in special cases -- and I'll be investigating this in my JMRI-based application.

I'd certainly want to see the results of applying your Java code changes to untouched existing custom panes I wrote for the LokSound V4 and 5 definitions. Your changes need to pass the "don't break existing" rule.
Good point, I need complex examples to play with and test various tweaks. Either to provide better infrastructure, or to find an easy migration path.

And yes, the Sound Level panel got broken although it shouldn't (I didn't messed up with grid) - probably by the initial "no change" refactoring. Will investigate tonight.

I saw the "Sound Level" pane's grid has most of the items repeated. This seems similar to Sidlo's 'many scenarios' pattern. Is it important - for the user doing setup job - that *all* the sounds are visible at the same time ? It would be visually better to _reduce_ the area somehow, *and* emphasize the sound number.
If interested, let's start a separate thread on this item.

-Svata


BTW around 2000-2004, we did most of our UI in NetBeans using GridBags. Nowadays, virtually all UIs were already converted to GroupLayouts ...

Svata Dedic
 

Dne 16. 10. 19 v 1:19 Bob Jacobsen napsal(a):
It would be helpful if you would push a branch with this to your GitHub repo so that we can run it ourselves. Understood that it’s not final. The idea is to see how it works with various existing definitions, etc.
The 'just refactoring' branch:

https://github.com/svatoun/JMRI/tree/feature/decoderpro_layout_split

As written previously, this should just cleanup the code. Bugs in Dave's ESU Loksound fixed.

Alignment as seen on screenshots.
https://github.com/svatoun/JMRI/tree/feature/decoderpro_gridbag_spaces

Some minor changes to decoder files (more or less experiments):
- shorter wording
- hide Zimo func alt mapping when CV value does not enable it
- more even distribution of checkboxes in analog controls

They're rather minor, but it's the excess and repeated wording which makes the UI so bloated.

-S.

Dave Heap
 

Svata,

On 17 Oct 2019, at 8:06 AM, Svata Dedic <svatopluk.dedic@...> wrote:

The 'just refactoring' branch:

https://github.com/svatoun/JMRI/tree/feature/decoderpro_layout_split

As written previously, this should just cleanup the code. Bugs in Dave's ESU Loksound fixed.

Alignment as seen on screenshots.
https://github.com/svatoun/JMRI/tree/feature/decoderpro_gridbag_spaces

Some minor changes to decoder files (more or less experiments):
- shorter wording
- hide Zimo func alt mapping when CV value does not enable it
- more even distribution of checkboxes in analog controls
Thanks for posting those branches. It'll be at least 24 hours from now (possibly more) before I'll have access to a computer to checkout and view those branches.

Dave

Dave Heap
 

Svata,

On 17 Oct 2019, at 3:37 PM, Dave Heap <dgheap@...> wrote:

Thanks for posting those branches. It'll be at least 24 hours from now (possibly more) before I'll have access to a computer to checkout and view those branches.
Went to checkout your branches but was waylaid by a problem with my master branch. Suspect it will affect my checkout of your branches as well.

Will have to leave until tomorrow...

Dave in Australia

Dave Heap
 

Svata,

I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.
2) The special (replacement) Speed Table pane is not rendering correctly.

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.

Dave

On 17 Oct 2019, at 8:06 AM, Svata Dedic <svatopluk.dedic@...> wrote:

The 'just refactoring' branch:

https://github.com/svatoun/JMRI/tree/feature/decoderpro_layout_split

As written previously, this should just cleanup the code. Bugs in Dave's ESU Loksound fixed.

Alignment as seen on screenshots.
https://github.com/svatoun/JMRI/tree/feature/decoderpro_gridbag_spaces

Some minor changes to decoder files (more or less experiments):
- shorter wording
- hide Zimo func alt mapping when CV value does not enable it
- more even distribution of checkboxes in analog controls

They're rather minor, but it's the excess and repeated wording which makes the UI so bloated.

Svata Dedic
 

Dne 20. 10. 19 v 12:24 Dave Heap napsal(a):
I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.
Yes, definitely needs more testing.

I've pushed the code because of Bob's request - my intent was to make more obvious the general direction/idea. Since it is a *refactoring* (rather: rewrite), bugs are naturally expected.

The about 4th question (there are more important ones to get answer first!) is:
"is there anyone willing to help testing ?"
maybe yes, maybe not, maybe on jmri-users mailing list. But I don't want to waste their time before the more important questions have answers.

2) The special (replacement) Speed Table pane is not rendering correctly.
Thanks.
I compared "Speed table"s .. and (obviously) found some bug: In my case bottom controls (<griditems> enclosed in <grid>) were skipped by refactored code. Is that the same bug you hit ?

I put the fixes into the branch.

Considering the round-trip time, would you please provide like one-sentence description next time, so I my fixes are better targetted ?

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.
Acknowledged. Will elaborate in a separate e-mail; in the meantime, could you please pinpoint - in your opinion - an example + explain (since some preferences may not be obvious / shared) ?

-Svata

Dave Heap
 

Svata,

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

Dne 20. 10. 19 v 12:24 Dave Heap napsal(a):
I've managed to make some time to have a quick test of your branches, looking only at the ESU series decoders, and found two very obvious problems:
1) The special ESU Function Map is missing.

Yes, definitely needs more testing.

I've pushed the code because of Bob's request - my intent was to make more obvious the general direction/idea. Since it is a *refactoring* (rather: rewrite), bugs are naturally expected.

The about 4th question (there are more important ones to get answer first!) is:
   "is there anyone willing to help testing ?"
maybe yes, maybe not, maybe on jmri-users mailing list. But I don't want to waste their time before the more important questions have answers.

I've been keeping a close eye on this (and have already put a lot of time into it, more than I should have, given other commitments) but don't want to be responsible for all testing.

But it's not just a case of testing, it's also a case of whether others agree with your idea of what is more readable. I'm not at all convinced about some aspects of your proposal.

But please see below...


2) The special (replacement) Speed Table pane is not rendering correctly.
Thanks.

I compared "Speed table"s .. and (obviously) found some bug: In my case bottom controls (<griditems> enclosed in <grid>) were skipped by refactored code. Is that the same bug you hit ?

Yes, I suspect it's due to incorrect rendering of <griditems> enclosed in a <group> within the <grid>.

I put the fixes into the branch.

Thanks. Will pull them later.


Considering the round-trip time, would you please provide like one-sentence description next time, so I my fixes are better targetted ?

As a personal opinion, on an onscreen side-by-side comparison of current master and your decoderpro_gridbag_spaces branch, I'm afraid I find the readability of the majority of your panes much lower.


Acknowledged. Will elaborate in a separate e-mail; in the meantime, could you please pinpoint - in your opinion - an example + explain (since some preferences may not be obvious / shared) ?

With the caveat below, here is a link to some "before and after" side-by-side screenshots, for general perusal:


However, I believe the goalposts have shifted. Your original proposal was for "DecoderPro panel cleanup", to which Bob responded very positively.

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

I'd like to refactor the way how PaneProgPane is built up. No UI change intended in this phase, but rather code can be cleaned up.

That was the proposal. Note the "No UI change intended in this phase". We were all keen about that.

Why doing this: in a later phase, I'd like to make _visual_ changes (see below). Any change, or bugfix will be more consistent, if done on 'canonical' code and easier to review.

Note the "in a later phase".

The two phases seem to have morphed into one and that was not my understanding of your original proposal.

Dave


Svata Dedic
 

Dne 21. 10. 19 v 12:58 Dave Heap napsal(a):
time into it, more than I should have, given other commitments) but don't want to be responsible for all testing.
Definitely not; given the number of decoders. Again: how to test is "only" about 4th in the queue.

Dne 21. 10. 19 v 12:58 Dave Heap napsal(a):
But it's not just a case of testing, it's also a case of whether others agree with your idea of what is more readable. I'm not at all convinced about some aspects of your proposal.
Correct; I don't know if there's a decision "procedure" in place, like in Apache projects; should be used if so.

NOTE: there are actually TWO questions:
1/ Does the community SUPPORT such *general direction* - "UI facelift" ?
2/ Is the the *current* state acceptable for merge ?

(1) is why I published the refactoring AND the changed layout in a branch. I suppose the answer to (2) is "no" at this moment: You can be sure there is definitely quite a few (visual) bugs still left.
For example, https://www.dropbox.com/sh/54vm9n5uysnemda/AACHkYMaRg5ppB9kgvMtm6eOa?dl=0&preview=Screen+Shot+2019-10-21+at+6.30.43+pm.png indicates, that the "big columns" of controls should have more distance between them. I don't know if that counts toward 'less readability' for you (no such item was in your messages); it does for me. Others may have different preferences.

Again: If the feedback is vague "I don't like it, you sure see it yourself" (rephrased), rather than explicit, issues can't be collected, evaluated, addressed ... and as a result there's won't be a metric or a way to set up a target to reach.

So; the most important answer is (1). I'd like this confirmed by the community, whatever the process is. My goal is to have an usable tool; it could be quite wasteful to invest into improving JMRI core instead of my own code without such "green light".

After that, we may talk about some regular "checkpoints", so you won't be saturated reviewing small changes separately, and objectives to be met.

One correction, though:
I'm not at all convinced about *some aspects of your proposal*
I am not the inventor of *any* of the proposed changes. I follow the guides and examples: cross-platform style (JLF + adjustments for L&Fs) AND Microsoft (80% desktop share). I do believe that true UI design requires a different set of skills than I have.
These guides are also by no means perfect. BUT they bring consistency between apps, allow users to reuse habits they already built up.

Over time I've relized, that that every time I say "I will do things differently than UX", it indirectly says
"I am MORE clever than UX teams at Microsoft, Apple, SUN and Oracle".
Quite ridiculous if put that way, isn't it ? xThat rings the bell to find and clearly articulate WHAT is the special property, that validates the divergence. Sometimes, others must ring the bell for me. I usually fail the test, so - redesign and try again. "I like it" is not a valid reason in this game - it leads to "programmer's UI", which tends to be "non-user friendly".

-Svata

Dave Heap
 

Svata,

On 23 Oct 2019, at 9:44 AM, Svata Dedic <garat@...> wrote:

For example, https://www.dropbox.com/sh/54vm9n5uysnemda/AACHkYMaRg5ppB9kgvMtm6eOa?dl=0&preview=Screen+Shot+2019-10-21+at+6.30.43+pm.png indicates, that the "big columns" of controls should have more distance between them. I don't know if that counts toward 'less readability' for you (no such item was in your messages); it does for me. Others may have different preferences.
I do agree with you about the "big columns" spacing being insufficient on the right-hand side.

However, my personal view is that readability has also been lost for two more reasons:
- The section headings are now no longer distinct from the item labels, making them harder to find.
- The inevitability different-length labels have made a lot of white space the eye has to traverse to find the associated text entry box, increasing the probability of error.

I asked my wife (a non Programmer-JMRI user but with quite a bit of document layout experience) to view all these side-by-sides and comment on the relative merits. Her personal response to this particular image was:
- The left-hand pane has insufficient space, particularly between label and text box (too crowded).
- The right-hand pane has better spacing but has lost a lot of readability. The labels need to be right-aligned and the headings need to be left-aligned.

So that's two opinions from down-under. But maybe that's because we look at things other-side-up!

Maybe no one agrees with us?

Dave in Australia

danielb987
 

I agree with:

- The right-hand pane has better spacing but has lost a lot of
readability. The labels need to be right-aligned and the headings need
to be left-aligned.
Daniel

2019-10-23 06:31 skrev Dave Heap:
Svata,

On 23 Oct 2019, at 9:44 AM, Svata Dedic <garat@...> wrote:
For example, https://www.dropbox.com/sh/54vm9n5uysnemda/AACHkYMaRg5ppB9kgvMtm6eOa?dl=0&preview=Screen+Shot+2019-10-21+at+6.30.43+pm.png indicates, that the "big columns" of controls should have more distance between them. I don't know if that counts toward 'less readability' for you (no such item was in your messages); it does for me. Others may have different preferences.
I do agree with you about the "big columns" spacing being insufficient
on the right-hand side.
However, my personal view is that readability has also been lost for
two more reasons:
- The section headings are now no longer distinct from the item
labels, making them harder to find.
- The inevitability different-length labels have made a lot of white
space the eye has to traverse to find the associated text entry box,
increasing the probability of error.
I asked my wife (a non Programmer-JMRI user but with quite a bit of
document layout experience) to view all these side-by-sides and
comment on the relative merits. Her personal response to this
particular image was:
- The left-hand pane has insufficient space, particularly between
label and text box (too crowded).
- The right-hand pane has better spacing but has lost a lot of
readability. The labels need to be right-aligned and the headings need
to be left-aligned.
So that's two opinions from down-under. But maybe that's because we
look at things other-side-up!
Maybe no one agrees with us?
Dave in Australia

Svata Dedic
 

Dne 23. 10. 19 v 7:06 danielb987 napsal(a):
- The right-hand pane has better spacing but has lost a lot of
readability. The labels need to be right-aligned and the headings need
to be left-aligned.
I don't want to battle over marginal things like label alignment; if that is such a centerpiece, let's have them right-aligned.

Additional things to note

1/ the huge gap is mainly because "Preserve Driving Direction when Changing from Analog to Digital". This label alone has several issues no matter what the alignment is:
- repeats part of its section heading
- labels should not be sentences
- long labels are recommended above, not next to a control

The next long control, "Power Pack Maintain Time", also duplicates its section heading; the number-slider control is actually something that IMHO needs some separate thought: unlike other controls (on right), this is on left. Other panels have number-slider control below (Sound, Sound Levels), or also on right (Function Outputs, Speed Control). This is more visible in the "Constant Brake Distance" section.

BTW since the number-slider pair is quite used throughout UI, I think it could deserve a 'format of its own, so one does not need to hack it with label-less display in XML.

Similar issues can be seen throughout the dialog. Should they be cleared, the entire dialog would become less complex (and less gaps between label and control, or label and margin).

2/ "static labels" on left vs. "control labels" on right is a misuse of the layout, in a sense. Should the label be marked as "heading", even left-aligned labels could be indented. Headings could be visually different: size, or bold font. Or, in case of a long section, collapsible.
Not saying that everything that should be done, but marking "heading label" a heading makes enables those steps for the future.
Could be useful in other decoders, too to reduce text duplication.

I'll try to address these: long labels, long combos, section/grouping support, number-slider control.

If time permits, please continue with such feedback, comments to the proposed changes are welcome.

To save time, I'd suggest *visual* preview checkpoint approx 2-3 weeks from now. Sounds reasonable ?


So that's two opinions from down-under. But maybe that's because we
look at things other-side-up!
Nice :) but then you (or I) should be rather north/south mirrored, not east/west, right ?

-Svata

Dave Heap
 

Svata,

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

Additional things to note

1/ the huge gap is mainly because "Preserve Driving Direction when Changing from Analog to Digital". This label alone has several issues no matter what the alignment is:
- repeats part of its section heading
- labels should not be sentences
- long labels are recommended above, not next to a control
As the creator of the ESU definitions, I deliberately used the same Variable Names and Section Headings as used in the ESU documentation and ESU's own LokProgrammer software. Such consistency assists users of the these decoders and those providing technical support for them.

The next long control, "Power Pack Maintain Time", also duplicates its section heading; the number-slider control is actually something that IMHO needs some separate thought: unlike other controls (on right), this is on left. Other panels have number-slider control below (Sound, Sound Levels), or also on right (Function Outputs, Speed Control). This is more visible in the "Constant Brake Distance" section.
As above.


BTW since the number-slider pair is quite used throughout UI, I think it could deserve a 'format of its own, so one does not need to hack it with label-less display in XML.
That's a possibility, but for future implementation.


Similar issues can be seen throughout the dialog. Should they be cleared, the entire dialog would become less complex (and less gaps between label and control, or label and margin).
These are your personal views, not necessarily shared by others.


2/ "static labels" on left vs. "control labels" on right is a misuse of the layout, in a sense.
These are your personal views, not necessarily shared by others.

Should the label be marked as "heading", even left-aligned labels could be indented. Headings could be visually different: size, or bold font.
I think that's a positive proposal. But it does overlap slightly with the existing Java support for embedded HTML in text fields.

Or, in case of a long section, collapsible.
I'm somewhat dubious about the merits of that. Many of our users are of advancing age, not savvy with the latest UI fashions (many of which are biased against those of advancing age and failing eyesight) and wouldn't recognise the latest clues of a collapsed section. It could significantly increase our support load.

Not saying that everything that should be done, but marking "heading label" a heading makes enables those steps for the future.
Could be useful in other decoders, too to reduce text duplication.

I'll try to address these: long labels, long combos, section/grouping support, number-slider control.
In my view, this has moved far from the original (welcomed) proposal of a code cleanup of PaneProgPane to "I don't like the way others have done definitions because they visually offend me/UI specification xxxx so I'm going to start proposing changes to existing definitions for stylistic reasons, with little or no knowledge of the product, its users, documentation or the work of those who provide technical support for it".

JMRI is a volunteer and cooperative effort and we generally welcome new feature proposals, code, bug fixes, new definitions etc. There are plenty of outstanding Feature Requests, Bug Fixes in <https://github.com/JMRI/JMRI/issues> (as well as code refactoring, better tests for existing classes, etc.) for those keen to assist.

In my part of the world we have a saying "If it ain't broke, don't try to fix it."

We also have a much less pedantic view of the definition of "broke".

Dave in Australia

Svata Dedic
 

Dne 23. 10. 19 v 19:58 Dave Heap napsal(a):
As the creator of the ESU definitions, I deliberately used the same Variable Names and Section Headings as used in the ESU documentation and ESU's own LokProgrammer software. Such consistency assists users of the these decoders and those providing technical support for them.
OK, so what I interpreted as a bug is for the purpose of consistency; good.

BTW - what I offered to prototype are things that usualy works in my daily tasks. I do support for technologies, not devices; the concept of having a verbatim term on screen is sort of novel to me.

Pity that you took offense; not meant that way. Please consider to accept my apology.

2/ "static labels" on left vs. "control labels" on right is a misuse of the layout, in a sense.
These are your personal views, not necessarily shared by others.
Probably yes; unless voiced, one never knows if correct or not.
Sorry for the bad wording. I meant that it conceals layout semantics which is otherwise well split between Programmer and Decoder parts.

I think that's a positive proposal. But it does overlap slightly with the existing Java support for embedded HTML in text fields.
Those concepts could eventually combine. Any automatic text decoration can be disabled in presence of HTML (richer) content.

I'm somewhat dubious about the merits of that. [...] not savvy with the latest UI fashions [...] It could significantly increase our support load.
OK. Note that the "collapsible" stuff was rather an example of possibility.

In my view, this has moved far from the original (welcomed) proposal of a code cleanup of PaneProgPane to "I don't like the way others have done definitions because they visually offend me/UI specification xxxx so I'm going to start proposing changes to existing definitions for stylistic reasons, with little or no knowledge of the product, its users, documentation or the work of those who provide technical support for it".
I don't feel offended. Rather surprised that "patterns" routinely applied in the SW corporates and touted as 'universal' are not applicable. It takes some time and failed attempts to discover what is seen appropriate.

Otherwise, fair enough; naive or hasty approach sometimes deserve a sharp correction. Interpreted in plain words, no UI changes in this style welcome. Good.

An afterthough: there was possibly another misunderstanding - I "picked up" your decoders as testing data since my experiment broke (even the refactoring) them AND they excercise many features of the layout code.
I guess I didn't (in addition) separate clearly in MY head the original idea (simplify ZIMO I personally use, if possible) and "marketed" the idea as univesal one. Again - sorry.

JMRI is a volunteer and cooperative effort and we generally welcome new feature proposals, code, bug fixes, new definitions etc. There are plenty of outstanding Feature Requests, Bug Fixes in <https://github.com/JMRI/JMRI/issues> (as well as code refactoring, better tests for existing classes, etc.) for those keen to assist.
Interesting.

In my part of the world we have a saying "If it ain't broke, don't try to fix it."
We have the same saying.

Does copy-paste of blocks of code, events looping (but converging!) between objects back and forth count as aesthetical detail, or as https://en.wikipedia.org/wiki/Technical_debt in this developer community ?

-Svata

Michael Mosher
 

I don't care for the new layout as shown on the right side of the pic linked below, too much space between the label and the check box for those variables that use check boxes.

I looked a several Windows programs and one Linux program and they all have check boxes and radio buttons to the left of the label and the label text is left justified.  Handling of text boxes, drop down lists, and sliders is more varied, but applying same format to them, I think looks good.

See:
https://www.dropbox.com/s/o86zzee1a9tp2w6/mod.png?dl=0
Note this is just editing the image in a paint program by dragging things around, alignment by eye so not perfectly aligned.
I did not remove the ":" at the end of the labels, but I think they are not needed.


Michael Mosher
Member SFRH&MS http://www.atsfrr.net/
DCC Master PVSMR http://www.patcongvalley.com/