Topics

Proposed: Sitcky column customization in tables

Svata Dedic
 

Hi,

I'd like to discuss something first before turning the idea to a pull request, since it is not a clearly bug, and changes UI behaviour - I hope for the better.
When the user wants to customize columns in a table, currently the user has to:
- invoke popup menu
- hide an unwanted column
- invoke popup menu
- show desired column
- repeat the above untill satisfied

For each change a popup trigger has to be pressed; the popup disappears after checkbox click.

The proposal is simple: let the column selection menu to stay on the screen, so the user can click in/out as many columns as needed. The popup menu can be then closed by clicking outside the area or ESC as usual.

Thanks for feedback,
-Svata

whmvd
 

Hi Svata,

Do people use this much other than to set it up once and then forget about it? If not, then it seems to me that it's quite a bit of effort to little avail. But if my guessing's wrong, or someone's willing to spend the time on it anyway, then I'd much prefer it the way you describe. It would be a good moment to think about adding some sort functionality there as well (as sorting is impacted anyway if a column that's being used for sorting is hidden).

So one row of the column table (yeah, really, that is what I mean...) would have the following, erm, columns:
1) checkmark (show this column)
2) column name
3) radio button (primary sort up)
4) radio button (primary sort down)
All radio buttons in one group (not just on one line, but all of them)

Optionally 3a: numeric input for column width.

Also optionally 5) and 6) for more sorting options as secondary sort would be nice. Primary and secondary would be separate radio button groups. If the underlying data structures permit secondary sorts, which I don't know by heart.

By 'optionally' I mean optionally to be designed in, not optionally displayed by some criterion or other - simply always there if the designer chooses to have them implemented.

But again: I can't judge if it's worth the effort.

Wouter


On Mon, 23 Sep 2019 at 10:22, Svata Dedic <garat@...> wrote:
Hi,

I'd like to discuss something first before turning the idea to a pull
request, since it is not a clearly bug, and changes UI behaviour - I
hope for the better.
When the user wants to customize columns in a table, currently the user
has to:
- invoke popup menu
- hide an unwanted column
- invoke popup menu
- show desired column
- repeat the above untill satisfied

For each change a popup trigger has to be pressed; the popup disappears
after checkbox click.

The proposal is simple: let the column selection menu to stay on the
screen, so the user can click in/out as many columns as needed. The
popup menu can be then closed by clicking outside the area or ESC as usual.

Thanks for feedback,
-Svata




Randall Wood <rhwood@...>
 

Can you provide examples of common applications that do this?

I don’t have a Windows system handy right now, but the file system explorers for Linux/GNOME and MacOS display table column selection menus the way JMRI does.

I think those applications behave that way because the *normal* menu behavior is that the menu closes after clicking an item in the menu. Since that is the normal behavior, we may want to avoid adding a non-normal behavior for table column visibility, and we really want to avoid it unless you can actively ensure *all* table column visibility menus behave the same way—there is, from a design perspective, little worse than internal inconsistency in an application’s user interface (i.e. all menus that look just like menus should behave the same).

That said, technically doing what you want is easy by using the “tear off” menu functionality. Note that this only works on some operating systems, so its not 100%. I does, however, have some advantages over any other method for keeping a menu open I can Google:
- It embeds the menu in a window with an explicit close/dismiss button (we do not rely on users clicking off the menu but in the application to dismiss)
- It is clearly visually distinct from other menu types (see first item), so users will not be surprised when it does not act like other menus
- It’s optional — users who want to tear off the menu can, otherwise it behaves like a normal menu

Randall

On Sep 22, 2019, at 07:09, Svata Dedic <garat@...> wrote:

Hi,

I'd like to discuss something first before turning the idea to a pull request, since it is not a clearly bug, and changes UI behaviour - I hope for the better.
When the user wants to customize columns in a table, currently the user has to:
- invoke popup menu
- hide an unwanted column
- invoke popup menu
- show desired column
- repeat the above untill satisfied

For each change a popup trigger has to be pressed; the popup disappears after checkbox click.

The proposal is simple: let the column selection menu to stay on the screen, so the user can click in/out as many columns as needed. The popup menu can be then closed by clicking outside the area or ESC as usual.

Thanks for feedback,
-Svata



Randall Wood <rhwood@...>
 

Windows Explorer in Windows 10 has an interesting solution to the problem of maintaining the normal menu behavior while allowing the originally desired alternate: the last menu item in the columns menu is “More...”, which brings up a window that includes both column visibility controls and column order controls.

Randall

On Sep 23, 2019, at 06:16, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

Can you provide examples of common applications that do this?

I don’t have a Windows system handy right now, but the file system explorers for Linux/GNOME and MacOS display table column selection menus the way JMRI does.

I think those applications behave that way because the *normal* menu behavior is that the menu closes after clicking an item in the menu. Since that is the normal behavior, we may want to avoid adding a non-normal behavior for table column visibility, and we really want to avoid it unless you can actively ensure *all* table column visibility menus behave the same way—there is, from a design perspective, little worse than internal inconsistency in an application’s user interface (i.e. all menus that look just like menus should behave the same).

That said, technically doing what you want is easy by using the “tear off” menu functionality. Note that this only works on some operating systems, so its not 100%. I does, however, have some advantages over any other method for keeping a menu open I can Google:
- It embeds the menu in a window with an explicit close/dismiss button (we do not rely on users clicking off the menu but in the application to dismiss)
- It is clearly visually distinct from other menu types (see first item), so users will not be surprised when it does not act like other menus
- It’s optional — users who want to tear off the menu can, otherwise it behaves like a normal menu

Randall

On Sep 22, 2019, at 07:09, Svata Dedic <garat@...> wrote:

Hi,

I'd like to discuss something first before turning the idea to a pull request, since it is not a clearly bug, and changes UI behaviour - I hope for the better.
When the user wants to customize columns in a table, currently the user has to:
- invoke popup menu
- hide an unwanted column
- invoke popup menu
- show desired column
- repeat the above untill satisfied

For each change a popup trigger has to be pressed; the popup disappears after checkbox click.

The proposal is simple: let the column selection menu to stay on the screen, so the user can click in/out as many columns as needed. The popup menu can be then closed by clicking outside the area or ESC as usual.

Thanks for feedback,
-Svata





Svata Dedic
 

Wouter, Randall,

Dne 23. 09. 19 v 12:16 Randall Wood via Groups.Io napsal(a):
Can you provide examples of common applications that do this?
Actually, I don't think so.
Either rather sophisticated customizer (for bulk layout changes), that Wouter has outlined in his message. File managers, spreadsheets etc use the current approach as restructuring standard views is only exceptional or a one-time setup.

I encountered the scenario on a narrow display trying to get an overview of turnouts that I needed *at the moment* - needed to remove/add more columns to get a proper view for the task. I can surely live with the current behaviour, but found it a little awkward and easy to change.

Implementation-wise, the change is rather simple: https://github.com/JMRI/JMRI/compare/master...svatoun:feature/persistent_tableheader_menu
+ of course propagating to other table headers, as you noted.
Should be however portable and retain menu L&F.

You nailed it down: - the real decision is 'standard behaviour' versus 'smoother workflow' - and that's why I asked on the mailing list; PR queue should be left for technical code reviews, if agreed on functionality (IMHO).

The change will incur one extra click (or keypress) in the one-column change process; could be (didn't try, idea came only now) refined to require (for example) SHIFT click, so that one-column scenario is not affected at all.

Speaking of desktop consistency - JMRI already breaks many common (and Swing) UI and consistency rules that there is definitely. So I definitely don't want add another one if not seen beneficial in terms of functionality.

-Svata

Svata Dedic
 

Hi, again

sorry; mouse copy-paste typo occured. Apologies for duplication. The last paragraph should read:
---
Speaking of desktop consistency - JMRI already breaks many common (and Swing) UI and consistency rules. So I definitely don't want add another one if not seen beneficial in terms of functionality.

---

-Svata

Svata Dedic
 

Hello,

Reposting last item in a discussion that was not concluded in any way (shortening to relevant parts):

Dne 23. 09. 19 v 19:12 Svata Dedic napsal(a):
You nailed it down: - the real decision is 'standard behaviour' versus 'smoother workflow'
[...]
The change .... could be [...] refined to require (for example) SHIFT click, so that one-column scenario is not affected at all

-Svata

Randall Wood <rhwood@...>
 

Suggest following pattern in Windows Explorer, since this leaves normal behavior in place while allowing “advanced” control for those who feel the need for it.

Randall

On Oct 1, 2019, at 15:00, Svata Dedic <garat@...> wrote:

Hello,

Reposting last item in a discussion that was not concluded in any way (shortening to relevant parts):

Dne 23. 09. 19 v 19:12 Svata Dedic napsal(a):
You nailed it down: - the real decision is 'standard behaviour' versus 'smoother workflow'
[...]
The change .... could be [...] refined to require (for example) SHIFT click, so that one-column scenario is not affected at all

-Svata


Svata Dedic
 

Dne 01. 10. 19 v 22:18 Randall Wood via Groups.Io napsal(a):
Suggest following pattern in Windows Explorer, since this leaves normal behavior in place while allowing “advanced” control for those who feel the need for it.
OK. The last modification that retains normal behaviour rejected.

Since my use-case does not require sophisticated UI suggested, and because of implicit pushback to the proposed idea, I am giving up the feature.

Seems that a lot of attention is being paid to consistency and UI standards. Let me ask - what standard tabular UI was the model for JMRI tables ?
For example uses "Delete" (or other action buttons) per row, but does not any allow bulk-operations (like delete) while supports row multi-selection ?

Thank you for the input,
-Svata

Randall Wood <rhwood@...>
 

Here’s the thing about the history of JMRI and why I care about be able to use assistive technologies (i.e. not use color exclusively): 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.

JMRI has had (and may still have):
- Windows that can be moved and resized, but don’t retain that change for next time (while other windows do retain those changes).
- Windows that redefined, just for that window, the duration of a double click in a mouse (ignoring the setting in the OS).
- Windows that redefine how mice behaves (Ctrl-Click is the equivalent of the right mouse button click in macOS, but some windows in JMRI change that to something else, and some require a Ctrl-right-click to do something).

So we have had, and still have, idiosyncratic behaviors in JMRI, where single windows behave in strange ways, or controls in a single window behaves in strange ways.

That we have done that in the past does not mean we want to continue to do that, or introduce new idiosyncratic behaviors, because anything that is not normal is generally not desirable, and difficult for someone who needs special accommodation (whether visual by using larger than normal text, or using a special pointing device, or relying extensively on a keyboard).

(Incidentally that is why the suggestion was made that a custom L&F be made usable for a specific platform, because in so doing all of JMRI on that new L&F gets that behavior, not just the one window, and the other proposal, was not standard, since the standard in Windows, macOS, and Linux is that widget borders change color and size to denote focus, not to provide other information.)

Randall

On Oct 1, 2019, at 16:37, Svata Dedic <svatopluk.dedic@...> wrote:

Dne 01. 10. 19 v 22:18 Randall Wood via Groups.Io napsal(a):
Suggest following pattern in Windows Explorer, since this leaves normal behavior in place while allowing “advanced” control for those who feel the need for it.
OK. The last modification that retains normal behaviour rejected.

Since my use-case does not require sophisticated UI suggested, and because of implicit pushback to the proposed idea, I am giving up the feature.

Seems that a lot of attention is being paid to consistency and UI standards. Let me ask - what standard tabular UI was the model for JMRI tables ?
For example uses "Delete" (or other action buttons) per row, but does not any allow bulk-operations (like delete) while supports row multi-selection ?

Thank you for the input,
-Svata



Svata Dedic
 

Dne 02. 10. 19 v 1:10 Randall Wood via Groups.Io napsal(a):
(Incidentally that is why the suggestion was made that a custom L&F be made usable for a specific platform, because in so doing all of JMRI on that new L&F gets that behavior, not just the one window, and the other proposal, was not standard, since the standard in Windows, macOS, and Linux is that widget borders change color and size to denote focus, not to provide other information.)
No need to argument futher for your decisions; they have been already made and I consider those topics closed.

If I may, I'll address the other parts of the reply in a separate message (not going back to borders and column visibility).

-Svata