Hollywood Meets Office Add-ins

Today's Guest Writer: Savraj Dhanjal

Savraj is a Program Manager on the Office User Experience team focused on user interface extensibility for Office developers.

One of the key design features of RibbonX is the "pull" model, a model where Office asks add-in controls for their state. Though different than the "push" model of CommandBars, the pull model enables a number of scenarios for add-ins such as end-user customization, a separation between UI and core solution code, and better performance.

The model is straightforward--Office asks you for information about your controls--it "pulls" this information from your solution. Typically, Office asks for control properties that you did not declare up front in your customUI markup. Let's say you've got a button that should only be enabled when a certain condition is present. You write a function that returns true when your button is enabled. In your customUI markup, you associate this function with your button.

When Office first loads your button, and the button is on screen, Office calls back to your code to see if the button should be enabled. Office doesn't ask again, unless you indicate that your state has changed, by calling IRibbonUI.Invalidate, which invalidates all of your custom controls, or IRibbonUI.InvalidateControl, which invalidates a particular control. The function that Office calls is called a callback.

The interaction between Office and your add-in is best summarized in the following excerpt from a screenplay:

 Add-in:   Hi Excel! Here's some customUI markup.
           ...
     <button id="ButtonOne" label="Hello World!" 
       getEnabled=”enabledState” onAction="sayHello"
            imageMso="HappyFace" />
    ...
  
Excel :   Great, I've applied it to the Ribbon. By the way, 
          it looks like you have set a callback for the enabled 
          state of ButtonOne. I'll call back to your function, 
          enabledState, the first time your button is on screen.

Time passes, user clicks on custom tab

Excel :   The user clicked on your tab, your button is appearing.
          Calling enabledState, is ButtonOne enabled?

Add-in:   Yes.

Excel :   Ok great, I won't ask you again until your state changes.

 *Time passes, user does something

Add-in:   My state changed.  I'm calling Invalidate.

Excel :   Ok, calling enabledState, is ButtonOne enabled?

Add-in:   Yes.

Excel :   I won't ask you again until state changes.

Go to *, until user closes the app. 

Ok, so that wasn't too exciting. But it's an illustration of how pull works. Add-ins can return just about all of the properties you can declare in markup, like the images, labels, descriptions, screentips, visibility, and enabled state of controls, through callbacks. For dynamic controls, like galleries and comboboxes, callbacks return the items that populate these controls.

The pull model affords several benefits for developers. The first is free end-user customization. If an end-user wants to promote a custom gallery to the quick access toolbar, she can. This behavior is completely transparent to the solution developer. Since code is never tied to the location of a control, callbacks for the state, label, or other properties still work even if the control is on the QAT. If your control was copied elsewhere in the world of CommandBars, you would have to write code to update the state of your control in both locations.

If you've ever developed a complex solution with a large amount of UI, you probably understand the benefit of keeping core application code and the UI separate -- the benefit is that the UI remains easy to change. Because of the "location agnostic" nature of the pull model, RibbonX developers get this benefit as well. You (or a UI designer) can rearrange your UI without ever touching your core application code.

We're also making add-ins more performant (in our own small way) with the pull model. In CommandBars, you could waste time updating controls that were not available or visible to the user. With RibbonX, if you tell us your state has changed, we only ask you for the new state of your controls if it is applicable -- that is, if your controls are visible to the user. If your controls are not on the screen (perhaps they're on a different tab) there's not reason to keep these hidden controls up to date.

As a final note, the RibbonX implementation of the pull model brings add-ins much closer to how the applications have always worked internally. It should be no surprise that the Office apps follow this very same design pattern: If something changes, the on-screen controls get updated. When the state changes in an add-in, or in the application, Office updates its UI to reflect the new state.

I'm sure some of you are wondering about the Hollywood-quality screenplay I'm writing regarding Office add-ins. Does anyone have any connections to get it submitted? A tentative title could be "Don't call us, we'll call you."

Comments

• Anonymous
  March 30, 2006
  Interesting post.
  
  Here's a (perhaps odd) request: a wide variety of icons built-in that aren't already being used for Office commands that we can use when we create Office add-ins. There are times when I'd really like to assign a new image to a particular button, but I don't have the time (or skill, frankly) to come up with something decent.

• Anonymous
  March 30, 2006
  Pretty cool sounding, can't wait to see more. Although, I do have one minor thing...Add-in sure isn't a very talkative fellow is he?

• Anonymous
  March 30, 2006
  ... core solution code ...
  ... it "pulls" this information from your solution ...
  
  ???
  
  Savraj Dhanjal is responsible for using the word 'solution' 27 times on Jensen's home page, and in only 1 instance did he use it correctly.
  
  Mr. Dhanjal, whenever you find yourself about to type 'solution' in the future, please think, do I really want to sound like a pretentious marketing type?
  
  How this buzzword got so ingrained in VS I have no idea.  What you build is a project.  Whether it's a solution or not is up to the customer.

• Anonymous
  March 30, 2006
  Excellent! I've been using this pattern for over 8 years now in my own user interfaces, both in this control-oriented style and in a more declarative command-oriented style.
  
  It's good to see Office catch up. Hopefully WPF and ASP.NET will catch up too, some day.
  
  Of course, WPF's data binding can be coerced to working this way, but it requires extra work (i.e. another layer of indirection, such at a C# property) to allow an arbitrary function to be written per control property.

• Anonymous
  March 30, 2006
  To "clarity"
  
  solution: The method or process of solving a problem
  
  "...the pull model enables a number of scenarios for add-ins such as end-user customization, a separation between UI and core solution code, and better performance."
  
  or...
  
  "...the pull model enables a number of senarios for add-ins such as end-user customization, a separation between UI and [the method of solving a problem], and better performance."
  
  Here, the solution <i>is</i> the code.
  

• Anonymous
  March 31, 2006
  Dennis,
  
  > Here, the solution <i>is</i>
  > the code.
  
  Then why doesn't he just say, code?

• Anonymous
  March 31, 2006
  From http://www.babsoninsight.com/contentmgr/showdetails.php/id/650
  
  Solutions: A Nebulous Term That Breeds False Expectations
  Many executives were skeptical of vendors who pushed “solutions,” a term with which the marketplace continues to struggle. Approximately half the executives interviewed articulated a definition that resembled that used by ITSMA and Babson College (see sidebar for definition). The other half either could not define the term or equated solutions with software, either packaged or custom-developed. Regardless of the definition, the connotation of the term—its sense of providing a comprehensive, end-to-end resolution of a problem—often fosters false expectations and accusations of bogus claims. Respondent reactions were often emotionally charged. According to Joe Puglisi, group CIO of EMCOR, “My gut reaction when someone offers a solution is, ‘That’s great, but do you know what the problem is?’ The mere characterization of a product as a solution suggests that people are pushing the answer without first knowing the question!”

• Anonymous
  March 31, 2006
  Ok, clarity, he used 'solution' too often. Anything else in the article strike you as relevant?

• Anonymous
  March 31, 2006
  Is there UI to create the markup inside of Office and/or VBA? Is there a way we can embed this information directly in an Excel/Word/Access file?
  
  If I have a simple solution I would like to embed the markup and the code directly in my Excel template rather than providing  multiple files for 8 lines of code and 1 button.
  
  Steve

• Anonymous
  April 01, 2006
  The comment has been removed

• Anonymous
  April 27, 2006
  Today's Guest Writer: Savraj Dhanjal
  Savraj is a Program Manager on the Office User Experience team focused...

• Anonymous
  May 21, 2006
  Well done!
  [url=http://rsyhvqwr.com/pqbz/usdz.html]My homepage[/url] | [url=http://zhgqoyfj.com/jwib/nbdf.html]Cool site[/url]

• Anonymous
  May 21, 2006
  Great work!
  <a href="http://rsyhvqwr.com/pqbz/usdz.html">My homepage</a> | <a href="http://hneckmtv.com/mwhz/ccoo.html">Please visit</a>

• Anonymous
  May 21, 2006
  Great work!
  http://rsyhvqwr.com/pqbz/usdz.html | http://nnfyqdkp.com/sbwh/mtox.html

• Anonymous
  October 27, 2008
  PingBack from http://mstechnews.info/2008/10/the-office-2007-ui-bible/

• Anonymous
  June 02, 2009
  PingBack from http://woodtvstand.info/story.php?id=86878