Office is more than a suite of applications. It’s also an important development platform.
A change as big as the new Office 12 user interface has implications for
developers. There are thousands of publicly available add-ins written to
take advantage of Office. Many companies have also written their own
suite of internal add-ins which extend Office to impressively integrate into their
The good news is that Office 12 provides an enormous opportunity for add-in
developers. We’ve introduced a new model for extending the Office
interface code-named RibbonX, which addresses directly many of the
toughest issues facing Office UI developers today. Based on a declarative,
XML-based model, RibbonX unlocks much of
the power of the new UI in a straightforward way, whether you
write in C#, Visual Basic.NET, C++, or VBA.
In an upcoming series of articles, I’ll walk you through the extensibility story
of the Office 12 UI. If you are especially interested in these developer
issues, I’ve created a new
which you can use to follow just these posts. (Of course, I’m sure you’d
rather keep reading the entire blog, right?)
Getting the programmability story right has been one of the biggest challenges
of this release. Not since perhaps the changeover from Windows 3.1 to
Windows 95 has there been such a large number of existing applications expecting a totally
different UI from the environment they ended up running in.
Tomorrow, I’ll kick off the series by discussing what happens to the existing
base of Office add-ins and macros in the new UI. (Hint: They still work!)