UI matters (Revisited): Menus and ToolBars vs. Office 2007 Ribbons

Posted by Patrick Smacchia on August 29, 2007

 

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).

 

 

 

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.

 

This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.NDepend.com Patrick Smacchia

    So far we are using DevExpress DXPerience Windows Form library but it is a bit too buggy unfortunatly.

  • Esraa

    What are the steps used to create a ribbon ?!

  • Montre

    Hello Patrick

    Thanks for sharing – I think it will be quite common use case! Would you mind telling us a little bit more about the architecture of two mainforms, how they are selected in runtime and how code duplication was avoided?

    thanks a lot
    cheers
    M

  • http://codebetter.com ???????

    I don’t know if asking this question violates some design heuristic of the ribbon control but from a screen real estate perspective is it possible to have the ribbon cascade in and out as needed? I would love this feature in Office 2007.

  • David Martin

    The new UI looks great, and I’m a fan of the new Ribbon UI from MS. However, it was interesting to see that the DevX version does not strictly adhere to the guidelines. For the Quick Access Toolbar (QAT) the 9th guideline states that the right border MUST have a concave curve. They even go so far as to state the the radius of the concave curve MUST equal the radius of a circle centered in the app title bar.

    A little too much guidance in my opinion – would rather have seen a SHOULD unstead of a MUST. But there you have it.

    Keep up the good work. I’m mainly glad to see more people concerning themselves with user experience.

  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo

    Awesome!!! I didn’t know that, thanks Patrick! It’s the simple things that make me happy.

  • http://www.NDepend.com Patrick Smacchia

    The Office 2007 Ribbon license doesn’t cost a penny it is 100% free. My understanding is that MS created this license to make sure that in the future, all UI that uses Ribbon look alike. This way, it will be easier for users to get started with various products.

    Our Ribbon experience relates this fact well. If you read my first post you’ll see that our first UI choice were not that judicious and not very close to what Office UI looks like. If the license were not here to ‘scare’ us, maybe our UI would be more difficult to start with.

    My opinion is that it is a good thing. Futue NDepend users that are used to Office Ribbon will feel at home when discovering NDepend. Also, MS spent hundreds of M$ in this Ribbon stuff, and I’m certain that me and my team could not have done a more comprehensive UI by ourselves.

    Joe, I’m not sure to understand the term ‘ribbon cascade in and out as needed’ but if you mean having several Ribbon visible in the same Window the answer is no, the license doesn’t permit that (maybe you can play with the ‘Window’ term, is a panel a window?). If you mean collapsing the Ribbon UI, take a look at Office 2007, it is already implemented by double-clicking any tab.

  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo

    I don’t know if asking this question violates some design heuristic of the ribbon control but from a screen real estate perspective is it possible to have the ribbon cascade in and out as needed? I would love this feature in Office 2007.

  • Mike

    So why exactly do you need to abide to a licence for a user interface? Did you have to do that for the old interface? If not, how is it an improvement for you and your product, that you need to have some licence for a GUI? Since when do we need a licence for the GUI we create. Did you get legal advice on this, or did they just scare you into it?