Total Commander

Roman:

Take the example of a population of image files (jpgs, for instance) which are pictures. The task is to move the pictures that contain images of red cars to another folder.

The keyboard effort for selecting the red cars is costly. If one assumes that 1 keystroke is necessary for navigation between files (for marking purposes), and an addition 1 keystroke is needed to actually mark a red car file once navigation completes, then the average cost for using the keyboard for this task scales upward to a limit of O(0.5*2*n) keystrokes, where n is the population of files in the selection domain and assuming one starts at the beginning.

If a meaningful ordering can be performed on the domain of files (exactly your examples, for instance) and/or a meaningful routinized subselection (such as a filter) can be applied to the domain BEFORE the selection activity, then hotkey combinations can be substituted for long sequences of keystrokes. This is where the keyboard shines, because in some cases keyboard selection can scale downward to O(1), the "select all" hotkey.

The efficiency of a keyboard for selecting from a domain of files is proportional to the homology between the domain ordering paradigm and the selection criteria. This is because keyboard selection is essentially sequential in action (one key after another), and benefits substantially from any meaningful sequencing of the files. But keep in mind that the sequencing/subsetting activities themselves (needed to make the hotkeys useful) consume time and keystrokes. Quite a bit of borrowing from Peter to pay Paul, as the saying goes, to "purchase" that keyboard efficiency.

But suppose you cannot use the filename, or file size, or date-time value (or what have you) to order or subset the domain, ie., when the criteria ("red car in image") cannot be expressed routinely. In that case, hotkeys will have no efficiency because no useful ordering or subsetting can precede the selection activity.

If one cannot routinize either sequencing or subsetting of a domain of files, then the selection marque is a more efficient selection mechanism than a keyboard. Consider (in thumbnail mode) that sometimes files showing red cars may occupy adjacent positions in the TC file panel.

Now do you see how (mouse vs. keyboard selection) and (rectangle selection vs. linear) are related?

But suppose you cannot use the filename, or file size, or date-time value (or what have you) to order or subset the domain, ie., when the criteria ("red car in image") cannot be expressed routinely. In that case, hotkeys will have no efficiency because no useful ordering or subsetting can precede the selection activity.

And how will a rectangle help in here?

And how will a rectangle help in here?

Hard to describe verbally.

The selection marque/rectangle allows the user to be less accurate in mouse movement. The reduced requirement for accuracy means that the user can move the mouse faster. The end result is faster selection of contiguous files, in any rectilinear direction, but most especially in thumbnail mode.

When using the mouse to select files, I keep one hand hovered over the [Shift] and [CTRL] keys, the other hand on the mouse. Instead of many short abrupt movements (ie. keyboard), selection becomes a series of fewer, simple, fluid motions of my hand across the desk.

The selection marque is even more useful when I use my pen tablet.

Try the selection marque in Salamander or SpeedCommander. I mean try it on some real work, not just play around with it.

Some of you may like it.

If someone requests a true Explorer selection mode that's ok but let me also lists some disadvantages of this approach. The user always has to start the selection outside the filename and move it somewhere over a filename. In addition he has to move the cursor to the very left of the column to ensure all shorter filenames are included in the selection. This procedure must be repeated for every single part of not connected selections. This really requires a very high accurary in mouse movement.
There is also another difference to the classic selection mode. The rectangle always inverts the current selection while in classic mode one action either selects or deselects items depending on the selection state of the first item in the current selection action. In my opinion it doesn't make sense to simply invert the existing selection (only if you really want to invert the whole selection but in this case a special command is better). In case you just want to deselect some not connected items if some items which you never wanted to select are between two parts which you want to deselect these items are selected. The only alternative is to make two rectangles.
The next point is that starting a drag action and selecting are on the same mouse button. You have to be very careful not to start a drag action if you want to select some items. Both actions are just separated by their mouse position. This can be just a few pixels. Again this requires more accuracy. In classic selection mode left mouse button is for starting the drag action and right mouse button is for selecting.
My last point is that Explorer selection mode is just volatile. Clicking somewhere without pressing Ctrl on the keyboard will kill my selection. In classic selection mode I can select some files, interrupt the process and select some more later. That's a really tolerant behavior.

Hi Lefteous

You are describing consequences of TC's private, characteristic behaviors. Obviously, marque selection would require some modification of that behavior. For instance, TC's intrinsic file selection order (sequential left-to-right, top-to-bottom) would have to be abandoned for thumbnail mode in order to accomodate selections of files in vertical columns via one continuous mouse movement (here is a Salamander example). This is a non-trivial programming effort to apply to a naked list box.

Considering the legacy nature of TC file panels, I have zero hope for this ever occurring (I've learned a lot over the years here in the forum). Too much trouble to implement and I am not even requesting it. There are many modern interface paradigms that are just too costly to program from scratch. They will never be available in TC. What's Mr. Ghisler's incentive, after all? Leave it to the hungry guys.

Perhaps a step in a compromise direction would be for TC to allow a grid of thumbs sorted down the panel by one metadata value (such as size) and across the panel by another value (such as extension), with row or column selection functionality enabled. That certainly doesn't address my "red car" example, but would be a useful improvement to TC, nevertheless.

That won't happen either, it's too development-resource intensive. (I don't argue with that, though, Unicode certainly is the more strategic area into which to devote resources.) Besides, nowadays we use grid/spreadsheet/datasheet controls for that sort of thing.

@Hacker:
Yep, it has to be contructed like that, you are right.

Icfu

2JohnFredC

You are describing consequences of TC's private, characteristic behaviors.

What I describe is nothing TC invented. It's the same behavior as in many other DOS file managers.

This is a non-trivial programming effort to apply to a naked list box.

The classic selection mode, the trees and especially the thumbnail view mode are so far away from standard listboxes. It's absolutely no problem to add selecting items as if a rectangle would be used in thumbnail mode. The only challange is to draw the selection rectangle itself.

The question of my previous post was not if this is feasible but if it makes sense. For me Explorer selection mode really has some disadvantages.

Some final words about selection in thumbnail view. Explorer offers both continous (by using the shift button) and non-continous selections (using the rectangle). This is fine as both make sense.
TC only support continous selections. This is really strange for me as before thumbnail mode was introduced I thought the rule is only these items get selected where I'm moving over with the mouse cursor. Since TC 6.5 I had to drop this mental model as it's really just continous. In my opinion this should be reconsidered and of course a rectangle would be a great visual help.

JohnFredC,

Now do you see how (mouse vs. keyboard selection) and (rectangle selection vs. linear) are related?

No, sorry, I still don't get it.

Consider (in thumbnail mode) that sometimes files showing red cars may occupy adjacent positions in the TC file panel.

Adjacent = linear, right? Perhaps you could provide some (fake) screenshot or video or something that would show at least one plausible scenario in which files are arranged in a rectangle or would otherwise benefit from rectangle selection.

Roman

I apologize in advance to the entire forum for the length of this post, probably my last on this topic, as well as for the lengths of most of my posts in this thread.

Hacker wrote:Adjacent = linear, right?

Right. Exactly. Linear selection techniques benefit to the extent that the objects to select are adjacent to each other. One mode of a selection rectangle is linear (1 dimensional). But it also has what I call Cartesian mode (2 dimensional).

EXAMPLE 1

Here is an "almost" best case example that demonstrates linear mode with the selection rectangle. Task is to select the red car images. Assume these are not the real file names, so sorting on filename does not group the red car images. There is one selection group. The panel cursor is on pic01.

- With a rectangular marque, the cost to make the selection is two mouse moves. Selection cost is therefore 2 user actions.

1. Position mouse near REDCAR1
2. Drag rectangle to REDCAR4

The selection rectangle method clearly benefits from the adjacency (in this case linear adjacency) of the desired files.

What would be the cost of an efficient keyboard selection strategy for this example?

EXAMPLE 2

Here is another "almost" best case example that demonstrates Cartesian mode with the selection rectangle. Same rules. This time there are 2 linear selection groups (2 rows) but only 1 selection group for a rectangular selection marque. The panel cursor is on pic01.

- With a rectangular marque, the cost to make the selection is 2 mouse moves. Selection cost is 2 user actions.

1. Position mouse near REDCAR1
2. Drag rectangle to REDCAR4

There are 3 other marque strategies that have the same cost (2) as Example 1.

What would be the cost of an efficient keyboard selection strategy for this example? Since there are 2 linear groups (first row, second row) an approximate cost for using the keyboard in Example 2 is 2x as expensive as in Example 1, which had only 1 linear group.

EXAMPLE 3

Here is an example with some random grouping. Same assumptions. There are three marque selection groups but 5 linear selection groups. The panel cursor is still on pic01.

- With a rectangular marque, the cost to make the selection is five mouse moves and 1 mouse pick (plus two modifier keys). Call it a selection cost of 8 user actions.

1. Position mouse near REDCAR1
2. Drag rectangle to REDCAR2
3. Position mouse near REDCAR3
4. Hold modifier key (ctrl)
5. Drag rectangle to REDCAR5
6. Position mouse near REDCAR6
7. Hold modifier key (ctrl)
8. Click

Most mousers can casually perform this entire sequence (using the rectangular marque) in 3-4 seconds.

And the keyboard cost in this example? The most efficient strategy must be discovered, so the total cost is the sum of the selection cost plus the discovery cost. Most users will settle for just getting it over with and likely will not choose the most efficient method. Even if a minimum cost strategy has been discovered, it will be more expensive (in key strokes and time) than using the selection marque.

SUMMARY

It is possible to tally the selection cost of any combination of selection requirement and selection method. As adjacency of "elements to be selected" declines, the efficacy of all selection methods also declines, ie. the user interaction cost increases. But the cost increases more slowly for the selection rectangle since it has 2 degrees of freedom compared to the linear (such as keyboard) method's 1 degree of freedom.

The average selection cost for the rectangle method is approximately 2 user actions for each rectangular selection group, that is: O(2*g) where g is the number of rectangular groups. (An additional cost factor related to how much file panel scrolling is required should also be added.)

The average cost of linear selection methods (such as using the keyboard) scales to approximately O(0.5*2*n). See my previous post, above.

As n (number of files in the domain) increases...

and since g < n

it follows that:

O(2*g) < O(0.5*2*n)

... proving that the selection marque/rectangle method has a lower user interaction cost than a purely linear selection method such as keyboard iteration through the files.

This topic is rooted in topology and graph theory, both of which disciplines employ specialized notation to express the matters we are discussing.

Tired, now. No more for me. I'm not quite this boring in person, but almost.

A rectangle can be used as a linear selection tool and is as efficient as just dragging over each single item* in case the items to be selected don't include rectangular areas as in JohnFredCs example 3.
In case the items to be selected are ordered in a rectangular area it's more efficient as you can start dragging at the top left item and draw a rectangle to the bottom right.

* The only difference is that using a rectangle normally includes releasing the mouse button before starting a new rectangle while a linear selection only needs to be released if there is a gap between two selection parts. Such a linear selection doesn't exist currently in TC.

JohnFredC,
Like Lefteous says, the only example you gave that would benefit from a rectangular selection (compared to linear selection) is example #2. I still insist on such a grouping being highly improbable.

And I am still talking about mouse selection only (linear - move mouse cursor over all the items that are to be selected vs. rectangle - move mouse cursor in a diagonal to define a rectangle above items to be selected), I do not understand what the keyboard has to do with that, I am sorry.

Roman

2Hacker

Like Lefteous says, the only example you gave that would benefit from a rectangular selection (compared to linear selection) is example #2.

I never wrote that.

I still insist on such a grouping being highly improbable.

I'm not so sure about that.

Beside that I guess using a rectangle to select full rows of items is more transparent than the current approach to automatically include all items between the first and the last selected item while holding down the mouse.

This statement also applies to example 3 but in this case my "drawing lines" suggestion would also help. The current approach really fails in such cases and I hope you agree that this is really a realistic scenario.

Lefteous,

I never wrote that.

I misunderstood you then, sorry.

Roman

JohnFredC
My question is: do you know that in TC you can select continuously files (linear selection as Roman calls it) by right-clicking and dragging?
You keep mentioning the selection by keyboard in TC, but that's comparing apples to oranges.

In my experience TC's mouse selection is better than the rectangular one.
This might be a personal preference, but in general I think both have advantages and disadvantages.
For me the rectangular one feels to have more disadvantages than advantages, so I don't miss it at all in TC.

The most efficient selection depends on the amount needed to be selected.
If the number of files is very big for instance, the best way is neither keyboard nor mouse, neither rectangular nor linear, but rather such handy TC features like select all with same extension or custom selection based on different attributes.

Ough, I spoke.

Hi szlori

I am aware of (and sometimes use) the NC selection mode. But it is a linear selection mode that requires the mouse to traverse every node (:file) to be selected. This is fine for details mode, but not (at least as it is currently implemented in TC) for thumbnail mode. See Lefteous' posts, above.