Section 20.3. We Like Taxonomies, Whatever They Are


20.3. We Like Taxonomies, Whatever They Are

Well, many heads were throbbing at Microsoft. And an odd and often misunderstood term"taxonomies"began to be heard in corridors at Redmond. Although they share a common x, "taxonomies" and "sexy" are two words that aren't often seen together in public. So when "taxonomies" become a part of everyday conversation, it's a sure sign that an organization is ready for a deeper look into information architecture.

So Microsoft's MSWeb team heard the word and knew that the time had come for a more ambitious approach to improving MSWeb. The teamfewer than 10 people, but populated by an impressive mix of information scientists, designers, technologists, and politically savvy managersbegan to consider what users meant when they called for better (or any) taxonomies. Instead of the traditional biology-inspired definition, Microsoft's employees thought of taxonomies as constructs that would help them search, browse, and manage intranet content more effectively.

In response, the MSWeb team developed a more generalized operating definition of taxonomies that would be more in line with how other employees were using the term. This flexibilitythe willingness to speak the language of clients, rather than rigidly clinging to a "correct" but ultimately unpopular meaningwas key. It set the tone for successful communications between the MSWeb team and its clients throughout the organization.

20.3.1. Three Flavors of Taxonomies

The team defined taxonomies as any set of terms that shared some organizing principle. For example, descriptive vocabularies were seen as controlled vocabularies that described a specific domain (e.g., geography, or products and technologies) and included variant terms for the same concept. Metadata schema were collections of labeled attributes for a document, not unlike a catalog record. Category labels were sets of terms to be used for the options of navigation systems. These three areas comprised the foundation of the MSWeb approach. Better searching, browsing, and managing of information would be achieved by designing taxonomies that could be shared throughout the enterprise.

20.3.1.1. Descriptive vocabularies for indexing

Developing terms to manually index important pieces of content seemed a smart proposition for the MSWeb team. It would complement automated indexing by the search engine, which was currently the primary means of making the site's content available. But creating and applying descriptive vocabularies is an expensive proposition, especially within an information environment as large as Microsoft's. And there are so many different ways to index content, so half the battle was in selecting which vocabularies would deliver the most value to the organization as a whole.

The MSWeb team considered a number of issues when deciding which vocabularies to develop. Not surprisingly, characteristics of the content drove many of the decisions.


Search-log analysis

Queries from MSWeb's search-query logs are stored in an SQL database and can therefore be searched and more easily analyzed. Search-log analysis helped the MSWeb team gauge user content needs in users' own words and determine appropriate vocabulary terms. Studying the search log's most common queries also helped the team get a good overview of which content areas were generally most valuable to users.


Availability

The team looked for decent controlled vocabularies that had already been developed in-house or that were available commercially. Vivian Bliss, MSWeb Knowledge Management Analyst, puts it simply: "Don't reinvent the wheel!" If there's a useful vocabulary out there, it's much cheaper to license and adapt it than to create a new one. Unfortunately, most of the required vocabularies were very specific to Microsoft's content and had to be custom-built in-house.

Other decisions were driven by business context. The MSWeb team considered such issues as:


Politics

The team was careful to talk with content stakeholders about what they felt was needed to make their content more accessible. In some cases, stakeholders were interested both in information architecture concepts and in committing to working with the MSWeb team. Others were interested in neither. Through such discussions, it became apparent which stakeholders were ready to participate and which weren't.


Applicability

Some vocabularies were too specific to have broad value for users across the company. The MSWeb team instead focused on vocabularies with broader appeal and value.

After taking all of these considerations into account, Microsoft narrowed its vocabulary development to the following vocabularies:

  • Geography

  • Languages

  • Proper names

  • Organization and business unit names

  • Subjects

  • Product, standards, and technology names

Developing some of these vocabularies was trickier than you might think. Geography, for example, had to be split into two separate vocabularies: general place names, and locations of Microsoft installations. On the other hand, the subject vocabulary development was simpler than it might have been: its development was constrained primarily to addressing equivalence relationships. The MSWeb team hasn't added extensive hierarchical and associative relationships; that would require a huge effort and take resources away from developing other vocabularies that could provide broad benefits right away. (In the future, the team does plan to selectively address these other relationships as time and resources permit.)

20.3.1.2. Metadata schema

Developed hand-in-hand with controlled vocabularies, metadata schema describe which metadata to use to describe or catalog a content resource. While Microsoft's descriptive vocabularies were driven by content and context, metadata schema were informed more by issues of users and content.

The MSWeb team developed a single schema that has value for both MSWeb and other intranet sites. Borrowing from the Dublin Core Metadata Element Set (see http://dublincore.org), MSWeb's schema was intended to be sufficiently "stripped down" so that content owners would use it to describe resources, resulting in more records and therefore a more useful collection of content. The schema's simplicity was balanced with the goal of providing enough descriptive information to augment searching and browsing by users.

The team also had to ensure that records produced using the schema would include fields useful for resource description, display, and integration with other parts of the information architecture (namely by integrating with search results and browsing schemes). The process used to develop this metadata schema was, in the words of one team member, "down and dirty." Although more polished methodologies exist, sufficient resources were not available at the time for this initial schema development project. For this reason, it was important to structure the schema to include both a required "core" set of fields and the flexibility to support future extensions of the schema by other business units. To date, seven other major portals are using the metadata schema, and many have extended and customized it for their own context.

The schema's core fields are:


URL Title

The name of the resource


URL Description

A brief description of the resource; suitable for display in a search result


URL

The address of the resource


ToolTip

Text displayed for a mouseover


Comment

Administrative information that helps manage a record (not seen by the end user)


Contact Alias

The name of the person responsible for this resource


Review Date

The date that the resource should be reviewed next (default setting is six months from when the record was created or last updated)


Status

The record's status; e.g., "active" (the default), "deleted," "inactive," and "suggestion"; used for content management purposes

The schema has been commonly extended with these optional fields:


Strongly Recommended

Flags resources that are especially appropriate


Products

Terms from the product, standards, and technology names vocabulary that describe the subject matter of the resource


Category Label

Terms from the vocabulary of category labels; used to ensure that the resource is listed under the appropriate label in the site's navigation system


Keywords

Terms from descriptive vocabularies used to describe the resource

MSWeb began to use the metadata schema to create resource records in 1999; since then, over 1,000 records have been created. These fuel the immensely useful "Best Bets" search results and hold huge potential for improving areas such as content management. We'll describe the role of both metadata schema and "Best Bets" at Microsoft in greater detail later in this chapter.

20.3.1.3. Category labels

The third type of taxonomylabels for the categories in site-wide navigation systemswas geared toward providing users of Microsoft intranet sites with navigational context. Category labels help users know where they are and where they can go. The MSWeb team employed a user-centered process for designing navigation systems, relying upon useful standbys as card sorting and contextual inquiry. In Figure 20-1, the category labels are shown on the lefthand side of the screen. Descriptions of nodes, displayed on the righthand side, help catalogers choose the appropriate category label.

Figure 20-1. A subset of MSWeb's category labels, with some expanded to show subcategories


The initial set of category labels was developed solely for the MSWeb portal's navigation system. But because the portal is so widely used and because the revised navigation represented a major upgrade for many users, the owners of other intranet sites began to approach the MSWeb team for assistance in developing their own navigation systems.

The MSWeb team responded by making its user-centered design process and expertise into a service that other site owners could utilize. As collaboration with other sites increases, a "standard" intranet navigation system will eventually be created, likely a combination of predetermined intranet-wide options (e.g., another "core") and a locally determined selection of choices ("extensions") that would be informed by a shared set of guidelines. For now, the transitional stage of raising awareness and providing support to other site owners is considered a great leap forward and a prerequisite to further navigation standardization.

20.3.2. How It Comes Together

The impact of all three taxonomies is clear from the MSWeb search results shown in Figure 20-2. Category labels provide contextual navigation at the end of each "Best Bet" result (the first two displayed) and populate the "categories" site-wide navigation system on the lefthand side. Below that, the "terms" area displays two variants of the search term that come directly from the descriptive vocabularies. The "Best Bet" search results themselves are drawn from resource records based on a metadata schema.

Figure 20-2. All three taxonomies are used to create these search results


MSWeb's "three taxonomies" approach is steeped in traditional library science, which isn't surprising considering the backgrounds of many of those on the MSWeb team. But it's important to note how willing the team was to abandon the traditional library science concepts that didn't make sense in the intranet environment. For example, the team did not try to create "traditional" thesauri for its metadata schema and category label taxonomies. Other standards familiar to the LIS community, such as Dublin Core, weren't initially adopted for MSWeb's metadata schema because they were not appropriate at the time (although the Dublin Core schema may be partially or completely adopted by MSWeb at some point).

20.3.3. The Technical Architecture: Tools for Taxonomies

The MSWeb information architecture is certainly informed by library science ideas. But it's important to remember that the team (not to mention the company) has its share of technical smarts, too. Out of that combined expertise was born a suite of advanced tools for managing MSWeb's various taxonomies. And, as mentioned earlier, we wouldn't be shocked to see these tools on the shelves in the near future.

Figure 20-3 shows a simplified view of the MSWeb technical architecture. The tools are the Metadata Registry (MDR), which is used for storing, managing, and sharing taxonomies used on the Microsoft intranet; VocabMan, which provides access to the MDR; and the URL Cataloging Service (UCS), which is used for creating records based on the metadata schema, category labels, and descriptive vocabularies.

Figure 20-3. A simplified view of the MSWeb technical architecture


VocabMan and the MDR feed terms from descriptive and category label vocabularies into records generated from the metadata schema stored in UCS.

The ultimate goal is the creation of a valuable catalog record that improves searching and browsing for users, and makes content management easier.

20.3.3.1. Creating and managing the taxonomies: VocabMan and the Metadata Registry

VocabMan and the Metadata Registry (MDR) are separate tools that are used together for taxonomy management. The MDR is simply a SQL-based relational database that uses an associative data model to store MSWeb's taxonomies. VocabMan is a Visual Basic client that provides taxonomy specialists with access to the MDR, allows the creation and editing of taxonomies, and supports the creation of relationships between them.

Pictures are definitely worth thousands of words, so we'll let screenshots tell the story of how VocabMan works. The following sequence shows how a taxonomist might find a specific term to see if it is listed in an existing vocabulary, or simply to understand its context in a particular vocabulary.

VocabMan's initial screen (Figure 20-4) displays available taxonomies for MSWeb and for subsites in the lefthand column. These can be either browsed in "tree" format or searched. The fields in the righthand column support the creation of a new "collection" or taxonomy of vocabulary terms.

Figure 20-4. Creating and editing taxonomies in VocabMan


Once an existing taxonomy is selected (in Figure 20-5, the descriptive vocabulary "Geography"), it can be searched or modified from this screen. Note that "Relation to Parent," "Related Terms," "Entry Terms," and "Scope Note" are attributes of a specific term drawn directly from traditional thesaurus design.

Figure 20-5. Selecting a taxonomy in VocabMan


To find a specific term, we can browse the tree on the lefthand side or search on the righthand side (Figure 20-6). Here, "entry terms" are equivalent to variant terms.

Figure 20-6. Finding a term in VocabMan


In Figure 20-7, a search on "Chicago" shows that it is an authorized term in several taxonomiesa test vocabulary, the products vocabulary, and twice in the geographic vocabulary (once as a place in Illinois, and once as a subdistrict in Microsoft's Midwest Sales District).

Figure 20-7. Searching for a term in VocabMan retrieves source taxonomies


After selecting "Chicago" as a place in Illinois, the term is displayed in the broader context of the geographic descriptive vocabulary (Figure 20-8). The lefthand side shows us that Chicago is a city in Illinois, a Great Lakes state, and a part of the United States. On the righthand side, we see that it is a major city in relation to its parent term ("Illinois") and is related to the Chicago Sales subdistrict (no entry terms or scope notes are available for this term). Note that the same interface allows the editing of this term's entry.

Figure 20-8. VocabMan provides context for a taxonomy term


VocabMan can also be used to create thesaural relationships (i.e., hierarchical, equivalence, and associative) between terms within specific taxonomies and between terms in different taxonomies. The screenshot shown in Figure 20-9 has a specific schema (for "Best Bets") displayed on the lefthand side. Highlighting "Keywords" displays the vocabularies associated with this particular schema tag in the "Related Vocabularies" field on the righthand side. "IS Proper Names," "Subjects," and "Organization and Business Unit Names" are the descriptive vocabularies that supply the terms for the "Keywords" tag. ("Pivot vocabulary" is an administrative vocabulary that is not used for indexing.)

Figure 20-9. Viewing a metadata schema's tags and associated vocabularies in VocabMan


20.3.3.2. Creating and managing the records: the URL Cataloging Service

Drawing from taxonomies stored in the MDR, the URL Cataloging Service (UCS) is a "workbench" for creating, managing, and tagging records; it enables the creation of shared catalog records for useful resources in the Microsoft intranet (such as "Best Bets"). It's based on a relational database and uses SQL Server. Like VocabMan and the MDR, UCS was initially designed for use by the MSWeb team, but its value was soon recognized by other groups, and UCS eventually became another service offered by MSWeb to other players in the Microsoft intranet environment.

Using UCS, catalogers create quality resource records that directly improve the user's experience because they can be indexed for searching and browsing. These records are created quite simply: when invoked, UCS displays the metadata schema's attributes as fields within a form. Record creators fill out the form, selecting from category labels to classify the record and from the various descriptive vocabularies available to index the record. Catalogers have access to all the vocabularies stored in the MDR; however, they don't have modification privileges for all records, as do the taxonomists who access the MDR via VocabMan.

The initial screen of UCS (shown in Figure 20-10) describes an array of services, ranging from cataloging resources to link checking. It is accessed from the SAS console, which also provides read access to the MDR. SAS (Search As Service) is the bundle of information architecture and content management services that the MSWeb team offers to other Microsoft business units, and the console is the control panel that MSWeb puts in its clients' hands. (We'll describe SAS in greater detail later in this chapter.)

Figure 20-10. The initial screen of UCS, accessed from the SAS console


In this case, the user can edit or add resource records to any of the three URL sets or collections listed in the lefthand column of Figure 20-10. Catalogers are limited to modifying only those collections that they own and are responsible for; however, the MSWeb team has permissions to modify any collection. This despotism is used benevolently; for example, if a cataloger wishes to create a collection of 60 resources, the MSWeb team might find that 28 of these resources are already cataloged. As the cataloger can "subscribe to" (but not modify) these 28 resource records or incorporate them into his collection, a significant amount of duplicated effort can be eliminated. Figure 20-11 shows a new record being added to the "Best Bets" Collection.

Figure 20-11. Using UCS to add a new resource record


UCS automatically checks the URL of the record to be added to see if one has been created already for that resource. In this case, no record exists, so we'll create a new one, as shown in Figure 20-12. The fields in this form are essentially an interactive version of the metadata schema, and filling them out creates a new record. Note that this process is fairly simple and straightforward, sacrificing a degree of richness and data validation for the ease of creating new records.

Figure 20-12. Filling out the fields of the new resource record


The righthand side of the new form displays the ways it should be indexed, which are encoded in the metadata schema (Figure 20-13).

Figure 20-13. The new record is ready for indexing


These taxonomies draw from the category labels and descriptive vocabularies managed in the MDR. Clicking "Add Terms" brings up a pop-up window for selecting vocabulary terms to be added to the record. These are displayed as hierarchies for easier browsing, as shown in Figure 20-14. Or, if the cataloger prefers, he can search the descriptive vocabularies for terms that match his interest, as shown in Figure 20-15. Search results display a full path"breadcrumb" styleto provide fuller context for the matching terms.

Figure 20-14. The cataloger can browse for a term from a taxonomy associated with this schema


Selecting a term (or "node," as shown in Figure 20-15) displays its relationships to other terms. These thesaural relationships are all stored in the MDR and managed by taxonomy specialists with access to VocabMan.

Figure 20-15. or the cataloger can search for a taxonomy instead (note the helpful information displayed for this node)


On the other hand, if the record for a resource already exists, the cataloger can simply modify the record if it's part of a collection he controls. If it's part of another collection, he can't modify the original record, but he can "subscribe" to that record and add custom tags to it that are locally used (record subscription is described later in this chapter). In all cases, the cataloger can elect to create a duplicate entry.

For example, the cataloger might know from search-log analysis that his site's users are often looking for product information. The product history information at http://msw/products would be an excellent "Best Bet" for his site's users. He enters the URL and learns that two records already exist for this resource (see Figure 20-16). One record is from the MSWeb "Best Bets" collection, and the other is from Microsoft's Museum "I Need To" collection (another high-value record collection used in MSWeb, similar to "Best Bets"). Note that only the URL is the same; the two records have different titles, descriptions, and other metadata associated with them, and different contexts often require different tags. In this case, the cataloger chooses the Museum record for this resource.

Figure 20-16. Two records have already been created for this resource


Because this record was created as part of a separate collection, its core tags can't be modified. However, subscribed records can be extended for local use. In this case, the cataloger can apply the metadata schema extensions that are used by his own collections (Figure 20-17). These fields"Keywords" and "Products"are displayed in the upper-right corner. The cataloger can populate these fields with terms from the descriptive vocabularies that his organization has decided will have the most value for its users and content owners.

Figure 20-17. The selected record, created by another cataloger, can be extended with fields from the metadata schema utilized by this editor's collection


UCS also provides other useful tools for helping manage resource records, including link checking, broken-link reports (Figure 20-18), and a calendar of tasks for periodically revisiting and checking the quality of a resource record. But perhaps the most important aspect of UCS is how well it balances a core of requirements with a flexible set of extensions. By bringing together taxonomies and other resources in a straightforward interface, UCS makes it easy to create more records. Similarly, because UCS supports the sharing of those records, intellectual effort is not duplicated. Sharing is made even more effective by the metadata schema's extensibilityresource records can be better customized for local use, resulting in more incentive to "borrow" rather than re-create. In other words, UCS supports the investment of human capital in the creation and customization of content rather than the duplication of effortsomething all too common in most enterprise environments.

Figure 20-18. UCS's reporting features help catalogers maintain the quality of resource records


This philosophy of flexibility and sharing extends throughout the MSWeb approach and suite of tools. For example, Microsoft's library doesn't use UCS at all, opting instead for its own homegrown tool for creating resource records. However, its tool can access the MDR and its taxonomies in much the same way that UCS does. In this case, flexibility through modularity accommodates other business units' needs (i.e., for a specialized record-creation tool) without forcing them to reject all aspects of MSWeb's approach (i.e., the taxonomies stored in the MDR).

The use of open standards further illustrates this flexible, modular approach. XML is employed in exporting taxonomy terms to tools like UCS and the library's similar tool; other units' approaches could easily utilize XML exporting in the same way. Similarly, XML is employed by UCS as the basis for exporting resource record data to be used as search results by numerous Microsoft intranet sites.

20.3.4. Beyond Taxonomies: Selling Services

The MSWeb team started out with a vision of the very broad but tricky area of taxonomies, and went to work figuring out how they could be built for use on the MSWeb portal. The team tested and developed tools and vocabularies that improve content management as well as searching and browsing of the MSWeb site.

This project has begun to have an impact far beyond the MSWeb site. Other major Microsoft intranet sitesthose for human resources, finance, the library, and the information technology grouphave begun to use some or all of the tools and taxonomies that were developed by the MSWeb team. And more than two dozen major subportals have implemented aspects of MSWeb's search system. How has the MSWeb team succeeded at spreading its gospel through a huge organization like Microsoft when similar efforts at smaller companies often fail?

There are many reasons for MSWeb's success. Let's examine them.

20.3.4.1. Location, location, location

Because MSWeb is the company's major intranet portal, just about everyone in the company uses it94 percent of all Microsoft employees. The site is large and complex, providing the team with ample challenges and a test bed for trying out new solutions. Additionally, MSWeb's enterprise-wide prominence has made for an excellent marketing opportunity for the team's efforts and for information architecture in general.

Indeed, as a candidate site for an information architecture redesign, MSWeb is the ultimate low-hanging fruit: highly visible, frequently used by many in the company, rich in valuable content, important to management, and, finally, managed by an enlightened team that was aware of information architecture. You couldn't ask for a better showcase for the value of good information architecture.

20.3.4.2. Helping where it hurts

Every information architecture project ultimately has two audiences: users and site managers/owners. It's important to make both audiences happy, and the best way to do so is to fix what hurts.

The MSWeb team intentionally selected a major areasearchthat would greatly benefit both users and managers, and designed its taxonomies to specifically improve search performance. Users' experiences with searching were greatly improved through the integration of Best Bets into search results (more on Best Bets below). And the MSWeb team began to help site managers address search, sometimes by simply providing informal consulting, but also in more concrete ways such as providing a centrally managed crawling and indexing service. By encouraging units to develop resource records, the MSWeb team spawned a collection of content surrogates that references some of the most valuable content in the Microsoft intranet environment. And once these records were created, they made for great starting points for site crawlingrobots simply followed the links embedded in the UCS's records.

Just as the prominence of MSWeb gained exposure for the team's efforts, the success of Best Bets validated the MSWeb approach. Both paved the way for improved collaboration between the MSWeb team and many other business units that were players in the Microsoft intranet environment.

20.3.4.3. Modular services

From the very start, the MSWeb team has looked for opportunities to develop its taxonomies and tools in a modular and therefore reusable fashion, and package them as services for the rest of the company. In fact, it's even branded its offerings as "Search and Taxonomies as a Service" (originally "Search as a Service," and still referred to as SAS). The SAS console, displayed in Figure 20-19, provides an excellent visualization of what SAS offers to its users.

Figure 20-19. The SAS console


The MSWeb team recognized that other business units would have a wide variety of needs as well as existing tools on hand to address their own information architecture and content management challenges. It knew that no one could compel those business units to adopt 100 percent of the MSWeb approach. So the team designed SAS to be extremely modular; Microsoft business units could take advantage of some services while passing on others.

For example, SAS offers access to MSWeb's taxonomies through the MDR. Other units can manage and store their own taxonomies through the MDR as well, as long as they are willing to share their work. And to ensure quality in their taxonomies, those other business units can take advantage of taxonomy-related consulting services provided by SAS.

Different business units can access taxonomies from the MDR through the SAS console. Or, because the taxonomies are exportable in XML, units can develop their own interfaces, as did Microsoft's library. This flexibility means that existing tools, homegrown or not, don't need to be thrown out in favor of MSWeb's version. Similarly, XML is used to export search results; this enables another unit's site to leverage the records stored in UCS (assuming that its engine can accommodate XML). Even the MSWeb search interface is exportable since it's written using XSL.

As discussed earlier, metadata schema are extensible, in effect allowing different business units to create customized versions of any schema. Records created using those schema are reusable through a highly flexible subscription process. And last but not least, optional crawling and indexing services are also made available by SAS to its client business units.

All of this flexibility leads to a huge number of possible SAS service configurations. A Microsoft business unit could handle most of its information architecture and content management needs using everything SAS has to offer, or it could operate its own publishing system that only imports taxonomies from the MDR. Or it might choose to go it completely alone. The decision is up to that business unit and is impacted by the factors of users, content, and context that guide all information architecture work.

In the case of HRWeb, Microsoft's human resources portal, the team decided to use most SAS services. SAS was used to:

  • Identify content for crawling and indexing for use in searching

  • Create a category label taxonomy for browsing

  • Create Best Bets specifically for use in the HRWeb portal

  • Classify those Best Bets using HRWeb's category label taxonomy

  • Provide access to the SAS high-quality search engine

  • Export Best Bets search results to HRWeb's site

Perhaps most importantly, HRWeb drew on the MSWeb team's expertise through a consulting relationship. MSWeb staff taught HRWeb's team how to develop category labels through user-centered design (UCD) techniques such as contextual inquiry. The HRWeb team was also instructed in the art and science of cataloging resource records using descriptive vocabularies and the shared metadata schema. The resulting HRWeb site is shown in Figure 20-20.

Figure 20-20. Microsoft's HR group is a full-fledged SAS "client," using all of SAS's services


Currently, most units have small web development-related teams and limited resources, and are just beginning to delve into the sticky topics of taxonomies, searching, and browsing. As they learn about SAS, they are generally quite glad to take advantage of the tools and expertise already developed by the MSWeb team. But as each unit's expertise and budget for information architecture grows, it will likely want to take on more and more control. The flexibility of its service modules will ensure that SAS can be configured to keep up with those changes.

20.3.4.4. Different kinds of flexibility

Aside from a focus on taxonomies, the major components of MSWeb's approachthe tools and a flexible, modular, and somewhat entrepreneurial service modeldraw little from library science. And as noted earlier, the taxonomies themselves, not to mention MSWeb's operating definition of the word "taxonomy," do not adhere to an orthodox library science approach.

This is a different flexibility than the kind that drives the SAS approach. The MSWeb team has been driven by a philosophy built on a flexibility of mind. Although many team members have library science backgrounds, they have left their disciplinary baggage at the door in order to achieve buy-in and support from colleagues from different backgrounds and with different perspectives.

For example, few (if any) graphic designers get excited by the thought of developing taxonomies. But anyone will listen to an open-minded colleague describing a good approach to solving a big problem. Because the MSWeb team was willing to be flexible in its terminology and outlook, it could communicate its taxonomy-based solutions more effectively to colleagues and clients who might be turned off by "library talk." One senior designer on the MSWeb team described his realization of the value of the taxonomy approach and its basis in UCD techniques as the moment he "drank the Kool-Aid." From that point on, he bought into the approach 100 percent.

The team was also successful because it was flexibly designednot just LIS people, but technologists, technical communicators, designers, and strategists. In addition to lending the team more credibility with outsiders, the team's interdisciplinary nature meant that many ideas were explained, translated, and fought over before they were ever exposed to outsiders. Interdisciplinary perspectives lead, as always, to a better and more marketable set of services.

20.3.4.5. Company savings

The MSWeb team members understand the need for baby steps in any significant information architecture project. They've spent years developing taxonomies and supporting tools to use on MSWeb. And they've taken a gradual approach to rolling them out as SAS services to other business units.

But it's also important to note that within three months of launching SAS, nine sub-portals had already implemented SAS-based search on their sites. Two of those had created site-specific category label taxonomies to support browsing, and another was in the process of doing so. All leveraged the MSWeb Best Bets results as part of their own search systems.

Quick adoption of SAS represents success for the MSWeb team, but it has much greater significance to Microsoft as a whole. Besides the benefits to users, which we'll describe in the next section, an incredible amount of labor has been saved. It's estimated that SAS has resulted in a cost savings of 45 person years in avoided work (based on calculating the development effortsestimated at 5 person yearsand multiplying by 9the number of business units that didn't have to reinvent the SAS wheel). These savings were achieved with no increase in the MSWeb team's staffing levels, and what was developed for MSWeb has been completely reusable by other business units.




Information Architecture for the World Wide Web
Information Architecture for the World Wide Web: Designing Large-Scale Web Sites
ISBN: 0596527349
EAN: 2147483647
Year: 2006
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net