Tough words about GUI

[admin]

A couple of things to say about the these changes:

Code: Select all

v9.70.0049 - 2010-11-28 17:33
    + Configuration | File Operations | Backup Operations | On name
      collisions: Added two new options and revised the wording of some
      of the old options:
      - Overwrite only older files
      - Overwrite always
      - Overwrite never
      - Suffix number to copies
      - Affix current date to copies
      - Affix last modified date to copies
      - Suffix number to existing
      - Affix current date to existing
      - Affix last modified date to existing

a) It's bad that there is no alphabetical grouping, the drop-down list looks messy as overwrite, suffix and affix options are mixed like a Caesar salad. Affix should be at the top, followed by Overwrite and then Suffix.

b) An even better approach would be to refactor them into 2 side-by-side drop-down lists: one to choose from Affix, Overwrite and Suffix and another to drill down into details. The lists would look much tidier with this liner approach.

I'm not so much against the flat approach because it is faster as long as the list is still as short as this one.
However, the current approach lacks certain useful combinations, e.g. "Affix current date to existing IF it is older (else do not copy)". So I will reorganize it as follows:

On name collision:
- Don't copy
- Copy always
- Copy if newer

On copy:
- Overwrite
- Rename copies
- Rename existing

On rename:
- Suffix number
- Affix current date
- Affix modified date

[zer0]

Nothing like a quiet day to post a grumble about a GUI aspect...

Currently, if no file is selected in the list, entries "Add Tags..." and "Edit Tags..." are not greyed out. They should be as they are redundant in such circumstances and clicking them does nothing. Status bar does notify that no file is selected, but it was outside of my peripheral vision so it can easily be missed -- notification window should be shown instead.

Further, when selecting file(s) with no tag(s), "Edit Tags..." becomes redundant as a) it does the same job as "Add Tags..." b) lacks logic as there are no tags to edit. Solution: grey out "Edit Tags..." in such situation.

[admin]

Nothing like a quiet day to post a grumble about a GUI aspect...

Currently, if no file is selected in the list, entries "Add Tags..." and "Edit Tags..." are not greyed out. They should be as they are redundant in such circumstances and clicking them does nothing. Status bar does notify that no file is selected, but it was outside of my peripheral vision so it can easily be missed -- notification window should be shown instead.

Further, when selecting file(s) with no tag(s), "Edit Tags..." becomes redundant as a) it does the same job as "Add Tags..." b) lacks logic as there are no tags to edit. Solution: grey out "Edit Tags..." in such situation.

I had this at one point, but then there was so much grey in the Favorites menu, that it looked awful and the uninformed user would wonder what's going on. So I decided to enable them and add the Statusbar message. But I agree it's not ideal. Hm.

Your 2nd point: Well, yes, but I think the human brain can handle this.

[zer0]

Recent emergence of a tendency to "consolidate" settings into additional modal (!) dialogue windows concerns me. It may create an impression that plethora of check boxes is no longer spoiling the sight, but that is not the case. The same check boxes are accessible via "Apply to..." buttons and "Extended" area has been added as "General" and "Advanced" can no longer cope with the overflow of options. It's a shady tactic that does not solve the underlying problem of GUI complexity. And it's only going to get worse unless something is done about it.

So many check boxes, at first sight, look overwhelming, maybe even intimidating. Some come with tooltips, which are unnecessary providing that labelling has been done correctly. Is a particular check box needed in the GUI or should modifying of the setting it controls be done within the INI file instead? There are no metrics as to how often each box is checked/unchecked, so that question is not easily answered. If there were such metrics, then it would be possible to determine the frequency of toggling and transition those settings that are rarely changed out of the GUI.

Coming back to check boxes, the labelling is often redundant and can be refactored for better clarity. In the "General" section, for example, Items in Tree and List can be renamed into Show Items in Tree and List. Doing so will allow removal of Show from subordinate check boxes as they share the same introductory text. It will also emphasise differences between options. Similar refactoring can be done with Folder Sizes and Sorting. Speaking of subordinates, on at least 5 occasions -- Context Menus in Extended, Miscellaneous in Advanced, Previewed Formats, File Info Tips and Startup & Exit -- having high-level check boxes unchecked does not render the nested buttons/check boxes inoperable. This is inconsistent with behaviour of all other subordinate check boxes and creates a confusion as to the meaning of subordinate controls.

Overall, a lot of check boxes have to go: either into the INI file or completely. Yes, difficult decisions would have to be made. Yes, they are easy to avoid by making everything optional/configurable. However, doing so would be equivalent to sticking one's head into the sand and it would not improve XY's GUI or user experience.

[j_c_hallgren]

Overall, a lot of check boxes have to go: either into the INI file or completely.

The problem I have with options that are strictly in the INI is that finding/documenting them isn't as easy and explaining how to do it to new users is always an issue...now what a few products I've used to to address the issue is to have an "Advanced" section of each section that is only displayed on request (like extended 2nd half on bottom) so the new/common users don't get overwhelmed by choices yet can still locate and set them as needed...it would clean up the config yet leave it convenient for us who want to set some options that others may never care about.

Regarding caption/tooltip: While I agree some captions might be able to be improved, due to space constraints some can't and having that tooltip avoids having to use the Help to figure out what it is...so when I see a few options that DON'T have tips, I'm surprised because they might well benefit from a short auxilliary desc.

[zer0]

Overall, a lot of check boxes have to go: either into the INI file or completely.

The problem I have with options that are strictly in the INI is that finding/documenting them isn't as easy and explaining how to do it to new users is always an issue...now what a few products I've used to to address the issue is to have an "Advanced" section of each section that is only displayed on request (like extended 2nd half on bottom) so the new/common users don't get overwhelmed by choices yet can still locate and set them as needed...it would clean up the config yet leave it convenient for us who want to set some options that others may never care about.

New users shouldn't be expected to dig around in the INI as the app is meant to provide sufficient extent of customisation out-of-the-box. However, said extent in XYplorer is an overkill. While an extended half on at the bottom sounds better than a modal window, it's still an area where the excess is stashed away. Using group boxes to contain related check boxes wouldn't go amiss either.

Regarding caption/tooltip: While I agree some captions might be able to be improved, due to space constraints some can't and having that tooltip avoids having to use the Help to figure out what it is...so when I see a few options that DON'T have tips, I'm surprised because they might well benefit from a short auxilliary desc.

I don't know of another application that has tips on check box labels. If there are space constraints then maybe having configuration categories organised at the top would give more width for better captions. And help is there to do exactly that: help. It shouldn't be feared -- who knows, users may learn a little extra

[j_c_hallgren]

And help is there to do exactly that: help. It shouldn't be feared -- who knows, users may learn a little extra

But I'm thinking of it from a usability POV...when I'm new to the appl or that option, a 3-4 word caption may be inadequate but a full sentence via tooltip may be more than enough so by using tooltips to avoid having to access help when all that is needed is a slightly longer or alternate wording seems ideal solution...after all, when I hover over icons on my Google Toolbar, it gives a short desc of that icon so this is similar but just a bit extended in that Config caption already gives the equiv a short vers and the tip gives the long vers.

I can't place it right now but I'm 99+% sure i've got some other appl that have hovering tips on their config/pref setups.

Addendum: VLC has quite extensive tooltips on their pref dialogs as well as a "Simple" switch to make the config easy for newbies/etc.

[zer0]

And help is there to do exactly that: help. It shouldn't be feared -- who knows, users may learn a little extra

But I'm thinking of it from a usability POV...when I'm new to the appl or that option, a 3-4 word caption may be inadequate but a full sentence via tooltip may be more than enough so by using tooltips to avoid having to access help when all that is needed is a slightly longer or alternate wording seems ideal solution...after all, when I hover over icons on my Google Toolbar, it gives a short desc of that icon so this is similar but just a bit extended in that Config caption already gives the equiv a short vers and the tip gives the long vers.

I can't place it right now but I'm 99+% sure i've got some other appl that have hovering tips on their config/pref setups.

Addendum: VLC has quite extensive tooltips on their pref dialogs as well as a "Simple" switch to make the config easy for newbies/etc.

First things first, I made a mistake when I said tooltips. Tooltips are reserved for unlabelled controls, so calling them infotips is more appropriate. Second of all, there is no consistency -- not all check boxes have them. This is what Microsoft User Experience Guidelines have to say:

* For infotips in nonstandard places, favor consistency over helpfulness to improve discoverability. Provide tips for all objects for which users are likely to want supplemental information, even if a few infotips might be obvious. Doing so avoids having users wait for an infotip that will never come.
* Exception: If only a few objects have helpful infotips, don't use infotips at all. Rather, use self-explanatory control labels or in-place supplemental text instead.

Re: VLC player, it's an open source application, so there are helpful people who add things like that. XYplorer is closed source, so we can't contribute that much

[j_c_hallgren]

And for consistency, I wouldn't have any objection to having a infotip for all items...and VLC was just the example I found the first...I'm sure I have others.

[PeterH]

I don't know of another application that has tips on check box labels. If there are space constraints then maybe having configuration categories organized at the top would give more width for better captions. And help is there to do exactly that: help. It shouldn't be feared -- who knows, users may learn a little extra

Yes: help should not be feared.
But I think it's wrong to give less information directly when using a program, and say people could use help. I prefer "rich" information while using a program.

[zer0]

I don't know of another application that has tips on check box labels. If there are space constraints then maybe having configuration categories organized at the top would give more width for better captions. And help is there to do exactly that: help. It shouldn't be feared -- who knows, users may learn a little extra

Yes: help should not be feared.
But I think it's wrong to give less information directly when using a program, and say people could use help. I prefer "rich" information while using a program.

Giving infotips to check boxes is unconventional, which reduces expectation. Inconsistency is my main concern.

[j_c_hallgren]

Yes: help should not be feared.
But I think it's wrong to give less information directly when using a program, and say people could use help. I prefer "rich" information while using a program.

Giving infotips to check boxes is unconventional, which reduces expectation. Inconsistency is my main concern.

It may be not the norm, but it's not unconventional and I just can't see how providing MORE information in a very easy to access manner "reduces expectation".

If I have a choice between two products and one gives me infotips on their config settings and the other doesn't, I'd most certainly prefer the first! Makes conversion and usage quicker.

And I've addressed inconsistency: Have tooltips for all items, even if minimal.

[zer0]

Giving infotips to check boxes is unconventional, which reduces expectation. Inconsistency is my main concern.

It may be not the norm, but it's not unconventional and I just can't see how providing MORE information in a very easy to access manner "reduces expectation".

Not having infotips in config's check boxes of most other applications reduces people's expectations of seeing them in XYplorer. I hope that most are pleasantly surprised to see them.

[PeterH]

Giving infotips to check boxes is unconventional, which reduces expectation. Inconsistency is my main concern.

It may be not the norm, but it's not unconventional and I just can't see how providing MORE information in a very easy to access manner "reduces expectation".

Not having infotips in config's check boxes of most other applications reduces people's expectations of seeing them in XYplorer. I hope that most are pleasantly surprised to see them.

(Deleted one /quote)

You say pleasantly - as you think people like them?
I, at least, do so.

[zer0]

Not having infotips in config's check boxes of most other applications reduces people's expectations of seeing them in XYplorer. I hope that most are pleasantly surprised to see them.

You say pleasantly - as you think people like them?

Some may like them and some may not. I'm not the biggest fan as the less I have to read in order to get my task done the better

Change of subject...came across this notification just the other day

Capture2.PNG (36.91 KiB) Viewed 1994 times

A couple of things to say:

a) "The rename job is now completed" doesn't gel with "An item could not be renamed" and "Rename Failed". Those together send an inconsistent message to the user. "The rename job is now completed" should be removed from the window to avoid confusion.
b) The window itself is presented as a warning message, whereas it should be an error message as it is presenting a problem that has already occurred.