I followed Jensen's blog postings all throughout the development of the ribbon; but it's all highly unconvincing to me, because it fundamentally is at odds with how I interact with software. Menus work for me because they are lists of text; when I'm looking for a command, a list of text is exactly what I want. If it's a command that I use often, it doesn't belong in a menu - for that, something like a ribbon might be a good idea, though a toolbar uses less space and doesn't have tabs, so I think it's better - but for commands I don't use often, lists of text are very close to ideal.
Sure, any new UI modality will be at odds. But for mouse-oriented UI, I haven't seen anything better for a situation where you have many, yet infrequent, commands. A search interface seems like it could work well, but you'd have to know (a) that the software supported the command you're looking for, and (b) what aliases the software supported for that command. The Windows start menu search kinda works, most of the time; but that's because you generally know whether or not you have a particular piece of software installed. But when you don't know 100% if the software actually has the feature, and you're looking for it...
So in the absence of an effective search, it seems clear that a list of commands, grouped into categories, is best for finding infrequent functionality - particularly when a mouse is the modality.
One thing I am absolutely certain of: searching for a command in a ribbon is harder than searching a menu. I've had opportunity to do both in unfamiliar UIs, and searching ribbons is definitely harder.
I'm not sure the comparison is quite the same. The key difference is that with a CLI or punch card interface, you need to know the command syntax in advance - it can't be discovered by interacting with the system. With a GUI, you can discover the appropriate commands to make the application do what you wanted to do.
The menus vs. ribbons debate essentially boils down to one of aesthetics. But I'll personally agree with barrkel in finding it much easier to locate the function I need by browsing through one-dimensional lists of text than by browsing through two-dimensional grids of pictures (of varying sizes and shapes).
The Ribbon may make locating a small set of basic features slightly easier for inexperienced users, but it makes far more difficult for everyone else to work with more complex functions - the very thing for which software adds the most value.
Comments
I followed Jensen's blog postings all throughout the development of the ribbon; but it's all highly unconvincing to me, because it fundamentally is at odds with how I interact with software. Menus work for me because they are lists of text; when I'm looking for a command, a list of text is exactly what I want. If it's a command that I use often, it doesn't belong in a menu - for that, something like a ribbon might be a good idea, though a toolbar uses less space and doesn't have tabs, so I think it's better - but for commands I don't use often, lists of text are very close to ideal.
>"but it's all highly unconvincing to me, it fundamentally is at odds with how I interact with software"
The same argument could have been made about GUI's v command lines or command lines v punch cards.
Any new UI architecture will be fundamentally at odds with how you interact with software.
Sure, any new UI modality will be at odds. But for mouse-oriented UI, I haven't seen anything better for a situation where you have many, yet infrequent, commands. A search interface seems like it could work well, but you'd have to know (a) that the software supported the command you're looking for, and (b) what aliases the software supported for that command. The Windows start menu search kinda works, most of the time; but that's because you generally know whether or not you have a particular piece of software installed. But when you don't know 100% if the software actually has the feature, and you're looking for it...
So in the absence of an effective search, it seems clear that a list of commands, grouped into categories, is best for finding infrequent functionality - particularly when a mouse is the modality.
One thing I am absolutely certain of: searching for a command in a ribbon is harder than searching a menu. I've had opportunity to do both in unfamiliar UIs, and searching ribbons is definitely harder.
I'm not sure the comparison is quite the same. The key difference is that with a CLI or punch card interface, you need to know the command syntax in advance - it can't be discovered by interacting with the system. With a GUI, you can discover the appropriate commands to make the application do what you wanted to do.
The menus vs. ribbons debate essentially boils down to one of aesthetics. But I'll personally agree with barrkel in finding it much easier to locate the function I need by browsing through one-dimensional lists of text than by browsing through two-dimensional grids of pictures (of varying sizes and shapes).
The Ribbon may make locating a small set of basic features slightly easier for inexperienced users, but it makes far more difficult for everyone else to work with more complex functions - the very thing for which software adds the most value.