Adoption of the Ribbon UI

Question

Understandably the Ribbon UI doesn't suit every application, or even most of them, however I'm suprised so few developers have chosen to adopt it. Any ideas why?

How much work would be involved for a fairly major application to get the new UI?

Answer 1

If you're thinking about adopting the ribbon UI in a production commercial application, I would recommend to look for third party components instead of developing your own.

Answer 2

I think it stems from the fact that most users still use Microsoft Office 2003. I've found that companies that use Microsoft Office 2007, it's easier to get the users to migrate to the new ribbon control.

Answer 3

In my experience, most of the work would go into the design.

I converted one pretty small application into ribbonized form and I can tell you that 80% of the work was deciding how the ribbon will be structured - what will be seen on which page, how each page will be organized and so on. Then the rest was simple.

Of course, I used a ribbon library that did all the painting, collapsing etc for me.

Answer 4

I think the big issue is that you need to pay for a third party ribbon control in order to implement it.

Here's a couple of the commercial ribbon controls out there:

Krypton Ribbon

Actipro Ribbon

ComponentOne Studio

DevComponents Ribbon

Answer 5

We use the Ribbon (third-party component) in our WinForms applications, and it's not an enormous amount of additional effort over a standard Menu-and-Toolbar approach. It can, however, be a tough sell the first time you ship it -- most corporate users suffer from what I call a "deer-in-the-headlights" effect, whereby anything that's not exactly like what they had before causes them to be utterly disoriented and initially hate the new version with a passion. Quite quickly, I think, they get to know the interface and appreciate it.

I do think that the ribbon is only appropriate for a certain class of application -- typically corporate apps that integrate with Office at some level or are being deployed to knowledge workers already familiar with Office apps.

I'm still to determine if the ribbon will survive the next generation of WPF apps we'll deliver.

Answer 6

The Office 2007 ribbon came from years and years of usability and data collection (remember checking the box when you first installed Office?). As gabr alluded to, the user interface is the hardest part. Questions like the following need to be answered:

• What is used the most?
• How many clicks does it take to do most functions?
• Is the naming convention standard?
• How will the ribbon change given the context of the user's actions?
• etc.

And, frankly, those questions alone take a ton of work. The reason people haven't developed ribbon interfaces is it's too hard (or too easy to screw up).

Answer 7

If I'm not mistaken, Visual Studio 2008 Service Pack 1 (3.5 SP1) comes with the MFC-based Office 2007 style ‘Ribbon’.

If this is your dev. environment, I'd fiddle with it and see how it ticks.

Answer 8

I think it's because the ribbon was designed for a highly complex UI that has way too many controls to be manageable with a standard toolbar and menubar. It's (arguably) perfect for Word and Excel and a handful of others, but not so necessary for most applications. Most UIs are not that complex and thus don't need to use a ribbon.

Another reason might be that it is sufficiently different that many vendors don't want to "rock the boat" design-wise, fearing they will scare away customers. I'm not sure that reason holds much water though since there's likely an equal amount of vendors that don't care as much about their users as they do about attracting potential new users by incorporating the Next Big Thing. Perhaps at this point in time it remains to be seen whether the ribbon is truly the Next Big Thing.

Answer 9

In my case I liked some of the ribbon's features but didn't want some of the other features (like the application menu button and quick-access toolbar) since I'm writing a web application. However the license for using the ribbon requires you to implement it in full or not at all.

Answer 10

One of the hardest things is satisfying the MS requirements, so it is certainly worth buying a library to do all the heavy lifting for you.

I have implemented it for a complex web-application and it is non-trivial to get all of it working properly. I mean, it is easy to make it look like a Ribbon, but hard to get all the fiddly details right.

Nobody seems to be selling a commercial web-based Ribbon library, which is a pity, as I'd have bought it for that recent project.

Answer 11

If you feel you need to use the ribbon to better manage complexity you have already screwed up. MS Office uses the ribbon because it is a bloated toy that needs to appeal to people who will never learn to use even the most basic features properly.

If your application needs a huge number of features and eye candy for marketing reasons, by all means do use a ribbon. That's exactly what it was designed for. On the other hand, if your application is a serious tool for professionals, then take your GUI examples from Adobe.

Answer 12

Delphi 2009 has added components for Ribbon Controls. So technically, it is no longer difficult to add Ribbon controls to your application with D2009. I plan to do so in the future.

However, the real difficulty is in figuring out how best to implement them. Do it right and you'll have a fantastic user interface, since the agreement out there is that most people like the new Office ribbon.

But do it wrong, and you'll have a real mess.

Answer 13

Here's a good post by Jensen Harris about how the Office 2007 Ribbon came about. It's kind of a long video but a really good watch if you want to see why MS went down that path and help make a decision if it'd be a good choice (or how to decide) for your applications: http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx

Answer 14

I find, as a veteran user of Office that the ribbon is hard to get used to. I am currently enrolled in a Computer Literacy course (missed it my first time through, and it's required) at my college, and seeing people who have never touched a mouse in their life use it gives me new perspective.

For those new users, it seems to be fairly easy to pick up, and seems logical to them (not that they think about these things in those terms).

I think that for a new application developed for a new market, the ribbon UI would work very well. A veteran application in a wide-open market, however, might not fit well with the competition, and would end up turning people who are firmly grounded in the application's market away.

Answer 15

There are a number of problems with using the Ribbon UI.

First, is that Microsoft has a license you have to comply with to use the UI, but they don't actually have a library that you can use once you have agreed to the terms of the license! So you wind up having to go out and use a third party toolkit to implement the ribbon that you obtained a license from Microsoft to use.

Next, the terms of that license state that you are not allowed to use it to compete with Office or other Microsoft programs that use the Ribbon. However, there is no telling the direction the Microsoft Office suite will evolve or what constitutes competition until after you have sunk in the investment.

Finally, the Ribbon UI you can "license" from Microft, being just a set of user interface guidelines actually explicitly precludes deviation from those guidelines by pretty much any means. So if you need a novel UI element that Microsoft hasn't specified down to the pixel then you're hosed.

It is hard to find companies willing to invest that much up front development effort for such a limited (or even limiting!) return on investment.

Answer 16

We use the MS Ribbon GUI in our product Artisteer and most of our customers love it. It was very easy to implement using 3rd party Ribbon GUI component from CodeJock. You can check these products out if you like to see such implementation.