The ribbon (or RadRibbonBar, as we have named it) is among the most tempting-to-use looking and yet somewhat neglected controls. True, it has received some Microsoft love with being the core command component in the Office suite, as well as being more deeply integrated in the soon-to-be-released Windows8, but overall it's not been used that much.
Main reason being “why use it”. That, by the way, is an excellent question.
To answer that, let's first analyse the control and its purpose: it looks like a tabbed command area; a tabbed toolbar if you will. For the most part, you could say that's true, but just for the most part.
Other than being an overly sized toolbar, a ribbon has a couple of overwhelming features making it superior when compared to traditional toolbars:
If it's not clear from the above features, the ribbon is a command interface that offers a very narrow focus over a broad range of commands.
So far it sounds nice and easy. We have to remember though, that simple things are not only rainbows and unicorns — when you look beyond the visually stunning fluent interface, there is an awful lot of logic and math happening behind the scenes. Thankfully, all that and much more is described in a big, extremely detailed specification.
Speaking of which, true, the spec, math and logic are somewhat “easy” to implement in a controlled environment such as Silverlight and WPF; but when it comes to HTML and browsers, things couldn't be worse or harder to implement.
I won't bore you with the exact details, which can be found in various places across the internet, but the key elements of the spec are:
Those are the so called requirements for ribbon; in a way, in order for a ribbon to be recognized as such, it has to comply with the above and other requirements.
Those requirements, I spoke about, roughly translate to the following:
If you have been using the ribbon prior 2012 Q2, you might know that we did not follow that specification too strictly. We also knew it and we decided to correct that.
Starting 2012 Q2 we introduced many changes to comply with the spec as much as possible. But it turned out, that there were too many “must” in that spec and some of them did not feel right for our customers.
For instance, a group must have a title. It wouldn't occur to me, not to set a title to a group, but we began receiving support tickets, so we fixed that. A ribbon must not be empty… turns out that empty ribbons are also common.
So we decided to change some of the “must” to “should” and try not to enforce things.
The resizing, per say, was one area where we vastly improved over the last year. The previous resizing algorithm was … well a bit magical; we also didn't like the algorithm in the spec, as it was a bit of overkill… The current resizing is what we call “predictable resizing” e.g. both shrinking and expanding of ribbon commands to work identically (but in a mirrored fashion).
The resizing itself would not have been possible if we did not perform a bit of reordering of the items on the client (in the browser). That by itself is a breaking change, but we did add the option to disable the reordering of the items, should anyone wanted it.
We are planning to add new items for the ribbon to make the ribbon more flexible. One such item would be the combobox / dropdown, though the one in the ribbon will be much simpler than the already existing RadComboBox.
Textboxes are also not perfect, when you add them as template items, so we are going to make them a standard ribbon item.
Those two are a must for the 2012 Q3 release, but the rest are up to you. Tell us what else you would like to see in the ribbon, be it a numeric textboxes, galleries or backstage view…
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.