In the menu hierarchy tree of file managers such as Windows Explorer, why are redundant behaviors of "expand" "collapse" folders given in context menu when the user can anyways click the + or - icon beside the folder to expand or collapse it? See the icon and menu item outlined in yellow below:
What is the UX benefit of such redundancy?
According to Jef Raskin at his book The Humane Interface, designers use the following justifications, when they decide to use many ways to perform the same action :
One justification for having multiple methods to do a given task is that some users prefer one method and other users prefer a different method. For example, a novice user might find menus easier to learn, although an expert user might rather keep her hands on the keyboard and issue commands by typing them.
Another justification is that one method -- for example, selecting, cutting, and pasting -- is useful between distant portions of a document, and the other method -- selecting and dragging -- is effective only when the source and destination are both visible on the display.
Another reason for a plurality of methods is that each of them is sanctioned by custom, and the developers felt it wise to accommodate as many previously developed skills as possible.
backward compatibility
The author is against this strategy. He believes providing only one way to accomplish a task (monotony), makes the interface easier to learn and use.
When you have to choose among methods, your locus of attention is drawn from the task and temporarily becomes the decision itself. This is a primary reason for choosing to design a monotonous system. If the conditions for making the decision are sufficiently clear and distinct, the path you take in each case can become habitual, and you have monotonized the situation. It still behooves the designer to seek an efficient monotonous solution to gain benefits, including ease of learning, simplicity of implementation, minimization of documentation, and lowered maintenance costs. ... If I am correct, the use of a product based on modelessness and monotony would soon become so habitual as to be nearly addictive, leading to a user population devoted to and loyal to the product. Its users would find moving to a competitor's product psychologically difficult.
I tend to agree with the author, in most cases his approach is much better.
It’s a Historical Leftover
Speaking specifically about the Windows File Manager, the answer is in the history of its UI. Look at screenshots of the older Windows file manager, and you’ll see there are no +/- icons.
Instead, there was a pulldown menu command (in the Tree menu, I think) to expand/collapse. Double-clicking and later the context menu were included as expert shortcuts (“expert,” because they were easier to use than the pulldown menu, but harder to discover, at least in theory).
At some point (maybe Windows 95?), Microsoft decided that expand/collapse was too important and frequently used to be buried in menu or hidden in a secret gesture like double-clicking. Thus, it added the +/- icons. However it kept the double-clicking/context menu UI presumably for users that were used to it. So the two means to expand/collapse are to accommodate different user habits or skills (Raskin Bullet 3 in DesignerAnalyst’s answer).
Other Factors?
Another possible factor is Microsoft wanted to keep the behavior of the folder icon in the tree consistent with the folder icons in the detail pane. There, double-clicking a folder shows the contents of the folder in the same pane. Since you don’t want the user having to make fine distinctions on what folder icon where will respond how to double-click, you try to make them the same as possible. Sometimes you have two different ways to do the same command in order for one of the ways to be internally consistent, i.e., consistent with something else in the UI.
According to Microsoft’s UX guidelines, if double-click does something, then the same command must be in the context menu (in bold, at the top), so, given there were a couple reasons to to keep double-clicking for expand/collapse, Microsoft was compelled to have the command in the context menu too to be externally consistent with other Windows UIs.
It’s generally a good practice to have a text equivalent for any command executed with an icon because icons can be inscrutable labels. So, maybe Microsoft kept the context menu item to have a text equivalent. In other words, sometimes you have different ways to do the same command to accommodate different user expertise (Raskin Bullet 1 in DesignerAnalyst’s answer). However, IMHO, I’d expect that users who understand an expert feature like context menus would also understand a standard and reasonably intuitive icon like +/- for expand/collapse.
Accessibility is another reason for redundant means of executing a command, but I don’t think it played a role in this case.
Organic Development
Perhaps at the same time that Microsoft added the +/- icons, it dropped the expand/collapse command from the pulldown menu, and, eventually, hid the entire menu bar by default. Now the menu bar is the place of expert commands, accessible only with the secret Alt key. Not an entirely satisfactory solution, but that’s how it evolved.
Complex UIs, especially over multiple versions, tend to drift from their original coherent vision due to lots of little easy decisions that seem reasonable in their own context but can morph the UI into something weird in aggregate.
Alan Cooper, in his classic interface design book, About Face, speaks directly to this question.
He points out, as you have, that there are multiple distinct techniques for issuing instructions to a program. He terms these, collectively, "command vectors." Menus are one type of command vector, as are toolbar "buttcons" (his term for toolbar buttons labeled with only an icon), drag-and-drop, and keyboard shortcuts (among others).
I call each distinct technique for issuing instructions to the program a command vector. Menus are a command vector, as are direct manipulation and toolbar buttcons. Good user interfaces will conscientiously provide what I call multiple command vectors, where each function in the program has menu commands, toolbar commands, keyboard commands, and direct-manipulation commands, each with the parallel ability to invoke a given command. This enables users of different skill sets and preferences to command the program according to their desires and abilities.
He argues that the primary purpose of menus is to serve as a pedagogic vector. In other words, they serve a teaching role because they are clearly labeled, explanatory, and present a catalog of all of the available options. Menus are also "safe," because users can easily browse all of the available options without actually invoking any of them. Finally, it is common for menus to display, in addition to a description of the command, the associated keyboard shortcut (if applicable). New users can easily ignore this information when learning the software for the first time, but as they begin to become more advanced, they will gradually discover it and begin to make use of it. Sure, this information could be buried in documentation somewhere, but that makes it harder to find and much less likely that anyone will ever read it. Taken together, all of these are compelling reasons why at least one of the command vectors must be a menu option.
But then, Cooper also points out that menus have a cost: they are slow and cumbersome to use for power users (or anyone who uses a particular piece of software frequently, becoming a sort of micro-expert with that software, even if they are not overall power-users when it comes to computers).
This is where the other types of command vector idioms come in, like toolbar buttons and direct-manipulation (like the +/– icons in a TreeView control). Keyboard shortcuts also fall into this category. They have the advantage of being quick and easy-to-use for power users, although they are not very clear or discoverable for novice users.
A well-designed UI should cater to all audiences. For anything but a throwaway, single-use application (for which speeding up experts is not an important goal), you need to provide both pedagogic and immediate vectors for the most commonly-used functions.
Both direct-manipulation and toolbar-buttcon command vectors have the property of being immediate vectors. There is no delay between pressing a buttcon and seeing the results of the function. Direct manipulation also has an immediate effect on the information without any intermediary. Neither menus nor dialog boxes have this immediate property. Each one requires an intermediate step, sometimes more than one.
In the same way that a stranger to town may take a roundabout route to her destination while a native will always proceed on the most economical path, experienced users of a program will commonly invoke a function with the most immediate command rather than the one that requires intermediate steps. Naturally, the most frequently used commands in a program are those that migrate onto buttcons in the toolbar. These functions are still supported by items on the menu—the menu command vector—where their use becomes increasingly the purview of beginners. Experienced users, however, gravitate toward the immediate vectors of buttcons and direct manipulation.
This bifurcation of usage along lines of experience is an important characteristic of software usage, and it affects how menus and dialog boxes are used. They are needed less and less for daily use, and have instead become a teaching tool for first-time and infrequent users.
The buttcons and other gizmos [controls] on the toolbar are usually redundant with respect to commands on the menu. Buttcons are immediate, while menu commands remain relatively slow and clunky. Menu commands have a great advantage, however, in their English description of the functions, and the detailed commands and data that appear on corresponding dialog boxes. This detailed data makes the menu/dialog command vector the most useful one for teaching purposes, which is why I call it the pedagogic vector.
This is all taken from Chapter 19 ("The Meaning of Menus"), p 278–80, in the book's first edition (© 1995). He goes on to say lots of other interesting and useful things in the chapter. I've tried to provide a concise summary of the observations most relevant to this question in my own words above. I'm not sure if he has changed his tune in the later editions of the book—I only have the first edition.
Even if he has, this still provides an illuminating historical perspective. Given Alan Cooper's influential role at Microsoft during this time (he is often credited as the "father" of Visual Basic), when the Windows GUI was evolving, it is reasonable to assume that many of the programmers and UI designers responsible for developing its characteristic idioms were strongly influenced by his opinions and perspectives.
It allows better accessibility, likewise those +/- buttons are highly inaccesible, except for users with high mouse dexterity (*). It serves also as notifier of what "default" action is when hitting enter (for directory, "expand" is default, for file "open"). Also power users are not likely to touch those +/- icons at all, but simply rely into TAB, ENTER, UP, DOWN, LEFT, RIGHT, SHIFT, CTRL, MENU keys for navigation and manipulation. In that era context menu serves also as intermediator between power and ordinary users, aka. group of people leveling up in experience.
(*) for someone without good mouse dexterity doing any operationa with mouse on tiny icons is challenge. Single clicks, double clicks, slow double clicks, all get mixed up and sometimes become even random drag'n'drops of files/dirs.
