Like others have said, the ribbon is either a "love it or hate it" item, for some reason.-Josh
Let me add my $0.02. The ribbon looks totally awesome, but I would argue that it less usable and in the long run more annoying than menus and toolbars.
First of all, you can navigate menus with the keyboard much easier than the ribbon. You can just browse the menu, and discover keyboard shortcuts in peace. IN the ribbon, accelerators only show up when you press Alt, and when they do, the labels obscure big parts of the buttons, so it's really hard to see what is what. Otherwise keyboard shortcuts are only displayed in mouseovers. Menus 1, Ribbon 0.
The ribbon, at least in Office, tends to be dynamic. When you're focused on a table, an additional page may be shown with table-related commands. I hate that truly, because after two years of using Word and Excel 2007 I still cannot find important functions I often use. Sometimes I cannot find them because they are simply not there - they only show when Word thinks I need them.
The ribbon does take a lot of space, and if you watch the MS presentation, the crucial point there is that they only decided to go with the ribbon when it became clear they could not fit any more stuff into the menus and toolbars, and when they knew users did not even know about a lot of fearures and so they never used them. OK, I buy that. But to day you often see applications that have a ribbon with only one tab, like this. Now that totally makes no sense. Clearly the author went for the Aaah! cuteness of the ribbon without anything close to the need for it that MS originally had. There are plenty of apps like this, and to me a design like that indicates the author wanted to entice users with cool-looking interface, but at a price in ease of use and convenience (and screen estate). When I see that, I am very unlikely to buy the product, because I know the author doesn't care much about how the app is actually used, only that it looks good.
(The same BTW goes for anything .Net based - same reason, except there's not even the visual reward there).
My rule of the thumb is, if you have enough UI to fill half a dozen tabs on the ribbon, then maybe consider it. But if you're going to have a whole huge ribbon with only one tab and six buttons on it, then that's exactly what the ribbon was not designed for.
-tranglos
I'm not buying those.
The ribbon gives you a flexible toolbar. Looking at the example you gave there, that's what it looks like. You just don't get that nice, compact UI with most toolbars. A ribbon with 1 tab can do that. And that is what I'm seeing there.
Sure, the tab could go, but other than that, I don't see a problem. It's neat, compact, and gives you everything in 1 shot. It's easy to look at, and I think that's what most people need.
Yeah... I can see it being overkill... But it seems ok at a glance, and likely much better than burying them in an older menu style with flyouts.
As for screen real estate... Not buying that either.
If you can't fit in an extra 80 pixels or so at the top when you have monitors at 1920 x 1200... You have a real problem. It's not the software taking up 80 pixels that's the problem.
If you can't afford a monitor with a modern resolution, then the solution to me seems to be to use older software that's designed for small resolutions. But don't blame the software author for taking advantage of newer technologies that most people have.
10~15% (give or take a bit) of the vertical resolution for a toolbar or ribbon isn't unreasonable.
You can't even easily get 15" or 17" monitors anymore. Laptops regularly have 1600 x (whatever) resolutions now, or higher. The small laptops have 1200 x (whatever).
As for .NET. Who cares?
Quite frankly, when I use some software, I couldn't care less if it's written in Erlang or Fortran or .NET or C++ or Delphi or whatever. I only care that it does what I need it to do. Language is irrelevant.
Well, that's not always true... Some languages are better at some tasks and others excel at other tasks. e.g. C# for general productivity or anything, C or assembler for very low level networking, F# or Erlang or another functional language for computation, etc. etc.
But for general software, languages are irrelevant as a consideration for most users.
As for when it is appropriate to use a ribbon... Meh... Whatever works. I think it's all case-by-case.
For keyboard shortcuts:
That seems to work fine.
I don't see what the resistance to the ribbon is. It's just another way of doing things, and for most people, I think it's much easier than farting around with menus and flyouts.
At the end of the day there is 1 and only 1 and exactly 1 consideration that matters: What will make life easier for the people that use the software? Nothing else matters beyond that. Nothing. If a ribbon fits that, then so be it. If not, then that's the answer.
