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". :confused: 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". :confused: 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". :confused: 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.]

[Aaron]

Hello Michael,

It certainly is something to consider. The first thing I think of, though, is all of the users who are confused over our Find Left, or Find Left/Right Dialog. Some people may wonder why when they right click on an overall selection why it (appears to) arbitrarily choose left or right for them. I, personally, lean a bit more towards "it should behave differently", but I am undecided as to how.

It is also a matter of time and scheduling it. Even though it appears trivial, we'll still want to QA the process to make sure we don't introduce any odd behavior.

[Michael Bulgrien]

The first thing I think of, though, is all of the users who are confused over our Find Left, or Find Left/Right Dialog.

The confusion in the Find dialog could easily be reduced as demonstrated in this post (http://www.scootersoftware.com/cirrus/vbulletin/showthread.php?t=150). Label the option as Current (with "Left" or "Right" in parentheses) and it becomes self-explanatory (see screenshot (http://mysite.verizon.net/bulgrien/images/FindDialog.png)).
This could easily be implemented even without the rest of my sticky search enhancement request.

[Michael Bulgrien]

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

Since I ran into this again today, I'll share my experience. In my opinion, the actionable context is incorrect because because Ctrl+A does not remain confined to the side that has focus. I've mentioned before that I would prefer Ctrl+A to set the context:

Click in left pane, Ctrl+A selects All in left pane only
Click in right pane, Ctrl+A selects All in right pane only
Click in center column between panes, Ctrl+A selects All on both sides
If Ctrl+A worked in this way, I would rarely run into the situation where I am trying to copy from one side to the other with both sides selected. Since Ctrl+A always selects everything on both sides, BC3 has already failed to set the actionable context on my first attempt.

When I open the context menu from the right side to initialize the copy files direction to be right to left, BC3 fails to update the actionable context a second time. This is why the current functionality is doubly frustrating to me. I've already attempted to set the context twice, and am forced to take yet one more step to correct the situation.

[Tim]

I prefer to keep it like this:

Ctrl+A selects all
Ctrl+A, Shift+Left Arrow selects left side
Ctrl+A, Shift+Right Arrow selects right side

[RunnerBiker]

I prefer to keep it like this:

Ctrl+A selects all
Ctrl+A, Shift+Left Arrow selects left side
Ctrl+A, Shift+Right Arrow selects right side

Cool, I didn't know about the Shift+Left Arrow and Shift+ Right Arrow. I guess I need to spend some more time reading the help files.

[Michael Bulgrien]

I prefer to keep it like this:

Ctrl+A selects all
Ctrl+A, Shift+Left Arrow selects left side
Ctrl+A, Shift+Right Arrow selects right side

Yes, I know you do. That is why it would be nice if more priority were given to letting the side of the right-click initialize the direction of a file copy... for those of us who do not prefer the BC3 implementation of Ctrl+A. It forces me to do extra keypresses for every file copy, keypresses that would be unnecessary with the implementation of the enhancement request in this thread.

[Michael Bulgrien]

By the way, a wishlist item I would have is for a Tweak to change the Ctrl+A functionality.

[markf_2748]

I prefer to keep it like this:

Ctrl+A selects all
Ctrl+A, Shift+Left Arrow selects left side
Ctrl+A, Shift+Right Arrow selects right side

I don't have a problem with this trick. Once you have made a selection, use of the arrow keys can be very handy and is perferctly logical. But here are two other suggestions that I would find just a little easier (more direct) at times. They are compatible with each other as well as with current behavior:

Suggestion 1:
Select anything on left side. Then <Shift> <Select All> selects everything visible on the left side.
Select anything on right side. Then <Shift> <Select All> selects everything visible on the right side.

Suggestion 2:
<Control><Select All> selects everything visible on left, no matter what the current selection.
<Alt><Select All> selects everything visible on right, no matter what the current selection.

Analagous behavior for <Select All Files>.
A consistent set of keyboard shortcuts would require some thought.

:)