An Interview with the Developer of a Silverlight 2 Ribbon Interface

The first project that I did when I started experimenting with Silverlight 1.0 (at that time it was called WPF/E) was an Office Ribbon UI.  It was a great learning experience and when Silverlight 2 betas started becoming available, I started to rewrite it for Silverlight 2 as a user control.  I was doing this in my limited free time but I stopped when I saw this:

I contacted the developer, Simon Matthews, once he uploaded the control to CodePlex and sent him a few questions.  I found that his experience and motivation were very similar to mine. 

Why did you decide to develop this ribbon control set?

I’ve always been interested in new technologies, especially from Microsoft, and for the past year I’ve been working mainly with ASP.NET 2.0 with little time to look into the new features of .NET 3.0 / 3.5 / SP1. I wanted to choose a project that would stretch me to understand XAML and Silverlight, coupled with my passion for UX the fluent Ribbon control was an obvious (even optimistic) choice.

What were some of your design goals with building this control set?

My main aim in building these controls was to understand the architecture needed to implement scalable robust Silverlight controls.

How accurately did you follow the Office Fluent UI guidelines?

I read as much as I could my hands on before starting the controls, I wanted to understand how the Ribbon behaved and how third parties could extend it. This coupled with extensive analysis of the Ribbon’s behaviour as I played with the Office control I attempted to replicate what I saw and read about. Thinking back, I should have probably followed the guidelines a bit more closely but I didn’t think my first stab at the control would get this far!

What were some of the challenges you faced in development?

There were many frustrating walls hit during development, I was originally working with Silverlight 1, migrated to Silverlight 2 beta 1, then beta 2 and finally to RC0 and RTW. As each version came out and I migrated my code over, more and more ‘undocumented features’ were being fixed. For example, a multi-line TextBlock over reported its ActualHeight which took me a couple of hours to understand and mitigate in beta 1… beta 2 fixed the issue causing me more headaches as I had to undo custom rendering code. I also spent many hours simulating pixel rendering as one of the nice things about the Ribbon control is the crispness of borders and buttons etc.

The other challenge I had developing in Silverlight was my lack of experience with technology specific areas of the framework such as XAML, Dependency/Attached Properties and the render lifecycle.

Why did you choose Silverlight 2?

I originally chose Silverlight 1 as I wanted to see how far web development could be taken from a Microsoft perspective. I have zero experience with Flex and didn’t really have the drive to learn it. When I heard WPF/E was in the pipeline I was excited to see how my current Microsoft based skills could translate into creating rich internet applications. Silverlight 2 was a natural evolution.

What WPF & Silverlight experience did you have before starting this project?

I had zero experience with WPF / Silverlight before starting the controls.

What is the roadmap with this control set?

There wasn’t really a roadmap to begin with – I just wanted to see how far I could get in replicating the Ribbon. Now I have to think hard about where I want to take the control. I think the roadmap has yet to be defined. I’m currently very busy with my day job making it difficult for me to spend time working on the control. I’d love to see the control finished, and brought up to scratch, using new additions to the Silverlight framework such as VisualStates. I’d also like to re-write sections of the code to make it meet best practices that have evolved in the Silverlight community over the past year.

What were the biggest challenges in development?

The biggest challenge by far was getting time to sit down and concentrate on the control. I would estimate 90% of the code was written on the train to and from work (45 minutes each way) which made it difficult to get into a coding groove. I don’t have access to the internet on the train either, so I had to cache tutorials/documentation etc before my journeys!

Are you looking for contributors to help development – if so, what are some areas you need help with?

I haven’t really thought about this, but if there are people out there willing to help out that would be great! The Ribbon is so functionality rich that there are areas yet to be started, for example, the collapsing of controls as the real-estate shrinks or galleries for things like formatting styles. I’m sure there are many areas of the code that could do with a review and clean up so I think there are tasks of all sizes to be tackled!

Tell me a bit about you.

I’ve been working in the IT industry for four years since graduating from the University of Sheffield, England, with a BSc in Computer Science and Artificial Intelligence. I moved to Canada in October 2007 and I’m now working as a Senior Consultant for Infusion Development ( based in Toronto.


Download the control here:

Comments (3)

  1. Chris Anderson, Tim Heuer, Michael S. Scherotter, and Jonathan van de Veen. Shoutout: If you don’t read

  2. Pete Brown says:

    Hi Michael

    Not to be a wet blanket here, but…

    The ribbon has some serious baggage attached to it. In order to use *any* implementation of the ribbon control, you have to license and comply with the "shalls" and "musts" in the Office UI Guide.

    I’ve been hesitant to use any ribbon control due to that set of restrictions, and how the available third party controls don’t meet the requirements 100%, and therefore don’t comply.

    I totally get why MS has done that, but it is not something we’re used to.

    Q: What are component vendors’ responsibilities?

    A: As for other licensees, component vendors who intend to implement the new Office UI must license the UI from Microsoft and register their products that include the UI.  In addition, component vendors are required to include a statement in their license agreements with their customers directing the customers to to obtain their own license if they wish to create products with the UI.  

    Q: What are the responsibilities of customers of component vendors?

    A: Third parties who obtain Office UI components from component vendors and intend to use them in software need to separately seek a license from Microsoft and comply with its terms in using the components.


  3. Synergist says:


    You’re right – this is a new model for Microsoft.  The baggage that you mention is a very explicit specification about how the ribbon should look and feel.  And for the ribbon it’s a lot of work.

    From my read of the specification, about 99% of it could be implemented in Silverlight.

    Even if they are not creating the control themselves, licensees of the ribbon should read the specification to understand what is needed and required.


Skip to main content