XYplorer Beta Club

Posted: **25 Nov 2009 17:46**

zer0 wrote:Win-Win, from where I stand

I guess we're going to have to disagree here as I see auto-apply as the only choice to be a big loss in flexability and would lead to unwanted changes being saved.

Because...if I've made a change that wasn't intended (i.e. accidental), and then move to another UDC, it will be auto-applied without any notification, and then when I exit via "OK", it will be saved..and thus cause a problem...so why would I use "OK" and not Cancel? If I didn't have any intent to make chgs, it shouldn't matter that I use the default.

That's why I want the pop-up as an option so that I'm forced to choose what I want to possibly save or not and have to make an obvious key entry to do so.

I compare it to Excel, where when I close a sheet, if I've done anything whatsoever since I opened it, even like moving cursor to just another cell, I get a prompt to decide what to do.

Posted: **25 Nov 2009 18:41**

j_c_hallgren wrote:I guess we're going to have to disagree here as I see auto-apply as the only choice to be a big loss in flexibility and would lead to unwanted changes being saved.

It's a battle between getting into a habit of clicking a button to confirm a change and then confirm it again versus having those changes autosaved with an option to reverse them prior to "overall" confirmation.

j_c_hallgren wrote:Because...if I've made a change that wasn't intended (i.e. accidental), and then move to another UDC, it will be auto-applied without any notification, and then when I exit via "OK", it will be saved..and thus cause a problem...so why would I use "OK" and not Cancel? If I didn't have any intent to make chgs, it shouldn't matter that I use the default.

The only way there'd be a change, for example, is if you edit a script for a UDC and click OK. It's difficult to construe that as anything other than wanting to make a change. If you clicked 'OK' by mistake, then 'Reset' is there to roll-back the changes.

j_c_hallgren wrote:That's why I want the pop-up as an option so that I'm forced to choose what I want to possibly save or not and have to make an obvious key entry to do so.

A pop-up every time you make a change and try to navigate to another UDC? What are the chances of you making an change you didn't intend to make?

j_c_hallgren wrote:I compare it to Excel, where when I close a sheet, if I've done anything whatsoever since I opened it, even like moving cursor to just another cell, I get a prompt to decide what to do.

You and me must have different versions of Excel (I have Excel '07), because it doesn't nag

me about something as petty as moving a cursor to another cell.

I think the version that Don proposes is better than current. I thought of another reason why it's better just now. Currently, if you click 'Apply' then that change is applied and 'Reset' won't reverse applied changes. Having them autosaved while you're browsing between UDCs puts those changes into a suspended state, where you can reverse individual ones if you wish via 'Reset' and confirm the lot via the "big" 'OK'. If it's easy for Don to implement some form of a mechanism by which a user can choose either Autosave or a form of notification then super, though I think it's reasonable to presume that factory default should be autosave.

Posted: **25 Nov 2009 19:15**

I'm with jc on that one, I don't think I would like an auto-apply when clicking away. If anything, it would be inconsistent with standard behavior : we have those settings, and as soon as we change them, they enter a state of being "unsaved" as is even visually indicated by the * added after "Command Properties"
And the standard, I believe, is that then those changes must be either applied or reset (to keep using the current buttons captions), and if one tries to trigger something that would result in those changes to be lost, we get a popup asking what to do. Just like, as jc said, in Excel I'm sure or in pretty any much any text editor for example, trying to quit while there's an unsaved file open will get us a "There are unsaved changes, do you want to save the file ? Yes/No/Cancel"

While not having this popup upon pressing either Ok or Cancel make sense, when we're talking about just clicking on another category, UDC, etc I think the confirmation popup is to be expected.

And I do think that it is much better to have such a popup as well as a button Apply so one can say "yes, I validate those changes" rather than have an auto-apply all the time & no more Apply button.

zer0 wrote:It's a battle between getting into a habit of clicking a button to confirm a change and then confirm it again versus having those changes autosaved with an option to reverse them prior to "overall" confirmation.

zer0 wrote:It's difficult to construe that as anything other than wanting to make a change. If you clicked 'OK' by mistake, then 'Reset' is there to roll-back the changes.

That's not really it, no. It is more you confirm one specific set of changes (on UDC-level), and you then confirm all the changes made on this dialog (all UDCs, all categories), you don't actually confirm the same thing twice. Also, if changes are auto-applied there's no way to reverse them, that option (Reset) is only available while in unsaved state, once it's been either applied or reverted, that's done. (Only thing left would be to hit Cancel, but again that doesn't work on the same level, and would reset every changes (all UDCs, all categories) which is quite different.)

zer0 wrote:You and me must have different versions of Excel (I have Excel '07), because it doesn't nag me about something as petty as moving a cursor to another cell.

He didn't say that at all, only that you get such a popup in Excel when trying to close an unsaved document... and that's far from being limited to Excel, obviously.

Posted: **25 Nov 2009 22:06**

zer0 wrote:
j_c_hallgren wrote:That's why I want the pop-up as an option so that I'm forced to choose what I want to possibly save or not and have to make an obvious key entry to do so.
A pop-up every time you make a change and try to navigate to another UDC?

Yes, if that's how it works best for me (and jacky and likely some others)...we're not saying you must adopt our methods so why insist that we adopt yours?

zer0 wrote:If it's easy for Don to implement some form of a mechanism by which a user can choose either Autosave or a form of notification then super, though I think it's reasonable to presume that factory default should be autosave.

And that choice of methods is what I've been requesting in this entire thread..

But I'd select prompt as factory default as that seems to be more consistent with other app's.

Posted: **25 Nov 2009 22:24**

jacky wrote:I'm with jc on that one, I don't think I would like an auto-apply when clicking away. If anything, it would be inconsistent with standard behavior : we have those settings, and as soon as we change them, they enter a state of being "unsaved" as is even visually indicated by the * added after "Command Properties"
And the standard, I believe, is that then those changes must be either applied or reset (to keep using the current buttons captions), and if one tries to trigger something that would result in those changes to be lost, we get a popup asking what to do. Just like, as jc said, in Excel I'm sure or in pretty any much any text editor for example, trying to quit while there's an unsaved file open will get us a "There are unsaved changes, do you want to save the file ? Yes/No/Cancel"

While not having this popup upon pressing either Ok or Cancel make sense, when we're talking about just clicking on another category, UDC, etc I think the confirmation popup is to be expected.

And I do think that it is much better to have such a popup as well as a button Apply so one can say "yes, I validate those changes" rather than have an auto-apply all the time & no more Apply button.

I, however, think that navigating to another UDC is a bad trigger to get a prompt whether to Save/Discard/Cancel. At the very least not as default behaviour, it's just not in the spirit of "power user". And speaking of consistency, I cannot help but think of each UDC category as a category in Configuration. If parallel lines are drawn, then there are definitely inconsistencies there, because one does not have to confirm individual setting changes and they are not discarded upon browsing to another category. Having 'Apply' button and/or pop-up also feels too much like holding a user's hand and almost punishing a user, saying something along the lines of "If you don't click apply and browse to another UDC your changes will be lost, but if you do click 'Apply' then you won't be able to revert them". What if one's finger slips and one clicks 'Apply' instead of 'Reset'?

jacky wrote:That's not really it, no. It is more you confirm one specific set of changes (on UDC-level), and you then confirm all the changes made on this dialog (all UDCs, all categories), you don't actually confirm the same thing twice. Also, if changes are auto-applied there's no way to reverse them, that option (Reset) is only available while in unsaved state, once it's been either applied or reverted, that's done. (Only thing left would be to hit Cancel, but again that doesn't work on the same level, and would reset every changes (all UDCs, all categories) which is quite different.)

To confirm a change of, for example, 'Run Script' you can do it in either 2 or 3 steps. 2-step way would involve clicking 'OK' on 'Edit Script' window and 'OK' on overall UDC window. 3-step way would have the aforementioned 2 with an addition of clicking 'Apply' button. Effect of 'Apply' can be reversed by clicking the main 'Cancel', but then one looses all changed that were made outside of the one that one wishes to reverse. Considering that if one clicks 'OK' on 'Edit Script' window by mistake, it's quite likely that one would notice that straight away and will be able to reset. If one does not reset straight away and browses away to another category, then I see no risk in saving those changes, with an option to reverse pending the overall UDC 'OK'. Currently, browsing to another category has the effect of clicking 'Reset' without doing so and I just don't think that's very user-friendly, especially since these nested confirmations are a rarity in my experience.

j_c_hallgren wrote:But I'd select prompt as factory default as that seems to be more consistent with other app's.

Not for nested changes, it's not consistent.

Your example of a Excel is not a very good one, because there's no concept of nesting unlike one that is present in XYplorer. An equivalent of what you're suggesting is if you had 2+ sheets in your Excel workbook and you'd get prompted every time you swapped between them after making changes in one. Think of those individual sheets as UDC commands and a workbook as a UDC category, with Excel being the overall wrapper of a program ala XYplorer. The point is that you don't get prompted when you swap between sheets, prompts for nested changes is not something that I ever came across with any other app as far as I can remember.

Posted: **26 Nov 2009 07:53**

I'm still with zer0 and muroph. But I try to use less words:

Consistency: This is the only Apply button in XYplorer. Everywhere else making a change and then moving on to the next option in the same window will apply that change.

What is gained by the Apply button? I would assume that making or changing an entry is in most cases something you intend to do. Why force the user to double-confirm his intention? Or rather triple-confirm, because the final "apply" is (consistently) done with the OK button.

And for the case you really change your mind: there's the Reset button.

A possible improvement for me would be to enable the Reset button only if the properties have been changed (if there is something to reset). This would make the "*" marker superfluous.

Posted: **26 Nov 2009 09:58**

admin wrote:A possible improvement for me would be to enable the Reset button only if the properties have been changed (if there is something to reset). This would make the "*" marker superfluous.

That would help somewhat, as it then becomes a visual indicator that something was altered...but could this ability to reset be maintained even if one were to switch to another UDC and than back? Especially if we're going to auto-apply...That would allow user to later 'undo' some changes but retain others as using OK or cancel at higher level affects all.

I think if this were done that I and maybe jacky would be more accepting of the auto-apply concept.

Posted: **26 Nov 2009 11:41**

j_c_hallgren wrote:
admin wrote:A possible improvement for me would be to enable the Reset button only if the properties have been changed (if there is something to reset). This would make the "*" marker superfluous.
That would help somewhat, as it then becomes a visual indicator that something was altered...but could this ability to reset be maintained even if one were to switch to another UDC and than back? Especially if we're going to auto-apply...That would allow user to later 'undo' some changes but retain others as using OK or cancel at higher level affects all.

No.

This would make necessary that the Reset button is always enabled. For that purpose you should simply press Cancel.

Another advantage of removing the Apply button: It prevents a possible user mistake where the user might think that "Apply" does actually apply for good without the need to press OK later. This behavior of "Apply" is very common in Windows dialogs. But in XY you currently have to press Apply AND OK -- very uncommon for Windows.

Posted: **26 Nov 2009 14:03**

admin wrote:
j_c_hallgren wrote:
admin wrote:A possible improvement for me would be to enable the Reset button only if the properties have been changed (if there is something to reset). This would make the "*" marker superfluous.
That would help somewhat, as it then becomes a visual indicator that something was altered...but could this ability to reset be maintained even if one were to switch to another UDC and than back? Especially if we're going to auto-apply...That would allow user to later 'undo' some changes but retain others as using OK or cancel at higher level affects all.
No. This would make necessary that the Reset button is always enabled. For that purpose you should simply press Cancel.

Another advantage of removing the Apply button: It prevents a possible user mistake where the user might think that "Apply" does actually apply for good without the need to press OK later. This behavior of "Apply" is very common in Windows dialogs. But in XY you currently have to press Apply AND OK -- very uncommon for Windows.

Okay, you know what: drop the Apply button, and drop the Reset one as well. Seriously, let's get clean and make this behave like elsewhere in XY : on Config, if I update a few categories, add/remove/edit some Color Filters, add/edit/remove some tags, only to realize I removed/edited one but shouldn't have, what can I do? Either I know how to manually fix it, or I hit Cancel and everything I did on Configuration - not just this tag or even this category or anything, but everything I did on Configuration - gets dropped.

This is the standard XY behavior, so let's just make UDC behave exactly the same, and that should be a lot more clear/consistent. So no more Apply nor Reset, and changes to a UDC are always and instantly auto-applied.

Posted: **26 Nov 2009 14:37**

jacky wrote:
admin wrote:
j_c_hallgren wrote:
admin wrote:A possible improvement for me would be to enable the Reset button only if the properties have been changed (if there is something to reset). This would make the "*" marker superfluous.
That would help somewhat, as it then becomes a visual indicator that something was altered...but could this ability to reset be maintained even if one were to switch to another UDC and than back? Especially if we're going to auto-apply...That would allow user to later 'undo' some changes but retain others as using OK or cancel at higher level affects all.
No. This would make necessary that the Reset button is always enabled. For that purpose you should simply press Cancel.

Another advantage of removing the Apply button: It prevents a possible user mistake where the user might think that "Apply" does actually apply for good without the need to press OK later. This behavior of "Apply" is very common in Windows dialogs. But in XY you currently have to press Apply AND OK -- very uncommon for Windows.
Okay, you know what: drop the Apply button, and drop the Reset one as well. Seriously, let's get clean and make this behave like elsewhere in XY : on Config, if I update a few categories, add/remove/edit some Color Filters, add/edit/remove some tags, only to realize I removed/edited one but shouldn't have, what can I do? Either I know how to manually fix it, or I hit Cancel and everything I did on Configuration - not just this tag or even this category or anything, but everything I did on Configuration - gets dropped.

This is the standard XY behavior, so let's just make UDC behave exactly the same, and that should be a lot more clear/consistent. So no more Apply nor Reset, and changes to a UDC are always and instantly auto-applied.

I'm with you!

Posted: **08 Jan 2010 11:24**

Code: Select all

v8.70.0011 - 2009-12-07 14:46
    - Reverted this change from v8.70.0006 - 2009-12-04 11:51:
      * Manage User-Defined Commands Dialog: Removed the buttons Apply 
        and Reset from the Command Properties section. ...
      Reason: Complications under certain conditions. Not worth the 
      pain fixing this.

This just won't do

By having it this way, you're committing three cardinal software sins (yes, there are those

):

It means I lose my work when I navigate to another category or list item in UDC modal window
It is annoying, requires attention and distracts me from what I want to do. It's also inhabitual -- confirming changes to sub-items and then doing an overall confirm is rare, haven't encountered it anywhere apart from XYplorer
I have to redo what I lost, so it requires more work from me than necessary.

Not knowing what complications you're referring to, I couldn't possibly comment, but I urge you to try to find a way to make this work, because an interface that doesn't respect habituation is a bad interface

Posted: **09 Jan 2010 15:48**

zer0 wrote:
Code: Select all
v8.70.0011 - 2009-12-07 14:46
    - Reverted this change from v8.70.0006 - 2009-12-04 11:51:
      * Manage User-Defined Commands Dialog: Removed the buttons Apply 
        and Reset from the Command Properties section. ...
      Reason: Complications under certain conditions. Not worth the 
      pain fixing this.
This just won't do By having it this way, you're committing three cardinal software sins (yes, there are those ):
It means I lose my work when I navigate to another category or list item in UDC modal window
It is annoying, requires attention and distracts me from what I want to do. It's also inhabitual -- confirming changes to sub-items and then doing an overall confirm is rare, haven't encountered it anywhere apart from XYplorer
I have to redo what I lost, so it requires more work from me than necessary.
Not knowing what complications you're referring to, I couldn't possibly comment, but I urge you to try to find a way to make this work, because an interface that doesn't respect habituation is a bad interface

Those complications had also to do with sparse time at that point. I revisited them and found them easy to solve. So next version will finally come without the need to press buttons.

Posted: **18 Jan 2010 17:43**

Thank you for implementing this. Not having those 2 buttons does create a fair bit of empty space, but I hope that you will deal with that in due course

Also, you may wish to update a screenshot for UDCs on the Product page of the main site as it shows those buttons.

Posted: **22 Mar 2011 23:01**

Code: Select all

v9.90.0515 - 2011-03-22 22:28
    * Manage User-Defined Commands Dialog: Re-added the buttons Apply
      and Reset to the Command Properties section. They had been removed
      in v8.80.0014 - 2010-01-09 16:12, but now I think it was a bad
      idea.

Over a year on and no complaints in the forum, so what is the reason the change of mind?

Posted: **23 Mar 2011 08:32**

zer0 wrote:
Code: Select all
v9.90.0515 - 2011-03-22 22:28
    * Manage User-Defined Commands Dialog: Re-added the buttons Apply
      and Reset to the Command Properties section. They had been removed
      in v8.80.0014 - 2010-01-09 16:12, but now I think it was a bad
      idea.
Over a year on and no complaints in the forum, so what is the reason the change of mind?

Yesterday I came back to actually using this interface and found it unintuitive.

XYplorer Beta Club

UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button

Re: UDC menu's Apply button