Tough words about GUI

[Stefan]

About "Custom Copy": my first try with 1110, looks good. Fine work Don, :thumpsup:

(for newbies like me: first enable "Custom Copy" via menu "Tools > Configuration > File Op")

i kinda agree with zer0 that maybe there are too much of "completed" there. maybe it's better to a bit paraphrase it? for example "Processing ended" and "Custom Copy done in .. min".

Yes, there are other similar words that could be used so there is a bit of variety..like finished/done/ended/etc.

And next i ask you what is the difference between "finished/done/ended"

"completed" looks fine to me.

[admin]

I didn't use "completed" 3 times light-heartedly. This is not about poetry but about exactness. In each of the 3 places "completed" fills a paradigmatic slot in opposition with "paused" and "cancelled". Choosing a different word here just for variety would lead to confusion in the user.

[zer0]

A screenshot is enough to design a changing thing like a progress dialog. It's a machine with various states and routes. You'd rather need a storyboard approach. But please don't try to do this now, as I won't change the design anymore now. Possible future paths are already laid out in my head, so you have very little chances to add something valuable here.

I'm guessing that you meant "...not enough to design...". That makes it easy, I just won't use custom copy. It does not work for moves and I am yet to see if it is faster as far copying is concerned.

I didn't use "completed" 3 times light-heartedly. This is not about poetry but about exactness. In each of the 3 places "completed" fills a paradigmatic slot in opposition with "paused" and "cancelled". Choosing a different word here just for variety would lead to confusion in the user.

Once it's completed, it doesn't need to be said 3 times, once is enough.

[admin]

A screenshot is enough to design a changing thing like a progress dialog. It's a machine with various states and routes. You'd rather need a storyboard approach. But please don't try to do this now, as I won't change the design anymore now. Possible future paths are already laid out in my head, so you have very little chances to add something valuable here.

I'm guessing that you meant "...not enough to design...".

Oh, sure. I edited the original post.

[alps]

I too agree with "zer0" and i respect your feeling's that it build's confidence,but 3 times is too much.And instead of Custom copy in the dialog we can use just CC completed.

[gtm]

I agree with the following too

http://i49.tinypic.com/2ztac1c.png
Locking the GUI components, otherwise when unlocked drag drop would be good

http://i49.tinypic.com/m8k192.png

http://i49.tinypic.com/2ztac1c.png

[Trasd]

Can I jump in...?

I was going to try and read all 23 pages on this forum before I posted (so I was knowledgeable and wouldn't repeat), but it was started a couple of years ago (much could have changed since then) and, really, I'm too lazy. I'll try to keep up from here on out.

I did find something interesting in http://i50.tinypic.com/2zjdg7p.png, so I did a forum search on the PNG and came up empty. I wanted to comment on the ... (ellipse). The ellipse and right arrow, on a menu, have a very specific meaning in Windows: the ellipse means that if this menu item is selected, you will get further interaction (non-committal); the right arrow means you will get a submenu when you point to this menu item. I'm a stickler for details like this and for some reason, even with my otherwise bad memory, I remember them. Anywho, here is Microsoft's official documentation.

Now, a piece of trivial? Who developed and wrote the first GUI architectural standards? If your answer was the obvious Microsoft, you'd be surprised to know it was IBM, not Mr. Gates. Here is a Wiki exert:

Common User Access (CUA) is a standard for user interfaces to operating systems and computer programs. It was developed by IBM and first published in 1987 as part of their Systems Application Architecture. Used originally in the OS/MVS, VM/CMS, OS/400, OS/2 and Microsoft Windows operating systems, parts of the CUA standard are now implemented in programs for other operating systems, including variants of Unix. It is also used by Java AWT and Swing.

Of course it was called CUA (Common User Access), not GUI (Windows wasn't around yet - it was a few years later when the GUI version of Excel was released, which was the basis for MS Windows). Graphic UI standards were also documented in this manual, though. I couldn't find a good link to the PDF, but I actually still have the original printed manual, as well as the IBM Bookshelf Library CDs (yea, OK, I'm a documentation pack-rat - you never know when they'll come in handy again! Just a few days after I finally threw out my printed EMACS books, I needed them).


One last comment on:

Now, as long as XY's "look and feel" is better than TC's "look and fear" I don't worry too much about the GUI.

All I can say is, "DANGER WILL ROBINSON DANGER."

[zer0]

Code: Select all

v10.50.0023 - 2011-11-12 14:25   
    + Configuration | General: Added "Allow move on rename"
      - This feature already exists as a tweak (AllowMoveOnRename)
        since v6.80.0098 - 2008-03-05 12:52. Finally I got around
        raising it to Configuration level.

A question: why was there a need to bring in an additional check box after over 3.5 years in exile as a tweak? If anything, as time goes on, set-it-and-forget-it type settings should be migrated to the configuration file, not the other way around. I don't know about you, but I think that it is sure getting crowded in Configuration | General. Personally, the only setting I tend to change on a semi(!)-frequent basis is to toggle folder sizes being shown in the list. That's it, no more. I have said it before and I will say it again that this ocean of check boxes is not helping on iota to keep things simple, because therein lies sophistication.

[nas8e9]

Code: Select all

v10.50.0023 - 2011-11-12 14:25   
    + Configuration | General: Added "Allow move on rename"
      - This feature already exists as a tweak (AllowMoveOnRename)
        since v6.80.0098 - 2008-03-05 12:52. Finally I got around
        raising it to Configuration level.

A question: why was there a need to bring in an additional check box after over 3.5 years in exile as a tweak? If anything, as time goes on, set-it-and-forget-it type settings should be migrated to the configuration file, not the other way around. I don't know about you, but I think that it is sure getting crowded in Configuration | General. Personally, the only setting I tend to change on a semi(!)-frequent basis is to toggle folder sizes being shown in the list. That's it, no more. I have said it before and I will say it again that this ocean of check boxes is not helping on iota to keep things simple, because therein lies sophistication.

Basically, stuffing it in Configuration does aid accessibility (it isn't unusual to see forum posts where people went wrong with tweaking or indeed haven't yet found it). I do agree that with regard to discoverability, there's a balancing act involved. Ideally, one look at the Configuration-dialog shows you what section you need to enter. As is, the first three sections have several subsections with minimal to no relation to the name of the section.

Unfortunately, I can't think of a single complex app that has a perfect configuration dialog. The one thing that might be useful however, is a search facility (such as the List Management-dialog already has) for the Configuration-dialog, perhaps searching in the dialog text for that option (and its section and subsection name) but also in the accompanying popup help text. And yes, that idea is borrowed from a competing product.

[PeterH]

At least I'm not convinced that having to edit a .ini makes it easier than to config by dialog.

That is: seeing the advantages of less options in configuration dialog implies seeing the disadvantages of manually editing a .ini - including creation of problems by accidentally making errors.

I'm not a friend of .ini-editing, you see.
OK - there might be the "advantage" of less people "configuring around", when they have to do it "native"...

[Jerry]

A question: why was there a need to bring in an additional check box after over 3.5 years in exile as a tweak? If anything, as time goes on, set-it-and-forget-it type settings should be migrated to the configuration file, not the other way around. I don't know about you, but I think that it is sure getting crowded in Configuration | General. Personally, the only setting I tend to change on a semi(!)-frequent basis is to toggle folder sizes being shown in the list. That's it, no more. I have said it before and I will say it again that this ocean of check boxes is not helping on iota to keep things simple, because therein lies sophistication.

The problem of editing a growing number of configuration options via the GUI is a legitimate concern. But editing the configuration file should never be the only way to set a subset of permanent options, even if they are advanced power-user settings or typically only set once and never changed again. In fact, direct user-editing of the configuration file should be proscribed completely.

A good, easily implemented, scalable way to deal with this problem is illustrated by Firefox 3.6x's about:config panel. There you can access every configuration property, filtering the list to show just what you want, and the hierarchical naming convention is self-organizing and mostly self-descriptive. Ideally, it ought to also provide help descriptions for each property. So advanced settings or those not likely to be set by the majority of users, can always be edited here, but still under the full control of the application.

This kind of thing should be added to the Roadmap.

[nas8e9]

The problem of editing a growing number of configuration options via the GUI is a legitimate concern. But editing the configuration file should never be the only way to set a subset of permanent options, even if they are advanced power-user settings or typically only set once and never changed again. In fact, direct user-editing of the configuration file should be proscribed completely.

+1 with regard to regular settings. Given the way Don works however, I don't see tweaks (which currently can only be set through XYplorer.ini-editing) go away.

A good, easily implemented, scalable way to deal with this problem is illustrated by Firefox 3.6x's about:config panel. There you can access every configuration property, filtering the list to show just what you want, and the hierarchical naming convention is self-organizing and mostly self-descriptive. Ideally, it ought to also provide help descriptions for each property. So advanced settings or those not likely to be set by the majority of users, can always be edited here, but still under the full control of the application.

I think that to be just too crude for the regular options: after all, Firefox has a Options-dialog as well. As for a separate option editing functionality which combines both regular options as well as tweaks, I think it has merit. Distinct from this, I'd like a search function integrated in the regular Configuration-dialog as posted earlier, particularly to cover the dense three sections as well as for options which can be classed in more than one section, e.g. Rename.

[Jerry]

+1 with regard to regular settings. Given the way Don works however, I don't see tweaks (which currently can only be set through XYplorer.ini-editing) go away.

The idea is that this venue would always available for ALL options, including tweaks. Not sure what you mean by the way Don works, but this is just a simple UI for editing the configuration file, whatever is in it, new or old.

I think that to be just too crude for the regular options: after all, Firefox has a Options-dialog as well. As for a separate option editing functionality which combines both regular options as well as tweaks, I think it has merit.

Yes, it would be crude if it were the only way to edit options. And just as Firefox does, XYplorer would still provide it's various explicit dialog panels for just the "regular" options.

Distinct from this, I'd like a search function integrated in the regular Configuration-dialog as posted earlier, particularly to cover the dense three sections as well as for options which can be classed in more than one section, e.g. Rename.

I absolutely agree. And I think the best model for that is the Eclipse IDE. I haven't used it for a couple of years now, but it lets you search for anything appearing in its configuration dialogs, shows you what dialogs are relevant and with a click you go to just the right place.

[nas8e9]

+1 with regard to regular settings. Given the way Don works however, I don't see tweaks (which currently can only be set through XYplorer.ini-editing) go away.

The idea is that this venue would always available for ALL options, including tweaks. Not sure what you mean by the way Don works, but this is just a simple UI for editing the configuration file, whatever is in it, new or old.

AFAIK Don will occasionally implement something which he doesn't want to elevate to regular status (yet). Regular status implies that it can be set through the GUI while tweaks are XYplorer.ini-only.

In your proposal, the alternative Firefox about:config-like editing environment would cover the whole of XYplorer, i.e. regular options and tweaks. Given that it's more hard-core than Tools > Configuration, and at the same time avoids the XYplorer.ini-editing, it seems promising to me.

Distinct from this, I'd like a search function integrated in the regular Configuration-dialog as posted earlier, particularly to cover the dense three sections as well as for options which can be classed in more than one section, e.g. Rename.

I absolutely agree. And I think the best model for that is the Eclipse IDE. I haven't used it for a couple of years now, but it lets you search for anything appearing in its configuration dialogs, shows you what dialogs are relevant and with a click you go to just the right place.

I was thinking of Directory Opus's Preferences window.

[zer0]

Basically, stuffing it in Configuration does aid accessibility (it isn't unusual to see forum posts where people went wrong with tweaking or indeed haven't yet found it). I do agree that with regard to discoverability, there's a balancing act involved. Ideally, one look at the Configuration-dialog shows you what section you need to enter. As is, the first three sections have several subsections with minimal to no relation to the name of the section.

But it sat perfectly well as a tweak for such a long time without any problems. Raising it to the UI level does not seem warranted.

Unfortunately, I can't think of a single complex app that has a perfect configuration dialog. The one thing that might be useful however, is a search facility (such as the List Management-dialog already has) for the Configuration-dialog, perhaps searching in the dialog text for that option (and its section and subsection name) but also in the accompanying popup help text. And yes, that idea is borrowed from a competing product.

Instead of trying to imitate, XYplorer should innovate. So it should aim to have a perfect configuration dialogue. Having a search facility would already speak volumes that the dialogue is too complex -- if one cannot determine a section for a setting and click to it and check there is something wrong.

At least I'm not convinced that having to edit a .ini makes it easier than to config by dialog.
That is: seeing the advantages of less options in configuration dialog implies seeing the disadvantages of manually editing a .ini - including creation of problems by accidentally making errors.
I'm not a friend of .ini-editing, you see.
OK - there might be the "advantage" of less people "configuring around", when they have to do it "native"...

To be honest, just how often would people need to edit the .ini? How often do people change settings in the main configuration dialogue? I suggested quite some time ago that Don implements usage statistics, but he has not done so (yet, I hope). If you could know that 90-95% of users do not change a particular setting over the course of months, you could contemplate to keep its value, but relegate it from the GUI. Likewise, if a lot of users enable a setting that is unchecked by default, there is a case for having it on out of the box. And if they change it and keep it that way, it may not need raising the GUI level. It's about making intelligent decisions.