Tough words about GUI

[admin]

Is it just me or, when XYplorer is maximised in Win 7, the vertical scroll bar in the list is not infinite width-wise? In other words, there is a pixel or two between the scroll bar and the edge of the screen. If that is indeed the case, then XY is falling foul of Fitt's Law with respect to user interface and edges of computer display.

I have to agree. Never noticed this difference to WE. Changed in next version. Thanks!

[zer0]

prev_formats.PNG (74.65 KiB) Viewed 2192 times

Don, I noticed in the changelog -- I do read it! -- that you have redesigned Previewed Formats' GUI and of course I cannot help but have a few thoughts.

* Categories are not well-defined visually. There is no visual linkage between categories and formats that fall under them. A typical way would be to have them horizontally tabbed, especially if you don't plan to give us freedom to add more categories. Check boxes for categories do not have a mixed state.

* Categories are not well-defined functionally. Un-checking a box for a category does not clear check boxes for all formats that are in that category, although that is the effect. Not having a visual confirmation is bad UX design.

* Add/Remove buttons are positioned awkwardly. Why are they down there and to the left? It is expected for such buttons to the aligned to the right as that is how most people's vision works. And XYplorer's dialogue windows' buttons are typically placed against the right edge, so why part with a tradition this time?

* A large amount of visual space is between categories and Add/Remove buttons is not utilised Unless we will have freedom of more categories' granularity?

* What is the advantage of line numbers for formats? IMO, it adds a lot of bloat pixels.

[admin]

All theory, dear friend, is grey... I will wait for the first user who really does not get it.

[zer0]

All theory, dear friend, is grey... I will wait for the first user who really does not get it.

I don't get it. That's why I brought up those concerns. Currently, the arrangement of elements in that layout looks like a badly-lost game of Tetris.

[j_c_hallgren]

* Check boxes for categories do not have a mixed state.

And that is something that is quite typical in this situation, as it's not always a full on or off but a mixture.

Un-checking a box for a category does not clear check boxes for all formats that are in that category, although that is the effect.

Agree that clearing a category box should clear all sub-selections, as that seems to be most typical behavior.

* Add/Remove buttons are positioned awkwardly. Why are they down there and to the left? It is expected for such buttons to the aligned to the right as that is how most people's vision works. And XYplorer's dialogue windows' buttons are typically placed against the right edge, so why part with a tradition this time?

True! It's a bit inconsistent, I agree.

* What is the advantage of line numbers for formats? IMO, it adds a lot of bloat pixels.

It's something I have seen in a few other places but doesn't really bother me either way.

[zer0]

Another day, another addition to GUI, another moan from me...

sync_tools.PNG (53.34 KiB) Viewed 2158 times

1) Such commands need never be in a dedicated, not to mention modal, box. A sub-menu is a much more appropriate element for their display.
2) Linguistically, a lot of things don't make sense.
a) In the description, you write "All action is applied to the active pane.", but then refer to inactive pane as "the other pane". You may think that such semantics don't matter, but they do. Calling the inactive pane "the other pane" sounds amateur/casual.
b) "Select Selected" and "Select Unselected" confuse the hell out of me. Without reading their respective descriptions (a user shouldn't have to do that ), why would I want to select items already selected or specifically unselected? Please phrase them better.

I know I may be playing dumb with a couple of the above, but such concerns are not to be ignored/disregarded. Just because it makes sense to you -- and it should since you're the dev -- doesn't mean there are no wrinkles to iron out

[j_c_hallgren]

1) Such commands need never be in a dedicated, not to mention modal, box. A sub-menu is a much more appropriate element for their display.

TheQwerty talked about this in item 2 of http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=5601 and Don responded there so look at that also.

Addendum:
Regarding your second item...I also find the desc a bit confusing, as I would most likely expect to have made the desired selections in the active pane and have those applied to the inactive pane via this but based on this text, I'm not immediately sure what happens where.

And "Select Selected"? That seems rather unusual wording...not sure what's better but this is not ideal.

[zer0]

1) Such commands need never be in a dedicated, not to mention modal, box. A sub-menu is a much more appropriate element for their display.

TheQwerty talked about this in item 2 of http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=5601 and Don responded there so look at that also.

I'm still not persuaded. It's modal, with those redundant line numbers, doesn't remember its size, has confusing descriptions and -- correct me if I'm wrong -- I currently cannot call individual actions through command IDs in scripting

P.S. Sorry if I'm being overly critical, but I get a feeling that when it comes to GUI I'm the most vocal user, so I do want to make sure that concerns are raised when there are causes for them.

[admin]

The GUI is okay to me (hey, I made it to please me). Watch it grow and you might see the light.

The only point that concerns me is command #2, Select Non-Matching. It is simply the inverse of #1. I tend to drop it and add another checkbox "Invert" to the bottom. That would give also 2 more alternatives together with #3 and #4.

[zer0]

The GUI is okay to me (hey, I made it to please me). Watch it grow and you might see the light.

Herein lies a problem, I think. When I was coding for my university projects, I didn't pay much attention to GUI tendencies, because I was more concerned with functionality. However, I have since became acutely aware of the rights and wrongs of GUI design, especially when it comes to an application that I use for best part of a day. Personal agenda needs to step aside in such situation (it did for DP ).

I recall you mentioning that GUI changes are planned for sometime this year -- subject to the usuals -- and I am intrigued by that. However, most of the concerns that I brought up 9 months ago are yet to be actioned. It doesn't fill me with optimism, since we know that the longer something is allowed to stay the smaller the possibility that anything will be done about it.

[zer0]

The only point that concerns me is command #2, Select Non-Matching. It is simply the inverse of #1. I tend to drop it and add another checkbox "Invert" to the bottom. That would give also 2 more alternatives together with #3 and #4.

"Select Matching (Inverse)" does not read very well. This is because it is not until my eyes get to the 3rd word do I know the difference between that action and the one above. The distinction needs to be immediate and obvious. "Invert Matching Selection" gets the message across better (but still does not pre-empt from reading its description).

[grindax]

.

[admin]

"Select Matching (Inverse)" does not read very well.

I would have gone for "Select Non-Matching"

EDIT: Which looks like what it was previously, in an earlier build

I find the current way clearer in stating that the first two actions are just two sides of the same coin.

[grindax]

.

[admin]

I find the current way clearer in stating that the first two actions are just two sides of the same coin.

Makes sense. Reading a previous post in this thread, I actually like your earlier idea about just putting an "Invert" checkbox at the bottom. Seems like that would be much neater.

In the meantime I changed my mind about it, because I *assume* that both commands are quite useful so it's just less trouble for the user to have a quick one-click choice without having to care about the state of a checkbox. And it's less likely (I *assume*) that the other two commands need an inverted version (and you can always do "Invert Selection" when you need it).

But the last word will be spoken based on the accumulated experience of users actually working with these commands... swarm intelligence rules (at least when it matches what I think is best ).

FYI, the new scripting command sync (coming soon) will have invert (or inverse?, not sure) as an argument.