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:
Moise who took the time to clearly expose its motivation on his blog
about his choice of Ribbon for the UI of the NStatic
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
M Bucknall, CTO, Developer Express, who’s behind the DXperience framework
that helps us achieve our UI revamping.
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).
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
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:
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
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.
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.
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:
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.
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.