453 Right's Move moves from left

[chrisjj]

EDIT: If with both sides selected I right-click on the right side and select "Move To Other Side...", BC offers move Left to Right!

[Tim]

That's correct. With both sides selected, we consider it an ambiguous selection and prompt for the direction (consistently initialized as a left to right move). In my view, the context associated with right-clicking a selection is the entire selection, regardless of where the mouse is positioned.

[Michael Bulgrien]

I, too, have brought this up in the past.
I, too, would prefer that the direction be initialized based on the side that is clicked on.

[chrisjj]

[EDITed]

With both sides selected, we consider it an ambiguous selection and prompt for the direction (consistently initialized as a left to right move). In my view, the context associated with right-clicking a selection is the entire selection, regardless of where the mouse is positioned.

I can't see the advantage of ignoring the full click context and instead making the arbitrary choice of Left>Right. Would you please refer this to the team? Thanks.

[Tim]

The "team" is welcome to chime in.

We are not ignoring context: The actionable context is the entire selection. You're suggesting that a secondary context influence the dialog. That's fine as a minor convenience feature, but I do not accept that the current behavior is wrong. We'll add it to the wishlist if it's not already there.

[Michael Bulgrien]

We are not ignoring context: The actionable context is the entire selection. You're suggesting that a secondary context influence the dialog.

I often find myself selecting both sides (clicking in the center) because in the back of my mind, the operation will be done with that file (or folder) pair. It is not a conscious decision. It is the way my mind works...narrowing down the context as I go rather than stopping long enough to force myself to think through the exact steps that I must do to get the results I want the first time. Either way, it wastes time and productivity.

• If I stop and think it through before selecting only one side, then I've wasted a second before initiating the functionality.
  
• If I do what comes naturally to me (clicking in the center and setting the primary context first) then I have to take the time to notice that secondary context did not get set automatically and make a correction to it before continuing with the desired functionality.
  
• If I am working too quickly and happen to miss that the direction was not set appropriately based on side of my right-click, then it also increases the risk of mistakes (the fuctionality occuring in the opposite direction than desired.)

I've stressed before that people do not all follow the same train of thought It is that left-brained/right-brained thing. I don't understand why something like this would receive so much resistance when it will make the product more flexible and make it feel more natural to a broader base of users. It annoys me when the selection does not default in the way that it feels like it should...and frankly, if it were my product, I would consider removal of such annoyances to my user base as more than an implementation of a "minor convenience".

It seems like a little thing to you because testing a product in a slow, methodical manner produces the types of arguments used by the Scooter team in this thread...yes, the ability to change the direction of the pending operation is still there, so from a strictly functional perspective, the user has not reached a dead end and can continue on...

From a practical perspective, when a user is working quickly with many files in rapid succession, such arguments grow weak. If easily avoidable, any functionality that causes a user to stumble and have to re-assess what they are doing, or how they are doing it, leaves a hint of frustration in the experience. The more often it happens, the more annoyed or frustrated a user will get.

[Tim]

Please don't blow this out of proportion. I'm merely saying the current behavior is not a bug, and that we'll consider enhancing it when we have time.

[RunnerBiker]

I don't use the "RightClick => Move", I have redefined the Move-Left and Move-Right keyboard commands by assigning Ctrl+L and Ctrl+R in the Tools => Customize Commands menu.

These Customized keyboard commands are not ambiguous.

One other thought about the Move Left-Right.

The file that is deleted does not go into the recycle bin, even though the "Use recycle bin if possible" option is selected in the Delete control screen. So I don't move one file over the other. I delete the obsolete file first and then move the correct one second.

Michael - When you were talking about left brain, right brain, think about this:

Two files are highlighted. One on the left and one on the right. Press the delete key. The Delete Dialog box pops up. To delete the left side file you need to unselect the right side file. In my (feeble little brain) I have learned that I need to press the "R" key to delete the file on the left and the "L" key to delete the file on the right, and the method I used is to associate the key positions on the keyboard with the file's position on the screen. I'm afraid I haven't made this clear yet.

I have two keys to choose from (R/L) and I associate their position on the keyboard with the file that is going to be deleted. The "R" key is on the left side of the keyboard, so pressing "R" will cause the left side file to be deleted. The "L" key is on the right side of the keyboard, so pressing the "L" key will cause the right side file to be deleted. For this command, I have disassociated "R" and "L" from meaning right and left, and learned that I have to choose between these two keys and to delete the file on the left, I must choose the key on the left, which happens to be the "R". Simple huh?

An example:
With two files highlighted and I want to move the right side file to the left, I key:

Del R Ctrl+L

[markf_2748]

I have two keys to choose from (R/L) and I associate their position on the keyboard with the file that is going to be deleted. The "R" key is on the left side of the keyboard, so pressing "R" will cause the left side file to be deleted. The "L" key is on the right side of the keyboard, so pressing the "L" key will cause the right side file to be deleted. For this command, I have disassociated "R" and "L" from meaning right and left, and learned that I have to choose between these two keys and to delete the file on the left, I must choose the key on the left, which happens to be the "R". Simple huh?

To each his/her own: Some of us use the Dvorak layout, in which case both L and R keys are on the right side of the keyboard!

[penguin22]

I know it's never desirable to go off thread topic, but as this thread has taken an extra path anyway...

One of those time saving features that I yearn for, which was brought up in a separate thread, is to be able to highlight a file/folder and then click in the text to open the rename function... I do this extremely often with versioning and having to select, right click, move mouse down to rename and then move mouse back to the selected text to adjust the part I want changed vs. clicking to highlight, click to rename, hold click select the part to be renamed...

There is no better tool in my arsenal than BC and BC3 is a huge improvement over BC2, but is there a better forum/sounding board to have some of these suggestions better heard and or understood/implemented?

[markf_2748]

One of those time saving features that I yearn for is to be able to highlight a file/folder and then click in the text to open the rename function...

I second the motion - thanks for bringing it up. Several times a day I click rename in BC Folder Compare view to solect a filename and then 1) actually rename it or 2) immediately copy (CTRL c) and paste (CTRL v) it elsewhere. It's also handy for renaming both sides or even editing parts of several filenames all in one shot.

I'm happy to see Left Click select/edit functionality in the new Home Folder Tree; it just needs to be extended to the Folder Compare view, at least for single name select/edits. The simultaneous multiple name edit may still require the current Rename menu methodolgy.

[RunnerBiker]

The F2 key opens the rename dialog.

Since you are going to the keyboard to rename or copy/paste with Ctrl+C/Ctrl+V its fairly easy to hit F2 to do what you want.

[chrisjj]

> We are not ignoring context: The actionable context is the entire selection.
> You're suggesting that a secondary context influence the dialog.

That is indeed the ignored context I'm referring to.

> We'll add it to the wishlist if it's not already there.

Thanks.

[chrisjj]

to delete the file on the left, I must choose the key on the left, which happens to be the "R". Simple huh

Not to mention how one handles this in the over-under view...

[markf_2748]

The F2 key opens the rename dialog.

Since you are going to the keyboard to rename or copy/paste with Ctrl+C/Ctrl+V its fairly easy to hit F2 to do what you want.

True, thanks for the reminder - I sometimes do just that, and F2 has the intelligence to recognize whether you are editing a single name (no dialog box) or multiple names (dialog box needed). Mostly its a matter of habit though - the Left Click to select/edit a name is so pervasive in the Windows world (for example in Windows Explorer) that one expects it to work here as well, at least for the simple one-name case. [Note that in some Windows apps, this functionality is provided by Right Double Click (for example within Excel cells), but Right Double Click from Folder Compare is already pretty well established for opening File Compare in BC.]