Markup Language for the Ribbon Framework
(Page 1 of 5 )
If you've started up a computer with an Office application during the past couple of years, you probably met up with the Ribbon. This ingenious visual element of the Office package revolutionized the way we perceive working with documents. In this article, we'll take a closer look at it, and even learn how to use the Ribbon Framework to suit our own programs.
At first, Microsoft was cautious about disclosing how they handled the Ribbon. This is understandable; they invested significant money in research to come up with the idea, and then in a developer team to execute it. Eventually, along with the visual and functionality upgrade for the Microsoft Foundation Class Library, they launched the first module showing how you could use their "invention" in your own application.
In the early days, Microsoft tried to patent the ribbon. This failed, because the concept itself (tabbed toolbars) could be observed in some earlier applications on the Internet. Nevertheless, you had to sign the Office Fluent License Agreement if you wanted to use it. Only after doing this could you have access to the Design Guidelines (meanwhile, they are published on the MSDN, available to anyone).
Then again, the MFC approach was a little bothersome; although it works flawlessly you need to code the addition of each item yourself. Arranging items to be as user-friendly as possible resulted in countless synchronization hours between the design team and the coding team of the application. With the build of the Ribbon Framework, this problem should vanish.
The solution was to involve the designers in the creation of the application. As designers are not famous for their coding background, the team split up the job at hand into two tasks. The designers now take care of how everything looks with XAML markup code. The coding team implements the functionalities of the controls inside the ribbon.
While this is not as good as throwing out a list of controls, the mainframe of the ribbon has an editor where you can add/delete and move around controls; it is a step ahead. Now every designer that takes the effort to become familiar with the existing controls inside the framework (read learn names and configuration parameters) and is not too lazy to write a couple of lines into an XMAL file can modify the application on his or her own.
For example, suppose that we have a checkbox in our application that defines some trait. From point of view of the programmer, the behavior should be the same even if we change the text box to a combo box with true and false values inside. The coder only needs to know what input and output parameters a command uses. What control the command uses to get those parameters is up to the designer. This is called the intent-based model.
Next: The Build Up >>
More .NET Articles
More By Gabor Bernat
