Developing a Worldwide UI Framework
For the World's Largest Corporate Web Site
Published: May 3, 2004
This month’s article describes how a common presentation framework—including XML-based design templates, centralized control of common user interface (UI) elements, and a custom Web handler and rendering engine built on the Microsoft� .NET Framework—is leading to a consistent, reliable experience for visitors to Microsoft.com.
This article discusses business drivers that led us to develop the presentation framework and its common code base. We will cover the business benefits from both the customer and internal perspectives, and delve into the technologies used to deliver the common UI to the Web.
As Microsoft has grown and evolved, our corporate website has evolved as well. Microsoft.com has grown into one of the largest, most visited Internet sites in the world today. The site, which is actually a network of many smaller websites, has also evolved to reflect the global nature of the company. Today, more than 40 percent of the traffic to Microsoft.com originates outside the United States, and the site delivers content in more than 40 languages, tailored for more than 150 locales.
The website has become a critical part of the way customers perceive and interact with the company. For millions of customers, Microsoft.com is the first source they turn to for help and support information, software downloads, and information about our products. Thus, it is vitally important that the site not only meets the needs of our customers, but that it accurately reflects the voice of the company in a coherent, consistent fashion.
Challenges of a Decentralized Model
Originally, Microsoft.com was built on a decentralized Web publishing model. Individual business units and product groups were responsible not only for creating their own Web content, but also for building and designing their own websites, which existed independently within the Microsoft.com domain. Thus, in some respects Microsoft.com was less a centrally managed entity than a loose federation of disparate websites. While this decentralized approach holds certain advantages for the site owners tasked with delivering content to the Web, it has its disadvantages.
Inconsistent Customer Experience
Different groups within Microsoft used different design schemes, different navigational models, and different terminology and labeling, and they offered disparate features and functionality on the pages under their control. Individually, the various design systems and navigational models might have been effective and appropriate to the content presented on those pages; however, customer feedback and usability research indicated that Microsoft.com presented needless variation as customers navigated across the network.
At the very least, variations across the sites in the Microsoft.com network contributed to inconsistency in the way Microsoft presented itself online. At worst, users were confused by the widely varying structure and look of the pages they visited. In short, the flexibility afforded by the decentralized model was contributing negatively to our customers’ experience on the website and their perception of Microsoft as a whole.
The decentralized approach also contributed to internal inefficiencies. Because sites were created and deployed with near autonomy, different teams within Microsoft were developing tools and features that served essentially the same purpose. This parallel development resulted not only in duplication of development efforts, it compounded the effort and resources required to support and maintain the site, as we found ourselves with many different platforms, tools, applications, controls, and technologies deployed.
The lack of a common code base made it difficult to promote standards for editorial, privacy, and security concerns across Microsoft.com. It also made it challenging to implement common authoring tools and publishing processes. As the site grew in size and became more global, the complexities of the decentralized model were making site management even more difficult.
The Move toward a Standardized Model
When we recognized that the fully distributed model might be detrimental—both in terms of customer satisfaction and internal efficiency—we began taking steps to develop a more standardized, coherent approach to presenting content on Microsoft.com. The standards and technologies that support this initiative are largely complete, and numerous sites have already migrated to our rendering framework.
The drive toward coherence began several years ago, with the establishment of editorial and design standards among many of the product sites in the Microsoft.com network. The success of these first initiatives gave us confidence to expand our efforts, establishing a cross-functional team to create standards that are intended eventually to be used globally across the entire Microsoft domain. The most recent effort resulted in the common rendering framework, a Web presentation system that encompasses back-end and presentation technologies as well as editorial and design standards.
By deploying a common code base for Web publishing and establishing coherent standards for design and presentation of content, we hope to achieve the following:
Challenges of Standardization
Establishing standards on the scale of a site the size of Microsoft.com has many inherent challenges. Microsoft.com presents hundreds of types of content, from downloads to a huge range of product information, support information, news, and events, from text to streaming media. Our mission is to establish standards that will accommodate the entire range of content. We strive for consistency in the key areas that our customers use most and rely upon most, yet support flexibility and creativity wherever feasible.
The global nature of the site also presents challenges to the editorial and design system. Centralized control of a global site means that content decisions are much more complex than in the past. Microsoft Web publishing standards must be sensitive to the language, cultural, and geopolitical issues that affect each of more than 40 languages and 150 locales.
Finally, our standards must reflect sensitivity and a common approach to customer privacy, accessibility, and legal issues. It is important that we establish best practices for each of these areas and apply them in a consistent, effective manner.
The Common Rendering Framework
We are attempting to achieve consistency in presentation by deploying a common rendering framework that can be used by any site under the Microsoft domain. Use of XML throughout the rendering framework enables us to separate content from presentation, so that design and editorial standards, common page elements, and functional controls can be developed, applied, and modified independently of the content on the pages.
Common User Interface Elements
We identified three key areas that are common to many pages on Microsoft.com. Because they are ubiquitous and part of every customer’s experience, we focused on these areas as candidates for improving both usability and brand identification of the site.
Masthead and Footer
The masthead is the banner displayed across the top of all pages. The masthead controls many aspects of branding and provides navigational elements to be used across Microsoft.com. The sub-banner and local toolbar can be customized to include navigational elements or menus that are specific to a particular section of Microsoft.com.
The footer is displayed across the bottom of the pages built out by the framework. The global footer (the lowermost row of text and links) includes elements such as legal notices and privacy statements, and cannot be customized or modified by the individual site owners. The local footer is the portion of the footer that can be modified by site owners to include the links that are appropriate to their content.
Figure 1. Masthead and Footer Elements
Primary Content Navigation
Navigation is another feature that varied widely from site to site and page to page across Microsoft.com. Because navigation is so critical to usability and discovery, we decided to standardize the primary navigation as much as possible. We identified two widely used models, both based on existing Microsoft Windows� user interface standards. We performed usability testing as well as market testing on each model. Both were intuitive and easy to use; however, customers strongly preferred the “fly-out” model, where menus appear when the mouse cursor hovers over items in the navigation column (which is rendered on the left or right edge of the screen, as appropriate for the locale).
Figure 2. Primary Navigation Column with “Fly-out” Menus
The other model, which uses expanding menus, continues to be used as an alternative navigational scheme for deeply hierarchical content. (Examples of this navigational model can be seen in the MSDN library.)
The center of the page displays the page’s unique content using a system of XML-based templates. Rather than developing a template system from a purely structural basis, we started from an editorial standpoint. We initiated the design process by analyzing a specific type of content, determining the key elements, identifying required functionality, and deciding how best to display the content.
The result was a set of 15 core templates, which can be used to display more than 80 percent of the content on Microsoft.com. The templates include XML schemas that define the content types and XSLTs to render the display. As more site teams adopt these standards and migrate to the rendering framework, and as we continue to collect customer feedback, we will refine and expand our template set.
The key to our standardization effort is a presentation framework developed on the Microsoft .NET Framework and written in Visual C#�, ASP.NET, XML, and XSLT.
The presentation framework includes a custom Web handler built in ASP.NET. Pages that use the presentation framework have the .mspx filename extension, which is registered in Microsoft Internet Information Services (IIS) on the Web servers. When one of the Microsoft.com Web servers receives a request for an .mspx page, this custom Web handler intercepts that call and passes it to the framework for processing.
The framework first checks to see whether the result is cached. If it is, the page is rendered immediately. If the page is not cached, the handler looks up the URL for that page in the table of contents provided by the site owner (see below) to determine where the XML content for the page is stored. The framework then checks to see if the XML is cached, and either returns the cached content or retrieves the XML from the data store identified in the table of contents file.
Within the file that holds the content for the page, XML tags identify the content template to be used. The framework retrieves the appropriate template and uses a series of XSLTs to assemble the page, including the masthead, the footer, and the primary navigational column, finally rendering the content within the content pane.
XML Configuration Files
The specific elements of each page (for example, the template, branding elements, and locale) are identified in a set of XML configuration files. Generally, site owners maintain the configuration files, which hold information for all the pages within a site. These files are described in the following sections, and the relationships between these files are shown in Figure 3.
Figure 3. Relationships between configuration files.
Main Configuration File
The main configuration file includes the “content handler,” which tells the framework where and how the content for the site is stored. One advantage of the framework is that it allows website content storage in virtually any type of storage system, ranging from flat files to relational databases. The content handler identifies the system used, and it points to the DLL or service used to retrieve content from the repository.
The main configuration file also contains information that tells the framework where the templates for the site content are located. The standard templates created for the framework are stored in a central location; by default, the configuration file points to this central group of templates, but a site could add pointers to one or more additional template libraries if the site requires additional flexibility.
If a site requires specific components be included on its pages (for example custom ASPX controls) these components can be registered in the main configuration file as well. Finally, the main configuration file includes a pointer to the site’s table of contents, which is discussed below.
Table of Contents
Site owners build and maintain the table of contents for their sites, according to an XML schema developed as part of the rendering framework. The table of contents file lists all the pages for a site, identifies page groups, and specifies which pages or groups are to be listed in the navigation column.
The framework allows the individual site owners flexibility in how they build the table of contents. While the framework natively supports a flat file version of the table of contents file, the framework also exposes an interface that allows site owners to create their own file structure. To support the site owners, we provide a tool that offers a graphical interface for creating and editing contents in an XML file. In our experience, most sites use the flat file format; however, some of the largest or most dynamic sites use a SQL Server structure to maintain tables of pages and page groups.
The table of contents file also includes a pointer to the site configuration file.
Site Configuration File
The site configuration file controls the look of the pages by specifying which common elements to include. The file specifies global settings for the site, including the brand to apply, the locale (language and regional settings) to apply, the direction of the text, and the location of the links that appear in the local footer and local toolbar. The configuration file includes references to these elements, which are maintained centrally in separate files.
Using a single configuration file to control global settings for a site dramatically streamlines the process of updating a site or applying global changes to all pages across that site. For example, because the locale setting is registered in the site configuration file—rather than hard-coded into the pages themselves—any changes to that locale are immediately reflected on all pages in the site, and the site owners do not have to touch the pages or the configuration file. Similarly, the site owner can change the brand for all pages by modifying the pointer in the configuration file, without touching the individual pages.
Global Configuration Files
The global brand elements and locale definitions are contained in configuration files that are maintained centrally as part of the rendering framework. For example, one global configuration file includes brand elements for more than 20 Microsoft brands, while separate XML files include all the information for supported locales (including localized strings for common UI elements, language, and other information about how to render content for that locale).
Although the rendering framework enforces a degree of consistency across the sites that comprise Microsoft.com, the framework also allows a high degree of flexibility, not only on the pages, but in the back-end components that store and render site content. While the framework is built on XML and supports flat XML files throughout, it also exposes numerous interfaces that allow site teams to build hooks to their own publishing platforms and tools.
For example, the content management team within Microsoft recently deployed a central content repository built on Microsoft Content Management Server 2002 (MCMS 2002). One of the first adopters of the platform MCMS 2002 service was the TechNet site. To allow TechNet to take advantage of the common rendering framework, their developers wrote an interface between MCMS 2002 and the framework. This interface is identified as the content handler in the main configuration file for the TechNet site. When the framework receives a request for a page stored in the central MCMS repository, the content handler points the framework to this interface, which retrieves the content from the repository in a format that is understandable by the framework.
Adopting the common rendering framework does not limit the ability of site teams to present their content in the manner most appropriate for their audience. Site teams can construct page layouts using any number of framework components to ensure the most effective presentation of their content. In addition to the continual refinement of the framework, planned features will allow site properties to build their own components and construct specific layouts using new and existing components.
Although it has yet to be adopted across the entire Microsoft.com network, the common rendering framework is already showing significant benefits both for our customers and our internal site owners. And because it functions across different audiences, different products, and different countries and regions, the common rendering framework is helping to make Microsoft.com a truly global site.
Better Customer Experience
Customer research has shown us that as websites become more consistent, pages become easier to use and to navigate. The development of a coherent design system—and the widespread application of this system across the Microsoft domain—helps customers navigate more quickly to the content they want, helps them recognize it when they find it, and helps them put that content to more efficient use.
More Efficient Publishing Processes
By adopting a set of common templates, individual site owners make efficient use of shared editorial and design resources. They devote fewer resources to creating and designing pages, and can focus on creating the content that customers need. Site owners also benefit from the usability testing and customer feedback reflected in each of the common templates, and it is easier for them to capture information from customer satisfaction surveys and click-stream analytics.
The XML-based system of configuration files streamlines the maintenance and update of pages that must reflect changes to the brand or other company-wide decisions. Under the framework, changes that were once made page by page across thousands of pages now flow through the entire Microsoft domain automatically. The inheritance process built into the technology ensures that when we change a brand color, or upgrade the functionality of a particular component, those updates propagate automatically to all the sites that have adopted the system, and no additional resources are required to rebuild individual pages.
These efficiencies are also felt at the individual site level. Changes to branding or functionality that apply only to a single site can be made simply in that site’s XML configuration files and inherited by every page within the site.
Together, these publishing improvements ensure that Microsoft makes the best use of its resources and that our content is delivered more quickly, in a way that is easier for customers to find and to use.