I am thrilled to announce that we just released the final version of our Wpf-Ribbonâ„¢ control and it is fantastic if I say so myself 🙂 Here is screen-shot from our RibbonPad sample shipped with the control:

All required functionality from Office 2007 Ribbon UI Design Guidelines is implemented as well as large number of the optional elements. See Wpf-Ribbonâ„¢ web site for complete details:

http://www.devcomponents.com/wpfribbon/

 So what is special about our Ribbon?

I could muse about functionality and design (and I will at later date ;-)) but after working actively with and looking at the WPF applications and controls I have to single out two things we particularly focused on in Wpf-Ribbonâ„¢ design and development:

1. Speed and Performance
2. No new concepts unless absolutely without doubt required

Speed and Performance

There are two things you will notice with the WPF based applications and controls very quickly:

1. It is fairly quick to create good looking UI with plenty of sparkle, animations and transparency
2. If you do not pay attention performance can and will quickly degrade

The point #2 cannot be stressed enough. I think that in coming months and years we will see lot of controls and applications being released with poor performance. It is just too easy to add animations, transparency and lot of fancy stuff that brings even powerful machines down to their knees.

Even on my fairly fast Conroe 3 GHz (over-clocked, of course) machine with 2 GB of RAM I’ve seen some WPF UI perform very poorly. Mostly this happens when WPF resorts to software rendering as opposed to hardware assisted rendering, but as with any performance issues there are many ways to cause slowdowns.

To build professional business applications with WPF that is just unacceptable. Most of the machines that business applications run on are not very powerful. Running underperforming applications on such machines is just painful for end-users and ultimately for us developers.

That is why we spent lot of time tuning the Wpf-Ribbonâ„¢ performance and sometimes writing more code so the control actually performs better. As you go through your Wpf-Ribbonâ„¢ evaluation pay attention to this and you will see that Wpf-Ribbonâ„¢ is very smooth in its operation.

That, I think, is very important if you are going to use control to build professional business apps.

No new concepts unless absolutely without doubt required

As soon as you start working with WPF you will notice how different it is from Windows Forms and GDI+ and how huge the framework actually is. There is a significant learning curve if you want to create anything that does not fit or goes beyond what is provided with existing framework. You can compare switching to WPF to switching from say VB 6 to Windows Forms and .NET Framework. It is probably even more involved than that.

Our goal with Wpf-Ribbonâ„¢ was to reduce the introduction of new concepts, non standard property and method names etc. so you can get going faster.

For example WPF introduces the HeaderedItemsControl which is used as base class for controls in WPF where you have a control with header, say menu item or TreeViewItem, and child items. HeadearedItemsControl introduces Header property to represent the header and Items collection to represent the child items.

Now it was tempting to invent different/new/cool concepts if you needed something that is little different. For example type of Header property is object type and you think you need string type for button caption. So you say: Sure, no problem I’ll just add Caption or Label property of string type and be done with it… Why even inherit from HeaderedItemsControl since it does not fit your need perfectly? Well not so fast we thought.

Once you start introducing new concepts people have to learn them even if it is just new property name. If you just learned that you use Header property to set the caption of MenuItem or TreeViewItem we thought it is only natural to let you carry that knowledge to our controls as well.

But, what about pesky string type that you need for button text you might say which you need if you want to provide little richer handling for the button titles for example auto word wrapping etc.? Well, with WPF while you can use string type to represent the button caption, but we do not think you should be required to.

We wrote little more code so control is smarter about caption you are using. Our button lets you use strings for button caption and it will provide automatic word wrapping when appropriate, but it also lets you use any other WPF control or content as button label all through the standard Header property you are familiar with. How cool is that?

Now every time you are creating something new you have to introduce new concepts but we tried to really restrain ourselves and see whether there is an existing concept already in framework before inventing one.

So, please head over to our Wpf-Ribbon™ site  http://www.devcomponents.com/wpfribbon/ download trial version, no registration required, play with it and let me know how you like it.

Stay tuned, there is more to come…