I’ll bite even harder: if the argument is one of efficiency, and that is all the argument is about, then there no conceivable advantage to using the menu unless there is no other option (and there are many cases where that is the appropriate answer, to be clear, but this response is why this particular case isn’t one of them). If this argument is about things not being the way they used to, or user preference as you suggest, well then that is another matter entirely, but in efficiency, there are two scenarios:
- You are writing and you just put down a word you are unsure of:
Method A: You reach for the mouse, move the pointer to the required location, right-click, access a menu function.
Method B: You press Ctrl-Cmd-D.
- You are editing or proofing; mouse is probably already in hand as random-access to your text is more efficient with a mouse for everyone except Vi users. You see a problem word:
Method A: You move the pointer to the problem word; right-click, access a menu function
Method B: You move the pointer to the problem word; click; Ctrl-Cmd-D.
Now note that I didn’t describe how you get to the menu function in both Method A answers. This is a variable quantity and involves a different amount of effort based on a number of difficult to predict factors. It is not a set procedure.
- If the word is at the top of the page, you will need to move the mouse differently than if the word is at the bottom of the page.
- Certain aspects of where you are clicking can and will alter the construction of the menu. If the problem word is in a table, the contextual menu will have different metrics, and different metrics means different hand-eye calculations
- If the word is misspelled, there may or may not be a varying quantity of suggestions, also adjusting the overall shape of the menu and adjusting, in real time and in no predictable fashion, modifying where you must move and click or release the mouse button.
- Beyond that there are purely mechanical variances, such as if your mouse is well positioned; if it is on a surface that promotes skipping; etc, but these are somewhat out of scope.
So quantifying the tail action, “access a menu function”, is difficult to do because it is highly variable, and a highly variable landscape that must be parsed and adjusted to using cognitive thought is by definition inefficient because of the introduction of semi-unpredictable multiple stimuli that you must react to in order to process a decision action and convert it into physical motion. Whether the item is in a sub-menu or the top-level menu is almost moot, given everything else. I say almost because in an isolated closed-box scenario where all you have is Method A, then any added complexity to the “access a menu function” stage is indeed a liability.
My point, and it is entirely relevant and not “beside the point”, is that there is more than just Method A, so attempting to construct an argument based solely on the neglect of external methods is not an accurate picture of the situation (there is also a Method C: and that is the “Dictionary” toolbar icon, which I would consider to be a compromise between A and B. It lack’s B’s precision, but at the same time it also lacks A’s unpredictability, though suffering a slight drop using Fitt’ Law in that the most optimal placement for something is where you already are—not that a contextual menu item usually is—but the menu at least is).
Method B, on the other hand, has no variables. The final action in the list is precisely the same no matter if the word is at the top or bottom of the screen, or if you are in a table cell, or clicking on a word with 35 suggestions—it simply doesn’t matter—it’s always the same purely mechanical reaction, requiring no extra cognitive functioning to perform: it is, by definition, efficient.
Circling back around to an earlier argument: it requires two hands. Yes, and presumably you have two. If you do not, then I apologise in advance for the faux pas. In fact, in most UI scenarios, unless the application is solely keyboard based or mouse based, a combination of the two comes out the winner. Classic example: Photoshop. There is another program that is extensively wired up for keyboard usage. Even though on the surface you might think it a mouse intensive application—it’s actually not. If you’ve ever been in the same room as a professional graphic designer you’ll know this. They almost use the keyboard more than the mouse in Photoshop. In most cases, the most efficient way to use Photoshop is with two hands: one to point and one to enact. Expert Photoshop users hardly touch menus (but even when they do, a menu use does not require displacement of the left hand).
I would submit that editing and proofing is, mechanically speaking, very similar to professional graphic work. It is a two-handed affair: one to point and one to enact. Now since editing does require periodic typing, there is going to be more back and forth than in Photoshop, no analogy is flawless and this truth cannot be avoided, unless you are particularly efficient at one-handed typing—most touch typists are not—or very good at navigating text without a mouse (again, Vi users).
So setting that outlier aside, most editing actions are point and enact. Point and fix a letter; point and highlight; point and delete; point and cut and paste; point and look up in dictionary. These are two handed actions by nature. They can be done all entirely with the mouse or all entirely with the keyboard, but neither is going to be as efficient, 90% of the time, as a two-handed approach.
I’m speaking purely of raw efficiency here. This isn’t about individual preference, or aesthetic beauty, or anything like that: this is purely about the reduction of cognitive UI management time (giving your brain more cycles to focus on the work and not the program) and the maximisation of mechanical protocols to accomplish frequently enacted tasks. The more predictable your pathing is, the less you have to look at the interface and “think” about it, giving you more time to do what your job is.
And how critical is all of this? Barely (no offence intended). The calculated differences between (a) item dynamic at top-level, (b) item dynamic at second-level static, and © item at static mechanical is—in the grand scheme of things: nothing to worry about. We are talking about fractions of a second and minuscule load time on the brain between the first two, compared with a fairly substantial reduction in the third. Or to put it another way: quibbling about variances in the pathing between a & b are like fussing over whether its faster to use the iPad glass keyboard in portrait or landscape orientation when you have a Bluetooth mechanical keyboard sitting right beside it.