Category: Special topic: Intranets

People Finder: Searching Without Logic?

by:   |  Posted on

One of the most frequent tasks on many intranets is finding people within the company. Providing an effective way to search people is thus a key goal in designing intranets. This goal becomes even more important for an organization like Emirates, a leading international airline, which has over 35,000 employees with over 140 nationalities and where more people are likely to use this feature more frequently.

Our intranet provides many applications that have a people finder feature to help staff find each other. The goal in using this feature varies depending on the application and situation. For example, people may want to find a staff to book a meeting or add them to a project team. Whatever the goal, a simple text input field and a Find button are enough to provide the sought-after results. But again and again I have heard complaints about not being able to effectively find colleagues using this feature.

The effectiveness of the People Finder feature is challenged in the following ways:

  1. People misspell names of staff they are searching. (e.g., ‘Vivek’ is spelled as ‘Vevek’; with over 140 different nationalities this is bound to happen.)
  2. Names stored in the database are not in proper format. (e.g., ‘Vivek Deshmukh’ is stored as ‘Vivek D.’)
  3. People are known by completely different names than the one stored in the database. (e.g., In some cultures women change their names after marriage.)


Figure 1: A typical example of not finding a person in staff directory

How can you design a better People Finder application than the one that so often says “Staff not found!”?

Building on users efforts

One idea is to look at what users do with the problem at hand and how they solve it, and then use their efforts to build the application. For our People Finder application we can do this by having a “Did you mean …” feature, which gives alternative name suggestions to users. These suggestions are not built by pre-defined logic but are based on the collective input of users.

In our department, when colleagues don’t find someone on a People Finder application, they try various strategies. These include:

  1. trying different spellings,
  2. asking another colleague for the persons correct name and spelling,
  3. calling the person directly (if they have their phone number), and
  4. checking previous emails to get the exact spelling.

Whatever activity they choose, they make sure that they have the right information to type in the People Finder text box. We need to make use of this effort (i.e., making an error and then fixing it) from the users to build our application. The following conceptual model is my attempt at designing such a system.

Building the application

There are five essential components to this concept:

  1. Build a relation table to store incorrect entries. In other words, store search queries which produced no results.
  2. Determine if the user has found the right person.
  3. Build a relation between the previous incorrect entries with the last correct entry determined in step 2.
  4. Check the strength of relation by observing patterns across all users.
  5. Present strong patterns as a “Did you mean …” feature on the search results page.

Let’s look at each step in detail.

STEP 1: Build a relation table to store incorrect entries.

To explain the concept, let’s take the scenario in which a user Sally wants to organize a meeting with Timothy Campbell using People Finder but cannot find him because Timothy Campbell is stored as Tim C. in the application database. (See Figure 1 above.) Let us store this incorrect entry Timothy Campbell in a database table called “Relation Database Table for Sally” (See Figure 2).


Figure 2: Incorrect entry inserted in the Relation table for Sally

STEP 2: Determine if the user has found the right person.

Next, let us say Sally tries a few more names in the People Finder text box, which generate no results. We store all of these incorrect entries in the Relation table. After a few failed attempts, Sally asks her colleague how to find Timothy Campbell in the address book. She is told his name appears in the address book as Tim C. Sally types the name ‘Tim C.’ and gets a result with Tim C.’s details. Sally adds Tim C. to the meeting list. It is this action of Sally clicking the Add button that allows us to identify a correct entry for the Relation table. (See Figure 3.)


Figure 3: Sally now types Tim Campbell’s name as it appears in the database.

STEP 3: Build a relation between the previous incorrect entries with the correct entry.

We then build a relation between the previous incorrect entries with the first following correct entry (i.e., Tim C.) and add it to another table called ‘Alias’ for the staff Tim C. Think of the Alias table as a ‘People also know Tim C. as …’ list. Note that the basis for saying that there exists a relation between the incorrect entries and the correct entry is the real life observation that people do what they must to find the correct name to type in the search text box. Of course you may get mismatches but this will be taken care of in the next steps.


Figure 4: Tim C. is related with the previously typed names


Figure 5: Alias table for Tim C.

STEP 4: Check the strength of relation by observing patterns across all users.

Next we identify the most common aliases used for finding Tim C. We do this by looking at the Alias table for Tim C. Those aliases that appear frequently are strong candidates to be displayed with a “Did you mean …” feature. In our example Timothy Campbell and Tim Campbell show a good pattern across different users as aliases for Tim C., so we conclude that when people search for Tim Campbell they mean Tim C.


Figure 6: Alias table shows that lot of people type Timothy Campbell or Tim Campbell to find Tim C.

STEP 5: Present common patterns as “Did you mean …” feature on the search results page.

The last step is to present the most common pattern to the users as a “Did you mean …” feature. In our example when -users search Timothy Campbell we present them with Tim C. as a “Did you mean …” feature. We can show additional information like the department, title or a photo of Tim Campbell so that the user can confirm that it’s the person he is looking for.


Figure 7: Implementation of the “Did you mean …” feature

Making the system efficient

The secret to making our system more efficient is eliminating -irrelevant relations. Consider this question: Should you build a relation between an incorrect entry which was entered at 08.30 and the next correct entry entered at 09.20? Probably not! It is very unlikely that the user will search for the same person after a gap of 50 minutes. A time frame of 20 minutes may be more realistic.

Advice on how to go about building such a system

  1. Build a business case
    Building such a system will take time and resources. You will need to present an argument to management why this is important and perhaps make a business case for the effort. Don’t forget to include key stakeholders like Human Resources while presenting the business case. Here are some key points:
    • Users will save valuable time while searching other staff.
    • Colleagues will not be disturbed – their time will be saved.
    • Companies will save on phone bills and employee time.
    • Systems become robust over time without additional work from users or a massive data cleaning effort.
  2. Collaborate and co-ordinate with different IT teams who build applications
    Pepare a list of all applications that use the People Finder feature. Collaborate with the IT teams who are responsible to build these applications and work out a plan to implement the “Did you mean …” feature on the current applications. This task becomes easier if you have a centralized IT team.

  3. Prioritize applications for implementation
    Our system becomes robust when many users use the system. Start implementing the feature on the “Frequently used by many” type of applications first. These applications will give maximum value in shortest amount of time.

The risks

There is a risk that few users can work together to build a strong pattern of, say, “Jerk” with Rob Stevenson, thus manipulating the system. This can be kept in check by doing two things. If your company is like ours (formal and very particular about its image) you can:

  1. Keep pattern strength high especially if the suggestions to users are going to be automatic without human intervention.
  2. In addition to high pattern strength you can include a manual check done by HR admin who can authorize or investigate each strong pattern. To do this you will need to provide an admin interface to HR where they can monitor and dig deeper in to strong aliases.

Going forward

Just as users learn a new system by using it, possibly by making mistakes on the way, a system can also be ”trained" to learn from the users by continuously “listening” to users inputs, while helping users along the way. Though some development effort and technical know-how is required, more intelligent people-finding features on company intranets are essential. There is a long-term payoff, and companies will be saving a great deal in terms of employee time and costs.

Enhancing Dashboard Value and User Experience

by:   |  Posted on

This article is the fifth in a series sharing a design framework for dashboards and portals.

Part 1 of this series, The Challenge of Dashboards and Portals, discussed the difficulties of creating effective information architectures for portals, dashboards and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using such standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part 2 of the series, Introduction to the Building Blocks, outlined the design principles underlying the building block system and the simple guidelines for combining blocks together to create any type of tile-based environment.

Part 3 of the series, Building Block Definitions (Containers), described the Container components of the Building Block system in detail.

Part 4 of the series, Connectors for Dashboards and Portals, described the Connector components of the Building Block system in detail.

In Part 5, we look at ways to enhance the long-term value and user experience quality of portals created with the building blocks by encouraging portability and natural patterns of dialog and interaction around aggregated content.

For the reader’s convenience, this article is divided into the following sections:

A Portal Design Vision: Two-Way Experiences

Recommendations

Metadata

Presentation Standards and Recommendations

Manage Functionality By Creating Groups

Enterprise 2.0 and the Social Portal

A Portal Design Vision: Two-Way Experiences

Portals gather and present content from a wide variety of sources, making the assembled items and streams more valuable for users by reducing the costs of content discovery and acquisition. By placing diverse content into close proximity, specialized forms of portals, such as the dashboard, support knowledge workers in creative and interpretive activities including synthesis, strategy formulation, decision making, collaboration, knowledge production, and multi-dimensional analysis.

At heart, however, aggregation is a one-way flow. In the aggregation model common to many portals, content is collected, organized, and perhaps distributed for use elsewhere, but nothing returns via the same channels. Savvy users quickly see that the greatest value of aggregative experiences and tools lies in their potential contributions to two-way flows. They understand that experiences capable of engaging direct and indirect audiences transform portal and dashboard content into a broadly useful resource for communities of much greater scope and impact. Further, business staff and IT users comfortable in the new world of Enterprise 2.0, DIY / mashups and shadow IT now often create their own information technology solutions, assembling services and tools from many sources in new ways that meet their individual needs.

Accordingly, portal designers should create experiences that support increased discussion, conversation, dialog and interaction, and allow for the potential value of remixing content in innovative ways. We might summarize a broad design vision for two-way portals that synthesizes these audiences, environmental factors and imperatives as follows:

  • Provide users with rich contextual information about the origin and nature of dashboard or portal content; context is crucial, especially in a fragmented and rapidly moving enterprise environment.
  • Improve the quality and consistency of the user experience of aggregated content.
  • Improve the portability of content, making it useful outside the boundaries of the dashboard.
  • Allow dashboard users to take advantage of other tools available outside the immediate boundaries of the portal.

Operatively, this means providing two-way channels that make it easy to share content with others or even "take it with you" in some fashion. The building block framework is ideal as a robust foundation for the many kinds of tools and functionality – participatory, social, collaborative – that support the design vision of two-way flows within and outside portal boundaries.

Recommendations

Based on this vision and my experience with the long-term evolution and usage of many portals, I recommend five ways to enhance two-way capabilities and the overall quality of user experiences designed with the building blocks framework:

  1. Define standardized Convenience functionality that could apply to all blocks. This will provide a baseline set of common capabilities for individual blocks such as export of Container content and printing.
  2. Define Utility functionality offered at the Dashboard or Dashboard Suite level. This captures common productivity capabilities for knowledge workers, linking the dashboard to other enterprise resources such as calendars and document repositories.
  3. Define common metadata attributes for all Container blocks, to support administration and management needs.
  4. Define presentation standards that appropriately balance flexibility with consistency, both within Container blocks and across the user experience.
  5. Define user roles and types of blocks or content to allow quick management of items and functionality in groups.

As with the rest of the building blocks design framework, these recommendations are deliberately neutral in terms of business components and processes, technology platforms, and development frameworks (RUBY, AIR, Silverlight, etc.), and design methods. They describe capabilities and / or functionality that design, business, and technology decision-makers can rely on as a common language when deciding together what a given portal or dashboard must accomplish, and how it should do so. (Besides allowing extension and reuse of designs, neutrality is consistent with the principles of Openness, Independence, Layering, and Portability that run throughout the building blocks system.)

Convenience Functionality

Convenience functions make it easier for users to work with the content of individual Container blocks. Good examples of Convenience functionality include printing the contents of Containers for use outside the Dashboard, or subscribing to an RSS feed that syndicates a snapshot of the contents of a block. Convenience functionality is associated with a single Container, but is not part of the content of the Container.

This collection is a suggested set of Convenience functionality meant to help establish a baseline that you can adapt to the particular needs of your users. Assign Convenience functions to individual blocks as appropriate for circumstances and as endorsed by users, business sponsors, and technologists. Some of these features make sense at all levels of the block hierarchy, and some do not (how would one print an entire Dashboard in a way that is useful or readable?).

The collection is broken into five groups:

  1. Understanding Content Sources and Context
  2. Making Dashboard Content Portable
  3. Controlling the User Experience
  4. Staying Aware of Changes / Subscriptions
  5. Social and Collaborative Tools

The illustration below shows Convenience functionality associated with a Tile.

convenience_functionality_c.jpg

Figure 1: Tile Convenience Functionality (By Group)

Group 1: Understanding Content Sources and Context

Preserving accurate indication for the source of each block’s content is critical for the effective use of heterogeneous offerings. Dashboards that syndicate Tiles from a library of shared assets may contain conflicting information from different sources, so users must have an indication of the origin and context of each block.  (Wine connoisseurs use the term "terroir.")

Show detailed source information for a block. For business intelligence and data content, the source information commonly includes the origin of the displayed data in terms of operating unit, internal or external system (from partners or licensed feeds), its status (draft, partial, production, audited, etc.), the time and date stamp of the data displayed, the update or refresh cycle, and the time and date of the next expected refresh.

For widgets, web-based applications, and content that takes the form of transactional functionality such as productivity or self-service applications delivered via an intranet or web-service, source information commonly includes the originating system or application, its operating status (up, down, relevant error messages), and identifying information about the group, operator, or vendor providing the functionality.

Send email to source system owner / data owner. This allows portal users to directly contact the "owners" of a content source. In enterprises with large numbers of internal data and functionality sources that frequently contradict or qualify one another, the ability to ask clarifying questions and obtain additional or alternative content can be critical to making effective use of the content presented within the Dashboard.

Show performance data and metrics. If standard performance data and measurements such as key performance indicators (KPIs) or balanced score cards (which have risen and then fallen out of favor in the past five years) affect or determine the contents of a block, presenting them readily at hand is good practice. 

Such performance indicators might take the form of KPIs or other formally endorsed metrics, and require:

  • Showing displayed KPIs
  • Showing supporting KPIs (rolled up or included in the summary KPI on display)
  • Showing related KPIs (parallels by process, geography, industry, customer, etc.)
  • Showing dependent KPIs (to illuminate any "downstream" impact)

For performance indicators defined by number and name—perhaps they are recognized and used across the enterprise or operating unit as a comparative baseline, or for several different measurement and assessment goals—provide this important contextual information as well.

Show related documents or assets. Whether automated via sophisticated information management solutions or collected by hand, related documents and assets increase the range and applicability of dashboard content. Bear in mind that less is often more in a world drowning in electronic assets and information.

Show source reports or assets. If the contents of a block are based on an existing report, then providing direct access to that item—bypassing document repositories, collaboration spaces, or file shares, which often have terrible user experiences and searching functions—can be very valuable for dashboard users.

Show related blocks. In large portals or Dashboards that aggregate Tiles from many different sources—perhaps several Tile Libraries—providing navigable links to related Pages or Sections of the Dashboard increases the density and quality of the connections between pieces of content. Whether mapped by hand or automated, these links can further enhance the value of the dashboard by exposing new types of relationships between informational and functional content not commonly placed in proximity in source environments.

Search for related items and assets. If individual Container blocks carry attached metadata, or metadata is available from the contents of the block, search integration could take the form of pre-generated queries using terms from local or enterprise vocabularies, directed against specifically identified data stores.

Group 2: Making Dashboard Content Portable

These capabilities enhance the portability of content, supporting the two-way communication and social flows that make content so useful outside the boundaries of the dashboard. The items below include several of the most useful and commonly requested portability measures:

  • Print contents of block
  • Email contents of block (HTML / text)
  • Email a link to block
  • Create a .pdf of block contents
  • Create a screenshot / image of block contents
  • Download contents of block (choose format)
  • Save data used in block (choose format)
  • Download source report (choose format)

Group 3: Controlling the User Experience

Individual blocks may offer users the ability to change their on-screen layout, placement, or stacking order, collapse them to smaller sizes, or possibly activate or deactivate them entirely. If designers have defined standard display states for Containers (see Presentation Standards and Recommendations below), blocks may also allow users to customize the display state:

  • Change layout or position of block on screen
  • Collapse / minimize or expand block to full size
  • Change display state of block
  • Deactivate / shut off or activate / turn on block for display

Group 4: Staying Aware of Changes / Subscriptions

Aggregation models lower information discovery and acquisition costs, but do not obviate the costs of re-finding items, and do little to help users manage flows and streams of content that change frequently. Many portals and dashboards aim to enhance users’ awareness and make monitoring the status of complex organizations and processes simpler and easier. This group includes functionality allowing users to subscribe to content through delivery channels such as RSS or to receive notices when dashboard content changes:

  • Send email on block change (it is optional to include contents)
  • Subscribe to RSS feed of block changes (it is optional to include contents)
  • Subscribe to SMS message on block change
  • Send portal Page on block change

Group 5: Social and Collaborative Tools

This group includes social features and functions that engage colleagues and others using social mechanisms. Introducing explicitly social mechanisms and capabilities into one-way dashboard and portal experiences can dramatically enhance the value and impact of dashboard content.

When designed properly and supported by adoption and usage incentives, social mechanisms can encourage rapid but nuanced and sophisticated interpretation of complex events in large distributed organizations. Social functions help preserve the insight and perspective of a diverse community of users, an intangible appreciated by many global enterprises.

Annotate block. Annotation allows contributors to add an interpretation or story to the contents of a block. Annotation is typically preserved when blocks are syndicated or shared because annotations come from the same source as the block content.

Comment on block. Commentators can provide a locally useful interpretation for a block originating from elsewhere. Comments are not always portable, or packaged with a block, as they do not necessarily originate from the same context, and their relevance will vary.

Tag blocks. Tagging with either open or predetermined tags can be very useful for discovering unrecognized audiences or purposes for block content, and quickly identifying patterns in usage that span organizational boundaries, functional roles, or social hierarchies.

Share / recommend blocks to person. Combined with presence features, sharing can speed decision-making and the growth of consensus.

Publish analysis / interpretation of block content. Analysis is a more thorough version of annotation and commenting, which could include footnoting, citations, and other scholarly mechanisms.

Publish contents of block. Publishing the contents of a block to a team or enterprise wiki, blog, collaboration site, or common destination can serve as a communication vehicle, and lower the opportunity costs of contributing to social or collaborative tools.

Rate block. Rating blocks and the ability to designate favorites is a good way to obtain quick feedback on the design / content of blocks across diverse sets of users. In environments where users can design and contribute blocks directly to a Tile Library, ratings allow collective assessment of these contributions.

Send contents of block to person (with comment). Sending the contents of a block – with or without accompanying commentary – to colleagues can increase the speed with which groups or teams reach common points of view.  This can also provide a useful shortcut to formal processes for sharing and understanding content when time is important, or individual action is sufficient.

Send link to block to person (with comment). Sending a link to a block – with or without accompanying commentary – to colleagues can increase the speed with which groups or teams reach common points of view.  This can also provide a useful shortcut to formal processes for sharing and understanding content when time is important, or individual action is sufficient.

Commenting and annotation, coupled with sharing the content that inspired the dialog as a complete package, were the most requested social capabilities among users of many of the large enterprise dashboards I have worked on.

Stacking Blocks

Some combinations of Convenience functionality will make more sense than others, depending on the contents of blocks, their purpose within the larger user experience, and the size of the blocks in the stacking hierarchy (outlined in Part 2). Figure 2 illustrates a Page composed of several sizes of Containers, each offering a distinct combination of Convenience functionality.

combinations_convenience.jpg

Figure 2: Combinations of Functionality

Convenience…or Connector Component?

Several of the Connector components (described in Part 4 of this series) – especially the Control Bar and the Geography Selector – began life as examples of Convenience functionality. Over the course of many design projects, these pieces were used so frequently that their forms standardized, and they merited independent recognition as defined building blocks. (The change is a bit like receiving a promotion.)

With sustained use of the blocks framework, it’s likely that designers will identify similar forms of Convenience functionality that deserve identification as formal building blocks, which can then be put into the library of reusable design assets. This is wholly consistent with the extensible nature of the blocks system, and I encourage you to share these extensions!

Utility Functionality

Utility functionality enhances the value of content by offering enterprise capabilities such as calendars, intranet or enterprise searching, and colleague directories, within the portal or dashboard setting. In practice, Utility functionality offers direct access to a mixed set of enterprise resources and applications commonly available outside portal boundaries in a stand-alone fashion (e.g. in MS Outlook for calendaring).

Common Utility functions include:

  • Team or colleague directories
  • Dashboard, intranet or enterprise searching
  • Dashboard personalization and customization
  • Calendars (individual, group, enterprise)
  • Alerting
  • Instant messaging
  • Corporate blogs and wikis
  • Licensed news and information feeds
  • RSS aggregators
  • Attention streams
  • Collaboration spaces and team sites
  • Profile management
  • Document repositories
  • Mapping and geolocation tools
  • Business intelligence tools
  • Supply Chain Management (SCM), Enterprise Resource Planning (ERP), and Customer Relationship Management (CRM) solutions

My Experience or Yours?

One important question designers must answer is where and how portal users will work with Utility functionality: within the portal experience itself or within the user experience of the originating tool? Or as a hybrid of these approaches?

Enterprise productivity tools and large software packages such as CRM and ERP solutions often provide consumable services via Service-Oriented Architecture (SOA) or Application Programming Interfaces (APIs), as well as their own user experiences (though they may be terrible). The needs and goals of users for your portal may clearly indicate that the best presentation of Utility functionality syndicated from elsewhere is to decompose the original experiences and then integrate these capabilities into your local portal user experience. Enterprise tools often come with design and administration teams dedicated to supporting them, teams which represent significant investments in spending and credibility. Carefully consider the wider political ramifications of local design decisions that affect branding and ownership indicators for syndicated Utility functionality.

utility_ux.jpg

Figure 3: Local vs. Source Experiences

Metadata

In portals and dashboards, aggregation often obscures origins, and content may appear far outside the boundaries of its original context and audiences. The Convenience and Utility functionality suggested above is generally much easier to implement and manage with the assistance of metadata that addresses the dashboard or portal environment.

The attributes suggested here establish a starting set of metadata for Container blocks managed locally, or as part of a Tile Library syndicated across an enterprise. The goal of this initial collection is to meet common administrative and descriptive needs, and establish a baseline for future integration metadata needs. These attributes could be populated with carefully chosen values from a series of managed vocabularies or other metadata structures, or socially applied metadata provided by users as tags, keywords, facets, etc.

Administrative Attributes:

  • Security / access level needed for content
  • System / context of origin for content
  • System / context of origin contact
  • Data lifecycle / refresh cycle for content
  • Most recent refresh time-date
  • Effective date of data
  • Block version #
  • Block release date

 Structural Attributes:

  • Container blocks stacked in this block
  • Crosswalk Connectors present within block
  • Contextual Crosswalk Connectors present within block

 Descriptive Attributes:

  • Title
  • Subtitle
  • Subject
  • Audience
  • Format
  • Displayed KPIs (defined by number / name)
  • Supporting KPIs (defined by number / name)
  • Related KPIs (defined by number / name)
  • Related Documents / Assets
  • Source Report / Assets
  • Related Blocks
  • Location

Metadata Standards

The unique needs and organizational context that drive the design of many portals often necessitates the creation of custom metadata for each Tile Library or pool of assets. However, publicly available metadata standards could serve as the basis for dashboard metadata. Dublin Core, with a firm grounding in the management of published assets, offers one useful starting point. Depending on the industry and domain for the users of the dashboard, system-level integration with enterprise vocabularies or public dictionaries may be appropriate. Enterprise taxonomies and ontologies, as well as metadata repositories or registries, could supply many of the metadata attributes and values applied to building blocks.

Presentation Standards and Recommendations

Visual Design and Style Guidelines, Page Layouts, Grid Systems

The neutrality of the building blocks framework allows architects and designers tremendous flexibility in defining the user experience of a dashboard or portal. The system does not specify any rules for laying out Pages, defining grid systems, or applying design styles or guidelines. Responsibility for these design questions should devolve to the local level and context; the architects and designers working on a given user experience must make these critical decisions.

Standards for Containers and Connectors. One of the paramount goals for the building blocks system is to minimize the presence of unneeded user experience elements (no excess chrome for designers to polish!), and maintain the primacy of the content over all secondary parts of the dashboard experience. Even so, aspects of the building blocks themselves will be a direct part of the user experience. Thus setting and maintaining standards for those aspects of Containers and connectors that are part of the user experience is essential.

The many renderings and examples of Tiles and other components seen throughout this series of articles show a common set of standards that covers:

  • Location and relationship of Tile components (Tile Body, Tile Header, Tile Footer)
  • Placement of Convenience functionality
  • Placement of Utility functionality
  • Treatment of Connector components
  • Boundary indicators for Tiles and Containers
  • Boundary indicators for mixed content (block and free-form)

Figure 4 shows one set of standards created for the Container and Connector components of an enterprise dashboard.

standards_view_border.jpg

Figure 4: Presentation Standards for Containers and Connectors

This is a starting set of elements that often require design standards. Architects and designers working with the building blocks will need to decide which block elements will be part of the user experience, and create appropriate standards. (If using lightweight and modular user experience development approaches, relying on standards and structured components, it’s possible to effect quick and easy design iteration and updates.)

Standards For Content Within Containers. Setting standards and defining best practices for layout, grid systems, and visual and information design for the contents of Container blocks will increase the perceived value of the dashboard or portal. In the long term, offering users a consistent and easy-to-understand visual language throughout the user experience helps brand and identify Tile-based assets that might be syndicated or shared widely. A strong and recognized brand reflects well on its originators. Figure 5 shows example standards for chart content in Container blocks.

standards_block_content_border.jpg

Figure 5: Presentation Standards for Chart Content in Container Blocks

Standards For Mixed Building Block and Freeform Content. Setting standards for layouts, grid systems, and information design for the freeform content that appears mixed with or between Containers makes sense when the context is known. When the eventual context of use is unknown, decisions on presentation standards should devolve to those designers responsible for managing the local user experiences.

Container States

The core principles of openness and portability that run throughout the building blocks framework mean the exact context of use and display setting for any given block is difficult for designers to predict. Defining a few (three or four at the most) different but standardized presentation states for Containers in a Tile Library can help address the expected range of situations and user experiences from the beginning, rather than on an ad-hoc basis. This approach is much cheaper over the long-term, when considered for the entire pool of managed Tiles or assets.

Since the on-screen size of any element of the user experience is often a direct proxy for its anticipated value and the amount of attention designers expect it to receive, each standard display state should offer a different combination of more or less content, tuned to an expected context. Using a combination of business rules, presentation logic, and user preferences, these different display states may be invoked manually (as with Convenience functionality) or automatically (based on the display agent or surrounding Containers), allowing adjustment to a wide range of user experience needs and settings. In practice, states are most commonly offered for Tiles and Tile Groups, but could apply to the larger Containers with greater stacking sizes, such as Views, Pages, and Sections.

One of the most commonly used approaches is to assume that a Container will appear most often in a baseline or normal state in any user experience, and that all other states cover a sliding scale of display choices ranging from the greatest possible amount of content to the least. The four states described below represent gradations along this continuum.

Normal state is the customary presentation / display for a Container, the one users encounter most often.

Comprehensive state is the most inclusive state of a Container, offering a complete set of the contents, as well as all available reference and related information or Containers, and any socially generated content such as comments, annotations, and collective analyses. Figure 6 shows a Tile in comprehensive display state.

states_comprehensive.jpg

Figure 6: Tile: Comprehensive Display

Summary state condenses the block’s contents to the most essential items, for example showing a single chart or measurement. The summary state hides any reference and related information, and places any socially generated content such as annotation or comments in the background of the information landscape. Figure 7 shows a Tile in summary display state.

states_summary.jpg

Figure 7: Tile: Summary Display

Snapshot state is the most compact form of a Container block, offering a thumbnail that might include only the block’s title and a single highly compressed metric or sparkline. Snapshot states often represent the Container in discovery and administrative settings, such as in search experiences, in catalogs of assets in a Tile Library, or in dashboard management interfaces. Figure 8 shows a Tile in snapshot display state.

states_snapshot.jpg

Figure 8: Tile: Snapshot Display

Convenience and Utility Functionality

New platforms such as Adobe Integrated Runtime (AIR) and Microsoft Silverlight, and the freedom afforded by Asynchronous Javascript and XML (AJAX) and Rich Internet Application (RIA) based experiences in general, offer too many possible display and interaction behaviors to discuss in detail here.

Accordingly, I suggest designers keep the following principles in mind when defining the interactions and presentation of Convenience and Utility functionality:

  • Convenience functionality is meant to improve the value and experience of working with individual blocks.
  • Utility functionality addresses the value and experience of the portal as a whole.
  • Convenience functionality is less important than the content it enhances.
  • Convenience functionality is always available, but may be in the background.
  • Utility functionality is always available, and is generally in the background.
  • Convenience functionality does not replace Utility functionality, though some capabilities may overlap.
  • Usability and user experience best practices strongly recommend placing Convenience functionality in association with individual blocks.
  • Usability and user experience best practices strongly recommend presenting Utility functionality in a way that does not associate it with individual Container blocks.

Manage Functionality By Creating Groups

Most users will not need the full set of Convenience and Utility functionality at all times and across all Tiles and types of Container blocks. Usage contexts, security factors, or content formats often mean smaller subsets of functionality offer the greatest benefits to users. To keep the user experience free from the visual and cognitive clutter of un-needed functionality, and to make management easier, I recommend designers define groups of functionality, users, and content. Create groups during the design process, so these constructs are available for administrative use as soon as the portal is active and available to users.

Other recommendations include:

  • Define bundles of Convenience and Utility functionality appropriate for different operating units, business roles and titles, or access levels of users.
  • Allow individual users to select from bundles of Convenience and Utility functionality. Customization commonly appears in a profile management area.
  • Create roles or personas for dashboard users based on patterns in content usage, and match roles with relevant and appropriate functionality bundles.
  • Define types of user accounts based on personas, or usage patterns and manage functionality at the level of account type.
  • Define types of Tiles or Containers based on content (informational, functional, transactional, collaborative, etc.). Apply bundles of Convenience functionality to all the Tiles or Containers of a given type.
  • Define standard levels of access for social features and functionality based on sliding scales of participation or contribution: read, rate, comment, annotate, write, edit, etc. Manage access to all social functions using these pre-defined standard levels.

Larger portals may warrant the creation of a dedicated administrative interface. The building blocks make it easy to define an administrative console accessible via a Page or Section apparent only to administrators.

Enterprise 2.0 and the Social Portal

Portals and dashboards that augment one-way aggregation of information with Convenience and Utility functionality can offer diverse and valuable content to savyy users – customers who expect Enterprise 2.0, Web 2.0, and social software capabilities from all their experiences and tools. As these recommendations demonstrate, the building blocks can serve as an effective design framework for portals that serve as two-way destinations.

Many of these recommended Convenience and Utility capabilities now come "out of the box" in portal or dashboard platforms, and the interactions that make them available to users follow standard behaviors in the resulting user experiences.When first identified as valuable for users (almost five years ago), these capabilities almost universally required teams to invest considerable amounts of time and money into custom design, development, and integration efforts. Thankfully, that is no longer the case.

Part Six of this series will explore how the Building Blocks framework solved recurring problems of growth and change for a series of business intelligence and enterprise application portals.  We will review the evolution of a suite of enterprise portals constructed for users in different countries, operating units, and managerial levels of a major global corporation.

The Trouble With Web 2.0

by:   |  Posted on

Today, there is a lot of buzz around a number of topics labeled as "Web 2.0“. Consultants jump on the "Web 2.0" bandwagon and IT vendors desperately struggle to add “Web 2.0” features to their products. But the term is still unclear and nobody has a good definition of what “Web 2.0” is and what it is not. The term was originally coined by Tim O’Reilly in an article describing the changes in business processes and models that have been triggered by new and creative combinations of already existing technologies.

Other “social networking” services (like wikis and blogs) have been added to the Web 2.0 “genre”, generating a new end user experience on the Internet. Many large enterprises are now starting “Web 2.0” projects, their IT departments seemingly eager to show their technological abilities. The “new” is strangely attractive and everyone wants to be on board.

But what is the real core of this new phenomenon? According to the conclusions of Tim O’Reilly the core is not the technology (which has been there for some time) but the emergence of new “patterns” – new or changed business processes and a new concept of the user. These patterns have been put to good use in the World Wide Web. But can they be transferred to a corporate environment, at the enterprise level, as well? Let’s have a closer look on them.

  • the Web 2.0 platform breaks down borders between services
  • Web 2.0 utilizes the collective intelligence of its users
  • Web 2.0 cannot control the process of knowledge creation
  • Web 2.0 is constantly linking knowledge, thereby not protecting intellectual property

The web as platform.

Or the Web 2.0 platform breaks down borders between services

One pattern identified by Tim O’Reilly is a change in the business model of software suppliers. In “Web 1.0” times the web was used only as a transport medium, delivering predefined information (e.g. static HTML pages) to client based software products (e.g. the Netscape browser). In Web 2.0 companies use the web as a platform, using the enhanced technology offering to create web-based applications or services that do not require any installation on the user’s machine (e.g. the Google Search Engine). If the client does not install a program that allows tracking of usage then charging for usage become difficult.

Business models that rely on the sale of personalized or concurrent software licenses will not work anymore. The suppliers will be forced to find another way to charge for their services. To generate income they may use advertisements (like Google) or additional service or content offerings (like “land” purchases in Second Life). Internal IT departments however may have to rethink their funding models, especially if they are funded by various company departments for their services. They will not be able to allocate operating costs per license if they want to be Web 2.0 .

Let’s assume a departmentally funded IT department offers a blog or wiki as a new service. No client installation is necessary, but access can be restricted to the members of those departments who pay for the service. Restricted access, as we will see later, will affect the overall value of a collaboration service and yet is not a fair sharing model – it opens up all sorts of claims for charge reduction on the grounds that the other departments use the service more intensively or in a different manner. A per-capita cost allocation may be a solution, but then the departments might try to overextend service usage as they don’t pay extra for more intensive use. The means of measuring usage and paying for it will have to change in order for the IT department to get paid for its services.

But this new platform pattern implies more than just a change in software distribution mechanisms. Not being bound to a client means these new web services typically do not rely on a single source of data, like a classical application with its own database, but combine data from different sources, enabled by open source protocols and standards. The large number of mash-ups (data combined and displayed in a new and usually creative manner) that have emerged around the Google map function are a good example. With these new service offerings the core competency of the service provider shifts from software development to database management and the ability to combine data that is available on the Web to create meaningful information.

Many internal IT departments face a different situation where access to data and the means to combine them are restricted by departmental boundaries, technological incompatibilities or data security and protection rules. Person-related HR or sales data are among the most protected in a corporate environment, and their usage is highly restricted for good reason. Data security and protection rules will also be a showstopper for externally hosted services. According to Article 25 of the European Data Protection Guideline, issued by the European Commission, personal data may only be transferred to third countries (all non-EU countries) if the receiving country provides an adequate level of protection. US organizations have to qualify under the “safe harbor” program to be able to receive data from a European organization.

But even then the idea of having your company’s most valuable data in an externally hosted application (e.g. the Salesforce CRM), with data transfer over the Internet will be the ultimate nightmare of every company’s IT security officer. The required security prohibits the clever combination and reinterpretation of data that we see on Google maps or elsewhere.

Web 2.0 cannot control the process of knowledge creation.

Or utilizing and enabling collective intelligence

We have seen that the new Web 2.0 services are powered by the ability to combine data from different sources. But where does the data come from and who creates it? The Web 2.0 pattern of “collective intelligence” shifts the task of creating and maintaining data and content from centralized resources to a dispersed user community. The eBay selling platform would be useless without the activities of the millions of sellers and buyers, who are creating the content and a critical mass of offerings that attract other users into using the service. Wikipedia would be a completely empty shell without its users creating and maintaining the content. In his article Tim O’Reilly states that the value of the service is related to the scale and dynamism of the data it provides. The larger the number of articles in Wikipedia the more users will use it as reference, therefore the service gets better the more people use it and contribute to it. Tim O’Reilly calls this the “LOW” principle – “let other’s do the work”. This works perfectly in the Web with its huge user base (according to the statistics already more than one billion people) but will this pattern also work in a corporate environment?

The corporate user base, even in the largest enterprises, is smaller than the user base on the Web which limits the number of potential contributors. If the quality of the service depends on the number of users then companies have a disadvantage compared to the Web-based services. In many interviews end users said that they often prefer to research on the Web instead of using their corporate knowledge resources because they are confused by the complexity of internal search and because the information they can find on the web seems to be more recent. However the reliability of Web-based information that can be edited by everybody is in doubt when comes to hard legal or medical use. Would you be willing to bet your career on a Wikipedia article?

If the quality of the service is improved by the amount of user commitment it will only be successful if a critical mass of users can be attracted. While Web services like eBay, Wikipedia or Flickr have been soaring over the last years, driven by user commitment, corporate services often have a contribution pattern like this:

web2_knowledgecurve.gif

But what attracts users to donate their time and energy to contribute to Web services like Wikipedia or Flickr while not doing so to corporate services? Psychology and economics teach us that there is no such thing as altruism – whatever people do will create a personal return of value for them. This personal value is measured by individual criteria. Respect and prestige, personal reputation, political beliefs or desires, and of course monetary incentives influence the decision as to whether their contribution creates this value. People create an article in Wikipedia because they believe that the topic is interesting or important or because they want to see their name in print, and put pictures on Flickr because they want to share them with others, thereby influencing how they are perceived by others. The value of contributing must be higher than doing something else (e.g. watching a sports game on TV or adding to the corporate knowledge base).

In a corporate environment this might be different as a different set of values becomes dominant. Company vision, goals, or instructions will be added on top of the personal value criteria, together with given priorities changing the decision of what creates value. Of course one big driver for such decisions is the need for an employee to be externally “chargeable”, a typical situation in the consultancy business. If a consultant has to decide whether he spends his time generating direct revenue for the company (and therefore for himself) by working for a client; or having to explain to his supervisor why he choose to improve the internal knowledge base instead he or she will opt for the first alternative. As long as contribution is regarded as less important topic in the corporate hierarchy the priority of knowledge initiatives will go down over time simply because people start to value other things as more important.

So contribution is rational for people if there is a reward. But there is another rationale for people, especially in large organisations. Cooperation within the Web communities is mainly driven by non-monetary values as the contributors don’t receive any money for their input. These communities are networks of specialists who rely on each others knowledge. Investing time to create and contribute knowledge will pay off here because there is no direct competition and other people’s knowledge might help you tomorrow. Small consultant companies may be examples of those tight communities. If there is direct competition people normally tend to change their behaviour. They try to acquire and to protect their special knowledge. The German language even has a special term for this kind of behaviour: “Herrschaftswissen”, which means superiority through withheld or not communicated information or knowledge. Many corporations have answered these issues by centralizing knowledge management into special departments . But Web 2.0 requires involving the largest number of users possible and a centralized approach might not be the right answer anymore. Corporate projects that focus on providing Web 2.0 technologies alone will fail if the companies do not change their rewarding schemes and knowledge management processes. Such projects will need to rethink incentives for participators and to create the time slots necessary for people to contribute. If the corporation wants the genuine benefit from Web 2.0 then they must not underestimate the effort it takes to produce it. Finding a balance between corporate or proprietary knowledge and the free-for-all idea exchange of Web 2.0 services is critical if a corporate IT department wants be benefit from Web 2.0 style services.

Web 2.0 cannot control the process of knowledge creation.

Or the uncontrollable wisdom of the “blogosphere”

Judging by the hype they have created; wikis and web logs (blogs) seem to be an important part of the Web 2.0 patterns. As blogs have spread through the web like wildfire vendors of content management systems are struggling to add this functionality into their applications. Already the term “blogosphere” has emerged as a collective term encompassing all blogs and their interconnections. It is the perception that blogs exist together as an extended connected community or a complex social system. However it is common knowledge that a system composed from several component parts will act differently than its individual isolated components. An ant colony develops complex social behaviour and erects structures – a task a single ant could never perform. While a single nerve cell is only able to transfer electrical impulses the enormous network of synaptical references and trackbacks of the human forebrain enables conscious thought.

Tim O’Reilly states that the blogosphere creates a structure that resembles the human brain. Expressing an idea in a single blog might not change the world, but if this idea is picked up, discussed and commented in a large number of blogs it not only gets the attention of many people – it might get enhanced, developed, refined, challenged and eventually transformed evolutionary into something that might influence the way of the world. Like in the anthill or the human brain this process is not controlled by a single instance – it is driven by the participation and cooperation of many individuals with their individual motives. This absence of a controlling instance allows for creativity, progress of ideas and the expression of individual opinions. The old saying that the whole is more than the sum of the parts is true here. However it is a self-organized process that follows its own rules – forcing or securing this is not currently possible nor probably desirable.

The various discussions on the attempts of some nation states to restrict Internet access within their borders show that organizations that rely on its inhabitants to keep within the existing structures will only tolerate an “uncontrollable” environment up to a certain level and will try to erect restrictions if this environment starts to thread organizational foundations. Using the discussions within a blogosphere to enable the development of new consulting solutions might be welcome to a corporation while critical comments on the latest corporate policies and procedures might not. In some corporate areas where following predefined procedures and processes (e.g. accounting standards) is necessary or where secrets have to be protected an open exchange among employees might not be allowed at all to protect the company interests. And companies who start allowing employees to blog will experience that enforcing control on the blog or wiki contents will be detected and will create strong opposition. Companies have to be aware that open service offerings like blogs and wikis cannot be removed afterwards or restricted in scope without losing employee loyalty or making themselves look like fools in the process. And worse – as the Internet provides a means to get around those blockages that the enterprise might believe are comforting: people might take their internal discussions public.

One other aspect – the strength of a wiki is the presentation of content in a loosely structured, intuitive way, creating a hypertext structure resembling creative human thought processes. As there is no visible hierarchical structure in a wiki retrieving content mainly relies on search. That is why Wikipedia or Google show a large search field on their main pages. This unstructured organisation of content fails if the content itself is highly structured. A law commentary contains the text of the law structured by paragraphs, with some comments or additional materials for each paragraph, sometimes for each sentence. Having a search might help if materials related to a special topic are needed, but if an experienced lawyer needs the latest comment on a certain paragraph he needs a different navigation – he will prefer to select the paragraph directly from a list, browsing through the hierarchy of paragraphs and comments. So wikis are a great tool but not a cure-all.

The Web 2.0 is constantly linking knowledge, thereby not protecting intellectual property.

Or the perpetual beta, mash-ups and new intellectual property

Another pattern Tim O’Reilly points to – most of the emerging 2.0 services will (or should) forever wear a “beta” sticker on their homepages. As the role of the user moves from passive consumer to active participant; the quick and continuous implementation of user driven enhancements becomes a driver for the service provider, especially in a competitive market environment.

Release cycles tend to diminish as deployment does not count for Web based services – users will always get the latest version of the service when (re-)loading the site. While development cycles shrink to days or hours and pressure to continuously implement new features rises quality assurance procedures becomes less important – bug-fixes can be deployed instantly and as long as the users don’t pay for the service they will tolerate errors or will be willing to learn new features by themselves. In a corporate environment this might be different. Deployment delays do play a role, especially when permanent online access is not given or network traffic is limited. Quality of the service and at least a certain operational stability will be more important than speed of delivery, especially if software errors will cause financial damage or threaten the company in other ways. And as corporate applications tend to be more complex than Web services training efforts becomes an important part. So corporate applications cannot be developed and deployed using a “perpetual beta” mode.

One other thing is the focus – while most of the Web 2.0 companies focus on a single product or a small suite of similar services; an internal corporate IT service provider will have hundreds, sometimes thousands of services (and applications) to provide. Release management and portfolio management will be needed to ensure maximum value, which means that development resources might not be able to work on one service the whole time.

Another pattern that follows from this development mode is the emergence of so called mash-ups. As the rapid development relies on “lightweight programming models” (another pattern described by Tim O’Reilly), like scripting languages the security of the code is minimal, exposing the software to the users who are able to use or even “hijack” the existing interfaces to create their own solutions and mash-ups on the existing platforms, combining data from different sources to create new information and knowledge. In some cases (e.g. Google Maps) this is welcome to the service provider as it increases the spread of the service and the data quality it provides – all the users of Google Maps do provide Google with an enormous amount of location data, enabling Google to create the most detailed worldwide Yellow Pages ever seen. However if access to or re-use of the data should be limited (e.g. to paying customers) the Web 2.0 technology might not be safe enough. In business to business relations and also in a corporate environment data protection, security and the protection of intellectual property are issues of huge importance, so an open technology platform will be out of scope. On the other hand this limits companies in leveraging the know-how and creativity of its users. Even the internal use of existing Internet web-based services might cause issues as the company cannot control the service. What if the service provider decides to change, charge for or even discontinue an external service the company has come to rely on? Replacing the service will again create additional efforts to adapt the internal applications, which might outweigh the savings created by the free use of the service.

What now?

We have seen that there are differences between the Web and corporate environments. While the Web is a deregulated environment, with millions of users contributing and easy access to data, corporations have to restrict their users for many reasons, thereby limiting the potential of the Web 2.0 patterns. While Web 2.0 patterns work well in the Web there might be obstacles and issues when they are implemented in a corporate environment without adaptation. “Might” because every company is an individual organization and there are no easy, “one-size-fits-all” solution. On the other hand the Web 2.0 patterns have been proven to be too successful to be ignored.

There is no ready-made solution, only some good advice. The most important and most simple is that corporate behaviours and processes are not changed just by implementing a new IT service. Installing a blog in a formal and hierarchical corporate culture will not change the company in an open and informal community. Web 2.0 patterns will only work if the corporate and even national culture is already responsive to more collaboration and participation or if the implementation is accompanied by other measures to support cultural change. Creating and holding up motivation of users to contribute, seemingly no problem in the WWW with a billion users will be one of the success factors. So corporate Web 2.0 implementation projects have to broaden their scope, have to add structural and cultural change or process redesign to their charter. And those “soft” topics tend not to have easy solutions. So when your IT department or an external consultant excitedly tells you about how they are adding “Web 2.0” to the corporate computing environment: be prepared for a difficult birthing process and adjusting your expectations.

I would be happy to hear about your experiences.

Connectors for Dashboards and Portals

by:   |  Posted on

This article is the fourth in a series sharing a design framework for dashboards and portals.

The Building Blocks are an open system – architects and designers should introduce additional navigation models and mechanisms into the experience as needed.Part 1 of this series, “The Challenge of Dashboards and Portals,” discussed the difficulties of creating effective information architectures for portals, dashboards and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality and users over time. In enterprise and other large scale social settings, using such standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part 2 of the series, “Building Block Definitions (Containers)” described the Container components of the Building Block system in detail.

Part 4 describes the Connector Components in detail.

Overview of the Connector Blocks

The building block system includes several types of Connectors that make it possible for designers and architects to link the different areas of a Dashboard together via a consistent, easily understandable navigation model. The system also ensures the resulting information architecture can grow in response to changing needs and content. There’s no special stacking hierarchy for the Connectors. However, they do have an official stacking size (most are size 3) in order to keep Dashboards constructed with the building blocks internally consistent.

The defined Connectors are:

  • Control Bar

  • Section Connector

  • Page Connector

  • Dashboard Connector

  • Crosswalk Connector

  • Contextual Crosswalk Connector

  • Utility Navigation

  • Geography Selector

Control Bars allow access to deeper collections of similar blocks, such as Tile Groups and Tiles offering narrowly focused content. Section, Page, and Dashboard Connectors offer hierarchically driven navigation paths between larger Containers. Crosswalk Connectors and Contextual Crosswalks extend the capabilities of the default Building Blocks navigation model to include links that express context-driven associative relationships between Containers, regardless of their location within the Dashboard or Portal structure. Combinations of Connectors provide the familiar patterns of paths from a user’s current location to higher or broader levels of the Dashboard, links to items at the same level, links to contextually related items at all levels, etc.

Container Definitions

Each Connector definition includes:

  • Mandatory components

  • Optional components

  • Stacking size

  • Detailed description

  • Example rendering (for illustrative purposes only)

  • Rendering description

Control Bar definition

Mandatory components: Controls for manipulating Container content
Optional components: None
Stacking size: special – can be attached to Tiles, Tile Groups, or Views

Control Bar description

A Control Bar increases the amount of content offered by a Tile, Tile Group, or View by giving users the ability to change the content displayed within the block. Designers attach a Control Bar to a block to increase the effective depth (or scope) of the block’s content. Control Bars allow dashboard designers to increase the depth of a new or existing Container block without increasing the on-screen size of the block or creating a large number of very similar blocks.

One common way of using Control Bars is to allow users to perform repeated tasks on one object that is a member of a group of similar objects. For example, a Tile that allows users to approve or reject purchase orders for one operating unit could be augmented with the addition of a Control Bar. The Control Bar will expand the scope of purchase order approval functionality by allowing the user to choose one or more operating units from a list of all available operating units. The approval functionality itself should appear and remain within the Tile, though the scope may expand with successive revisions of the Tile.

Another common use for Control Bars is to provide tools for choosing different combinations of data parameters for display within a block, such as selecting a single item for focus (or rendering of available data) from a list of many other items of the same type, shifting the start or end dates for a time period, changing a measurement unit or referencing an axis for comparison.

The controls – buttons, sliders, actuators, etc. – in a Control Bar are often rendered as standard form elements such as radio buttons or select lists, or hyperlinks. They could just as easily appear as custom scripted elements, applets, or AJAX / RIA delivered sliders. The types and styles of controls presented should be driven by the guidelines of good user experience design. And perhaps your budget!

A primary benefit of Control Bars is to reduce the total number of blocks necessary for a dashboard – though they do increase the complexity of individual blocks – thereby lowering overall development costs and saving valuable screen real estate. For example, consider a single product that is part of a family of fifteen related products: placing a Control Bar on a Tile that shows the inventory for one of those products allows users to change between displaying the same kind of inventory data for any product in the family, instead of simultaneously displaying fifteen separate Tiles with the same inventory data for all the different products in the family. Control Bars also work well when users need to compare metrics, items, or groups of metrics or items, in a side-by side fashion.

Control Bars attached to stacked blocks retain their functionality. Stacking Containers with attached Control Bars can lead to complex possible permutations of scope and depth for block content. Explore the potential combinations and permutations carefully, especially in regards to security and access rights. Control Bars should not replace functionality already located within a block, or serve as a means of combining wildly different sorts of content together into a single block that is incoherent or inconsistent. I recommend limiting the use of Control Bars to one per Container.

Example rendering:

control_bar.jpg
Figure 19: Example Control Bar

Rendering description

This rendering shows a Tile with attached Control Bar that allows users to shift the focus of the Tile to any of a list of fifteen individual products, chosen via the select list shown. When the user chooses a product, the contents of the Tile refresh to show weekly inventory data for the new product, as well as a reference table and associated documents and links for the same new product.

Page Connector definition

Mandatory components: links to all Pages in the parent Section
Optional components: None
Stacking size: 3

Page Connector description

The Page Connector links all the Pages stacked within a single Section of the Dashboard. The Page Connector typically appears on every Page within a Dashboard, though this is not required. As users navigate from Section to Section, the links in the Page Connector change to reflect the different Pages stacked in each Section. Of course, placing a Page Connector on any Page does not preclude creating other groups of links to other Pages located throughout the Dashboard. The Building Blocks are an open system – architects and designers should introduce additional (Free Form, within the view of the blocks) navigation models and mechanisms into the experience as needed.

Example rendering:

page_connector.jpg
Figure 20: Example Page Connector

Rendering description

This rendering shows the navigation links to Pages appearing in a Page Connector for a Section titled Products, which contains a Section summary page and four other Pages.

Section Connector definition

Mandatory components: links to all Sections in the Dashboard
Optional components: link to Dashboard Home Page
Stacking size: 3

Section Connector description

The Section Connector is a high level Connector that provides a link to each Section making up the Dashboard. The Section Connector typically appears on every Page within the Dashboard, though this is not required. The Section Selector is akin to the ubiquitous global navigation element familiar from many web sites, though its actual content when displayed to a user will vary based on security settings or access rights. The links in the Section Connector should take users either to the Section Summary Page for that Section or to the chosen default Page within the Section. Include a link to any Dashboard Home Page in the Section Connector, especially if it offers unique content not available elsewhere in the dashboard.

Example rendering:

(click on image for larger view)
section_connector_small.jpg
Figure 21: Example Section Connector

Rendering description

This rendering shows the navigation links to Section summary Pages appearing in a Section Connector for a Dashboard that includes a Home Page and five Sections. Four of the Sections are navigable via the Section Connector, the remaining fifth Section – S.5 Administration – is dedicated to administrative uses, and is not navigable or linked via the Section Connector.

Dashboard Connector definition

Mandatory components: links to each Dashboard in a Dashboard Suite
Optional components: None
Stacking size: 3

Dashboard Connector description

The Dashboard Connector allows users with access to two or more Dashboards within a Dashboard Suite to move quickly and directly amongst all the Dashboards they may access, without passing through multiple log-in or authentication interfaces. Dashboard Connectors typically appear on every Page of a Dashboard, though this is not required. The individual links in a Dashboard Connector often point to the Homepage for each listed Dashboard. A less-common linking behavior for Dashboard Connectors is to connect to the last visited Page in each linked Dashboard or to a default Page of the users choosing that is stored as a personalization preference. For administrators and maintenance staff, Dashboard Connectors can offer the same quick and direct access to the separate administrative areas of each Dashboard in a Suite.

Example Rendering:

dashboard_connector.jpg
Figure 22: Example Dashboard Connector

Rendering description

This rendering shows the Dashboard links appearing in the Dashboard Connector for the Business Intelligence Suite described above.

Crosswalk Connector definition

Mandatory components: recurring item (link origin), destination building block
Optional components: None
Stacking size: None

Crosswalk Connector description

A Crosswalk Connector is a direct navigation path between individual building blocks, regardless of origin and destination locations in the Dashboard structure. Crosswalk Connectors provide a hub and spoke style path from many locations to a single destination, rather than a uniquely occurring link between two blocks. Crosswalks often take the form of a recurring name, term, or object that consistently links to another single building block offering content related to the linked item.

Common examples of Crosswalk Connectors include:

  • product names linked to a summary Page or View of the identified product

  • topic terms linked to a news aggregator or RSS aggregator block that shows recent items related to that topic

  • competitor names linked to a profile snapshot or market intelligence block

  • market or product family names linked to sales performance blocks

  • colleague names linked to profile information blocks showing their role, responsibilities, and direct reports

Example rendering:

(click on image for larger view)
crosswalk_connector_small.jpg
Figure 23: Example Crosswalk Connector

Rendering description

This rendering shows all the appearances of a Crosswalk Connector that links the instances of a product name to a destination Page in the Products Section (S.3) titled “Product Focus” (S.3.2), in this case a Page offering detailed information and tools related to a single product.

Contextual Crosswalk definition

Mandatory components: linked term (recurring item), origin contexts associative relationship, destination building blocks
Optional components: None
Stacking size: None

Contextual Crosswalk description

Contextual Crosswalks allow dashboard architects to create a direct link between blocks that is sensitive to context, instead of simply point to point. Contextual Crosswalks typically link a recurring item, such as a product name, to a destination block that varies based on the location of the originating link within the Dashboard’s information architecture. With a Contextual Crosswalk, the destination block of each occurrence of the product name is determined by the location or context of the link within the Dashboard structure; that is, by relying on the users current location to offer insight into the things they are most interested in seeing.

For example, each occurrence of a product name throughout a Dashboard could link either to a block offering inventory information for that product, or to a block offering sales information for competing products. When the product name is located in the Supply Chain section of the Dashboard, it would connect to the inventory block: when the product name is located in the Sales section, the link would connect to the competitor sales block.

Contextual Crosswalks are useful when Dashboards offer a substantial amount of content that addresses several different facets or aspects of an important and recurring topic, term or item. Contextual Crosswalks often appear in the form of a Page showing Views for an item, both of which are chosen via Control Bar to give users ready access to the other available collections of blocks matching the other origin contexts.

Keeping the broader principles of the Building Blocks in mind, it’s perfectly logical for Contextual Crosswalks to link from one of several Dashboards or Portals within a Dashboard Suite to another destination Dashboard.

While Contextual Crosswalks can express any kind of associative relationship, in practice, it’s best to define a limited set of types of Contextual Crosswalk in advance and apply them consistently across the Dashboard or Portal Suite. We know well that complex navigation models increase the work required for designers, developers, users and administrators. Prescribing the available set of Crosswalk Connectors (Contextual and standard) in advance will make it much easier to maintain consistent and easily understood navigation models.

Example rendering:

(click on image for larger view)
contextual_crosswalk_small.jpg
Figure 24: Example Contextual Crosswalk

Rendering description

This rendering shows the navigation paths for a Contextual Crosswalk that links from a number of different origin contexts (or locations) to one of a number of similar destinations within the Products Section of a medium-size Dashboard. The legend on the map identifies the origin contexts and destinations for the Contextual Crosswalk, as well as the linked term: a Product Name. In this case, the Contextual Crosswalk directly links product names in six possible origin contexts (Marketing, Finance, Supply Chain, etc.) with six matching briefings that provide detailed information on the status of a that same product. Those briefings appear as Views available from the Branded Product Focus Page (which contains the Marketing, Supply Chain, and Competitors briefings) or the Co-brand Product Focus Page (which contains the Customers, Regulatory, and Auditing briefings). After clicking the linked product name in the Supply Chain Section, a user navigates to the Branded Product Focus Page (P.3.2), which presents them with the Supply Chain Briefing (V.3.2.2).

Utility Navigation definition

Mandatory components: links to Dashboard Utility Functionality
Optional components: None
Stacking size: 3

Utility Navigation description

This Connector gives users consistent access to the most important utility functions and features for a Dashboard or Portal, gathering ubiquitous links to these necessary tools into a single building block. Utility Navigation should include links to any Utility Function that must be accessible from most or all Dashboard Sections or Pages.

Utility Navigation is typically considered to have a stacking size of 3, meaning it is placed at the Page level of the stacking hierarchy and not within individual Tiles, Tile Groups or Views. This approach is common practice in design settings and enterprise environments where standardized functionality is often supplied by or closely connected to externally defined services supplied via SOA – situations where some sort of dependency links the Dashboard or Portal to another system or environment.

Example rendering:

utility_navigation.jpg
Figure 25: Example Utility Navigation

Rendering description

This Utility Navigation component uses icons to provide links to eight distinct Utility Functions, an enterprise directory, a news feed aggregator, managed documents (Resources), a calendar, enterprise search, KPI driven alerts, prioritized staff updates and personalization settings. As you review the illustrations and examples of Utility Navigation and the other Connectors, keep in mind that no rule from the Building Blocks system requires Utility Navigation to appear onscreen collected together in a single location (though good conceptual and practical reasons for doing so often apply). Likewise, the design decision about how to provide access and use – via icons, text, or other features – should be driven by the particulars of your project and user needs.

Recalling the example business intelligence dashboard designed with the Building Blocks system from Part 1, this illustration shows a Dashboard Page which includes several of the Connectors.

us_products_example_callouts.jpg

This Page includes a Section Connector, a Page Connector, a View and a Tile with attached Control Bars, Utility Navigation (labeled ‘Utility Functionality’ here) and Convenience Functionality (described in more detail in Part 5).

Geography Selector definition

Mandatory components: controls or links for shifting the geographic context of a Container
Optional components: None
Stacking size: special – can be attached to Tiles, Tile Groups, Views, or Pages.

Geography Selector description

The Geography Selector allows designers and architects to decouple the information architecture of a Dashboard from the shifting organizational structures based on geography that many enterprises rely on to understand the fundamentals of their activities. The Geography Selector presents users with controls or links allowing them to change the geographic reference point of a Container, while maintaining the structure of that Container. In the same way that Control Bars increase the depth of a Tile, Tile Group, or View, a Geography Selector increases the scope or depth of a Container while reducing the number of additional Containers to manage. For example, a Geography Selector might allow users the ability to change the focus of a sales activity chart located in a Tile from one US state to another.

Large enterprises often operate in or with reference to multiple states (or provinces, departments, etc.), regions, countries or even continents. These geographic concepts or schemes frequently differ from unit to unit within an enterprise. They often change dramatically from year to year to suit external environmental changes or internal reorganizations. Just as aligning a site map to an organization chart creates a brittle structure subject to disruption during reorganization, tying a Dashboard’s information architecture to an enterprise’s current geographic scheme is a recipe for frustration.

Some Geography Selectors allows users to choose from a single set of geographic units, such as states or counties, with respect to the parameters determining the data shown for a defined set of KPI’s (fixed Containers, variable scope for their content). Other Geography Selectors allow users to traverse a hierarchy of geographic units, with respect to the parameters determining the data shown for a defined set of KPI’s (fixed Containers, variable scope for their content). It’s possible to attach Geography Selectors to Containers with Control Bars. In these cases, the Geography Selector typically drives the Container contents before the Control Bar.

Example rendering:

geography_selector.jpg
Figure 26: Example Geography Selector

Rendering description

This rendering shows a Tile Group with attached Geography Selector and Control Bar. The geographic scheme represented is hierarchical, spanning three tiers, beginning with State, moving to district and concluding with territory. Of course, many businesses use non-hierarchical geographic schemes, irregular schemes, or a combination of these options; in these cases the structure and quality of the underlying data, functionality and business logic may require creative solutions to the problems spawned by unusual intersections of the various choices.

This set of Connectors provides the minimum tools necessary for the assembly of coherent Dashboards across a wide variety of circumstances. I encourage you to refine this starting set, or create additional types of Connectors to meet new challenges.

Conclusion

When combined in a fashion that meets the specific needs and context of a tile-based design effort, the Containers and Connectors can strike a good balance between cost, flexibility, and customization in terms of the user experience, systems and technology efforts and business perspective.

With proper assembly, using the stacking hierarchy and the small set of required elements, the information architect can create a consistent and scalable structure that supports a high quality user experience, lowers development costs and establishes a basis for sharing of resources across the enterprise.
—
Part Five of this series will describe a common set of utility and convenience functionality often used to extend the reach and relevance of dashboard content to other contexts of use, making practical suggestions for following the principles of Openness, Independence and Portability underlying the Building Block system.

Ease of Use Outside the Box

by:   |  Posted on

As user experience designers in an enterprise, we find ourselves knee deep in pixels. Should we use a dropdown element or a set of radio buttons? 10pt or 12pt size font? A broad-and-shallow or narrow-and-deep information architecture? While such design considerations are necessary and important, we miss huge user experience opportunities outside the webpage, outside the website, outside the browser. By tackling inter-application usability opportunities, user experience (UX) professionals can make things easier in a big way.

Ease of Use Outside the Box

Since enterprise usability issues affect the entire organization, even small gains in improved ease-of-use can reap large benefits in aggregate across the entire user base. Whereas we traditionally focus on intra-system usability, we can also advocate inter-system usability, basically greasing the skids between systems so that all systems are easier to use. We could champion the merits of large monitors, decry unrealistically complex password policies while offering password management solutions, and develop easy-to-remember URL shortcuts for all websites that our colleagues access.

Fundamentally, user experience design strives to optimize the efficiency with which users communicate with other users through a computer. Users retrieve, consume, and input information. Within a system, we design the interfaces that allow users to efficiently perform those tasks. But users access systems in context of the environment that they are in. A system’s user experience may be drastically impaired when users access a system in a suboptimal context.

Take an application with a very well-designed user experience, say Apple’s iTunes. Fire it up, search, sort, categorize, play, and buy songs with ease. Well, perhaps not so easily. What if you were running the application on a computer with a 233MHZ processor, 32Mb of RAM, 640×480 monitor, 28.8Kb modem, and one tinny speaker? What if your iTunes password had to be changed every 15 days, must be 12 characters long, and include at least one number and one non-alphanumeric character? What if simply finding the icon to launch iTunes was a chore?

You would have a drastically different (worse) overall user experience than what you’re probably used to, in spite of the application’s well-designed user experience. Software makers understand the impact that the context in which an application is served can have on the user experience that is actually experienced. Hence the ubiquitous “System Requirements” that helps to ensure that an application is being used in its prescribed context.

Clear Path to Information

A primary system task for users is retrieving information. How can we make it easier for users to get the information they need? Unfortunately, we almost always assume an intra-system perspective—one where the information that the user needs is accessible via the system and the user is already in the system. But what if we were to take a step back and look at the larger context in which the system is accessed? What we’d find are multiple usability hurdles between users and information. In fact, there are many hurdles between the users and the applications.< Let’s take a look at three key inter-system usability issues and how they can be addressed: # Viewport size – How much information can you view at a single time? # Authentication – Can you securely and easily log into your systems? # URLs – How easily can you get to your systems?

Even High Def is Low Def

Walk into any big box electronics store and you’ll see the ubiquitous wall of so-called high-def TVs. Great, stunning, crisp pictures – right? But if you were to compare the resolution of the world’s best hi-def TV to that of printed paper, the paper would easily win. The LCD technology that many hi-def TVs use is the same as that of our computer displays. We are constrained with limited information density.

Computer displays are the viewport though which the majority of communications between the user and computer occur. Because that channel is choked by relatively low resolution and small overall area, communication throughput is limited.
Alleviating this problem is easy – increase the display area. Either get a larger monitor or, better yet, get two larger monitors and use a virtual expanded desktop that spans both. Research has shown that users can complete tasks 10% – 44% quicker with larger screens and that multi-tasking was less, well, tasking.[1] With prices of large LCD monitors drastically dropping, you can have such a setup for under $500. The increased work efficiencies that you’ll gain can easily justify the relatively small upfront expense. In fact, usability guru Jakob Nielsen states, “anyone who makes at least $50,000 per year ought to have at least 1600×1200 screen resolution.”[2]

When More Secure is Less Secure

Everyone logs into applications in the workplace. Whether you’re submitting an expense report, entering worked hours, or just logging into an intranet, you have to authenticate yourself as a valid user. The integrity of authentication lies primarily with password policies that govern password complexity and required frequency of change.

A good password is one that cannot be guessed. And there within lies the problem. What is difficult to guess is most likely difficult to remember. This problem is mulitplied when you have many applications that require authentication, each with its own password policy that dictates password complexity and mandatory resetting. So while a hacker may not be able to guess your passwords, you most likely will not be able to remember them either. So what do you do? Do what everyone else does (but knows they shouldn’t) – write your passwords down on the small piece of paper in your desk drawer. Not exactly the most secure practice.

The problem here is that the security folks design their password policies in a theoretical world where they only consider computers and hackers. Make the passwords very strong. But the primary end users, the people who actually log in appropriately, are not considered. The ultimate result is systems that are less secure. People are people. Defining password policies without considering the complete human context in which they are applied results in lower security.

As usability experts we should prescribe password management utilities. Password management utilities lock all your credentials to multiple applications under one master credential. The master credential is often a master password or a fingerprint scan. Once you have authenticated yourself with the master credential, the password management utility can then submit the individual credential to the respective applications as you access them. Since you no longer have to remember each password, you can realistically use tough-to-hack passwords for each application. Because you only have to remember a single master password, you can be realistically expected to use a strong master password.

Do You Speak URL?

It’s not uncommon to have a dozen websites that you need to access in the workplace. You need to go to one website to track your work hours, another for expenses, another for benefits enrollment, and yet another to log help desk tickets. Just arriving at these websites is often a challenge in-of-itself because each has its own long, cryptic URL. This is especially the case with internally deployed applications where the URL may include the server name, port number and even URL parameters.

A URL for an internally deployed PeopleSoft application such as http://psoft-production.hostinghub.companyname.net:8080/asp/ASPPROD/?cmd=login is not uncommon. Using your browser’s “favorites/bookmark” functionality can alleviate the problem, but that still places unnecessary burden on the users to bookmark each website and organize them. Even if the websites are bookmarked well, each time the user has to access a website, he must open his bookmarks, browse, find, and click.

Fortunately, there is an easy to implement solution that addresses the problem. URL “jumpwords” are words that you can type into your browser address bar that take you directly to a website. Think AOL “keywords,” but more persistent because they are integrated directly into existing browser functionality. So rather than having to bookmark http://psoft-production.hostinghub.companyname.net:8080/asp/ASPPROD/?cmd=login to access your Peoplesoft application, you would be able to just type “peoplesoft” in the address bar and you would be taken to the application.

Catching and rerouting the user can only work within an organization’s network (this does not work across the Web in general for obvious reasons). There are two main steps to set it up. First, you must make an internal DNS entry that catches and routes all jumpwords. All jumpwords are routed to a single, simple application page that maps the jumpword to the specific full URL and then bounces the user to that URL. You’ve then literally brought your organization’s websites to employee’s finger tips.

Big Picture Ease-of-Use

Whether designing a user interface or conducting a usability test, we generally assume that the user has already accessed the system in a predefined context. Take a step back and apply ease-of-use fundamentals to the factors that lie immediately outside of individual applications. By keeping our eyes open for opportunities to improve the user experience in a larger context, we can increase the communication efficiency within organizations and use simple solutions to reduce frustration and confusion of the people using the systems.

1.”Meet the Life Hackers”:http://www.nytimes.com/2005/10/16/magazine/16guru.html?ei=5090&en=c8985a80d74cefc1&ex=1287115200&partner=rssuserland&emc=rss&pagewanted=print New York Times Magazine, October 16, 2005
2. “Jakob Nielsen’s Alertbox”:http://www.useit.com/alertbox/screen_resolution.html , July 31, 2006

Introduction to the Building Blocks

by:   |  Posted on

The Building Block System

This story continues the Introduction to Building Blocks Series.

Part 1 of this series “The Challenge of Dashboards and Portals” discussed the difficulties of creating effective information architectures for portals, dashboards, and tile-based information environments using only flat portlets, and introduced the idea of a system of standardized building blocks that can effectively support growth in content, functionality, and users over time. In enterprise and other large scale social settings, using standardized components allows for the creation of a library of tiles that can be shared across communities of users.

Part two now outlines the design principles underlying the building block system, and the simple guidelines for combining blocks together to create any type of tile-based environment.

Overview

The building block system is a packaged toolkit that offers standardization across several layers of an information environment, including the information architecture, the user experience, the functionality, and the metadata. As a potential framework for standardization, it is most important to understand that the building blocks are inclusive rather than exclusive, and that they are neutral with regard to any specific software solution, vendor, package, programming language, system architecture, development platform, business rules, enterprise environment, or user experience design guidelines.

Consequently, adopting the building block system and approach – at the right level of formality for a particular set of business, technology, and information architecture needs – can help resolve some of the many problems inherent in flat portlet-only design approaches (the box of chocolates model) regardless of the context. Potential applications or contexts of use for the building blocks include:

  • Any experience defined by stock portlets
  • Any environment assembled from custom built or customized off the shelf [COTS] tiles
  • Intranets and extranets
  • Content aggregators
  • Collaboration environments and solutions such as SharePoint, eRooms, etc.
  • Personal publishing platforms and group authoring solutions
  • Wikis and other collaboratively authored knowledge organization structures
  • Web-based personal desktop services such as Google and Netvibes
  • Mashups services and platforms such as Yahoo Pipes and Google Gears
  • Social networking platforms such as Facebook, Myspace, etc.
  • The rapidly expanding collections of public domain widgets

The building block system defines two types of information architecture components in detail – building blocks (or Containers), and navigation components (or Connectors) – as well as the supporting rules and guidelines that make it possible to assemble complex user experience architectures quickly and effectively. The block system is not a pre-packaged dashboard or portal design. Instead, it offers modular components you can rely on to work together and grow coherently as the pieces making up a finished dashboard or enterprise portal. Using the blocks will help focus design efforts on the important questions of what content to provide, how to present it to users, and how to manage it effectively.

The complete package includes:

  1. Basic principles and assumptions underlying the block system, and how it can complement other design approaches.
  2. Assembly guidelines and stacking hierarchy which shows how to combine blocks into larger units while ensuring a sound and consistent information architecture.
  3. Modular building blocks of all sizes (Containers)
  4. Modular navigation components (Connectors)
  5. Standardized Convenience Functionality for blocks, which recommends a baseline set of common capabilities such as export of building block content, printing Tiles, etc.
  6. Common Utility Functionality which captures common productivity enhancements and capabilities linking the block-based system to other enterprise systems such as calendars and document repositories.
  7. Suggested metadata attributes for blocks that support administration and management needs, as well as important classes of utility functionality including alerting, syndication, searching, collaboration, and system administration.

1. Basic Principles and Assumptions

A few basic principles inform the design of the building block system and establish its boundaries with regards to other design systems or paradigms. In sum, they outline an open, flexible, well-structured, and internally consistent system. While the building blocks are independent of many constraints for where and how they may be put into effect, they will be most effective when a limited set of assumptions about the underlying environment are true. Those assumptions include the availability of authentication functionality to verify user identities, a role-based security framework that allows security permissions to be set at the level of individual blocks, a reasonably robust network that doesn’t require design for asynchronous use, and standard service levels for source application and system hosting and maintenance to ensure the steady availability of aggregated content and functionality.

Principle:Openness

The building block system is open: using the building blocks does not mean that every piece of content must appear within a Tile (Tiles are the smallest building blocks, the de facto foundation level). In the same way that many sites supported by content management systems include considerable amounts of content that is not directly managed by the CMS, it is easy to mix block-based and free-form content in the same Dashboard or Portal, and even on the same Page. Mixing content may require you to give up some of the benefits of the building block system, depending on your platform and other infrastructure elements, but this is not sufficient reason to try and wedge everything into a poorly designed Tile.

Openness
Figure 5: Openness

Principle: Portability / Syndication

The building blocks support portability and syndication by design, under the assumption that individual building blocks or groups of blocks can and will appear outside their original context or in more than one context (if not immediately, then at some point in the future). With the right IT infrastructure and environment in place, it is possible to share defined blocks of all sizes amongst a suite of integrated dashboards/portals or other environments tailored to different audiences, or with other applications and systems. The structure, presentation, and attributes of the building blocks look ahead to the creation of a large library of assets that diverse consumers throughout the enterprise or in the broader community can use and reuse.

Portability
Figure 6: Portability / Syndication

Principle: Independence

Building blocks are wholly independent of one another, unless stacked together into a larger unit. This means that while one block may offer controls or functionality that manipulate its contents, neither those controls nor that functionality will affect neighboring blocks unless the blocks are stacked together.

Independence
Figure 7: Independence

Principle: Inheritance

The blocks follow a simple inheritance pattern, wherein nested blocks inherit the properties and behaviors of blocks with a higher stacking size stacked above them. (Keep in mind that the literal ‘size’ of a block – what kinds and how much content it can contain – is not determined by its stacking size. The purpose of the stacking size is to assist designers in creating experiences with consistent behavior and structure.) If a block at a higher level offers the ability to change its contents with a Control Bar, these changes affect all blocks stacked inside, cascading down from the highest level of the stack. If a block contains other blocks nested at several levels of the stacking hierarchy, and those blocks offer controls that change their contents, then changes affect all of the blocks nested within (or stacked below).

Inheritance
Figure 8: Inheritance

Principle: Layering

The building blocks work together as a coordinated system across multiple levels of the layer cake that comprises an information environment, from the user experience – visual design, information design, interaction design, information architecture – to functionality, metadata, business logic, and administration. It is possible to use the blocks to effect standardization at the level or layer of your choosing. For example, you could rely on just the presentation standards for identifying Container blocks to establish consistent screen layouts. Or you could put all the aspects of the block system into practice to drive the structure of a suite of integrated sites from top to bottom.

Layering
Figure 9: Layering

2. Assembly Guidelines and Stacking Hierarchy

The building block system relies on a small set of assembly guidelines and a size-based stacking hierarchy to ensure that it is easy to understand how to properly combine blocks together into larger units. The purpose of the guidelines and stacking hierarchy is to maintain the internal consistency of information architectures organized and managed via the building blocks. The hierarchy assigns each block a stacking size, ranging from one to seven, and specifies a few simple rules for stacking blocks of different sizes. To see if it is possible to stack blocks together, compare their stacking sizes in light of the rules below.

Note: The Container blocks will be defined in detail in Part 3 of the series.

Stacking Hierarchy
Figure 10: Stacking Hierarchy
This illustration shows the stacking hierarchy of the Container blocks, from the Tile – smallest, with a stacking size of 1 – to the Suite – largest, with a stacking size of 7.

Here are the assembly guidelines to determine proper block stacking:

  1. It is possible to stack blocks with a lower stacking size (“smaller” blocks) inside blocks with a higher stacking size (“larger” blocks).
  2. It is possible to stack several smaller blocks inside a larger block, for example placing three Tile Groups [size 2] inside a single View [size 3].
  3. It is not possible to stack a larger size block inside a smaller block. This means you can stack several Tiles [size 1] inside a single Tile Group [size 2], but you can’t stack a Tile Group [size 2] inside a Tile [size 1].
  4. It is possible to stack several sequential sizes of blocks together inside a single larger Container. This is the basic pattern for assembling a complex user experience.
  5. It is possible to skip a level of the stacking hierarchy when stacking several layers of blocks, for example by stacking Tiles [size 1] within a View [size 3], without placing them within a Tile Group [size 2].
  6. It is possible to stack different sizes of blocks together at the same level inside a larger Container.

As an example of the last three rules, a single Page [size 4] could include a View [size 3] and two Tiles [size 1] stacked at the same level. Inside the View are one Tile Group [size 2], with two Tiles [size 1] stacked inside the Tile Group, and two additional separate Tiles [size 1].

stacking example
Figure 11: Stacking Example

Social Building Blocks Mechanisms and Network Effects

Thanks to these largely open system principles and flexible assembly guidelines, the building blocks can provide a lightweight skeleton that allows communities and groups of any size to create and use tile-based content and functionality within coordinated structures and processes, and then benefit from the network effects and social mechanisms that common structure and architecture makes possible.

With the support of basic environmental services such as tagging, rating, linking, search or findability, syndication, notification, and clear status signals, the building blocks can enhance well-known social processes or collective effects including:

  • sharing
  • comparison and interpretation
  • synthesis
  • remixing and mashup
  • opportunistic discovery
  • the emergence of collective consensus
  • crowdsourcing
  • exchanges with affiliate networks
  • the formation of specialized sub-communities
  • functional diversification

The building blocks can support all these social and network effects across the continuum of transparency and social involvement, from fully closed enterprises, to private and semi-public forums, to fully transparent or public contexts.

In the near future, Part 3 of the series will define the building blocks in detail.

Better Content Management through Information Architecture

by:   |  Posted on
“To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content.”

Everyone understands the business case for Content Management: Organizations drowning in information can’t learn from, act on, or leverage knowledge and resources trapped in assets that already exist. You lose the content’s value if you can’t find it to use it.

To solve problems like these, business often purchases a technology, assuming the former is a feature of the latter. In the content management world, we hear the same kinds of promises from IT stakeholders, again and again:

  • Our developers will provide forms that authors will use to update content online (and every one will live happily ever after).
  • We will use XML (and every one will live happily ever after).
  • We will buy This software from That vendor—off the shelf—and authors will use this to update content. We will customize These options to match our requirements. (And every one will live happily ever after.)

Unfortunately, business often confuses technology for the solution. Forms, XML, and software won’t manage your content. Neither will they help authors create content, nor do they help you leverage content for later use. When Content Management Systems go wrong – and they frequently do – you can end up with terrible nightmare scenarios:

  • Authors write content, and try unsuccessfully to use theCMS.
  • IT updates content in relevant format and uploads for authors to review. The authors make power point presentations with changes and mail them to IT.
  • IT reviews the PowerPoints and uploads the changes.
  • Authors approve the changes, and IT uploads the final version to the site.

To prevent these kinds of scenarios, we try to customize off-the-shelf systems or develop our own, but… IT and business, focused on issues with technology and business process neglect the system-wide ecology that governs how those technologies and processes will be used.

Four crucial factors govern the success of your content management system

Four crucial factors that govern successful CMSs
To implement a successful content management system, we have to go beyond business process and technology and understand how the organization, as an organism, interacts with and uses its content. Four factors are crucial to ensuring an organization can successfully manage its content:

  • Who will interact with the system? Who will create and manage the content? Also, who will need to find and use the content later?
  • What are we managing? What is mission-critical? What kinds of data do we need to manage?
  • How is the system managed? How is the content authored, approved, and managed? How does theCMS enable your business processes?
  • How is the content used? Who will use it, when, and why? How does this integrate with your Information Architecture?

Framing content management in this way helps move the discussion away from business processes and technology. Several familiar methods and tools can help organizations answer these questions and understand how content is created and managed into the system, as well as found and used out of the system.

Who uses your CMS? Authors, approvers, and users (oh my!)

One of the first steps in implementing a CMS should be to identify theCMS users: who will author and publish content? Gather data through user research and modeling.

Scenarios can reveal how the system will really be used, and personas can help business and IT better understand the goals, skill-sets, and motivations that directly impact how successfully the content management system will be used.

The following questions can be useful during user research:

  • What tools are used to author content? At one large research University, instead of composing content using the CMS’s forms, instructors copied and pasted existing content from old syllabi written in Word.
  • How is content authored? At a financial services consultancy, all content was painstakingly crafted by copywriters. In one city council campaign, content appeared as bullet points in emails (or on a whiteboard) that were translated and uploaded by (seemingly) random volunteers.
  • Do the authors and managers understand and use the information architecture? At a large development bank, authors rarely categorized content because they didn’t understand the interface (or its importance). Figure 1 shows a typical content administration screen. Do content authors and managers understand and use the interface?

cms_categories_edit.gif
Figure 1: A typical content administration interface.

Understanding how people use the content is equally important.

  • Who uses the content? In that city council campaign, the website was written for potential voters, but it was mostly used by reporters and precinct captains.
  • How do they use the content? At a large government agency, the system stored versions to help in production of final documents, but writers used stored versions to find examples to copy and paste from.
  • When do they use the content? One music publication published reviews of new releases as a stream of new content, but access was most common for users researching albums long-after they had come out.

    In addition to helping you better understand your users, personas and scenarios can help you test and validate how the effectiveness of theCMS

What are we managing? Handling mission critical content.

What data really needs to be handled by a CMS? In a utopian situation, the database can manage any type of data or content. In reality, it does not work that way. Content management systems usually do not handle all types of data effectively, so you must prioritize critical data and workflows.

  • Where does the content come from? Is it created in-house? Does it arrive in feeds from outside providers? At a large entertainment website, most content came from licensed feeds from outside providers, but in important cases, content was created by onsite editors.
  • What formats do you need to manage? Large enterprises typically manage office documents created, like Word or WordPerfect files. Do you need to manage multi-media files? PDFs? Flash? Implementing search or a decent taxonomy for these formats is a different ball game altogether, and many content management systems simply do not have the ability to manage them efficiently.
  • How often does the content need to be managed? It often does not make financial sense to manage content that is updated on an infrequent basis. Content management systems typically do not have the ability to present brand vehicles – like annual reports – in formats that are aesthetically pleasing and reflect the company’s branding. That job is best left to your creative and marketing team.
  • What content is most important? Critical tasks deserve special attention. Regardless of how frequently critical content tasks must be completed, their importance may require the system allow you to manage their content quickly and flawlessly.

Along those same lines, it may be better to handle a few types of content well, than to handle all types badly.

A broad inventory that lists types of content, sources, and formats can help you understand the potential scope of content you need to manage. Rating the importance of each type of content can help you prioritize what the system must handle, as opposed to what would be nice.

In the example above, handling annual reports might be nice, but managing product descriptions may be imperative.

Along the same lines, task analysis of both common and critical tasks at your organization can further illuminate types of content to focus on.

Conclusion

To implement content management system that really works, business and IT must think beyond internal processes and technology. If your organization keeps in mind the users who will interact with the content as well as the range of types of content, then your CMS is much more likely to succeed.

However, users and content are only the inputs that go into your CMS. Understanding the content lifecycle is the final missing piece. In part two of this series, I’ll examine additional design methods that can help illuminate the early content lifecycle—how the content is managed—as well as the content’s end lifecycle when it finally lands in the hands of end-users.

The Challenge of Dashboards and Portals

by:   |  Posted on
“In the same way you can create a cost-effective kitchen from a standard components such as cabinets, islands and fittings, it is possible to combine building blocks to create an executive dashboard or enterprise portal to meet your particular needs.”

Executive Dashboards present an interesting array of design challenges ranging in all areas of user experience. Take your pick from a list that includes information and interaction design as well as information architecture. Add to that the business of creating information architecture that can provide a structure for growth and evolution. These challenges will be addressed in a six-part series over the next few months. The first article looks at problems facing dashboards which can be addressed by using a system of components that fit together to form a whole. Much like IKEA uses interchangeable islands, counters, and cupboards to create a custom kitchen, by using a system of tiles, it is possible to create an executive dashboard that effectively serves all its users.

The executive dashboard is a portal that combines business intelligence systems and browser-based applications to summarize the status of a complex enterprise for senior decision-makers. Like all portals, dashboards integrate a variety of content and functionality. Integration lowers the acquisition costs of finding items from multiple sources. It also increases the value of each individual tool and content asset through grouping to help decision-making and understanding.

But integration may also emphasize the differing, and sometimes conflicting, origins of the content, highlighting differences in the contexts, forms, and behaviors of dashboard offerings. The challenge is to create an effective user experience unifying these variations into a cohesive whole while preserving the meaning and identity of the individual assets. These challenges exist in all areas of user experience, from information design and interaction design to information architecture. Establishing sound information architecture capable of providing a consistent structure for growth and evolution for dashboards is particularly challenging.

Portlets: MIA (Missing Information Architecture)

The portal paradigm (collections of individual portlets in a single environment) is, so far, the most useful and familiar approach to these user experience challenges. I call it the “box of chocolates” model, because it packages a large number of different elements, while keeping each piece in its own compartment. The portal paradigm has two great strengths. First, it is a simple design approach, easily understood by users, business sponsors, and development teams. Second, it addresses many of the user experience design challenges associated with dashboards. It does this by breaking large collections of widely varying content into a series of well-defined and self-contained units. These units then present individual problems of information design and interaction design which can be solved one at a time, independently. It’s a classic divide-and-conquer strategy that is successful because it is so simple.

From the perspective of information architecture, however, depending on compartmentalization and self-containment is not a complete solution. In the short term, separating items in this way helps manage some of the user experience complexity. Over the long term, it results in two significant weaknesses.

First, self-contained portlets cannot be combined easily to address the need for larger and more flexible communication, beyond the single chunk of information. Portlets are a one-size-fits-all solution to the many-sizes-at-the-same-time problem. The goal of a dashboard is to synthesize disparate information, at multiple levels of granularity and size, into meaningful packages that can be shared among leaders, each with their own perspectives. Facilitating such communication is a primary purpose of most executive dashboards.

Second, portlets are inherently flat, or two-dimensional. Flat portlets alone cannot provide a scalable, adaptable framework for growth and change within a consistent information architecture. Two-dimensional portlets will work is cases where information architecture is not a challenge (i.e., when a dashboard shows a small set of critical key performance indicators or functions to a select audience on a single page or screen) But as the amount of content and functionality (hereafter referred to simply as “content”) grows, the number of portlets increases. This is often the case with many successful enterprise portals and executive dashboards. As word spreads about the usefulness of the dashboard, new audiences and users with differing information needs will join the early adopters, challenging the single view of the dashboard’s range of content offerings.

Dashboard teams may face issues of poorly integrated or conflicting content, reduced usability, navigability, and findability, and a poorer quality user experience. Portlets can only deal with unmanaged growth by sprawling horizontally. Though convenient in the short term, flat portlets lack the capability to provide useful and adaptable structure in the long term. Such horizontal sprawl is similar to the real world example of unmanaged residential growth around major cities – a pattern resulting in urban sprawl, traffic congestion, social isolation, and high ecological impact combined with low energy efficiency.

Escaping flatland

“Building blocks offer standardization, modularity, and interoperability at multiple levels of the information environment, as well as in the user experience.”

After encountering these weaknesses in a number of dashboards, I developed a simple set of information architecture building blocks to introduce depth and structure to flat dashboards. These building blocks allow for the rapid creation of larger units of content from smaller chunks of information, and support the goal of easily managed enterprise IA. The building blocks offer design teams modular information architecture components designed for assembly into larger combinations that scale effectively and respond to change. In the same way that you can create a unique but cost-effective kitchen from standard components such as cabinets, islands, fittings, and appliances, you can combine these building blocks to create an executive dashboard or enterprise portal that meets your particular needs.

The basic building block is a flexible component called a Tile. Tiles combine with other Tiles and building blocks to form larger, more complex units for content and functionality. Tiles and the other building blocks simplify the addition and removal of content, provide a basis for access and security controls at all levels, offer standard metadata attributes to simplify syndication and semantic issues, and make it possible for users to move about within the dashboard using consistent navigation flows. Together, the building blocks provide a sound information architecture for content required by business and a means of managing growth and change. Building blocks offer standardization, modularity, and interoperability at multiple levels of the information environment, as well as in the user experience.

Here’s an example of a complex dashboard designed with the building block system. The image shows a portion of a business intelligence dashboard displaying content related to products sold by the U.S. subsidiary of a global pharmaceuticals company. Many of the different building blocks appear in this single screen: a Section Connector, a Page Connector, a View, Control Bars, several varieties of Tiles, Utility Navigation, and Convenience Functionality. Present but not visible are common metadata, access definitions, and other infrastructure attributes. This screen illustrates several of the basic guidelines and principles of the building block system: openness, inheritance, independence, and layering. This screen also shows effective stacking of smaller building blocks. In this case, several Tiles are stacked within a View, which is itself part of a Page, to create a larger unit of content available for syndication to other enterprise systems.

us_products_1_example_thumb.jpg
Figure 1: Example Dashboard Screen, Products Page (Click to enlarge.)

us_products_example_callouts-1_thumb.jpg
Figure 2: Dashboard Screen: This overlay outlines the individual building blocks that make up the Products page (Click to enlarge.)

A vision: syndicated assets for enterprise portals

The building blocks provide a strong foundation for the executive dashboard as an individualized console or executive information system. They allow the dashboard to offer different users a tailored subset of a larger pool of shared information and functionality assets.

This vision is based on a collection of building blocks for sharing and syndication: a Tile Library. Because the blocks represent standardization across many levels of the information environment, the Tile Library itself could take form at one or more of these levels. In enterprises lacking information infrastructure (such as a robust integrated enterprise applications layer or a strong semantic framework of enterprise metadata), the Tile Library might exist as a set of defined UX and IA blocks requiring custom technical design and system integration efforts. In enterprises with stronger, more mature information infrastructures, a Tile Library could take the form of a repository of building blocks users may access as services and assemble into new configurations labeled Dashboards, Enterprise Portals, or something else.


Figure 3: Tile Library

When used in environments with infrastructure capabilities such as single sign-on, distributed security and access management, discoverable web services, and integrated enterprise applications (EAI), this system of building blocks allows sharing and reuse of defined blocks among applications of all sizes and complexity. Widespread adoption and implementation of web services, XML, enterprise metadata, and enterprise security protocols make this both possible and practical.


Figure 4: Vision: Shared Enterprise Assets / Tile Library

In this vision, the dashboard is the conduit through which a consumer can access and manipulate assets from a common library managed and governed as an enterprise resource. It is possible to imagine an integrated suite of dashboards relying on common architectures (information, user experience, and systems) and coordinated management or governance apparatuses working together to satisfy the needs of a diverse enterprise leadership.

This is the first in a series of articles about executive dashboards and portals. Part two will address, in detail, the use of Tiles as bulding blocks for an effective enterprise portal.

Succeeding at IA in the enterprise

by:   |  Posted on

As information architects, the core of our profession rests on the analysis of information, the identification of structure, the creation of taxonomies and site maps, and the development of wireframes and user interfaces. These skills are well-honed, and we play a significant role in the design and creation of many systems, from websites to web 2.0. The real challenge is making things happen and getting users to adopt the new solutions

Working within the enterprise, we are confronted with new challenges. There is a lack of clarity around needs and goals, organisational issues are paramount, and the real challenge is making things happen and getting users to adopt the new solutions.

This is the focus of what is often called “enterprise IA”, the application of information architecture in complex business environments. To be successful in these situations, we need skills and strategies that focus much more on people than on information.

This article explores some of the approaches needed to ensure that we are successful at implementing IA within organisations, with the goal being to encourage further discussion in the community about these issues.

Business strategy At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

More than any other skill set, enterprise information architects need to have a strong understanding of business strategy and planning. With so many possible issues to solve, the greatest success is achieved when activities are designed to support organisational strategy and to deliver tangible business benefits.

In practice, this includes:

  • Building a strong understanding of overall corporate strategy and directions.
  • Using this knowledge to select projects that will support organisational goals.
  • Designing projects to deliver tangible and visible benefits within the organisation.
  • Developing project plans that will deliver “quick wins” while building momentum for longer-term activities.
  • Conducting good project management, including working within project constraints and maximising the use of project resources.

At the end of the day, enterprise IA projects need to be able to demonstrate that they have made a real and measurable difference to the core activities of the organisation.

Top down and bottom up

Successful enterprise projects follow both a “top down” and “bottom up” approach that combines overall business strategy with an in-depth understanding of staff needs and issues.

This is illustrated in the following diagram:

Enterprise flow diagram

For an information architecture project, this means:

  • Working with senior management to obtain strategic input, including overall business goals and objectives.
  • Conducting in-depth research with key staff groups to identify major staff issues and needs.
  • Using the strategic view as a “lens” to select key activities that both support business goals and meets the needs of staff.
  • Developing a set of tactical (short-term) strategic (longer-term) activities to deliver improvements to information management within the organisation.

While this is not the only way that an enterprise IA project can be managed, it demonstrates different approaches that must be explored by information architects when addressing complex business problems.

Understanding staff

User research techniques such as interviews, focus groups, contextual inquiry, and workplace observation are well understood and widely practiced by most IAs. While these techniques are important in general IA projects, they are critical for enterprise IA activities.

For a typical website project, the starting point is to define goals, objectives, and broad functionality. Research is then done to determine the best way to design and deliver the solution, with user-centered methodologies driving interface design and site structure.

Within the enterprise, the order is reversed. The starting point, as outlined earlier, is to conduct research with staff. The purpose is to identify the needs and issues of staff, which then helps define the goals and scope of the project.

This research is much more open-ended than typical user-centered design. Staff aren’t asked questions about the intranet, portal or document management system. Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate. In practice, we’re looking for issues and needs that we don’t even know to ask about. (The “unknown unknowns”, to quote a now-infamous speech in the US political arena.)

This approach is much closer to ethnography than user-centered design, and we can learn much from this discipline when working within the enterprise. By building up this depth of knowledge, we can target the most important needs, confident that the solutions delivered will be useful (and used) in practice.

Organisational change

Enterprise IA projects are only successful when delivered solutions are actually used by staff. While this is more certain when solutions are based on an in-depth knowledge of staff needs, a comprehensive change management plan will still be required.

Organisational change becomes a key element of enterprise IA projects. Information architects working within complex business environments need to have a strong understanding of organisational culture and how to work effectively within it.

For example, the greatest enemy of our projects is not active resistance, but apathy. While information problems within the organisation are generally widely known, they are not seen as sufficiently urgent or important to be addressed as a matter of priority.

Enterprise IA projects must start by creating a sense of urgency within the organisation. A strong message and vision must be created for the projects, and communicated widely to build support at all levels of the organisation.

Technology

Enterprise information architects must be prepared to work across technology boundaries. This is about delivering a single user experience that provides a seamless work environment regardless of what technology is used behind the scenes.

This means that enterprise IA projects must at least have an understanding of:

  • intranets
  • content management systems
  • document and records management systems
  • collaboration tools
  • applications and databases

This is not to say that enterprise architects need to be technologists or developers. In most cases, enterprise projects will be supported by IT teams and departments that provide specialist skills in these areas.

Enterprise IAs must, however, understand enough of these technologies to create solutions, taxonomies, and designs that help to bring these systems closer together, towards the goal of a single user experience.

Working with others

There are many disciplines that are working to solve enterprise issues, including:

  • knowledge management
  • content management
  • information management
  • document and records management

There is no one group that “owns” the problem, or has all the skills, tools and resources to solve it. While each group has its own models and metaphors, each successfully addresses at least part of the overall problem.

This is where we need to build our skills in working with others, what Lou Rosenfeld calls our “horse trading” skills. This is not just about working in multi-disciplinary teams, it is about working with key individuals from other teams, business units or even divisions, all reporting through different chains of command.

(This is where establishing a “community of practice” focusing on enterprise issues can be very helpful. This approach is actually drawn from the knowledge management domain, further demonstrating the need for collaboration between disciplines.)

Successful enterprise IAs are those with people skills, perhaps ahead of their specialist skills in card sorting, taxonomies, wireframes, and paper prototypes.

A call to arms

The need to deliver better solutions within organisations is great. When driven solely by technology, enterprise projects almost invariably deliver unusable interfaces and poorly structured information that generates considerable resistance to change.

While information architects are not the only group working within the enterprise space, there is the opportunity to demonstrate leadership in delivering effective projects and solutions.

If this is to occur, then the information architecture community needs to build its knowledge in the areas of business strategy and organisational change. We also need the people skills to work well with many other groups within the enterprise, each of whom contributes some part of the overall solution.

This is not to say that all information architects need these skills. Designing interfaces and structuring information is a worthy challenge, and it remains as the core of information architecture.

Space must be found, however, to discuss and explore the unique challenges encountered within the enterprise. We must recognise that a strategic view is equally important as professional design expertise and enterprise information architects must be supported in their quest for best-practice approaches and techniques.

So much more can be written about enterprise information architecture, and this article merely scratches the surface. It is hoped, however, that it will contribute to the discussions in this space, and to help raise the visibility of issues already being wrestled with by information architects in many organisations.

Final words In an ideal world, information architects will be part of a broader team …. we must understand organisational issues, but are not responsible for resolving them.

All of this is not to say that information architects need to become specialists in business strategy and organisational change. We will certainly not be hired to develop business strategy for organisations (and nor should we be!).

In an ideal world, information architects will be part of a broader team within an organisation that includes change managers, professional communicators and other specialists. As part of this team, we must understand organisational issues, but are not responsible for resolving them.

In practice, however, information architects often work alone or in small teams. Even large corporations often leave IA projects with only modest support and resources, perhaps due to a lack of understanding of the full challenges involved in delivering enterprise solutions.

In these cases, information architects are then faced with two choices: become more proficient in the areas outlined in this article, or narrow the scope (and expectations) of the project.

In either case, enterprise information architects will always benefit by having at least a core knowledge of organisational issues and approaches.

Further reading

The fields of business strategy and organisational change are well-developed and supported by many highly effective resources. In particular, the following books have strongly influenced the author when addressing enterprise challenges:

  • Leading Change (John P. Kotter; ISBN 0875847471) – this provides a very practical methodology for creating and driving change within an organisation. Required reading for every information architect.
  • The Heart of Change (John P. Kotter, Dan S. Cohen; ISBN 1578512549) – a companion volume that explores the role of storytelling in organisational change, providing many powerful examples of real situations.
  • Good to Great (Jim Collins; ISBN 0066620996) – explores why some organisations make the jump from “good” to “great”, based on extensive empirical research. Provides many insights that are valuable in enterprise IA projects.

Beyond this, there are many articles, journals, and training opportunities that can be used to build expertise in the fields of business strategy and organisational change. Once core IA skills have been developed, enterprise information architects should switch their focus to exploring these areas.

About the author
Portrait of James Robertson

James Robertson is apparently the “intranet guy”, or so he was told at the IA Summit in Vancouver . He runs Step Two Designs , a consultancy based in Sydney , Australia , and has written over one hundred articles on intranets and content management, which can be found on his site. He also has a blog, the writing of which gives him something to do each morning while his brain warms up.

Making Knowledge Management Work on your Intranet

by:   |  Posted on
“ …a genuine commitment to knowledge management (KM), a KM strategy centered in the application of knowledge towards specific business objectives, and tactics that use the company intranet as a platform to further those KM initiatives, will go a long way in realizing new organizational value.”

Introduction
In the information economy, the longevity of an organization is based as much on the sophistication of its knowledge management practices as it is on traditional differentiators such as the strength of its products, the talent of its employees, and its marketplace reputation and partner relationships. Simply speaking, as actionable and insightful information becomes the currency of an organization, there are few other ways to tap into any latent potential lost in the office corridors.

There is no one-size-fits-all, cost-effective knowledge management solution; nor is there a specific technology, product, or vendor offering that can help you differentiate yourself through your knowledge management practices. But a genuine commitment to knowledge management (KM), a KM strategy centered in the application of knowledge towards specific business objectives, and tactics that use the company intranet as a platform to further those KM initiatives, will go a long way in realizing new organizational value.

This article discusses typical KM challenges facing large organizations and how a company intranet can be leveraged to create lasting and measurable business value. It does this by examining the relationships between two aspects of knowledge management and how they contribute to a goal-oriented knowledge management initiative. The aspects of knowledge management discussed are people (in the form of communities of practice) and enterprise intranets as knowledge platforms.

What is knowledge management?
The first question often asked is what really is knowledge management? Is it simply the cataloging of all the documentation that resides on server hard drives, Outlook inboxes, and the filing cabinets of employees? Or is there something more scientific and strategic about it? Is it an archiving function appropriately delegated to a support team, or should it be something on the CEO’s radar?

The American Productivity and Quality Center defines knowledge management as “the strategies and processes of identifying, capturing and leveraging knowledge” (APQC, 1996 cited in Atefeh et al., 1999 p.172). For the learnings to be retrieved and reused, they need to be qualified and codified so that they are accessible and searchable. Furthermore, knowledge management can also include strategies to foster a culture of information sharing and the implementation of tools that make it easier for employees to share their learnings and, in turn, to learn from each other.

Typical KM challenges
All organizations are practicing KM in some fashion today. Sometimes these are management mandated, focused, and structured initiatives such as procedures to capture customer feedback on product features to help design new products. In other cases, they are basic grassroots efforts by enterprising managers who, for example, may encourage their teams to publish best practice documents on a file server. But while these organizations understand the importance of knowledge management, many of their initiatives produce mixed results. In fact, most knowledge management initiatives do not last more than six to twelve months. This is often because of the following factors:

  1. The knowledge management initiative lacks mass appeal — the initiative doesn’t have enough enthusiastic supporters or institutional support to reach critical mass where the benefits outweigh the time and dollar cost to support the endeavor.
  2. The initiative simply lacks depth — the repository isn’t large or diverse enough for its use to become a habitual activity for many employees. They visit once and never return.
  3. The knowledge isn’t qualified — the knowledge captured by the initiative is not validated, resulting in each individual employee having to expend energy in searching and filtering to identify the actual knowledge from the professed knowledge.
  4. Knowledge codification is ignored — the KM teams don’t put enough effort into adding metadata to the documents and organizing the learnings in a single repository, resulting in inefficient and duplicative KM systems from which it is difficult to search and extract knowledge.
  5. Competing systems undermine the effort — the KM initiative competes with too many other internal and external systems and processes as an authoritative knowledge source for employees.

Issues like these not only hamper the KM efforts, but, more troubling, their perceived value to an organization. As a result, many managers are becoming disillusioned with the potential of enterprise wide KM practices.

However, KM is getting a second chance with corporate intranets gaining new prominence in many organizations. As Fortune 1000 organizations recover from the recent economic downturn by consolidating their operations, revisiting their product roadmaps, merging with other firms, and positioning themselves as being more customer-centric and principled, they’re looking to their company intranets to communicate their new values, business objectives, and operational strategies to the rank-and-file. These organizations are also discovering that investing in an intranet is an expensive endeavor and that they must look for other benefits when trying to make a strong business case for an enterprise-wide intranet. This is where knowledge management enters the picture.

The KM opportunity
Some senior executives make the mistake of believing that knowledge management is an end unto itself and attempt to manage and measure KM success with that in mind. Rather, KM initiatives should be treated as intellectual capital investments aligned with specific, long-term business goals. For an organization to do this more effectively, it needs to leverage the Communities of Practice (CoPs) within its organization.

What is a community of practice? Brooke Manville, Director of Knowledge Management at McKinsey & Co., defines communities of practice as groups of people who are informally bound to one another by exposure to a common class of problems. These groups share their learnings and knowledge resources continuously and informally amongst each other for mutual benefit. Every organization has groups like these, which are typically loosely structured, decentralized, fluid, and built on personal relationships.

These CoPs are perfectly positioned to support knowledge management efforts. They are continuously capturing and sharing relevant knowledge with each other. Often, though, the knowledge captured is not directed towards a business objective and isn’t codified or validated in any formal capacity. Nor is the knowledge stored in a format that enables easy retrieval.

An organization can leverage these CoPs to further its KM objectives by stepping back and creating a list of priorities for what types of knowledge to capture and share. These priorities should directly map to the organization’s business goals and should represent what the organization needs to know to be more successful in the marketplace both at the organization and at the individual level. In other words, these priorities should be a list of “if only I knew” types of knowledge.

Once the business priorities have been identified, existing CoPs should be approached to more formally capture and roll out these organizational learnings in a piecemeal fashion using the intranet. If there aren’t any communities of practice naturally aligned to the business priorities, then new ones should be organized. Some large organizations with a history of knowledge management successes have already structured their communities of practice to do this for them on a regular, focused basis. However, these aren’t always successful initiatives because the CoPs have a hard time striking the right balance between knowledge explorations and being focused on the business goals.

Nevertheless, there are opportunities to further focus these communities of practice when using the enterprise intranet as a delivery mechanism. This is because collaborative environments such as enterprise intranets force the participants to be focused, thoughtful, and careful in their contributions. Knowing that what is published may potentially be viewed by the whole organization, or that other users may have the ability to rate the article, forces the participants to be more disciplined in their contributions. In effect, the collaborative, real-time feedback environments of a company intranet encourage self-policing and more strategic information sharing. The downside is that it can also discourage participants from sharing any information whatsoever.

Let’s take a management-consulting firm as an example to study this a little further and discuss how knowledge can be captured and shared.

A consulting firm example
In most consulting firms, knowledge priorities can be broadly categorized as knowledge that:

  • supports the business development and sales process,
  • contributes to the delivery of services in the form of methodologies, tools, and processes, and
  • builds awareness among employees of industry and discipline issues.

Let’s say that of these three knowledge priorities, the consulting firm identifies supporting the business development and sales process as being of the greatest importance. Further, it determines that actively sharing business proposals and case studies, along with the individual learnings regarding each one, is most important to satisfy the KM needs in this area. The organization can implement this knowledge priority via their intranet by doing the following:

  1. Choosing the right employees — Identify four to six employees who have been enthusiastic and informed KM supporters in the past to serve as community gatekeepers and monitor the publication of content if no existing CoPs exist that cover this subject area. If an appropriate CoP does exist, then gatekeepers from that community should be identified.
  2. Coaching the gatekeepers — Educate the gatekeepers on how to develop and nurture a new community of practice with a focused objective — in this case, capturing knowledge that can support the business development and sales process. The business objective should be further studied by the gatekeepers to more deeply understand what types of relevant learnings can be captured.
  3. Designing the collaboration environment — Create a collaborative space on the intranet for the distribution of these learnings. This space should allow for the submission, categorization, rating, and discussion of content. Careful attention should be paid to the structure of this workspace, from the labels used to who can access it and how much categorization is needed.
  4. Establishing rules for participation — Actively encourage employees to publish their relevant content to this collaborative workspace. These employees should be invited to join the community. The rules of participation, the organizational and personal benefits for getting involved, and the “safety net” guidelines to prevent discussions from spinning out of control should be explained. This collaborative workspace should support notification features so that users can be alerted when new content is added.
  5. Providing incentives — Tie in each participant’s KM involvement with his or her annual bonus. Reviewing how active the employees have been, whether they have been responsive and responsible community participants willing to share and learn from each other, and the quality of their contributions in relation to the business priorities should be included as contributors effecting their annual bonuses and raises.

An initiative like this doesn’t cost much and wouldn’t take long to implement. Once one knowledge community has been established, the organization could seek similar opportunities to create knowledge communities based on other business priorities. Thus over time it may have a network of interconnected communities that capture organizational and individual learnings related to specific business priorities. Remember that the more tightly defined the business priorities and the more motivated the community gatekeepers are, the more likely the initiative is to succeed.

Intranets as knowledge management platforms
Well-planned intranets make perfect platforms for your knowledge management initiatives. But most intranets aren’t deliberately planned, as they start out as grassroots, divisional efforts that are then leveraged across the whole organization. Many of these intranets hold valuable information but are wild, decentralized, and unstructured spaces. This can be a problem, as employees will only use the intranet as a learning, collaborative platform if they have confidence that it will consistently provide them with authoritative, validated, and qualified knowledge in return.

Your intranet can be optimized to support knowledge management initiatives if you make changes to the existing content, publishing processes, and information architecture of the intranet.

Evaluate your content
Existing content is the trickiest to deal with, as it is hard to know how much content is published online. Removing meaningless, orphaned, dated, and irrelevant content that is of little use to the employees is the first step in this process. This type of content has no place on the intranet and should be removed as soon as possible.

Another problem with the content on an intranet is that it could be published in the wrong place, in the wrong format, and potentially with the wrong amount of emphasis attached to it. Use professional content strategists and information architects to help you understand, manage, and evolve this content.

Make publishing more democratic
Publishing processes can really make or break the success of your KM intranet. Do not push the publishing of content down to the bottom of your corporate hierarchy. For the intranet to become a knowledge management platform with knowledge communities, every intranet user should know how to publish content and provide feedback on content already published.

Publishing should not be left to administrative assistants who don’t understand the content well enough to know where to publish it or whether it should be published online at all. Also pay attention to the actual publishing process, as this is your opportunity to codify individual learnings by forcing publishers to add metadata, categorize, and edit the content before publishing it.

Tweak the information architecture
Finally, if you hope to use your intranet as a knowledge platform to support your business objectives, pay particular attention to the information architecture. Research your users’ needs and, just as importantly, how the users relate to the current content and nomenclature on the intranet.

Consider categorizing all content by use rather than subject. Categorizing the content by the context of its use, the depth of the information, and the target audience will result in more distinct, intentional, and goal-oriented user experiences. It will also naturally limit the amount of redundant content published. Most intranets today organize content either by department or by Internal processes that only the process owners understand.

Conclusion
Knowledge management is becoming immensely important in today’s fast-paced, disruptive business environment. In fact, recent research conducted with 182 work groups at a Fortune 500 telecommunications company by Jonathon N. Cummings, assistant professor at the MIT Sloan School of Management, showed that teams that share knowledge, both intra-group and externally, perform better. These findings validate previous research and underscore the importance of knowledge management.

Still, organizations have struggled with implementing knowledge management effectively. Overly ambitious projects, a lack of attention to organizational cultures, and unsophisticated technology have doomed KM efforts in the past. The company intranet has been ignored or treated simply as a file server when it comes to sharing learnings.

But approaching knowledge management in a simpler, more tactical fashion where the emphasis is placed on the application of knowledge can be the key. Identifying your organization’s KM priorities, carefully focusing your communities of practice on these priorities, and upgrading your intranet to be a more of a knowledge platform will help you quickly develop a relevant, meaningful, and beneficial KM initiative.

References:

  • Kluge J., Wolfram S, and Licht T. 2001. “Knowledge Unplugged: The McKinsey & Company global survey on knowledge management,” Palgrave Publishing.
  • Cummings, Jonathan 2004 “Work Groups, Structural Diversity and Knowledge Sharing in a Global Organization,” MIT Sloan Management Review Winter 2004, Volume 45, Number 2, p. 5


Shiv Singh has been with SBI.Razorfish since 1999 and has worked in its Boston, New York, San Francisco and London offices. He helps clients leverage digital technologies to develop meaningful and value driven customer and employee relationships. Shiv primarily focuses on intranet and extranet design and likes to work at the intersection of business strategy and information architecture. If you want to learn more about him, visit his website at http://www.shivsingh.com