Boxes and Arrows: Stories by Joe Lamantia

Analyzing Card Sort Results with a Spreadsheet Template

Joe Lamantia, Joe Lamantia — Tue, 26 Aug 2003 21:10:06 GMT

“Once you've completed the data entry, you can immediately review your results.”This article explains how to quickly derive easily-read, quantitative results from a card-sort activity by entering data into a spreadsheet template that is adaptable to any set of cards and categories. The template provides visually attractive results showing:

In which categories each card appears
How often a card appears in any given category
Where cards appear by percentage
The number of unique cards in a category
Color coding to simplify interpretation
Summaries of category contents

You can see a preview of the results, using sample data, at right. Process and time requirements are minimal — all you need to do is paste your lists of cards and categories into the worksheet, enter your data, and tweak a few formatting rules. The template was developed as an analysis tool for interpreting the results of a card-sort exercise involving more than 100 items and approximately fifteen participants. The best known freely available automated card sorting tools (EZSort and WebCAT, for example) cannot work with item sets of this size. This template will accommodate 180 cards and 30 categories, but is easy to expand further via simple cutting and pasting of the cell references and formulae. Before You Begin Create and conduct your card sort, using numbered cards with a label and a short description. More information on how to complete a card sort is available in the references section at the end of this article. To help you get started quickly, I've provided a spreadsheet template, with examples, which you can download here. Preparing Your Spreadsheet Your first task is to alter the template to reflect the number of cards in your sort. Step 1: Open the Excel file and click the tab at the bottom of the window for the worksheet called Initial Card Count. Step 2: Cut and paste an alphabetical list of the titles of your cards into the column labeled Card Title (column A). The template includes a column for the card numbers (column B), which you may need for later reference. I recommend including the descriptions that appeared on your cards in the worksheets, as it is much easier for people who did not directly conduct the study to read and interpret the results when they have the original card description readily at hand. I usually place the descriptions in a new column (column C, in this layout) adjacent to the card numbers; you can see this on the last worksheet, “Summary.” Step 3: Paste this same list of card titles into column A of the other three worksheets: “Low & High Card Count,” “Card Placement Percentage,” and “Summary.” (I prefer to color code the card names on each worksheet according to different schemes, so I do not link the cells to the list on the first worksheet.) Don't worry about customizing the spreadsheet for your particular analysis needs just yet; it's easier to adjust the formulas and formatting logic for the worksheets after you've seen the results and feel comfortable with what they're telling you. There's more on this in the “Reading Your Results” section, and a complete list of the various formulas used in the worksheets in the “Formula Reference” sections below. Note: The “Card Placement Percentage” worksheet includes a hidden row (row 183, labeled “# zero % cards”), used as a shortcut to calculate values in the rows below. Be careful not to delete this row. Standardizing Categories for Analysis If your card sort uses predetermined categories (that is, if it's a closed sort), cut and paste the names of your categories into row 1 of the “Raw Data” worksheet; the template will automatically transfer these category names into the appropriate cells of the other worksheets. In an open sort you'll have to standardize the categories your participants create in order to effectively compare the placement of your cards (unless, of course, all the participants create exactly the same set of categories). This step is very important but tricky, so take care to think about the implications of ostensibly easy decisions. Here are three quick steps to help you arrive at a list of standardized categories: Step 1: Sort the category names your participants created into an alphabetical list. Strip any common prefixes (e.g., your company's name, the word “our”) from the user-created categories to expose the underlying topic or subject of the category. Step 2: Scan the list for groups of category names that are similar. Common methods of gauging similarity are by root word (noun or verb), by word order, or by meaning. Use the example below for reference. Combine categories with similar names into clusters, and choose a representative label for each cluster. Step 3: Review the remaining user-created categories, searching for common synonyms of the cluster labels (e.g., “employment” and “careers”). Add these to the initial clusters. Here's an example of how a list of raw categories might look when clustered: Step 4: Add any remaining categories from the original list of raw categories to the labeled clusters you've created. You now have a set of standardized categories to use in comparing card placement and category strength. Additionally, this list now maps user-created categories to the standard categories you're using for analysis. Make sure to save it, as you'll need it for reference when entering data into the spreadsheet. Some categories in the raw list will be unique, or won't easily fit into an existing cluster. Unless you're left with a large number (half or more of the total) of unique categories in the raw list, don't worry. If you do find a large number of unique raw categories, it's possible that your participants have widely different models of how to organize the content, which means that you'll need to rethink the starting set of items, or your approach, or both. Step 5: Cut and paste the final list of standardized categories (Edit > Paste Special, and check the box for “transpose”) across the Row 1 of the Raw Data worksheet. I like to color the cell backgrounds to make it easier to tell them apart when I'm entering the raw data. Note: The template will carry your category names forward to the other worksheets automatically. Entering the Raw Data Now for the fun part… Step One: Take a single group of sorted cards (cards in one raw category) from the collection of groups created by one participant, and match this raw category with the corresponding standardized category you chose earlier. You will likely need to refer to the document that maps the user-created raw categories to your standardized categories to ensure that you're entering the raw card data correctly. Step Two: Record the individual card numbers of the cards in the participant's raw category in the matching column for your standardized category in the “Raw Data” worksheet, entering only one card number into each cell in the column. Complete this process for one raw category at a time, until you've recorded the locations of all the cards in all the raw categories for one participant. Step Three: Moving through the collections of sorted cards from each participant, enter the card numbers from the raw categories they created into the columns for your corresponding standardized categories on the “Raw Data” worksheet. Note: Don't sort the columns on the “Raw Data” worksheet to get a preview of how many times cards are repeated in a given standardized category; it is much easier to check for data entry errors when the card numbers appear in the original order of entry. The template accommodates up to 250 entries in any one standardized category. Should you find that any of your standardized categories end up including more than 250 entries, you will need to alter the formulas in the spreadsheets to count the values from cells with row numbers greater than 250. This is explained further in the Formula Reference Section below. Here's a look at the Raw Data worksheet, showing sample categories and card data:
(Click to enlarge.) When you finish, you'll see that the other worksheets are populated with values, and some cells are in color. Reading Your Results and Customizing the Worksheets Once you've completed the data entry, you can immediately review your results. The template uses Excel's Conditional Formatting features to color and highlight cells with specific values, so you will probably need to make some simple changes to the logic that drives the formatting to accurately reflect the number of participants in your card sort, and the way that you wish to see results displayed. You can change the conditional formatting settings in any worksheet by:

selecting a block of cells in a worksheet
choosing the “Conditional Formatting” option from the Format menu

You will then see a dialog box that shows up to three conditions defined by simple Boolean operators and numeric values, each accompanied by a combination of formatting guidelines (font, color, background).
Conditional Formatting dialog. In this example, taken from a cell in the “Card Placement Percentage” worksheet, you can see three conditions defined in the formatting dialog box. The first condition sets the text color in all cells with a value of zero to white, which is an easy way to make results easier to read by cutting down on the number of cells that have visible results. The second condition sets the background color of cells with values between .01 and .34 to yellow, and the text color to a standard black. Since the values in these cells correspond to percentages, this condition makes it easy to spot cells with values in the bottom third of the results. The third condition sets the background color of cells with values between .66 and 1 to green, and the text color to black; this highlights cells with values in the top third of the results. Note: Excel applies conditions in the order you specify them, which means that you may need to think through combinations of logic-based conditions carefully to get the results you expect. You can read more about conditional formatting within Excel's Help libraries. Now let's take a look at the other worksheets. Worksheet 1 – Raw Data This worksheet contains the source data used to drive the values calculated on each subsequent worksheet in the template. It contains no formulas and no formatting. Worksheet 2 – Initial Card Count The Initial Card Count worksheet shows how often each card appears in each category. This is useful, but can be hard to digest, especially with a large set of cards and categories. Here's the Initial Card Count worksheet showing sample data:
(Click to enlarge.) Worksheet 3 – Low & High Card Count The Low & High Card Count worksheet shows the same numerical data, but employs some basic formatting features to highlight areas of interest and make the results easier to read. Here's the Low & High Card Count worksheet showing sample data:
(Click to enlarge.) Numbers are only visible in cells with card counts of one or higher. Using Conditional Formatting, I've specified rules that color the backgrounds of cells with card counts in the lowest third (light yellow) and highest third (light green) of the results to make them easier to pick out. (You might choose different color combinations to suit your needs and circumstances.) The rationale behind this is that a high occurrence count in a single category indicates clear agreement amongst users on where a card belongs, whereas a low count indicates a card that few agree on. You can change the thresholds for the formatting by opening the Conditional Formatting dialog box for any of the cells and altering the numeric values listed in the conditions to reflect your parameters. When you decide what rules to employ, remember that the total number of participants determines the thresholds for each segment of the results. The template assumes you have data from nine participants and wish to highlight what are roughly the highest and lowest thirds of the results. Accordingly, the conditional formatting rules come into effect for values of three or less, and six or greater. At the bottom of the Low & High Card Count worksheet, you'll find summary rows that show:

the total number of cards per category
the number of different cards per category
the ratio of these two measurements

I manually color-code the top five values in each summary row, again to make them easy to call out. While this isn't a solid statistical assessment of the data, it does give you an easy way to rapidly identify which categories are broadly and tightly defined, and to make some rough comparisons between them. Categories with a high ratio of total cards to different cards include many repeated cards. This indicates that your participants agreed often on the placement of those repeated cards within this single category. Compare the ratio to the number of participants in your sort. When these two numbers are close it's more likely that this category is strongly and consistently defined in the minds of participants. Categories with a low ratio of total cards to different cards do not include as many repeated placements of cards, which indicates that your participants agreed less often on which cards belong in this category. The real meaning of these numbers lies entirely in their context, so let's use a simple example to illustrate some of the conclusions you might derive from reviewing the results on this worksheet: Say that you ran a sort with 100 different cards; 30 of these cards included the names of songs written by Miles Davis, and the other 70 included a mixture of jazz songs by seven or eight other artists, the names of important jazz ensembles, musical styles related to jazz, famous jazz and blues albums, etc. If one of the standardized categories created during this sort was “Songs Written by Miles Davis,” you would expect it to contain approximately thirty different cards (one for each of the songs). The total number of cards in this category should be close to 300 — ten repeat placements of each of the thirty different cards for songs by Miles — and the ratio of total cards to different cards would be approximately 10 to 1, matching nicely with the number of participants. Even though this category contains nearly 30 percent of the original unsorted items, it makes sense in this context. If half of the participants chose to group songs by their opening key, and not by composer, you might see ratios much lower than 10, meaning that fewer participants agreed on how to create their category structures. Worksheet 4 – Card Placement Percentage The Card Placement Percentage worksheet lets you quickly assess the percentile distribution of placements for any card in relation to one another. Reading from left to right along a single row, you'll see percentages that represent the placement of each card in each standardized category as a percentage of all of the different placements for that card. High percentages indicate that more participants consistently placed that card in that category; naturally, the highest percentage is 100. I refer to these percentages as the level of participant “agreement” on the placement of the cards.
Card Placement Percentage worksheet. (Click to enlarge.)In the screenshot at left, look across the row for card #124. You'll see that it appeared in Category 1 (column AC) 50% of the time, and in Category 3 (column AE) only 13% of the time. By contrast, looking at the categories where card #147 was placed, you'll see that it appeared in Category 2 (column AD) 83% of the time. Clearly, a significant majority of participants agreed that this card belongs in Category 2 (column AD). Note: In this template, the Card Placement Percentage worksheet uses conditional formatting to highlight the lowest and highest thirds of the total set of results. Percentages above 66% appear in bold to make them easy to locate. You can change these thresholds by altering the decimal values in the Conditional Formatting rules. The far right columns of the Card Placement Percentage worksheet show the number of different categories each card appeared in across all of the results sets, as well as the average of all the percentage values. In these summary columns, conditional formatting highlights cards that appear in a large number of different categories (in this case, six or more, which appear in red), and those that appear in only two categories (in tan). Again, the rationale is to identify items that require immediate attention, or that offer ready opportunities for redefinition. At the bottom of the Card Placement Percentage worksheet, summary rows show:

how many high-agreement cards appear in each category
how many medium-agreement cards appear in each category
how many low-agreement cards appear in each category
the average-agreement index of all cards in the category

These are additional indicators of the strength of a category, and the way that cards were distributed across the different categories. I often manually color the top five results to allow faster spotting of strong and weak categories. The Card Placement Percentage worksheet, showing category summaries:
(Click to enlarge.) Note: Remember: The template includes a hidden row (row 183, labeled “# zero % cards”), used as a shortcut to calculate the values in the three rows below. Be careful not to accidentally delete this row. Worksheet 5 – Summary The Summary worksheet shows the summary columns from the far right of the Card Placement Percentage worksheet directly adjacent to the column containing the description of each card. It also includes suggested columns to use in comparing the current category location of each card with the location you understand the participants to prefer, and tracking recommendations and labeling changes for each card. I use this display for presentations with clients, developers, and business owners who need abbreviated results, rather than the exhaustive detail of the other worksheets. Interpreting the Results Interpreting the results of a card sort depends largely on the context of the exercise: what items you included, who participated, and what questions you hoped to answer or identify will all be important in shaping what you derive from the analysis. The strength of this tool is that it supports pattern analysis at more than one level: you can investigate individual cards, whole categories, and even — if you've defined them in advance — groups of cards and groups of categories. If you're using a card sort to drive the design of a new information architecture for an existing resource (perhaps navigation for a website), comparing the current location of items that fall into the lowest and highest results groupings with their user-preferred locations could indicate problems that require immediate attention or offer the greatest opportunity for improvement. Categories that include mostly high-agreement cards and few low-agreement cards are probably well understood in the minds of the participants, and represent structures you'll probably want to accommodate in your information architecture. Categories with many low agreement cards may indicate that participants were looking for a place for items they do not value or understand. Or it may mean that the labeling and content of the items is inconsistent, and users couldn't find a location that suited both the card name and description. Autofilters Using Excel's Autofilters (available under the “Data” menu via Data > Filter > Autofilter), you can display specific combinations of cards and categories to speed interpretation of the numeric results — for example, cards that participants placed in many categories, which indicate conflict about the cards' labeling and description. This is the Autofilter Dialog box: You can zoom in to display all the cards in a single category by percentage:
(Click to enlarge.) Or by count:
(Click to enlarge.) Or all the cards that appear in more than X number of categories:
(Click to enlarge.) While it is possible to use more specialized features in spreadsheet tools like Excel, or even dedicated statistical analysis packages, time and resource constraints make this a practical alternative for quickly deriving insight from the results of this common but usually labor-intensive user research technique. Formula Reference For easy reference while you prepare your own spreadsheet, this section collects all the formulas from the worksheets in the template. Each example formula is from the cells corresponding to the last card in the last category in the template. Most of the formulas are composed of simple functions like summing a range of numbers, comparing one value to another, or incrementing a counter to reach a total. Even if you're not an Excel power user, if you know just a little bit about how to use Excel’s formulas (which is certainly the case for me), you should be able to change these as necessary to suit your specific needs. Here are a few tips on what to look for and expect when customizing the template:

Adjust the template to fit the number of cards in your sort and the number of final categories by cutting and pasting whole rows and whole columns; Excel will update formulas and references automatically to reflect your changes.
The Initial Card Count worksheet counts up to 250 total cards in any one category on the Raw Data worksheet. If you end up with more (!) than 250 cards in any one category, you'll have to increase the value in the Main cell formula (see below) to make the template count all the cards.
Several formulas reference other worksheets; if you change the names of any of the worksheets in this template, most versions of Excel will automatically update all of the affected formulas.

Worksheet 1 – “Initial Card Count” Formulas Main cell formula =COUNTIF('Raw Data'!AD$2:AD$250,$B178) # Cards Per Category =SUM(AF2:AF179) Worksheet 2 – “Low & High Card Count” Formulas Total # Cards Per Category =SUM(AF2:AF179) # Different Cards Per Category =COUNTIF(AF2:AF178,">0") Ratio # Total Cards: # Different Cards =(AF180/AF182) Worksheet 3 – “Card Placement Percentage” Formulas Main cell formula ='Initial Card Count'!C2/MAX(SUM('Initial Card Count'!$C2:$AF2), 1) # Categories With This Card =COUNTIF(C178:AF178,">0") Average Agreement Per Category =SUM(C178:AF178)/AH178 # Different Cards =COUNTIF(AF2:AF178,">0") # zero % cards =COUNTIF(AF2:AF179,"0") # High Agreement Cards =COUNTIF(AF2:AF179,">.66") # Medium Agreement Cards =AF182-SUM(AF184,AF187) # Low Agreement Cards =AF186-AF183 Average Card Agreement =SUM(AF2:AF178)/'Low & High Card Count'!AF182 Worksheet 4 – “Summary” Formulas # Categories With This Card =COUNTIF('Card Placement %'!C178:AF178,">0") Average Agreement Per Category =SUM('Card Placement %'!C178:AF178)/D178

EZSort is available for download at http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/410 Information & Design — a usability consultancy in Australia — provides a brief and useful overview of how to conduct a card sort here: http://www.infodesign.com.au/usabilityresources/design/cardsorting.asp UsabilityNet.org discusses card sorting by placing it in context of the broader landscape of user research and usability tools here: http://www.hostserver150.com/usabilit/tools/cardsorting.htm Since 1996, Joe Lamantia has worked under many titles for very small interactive agencies, very large consulting houses, several medium-sized (and now defunct) internet integrators, and even started his own B2B exchange (which is also—unfortunately—defunct). He is currently the information architect in residence at a major software firm in Boston, and is enjoying the opportunity to practice his User Research chops. Joe would rather be in Italy, which he will happily discuss with anyone who reaches him at joe (at) joelamantia.com.

The Challenge of Dashboards and Portals

Joe Lamantia — Thu, 14 Dec 2006 22:05:31 GMT

"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. Figure 1: Example Dashboard Screen, Products Page (Click to enlarge.) 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.

It Seemed Like The Thing To Do At The Time

Joe Lamantia — Wed, 27 Jun 2007 07:14:11 GMT

This is Part One of our “Lessons From Failure”:http://www.boxesandarrows.com/view/lessons-from-failure Series.

“Failure is instructive. The person who really thinks learns quite as much from his failures as from his successes.” JOHN DEWEY

Several years ago, I changed careers, moving from designer to entrepreneur starting a dot com company. The experience taught me many lessons in the basics of how—and how not—to successfully build an Internet business. But the most valuable lesson I learned—one applicable to any business model, design challenge, technology, or industry—was in the powerful links connecting state of mind, self-definition, and failure. Startlingly, these same links appear no matter what size the group of people or the venture: from design projects and startup teams, to cultures seeding colonies abroad, state of mind and self definition are closely connected to how well a group responds to failure.

In the midst of the exuberant rush to (re)create communities on the Internet for a dizzying array of peoples and purposes, we should understand and respect this underlying pattern, whatever our role: founder, designer, or member. For though the growing wave of technosocial media may change how we conceive of and relate to the Internet by offering abundant opportunities to create and join new societies, these societies will remain driven by fundamental elements of state of mind and self definition.

To illustrate these ideas, I’ll briefly discuss three examples of new societies—the entrepreneurial ventures of their respective cultures—that faced failure: first, the small Internet company I founded, then two cultures facing environmental challenges. Two of these societies failed, and one succeeded.

It Seemed Like the Thing To Do at the Time

In the winter of 1999, I decided to start a business with two partners. I was working as an Internet strategy and design consultant at the time, so moving from designing online businesses for clients to designing one for myself felt like a natural step. We had a talented group of founders with the right mix of experience, and we had a good idea. We needed money in order to build substantial business and technology infrastructure, but capital for a good idea was easy to obtain in early 2000. Becoming an entrepreneur genuinely seemed like the thing to do at the time, since it offered a good opportunity to apply my skills and experience at a new level, and to my own vision.

We worked diligently to build the company for the next twelve months. Our team grew from 3 people to 10 people in the U.S. and China. We recruited a (bad) CEO. We recruited a (good) CTO. We assembled an impressive roster of critical business partners and advisors on both continents. We were fortunate—given the terrible business climate for online companies after the dot com crash—to receive several funding offers from the very beginning. But none of them were sufficient, and some were downright shady (I met a number of “unusual” people during this time ¹).

In March of 2001, after a year of unpaid overtime, I left my regular full-time position to dedicate all of my time to the new company. In this, I was joined by several other team members. Based on our previous successes, we believed proper funding was literally around the corner. Our business plan was exquisite, our financial projections were meticulous, we had customers and staff in place, and our execution strategy was finely honed. Like a Broadway production awaiting the audience on opening night, we were ready to go. All we needed was capital.

By the summer of 2001, despite considerable success during difficult times, we were at a financial breaking point. Lacking strong revenue, we could not continue without help from outside in the form of legitimate funding. The attacks of September 11th, 2001 shut down the New York capital markets, closing the door on any hope of venture funding shortly afterward. We closed up shop, my partners went their various ways, and I took another full-time position.

A Moment for Reflection

After the team disbanded, I reflected on the experience to understand why we had failed.

Vizzini’s Advice

In retrospect, as Vizzini from the Princess Bride would say, we made a series of classic blunders:

We had a complex concept

We sought too much money during a difficult funding climate

We hired the wrong CEO (beware of business men who dress like Cuban drug smugglers)

We were not willing to compromise or modify our plans

We grew the team too quickly

We relied on unrealistic financial projections

We underestimated the operational challenges

As a once and future entrepreneur, I interpreted these as straightforward lessons for my next venture: begin with an idea that is easy to understand, be flexible, don’t fear change, involve only trustworthy and talented people, make realistic financial assumptions about revenue and income etc.

In summary, I understood that our failure was driven by the fact that we focused too much effort on securing external funding, and not enough on growing essential day to day operations. Vizzini would say our true blunder was that we did not get involved on the ground in Asia!

The Power of State of Mind

“I have not failed. I’ve just found 10,000 ways that won’t work.” THOMAS ALVA EDISON

Staying the Course…

People often ask why we made the decisions that took us from our first to our final steps. Why didn’t we change our plans? Why didn’t we put more effort into other ways to build infrastructure? I always answer, “It seemed like the thing to do at the time.” Meaning because of our state of mind and the progress we’d made, this course of action seemed the best way to reach our goal. We certainly didn’t intend to fail!

State of mind is an umbrella term for the common outlooks and framing assumptions that define the ways people perceive and think about situations and themselves. State of mind also sets boundaries for what people can and cannot consider. In practice, individuals and groups interpret the world through a state of mind that defines their understanding of:

Cultural concepts and ideas

Their needs and goals

The situations and environments around them

Their roles and the roles of others (both groups and individuals)

Available choices and actions

The results of those choices and actions

In retrospect, it is clear our team shared a common state of mind that we were unwilling or unable to change. In this state of mind, underlying all the decisions we made from beginning to end was a single goal: seeking external funding was the best thing to do for the business. Based on our shared understanding, we pursued this goal far past the point when a heavily venture-funded model became invalid, because the environmental conditions that sustained it had collapsed.

A glance at the headlines provides abundant examples of similar responses to failure driven by state of mind, such as the heated debate between the U.S. Congress and the Bush administration over different approaches to the ongoing U.S. involvement in Iraq. President Bush’s state of mind is epitomized by his dictum to “stay the course,” a view that substantially determines the choices considered possible by his administration.

Waiting for Rescue: Self vs. Other

Some time ago, I came upon a quotation from an 8th century Buddhist philosopher named Shantideva that changed my perspective on my experience as an entrepreneur. In “Entering the Path of Enlightenment,” ² Shantideva writes, “Whoever longs to rescue quickly both himself and others should practice the supreme mystery: exchange of self and other.” When Shantideva says, “exchange of self and other,” he is advising us to change our self-definition, one of the most basic components underlying state of mind.

Shantideva, or Manjushri

So I came to see that my team of entrepreneurs had set out on the wrong path from the beginning, and never wavered, because our state of mind rested on defining ourselves as venture funded entrepreneurs. We never considered changing our self-definition. Obtaining funding became part of our identity, rather than a pragmatic business activity. There is a second parallel with Shantideva’s words: we were unable to consider other courses of action even after we recognized that we were in danger of failing, because we were waiting for rescue from outside. We believed outside funding would save us.

We never considered how our self-definition was leading us to failure. Nor did we consider that we might find another way to succeed if we changed our self-definition. President Bush would be proud: we managed to stay the course!

Easter Island: A Machine for Making Statues

My experience as an entrepreneur shows the power of state of mind in societies on the small scale of a closely focused startup team. The Easter Island society that collapsed in the 18th century clearly demonstrates the strong connections between self-definition and failure on the much larger scale of a complex society of approximately 15,000 people. (The discussion that follows draws upon the work of Jared Diamond in Collapse. ³)

Easter Island

Easter Island was settled approximately 1200 A.D. by Polynesians from islands further to the west. ⁴ The small (64 miles square) island remained essentially self-contained due to its remote location in the Pacific Ocean. ⁵ The population increased quickly as settlers rapidly cleared forests for farming. Based on common Polynesian religious practices, the Easter Islanders began carving the immense volcanic stone statues (Moai) that make the island famous, mysterious, and photogenic.

Easter’s Statues

Over the next 500 years, in a remarkable demonstration of the power of a common state of mind and self-definition, Easter Island’s religious and ceremonial practices effectively turned the entire society into a machine for the construction of statues. ⁶ The Easter Islanders built their social and political system around the creation of statues. Reward mechanisms offered prestige and power to chiefs who competed to carve and erect ever larger statues, on ever larger platforms. Driven by this institutionalized self-definition, the population collectively invested massive effort into carving and transporting thousands of tons of stone for each burial platform and for the hundreds of giant Moai placed upon them. ⁷

Wood from the island’s forests was literally the fuel that kept this statue-making machine running. Farming to produce the food needed to feed large groups of workers required ever increasing amounts of cleared land. Moving statues required large wooden carriers and hundreds of miles of rope. Funerary rites mandated cremation and burial in the gigantic stone platforms. As Easter Island’s human and statue populations grew rapidly, estimates of the island’s forest coverage declined precipitously, as this comparison chart shows.

Figure 1: Forest Cover vs. Population ⁸

This self-reinforcing cycle of statue creation, deforestation, and population growth created a recipe for environmental collapse that lead to comprehensive social failure. ⁹ Conservationist Rhett A. Butler summarizes the findings of Terry Hunt, an anthropologist who studied Easter Island’s history of habitation:

“With the loss of their forest, the quality of life for Islanders plummeted. Streams and drinking water supplies dried up. Crop yields declined as wind, rain, and sunlight eroded topsoil. Fires became a luxury since no wood could be found on the island, and grasses had to be used for fuel. No longer could rope by [sic] manufactured to move the stone statues and they were abandoned. The Easter Islanders began to starve, lacking their access to porpoise meat and having depleted the island of birds. As life worsened, the orderly society disappeared and chaos and disarray prevailed. Survivors formed bands and bitter fighting erupted. By the arrival of Europeans in 1722, there was almost no sign of the great civilization that once ruled the island other than the legacy of the strange statues. However, soon these too fell victim to the bands who desecrated the statues of rivals.” ¹⁰

Lessons from Easter Island

Easter Island Today, Deforested

The tragic pattern is clear to see: though institutionalized practices and goals based on a narrow self-definition were leading to comprehensive failure, the Easter Islanders refused (or were unable) to change their state of mind and goals, and their entire society collapsed. To this day, Easter Island is almost totally deforested, with the exception of small patches of trees from recent plantings, and the ~400 stone statues that remain. In a potent instance of irony, the Easter Islanders succeeded in constructing dramatic and enduring stone testaments to those things their society valued, even as the act of constructing those monuments consumed their society. President Bush would be proud of the Easter Islanders, too—they stayed the course.

A Tikopial Paradise

It is on our failures that we base a new and different and better success. – HAVELOCK ELLIS

Tikopia Today

The Pacific island society of Tikopia is a good example of a culture that successfully responded to failure, by changing how its members define themselves. Tikopia differs from Easter Island in ways that make the challenges its inhabitants faced more pressing. Tikopia has been inhabited far longer (since ~900 B.C.), is much smaller (only 1.8 miles square), has fewer natural resources, and supports a much higher population density than Easter Island. ¹¹ Yet photographs of Tikopia today show a lush, green landscape that is well-forested, while the island is populated by closely spaced communities of villages, supported by well-tended gardens and farm fields.

Over the history of human habitation on Tikopia, three different economic and social models governed the production of food and management of the island’s environment. For the first 100 years of habitation, the Tikopians relied on a slash and burn style agricultural model that severely damaged their environment through deforestation. They also mined the nearby shellfish and bird colonies for needed protein.

Recognizing that this model was unsustainable on a tiny island, the Tikopians changed agriculture and food production practices to a mix of forest orchards and pig farming, wherein livestock made up ~50% of their protein sources. This new model retained a two-tiered social structure, allocating scarce protein to a ruling class of chiefs. Under the forest garden model, Tikopia’s environment continued to degrade, albeit more slowly than before.

Such a quick and comprehensive shift in economic and agricultural approaches across a whole culture—even a small one—is rare. By around 1600 A.D., the Tikopians again faced environmental and social breakdown driven by resource use. They again deliberately changed all aspects of their sustenance model and social structure in a single, closely coordinated effort:

Switched from unsustainable agriculture to a sustainable permaculture model ¹²

Completely eliminated expensive and inefficient livestock (pigs)

Substituted fish for large land animals

Removed social and economic distinctions—no more chiefs

Adopted stringent population management practices

Lessons from Tikopia

The dramatic changes in Tikopia’s social and economic model dating from ~1600 equate to a concerted shift of identity (self-definition) and state of mind for all of Tikopian society, a moment they commemorate to this day through oral storytelling. Unlike Easter Island, Tikopia’s society makes no distinction between the resources allocated to leaders and to the populace. Tikopian society does not reward environmentally destructive activity. The result is a stable population, kept carefully in balance for approximately 400 years by a range of practices that limit growth. All of these decisions were driven by a state of mind based on matching human impact with the island’s limited resources for the entire society.

Shantideva would surely say the Tikopians are remarkably flexible and resilient: instead of waiting for rescue, they averted failure (through environmental and social collapse) by redefining themselves not once, but twice.

Heed Shantideva

As an entrepreneur, I was one member of a small group making decisions about a single business venture which affected only our own lives. But as designers, architects, technologists, business owners, or anyone involved in building the new virtual societies emerging under the banner of social media, we have the power to affect many lives, by shaping self-definition and state of mind in a community from the very beginning.

We can’t predict every situation a starting society will face. But we can assume that potential failure is one challenge that may arise. And so—based on these three examples of societies facing failure—it seems wise to heed Shantideva’s advice about the exchange of self and other, thereby making our efforts now a part of the solution to future unknown problems. We can do this by allowing for changes to self definition, and by encouraging awareness of, and reflection on, state of mind, whether in our own venture or when we design a society for others.

Footnotes and References

¹ They ran the gamut from debased expatriate executives, to corrupt former politicians (with gout), to alcoholic ex-CIA operatives, to the founder of a major mainframe computer maker, to veterans of anti-communist coups in Africa during the 70’s. Or so they said…

² Bodhicaryavatara, ch. 8, v. 120

³ Diamond, Jared. Collapse: How Societies Choose to Fail or Succeed. Penguin Books: 2005.

⁴ Terry L. Hunt; Rethinking the Fall of Easter Island.

⁵ Easter Island is 1,400 miles from its nearest neighbor (tiny Pitcairn Island), and 2,500 miles from the nearest large land mass, Chile.

⁶ Competing clans and chiefs received social status and rewards, such as farmland and food resources, from the successful construction of more and larger statues, giving them clear incentives to continue carving and erecting Moai. In effect, Easter Island’s cultural / political / economic system was built around an unusual positive feedback loop, in which more statues for a clan meant more people and more power, which meant more statues, which meant more people and more power… Similar carving traditions exist among other societies elsewhere in Polynesia, but on much smaller scales.

⁷ A recent count shows 300 platform and burial sites (ahu) around the island, with approximately 400 statues. There are 300 tons of stone in a small ahu, and 10,000 tons of stone in the largest. The average moai is 13 feet tall and weighs 10 tons, the larger moai reach up to 32 feet tall and weigh 75 tons. Another 400 moai sit partly completed in quarries, reaching heights of up to 75 feet tall, and weighing 270 tons.

⁸ Simon G. Haberle, “Can climate shape cultural development?: A view through time,” Resource Management in Asia-Pacific Working Paper No. 18. Resource Management in Asia-Pacific Project, The Australian National University: Canberra, 1998 Working version obtained at http://coombs.anu.edu.au/Depts/RSPAS/RMAP/haberle.htm

⁹ Diamond writes, “The overall picture for Easter is the most extreme example of forest destruction in the Pacific, and among the most extreme in the world: the whole forest gone, and all of its tree species extinct.”

¹⁰ Rhett A. Butler, Easter Island settled around 1200, later than originally believed

¹¹ Tikopia; Tikopia.

¹² Permaculture Permaculture.

Introduction to the Building Blocks

Joe Lamantia — Tue, 24 Jul 2007 07:36:45 GMT

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:

Basic principles and assumptions underlying the block system, and how it can complement other design approaches.
Assembly guidelines and stacking hierarchy which shows how to combine blocks into larger units while ensuring a sound and consistent information architecture.
Modular building blocks of all sizes (Containers)
Modular navigation components (Connectors)
Standardized Convenience Functionality for blocks, which recommends a baseline set of common capabilities such as export of building block content, printing Tiles, etc.
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.
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:

It is possible to stack blocks with a lower stacking size (“smaller” blocks) inside blocks with a higher stacking size (“larger” blocks).
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].
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].
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.
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].
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.

Building Block Definitions (Containers)

Joe Lamantia — Wed, 26 Sep 2007 09:12:57 GMT

This story is the third in a series of articles 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, “

Overview of the Container Blocks

The building block system includes seven types of Containers, beginning with the Tile, and increasing size and complexity to include a collection of interconnected Dashboards or Portals, called a Dashboard or Portal Suite. From smallest to largest, the Container blocks are:

Tile
Tile Group
View
Page
Section
Dashboard or Portal
Dashboard or Portal Suite

The different kinds of Container blocks in the system play different roles, based on their relative size, in the overall effort to construct dashboards or portals. The smaller blocks--Tiles, Tile Groups, and Views–-enable the display of content, and support users’ interactions with content. Sections, Dashboards or Portals, and Dashboard or Portal Suites–-the larger blocks--enable the navigation, organization, and management of collections of content. Pages straddle the middle of the size continuum; they are the largest block whose role is primarily to provide a framework for display of dashboard or portal content, and the smallest building block which plays an important navigational / organization role in the system. The different kinds of blocks work in concert to enable the creation of a scalable, navigable, and maintainable information architectures that support high-quality user experiences. The Connectors (described in part four of the series, the next installment) ‘hold things together’; thereby creating navigation paths amongst destinations, establishing a tangible architecture or structure, providing referential cues for orientation with the environment, and allowing movement into and out of the environment. The different kinds of Containers work in concert with Connectors to enable the creation of scalable, navigable, and easily maintainable information architectures that support high-quality user experiences.

Container definitions

Each Container block definition includes:

Mandatory components
Optional components
Stacking size
Detailed description
Example rendering (for illustrative purposes only)
Rendering description

Tile definition

Mandatory components: Tile Header, Tile Body Optional components: Tile Footer Stacking size: 1

Tile description:

Tiles are the fundamental building block of the dashboard or portal framework. Tiles locate content and functionality within the coherent information and navigation hierarchy of the larger dashboard or portal environment, while clearly identifying the sources and broader contexts of the information or tools they contain, and offering consistent access to convenience functionality such as printing and e-mailing the Tile contents for use outside the dashboard. Tiles consist of two required components–-a Tile Header and Tile Body–-and one optional component--the Tile Footer. Tiles may include multiple Control Bars (note: adding multiple Control Bars can quickly increase development complexity and lower usability levels). The Tile Header contains a mandatory Title, optional Subtitle, mandatory source indicator identifying the origins of the content, and may include buttons or links for Convenience Functionality (described in detail in a subsequent part of this series). The mandatory Tile Body can contain nearly any form of content. Tiles commonly contain text, charts, tables, interactive maps, scrolling news feeds, RSS consoles, video, slideshows, syndicated XML structured documents, links to documents and resources, and complex transactional functionality. Of course, this is only a small subset of the tremendous diversity of Tile-delivered content available in the rapidly growing libraries of widgets published for Apple’s OSX desktop, Yahoo’s widget platform, Google Gadgets, web desktops such as NetVibes, and the many social networking platforms including FaceBook and MySpace. In the end, the range of content that can appear within a Tile is limited only by imagination and ingenuity. The optional Tile Footer is a structurally consistent location for contextual links, pointers to related destinations and content. The Tile Footer commonly offers links to additional resources or source data in another format (tab delimited, .pdf, etc.), links to other Tiles, Pages or areas of the Dashboard that provide related content or functionality, links to other applications and environments offering comprehensive functionality or information out of scope for the Tile, etc. The sizes and internal layouts of individual Tiles will vary depending upon several factors including, but not limited to their content, priority vs. neighboring Tiles or blocks, and expectations for reuse. It is good practice to define a grid for screen layouts that prescribes standard sizes for Tiles and all screen elements, and match the sizes and internal layouts of Tiles to this reference grid. Here are a few guidelines on information design and interaction design standards within Tiles:

Each chart, table, or text block within a Tile needs an accurate title or label
Charts may have a footer area that offers additional data values, a key or legend for the items shown in the chart, links to additional resources, or source data in another format
Tiles that contain long lists, large tables, or other large objects may scroll, depending on the interaction and design standards and capabilities of the dashboard or portal platform
Tables in Tiles often allow users to change sorting order or open and hide columns
Charts summarizing large amounts data can offer interactions or drill-down behaviors allowing users to navigate deep data sets

Many of these interaction behaviors and design best practices are now offered as standard functionality--making them ‘free’ or ‘low-cost’ in design and development terms--by leading business intelligence and portal platform vendors. Additionally, these capabilities are also becoming standard in many general purpose presentation frameworks, including RUBY and AJAX libraries, and the various for-purchase (Adobe AIR, etc.) and open-source development toolkits. Stacking note: Tiles stacked inside larger building blocks retain their individual Tile Header, Tile Body, and any optional components.
Figure 12 shows an example rendering of a Tile. Figure 12: Tile components and structure

Serve a group of executives running a large organizational unit within an enterprise, such as Marketing, Manufacturing, or Information Technology.
Provide a class of information resources giving insight across an enterprise, such as inventory monitoring, sales forecasting, financial reporting, and quality control assessment.
Offer functionality in support of specific roles that entail responsibilities across the enterprise, such as regional directors, account managers, or human resources directors.

I recommend labeling or branding these kinds of internally focused Dashboards or Portals clearly, to help communicate their contents and purpose to users and administrators who will likely have to work with many different tools and environments, and may easily suffer disorientation as a result. A simple title such as “Corporate Finance and Accounting Dashboard” can help distinguish one Dashboard or Portal in a Suite from another for busy users. I also recommend creating a log-in or destination page that orients users and confirms they are accessing the correct Dashboard or Portal to meet their needs. In more public and social settings, the patterns of architecture, usage, and design at this level of size and complexity naturally differ. Design note: Depending on the depth and complexity of the assets offered within any one Dashboard or Portal, it may make sense to create a separate Home Page that introduces the structure and contents of the Dashboard, and offers unique content. Home Pages in this style commonly provide trend charts with roll-ups of more granular metrics, score-card style visualizations that communicate status for major areas of interest, alerts that require business attention, and high-level summarizations of the more extensive information available deeper inside.
Figure 17 shows an example rendering of a Dashboard. (click on image for larger view) Figure 17: Example Dashboard or Portal

Rendering description:

This sitemap style rendering shows a medium-sized Dashboard or Portal designed to meet the information and business functionality needs of a large enterprise with multiple operating units and business lines. In this context, the Dashboard provides cross-unit summaries of many important metrics for senior managers, and could even provide them business functionality to alter business processes, change supply chain structures, or revise finance and resource allocations. This Dashboard or Portal consists of a dedicated Home Page, and five major sections: Marketing, Finance, Products, Supply Chain, and Administration. The first four sections--S.1 through S.4--are linked via a Section Connector, offering direct navigation between these Sections. Each of these Sections includes a summary style Page. The Administration Section is not linked and navigable via the Section Connector: access to this Section would come via another path, generally direct URL entry or at the Dashboard or Portal log-in prompt (not shown). Within the major sections, all Pages are linked and navigable via Page Connectors.

Dashboard or Portal Suite definition

Mandatory components: Dashboards Optional components: None Stacking size: 7

Dashboard or Portal Suite description:

A Dashboard or Portal Suite consists of a group of stacked (though at this high level of structure, the construct is more akin to a collection of interlinks rather than hierarchically arranged) Dashboards or Portals sharing integrated content and common infrastructure. Stacking Dashboards or Portals as a Suite allows design and support teams to organize and manage distinct but related Dashboards or Portals as a single unit, and can help users by giving them quick and direct access to the collection of interconnected Dashboards or Portals. These Suites generally serve a diverse population of users who draw on a variety of business intelligence resources or other functionality to execute job functions at a variety of levels within the enterprise. The goals or purposes of the Dashboards or Portals in a Suite may vary dramatically; hence their individual content offerings will also vary dramatically. Users whose business needs or functions require them to work with single Dashboards or Portals in a Suite may not realize the commonalities underlying the various individual Dashboards or Portals they use. Users whose needs span multiple Dashboards or Portals in a Suite typically rely on a Dashboard or Portal Connector to move from one Dashboard or Portal to another within the Suite. From an enterprise level architectural or IT administrative viewpoint, the Dashboard or Portal Suite can become the connection point to other enterprise level systems, such as metadata registries and repositories, ERP and SCM applications, enterprise data stores, security and authentication platforms, intranets, extranets, etc. The Dashboard or Portal Suite is also a useful unit for enterprise level perspectives including IT portfolio management, business process management, strategic information management, and knowledge management.
Figure 18 shows an example renderingof a Dashboard Suite. Figure 18: Example Dashboard Suite

Rendering description:

This sitemap style rendering shows an enterprise level Dashboard Suite made up of seven individual Dashboards that share assets. Five of the seven provide depth of content in major domains of a global enterprise: Supply Chain, Human Resources, Product Development, Knowledge Capital, and Finance. Each of these domain Dashboards has a distinct internal structure, with the individual Sections identified on this map. The remaining two Dashboards--Global Leadership and Regional Leadership--aggregate assets for presentation to the different levels of executive leadership within the enterprise. Within this scheme, the information architecture of the two leadership Dashboards is closely parallel, but the scope of the assets shown in each would differ; users of the Regional Leadership Dashboard would have a view of Finance assets for their individual regions, and not globally, as in the Global Leadership Dashboard. In this Suite, the five domain Dashboards are linked to the two Leadership Dashboards via a Dashboard Connector, meaning that each of these is navigable directly from the Leadership Dashboards. The Regional Leadership Dashboard is also linked to the Global Leadership Dashboard via another Dashboard Connector. Whether these Connectors allow two-way access is dependent on the individual access rights of the various Dashboard users. The Dashboard Connector here ensures that the members of the respective leadership teams can literally see what their colleagues see when discussing a course of action.

Coming soon: Building Block Definitions (Connectors)

The fourth installment of the series will define the Connector components in detail.

Boxes and Arrows: Stories by Joe Lamantia

Analyzing Card Sort Results with a Spreadsheet Template

The Challenge of Dashboards and Portals

Portlets: MIA (Missing Information Architecture)

Escaping flatland

A vision: syndicated assets for enterprise portals

It Seemed Like The Thing To Do At The Time

It Seemed Like the Thing To Do at the Time

A Moment for Reflection

The Power of State of Mind

Waiting for Rescue: Self vs. Other

Easter Island: A Machine for Making Statues

Lessons from Easter Island

A Tikopial Paradise

Lessons from Tikopia

Heed Shantideva

Footnotes and References

Introduction to the Building Blocks

The Building Block System

Overview

1. Basic Principles and Assumptions

Principle:Openness

Principle: Portability / Syndication

Principle: Independence

Principle: Inheritance

Principle: Layering

2. Assembly Guidelines and Stacking Hierarchy

Social Building Blocks Mechanisms and Network Effects

Building Block Definitions (Containers)

Overview of the Container Blocks

Container definitions

Tile definition

Tile description:

Rendering description:

Tile Group definition

Tile Group description:

Rendering description:

View definition

View description:

Rendering description:

Page definition

Page description:

Rendering description:

Section definition

Section description:

Rendering description:

Dashboard or Portal definition

Dashboard or Portal description:

Rendering description:

Dashboard or Portal Suite definition

Dashboard or Portal Suite description:

Rendering description:

Coming soon: Building Block Definitions (Connectors)