Building Block Definitions (Containers)

by:   |  Posted on

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, “Connectors for Dashboards and Portals

Part 3 now describes the Container components of the Building Block system in detail.


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


Rendering description:

This wireframe shows the structure of a Tile with an attached Control Bar. The Tile Header offers several types of convenience functionality (print, e-mail, and PDF export of the Tile). The Control Bar offers a single selector. The Tile Body contains a chart and table, each with a title and footer or key. The Tile Footer contains four links, to a mixed set of destinations.


Tile Group definition

Mandatory components: Tile Group Header, Tile Group Body
Optional components: Tile Group Footer
Stacking size: 2


Tile Group description:

Tile Groups consist of two required components – a Tile Group Header and Tile Group Body – and may include an optional Tile Group Footer. Tile Groups may include multiple Control Bars (note: adding multiple Control Bars can quickly increase development complexity and lower usability levels). The Tile Group Header contains a mandatory Title, optional Subtitle, mandatory source indicator, and may include buttons or links for Convenience functionality.

A Tile Group typically combines two or more Tiles together–likely from different sources or perspectives–into a larger unit of information or functionality that allows the combination of resources to answer more complicated questions, or achieve more complicated tasks. A Tile Group might answer the question, “How are my daily sales vs. my competitor’s daily sales?” by presenting a Daily Sales Tile and a Competitor Sales Tile next to one another, under the combined title “‘Daily Sales vs. Competitor Sales’.”

In this scenario, these two Tiles likely present information that comes from different data sources (perhaps one internal, and one licensed from a third party market metrics service), and different organizations that used the building blocks system to coordinate user experience design and development efforts that rely on a common enterprise portal or platform foundation. The consumers of the individual Tiles are likely affiliated with separate business units or operating groups, and may not need or be aware of the other Tiles, or the Tile Group. The consumers of the Tile Group could easily be part of a third element of the organization–or perhaps they are affiliated with the originating groups for the separate tiles, but share a common management perspective or performance incentive that requires a comparative presentation of the source information.

Stacking note: Tile Groups stacked inside larger building blocks retain their individual Tile Group Header, Tile Group Body, Tile Group Footer, and any optional components.

Design note: While Container definitions mandate some components to maintain the structural integrity of the building blocks system (always a Tile Header, etc.), they do not mandate constant visibility or display of all the structurally required components. Excess chrome is the enemy of a good user experience at all levels of structure, and should be avoided. Many existing interaction patterns, control mechanisms and design principles can help eliminate excess chrome, and minimize the presence of chrome in general to that which is necessary for a high quality user experience, without increasing the effort or cost of relying on the building blocks.

Figure 13 shows an example rendering of a Tile Group

Figure 13: Tile Group components and structure


Rendering description:

This wireframe illustration shows the structure of a Tile Group with an attached Control Bar. The Tile Group Header offers several types of convenience functionality (print, e-mail, and PDF export of the Tile as rendered). The Control Bar offers two selectors. The Tile Group Body contains two stacked Tiles; one Tile offering text, the other offering the combination of a chart and table seen previously. Note that both stacked Tiles retain their individual Tile Headers and Tile Footers. In this rendering, neither stacked Tile offers convenience functionality, though it is possible for stacked Tiles to offer convenience functionality.


View definition

Mandatory components: View Header, View Body
Optional components: View Footer
Stacking size: 3


View description:

Views consist of two required components–-a View Header and View Body–-and may include an optional View Footer. Views may include multiple Control Bars (note: adding multiple Control Bars can quickly increase development complexity and lower usability levels). The View Header contains a mandatory Title, optional Subtitle, mandatory source indicator, and may include icons for accessing standard convenience functionality.

A View typically combines Tiles and Tile Groups together to present a comprehensive set of information resources that address a single perspective within an area of interest. In common use, Views allow Dashboard or Portal users to see the most logical subsets of all available Tiles related to one aspect of an area of interest. For example, many Tiles might provide information about a single product–too many to appear on one Page–but the Customer View of a product presents only those Tiles that show information about a single Product in relation to major Customers. Another defined View could offer marketing information for that same product, and a third might allow executives to check inventory levels for the product at various storage facilities.

Views stacked inside larger building blocks retain their individual View Header, View Body, View Footer, and any optional components.

Figure 14 shows an example of rendering of a View.

Figure 14: View components and structure


Rendering description:

This wireframe shows the structure of a View with an attached Control Bar. The View Header offers several types of convenience functionality (print, e-mail, and PDF export of the View as a single unit). The Control Bar offers two selectors. The View Body contains two stacked Tile Groups, one Tile offering text, the other offering the combination of a chart and table seen previously. The stacked Tile Groups retain their individual Tile Group Headers, but do not include Tile Group Footers. In this rendering, neither stacked Tile Group offers convenience functionality, though it is possible for stacked Tiles to offer convenience functionality. The View Footer contains links to a variety of documents, applications, and destination sites.


Page definition

Mandatory components: None
Optional components: None
Stacking size: 4


Page description:

It’s best to talk about Pages in two senses; first as building blocks or Containers, and second as browsable destinations for users navigating dashboard or portal environments. In the first sense, as part of the hierarchy of building blocks in the dashboard or portal system, Pages are simply a larger kind of Container without mandatory components. They are governed by the same principles of portability, openness, independence, etc. as the other blocks, which means individual Pages may not be visible to some types of users, depending on security restrictions, and could consist of a mix of smaller building blocks and elements of free-form content. I considered calling them ‘nodes,’ to emphasize the distinction between their building block system role and their browser navigational role, but that felt too abstract.

In the second sense, Pages take on their traditional role as presentation canvases for content and functionality, linked together by navigation mechanisms: they serve as the single-screen units of display and interaction familiar from the Web browsing paradigm. In this role, Pages become the delivery vehicle for combinations of Containers and Connectors that allow users to work with content, and move through the dashboard or portal environment. Pages typically combine collections of Tiles, Tile Groups, and Views with a set of accompanying Connectors (Section Connectors, Page Connectors, Crosswalk Connectors, Geography Selectors, and Utility Navigation) to create a navigable user experience. Pages–following the principle of Openness–may include free-form content or navigation mechanisms. Common examples of free-form content include search functionality, global navigation, links to intranets and extranets, feedback forms for requesting new features, and branding elements.

A Page can consist of a single Tile, or only free-form content, may or may not have a Page Header or Page Footer managed as building blocks assets, and might not be connected to or accessible from other areas of the Dashboard or Portal. For example, a Page dedicated to account administration functions might only be visible to members of the user group Account Administrators, who themselves cannot see other areas of the Dashboard or Portal, and thus would not require navigation connections to other Pages in the Dashboard or Portal.

Figure 15 shows an example rendering of a Page.

Figure 15: Page components and structure


Rendering description:

This wireframe shows the structure of a Page that mixes free-form content with building block content. The free-form elements appear in the form of a typical dashboard page header that contains a stock ticker and market summary, and a staff directory search box. Branding elements such as logos identifying the individual dashboard often appear as free-form content.

The building block content includes a navigation cluster made of a Section Connector and a Page Connector, two stacked Tiles, and a View that contains two stacked Tile Groups (Tiles not shown). On this Page, the two independent Tiles and the View are stacked at the same level within the containing Page. The layout of this Page places the Tiles above the View to ensure they remain visible without scrolling, but this layout is not necessary by the rules of the building block system. The individual Tiles on this Page do not include either Control Bars or Footers. The View includes a Control Bar with two selectors. None of the blocks offers Convenience Functionality, though of course this is possible across all levels of the stacking hierarchy, and is commonly available for the Page itself.


Section definition

Mandatory components: 1 Page
Optional components: None
Stacking size: 5


Section description:

The Section is primarily an organizational building block, but it does have a mandatory component of at least a single Page; this is to define an explicit context for navigation, user role. Sections typically consist of collections of Pages related to a core conceptual element of the information architecture or mental model for the Dashboard or Portal. It is not uncommon to see broadly defined Sections such as “Products,” “Customers,” “Supply Chain,” or “Sales.” Deep or complex Sections offering a considerable number of Pages or a large amount of content commonly include summary style Pages that condense or introduce the full contents of the Section in an overview. Shallow sections offering few Pages often do not require a summary style Page.

Figure 16 shows an example rendering of a Section.

Figure 16: Example Section


Rendering description:

This site map style rendering shows a Section, titled Products, which contains five Pages that offer a variety of content related to the two types of Products produced and sold by a fictional company. The Section begins with a summary Page titled Products Overview. The four additional Pages are titled Branded Products, Product Focus, Co-Branded Products, and Co-brand Product Focus. The five pages contain a mixture of stacked Tiles, Tile Groups, and Views. The summary Page, titled Products Overview (P.3), offers the following: two stacked Tiles, Daily Sales (T.1) and Top 10 Products by Volume (T.12); and a stacked View, titled Products Sales Briefing (V.3).

By personal preference, only the blocks stacked at the level of the Page–level 3–are individually identified on this map-style rendering; the Views and Tile Groups would obviously include further Tiles stacked within. I use this rendering convention to cut down on visual clutter in maps of large dashboards or portals. For your own renderings, feel free to itemize every stacked block at every level on the Page, or even list the dashboard or portal contents in simple outline fashion without pictures. Each stacked block in the rendering is identified by its Title, and a unique ID code or label, to allow synchronization with a master list of building blocks available across all dashboards. The numbered lines indicate that each Page includes a standard Page Connector, offering navigation between all the numbered Pages in the Section.


Dashboard or Portal definition

Mandatory components: 1 Section
Optional components: None
Stacking size: 6


Dashboard or Portal description:

The Dashboard or Portal is the largest single unit of meaning possible to assemble from stacked building blocks. A Dashboard or Portal must consist of at least one Section (itself made of at least a single Page). Dashboards or Portals typically consist of several connected Sections, assembled from connected Pages that contain a variety of stacked building blocks, combined with a smaller number of stand-alone Pages dedicated to utility functionality or administration. Most Dashboards or Portals rely on a variety of Connectors to link assembled building blocks into a cohesive and navigable whole. A Dashboard or Portal’s information architecture often aligns with a single mental model, or a small set of closely overlapping mental models, though this obviously depends on the needs and goals of the expected users.

To most users of internal tools situated withing an enterprise, a Dashboard or Portal is the total set of Sections, Pages and other stacked building blocks their security and access privileges permit them to see and use when they visit a URL or some other user experience destination (note: for web-delivered Dashboards or Portals, it is common practice to create a URL and expose this address via an intranet or other internal gateway). Since each user has an individually determined and potentially different set of security and access rights to each possible Section, Tile, View, and Page, each user will likely see a different combination of Dashboard or Portal content that is tailored to his or her own needs.

In this way, individual Dashboards or Portals often draw from a pool of defined Tiles and blocks which:

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

A Map-Based Approach to a Content Inventory

by:   |  Posted on

In my current role, I have been responsible for creating a large intranet site from scratch for a local government department, and I now have the ongoing problem of maintaining it and ensuring all information is kept up to date.

The initial model for the site worked surprisingly well for a time but has been the victim of its own success. It now has well over a thousand pieces of internal and external content, and staff surveys have shown that findability has deteriorated over time. (Is there a law in that somewhere…? Same model + more content = poorer findability?)

I wasn’t surprised. I had reached the same conclusion some time before. The system was creaking at the seams and needed major surgery.

The Problem

I realized I could no longer rely on memory alone for a record of what the system contained—the content space was getting too large. Content needed to be periodically checked for currency and completeness to ensure that the system retained its credibility with users.

I was also feeling uncomfortable about succession planning issues because knowledge of the intranet’s structure and content existed only inside my head. If I got knocked over by the proverbial bus, it would be very difficult for someone new to visualize how the system was structured. I soon reached the conclusion that a formal content inventory system was needed.

I only found out that I was an IA a year ago, but I quickly gathered that doing a content inventory, while an important tool, is on par with cleaning out the garage or reconciling your bank account: Necessary, but no fun.

Bearing in mind the complexity of the site, I decided that any inventory needed to have two attributes:

  • A data attribute, such as Excel or Access sheets listing unique page number, title, content owner, approval/review dates, etc.
  • A structural attribute, since a list can only convey so much. I needed to know how all the pages and content were connected together

I felt the structural attribute was of greater importance. My mental picture of the intranet at this time was of a large plate of spaghetti. What linked with what? If I move this page, what else will it affect?

I did some research but could find nothing that answered my purposes.

Part of the Solution

The data attribute was easily achieved. I have worked with Access databases for quite a while and found them to be of great use. Creating the database was the easy part.

The structural attribute was the real problem. I had the latest version of Visio loaded on my laptop and started to play around with different ways of visually representing the intranet linkages.

I tried the ‘family tree’ approach, system mapping, business process charts, and so on, and found that there were two major problems with all of these approaches:

  • I had a problem with getting all of the information I needed on a single page.
  • It didn’t mean much to me when it was finished. Everything was there, but what was it saying to me? I didn’t know.

I was feeling a bit desperate. The date for the redesign was looming large and I dreaded the thought of carrying out such major surgery, as it were, in the dark.

Then I stumbled across the ‘Metro’ stencil in Visio and this brought to mind an attempt I’d made some time ago to produce a site map based on Harry Beck’s 1933 map of the London Underground, a concept now used in most public transport maps around the world.

I thought it was worth another try and started to build up a structure of the home page using the Metro stencil. I was pleased with the initial result. There was a clarity and simplicity in this approach that allowed me to concentrate only on the hierarchies and categories that formed the structure. I could also easily play around with all the elements by dragging them singly or in groups around the page.

What it needed to be complete, I thought, was some way of inserting links so that I could have a look at the actual webpage and some way of expanding the pages attached to the home page to show sub-maps. Both proved to be very simple. The insert hyperlink function works more or less the same as in Microsoft Word, so I could now link the page (station) titles to the relevant web pages.

I could easily create sub-pages by using the insert new page function in much the same way as in Microsoft Excel. Using the stencil, with some customised components, made creating sub-maps very easy, especially when similar structures already existed on previous pages. Whole lines and ‘stations’ could be quickly copied and pasted. The new sub-map could then be linked by a bookmark from the station roundel on the home or higher level page.

The different colored lines can be used to represent anything. The page below is one I am working on the moment. In this case, the green line pages are sub-pages, the blue line pages belong to other sections within the site, and the red line pages are external links.


Saving the whole document as a web page meant that I now had the ability to quickly click from map to map and, when I needed to look at the relevant web page, it would be only one click away. So far, so good.

Rest of the Solution

The new problem I had now was that my content inventory was effectively in two halves – data in one, structure in the other. I needed to connect them. Fortunately, the Visio people (and Donna Maurer) had already thought of this. By selecting Tools/Add Ons/Visio Extras/Link to Database, I found that I could link a shape to a particular Access database record. When saved again as a webpage, Control + Click displayed the database fields on the left hand side of the screen. I could now view both the data and the structure at the same time.

It was about this time I was seen dancing around my desk, shouting ‘Yes!’


Before I attempted any surgery on the intranet, I produced a map of the front page and major categories (above) and created sub-maps to drill down as far as possible. Iterative reviews eventually revealed a massively simplified structure. Once I was satisfied, I began surgery, using the maps to ensure that I kept strictly to the designed structure.

It’s working really well. I can only compare it to the joy of having a satellite navigation device in your car when trying to find a street in a town you’ve never been to before.

There were standard activities required for every page, such as link to database, link to sub-maps, link to webpage, and the like. To ensure that I didn’t miss anything, I created a status bar through which I could easily track what had been done for each page. I found this a very useful tool because I often had to stop and work on other projects. Tasks done were greyed out so that outstanding tasks could be clearly seen.

How To Do It

This approach to content inventory (I call it bird’s eye view, for want of anything better) should yield more value than the normal approach to an inventory. When I design my next intranet, I’m going to start with the maps, creating as much structure as possible and then validating it with clients and users. As it is a well known paradigm, most people get it straight away, with one caveat: I sometimes needed to explain that you don’t need to go through one ‘station’ to get to another.

Spending time planning the site at this early stage, especially when able to build in user research, should save a lot of time down the line.

Once the basic structure is set, the pages can be numbered and the database pages created and linked. Before a single webpage is coded, a ‘statement of requirements’ or wireframe may be produced for major pages. The map can function as the ‘spine’ of the development process by ‘station’ titles being linked to the statements or wireframes allowing the structure to be evaluated for completeness before coding begins.

The use of the status bar also allows for collaborative working as teams can easily see what has been done and what needs to be done on any page.


This approach provides a tool that can be used throughout the lifetime of a website. It starts off as a development tool, allowing the structure to be considered and documented without the distractions of other irrelevant information. It can be easily understood by users and clients and their views can be sought at an early stage.

Throughout development, the map can be iteratively assessed and amended and the database pages can be used for notes. The use of the status bar or similar can provide a quick indication of progress to date for each page.

The map, being a webpage, can be easily accessed and can be made available to stakeholders if required. This way clients, and even users if an intranet, can follow progress without having to be updated by the development team.

Finally, when the project is complete the content inventory can be handed over to whoever is managing the site as a tool for maintaining the site and controlling content. It could even be made available to users as an alternative way of navigating the website.

After giving it some thought, I find that the thing I like most about the map is that it is pure, stripped down navigation. Harry Beck decided that including streets, districts and other geographical information on his underground maps was distracting and added little value. All you need to know is how to get from A to B. I suspect that the same may be true in information spaces.

If you want a copy of the Visio stencil, you can get it here.

If you want the Mac stencil, you can get it here.

Introduction to the Building Blocks

by:   |  Posted on

The Building Block System

This story continues the Introduction to Building Blocks Series.

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

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


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.


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.

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

Here are the assembly guidelines to determine proper block stacking:

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

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

stacking example
Figure 11: Stacking Example

Social Building Blocks Mechanisms and Network Effects

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

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

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

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

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

What Does Rich Mean?

by:   |  Posted on

Amid the current hype of Web 2.0, rich has become the de facto buzzword suggesting fresh, sexy digital products, often marked by glossy buttons with AJAX-driven behaviors. But what does rich mean to a UI (user interface) designer who wants to craft intelligent, compelling, and memorable interactions? Given current digital and technological trends, today’s UI designers must deepen their understanding of richness. Such an effort will strengthen designers’ vocabularies (adding legitimacy and weight to client discussions), and enable designers to temper judgment when it comes to applying rich capabilities.

Before delving into notions about richness, it is critical to acknowledge the core challenge of designing rich experiences. Designers face an ongoing battle for human attention across the digital landscape—from websites and desktop applications, to mobile devices and beyond. Newer technologies allow for greater levels of information display and dispersion, enabling access anytime, anyplace. Scholar Richard Lanham has noted that we now live within an “attention economy” where designers must effectively arbitrate the scarcity of human attention. Those who know how to command the landscape of competing words, images, sounds, and motion will aid user goals more effectively. 1 Therefore, to move beyond the hype surrounding richness, it is vital to clarify its meaning.

A Framework for Experience: Rhetoric

For a common understanding of richness, it is necessary to step back and reference the dictionary. Typically, the definition of rich includes words such as abundant, plentiful, intense, and of course, wealth. Entities associated with richness are described as indulgent or saturated, like savory foods, glossy photographs, and luxurious objects. But how do these descriptions apply to online banking, mobile messaging, and other digital encounters?

To better articulate the relationship between richness and the quality of experience, we need to understand what is meant by user experience (UX). Controversies and definitions abound, but for the purposes of this article the approach is broad: A subjectively interpreted, continuous stream of psychological and physical phenomena brought into awareness through an interaction. 2 A complete user experience depends upon the correlation of three human elements:

Attention: the connection between a person and a form

Attraction: the process of being drawn to a form and engaging with it on multiple levels

Satisfaction: a fulfilling sense (yes, it’s a feeling thing!) of being useful, usable, and desirable 3

Admittedly, this description could refer to a number of situations, but within this article it applies to encounters with websites, mobile devices, and desktop applications. Using this framework, we can then identify the area of impact where richness becomes important: The choreography of sensory elements—text, image, sound, motion, and behavior—that comprise a digital experience and transform it into a compelling statement that entices a user to interact with a product. In sum, this transformation is about forming an argument, or persuasive message that is memorable and pleasing. Thus, richness enables a designer to communicate more effectively and sensually, and allows users to participate more fully in support of their goals.

The sensory elements listed above are not about flashy marketing spin, but rather how the user experience becomes a type of social, or rhetorical, communication. This communication between the designer and the user is mediated through digital elements that attract the user’s attention and compel the user to access the product or service for some goal. Hopefully, the goal is what the user intended to accomplish! Engagement is about the creation of an argument directed toward improving people’s lives: paying bills more easily, learning a new subject, or sharing photos with friends. The argument must be made into something integrative and whole, rather than a patchwork of poor navigation, buried features, and annoying graphics. According to classical rhetorical theory, which dates back 2,500 years to Aristotle and Cicero 4 , the necessary components of a well-formed argument include are:


Logos: the reasoning behind the argument

Pathos: cognitive and behavioral affects in relation to audience expectations

Ethos: the argument’s emotional voice or presentational style

These components must be shaped by a definition of the audience, the purpose of the argument, and the designer’s tone of voice. 5 Rounding out this rhetorical stance is a sense of plot or narrative (mythos), which brings the argument into completion as a consummated experience, whole and complete, and worthy of re-living and sharing with others (e.g., repeat sales and customer testimonials). See how this all connects!

If these concepts seems alien (or even antiquated), note that the key components of a classical argument described above are in line with views espoused by “Jeff Veen”: and “Bob Baxley”: in their works discussing web design and web-based applications. As designer “Luke Wroblewski”: has noted, such fundamentals seem to always come in threes!


Intersection of Richness and Experience

If a digital user experience is a form of social and rhetorical communication, then richness must address ways of amplifying rhetoric of that message through sensible and powerful means. By taking a closer look at rhetorical structure and the intersection of richness and user experience, we can then identify the key places where richness enhances engagement. 6

Rich Structure: Enhanced informational structure, layout, and content. The value is delightful (and convenient) discovery that aids in understanding of content.


  • Progressive layers of data
  • Different degrees of data connectivity
  • Findability marked by serendipitous discovery


  • “Spivot”: A media reader that aggregates news sources and user-generated content; the site is enhanced by a multi-faceted browsing model for gathering news feeds.
  • “LinkedIn”:, “Friendster”, “Orkut”: These social networking sites are based upon the six degrees concept of human connectedness, allowing for rapid discovery and browsing social contacts.
  • “Amazon”: Despite being the prime global marketplace, the Amazon website offers confusing navigational methods for purchasing and browsing items and creating lists.

Rich Behavior: Greater ability to interact with data and features using behavior and motion cues. The value is direct, real-time feedback that provides confidence and trust.


  • Direct manipulation and instant feedback without latency or page re-loads
  • Drag-and-drop interactivity (e.g., a constructor-like UI model)
  • Animation for presenting and dramatizing the interface


  • “Flickr”:http// Online photo site offers editable photo labels and descriptions, a drag-and-drop photo set builder, and interactive slide shows.
  • “Google Maps”: and “Yahoo Maps”: Using different technologies, both sites feature map manipulation, real-time traffic data, and zoom features aided by a mouse wheel.
  • In contrast, gratuitous Flash-enabled video advertisements distract the user, or worse, are displayed across the main content and have hidden close buttons that distract and annoy.

Rich Style: Visual embellishments that provide luminosity and convey texture and atmosphere, thus enhancing user experience.


  • Gradients and drop-shadows
  • Rounded edges
  • Translucent effects


  • Apple dashboard widgets: These whimsical mini-applications are rendered in a glossy or translucent fashion, adding to their stylishness.
  • XBOX 360 dashboard: The main hub for browsing, game play, and setup features a subtly animated background accompanied by glowing buttons, as well as gradient and shadow treatments tailored for a gamer audience.
  • Windows Vista: In contrast, the operating system for Vista features heavy styling that overwhelms the user and fails to provide organizational cues and system stability.

An Emerging Definition

By breaking down the major moments where richness amplifies the user experience we can arrive at a cumulative definition: A sensory-enhanced communication targeting human attention at key levels to comprise an argument. Its purpose is to enliven dialog with a digital product, thereby providing users with a sense of positive engagement. In his book “Emotional Design”:, “Don Norman”: illuminates the impact levels of user experience:

  • Visceral (physical or bodily)
  • Behavioral (psycho-motor skills)
  • Reflective (psychological interpretation and understanding)

Interestingly, these three levels map nicely to the underlying structures of argument and user experience!

  • Visceral : Style : Ethos
  • Behavioral : Behavior : Pathos
  • Reflective : Structure : Logos

While increasing the emotional appeal of a UI through seductive cues can have a positive impact, the level of complexity increases as well:

  • Information increases and becomes more dense
  • There are more visual cues begging for attention
  • A changing mix of graphic elements and behaviors across web, mobile, and desktop applications begin to blend

Quite simply, having flashy buttons and animated tabs are of no benefit if the labels are misaligned or somehow inhibit task completion. Good ol’ fashioned craft through sound typography, color, and layout remain vital. Each design variable is a communicative signal, but when combined with others, they merge to create an expressive message that informs and inspires. If executed poorly, these variables can interfere with the user’s goals and become a mess of interface signals.

The Burden and Gift of Richness

Designers must apply rich elements in careful balance (much like composing an argument where neither structure, nor style and behavior overwhelms the other) and be ever mindful of context and semantics. Will the meaning of the argument be enhanced by richness? These questions will only intensify as physical-digital interfaces, interactive cinema, and on-demand services herald new challenges for UI designers. Approaching them with an eye toward richness, combined with the goal of expressive communication, can help address difficulties and awaken the full potential for improving people’s lives.

It is useful to briefly remind ourselves that richness existed long before computers. Just think back to the last dinner you enjoyed with friends or family, complete with a delicious meal, aromatic wine, and sumptuous dessert. That moment exemplified a rich experience. The exchange of ideas, the multi-sensory objects, and the choreography from the arrival at the restaurant, to the waiter’s performance and the food’s presentation, all contributed to a sense of richness. This example and others like it can be a powerful remedy to hype-driven attempts at designing for richness.

And therein lays the great burden and hope of designing for rich experiences. As arbiters of human attention, designers must ensure there is not an overload of superfluous, gratuitous richness that distracts users or makes a product difficult to use. Recognizing that every digital product is a rhetorical moment amplified by expressiveness can enable designers to tap into the promise of rich experience: Intelligently crafted, well-intentioned acts of communication that are emotionally satisfying and sensibly organized to meet user goals, thus becoming something memorable and valuable. Ultimately, that is what richness is about—connecting to those core human qualities that define our goals, values, and attitudes for living.7


1 Lanham, Richard A., “The Economics of Attention”:

2 Gajendar, Uday. The Aesthetics of Design: A Model of Beauty for Designers. 2004 IDSA National Educators Conference, Pasadena, CA.

3 Ibid.

4 Rhetoric is typically regarded as sly double talk attributed with politicians and salesmen. Rhetoric is in fact a classical art formalized by Aristotle, which led to a discipline devoted to studying and performing persuasive public speech. As a situated art of communication, rhetoric offers strategies to shape people’s actions and thoughts with language. For more information on rhetoric, please see works by Richard Buchanan and Wayne Booth—and for hardy souls, Richard McKeon.

5 Booth, Wayne C. (1963). The Rhetorical Stance. College Composition and Communication, Volume 14, Number 3, Annual Meeting, Los Angeles, CA.

6 Screenshots of these examples can be found in this “Flickr photo set”:

7 For further pointers on how to put these ideas into practice, please visit “my blog”:

Two Designers, Two Years, One Facelift…

by:   |  Posted on

I can’t recall how or when I first learned of the Boxes and Arrows redesign contest. On July 5, 2004, I sent an email to a good friend, Matt Titchener, proposing that we enter the contest together. I got to know Matt while working with him at a nonprofit organization developing intranet web applications. We discovered that we shared the same appreciation and views toward usability, accessibility, web standards, and visual design. Matt is also one of those rare talents that possess great design ability as well as a keen technical understanding in web development/design. After confirming Matt’s interest in the contest, we embarked on what would become more than a two-year journey to redesign Boxes and Arrows.

The contest

From the start, Matt and I agreed to take this contest seriously, approaching it as if we were revamping a website for an actual client. We spent much time studying the existing site hierarchy and brainstorming for ways to produce better user experience. We knew that we didn’t have to convince Boxes and Arrows’ audience of all the invaluable and insightful articles and discussions on the site. It was only a matter of how to get readers to the content more effectively. We were looking to accomplish a very intuitive navigation and site structure/flow to allow the readers to reach their desired content with the fewest clicks possible. It took us roughly a month to create our initial design concept (see Figure 1 & 2), which we are still quite pleased with even to this day. Then with about four days remaining to the deadline, I revisited the contest guidelines and comments posted by the Boxes and Arrows staff. I realized that the B&A folks were looking for a fresh and entirely different look, but the design that we created still too closely resembled the existing site (with its color scheme and layout).

I became convinced that in order for us to have a better chance at winning the contest, we would have to rethink our concept. So painfully, we decided to put aside the design that we had worked so hard on, and started from scratch with a different visual approach. After a few sleepless nights, with heavy bags under our eyes, we submitted our new design concept less than two hours before the contest closing time (see Figure 3 & 4).

Then we waited…

Three months later, I received an email with the subject line “Congratulations!! You have the winning Boxes and Arrows Site Redesign Submission.” I habitually ignore and delete all email that has subject lines beginning with “Congratulations!! You have won…”, assuming spam, so I nearly missed this one! Not until I read through my inbox more carefully later that day and recognized it was from Erin Malone, did I realize that we had actually won the contest. I immediately rang up Matt in London to share the good news with him. I stopped everyone that passed my desk that day to tell them all about the contest. The announcement of our win put a fixed grin on my face for days to come.

front page
Figure 1: First iteration of the front page design

author page
Figure 2: First iteration of the author’s page design

front page contest
Figure 3: Final front page design submitted to the contest

category page contest
Figure 4: Final category page design submitted to the contest

Redesigning the redesign

In January of 2004, we began working with Christina Wodtke and Erin Malone on the implementation of the design. During one of our initial conference calls, we asked for permission to create another design concept different from the one we submitted. Since we only had a very short timeframe to put together the contest entry after our decision to start from scratch, we felt that we did not have adequate time to create a design that fully represented our capability or design vision. Christina and Erin kindly agreed to our request.

For the next nine months, we went through many rounds of brainstorming sessions, looking at ways to improve the visual presentation, the functionality, and the structural flow of the site (see Figures 5-7).

site structure proposal
Figure 5: Site structure proposal submitted with the design

issue transition
Figure 6: Idea for how articles should flow/transition through the front page from issue to issue

site map
Figure 7: Proposed sitemap

The folks at Boxes and Arrows made it clear from the onset that they would like to see B&A take on more of a magazine look instead of the blog-centric feel that it had previously. We began looking at various print magazines like Time, Wired, Newsweek, and National Geographic, trying to figure out what elements in periodical cover designs make people quickly recognize a magazine when they see one. We identified strong typography, compelling imagery, and the concept of weekly or monthly issues as the elements that we would like to bring into our site design. (“Transcending CSS”:, a book recently written by Andy Clarke, includes chapters entitled “Marking Up the World” and “Looking for Grids Outside the Web” touching upon the approach of bringing visual elements from different media to the web.) A few weeks later, we created a mockup of the front page. This mockup became the foundation of the design that you see today.

second redesign
Figure 8: First iteration of second redesign

Design ideas and solutions

Instead of a traditional navigation menu, we incorporated a tag cloud into the site’s left navigation design. Because of the variety of categories listed in the left navigation, we initially took this approach not only to highlight the categories with the higher number of articles, but we felt that different font weight distributions in the navigation menu would also draw the users’ attention to the category list. We invested much time in creating the best algorithm and rendering method to make this work effectively. At the end, B&A decided to leave this piece out after the site launch due to the arrangement of the current taxonomy on the B&A site and the evenly distributed number of articles across the categories (which negates the reason for having a tag cloud to highlight the variance between categories). Nevertheless, we still considered it a clever design approach and hope to see it implemented on the site again one day.

Two other areas that we put much thought into were the layout of the new articles on the front page and the transition/flow of the articles from issue to issue. We wanted to accommodate the different number of articles being published and at the same time create a dynamic layout that provides a fresh look to the front page in every issue, much like a print magazine. We proposed a template system that will allow the editors to easily choose the layout with the best fit each time they publish new articles (see Figure 9 and 10). I believe as the PublicSquare CMS continues to mature, a future plug-in can make this workflow even more automated.

Regarding the transition of articles on the front page, as you can see in Figure 6, we created a flow that will smoothly bring the articles from the new article spots at the top of the front page down to the “Previously” section whenever new articles are published. Eventually, the older articles will be moved out of the front page and will be found in the archived story section of the site. This helps to provide our readers a good sense of continuity each time when they visit the site and enables them to quickly locate the most recent issues.

Anther finer touch was the use of the font-embedding feature in Internet Explorer to apply a more attractive type (Helvetica Neue Medium 67) to the article titles and the issue header, while making sure it degrades gracefully with a similar core web font in other browsers with the help of CSS.

page layout creation process
Figure 9: Proposed process for creating different front page layouts for publication

article transition
Figure 10: Examples of different front page layouts based on the number of new articles

After several iterations of changes and refinement of this magazine site concept in collaboration with Liz Danzico and Christina Wodtke over a period of two months, we arrived at a polished design concept that was ready to be implemented (see Figure 11 & 12).

final front page design
Figure 11: Final front page redesign

final article page design
Figure 12: Final article page design

A bump in the road

While we were conceiving Boxes and Arrows’ new site design, “PublicSquare”:, a new content management system (which now drives the B&A site) created by Christina and Lars Pind was in the works. We soon shared the growing pains of PublicSquare as we were met with challenges in implementing our design into this developing CMS. After failing to launch the new design prior to the 2006 IA Summit, we went back to the drawing board and the implementation phase of the design was put on hold as Lars worked hard to integrate a new theme engine/templating language (“Liquid”: into PublicSquare. You can read more about this in “Christina’s article”:

Towards the later half of 2006, the maturing PublicSquare was ready for us to begin the implementation phase again. It took another few months for us to port over our design into the Liquid theme language with the PublicSquare API. Because of some intricacies in the design, the amount of effort and time required for this phase far exceeded our expectation. It also happened to be the busiest time of the year for our day jobs so we had a bit of a difficult time juggling the work. Nevertheless, slowly but eventually, on the evening of January 15, 2007, we raised the curtain on the new Boxes and Arrows site. I can’t begin to describe the overwhelming sense of joy and relief that we had seeing our design live on the web.

The tortoise crosses the finish line

It has been a long ride. From the day that we received Erin Malone’s email to the day that our design finally launched was almost exactly two years. On this road of redesign, there were many IM chats and Skype calls made, numerous late nights and working weekends spent, and countless cups of tea and coffee consumed. It took awhile, but we got there. Working with these folks at the forefront of the IA community has been a great learning experience. The positive responses from industry leaders in the field of web design have also been a real reward to us.

We hope to continue to contribute to Boxes and Arrows as well as the community it serves. But for now, I am going to get some much-needed sleep, so good night!

See also: Are We There Yet for more tales of the redesign.