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.
So why use the ribbon?
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:
- commands (buttons and alike) in the ribbon are grouped together in logical and visible entities — the groups;
- commands can have different size depending on the available screen real estate, with sizes ranging from large (big icon and text), through medium (small icon and text) and small (only icon);
- finally, if the real estate is not enough a group may be collapsed to a much smaller state;
- a ribbon could be vertically minimized to save even more screen real estate;
- a ribbon has an additional set of quick commands — the quick access toolbar;
- a ribbon may show additional commands depending on the context — the contextual tabs.
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.
The spec
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:
- a ribbon is a top level control;
- a ribbon must have tabs, groups, commands visible at all times;
- nor the ribbon as whole nor a group can be empty;
- height of the ribbon is fixed;
- size of the buttons is fixed to three possible variants; yet it's somewhat fluid;
- resizing is only limited to window (application) resizing;
- resizing happens in a particular algorithm with the developer either having a big part by supplying the parameters needed, or leaves everything to framework…
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.
What it means?
Those requirements, I spoke about, roughly translate to the following:
- a ribbon must be the first element that you put in your webform, after the script managers and such;
- the entire ribbon tab container must not be hidden; neither must the groups nor the commands nor any other elements, unless specified otherwise;
- each tab must have at least one group and at least one item must be present in each group;
- the ribbon cannot be taller or smaller than it is, with the minor exception if you have quick access toolbar or contextual tabs;
- a button cannot have size different from the one specified; neither it can have different icon size; nor it can have fixed width, except if it's small;
- no resize handle;
- developers must either specify how each group looks in each variant, or provide a sequence of how groups should be resized before being collapsed.
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.
Notable improvements
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.
More to come
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…