Ribbons, licenses and Microsoft
You can be proud of an interface you developed, but this is taking it too far.
Occasionally, someone does something so inexplicably stupid that it’s hard not to let your jaw drop so far that it hits the carpet and bounces twice. For an example, let’s take a look at the new Office 2007 product. The first thing that will jump out to massage your eyeballs is its completely new design for menus: in fact, menus have basically gone away altogether and there are now these “Ribbon” designs that change their behaviour depending on what you’re doing, based around a core set of common tasks such as creating a document, formatting it, revising it, graphing and so forth. Without doubt, a lot of design hours have been devoted to this menuing system, especially in the area of defining exactly how it should collapse down whenever you reduce the main window size. After all, there’s no sense in having large graphical buttons cluttering up a smaller window, so a change of size and content is obviously useful there.
Several developers outside of Microsoft have obviously said: “Wow, wouldn’t it be nice to have that kind of functionality in our own applications?” Meanwhile, the development tool vendors have been quick to develop easy-to-use drop-in tools that mimic the behaviour of the Office Ribbon design, but generate all the heavy code for you. There’s nothing new there -– tool vendors have been offering such button and menu builders for years, going back to the earliest days of Visual Basic with its VBX add-in control system. Today’s Visual Studio is awash with such builders, helpers, snap-in doodads and other useful gizmos. So, it was obviously with a great deal of interest that I read the press release from Microsoft saying it was licensing its Ribbon technology out to the developer community. I went to the right page to look at the details, and immediately it was obvious that something wasn’t quite right -– Microsoft hadn’t really released anything concrete, it had merely announced a licence for its “intellectual property” in the design and implementation of the code.
Now one reason for this is that Microsoft releases a lot of stuff nowadays under such an “it’s free but you must accept that it’s still our IP” licence, which I can perfectly understand. A good example of this kind of permission is the whole definition of the XML licensing schema for the Office document file format –- just place the words “XML file format copyright Microsoft” (or some such equivalent phrase) into your application and you can use the Microsoft XML schemas, definitions and so forth to your heart’s content.
But this case was different. First, it says you can’t use the Ribbon design for any application that competes with the main tools in Office, so you can’t design an Excel-alike or Word-alike. Unfortunately, it doesn’t clearly define the criteria by which you can tell whether a product is an Office competitor or not. I can imagine how a small data grid with some numerical capabilities would easily fulfil the needs of many people, especially in a vertical market context, but there’s no means of telling whether that would put you in violation of the non-compete with Excel or not. I guess that’s something Microsoft would arbitrarily decide upon at some unknown point in the future. However, it does fulfil Microsoft’s immediate need, which is to prevent OpenOffice and other such products from adopting the Ribbon look and feel for themselves.
But that’s not the half of the problem. Look at what you get when you agree to this online licence -– a download of a 150-page document that describes, in the most excruciating detail, how the Ribbon should look, operate, collapse, inflate and so forth in an Office application (which, of course, you can’t build because it would be in competition). Some items are marked as being mandatory, while others are optional, and if your app fails on a mandatory point then you don’t have much time in which to fix it before Microsoft will deem you to be in violation of the licence and will doubtless unleash the Lawyers From Redmond on you. And yes, it gets even better -– this document is considered Microsoft Confidential. Unbelievable though it might seem, a document that simply lays out all the visible behaviour of the Ribbon in Office -– a product that will ship tens of millions of copies -– is somehow a confidential matter.
Note that you don’t get any actual code with your licence. There’s no Ribbon Builder for Visual Studio supplied, which might make it easy to build a Ribbon toolbar and which had the smarts built-in to ensure it was “compliant”. So you turn to the third-party tool vendors, who’ve been working on Ribbon-esque tool builders since the first beta of Office escaped from Redmond into the public gaze. Yes, they have a range of tools that can help you design and build a Ribbon.
Microsoft believes it has a design icon that’s patentable and able to be protected in law. This is arguable -– resizing button bars aren’t new. Nor are large-icon button bars –- let me point to my gorgeous yet 15-year-old NeXT Cube. Yet, Microsoft thinks it can claim they are and force anyone who wants anything to do with them to sign on the dotted line and accept the licence terms.
So there you have it. A new Ribbon button bar that you can license for your application development, but so must every one of your customers if you create a tool generator. A big book of screenshots of Office Ribbons, but you can’t build an Office-competitive product. A licence that says Microsoft will decide how and when you’re in and out of compliance, but gives no framework, no come-back, no external review.
And you agree it’s covered by the law of King County, Washington State, USA. Best of all, you get no code to actually make any of this happen.
Despite that being a list that’s enough to make any grown man weep, there’s one final sting in the tail. Any third-party tool that takes the Ribbon idea, licenses the look and feel from Microsoft, and then builds a development tool to help with the building of Ribbons in your app has one final elbow lock around their throat. They can’t add any new functionality that isn’t in the Microsoft specification. If you think your app would benefit from a Ribbon that snaps to the bottom of the window, or maybe the right or left, and yet still fulfil the design criteria for auto-collapsing, you’re out of luck. No-one, whether it be you or a third-party tool vendor, is allowed to extend the definition of what the Ribbon does. Any extra feature will be considered a violation of the licence.
And note that the licence doesn’t mean you can piggy-back on their licence. If you use a third-party Ribbon development tool in an application you’re building, you have to agree to the Microsoft licence too. And if the middleman goes out of compliance, you do too.
What’s so galling about this is that in the past we’ve had documents called the Windows Style Guide, which defined how applications should look and feel to meet the “requirements” laid out by Microsoft. Naturally, there’s no style guide for Vista at present -– and, if there was, it would be interesting to see how Microsoft would defend the variations found within the Vista product itself. This is a company that has basically given up on getting drivers digitally signed for 32-bit Windows and hasn’t dared release a proper style guide for Vista, and yet wants developers to sign on the dotted line regarding the biggest change in the history of user-interface design on Windows. I smell a rat.
This article appeared in the June, 2007 issue of PC Authority.
Thoughts on this article? Add a comment below.
Be the first to comment on this article.