My post about our current work in enhancing the VisualNDepend UI with Ribbon Office 2007 style got a lot of feedbacks. Thanks to everybody who participate in the debate and especially to:

• Wesner Moise who took the time to clearly expose its motivation on his blog about his choice of Ribbon for the UI of the NStatic tool.

• Chris Bryant, Senior Product Manager, Microsoft Office, who took the time to advise us and to answer our questions about the Ribbon license (more on this later).

• Julian M Bucknall, CTO, Developer Express, who’s behind the DXperience framework that helps us achieve our UI revamping.

Based on all these feedbacks, we got convinced that the Ribbon choice is the good one. It seems that around 2 users on 3 would prefer Ribbon over Menus and ToolBars (aka. CommandBar). Although this ratio is significant, it is not high enough to allow us completely getting rid of the CommandBar option. Hence, in the option menu we will let the choice to our users to choose between Ribbon or (exclusive) CommandBar (Ribbon is the choice by default).

Supporting both Ribbon and CommandBar leaded us to some interesting refactoring of our MainForm class. Basically, we now have 2 MainForm classes, one that derives from the DevExpress.XtraEditors.XtraForm class (that directly derives from System.Windows.Forms.Form) and one that derives from  DevExpress.XtraBars.Ribbon.RibbonForm (that directly derives from XtraForm). Both classes rely on 15 common high level UI responsibility managers (one for file menu actions, one for project UI appearance while project loading, one for skin management, one for panel management, one for UI option persistence etc). Our 2 MainForm classes contain controls initialization code that is generated by the VisualStudio's Windows Form designer and also managers' objects' initialization. Except this, our MainForm classes are empty. This choice avoids duplicating code but also allow logically partitioning our big set of controls and as a consequence, we get a more rationalized code.

Since my first post on Ribbon vs. CommandBar, we figured out that we were not abiding by the Ribbon UI Microsoft license. Basically we were missing the application menu, the Quick access toolbar and some other details:

To respect the Ribbon UI Microsoft license, you must also make sure that you get only one Ribbon menu, that can optionally contains RibbonTab.

At first we were frustrated by this rule because we liked the fact to host a ribbon in our docking panel.

We then moved our Ribbon related to the dependency feature to the main Ribbon and figured out that this was the right think to do. Having 2 Ribbons shown at the same time represent a lot of screen real estate dedicated to commands.More importantly, having just one Ribbon with tabs makes the concepts of contextual UI a reality. When the user wants to browse dependencies, she doesn’t need to see UI commands related to metrics or build comparison.

However, we know that some advanced users work with both metrics and dependencies panels at the same time. It is especially convenient if you have more than one monitor. To handle this scenario, we decided to allow users to show/hide the ToolBars in respective panels at whim. It didn’t mean more work because these ToolBars were already implemented to support the Menus and ToolBars scenario.

Finally we took a chance on this major UI refactoring to propose a use-case oriented help panel that should result in a less steep learning curve:

We also propose a dozen of different UI skins. First we just wanted one skin to avoid investing energy in skins. But then we realized that the framework DXperience offers this possibility almost for free.

Once again, thanks for feedbacks and don't hesistate if you have more remarks. We hope to release this new UI (with some bug fixes) by mid september.