Compare Contents

[Marjolein Katsma]

Let me decide

I've been following this conversation with keen interest, hoping there would be a resolution. I am just as exasperated as you, Michael, seeing the program decide things for itself when - as far as I'm concerned - I've told it not to do such a thing, and only act when I tell it to: not on launching a dialog from a description with an ellipsis (meaning: needs user input before action can be started) but only on completing the dialog.

I am endlessly annoyed by the program doing things that I didn't ask for, in some cases consuming quite a bit of resources slowing down other programs doing things (that I did ask for).

I really don't see the problem in changing this behavior: if the user asks not to do any background comparisons, then don't! Seeing file and folder counts might be helpful in some cases, but they are not necessary for me to decide what type of comparison to do, and I'm certainly not expecting the program to decide to start a comparison before I've made that choice.

I realize I'm basically repeating your arguments, but that's because I agree 100%.

A program should not do what I haven't told it to do, and certainly not do what I have told it not to do.

If I had "Automatically scan subfolders in background" enabled in my session settings, then the current "preflight compare" could be considered appropriate. I was hoping, however, that you would agree to let an unchecked Automatically Scan Subfolders option be the deciding configuration that bypasses the "background compare" kicked off as a "side-effect" of the preflight scan. This would allow a user to override their default compare criteria, and start a compare with the overrided options.

Check.

Even if I select different compare settings, the default compare settings are already being used, so it negates the usefulness of this option.

Check.

I have only one wish: do not let the program decide things for itself, unless asked to do so by the user.

I find the current behavior always annoying, and in some cases (in a "fully loaded" machine) even destructive, because it cannot be overridden. The Automatically scan subfolders in background should be that override, and is formulated as a command - if it isn't interpreted that way, the option should be renamed to something like "automatically scan folders in the background unless I decide differently" or something along those lines.

[Michael Bulgrien]

And please dismiss my request for a toolbar button. I give up. Since the compare dialog will never be what I envisioned it could be...I might as well just drop in and out of session settings than insist on a less useful tweak. If you implement your idea of a Scan option when a default content compare is defined in the session settings, then I'll stop complaining and drop this tiresome debate.

[Michael Bulgrien]

Here's what I'd like to do to improve the situation and reduce confusion:

1. Remove the Compare Contents command
2. Add a Scan command (without ellipses or a dialog) for un-scanned folders

Tim,

I've been giving this more thought. It is obvious that we'll never see eye to eye on this. I had originally hoped that the compare contents dialog could be enhanced to perform any type of compare (even a quick compare) regardless of ones default session settings (a true override without any preflight compare activity to interfere with it). To be able to choose compare settings on-the-fly without altering one's session defaults would be a great feature! Much better than having to drop in and out of session settings and risk forgetting to restore your defaults after changing them for an on-the-fly compare. Although I still believe such a feature would be the most useful implementation, the idea was shot down because a "quick compare" is not considered to be a "content compare".

So I backed down from the "ideal" solution deciding that it would still be nice to be able to override default content compare criteria. If I had "Automatically scan subfolders in background" enabled in my session settings, then the current "preflight compare" could be considered appropriate. I was hoping, however, that you would agree to let an unchecked Automatically Scan Subfolders option be the deciding configuration that bypasses the "background compare" kicked off as a "side-effect" of the preflight scan. This would allow a user to override their default compare criteria, and start a compare with the overrided options.

It appears that you have no intention of even considering this request...not even as a post release enhancement (in a future 3.x version). Although it would be nice to be able to override compare settings from the context menu, truth is the "preflight" scan makes it impossible. Even if I select different compare settings, the default compare settings are already being used, so it negates the usefulness of this option. If you truly have no intention of implementing any of my ideas, then I would have to agree that your alternate design idea would be the best:

1) If the user has a compare contents method defined in their session settings, then provide a Scan option in the context menu to start the scan without a compare contents dialog. The toolbar compare button should also bypass the dialog.

2) If the user only has quick compare options set in their session settings, then provide the current Compare Contents option in the context menu and do not bypass the dialog when the toolbar button is used.

Although not what I consider the most ideal choice for your product, it would certainly be better than what we have today.

[Michael Bulgrien]

As long as I don't have to go in and out of session settings every time I want to toggle it. And as long as the settings are not lost when I close the session. The reason I'M asking for a toggle button is three-fold:

1) So that the default compare settings are not lost when the session is closed
2) So I can see at a glance whether I'm using Quick Tests or Content Compares
3) So I can toggle it on the fly without editing the session settings (since I will be using it heavily)

[Tim]

Now that we've moved Size Alone out of the compare contents section, you can toggle the Compare Contents checkbox to get exactly that behavior (unless you are comparing versions also). Does that help?

[Tim]

A scan is necessary to get the file/folder counts. The background content comparison is a side effect of the scan.

[Michael Bulgrien]

It allows is to display the file/folder counts in the operation dialog.

I've mentioned this before too. A content compare is not necessary to get file/folder counts.

[Michael Bulgrien]

I've suggested it before. Provide a toolbar button that lets a user toggle (temporarily disable) background content compares without modifying the default session settings, and that I'll be a happy camper.
This is what it might look like behind the scenes (in Session Settings):



Whether it is a single checkbox or two option buttons doesn't really matter.
What matters is being able to disable content compares without losing the configuration.

[Tim]

Just delay the "preflight scan" until after the user initiates the activity.

Then it wouldn't be a preflight, would it? The scan of unprocessed folders identifies exactly what will be acted upon by the command, before the user commits to it. It allows is to display the file/folder counts in the operation dialog.

[Michael Bulgrien]

Any command's preflight phase will invoke the background content comparison if it affects un-scanned folders.

That is precisely my point. It shouldn't when no activity has been initiated. The dialog box is not an issued command. A user can cancel the dialog. Clicking the "Start" button is the issued command. That is where the "preflight phase" should kick in.

If you don't want things to run in the background, independent of whether or not a foreground command has ellipses or is canceled, then please don't configure BC to do so.

Tim, I am comparing files that require content checking. It would not make sense to disable it. I just don't want Cirrus initiating things in the background before I've instructed it to do any activity.

Here's what I'd like to do to improve the situation and reduce confusion:

1. Remove the Compare Contents command
2. Add a Scan command (without ellipses or a dialog) for un-scanned folders

Why would you remove a dialog that allows a user to over-ride their content compare settings? Getting rid of something good in order to remove unnecessary confusion is a poor reason to do so. Just delay the "preflight scan" until after the user initiates the activity.

[Tim]

Michael,

There are two compare contents functions: The automatic background content comparison that you can configure in rules, and the explicit Compare Contents command.

What the Compare Contents command does or doesn't do is not the issue. Any command's preflight phase will invoke the background content comparison if it affects un-scanned folders. You could just as well complain that the Copy command, when canceled, continues to compare contents in the background.

If you don't want things to run in the background, independent of whether or not a foreground command has ellipses or is canceled, then please don't configure BC to do so.

Here's what I'd like to do to improve the situation and reduce confusion:

1. Remove the Compare Contents command
2. Add a Scan command (without ellipses or a dialog) for un-scanned folders

[Michael Bulgrien]

This problem is still occurring (both with a right-click Compare Contents from the context menu, and from a Compare Contents triggered from the toolbar).

Quoting industry standards:

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (...). The ellipsis provides a visual cue that the command requires additional information.

Label a button Cancel if canceling returns the environment to its previous state (leaving no side effect)

Since a content compare starts without the "Compare Contents" dialog returning additional information, the "ellipsis" is improperly used.

And since cancelling the dialog does not leave the environment in its previous state, the "Cancel" button is improperly used.

Please do not start the compare until the user clicks "Start"

[Tim]

Sorry for all the confusion. I hope this helps:

A "scan" is not synonymous with background content comparison. A scan visits folders recursively, building out our comparison tree structure. The "Automatically scan subfolders in background" option merely causes folders to be visited automatically when a session is loaded.

When you define content comparison in the comparison criteria, a background content comparison is queued whenever a folder is first visited. This is a low-level side effect of visiting a folder, whether it’s during a scan or when the user opens a folder.

To answer your questions:

1. Why does compare start before user selects an option in the "Compare Contents" dialog.

Because the folders were scanned in preparation for the explicit Compare Contents command, and your comparison criteria have instructed BC to do a content comparison whenever folders are visited.

2. What method of compare is being used since dialog did not wait for user to select one?

The method which you defined in the folder comparison’s rules dialog.

3. Why does the compare continue when the user cancels the dialog?

Because you cancelled the explicit Compare Contents command but not the background content comparison.

Clearly, you are using features available to you and the resulting behavior is confusing. I agree with you on that. We are studying the whole comparison criteria environment and have some ideas on how to clarify actions and enhance performance. Please give us some time to develop these ideas – I expect we’ll have some improvement in the next release or two.

[Michael Bulgrien]

Wow, this is really frustrating. We don't usually have such a difficult time communicating. Your questions clearly indicate that you do not understand what I am describing, or you would not be asking these questions. I must not be communicating clearly enough. Please bear with me as I answer your questions and try again.

If BC is already doing a background content comparison and you tell it to also do a foreground comparison you're probably doing something wrong.

Cirrus is NOT already doing a background content comparison.
I have "Automatically scan subfolders in background" disabled.

The background content comparison begins the moment I launch the Compare Contents dialog from the context menu...but before I have a chance to accept or override my default compare settings and click on the "Start" button.

Further explanation: I disabled/unchecked the "Automatically scan subfolders in background" option because I often work with large remote folder trees for which a background content scan of the entire tree saps my system resources for long periods of time. There is no reason to perform an automatic background scan on the entire tree structure of the base folder if I am only going to be working with a subset of its subfolders (and their subtrees).

The background content comparison runs automatically whenever a folder is visited or a file is changed. That's it's entire reason for being. If you don't want it to do that why are you turning it on?

The folder has NOT been visited. It remains collapsed (was never expanded).
The contents of the folder have NOT changed. No activity has been manually initiated against the folder.

By your own definition, the reason for the automatic execution of a background content comparison has not been met.

According to industry standards, the "..." at the end of a menu option indicates that a dialog will be launched from which the specified menu option can be executed or completed. For example:

Right-clicking a folder pair and Choosing "Rename..." does not start a background scan. It opens a dialog.
Right-clicking a folder pair and Choosing "Attributes..." does not start a background scan. It opens a dialog.
Right-clicking a folder pair and Choosing "Touch..." does not start a background scan. It opens a dialog.

However:

Right-clicking a folder pair and Choosing "Delete..." does start a content compare when it opens the dialog.
Right-clicking a folder pair and Choosing "Compare Contents..." does start a content compare when it opens the dialog.

These last two are the exceptions. From a purely technical perspective, I understand that Cirrus has scanned the folders in order to perform a file and folder count...but, from the user's perspective, no activity has been initiated. I have not accessed the folder or changed it's contents because I have not yet completed the dialog to execute the functionality behind the menu option. If I choose to Cancel the "Delete" option or to Cancel the the "Compare Contents" option then, from the user's perspective, the state of my folder session should not have changed because I did not initiate any activity against the selected folder pair.

I do think that there are rare circumstances where doing both can help

Wanting to override the default compare settings for a specific subfolder is not a rare circumstance. It is a perfectly normal and potentially frequent activity.

between your post and some internal discussions I now think the confusion and complications outweigh those cases.

The confusion comes from Cirrus triggering a background compare when the user has not performed any activity against the folder or its contents. Period. It is that simple. All you need to do is prevent the background compare from executing when the dialog is opened and the confusion is gone.

I think the way to simplify things is to just not offer it if background content comparisons are active.

That will in no way simplify things.

If you disable the "Compare Contents" menu option when a user has a default compare method defined, then there will be no way for a user to manually initiate a compare of the contents of a collapsed folder pair other than to open it.

If you disable the ability to specify a default compare method when the user has the "Automatically scan subfolders in background" option unchecked, then there is no way for the user to have folder content compared when a folder is opened or its content changed without forcing the user to always have to endure or cancel automatic scans of huge collapsed folder trees.

And, likewise, if you disable the ability to uncheck the "Automatically scan subfolders in background" option when a user has a default compare method defined, then there is no way for the user to prevent unwanted resource intensive background compares from happening automatically on folders that have not been touched, and yet have touched folders and files compared automatically with a default compare method.

I don't understand why you keep complicating this issue unecessarily. Simply launching a dialog should not trigger activity that effects a visual change to the User Interface unless the user completes the dialog. That is application development 101. Just because a file/folder count has been made for the dialog doesn't mean that the content of the folder pair should be compared and the colors of the folder pair updated to reflect the results.

[Zoë]

Michael,

Pardon me for being blunt, but if BC is already doing a background content comparison and you tell it to also do a foreground comparison you're probably doing something wrong.

The background content comparison runs automatically whenever a folder is visited or a file is changed. That's it's entire reason for being. If you don't want it to do that why are you turning it on?

I do think that there are rare circumstances where doing both can help, but between your post and some internal discussions I now think the confusion and complications outweigh those cases. The "Compare Contents" action isn't as necessary as it was in BC2, so I think the way to simplify things is to just not offer it if background content comparisons are active.