Tough words about GUI

[admin]

All menu items that open another window have an ellipsis.

Erm, dare I ask why? User interface guidelines -- such as http://msdn.microsoft.com/en-us/library/aa974176.aspx -- say that ellipses are to be shown "only when additional information is required" and "Don't use an ellipsis whenever an action displays another window".

Interesting. For me as a user the dots always meant: nothing serious will happen when I click this, it's just an intermediate step. And when I look around in my softwares, I find many counter examples where dots are used or not used against those interface guidelines. So this is a chaotic area. Has MS the authority to make the rules? I doubt it. But I'm open to remove the dots. I'm always pro removal.

[PeterH]

Sorry - I'm no specialist here.

But I also understood it that way, that ellipsis say that a screen requiring more input will follow. Like "Open...", where you will be asked what to open.

"Environment Variables" or "Various Information" will just show some output - and so should need no ellipsis.

Hope I'm right with this?

[zer0]

Interesting. For me as a user the dots always meant: nothing serious will happen when I click this, it's just an intermediate step.

Sure, I understand where you are coming from. However, on many an occasion in XYplorer, it's not an intermediate step, but a final one. One that notifies a user of certain information, rather than prompting for entry of data. That's a key difference -- if there is no prompt, there should not be an ellipsis in a caption.

And when I look around in my softwares, I find many counter examples where dots are used or not used against those interface guidelines. So this is a chaotic area. Has MS the authority to make the rules? I doubt it. But I'm open to remove the dots. I'm always pro removal.

Granted, it is a chaotic area. Thus, it is surely the purpose of these guidelines to attempt to introduce some form of consistency into this chaotic world. I think that if an application isn't developed with those guidelines in mind, it's because either a developer is not aware of them or does not think that they are relevant to an application's userbase. So another application gets added to this chaos and users are none the better.

Has MS the authority to make the rules? I doubt it. But I'm open to remove the dots. I'm always pro removal.

Not rules, but guidelines. And who better to produce those guidelines than maker of operating systems on which guidelines-compliant software would run? Microsoft's voice is loud enough to be heard.

Thanks for being open to remove redundant dots. I posted a list earlier in this thread -- http://www.xyplorer.com/xyfc/viewtopic. ... 689#p40689 -- it would be a good start

[admin]

2. Agreed, but did not find a way yet; working on it.

Thanks!

Failed.

[zer0]

I'm always pro removal.

As you are pro removal, could you please remove the pre-setup message about purchasing a license? At least from the beta versions as betas are largely intended for people who already have a license and, until recently, betas were only available from our License Lounges. I appreciate it's only one extra click, but as someone who is a Lifetime Pro licensee and keeps up-to-date with betas, those clicks are certainly adding up

Thanks for considering!

[zer0]

Agreed!

I would skip the [tickbox with "Enable" caption, ticked by default] though, and allow to add several extensions at once as a comma-separated list. The user-added extensions in the list should be printed in a special color (marked color #2). And there should be a way to remove a user-added extension from the list (disabling would be effectively the same, but user will ask for removing).

Planned for 9.20.

OK, so the new "Previewed Formats" interface is here and it's much better than the previous iteration -- so thanks!

However, I suspect that is still rough around the edges, so here a few bits of initial feedback:

1. Horizontal scrolling is a bad idea. A much better way would be to have extensions wrap onto a new row once they reach the edge of the pane. Granted, this may result in vertical scrolling, but vertical scrolling is more user-friendly.

2. Redundant white space. The scrollable list with extensions has a lot of white space to its right that is not utilised. There are not that many file formats that come with such a long type description -- and such descriptions are editable, so could be shorter at a user's whim.

3. "Remove" doesn't apply to factory-included formats. This is not immediately clear from the changelog. Only that user-added extensions can be removed. If most factory-default extensions do not apply to a user, they still have to scroll through lengthy lists to enable/disable their added extensions.

4. There is no "Miscellaneous" category. There are extensions that do not fit into any of the categories and should not be shoehorned into current sections. Most likely, such extensions are for proprietary file formats created by software used by a small sector of the market.

Not too much feedback, I hope

[TheQwerty]

1. Horizontal scrolling is a bad idea. .... vertical scrolling is more user-friendly.

I disagree on this. The only reason to even display the extensions here is for easy comparison between the groups, and I believe that will always be easier if there is no wrapping. If they wrap then you cannot see all of the groups at once and certainly make it much more difficult to compare groups that can no longer both be seen at the same time.

Another way of looking at it is now when you compare two groups you really only have to worry about your place in the horizontal space, as the vertical location won't be changing. With wrapping you'll have to worry about your place in both the horizontal and vertical space.

2. Redundant white space.

I don't see a harm in having it be that wide as it matches the group control and makes the entire page look uniform. What I would prefer to see though is the extension list be a sortable table, so that the CSV data actually lines up in columns. (And then we could focus on adding more useful columns.)

3. "Remove" doesn't apply to factory-included formats.

My original thoughts was it would be nice if there were just a way to filter the extension list to only show user items, but perhaps you're right that removing the separation between user and XY added extensions makes more sense.

4. There is no "Miscellaneous" category.

Miscellaneous wouldn't make sense in this dialog, and is a big problem with using the same data for defining preview and find filters. In config "Never Preview" would make more sense, but, yes, "Misc." works better as a find filter. The question though is do we really need a way to define Miscellaneous, or should it just be the anything not already in a group?

I'll add:
5. Priority & Find Filter Explanation. There probably needs to be some text on the page that explains that the order of the groups is the priority given when attempting to preview, and to also point out that these groups are used as Find Filters.


It's definitely a marked improvement, Don, but I was thinking/hoping of a much bigger overhaul that would bring some cohesion to defining extensions for Preview, Find Filter, Color Filter, and POM/PFA, while also allowing user created groups. (I had started to draft up a wish but wanted to let it percolate some more.)

[admin]

Thanks for the feedback! I will continue to work on the preview (see updated roadmap) in the next weeks (as WC allows) and things will fall into the right places then...

[zer0]

1. Horizontal scrolling is a bad idea. .... vertical scrolling is more user-friendly.

I disagree on this. The only reason to even display the extensions here is for easy comparison between the groups, and I believe that will always be easier if there is no wrapping. If they wrap then you cannot see all of the groups at once and certainly make it much more difficult to compare groups that can no longer both be seen at the same time.

Another way of looking at it is now when you compare two groups you really only have to worry about your place in the horizontal space, as the vertical location won't be changing. With wrapping you'll have to worry about your place in both the horizontal and vertical space.

I believe that where scrolling can be avoided, it should be avoided. That's why I try to resize windows to eliminate them where possible. In addition, if wrapping is implemented, you won't have to worry about your place in horizontal space, only along the vertical axis.

Overall, I'm not even sure that having a list of extensions shown in each category and reproducing it in a tick-box area underneath is the best way to go. It's pretty much showing the same thing twice but in different ways, i.e. isn't very efficient.

Miscellaneous wouldn't make sense in this dialog, and is a big problem with using the same data for defining preview and find filters. In config "Never Preview" would make more sense, but, yes, "Misc." works better as a find filter. The question though is do we really need a way to define Miscellaneous, or should it just be the anything not already in a group?

I suggested "Miscellaneous" as a one-stop shop for extensions that don't fit into other sections. However, as per your suggestion, user-created groups would be possible then that part of my feedback would be obsolete.

[TheQwerty]

In addition, if wrapping is implemented, you won't have to worry about your place in horizontal space, only along the vertical axis.

I may not have explained it well but you still would have to worry about it for each. Remember I'm talking about when comparing the extensions of two groups visually, the only reason I can see to even list the extensions here, and in such a case I need to track two points that I will reference and compare.

So (x1, y1) & (x2, y2).
Currently, I first identify the rows for the groups I want to compare, so I now have defined y1 & y2, and then to compare them I only have to scroll horizontally so the y-points stay the same while x1 & x2 change. The only real difficulty comes from when the difference between x1 and x2 is greater than the width of the control and I then have to also track the vertical scroll positions.

If you add wrapping to this, y1 & y2 need to be re-evaluated each time you reach the end of a line in either group, so both the x-points and the y-points change. In addition, as you admit, wrapping would likely lead to an inability to see as many groups at once leading to a greater likelihood of needing to track the scroll positions. This could be partially remedied by arranging the controls side-by-side instead of vertically.

That's why I think, for the only use case I can imagine, horizontal scrolling is preferred to vertical.

Overall, I'm not even sure that having a list of extensions shown in each category and reproducing it in a tick-box area underneath is the best way to go. It's pretty much showing the same thing twice but in different ways, i.e. isn't very efficient.

I agree, and I don't see any use beyond comparing what's defined for each group. Given that, it would be better if the extension control remembered its scroll position when changing groups, which would allow you to align them each and quickly flip between groups to see what differs.

However, if removing the extensions from the group list I'd then say that the groups should be put into a drop down list like the CKS categories, even if this means needing an additional checkbox & label for Dis/En-abling the entire group, so that more room can be given to the extensions.

[zer0]

I may not have explained it well but you still would have to worry about it for each. Remember I'm talking about when comparing the extensions of two groups visually, the only reason I can see to even list the extensions here, and in such a case I need to track two points that I will reference and compare.

So (x1, y1) & (x2, y2).
Currently, I first identify the rows for the groups I want to compare, so I now have defined y1 & y2, and then to compare them I only have to scroll horizontally so the y-points stay the same while x1 & x2 change. The only real difficulty comes from when the difference between x1 and x2 is greater than the width of the control and I then have to also track the vertical scroll positions.

If you add wrapping to this, y1 & y2 need to be re-evaluated each time you reach the end of a line in either group, so both the x-points and the y-points change. In addition, as you admit, wrapping would likely lead to an inability to see as many groups at once leading to a greater likelihood of needing to track the scroll positions. This could be partially remedied by arranging the controls side-by-side instead of vertically.

That's why I think, for the only use case I can imagine, horizontal scrolling is preferred to vertical.

I suppose the reason I didn't understand your reasoning was because I thought of how often would one need to compare extensions of 2 (or more) categories and the number was not high. What kind of comparison do you mean?

[TheQwerty]

I suppose the reason I didn't understand your reasoning was because I thought of how often would one need to compare extensions of 2 (or more) categories and the number was not high. What kind of comparison do you mean?

Simply comparing which extensions exist and are enabled for each group. Indeed it isn't something that's done often but it is something that was much easier in the previous (good riddance) configuration pane.

[admin]

I'm not entering the discussion now, but only that you know: The top list will get more entries soon, so there will be some amount vertical scrolling for sure. And line wrapping in such a list is not possible, resp. not implemented because it would lead to items with differents heights, which would need a completely new approach to such a control -- not one of my plans for now.

Generally I think these settings, while not exactly set and forget, and not frequented that often so a bit of scrolling ain't such a problem.

BTW, the bottom list will indeed get more fields (that's why I made it wide) and probably (have to write this first) also column headers and sorting. This is heavy stuff that needs a little thinking first... (and it's WC... )

[zer0]

I'm not entering the discussion now, but only that you know: The top list will get more entries soon, so there will be some amount vertical scrolling for sure. And line wrapping in such a list is not possible, resp. not implemented because it would lead to items with differents heights, which would need a completely new approach to such a control -- not one of my plans for now.

Generally I think these settings, while not exactly set and forget, and not frequented that often so a bit of scrolling ain't such a problem.

BTW, the bottom list will indeed get more fields (that's why I made it wide) and probably (have to write this first) also column headers and sorting. This is heavy stuff that needs a little thinking first... (and it's WC... )

IMO, the separation into top and bottom lists was not necessary. What I was encouraging in my critique of previous interface is a unification of factory-default and user-defined formats. To an extent, this has happened -- we can add our own formats to existing categories. However, it has been "2 steps forward, 1 step back" with separation of category selection, extension lists being listed twice and addition of horizontal scrolling.

There is no obvious relationship linking between top and bottom lists and it is one's peripheral vision that has to notice that contents of the bottom list change as you click in the top list. Related items should be close together, so eyes do not have to wonder around the screen, thus breaking the taskflow.

With respect to horizontal listing of extensions in the top list, there are more words to be said. If these settings are not frequented often and -- as per TheQwerty's post -- isn't done often, why have such an alignment? The only reason I can think of to have horizontally-listed extensions is to show which ones are actually in effect. But, it is much more difficult to read entries when scrolling horizontally than vertically, let alone vertical scrolling is easier than horizontal as is. A better way would be to have disabled extensions greyed-out in the bottom list -- a de facto standard technique for showing things that are not in effect or to de-emphasise them.

Further, the manner of how check boxes in the top list are used puzzles me. Unchecking the box for a particular category, does not clear the boxes for extensions in the bottom list. It should as unchecking such a box is equivalent to clicking "Clear All". In addition, check boxes for categories do not seem to have a mixed-state, which they also should.

All in all, I think that the top and bottom lists should be unified with columns being added for sorting. I'll do my vision's sketch later as a picture tells a 1,000 words

[j_c_hallgren]

All in all, I think that the top and bottom lists should be unified with columns being added for sorting. I'll do my vision's sketch later as a picture tells a 1,000 words

I'll just say that the current setup, while giving more info than before, seems a bit less usable than the prior scheme with the columns...having to scroll the top horiz and the bottom vertically doesn't quite appear consistent...

Plus, having all the extensions strung out in a CSV list isn't that readable to me, and makes comparing two groups quite difficult.

Not sure how to make it ideal but current isn't it...sorry!

Addendum/update:
Agree that unchecking group in top should unselect all in bottom...and inverse.
Maybe the top should only show the groups and not extensions?
Also, how about a working group and a reference group? So that you could compare lists for two groups? The reference group would be non-modifiable (view-only) and could use some of the space used for items in top now.