Introduction to the Building Blocks

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.

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.

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.

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).

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.

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.

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].

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.